Infrastructure as Code

Infrastructure as Code

Infrastructure as code (IAC) is a concept in which you create, deploy, update, and destroy your infrastructure by writing and executing code.

Categories

Ad hoc scripts

Bash, Ruby, Python scripts that execute on the servers. However, When you attempt to handle hundreds of servers, databases, load balancers, network settings, and so on using ad hoc scripts, things become complicated.

Configuration management tools

Examples include Chef, Puppet, Ansible, and SaltStack.

Advanteages:

1. Coding conventions: Contrary to ad hoc scripts, most configuration management systems come with a set of standards that help developers traverse their code.
2. Idempotence: Code that works correctly no matter how many times you run
3. Distribution: Ad hoc scripts are intended to execute on a single computer. Ansible and other configuration management technologies are intended to handle a large number of remote servers.

Server templating tools

Server templating technologies like Docker, Packer, and Vagrant have lately gained prominence as alternatives to configuration management. Instead of starting many servers and configuring them all with the same code, server templating tools generate a server image that contains a complete “snapshot” of the OS, software, files, and other important information. Then use another IaC programme to instal it on all your servers.

Tools for working with images

Virtual machines: A virtual machine (VM) simulates a complete computer system, including the hardware. With VMWare, VirtualBox, or Parallels you virtualize  the CPU, memory, hard drive, and networking.

Pros: Any VM image running on top of the hypervisor can only view virtualized hardware, keeping it completely isolated from the host system and other VM images (e.g., your computer, a QA server, a production server)

Cons: Each VM has its own OS, virtualizing all this hardware incurs significant cost in terms of CPU, memory, and startup time.

Cotnainers A container simulate an OS's user space, then you run a container engine like Docker, CoreOS rkt, or cri-o to generate separated processes.

Pros: The advantage is that each container running on top of the container engine can only view its own user space, keeping it isolated from the host system and other containers (your computer, a QA server, a production server, etc.)

Cons: The disadvantage is that all containers on a single server share the same OS kernel and hardware, making it impossible to achieve the same degree of isolation and security as a VM. However, because the kernel and hardware are shared, containers start up in milliseconds with little CPU and memory use.

Commom pattern

Note that each server templating tool has a unique function. Use Packer to build images that operate directly on production servers, like an AMI in your production AWS account. Vagrant usually creates images for development machines, such a VirtualBox image for your Mac or Windows laptop. Docker is usually used to build app images.

A common pattern is to use Packer to build an AMI with the Docker Engine installed, then deploying that AMI on a cluster of machines in your AWS account to execute your apps.

Immutable infrastructure

This concept comes from functional programming and involves immutable variables, which means that once set, they can never be changed. Because variables don't change, they're simpler to reason about.

Immutable infrastructure works similarly: once deployed, a server is never changed again. To update anything, you generate a new image from your server template and deploy it on a new server. It's simpler to reason about what's deployed since servers never change.

Orchestration tools

In real world, you will need the following steps to deploy the new infracturure:

• Deploy VMs and containers, making efficient use of your hardware.
• Roll out updates to an existing fleet of VMs and containers using strategies such as rolling deployment, blue-green deployment, and canary deployment.
• Monitor the health of your VMs and containers and automatically replace unhealthy ones (auto healing).
• Scale the number of VMs and containers up or down in response to load (auto scaling).
• Distribute traffic across your VMs and containers (load balancing).
• Allow your VMs and containers to find and talk to one another over the network (service discovery).

Orchestration tools like Kubernetes, Marathon/Mesos, Amazon Elastic Container Service (Amazon ECS), Docker Swarm, and Nomad can help software engineers to easily manage the those steps with less effort.

For example, Kubernetes lets you specify container management as code. You would first set up a Kubernetes cluster, which is a collection of servers managed by Kubernetes.

Provisioning tools

While configuration management, server templating, and orchestration tools specify the code that runs on each server, provisioning tools like Terraform, CloudFormation, and OpenStack Heat create the servers themselves, including database caches, load balancers, queues, monitoring, subnet configurations, firewall settings, routing rules, Secure Sockets Layer (SSL) certificates, and almost every other aspect of your infrastructure.

The Benefits of Infrastructure as Code

1. Self-service: Since infrastructure is defined in code, the whole deployment process can be automated, and developers can initiate their own deployments as needed.
2. Speed and safety: If the deployment process is automated, it will be considerably quicker since a computer can do the deployment stages much faster than a person; and safer because an automated process will be more consistent, repeatable, and less prone to human mistake.
3. Documentation: IaC serves as documentation, enabling everyone in the company to understand how things operate even if the system administrator is away.
4. Version control: Your IaC source files may be stored under version control, capturing the full history of your infrastructure in the commit log. When a problem arises, the first step is to examine the commit log to see what happened in your infrastructure, and the second is to simply rollback to a known-good version of your IaC code.
5. Validation: If your infrastructure is specified in code, you may conduct code reviews, run automated tests, and analyse the code using static analysis tools after every update.
6. Reuse: You can bundle your infrastructure into reusable modules so you don't have to recreate it for every product and environment.
7. Happiness: Manually deploying code and maintaining infrastructure is tedious. No originality, no challenge, no acknowledgement, no reward. No one will notice if you release code flawlessly for months, unless you make a mistake. That causes tension and annoyance. Instead, IaC lets computers do what they do best (automation) and people do what they do best (development) (coding).