If you are new to infrastructure automation, there is a high chance you would have come across the word “Immutable infrastructure.”
So what does immutable infrastructure really mean?
Traditionally to host an application, one would deploy a server and configure applications.
Then comes server patching, application upgrades, server configurations changes, etc. These actions would be performed on the same server manually or using tools.
Immutable — Like its literal meaning, Immutable infrastructure is a concept where you don’t make any changes to the server after deploying it.
If you want to make any changes, the existing servers should be destroyed and replaced with a new one.
A change could be patching, application upgrade, server configurations change, etc.
You can follow the immutable infrastructure model for most modern applications, including database clusters.
In an immutable model, standard best practices should be followed in terms of configurations.
For example, externalizing commonly changed configurations using config store or a service discovery tool. A classic example would be the Nginx upstream configuration.
This way, you don’t have to bounce off a server for minor changes and configurations.
When it comes to CI/CD in VM environments, a VM image would be a deployable artifact when following an immutable infrastructure model.
For example, once CI is done, you can bake the app in a VM image (AWS AMI) with tools like packer and use it to deploy in the relevant environments.
If you are aware of containers, it is the best example of immutable infrastructure. Any change to a container results in a rebuild except for externalized configurations.