Managing Infrastructure As Code
Friday, 19 August, 2022
Stay updated with our latest articles, subscribe to our newsletter
Manual vs “One touch” Provisioning
When servers were physical machines, system administrators used to purchase them, install them into racks, connect power cables, configure them from zero to working condition based on the purpose of the server. That time each server was like a pet – they usually had some names (like comics superheroes or ancient Greek Gods), but with virtualization, when multiple virtual machines (VMs) can be created on top of one physical server – the things have changed, and each virtual server has no longer its own individuality. This farm of servers is really treated as a herd of cattle rather than individual pets. These VMs do not have any meaningful names (only generated IDs), their lifecycle can be short compared to a physical host, they can be created and terminated based on current demand.
With scale comes the headache in managing multiple dynamically created and terminated machines, it gets even more dynamic with Containers whose life cycle is controlled by special Container Orchestration systems like Kubernetes or OpenShift.
Manual provisioning and management of a big number of servers is very inefficient, not scalable, prone to human errors, and not a reliable process. This effort cannot be reused and works only for a very limited number of hosts.
Nowadays, it is not an exceptional case when a company manages hundreds and thousands servers with help of relatively small DevOps teams, it would not have been possible without a significant level of automation, which is one of the core concepts of DevOps.
So, what can be done to facilitate provisioning and configuration of a large number of servers?
First, let us divide the task into smaller steps:
- Physical – unpack, install, connect to power, and plug into network
- Software/Configuration – install host OS, hypervisor, create VMs, install guest OS, create virtual network interfaces, configure security & network policies, install necessary patches and updates, configure monitoring, set up maintenance procedures like patch installation, backup creation, etc.
This is an example of a list of general activities required to provision and perform initial configuration of a VM on top of a physical server.
After this initial set up the VM is ready to be configured for some specific role, to become, for example, a Web Server, Application Server, DB server, etc.
If manual configuration of the physical part can hardly be automated, this is basically not in scope of work of DevOps team. Physical hardware configuration, installation to rack, and other mechanical work can be done by technicians or, in case, if we rent infrastructure from a Cloud Service Provider (like the Google Cloud Platform), it is made for us by the CSP in its provisioning computer data centers. So we shall focus only on the second part of the infrastructure provisioning process of cloud resources.
As DevOps, we always want to make any repetitive task automated and tracked, at the same time we would like to have our cloud infrastructure to be managed at scale with comprehensive and interactive configuration tools and practices. The Ultimate goal of such automation can be formulated as “One touch” provisioning, when you can perform full environment rollout with one click or one command.
The Solution
We have our goal specified, so how can we achieve it?
Here comes Infrastructure as Code (IaC) – concept of IT resource provisioning automation by creating documents similar to Software Development codes which define how what and when has to be provisioned. Let us focus on these three questions:
- What? – Identifies resources that we need to provision
- How? – Defines what parameters and configurations the resources must have. How they must be interconnected
- When? – Controls in what order, with what conditions and interdependencies the resources must be created
There is one additional question that arises sometimes – What if? It defines what to do if something goes wrong during infra provisioning, basically it sets up a rollback or rectification procedure.
Since DevOps takes the best of two worlds, to manage infrastructure we can use Software Development approaches such as:
- Preparation automation instructions as infra configuration files
- Versioning of the infra configuration files in Version Control Systems (VCS)
- Testing of infra automation
- Сoding best practices and conventions applied to configuration files
- Config files review and audit
- Collaborative work with machine readable definition files
Fig. 1. Infrastructure as code
Basically, Infrastructure as Code answers all the questions listed above and ensures reusability and transferability of infra configurations. It can be considered as preparation of an infrastructure template model that can be easily replicated to any number of different environments from a single point of truth.
Infrastructure as Code Tools
What does IaC stand for? It stands for Infrastructure as Code which pertains to the management of the system infrastructure using code instead of manually handling the processes involved.
There are two general approaches to how different IaC tools handle infrastructure provisioning automation: imperative and declarative. The difference is in the way instructions are defined in the code to be executed.
The imperative paradigm might be more familiar to system administrators because it is similar to Bash or PowerShell scripts they might have implemented themselves. These scripts execute various commands in a predefined sequence one by one in order to set up necessary infrastructure.
The declarative way is like a description of the desired infrastructure end state, a specification that needs to be met. Automation software uses this specification as a target and sets up all the elements considering interdependencies and interconnections between them.
The declarative way is considered as more popular and widely used. However, some systems combine both approaches that do not contradict, but complement each other as part of the Infrastructure as Code best practices.
It is also important to differentiate two types of provisioning infrastructure automation tools based on the level on which they operate:
- Configuration orchestration – work on VM/Container/Network. Basically it enables a platform for further software deployment. Examples of such systems: Terraform, AWS CloudFormation, Azure Resource Manager, and Cloud Deployment Manager.
- Configuration management – works with specific software systems to automate its deployment and configuration to already provisioned infrastructure. Examples of configuration management tools: Ansible, Chef, and Puppet.
In most of such tools, infrastructure configuration files are written using one of the two widely-used by DevOps file formats: JSON or YAML, less often IaC software use their own Domain Specific Language (DSL).
Fig. 2. git
Other Concepts
There are also few concepts to be familiar with when talking of IaC:
- Mutability/Immutability
- Idempotency
- Configuration Push/Pull
Mutability means that an infrastructure can be edited after provisioning and initial configuration. In this case, it becomes much more difficult to automate further the lifecycle of such an environment, which becomes inconsistent with other infrastructures created from the same code. The immutable environment does not change and keeps its initial configuration state, improving IaC security. If modification is necessary, the infrastructure can only be terminated and recreated again with changes applied to source configuration file(s).
Idempotency means that all configurations applied must produce the same result even if applied multiple times. The end state of the environment must remain the same regardless of its initial state.
Configuration Push/Pull pertains to the difference between two methods of how configuration is applied, whether it’s pulled from a central configuration server or pushed by it to the target environment. Pull-based systems use special programs, agents, to initiate configuration pull, when push-based systems are mostly “agentless”.
What Else to Consider?
Fig. 3. Consider factors like budget when choosing an IaC environment
(Source: Freepik)
When configuring an environment that contains elements that are stateful by design (like databases) or can contain some user data, you must be especially careful because if the environment is terminated and recreated, the data can be lost. It is quite common practice to exclude other infrastructure components from automated provisioning for production environments.
IaC can be used in all three cases: on premises, Private, and Public Clouds. When deploying it in Public Cloud it is very important to carefully review, audit and test your IaC configuration files for what types of IT resources and services they create. You must make sure that the infrastructure generated from these files fits into your budget and not give you “bill shock” if you keep launching new VMs if something is wrong with your config.
Conclusion
With help of IaC, DevOps teams can create infrastructures of any complexity from preconfigured templates in a form of configuration files that are managed, tracked, and tested in the same way as software development source code files. This approach allows to minimize provisioning time and effort, eliminate possible human errors, and gives the ability to replicate the same infrastructure for different purposes.
If you would like to know more about DevOps practices, tools, and concepts – stay tuned for future updates in our blog and join our project-based courses.
written by
Dare Olufunmilayo
Tell us about yourself...
Liked this article?
Stay updated with our latest articles, subscribe to our newsletter
