2

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.

Improve this question

2 Answers 2

Reset to default
1

check out https://direnv.net/ it sets environment variables based on the directory you are in.

other options are: 1.docker-compose 2.plain bash to set the variables. 3. bash source .env 4. use prefixes but you would still need to set the environment you are in via an environment variable, so back to options 1-3.

if you are going to store passwords or keys in the env variables locally that are sensitive i.e not a localhost db pass, use a secrets manager like https://pkhub.io/usecases/environments, or you could script up something with aws' secrets manager

Improve this answer
0

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.

Improve this answer
3
  • 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
    Commented Oct 15, 2018 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
    Commented Oct 16, 2018 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
    Commented Oct 16, 2018 at 0:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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