Closed iamike closed 6 years ago
sorry, I am a little bit confused here. looks there are 3 ways: 1) .env file can handle the cms environment variables, eg. we just make 2 .env files, one for dev environment, and another is for live environment. by using different docker-compose-dev, docker-compose-prod, to mirror the different file into the volume..
2) The docker-compose also provide the environment variables. which can be just defined in env_files setting config.
3) in some cloud service, there might be kubernetes which also provide the environment variables for the services. That mean we just take care of local dev env variables?
so, OMG, which way is the best approach?
When using the image's docker
config, if the APP_KEY
is not defined in your .env, it will fall back to the generic key set in config/docker/app.php. This is to facilitate a quick testing environment for developers without forcing them to configure settings.
More about the App Environment
I typically maintain a separate docker-compose for each environment (local, stage, prod) within the project repo. I store secrets in .env
that's not committed. Keep in mind, docker-compose supports .env variables as well.
In practice, the best approach really depends on the project and to an extent, your preference.
If you're planning to deploy via swarm or kubernetes, it's a good idea to extend the image so you're not dependent on volume mounts which may include baking in your own config.
can i can the default APP_KEY? Am I need put APP_KEY in .env file? if everybody using the default APP_KEY, is that will be a problem for security? Thanks