What are Design Patterns for creating images?

In Object Oriented Programming (OOP) there are Design Patterns (DP). DP are best practices for tackling certain problems. For example, a singleton is acceptable to be used in a logger class.

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.

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.

StackExchange DevOps Q#3510, answer score: 3