Wikipedia defines IaC as:
Infrastructure as code (IaC) is the process of managing and provisioning computing infrastructure (processes, bare-metal servers, virtual servers, etc.) and their configuration through machine-processable definition files, rather than physical hardware configuration or the use of interactive configuration tools. The definition files may be in a version control system. This has been achieved previously through either scripts or declarative definitions, rather than manual processes, but developments as specifically titled ‘IaC‘ are now focused on the declarative approaches.
Infrastructure as Code (IaC) is a way to configure infrastructure which operations teams can manage and provision automatically through code; thereby getting rid of the need of manual efforts to perform the same tasks. Infrastructure as Code can also be termed as programmable infrastructure.
IaC is not a product; it is a methodology. It is a thought process that leads to the execution and, at the end, rapid deployment of a virtual environment.
With IaC, the infrastructure is maintained at the same level as in a software project. It may be a related to programming scripts, which can automate important IT processes. But, instead of scripts, IaC uses a Domain-Specific-Language (DSL) to code more versatile and adaptive provisioning and deployment processes.
For example, IaC can be coded with Puppet, a product of Puppet Labs, could install Apache server, verify that Apache server is running properly, create a user account and password, configure Apache to run on a specific port, set up new virtual hosts and more, everything via code.
As mentioned before, the IaC infrastructure management resembles formal software design practices in which developers modify code, control code versions, test them and do conditional deployment (i.e. prove and approve the Code for production).
Benefits of IaC
There can be two immediate and highly visible advantages of IaC:
- Less manual efforts (hence reduced expenses).
- With IaC, things run more quickly and are less prone to error. The risks are reduced as well.
- Less dependency on IT, which means happy developers
- Developers do not need to depend on IT for their deployment and provisioning tasks.
Now, let us take a look at how we can actually use Puppet to implement IaC in any environment.
How Does Puppet Work?
Puppet consists of two physical components:
- Server: (usually called puppetserver or puppetmaster). This is the component of puppet infra that holds all the information about all the machines (called Nodes) that it can configure.
- Node: A machine that can be managed by Puppet in called a Node.
Specific software needs to be installed on each of the above machines
- Puppet agent: It is a daemon that runs on the Node servers
- Puppet server: A daemon which runs on the puppetmaster / puppet-server where all the node configurations are stored. The puppet server listens to any connection requests initiating from agents for configuration changes/upgrades.
NOTE: All the clients which are to be managed will have puppet agent installed on them, and are called nodes in Puppet.
Puppet master contains all the configuration for different hosts. Puppet master will run as a daemon on this master server.
The puppet agent and master communicate with each other via a secure encrypted channel implemented using the help of SSL.
An agent must authorize itself with the master (by submitting its keys and getting them signed) before it can be managed by the server. Unless this happens, the puppet master will simply ignore any request from the agent.
A fact to note is that it is the responsibility of the client (puppet agent) to regularly fetch the configuration data from the puppet master server. Puppet server never initiates the server configuration data requests.
The steps involved for a puppet agent to ask, receive and apply a configuration on the node on which it runs, are mentioned below
- Puppet agent requests the server to send the latest configurations. It also sends along the facts about the node (facts are nothing but system information, like OS type and OS Name).
- Upon receiving such request, the master server analyzes the configuration to be applied to the node.
- The analyzed data is compiled in the format native to the host environment of the agent node.
- Facts of the nodes are used for this. The compiled configuration data is called a catalog. 3
- This catalog is sent across to the puppet agent of the node.
- Puppet agent applies the catalog on the node
- Puppet agent updates the puppet master server about it (success/failures/commands executed etc.).
- Puppet can further, optionally, generate reports using Puppet APIs.
Note: If a configuration is already applied on the node, then the puppet agent does nothing.
Puppet stores all the configurations for a node in a platform independent manner. This means that a configuration can be applied on a CentOS machine, an Ubuntu Machine, and a Windows machine.
This is achieved by a unique concept in Puppet, called Resource Abstraction Layer. RAL is an abstraction which enables users to define a configuration which can be platform independent besides being highly portable. At the time of configuration compilation, the server looks at the Agent’s Node configuration (OS type, architecture, security restrictions etc.) and compiles a catalog accordingly.
Below are the various components involved:
- Manifests: Each Puppet node’s configuration details in stored on Puppet Master, written in the native Puppet DSL (Domain Specific language). These configurations are called manifests. The configurations can be stored in a single or multiple manifests. Manifests have the .pp extension. Manifests are platform independent.
- Module: A Puppet Module is a standalone collection of manifests and supporting data (for example classes, facts, files, and templates). Modules follow a very specific directory structure. Modules can be used to distribute your manifests with other users. They also come handy in organizing your Puppet code. Modules are self-contained bundles of code and data.
Resource: Resources are the fundamental and smallest unit for defining system configurations for a node. Each resource describes some aspect of a system, like a specific file, service or package.
Facter: Facter gathers basic information (facts) about Puppet nodes (for example hardware details, network settings, OS type and version, IP addresses, MAC addresses, SSH keys etc.). These facts are then made available in Puppet Master’s manifests as variables. Also, these facts are used in compiling platform independent manifests into a node platform specific catalog.
Catalogs: A Catalog describes the desired state of each managed resource on a node. It is a compilation of all the resources that the Puppet Master applies to a given slave, as well as the relationships between those resources. Catalogs are compiled by a Puppet Master from manifests and slave-provided data (such as facts, certificates, and an environment if one is provided), as well as an optional external data (such as data from an external Slave classifier, exported resources, and functions). The master then serves the compiled catalog to the slave when requested. The agent receives the catalog and applies it on the node for achieving desired server state.
Hope this blog helped you in understanding Infrastructure as Code. Enroll for the DevOps Training conducted by ACADGILD.