3 ms·

I like to divide up my compose files into three: 1. A `docker-compose.yaml` for basic configuration common among all environments 2. A `docker-compose.dev.yam

I like to divide up my compose files into three: 1. A `docker-compose.yaml` for basic configuration common among all environments 2. A `docker-compose.dev.yaml` for configuration overrides specific to development 3. A `docker-compose.prod.yaml` for configuration overrides specific to production Then I have `COMPOSE_FILE=docker-compose.yaml:docker-compose.dev.yaml` in my `.env` file in the root of the project so I can just run `docker compose up` in dev, and `COMPOSE_FILE=docker-compose.yaml:docker-compose.prod.yaml` in a `prod.env` file so I can run `docker compose --env-file=prod.env up` in production. Sometimes also a `staging.env` file which is identical to `prod.env` but with a few different environment variables. It's been working pretty well for me so far.

xorcist 4y ago
In my experience, the "base" configuration should always be in use somewhere. Otherwise you inevitably end up with cruft, when default values turns out to have no practical value. In your example, "dev" should probably be the default configuration, which "prod" overrides. It's a tiny detail but I think it pays over time. A similar situation is when you have lots of almost-identical settings between many (micro)services.
- lazide 4y ago
  100% agree - I find staging useful here. It’s the default ‘non-production’, and has realistic data shared in a way that anyone in dev can access it. Think ‘sacrificial prod with no actual real customers hitting it right now’. Depending on data sensitivity requirements, it might have a subset of real data, or no real data. Having prod be the default is a problem, as it’s inevitable someone will accidentally break production/write junk to it when they didn’t realize they were talking to prod. Having dev in it inevitably results in broken prod pushes because no one has ever tried it outside of a synthetic dev environment.
- heliodor 4y ago
  Sometimes dev and prod go in different directions so it makes more sense to inherit a common file. For example, dev might have a whole bunch of settings for some debug tool whereas prod might have a whole bunch of settings for the email server config.
  - xorcist 4y ago
    That could be something like "debuger = 0" in the prod config. It's preferable to configuration drift.
    - heliodor 4y ago
      I'm not talking about a simple debug=true/false. I'm talking about debug=true followed by various debugger settings. I don't want to see ten or twenty debugger settings in my prod config. Similarly, in dev, you can set the email config to output to a file and be done with it. I don't want to see all the email server settings in my dev config: the host, the port, the username, the password, the protocol, etc.

xorcist 4y ago

In my experience, the "base" configuration should always be in use somewhere. Otherwise you inevitably end up with cruft, when default values turns out to have no practical value. In your example, "dev" should probably be the default configuration, which "prod" overrides. It's a tiny detail but I think it pays over time. A similar situation is when you have lots of almost-identical settings between many (micro)services.

lazide 4y ago
100% agree - I find staging useful here. It’s the default ‘non-production’, and has realistic data shared in a way that anyone in dev can access it. Think ‘sacrificial prod with no actual real customers hitting it right now’. Depending on data sensitivity requirements, it might have a subset of real data, or no real data. Having prod be the default is a problem, as it’s inevitable someone will accidentally break production/write junk to it when they didn’t realize they were talking to prod. Having dev in it inevitably results in broken prod pushes because no one has ever tried it outside of a synthetic dev environment.
heliodor 4y ago
Sometimes dev and prod go in different directions so it makes more sense to inherit a common file. For example, dev might have a whole bunch of settings for some debug tool whereas prod might have a whole bunch of settings for the email server config.
- xorcist 4y ago
  That could be something like "debuger = 0" in the prod config. It's preferable to configuration drift.
  - heliodor 4y ago
    I'm not talking about a simple debug=true/false. I'm talking about debug=true followed by various debugger settings. I don't want to see ten or twenty debugger settings in my prod config. Similarly, in dev, you can set the email config to output to a file and be done with it. I don't want to see all the email server settings in my dev config: the host, the port, the username, the password, the protocol, etc.