Use Docker images for stability, reproducibility, and scalability
A friend asked why they shouldn’t promote their test docker image to production. He mentioned that the test image contains some development tools that they use to investigate issues, and they typically build a separate image to production. I don’t think that this is the right approach, so I wrote this post.
Why do we use docker (or containerd) images? Because, among other things, we want:
1. Stability: It works on my machine... and on every other machine, in the exact same way.
We may run some unit tests on specialised images (e.g. with test dependencies), but we should run acceptance tests against production images. That's the only way to guarantee that the tests are representative of production. Many teams use a staging environment that is a replica of their production environment.
2. Reproducibility: It was working yesterday... so it's safe to roll back.
We want to be able to reproduce issues using the same code, dependencies, and configuration. We also want to be able to roll back to a previous version knowing that it will work in the same way that it did previously. We want to avoid surprises resulting from any changes to the environment because of newer deployments. In other words, we want an immutable infrastructure.
3. Scalability: It works on one machine... it should work on ten.
We want to be able to scale rapidly on demand. It would be useless if we needed 15 minutes to scale to bursts of 5 minutes. Therefore, we want to minimise the time it takes to scale our application.
Container-based cloud infrastructure relies on sharing multiple hot machines between applications, assuming that some applications will scale down at times when others need to scale up. Given an image that fully describes the application's environment, we can deploy it to any machine with available resources.
However, this process is not effortless. Images have to be stored somewhere. They have to be downloaded to every new machine. Storage and bandwidth cost money (and environmental costs as well). They are also limited resources: any apps running on the machine will have less bandwidth while an image is being downloaded. And when the container runs, it consumes memory.
The smaller the image is, the less storage and bandwidth it will cost, the less time it will take to be downloaded and decompressed, and thus the quicker it will be ready for use. Additionally, its file system will be easier to cache, and the container may consume less memory in total.
4. Security: The less you know... the sounder you sleep.
We want to minimise the surface area exposed to attack. Security issues are usually caused by exploiting a chain of vulnerabilities, often in unexpected ways. To minimise this possibility, we should remove anything that is not necessary for our application. That's why we remove development dependencies from production images.
One may ask about the need for development tools in test environments.
If we need some tools to investigate issues on staging, then we need them even more on production. That's because we can choose to investigate issues on staging in our own time, but we'll have to investigate production issues under the pressure of an incident.
We have to choose our tools carefully to avoid introducing security issues, so maximise the use of distributed logging, request tracing, and metric visualisation, and keep your staging and production images the same.
discoholicmusic
gummygunk
snowghoul
theartofmadeline
germansingergirl
baratheonpilled
titsay
dailybridgerton