<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>

CC BY-SA 3.0
2018-04-10T14:39:46.613Z
Do the developers in your company docker themselves? In what way has DTAP been implemented in terms of using docker in every phase?
030
CC BY-SA 3.0
2018-04-10T19:34:01.650Z
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.
petrchpetr
CC BY-SA 3.0
2018-04-10T12:39:42.407Z
2018-04-10T12:39:42.407Z
petrchpetr
<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>

CC BY-SA 3.0
2018-03-15T07:00:47.983Z
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?
Ta Mu
<architecture><images>
What are Design Patterns for creating images?
030
# 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.  

---

