There are a lot of posts talking about containers: how to use them, how they are implemented and so on. But nothing about the high level ideas they should follow. So, let's talk about containers philosophy. I was not able to find a good post explaining the basic rules of containers so, let's try to describe them:
- A container is ephemeral: A request to the container engine to run a container will produce a running instance of an image. It is however, not guaranteed the image will run on the same container in perpetuity. For example, if using a container orchestrator, requests may be made to execute many replicas of the same container image. If a container is stopped (because there was a crash, an error...), the orchestrator can start a new one.
- Persistent storage should be managed in volumes, not within containers: this is related to the previous one. If a container is ephemeral, shared persistent storage from that container should be avoided. Mount a volume to keep data when a container is created again.
- A container should have only one mission: An advantage to using containers is the ability to subdivide the functions of a system into smaller collaborating pieces. This is how Docker may be used to achieve a microservice architecture. Microservices offer benefits in terms of scalability and maintenance.
- A container should minimize application dependencies: This will reduce the resource obligations required of the host by the container and possible interactions between libraries, configurations...
- A container should be treated like an executable: It should maintain its own minimal dependency set so when run, there exists no necessity for the user or administrator to maintain. The container should function as required as a “black box” within the system; which reduces administrative overhead and dependency mismatch.
Some of those rules remind me to the SOLID principles, don't you?
Top comments (0)