ENV ファイル
構成ファイルを使用することもできますが、ホスティングの世界では、アプリケーションを構成する 12 Factor App 方法が非常に採用されています. CI/CD、Heroku、Kubernetes などの環境では、これは非常に理にかなっています.
ただし、開発中は、これを使用するのは非常に厄介です.
例: バックエンド API
You've written a beautiful monolith, but it needs a couple of things to run properly. It uses a private key to sign auth tokens, and it uses AWS credentials for uploads to S3.
You decide to use ENV variables and decide on AUTH_KEY
and AWS_ACCESS_KEY_ID
and AWS_SECRET_ACCESS_KEY
. Then you set up your hosting, and configure your app to abort if any of those are missing.
In development though, instead of running npm run dev
, you now need to run AUTH_KEY=xxx AWS_ACCESS_KEY_ID=xxx AWS_SECRET_ACCESS_KEY=xxx npm run dev
.
This is rather annoying, and might prompt you to write a blog post about ENV variables...
.env ファイルの作成
Instead of defining the ENV variables every time, we can create a .env
file in our project workspace. It usually looks something like this.
# JWT encoding key
AUTH_KEY=youWillNeverGuessThisYouEvilHackers
# AWS Developer Access
AWS_ACCESS_KEY_ID=xxx
AWS_SECRET_ACCESS_KEY=xxx
You may be tempted to check this file into source control (e.g. Git) and store with your code. That would be a mistake. Especially if you decide at a later point to open-source your project. Then you'd also be giving everyone access to your AWS credentials. Even if you later delete the file from your repo.
Instead, add it to your .gitignore
file to make sure that it will never get accidentally pushed with your code.
.env
It may not be 100% secure, to store stuff like this on your developer laptop, but it's still better than storing secrets in your repository.
Pro tip: New developers on your projects may not know anything about ENV variables or your local
.env
file. So make sure you update your documentation, and provide useful error messages if those ENV variables are missing.
Never create .env
files for anything other than your development setup. It is very easy to accidentally expose secrets that way.
.env ファイルの読み取り
If we now run our backend, it will complain that our ENV variables are not set. We have to tell Node (or whatever) about those variables.
On Linux/Mac this is quite easy.
env-vars を MYCOMMAND に渡します
In this case npm run dev
will have access to any ENV variables in the file.
eval $(egrep -v '^#' .env | xargs) npm run dev
.env の変数をシェルにエクスポートします
It's also possible to "export" the variables to your current session. That way, any command you run afterwards from the same shell will inherit it.
export $(egrep -v '^#' .env | xargs)
npm run build
npm run dev
Node.js
It is also possible to read ENV files without doing shell-script dark arts.
dotenv
You can inject the ENV variables into your Node.js process like this.
npm install --save-dev dotenv
In your app.js
require('dotenv').config()
In my experience, this is a horrible way of reading the ENV file. Remember, that this is a convenience for development. Why are we adding it to production code?
dotenv、コードを汚染することなく
Add a file called env.js
to your project workspace.
const { execSync } = require("child_process");
// This reads the .env file into the environment
// and shares it with any child process
require("dotenv").config();
const [argnode, argcmd, ...argrest] = process.argv;
// Run whatever follows `node env.js` as a child process and inherit stdin/stdout/etc
execSync(argrest.join(" "), {
stdio: "inherit",
});
Then in your package.json. In my example, I'm loading .env
and then running the Remix dev-server.
{
"name": "your package"
"scripts": {
"dev": "node ./dev.js npm run dev:server",
"dev:server": "remix dev"
}
}
Reference
この問題について(ENV ファイル), 我々は、より多くの情報をここで見つけました https://dev.to/andrioid/env-files-3j8mテキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol