Answers: <p>The general design pattern is one container = one running service - see the initial comment at <a href="https://docs.docker.com/config/containers/multi-service_container/" rel="nofollow noreferrer">https://docs.docker.com/config/containers/multi-service_container/</a></p>
  
  <p>Now, after spending about a year developing a multi-service application relying heavily on docker this is what works for me:</p>
  
  <p>Avoid creating files inside the container unless it is your storage engine - in which case use volumes (recommended by Docker and also common sense) - we use Elasticsearch for that. </p>
  
  <p>If I need multiple custom configurations I am trying to either load it from somewhere (DB, Environment) or I mount the configuration as a volume like </p>
  
  <pre><code>-v config.yml:/usr/src/app/config.yml
  </code></pre>
  
  <p>In general, we have one service = one repository, but sometimes you have to copy all the dependencies in order to just create one script. So we have one repository where these scripts are aggregated and I change the CMD with an environment variable like this:</p>
  
  <pre><code>CMD cd /usr/src/app &amp;&amp; python -u $RUN_SCRIPT
  </code></pre>
  
  <p>It can be probably improved with a combination of ENTRYPOINT and CMD as described here <a href="http://goinbigdata.com/docker-run-vs-cmd-vs-entrypoint/" rel="nofollow noreferrer">http://goinbigdata.com/docker-run-vs-cmd-vs-entrypoint/</a></p>
  
  <p>Then we use various <code>docker-compose.yml</code> files for getting the setup we need. </p>
  
  <p>For some operations (like DB setup) we either run one container like </p>
  
  <pre><code>docker run --network ournetwork init-profiling
  </code></pre>
  
  <p>or I can run a command inside that container</p>
  
  <pre><code>docker run -it --network ournetwork init-profiling bash
  # run_command.sh
  ^D
  </code></pre>
  
  <p>We spent some time minimizing the footprint of containers, they can quickly get bloated. For example, we use a common base image for our python containers. Also, things like <code>pip freeze</code> do make sense only if you use a separate virtual environment for each repository/container.</p>
  
  <p>We do not use swarm/kubernetes for now, so I cannot add any additional guidelines for that. </p>
  
Answers: CC BY-SA 3.0
Answers: 2018-04-10T14:39:46.613Z
Answers: Do the developers in your company docker themselves? In what way has DTAP been implemented in terms of using docker in every phase?
Answers: 030
Answers: CC BY-SA 3.0
Answers: 2018-04-10T19:34:01.650Z
Answers: We have now a stable set of services so after creating the new repository the developers usually do git commit + Jenkins for building and putting the containers into AWS ECS repository (dev/stage/prod branches and environments). The new deployment is mostly checkout docker-compose, docker-compose pull and docker-compose up. It's not perfect, but it works. It's a little bit more complex than this, but this is the core.
Answers: petrchpetr
Answers: CC BY-SA 3.0
Answers: 2018-04-10T12:39:42.407Z
Answers: 2018-04-10T12:39:42.407Z
Answers: petrchpetr
Body: <p>In Object Oriented Programming (OOP) there are Design Patterns (DP). DP are best practices for tackling certain problems. For example, <a href="https://en.wikipedia.org/wiki/Singleton_pattern" rel="noreferrer">a singleton</a> is acceptable to be used <a href="https://stackoverflow.com/a/228380/2777965">in a logger class</a>.</p>
  
  <p>What about applying DPs to creation of images, e.g. docker. In our situation we have the core, i.e. the application, application configuration (customization per customer), and different artifacts per customer.</p>
  
  <p>At the moment, a bash script is used that contains various if-else statements and it is getting more and more a spaghetti.</p>
  
Comments: CC BY-SA 3.0
Comments: 2018-03-15T07:00:47.983Z
Comments: this is quite interesting and challenging question: would you share a couple of (pseudocode-formatted) if-else passages to make it more clear? that is, that seems that design patterns is a high level consideration, yet current problem is spaghetti bash code. What functional blocks are there to abstract from?
Comments: Ta Mu
Tags: <architecture><images>
Title: What are Design Patterns for creating images?
UserDisplayName: 030
ThreadText: # What are Design Patterns for creating images?
  
  (Asked by: username_0 on 2018-03-01)
  
  In Object Oriented Programming (OOP) there are Design Patterns (DP). DP are best practices for tackling certain problems. For example, [a singleton](https://en.wikipedia.org/wiki/Singleton_pattern) is acceptable to be used [in a logger class](https://stackoverflow.com/a/228380/2777965).
  
  What about applying DPs to creation of images, e.g. docker. In our situation we have the core, i.e. the application, application configuration (customization per customer), and different artifacts per customer.
  
  At the moment, a bash script is used that contains various if-else statements and it is getting more and more a spaghetti.
  
  **Tags:** architecture, images
  
  > **Comments:**
  > **username_1**: this is quite interesting and challenging question: would you share a couple of (pseudocode-formatted) if-else passages to make it more clear? that is, that seems that design patterns is a high level consideration, yet current problem is spaghetti bash code. What functional blocks are there to abstract from?  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2018-04-10. Score: 3 | Accepted answer
  
  The general design pattern is one container = one running service - see the initial comment at <https://docs.docker.com/config/containers/multi-service_container/>
  
  Now, after spending about a year developing a multi-service application relying heavily on docker this is what works for me:
  
  Avoid creating files inside the container unless it is your storage engine - in which case use volumes (recommended by Docker and also common sense) - we use Elasticsearch for that.
  
  If I need multiple custom configurations I am trying to either load it from somewhere (DB, Environment) or I mount the configuration as a volume like
  
  ```
  -v config.yml:/usr/src/app/config.yml
  
  ```
  
  In general, we have one service = one repository, but sometimes you have to copy all the dependencies in order to just create one script. So we have one repository where these scripts are aggregated and I change the CMD with an environment variable like this:
  
  ```
  CMD cd /usr/src/app && python -u $RUN_SCRIPT
  
  ```
  
  It can be probably improved with a combination of ENTRYPOINT and CMD as described here <http://goinbigdata.com/docker-run-vs-cmd-vs-entrypoint/>
  
  Then we use various `docker-compose.yml` files for getting the setup we need.
  
  For some operations (like DB setup) we either run one container like
  
  ```
  docker run --network ournetwork init-profiling
  
  ```
  
  or I can run a command inside that container
  
  ```
  docker run -it --network ournetwork init-profiling bash
  # run_command.sh
  ^D
  
  ```
  
  We spent some time minimizing the footprint of containers, they can quickly get bloated. For example, we use a common base image for our python containers. Also, things like `pip freeze` do make sense only if you use a separate virtual environment for each repository/container.
  
  We do not use swarm/kubernetes for now, so I cannot add any additional guidelines for that.
  
  > **Comments:**
  > **username_0**: Do the developers in your company docker themselves? In what way has DTAP been implemented in terms of using docker in every phase?  
  > **username_2**: We have now a stable set of services so after creating the new repository the developers usually do git commit + Jenkins for building and putting the containers into AWS ECS repository (dev/stage/prod branches and environments). The new deployment is mostly checkout docker-compose, docker-compose pull and docker-compose up. It's not perfect, but it works. It's a little bit more complex than this, but this is the core.  
  
  ---
  
  