環境変数が読まれない：手元では動くのにサーバーで動かない

レン

手で実行すると動くのに、サービスとして起動すると設定が読まれてない…

プロクラ

定期実行のときと同じ話だよ。キミがログインしたときに読み込まれる設定は、サービスの起動時には読み込まれない。だから、環境変数が空のまま動くことになる。

どこで読み込まれるのか

• ログイン時: ユーザーの設定ファイルが読み込まれる
• サービス起動時: それらは読み込まれない
• 定期実行: これも読み込まれない
• つまり、手で試したときだけ環境が整っている

プロクラ

この違いを知らないと、「設定は書いたのに読まれない」という状況で延々と悩むことになる。原因は設定の中身ではなく、読み込まれる場所のほうなんだ。

確実に渡す方法

• サービスの定義ファイルに、直接記述する
• 環境変数をまとめたファイルを指定して読み込ませる
• アプリ側で、設定ファイルを明示的に読み込む
• 起動スクリプトの中で、先に読み込んでから実行する

プロクラ

2つめが扱いやすいよ。設定を1つのファイルにまとめておけば、手で実行するときも、サービスから起動するときも、同じファイルを使える。食い違いが起きにくい。

確認する

プロクラ

読まれているかどうかは、推測せずに確かめよう。実際に動いているプロセスの環境を、外から見ることができる。

• 起動しているプロセスの環境変数を確認する
• アプリの起動時に、読み込んだ設定を記録する（値そのものは出さない）
• 設定が空のときは、起動時に分かるようにする
• 「なぜか動かない」より「設定が無い」と出るほうが親切

認証情報の扱い

ウィルスン

…その環境変数の中身、動いているプロセスから読めるのだったな。同じサーバーに入り込めた者にとっては、探す手間が省ける話だ。

• 環境変数をまとめたファイルは、本人だけが読める権限にする
• バージョン管理に含めない
• ログに出力しない
• サービスの定義ファイルに直接書く場合、そのファイルの権限にも注意する

レン

ログイン時と起動時で環境が違う。まずそこを疑えばいいんだ。

手元と本番で値を変える

プロクラ

環境変数を使う本来の目的は、同じコードのまま設定だけを差し替えられることだよ。ここが揃っていれば、移行も検証環境の用意も楽になる。

• 接続先やキーは、コードに直接書かない
• 環境ごとに、値をまとめたファイルを用意する
• 見本となるファイルだけをバージョン管理に含める（値は空にする）
• 新しい環境を作るとき、その見本を写して埋めれば済む

プロクラ

3つめは実用的だよ。何を設定する必要があるかが一覧になっているので、設定漏れに気づける。値そのものは含めないので、公開しても安全だ。