Node環境変数を実際に使用する方法は次のとおりです

環境変数はノード開発の基本的な部分ですが、何らかの理由で、環境変数を適切に使用する方法を学ぶことに悩まされることはありませんでした。

おそらく「環境変数」と呼ばれているからでしょう。

「環境変数」という言葉だけで、PTSDが組み込まれたフラッシュバックがトリガーされ、WindowsのJavaホームディレクトリに正しいパスを追加しようとしています。PATHまたはJAVA_HOME、あるいはその両方になりますか?セミコロンで終了する必要がありますか?なぜJavaを使用しているのですか?

Nodeでは、環境変数は(Windowsのように)グローバルにすることができますが、多くの場合、実行する特定のプロセスで使用されます。たとえば、Webアプリケーションがある場合、次のことを定義する環境変数がある可能性があります。

  • リッスンするHTTPポート
  • データベース接続文字列
  • JAVA_HOME…待って…いいえ—ごめんなさい。治癒過程には時間がかかります。

このコンテキストでは、環境変数は実際には「構成設定」に似ています。どれだけいい音がするかわかりますか?

以前に.NETを実行したことがある場合は、web.configファイルのようなものに精通している可能性があります。ノード環境変数は、の設定とほとんど同じように機能しweb.configます。ハードコーディングしたくない情報を渡すための方法です。

しかし、Nodeアプリケーションでこれらの変数をどのように使用しますか?必要な量のJavaジョークでこれに関する適切なリソースを見つけるのに苦労したので、それを作成することにしました。Nodeアプリケーションで環境変数を定義して読み取ることができるさまざまな方法のいくつかを次に示します。

ターミナルに渡す

ノードプロセスの一部として、ターミナルで環境変数を渡すことができます。たとえば、Expressアプリを実行していて、ポートを渡したい場合は、次のように実行できます…

PORT=65534 node bin/www

おもしろい事実:ポート65535は、利用可能な最大のTCP / IPネットワーク値です。どうすればそれを知ることができますか?もちろんStackOverflow。誰かが何かをどうやって知っていますか?ただし、ウェブアプリのポート65534までしかアクセスできません。これは、Chromeが接続する最も高いポートであるためです。どうすればそれを知ることができますか?LiranTalがコメントで私に言ったからです。あなたは彼に従うべきです。私たち二人の間では、彼は自分が何をしているのかを知っている人です。

コードで変数を使用するには、process.envオブジェクトを使用します。

var port = process.env.PORT;

しかし、これは醜くなる可能性があります。接続文字列がある場合は、端末で複数の変数を渡し始めたくないでしょう。あなたは構成値を蓄えているように見えます、そしてあなたを愛する誰かが介入を行うことができ、それは関係するすべての人にとって厄介でしょう。

PORT=65534 DB_CONN="mongodb://react-cosmos-db:swQOhAsVjfHx3Q9V[email protected]react-cosmos-db.documents.azure.com:10255/?ssl=true&replicaSet=globaldb" SECRET_KEY="b6264fca-8adf-457f-a94f-5a4b0d1ca2b9"

これはスケーリングせず、誰もがスケーリングしたいと考えています。私がこれまでに会ったすべてのアーキテクトによると、「スケーリング」は、アプリケーションが機能するよりも重要です。

それでは、別の方法を見てみましょう:.envファイル。

.envファイルを使用する

.envファイルを使用すると、環境変数をファイル内に配置できます。.envプロジェクトで呼び出される新しいファイルを作成し、そこに変数を別の行でスラップするだけです。

PORT=65534 DB_CONN="mongodb://react-cosmos-db:swQOhAsVjfHx3Q9V[email protected]react-cosmos-db.documents.azure.com:10255/?ssl=true&replicaSet=globaldb" SECRET_KEY="b6264fca-8adf-457f-a94f-5a4b0d1ca2b9"

これらの値を読み取るには、いくつかのオプションがありますが、最も簡単なのはdotenvnpmのパッケージを使用することです。

npm install dotenv --save

次に、環境変数を使用する必要がある場合は常に、プロジェクトでそのパッケージを必要とします。dotenvパッケージには、そのファイルをピックアップし、ノードにこれらの設定をロードします。

Use dotenv to read .env vars into Node require('dotenv').config(); var MongoClient = require('mongodb').MongoClient; // Reference .env vars off of the process.env object MongoClient.connect(process.env.DB_CONN, function(err, db) { if(!err) { console.log("We are connected"); } });

ヒント:.envファイルをGithubにチェックインしないでください。秘密はすべて含まれており、Githubからメールでその旨が通知されます。私のようにならないでください。

良いね。しかし、これは一種の苦痛です。これは、環境変数を使用するすべてのファイルに配置するdotenv必要があり、実際には必要のない本番環境にデプロイする必要があります。私は無意味なコードをデプロイすることの大ファンではありませんが、私は自分のキャリア全体を説明したと思います。

幸い、VS Codeを使用しているので(もちろん使用しているため)、他にもいくつかのオプションがあります。

VSCodeでの.envファイルの操作

First off, you can install the DotENV extension for code which will give you nice syntax highlighting in your .env files.

DotENV - Visual Studio Marketplace

Extension for Visual Studio Code - Support for dotenv file syntax

marketplace.visualstudio.com

The VS Code Debugger also offers some more convenient options for loading values from .env files if you are using the VS Code Debugger.

VS Code Launch Configurations

The Node debugger for VS Code (already there, no need to install anything) supports loading in .env files via launch configurations. You can read more more about Launch Configurations here.

When you create a basic Node Launch Configuration (click on the gear and select Node), you can do one or both of two things.

The first is you can simply pass variables in on the launch config.

This is nice, but the fact that every value has to be a string bothers me a bit. It’s a number, not a string. JavaScript only has, like, 3 types. Don’t take one of them away from me.

There is a simpler way here. We’ve already learned to love .env files, so instead of passing them, we can just give VS Code the name of the .env file.

And as long as we are starting our process from VS Code, environment variables files are loaded in. We don’t have to mutilate numbers into strings and we aren’t deploying worthless code into production. Well, at least you aren’t.

Starting with NPM instead of Node

You might have gotten this far and thought, “Burke, I never ever run node anything. It’s always an npm script like npm start”.

In this case you can still use VS Code Launch configs. Instead of using a standard Node Launch process, you add a config that is a “Launch Via NPM” task.

Now you can add back in your envFile line and tweak the runtimeArgs so that they launch the correct script. This is usually something like “start” or “debug”.

Note that you have to add the --inspect flag to your npm script so that VS Code can attach the debugger. Otherwise the task will launch, but the VS Code debugger will time out like me trying to get a date in high school.

Production environment variables

So far we’ve looked at how to define variables for development. You likely won’t use .env files in production, and VS Code Launch Configurations aren’t going to be super helpful on a server.

In production, variables will be defined however your platform of choice allows you to do so. In the case of Azure, there are 3 different ways to define and manage environment variables.

The first way is to use the Azure CLI.

az webapp config appsettings set -g MyResourceGroup -n MyApp --settings PORT=65534

Which works, but, ew.

Another way is via the Azure web portal. I don’t always use a web portal, but when I do, it’s to set environment variables.

In the case of Azure, these are called “Application Settings”.

And since you are using VS Code, you can install the App Service extension and manage all the App Settings right from the editor.

I love not having to leave VS Code to do anything. I would write emails in VS Code if I could.

WAIT A MINUTE!

markdown-mail - Visual Studio Marketplace

Extension for Visual Studio Code - Using markdown to write your email and send!

marketplace.visualstudio.com

Now you know

これで、私が知っていること(多くはありませんが、教えてください)がわかり、途中で上品な量のJavaジョークという目標を達成したように感じます。念のため、これを残しておきます。

Javaは、XMLをスタックトレースに変換するための非常に強力なツールです。

- わからない

風刺の免責事項:これのほとんどはユーモアの貧弱な試みであり、Javaを犠牲にしてその一部があります。これは良くありませんが、とても簡単です。これらのジョークは自分自身を書きません。