Immutable Infrastructure
The principle of immutable infrastructure is fairly simple:
The idea of updates-in-place is avoided. Meaning that:
Key idea:
The focus of configuration management shifts to the management of base images. Fixes, changes, and updates are applied to the base image rather than to running systems. Each time you want a new update you modify the base instance and run it through an automated test harness. You only create new servers when they pass these steps.
Once you've spun up a server instance from a well-tested base image, you shouldn't run configuration management tools, since they create opportunities for untested changes to the instance. Any changes that are needed can be made to the base image, tested, and then rolled out. Servers without the change are torn down and replaced.
When implementing immutable servers you should consider what data needs to be persisted as servers are destroyed and created, and what data must be replicated in order to scale by adding additional servers.
You can ship data off of the instance when it has value but isn't needed at runtime, for example sending log files to a central server.
Local business data should be living on a SAN and cloud platforms generally offer mountable storage devices which can be attached to new servers instances when the old ones are destroyed, or quickly duplicated and attached to replicas when scaling a cluster.
Immutable components are replaced for every deployment
The idea of updates-in-place is avoided. Meaning that:
- No updates should ever be performed on live systems
- You always start from a new instance of the resource being provisioned
Key idea:
An Immutable Server is a server that once deployed, is never modified, merely replaced with a new updated instance.
Benefits of Immutable Infrastructure
By frequently destroying and rebuilding servers from the base image, 100% of the server's elements are reset to a known state, without spending a ridiculous amount of time specifying and maintaining detailed configuration specifications.The focus of configuration management shifts to the management of base images. Fixes, changes, and updates are applied to the base image rather than to running systems. Each time you want a new update you modify the base instance and run it through an automated test harness. You only create new servers when they pass these steps.
Once you've spun up a server instance from a well-tested base image, you shouldn't run configuration management tools, since they create opportunities for untested changes to the instance. Any changes that are needed can be made to the base image, tested, and then rolled out. Servers without the change are torn down and replaced.
Persisting data
Even when servers are disposable, the data that lives on them often is not.When implementing immutable servers you should consider what data needs to be persisted as servers are destroyed and created, and what data must be replicated in order to scale by adding additional servers.
You can ship data off of the instance when it has value but isn't needed at runtime, for example sending log files to a central server.
Local business data should be living on a SAN and cloud platforms generally offer mountable storage devices which can be attached to new servers instances when the old ones are destroyed, or quickly duplicated and attached to replicas when scaling a cluster.
About Daniel Vukasovich
No comments