The Eternal Sunshine of the Spotless Data Centre
Containers are, broadly speaking, a codified way of ensuring that your IT people never get too attached to their servers. The idea is to use lots of identical containers built off the one master template (the image) so that if any one of them dies (or is killed) you don’t miss it much, and it’s easy to replace with another identical container built from the master image. They’re smaller and lighter than virtual machines, but their most important feature is:
They don’t remember anything.
You can alter a container’s state at runtime if you want to – changing configuration or setting up some local data of some kind – but when the container is destroyed all the data is destroyed with it.
This is an important point: it’s when, not if, because the defining characteristic of a container is that it’s relatively short lived, and is destroyed utterly on a regular basis, to be replaced by a shiny new version, un-tainted by any memories of its former self.
That’s actually great compared to other methods of doing software development. If you’ve ever endured the lengthy enterprise processes of the Software Development Life Cycle (Dev/Test/QA, then Change Advisory Board, then scheduling, then GoLive and then scrambling to fix all the issues) you’ll appreciate the pain I refer to.
This lack of state enforces discipline on the people responsible for writing your [entity display=”business” type=”channel” active=”true” activated=”false” deactivated=”true” key=”business” natural_id=”channel_1″]business[/entity] software. If everything is built fresh each time, there’s no advantage to quickly changing the configuration settings “just this once” in order to get the build running, or to fix a production problem. That fix will be quickly lost when the container is rebuilt. You can avoid having your Test environment set up differently to QA or Production, and avoid the cries of “Well, it worked in Test” as the reason Internet banking is down today.
Instead, everyone is forced up update the master configuration (dare we call it a CMDB?) with the Way Things Should Be, and then that image is deployed into all of the environment.Tags: container, docker, infrastructure, it