Clever Geek Handbook

process.envの効果的な使用

Node.jsを学習し始めたばかりの場合は、おそらくapp.listen(process.env.PORT)



ようなコード行に出くわしているでしょう。 ポート番号を指定するだけで同じ効果が得られるのに、コードエディターに16文字を入力するのはなぜですか（例：3000）。 調べることをお勧めします。







process.envとは何ですか？



グローバル変数process.env



は、内部Nodeメカニズムにより、実行時にアプリケーションで使用できます。 これは、アプリケーションの起動時のシステム環境の状態を表します。 たとえば、 PATH



変数がPATH



で設定されてPATH



場合、 process.env.PATH



構成を使用しprocess.env.PATH



アプリケーションからアクセスできます。 たとえば、コードからアクセスする必要がある実行可能ファイルを見つけることができる場所を見つける必要がある場合に使用できます。



アプリケーションが実行される環境の重要性



アプリケーションがデプロイされるまで、単純なサイトを実装するコードであろうと、重いコンピューティングで使用される複雑なAPIであろうと、それはまったく役に立ちません。 これらは、ファイルに保存されているテキストの単なる行です。



プログラムを作成するとき、開発者はどこで作業するかを正確に知りません。 たとえば、開発プロセス中にデータベースが必要な場合、データベースのインスタンスをローカルで実行し、次のような接続文字列を使用して接続します： 127.0.0.1:3306



ただし、アプリケーションの作業インスタンスをデプロイする場合、たとえば54.32.1.0:3306



で利用可能なリモートサーバーにあるDBMSに接続する必要がある場合があります。



環境変数を使用しないと仮定すると、2つのオプションがあります。



1つ目は、アプリケーションが実行されているのと同じマシンでデータベースの可用性を確保することです。これにより、アドレス127.0.0.1:3306



で接続できます。 このようなアプローチは、単一のDBMSインスタンスに応じて1つのアプリケーションインスタンスのみをデプロイできるため、インフラストラクチャへのアプリケーションの強力なバインド、その潜在的な低可用性、およびスケーリングの不能を意味します。



2番目のオプションでは、コードを変更して、実行中に、いくつかのelse



ブランチを含む条件ステートメントを使用して、適切なデータベース接続文字列を選択できるようにします。 



 let connectionString; if (runningLocally()) { connectionString = 'dev_user:dev_password@127.0.0.1:3306/schema'; } else if (...) { ... } else if (inProduction()) { connectionString = 'prd_user:prd_password@54.32.1.0:3306/schema'; } const connection = new Connection(connectionString);


このような構造は、プログラム実行パスの数を増やし、テストを複雑にします。コードの美しさについて話す必要はありません。



環境変数を使用してデータベースへの接続文字列を示す場合、問題は次のように解決できます。 



 const connection = new Connection(process.env.DB_CONNECTION_STRING);


このアプローチを使用すると、開発中にローカルDBMSインスタンスに接続するか、ロードバランシングをサポートし、アプリケーションとは無関係にスケーリングできる安全なリモートデータベースクラスターなどの接続を整理できます。 これにより、たとえば、特定のDBMSインスタンスに依存しない多くのアプリケーションインスタンスを持つことが可能になります。



一般に、特定の外部サービスに対するアプリケーションの依存関係を常に接続リソースと見なし、環境変数を使用してそれらへの接続を構成することをお勧めします。



環境変数の使用方法



アプリケーションの環境変数を準備するために実行される手順は、プロビジョニングまたはプロビジョニングと呼ばれます。 サーバーを準備するとき、環境変数を操作できる2つのレベルがあります。インフラストラクチャレベルとアプリケーションレベルです。 特別なツールを使用するか、アプリケーションレベルで実装されたロジックを使用して、環境を準備できます。



アプリケーションレベルで動作するツールの中で、 dotenv



パッケージについて言及できます。これにより、 .env



ファイルから環境変数をロードできます。 このツールは次のようにインストールできます。 



 npm install dotenv --save


環境変数は、次の簡単なコマンドを使用してロードされます。 



 require('dotenv').config();


このアプローチは開発プロセス中は便利ですが、 .gitignore



.env



推奨されません。したがって、特に.gitignore



ファイルを.gitignore



に追加することをお.gitignore



ます。



インフラストラクチャレベルでは、ツールを使用して、PM2、Docker Compose、Kubernetesなどのアプリケーションの展開を制御し、環境をセットアップできます。

PM2はecosystem.yaml



ファイルを使用します。このファイルでは、 env



プロパティを使用して環境変数を設定できます。 



 apps: - script: ./app.js   name: 'my_application'   env:     NODE_ENV: development   env_production:     NODE_ENV: production   ...


同様に、Docker Composeでは、サービスマニフェストファイルでenvironment



プロパティを設定できます。 



 version: "3" services: my_application:   image: node:8.9.4-alpine   environment:     NODE_ENV: production     ...   ...


Kubernetesのマニフェストテンプレートには同様のenv



プロパティがあり、環境変数を設定することもできます。 



 kind: Deployment apiVersion: extensions/v1beta1 metadata: name: my_application spec: ... template:   spec:     env:       - name: NODE_ENV         value: production       ...


環境変数を使用するシナリオ



▍アプリケーション設定



アプリケーション設定は、このアプリケーションが実行するアクションに正確には影響せず、そのロジックには影響しません。 たとえば、アプリケーションは、外部からアクセスできるようにポートでリッスンする必要があることを知っていますが、どのポートになるかを知る必要はありません。 このようなデータは、環境変数に入れるのに非常に適しています。 したがって、ネットワークインフラストラクチャのインストールと準備は、アプリケーション展開ツールで信頼できます。



external外部サービスとの相互作用



環境変数は、アプリケーションが依存するサービスに接続する方法を示すためによく使用されます。 これにより、コードをきれいにし、アプリケーションのテスト容易性を改善できます。 特に、このアプローチを使用すると、テスト環境から条件付きデータをアプリケーションに送信できます。これにより、たとえば、緊急事態をシミュレートし、そのような状況でアプリケーションの障害をチェックできます。 ここでは、同様の状況を扱っています。アプリケーションには特定のサービスが必要ですが、正確にどこにあるのかは事前にはわかりません。 このような場合の環境変数の設定は、デプロイメントマネージャーに任せることができます。



▍開発援助



ローカル開発では、通常、実行中のアプリケーションから情報をすばやく取得したり、エラーを特定したりできるソフトウェアツールがあると便利です。 このようなツールの例としては、Webページに関連するアプリケーションコードを変更した後、Webページをインタラクティブにリロードすることがあります。 そのような振る舞いは、条件付き構造を使用して実装でき、その決定は、 process.env.NODE_ENV



などの標準環境変数に基づいprocess.env.NODE_ENV



、またはprocess.env.HOT_RELOADING_ENABLED



ような開発者自身が作成した特殊変数に基づいて行われprocess.env.HOT_RELOADING_ENABLED



。



アンチパターン



以下は、環境変数の一般的な誤用です。



  1. NODE_ENV



    過度の使用。 process.env.NODE_ENV



    使用に関する推奨事項process.env.NODE_ENV



    多くのチュートリアルで見つけることができますが、これに関する特定の詳細は見つかりません。 その結果、条件文でNODE_ENV



    を不当に使用することになり、環境変数の目的と矛盾します。

  2. 時間依存情報の保存。 アプリケーションが同じサーバーにデプロイされた別のアプリケーションと対話するためにSSL証明書または定期的に変更するパスワードを必要とする場合、環境変数の形式でこのデータを設定するのは不合理です。 アプリケーションが受信した環境情報は、起動時の環境の状態を表し、操作中は変更されません。

  3. タイムゾーンの設定。 Leon Bambrickは2010年に次のように述べています。「コンピューターサイエンスには、キャッシュの無効化、エンティティの命名、エラーのバイアスの1つの複雑なタスクがあります。 ここでもう1つ追加します。タイムゾーンを操作します。 アクセスしやすい環境にアプリケーションをデプロイすると、そのインスタンスを異なるタイムゾーンで実行できます。 1つのコピーはサンフランシスコにあるデータセンターで、もう1つのコピーはシンガポールにあります。 そして、ユーザーはロンドンからこのすべてに接続しています。 サーバーロジックでは、UTCを使用し、アプリケーションのクライアント部分を残してタイムゾーンを処理することをお勧めします。



まとめ



process.env



からのデータを適切に使用すると、テスト、デプロイ、およびスケーリングがより簡単で便利なアプリケーションの開発につながります。 環境変数はそれらの小さなものの1つであり、ほとんど認識できない場合が多く、コードを改善するための正しい作業であり、間違った環境変数は最も予期しない瞬間に現れる傾向があるトラブルにつながる可能性があります。 環境変数に関するストーリーが、プログラムの品質向上に役立つことを願っています。



親愛なる読者！ Node.jsプロジェクトでprocess.env



を使用しprocess.env



いますか？


More articles:


All Articles