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.

jayhendren
  • 3,022
  • 8
  • 16
dwjohnston
  • 231
  • 3
  • 11

2 Answers2

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

gerritjvv
  • 11
  • 1
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.

Jiri Klouda
  • 5,867
  • 1
  • 22
  • 54