Answers: <p><strong>docker-compose.override.yml, docker-compose.prod.yml and <code>extend</code></strong></p>
  
  <p>An outline answer would be to have a <code>docker-compose.yml</code> file for your common base configuration, a <code>docker-compose.prod.yml</code> for production-specific sets of containers and for other specific environments, <code>docker-compose.override.yml</code>. It is possible to use the docker-compose <code>extend</code> keyword/command/statement in a docker compose yml file to inherit from another docker compose yml file.</p>
  
  <p>The above approach is on the basis that one would first consider only the things common across all environments as the pure, base setup and then dev and prod environments would be based off of this (inherited). </p>
  
  <p>Your dev-specific packer setup could be configured in the <code>docker-compose.override.yml</code> file, which inherits from the base <code>docker-compose.yml</code>. Configuration that is common across all environments would reside in <code>docker-compose.yml</code>. Your production setup could be in <code>docker-compose.prod.yml</code>, which again can inherit from the base <code>docker-compose.yml</code>.</p>
  
  <p><strong>References</strong></p>
  
  <p>This seems to be the best practice approach, based on the following references:</p>
  
  <ul>
  <li><p>The inheritance/nesting approach is explored here: <a href="https://stackoverflow.com/questions/33408118/inheritance-or-nesting-with-docker-compose">Inheritance or
  nesting with docker compose</a></p></li>
  <li><p>The official documentation here - <a href="https://docs.docker.com/compose/extends/" rel="nofollow noreferrer">Share Compose configurations
  between files and projects</a> - describes the docker compose
  <code>extend</code> keyword.</p></li>
  </ul>
  
  <p><strong>Some things you may or may not need to consider for your specific case</strong></p>
  
  <ul>
  <li><p>There may or may not be some bespoke config code required in
  <em>addition</em> i.e. in your deployment itself, e.g. bash scripts etc., should the above approach provide most of what you need but not quite everything. These scripts can be run from docker compose.</p></li>
  <li><p>Research what can be overridden when writing <code>docker-compose.override.yml</code>
  when "inheriting" from <code>docker-compose.yml</code>. Your particular project may require a configuration in each of the dev and prod environments that override the same thing in the base environment, thus the need to override what is in the "parent"/base docker-compose.yml environment. Consider this issue: <a href="https://github.com/docker/compose/issues/3729" rel="nofollow noreferrer">https://github.com/docker/compose/issues/3729</a> - which suggests there are limitations as to what can be overridden, particularly if you want to move a configuration item that was present in the parent <code>docker-compose.yml</code>. A better way could be to only have items common across all environments in <code>docker-compose.yml</code> and have the specifics in files for specific enviroments, such as <code>docker-compose.prod.yml</code></p></li>
  </ul>
  
Answers: CC BY-SA 4.0
Answers: 2018-06-24T19:47:31.520Z
Answers: 2018-06-28T08:13:24.430Z
Answers: 2018-06-28T08:13:24.430Z
Answers: therobyouknow
Body: <p>I'm creating a webapp with a python backend, Nginx as the server, and Vue as my frontend web framework.  When deploying to production, I build an nginx container that, on build, compiles all my frontend code into minified static files it can serve (takes ~2minutes), and on run, serves those static files and routes non-static-file HTTP requests to a different API Container (running the python app).  (So two containers: nginx, and api server).</p>
  
  <p>The problem I'm facing is that during development, I want to use a third container to run a hot-reloading webpack-dev-server for the frontend files, instead of having to wait two whole minutes for webpack to rebuild the frontend bundle every time I make a change. For reference, building the frontend code into servable static files takes around two minutes, whereas the webpack-dev-server can reflect changes in &lt;3 seconds)</p>
  
  <p>My idea is to have a production nginx config that handles the production case of serving static content directly from the nginx container, and a dev nginx config that handles the dev case of routing those static requests to the webpack-dev-server container.  But having different docker-compose files for different environments seems to go against docker philosophy.  Am I approaching this incorrectly?</p>
  
Tags: <docker><docker-compose>
Title: Using docker-compose, what's the recommended way to handle different sets of containers for dev and prod?
UserDisplayName: Christopher Shroba
ThreadText: # Using docker-compose, what's the recommended way to handle different sets of containers for dev and prod?
  
  (Asked by: username_0 on 2018-06-24)
  
  I'm creating a webapp with a python backend, Nginx as the server, and Vue as my frontend web framework. When deploying to production, I build an nginx container that, on build, compiles all my frontend code into minified static files it can serve (takes ~2minutes), and on run, serves those static files and routes non-static-file HTTP requests to a different API Container (running the python app). (So two containers: nginx, and api server).
  
  The problem I'm facing is that during development, I want to use a third container to run a hot-reloading webpack-dev-server for the frontend files, instead of having to wait two whole minutes for webpack to rebuild the frontend bundle every time I make a change. For reference, building the frontend code into servable static files takes around two minutes, whereas the webpack-dev-server can reflect changes in <3 seconds)
  
  My idea is to have a production nginx config that handles the production case of serving static content directly from the nginx container, and a dev nginx config that handles the dev case of routing those static requests to the webpack-dev-server container. But having different docker-compose files for different environments seems to go against docker philosophy. Am I approaching this incorrectly?
  
  **Tags:** docker, docker-compose
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2018-06-24. Score: 4
  
  **docker-compose.override.yml, docker-compose.prod.yml and `extend`**
  
  An outline answer would be to have a `docker-compose.yml` file for your common base configuration, a `docker-compose.prod.yml` for production-specific sets of containers and for other specific environments, `docker-compose.override.yml`. It is possible to use the docker-compose `extend` keyword/command/statement in a docker compose yml file to inherit from another docker compose yml file.
  
  The above approach is on the basis that one would first consider only the things common across all environments as the pure, base setup and then dev and prod environments would be based off of this (inherited).
  
  Your dev-specific packer setup could be configured in the `docker-compose.override.yml` file, which inherits from the base `docker-compose.yml`. Configuration that is common across all environments would reside in `docker-compose.yml`. Your production setup could be in `docker-compose.prod.yml`, which again can inherit from the base `docker-compose.yml`.
  
  **References**
  
  This seems to be the best practice approach, based on the following references:
  
  * The inheritance/nesting approach is explored here: [Inheritance or
    nesting with docker compose](https://stackoverflow.com/questions/33408118/inheritance-or-nesting-with-docker-compose)
  * The official documentation here - [Share Compose configurations
    between files and projects](https://docs.docker.com/compose/extends/) - describes the docker compose
    `extend` keyword.
  
  **Some things you may or may not need to consider for your specific case**
  
  * There may or may not be some bespoke config code required in
    *addition* i.e. in your deployment itself, e.g. bash scripts etc., should the above approach provide most of what you need but not quite everything. These scripts can be run from docker compose.
  * Research what can be overridden when writing `docker-compose.override.yml`
    when "inheriting" from `docker-compose.yml`. Your particular project may require a configuration in each of the dev and prod environments that override the same thing in the base environment, thus the need to override what is in the "parent"/base docker-compose.yml environment. Consider this issue: <https://github.com/docker/compose/issues/3729> - which suggests there are limitations as to what can be overridden, particularly if you want to move a configuration item that was present in the parent `docker-compose.yml`. A better way could be to only have items common across all environments in `docker-compose.yml` and have the specifics in files for specific enviroments, such as `docker-compose.prod.yml`
  
  
  ---
  
  