The context is that I'm looking at doing staging/testing and production on a kubernetes cluster.

Where I might have some code that looks like this:

doSomething({
  username: process.env.DB_USERNAME,
  password: process.env.DB_PASSWORD
})

For my various kubernetes environments, this isn't going to be a problem, as those environment variables can be set specifically for the environment.

However, for my development environment, there's a good chance that I'm going to have multiple projects, (or even different images for the same project) that all have a environment variable named DB_URL.

One solution would be to just prefix all environment variables with MY_APPLICATION_NAME_.

Another would be not permanently set environment variables, but instead to just call a script that sets them when needed. But that sounds a little messy.

I'm wondering if there's a well established way that deals with this problem.

bumped to the homepage by Community 2 days ago

This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.

Not sure if this is the first, but it surely won't be the last time. Having a script that starts a new shell (new container, new VM) with environment setup for the development of the project you will be working on next is something you will definitely need in the future. If there are multiple people collaborating, it is even more important. If you get into the habit of using it now, future changes will be easier.

The reason why you set it in new shell (container/VM) is that you can easily exit to unset the environment and enter a new one for a different project and because you might need to set a different user or group memberships for the project.

  • I don't typically run my development environment in a container - it just runs on my machine. Wouldn't file watching be problematic running on a container? – dwjohnston Oct 15 at 23:33
  • That was an alternative. In the most basic way you use a script with one argument being the project name and it knows where to get the settings, then it starts a new sub-shell where it sets the correct groups (if needed) and environment for that project. Once you are done working on it, you simply type 'exit' and you are back to your vanilla environment and can execute it with another project name. – Jiri Klouda Oct 16 at 0:24
  • If you use one repo per project, then you should always have a script of the same name in the root of the repo, like setup_env.sh then put all your repos in standard location and write a wrapper script that will cd to $HOME/co/$PROJECT_NAME and source (or exec) $HOME/co/$PROJECT_NAME/setup_env.sh – Jiri Klouda Oct 16 at 0:28

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.