INFRASTRUCTURE
AS CODE (IAC)
INFRASTRUCTURE AS
CODE (IAC)
Infrastructure as Code (IaC) is the managing and provisioning of
infrastructure through code instead of through manual processes
OR
IaC is the practice of provisioning and managing an infrastructure
through a descriptive model using code
INFRASTRUCTURE AS
CODE (IAC)
Configuration files created with Infrastructure as Code describe
the specifications of the infrastructure
Allows for automation of the creation and modification of
infrastructure
Configuration of a computer center's resources (network, servers,
virtual machines, load balancer)
An IaC model generates the same result every time it runs, avoiding
misconfiguration, and saving a lot of time
Helps you to avoid undocumented, ad-hoc configuration changes
Can be imperative and declarative
– CATEGORIES
Provisioning – tools in this category provision infrastructure
components for one or more cloud providers. Examples: Terraform,
AWS CloudFormation, and Pulumi
Configuration Management – tools in this category are
responsible for installing and managing software on already
existing infrastructure. Examples: Ansible, Chef, and Puppet
DECLARATIVE VS
IMPERATIVE APPROACH
Declarative Approach (Functional)
You specify the desired state, and the tool automatically determines the steps
to achieve that state
Define the "what" (desired end-state)
Figure out the "how" (steps to reach that state)
-----
Less manual intervention
More abstract and easier to read
Enables automation of infrastructure state management
(Terraform, AWS CloudFormation, Kubernetes)
DECLARATIVE VS
IMPERATIVE APPROACH
Imperative Approach (Procedural)
You specify the exact steps required to reach the desired state
Define the "how" (a sequence of actions or steps to execute)
Execute those steps in the specified order
----
More control over the process
Can be easier to debug since you specify every action
Suitable for complex, stateful workflows
(Ansible, Chef, Puppet)
DECLARATIVE VS
IMPERATIVE APPROACH
MUTABLE VS IMMUTABLE
INFRASTRUCTURE
Mutable Infrastructure
You can update and modify the infrastructure after it has been deployed
Define the "what" and "how" of the updates or changes
Apply the updates to the existing infrastructure
----
More flexible, as you can make changes directly to the running
infrastructure
Potential for configuration drift over time
Requires continuous monitoring to ensure consistency
Examples: Ansible, Chef, Puppet
MUTABLE VS IMMUTABLE
INFRASTRUCTURE
Immutable Infrastructure
The infrastructure cannot be updated directly. Any change requires redeploying
the entire infrastructure
Define the "desired state" of the infrastructure
Destroy the old infrastructure and recreate the new one based on the desired
state
----
Higher consistency and predictability, as all instances are identical
More rigid and less flexible; requires complete redeployment for any changes
Less manual intervention in maintaining the system's state
Examples: Terraform, AWS CloudFormation, Pulumi
AGENT VS AGENTLESS
Agent-Based Infrastructure
Requires installing an agent on each server or machine that needs to be
managed
Define the desired state for each server and configure the agent
The agent applies configurations and synchronizes updates
----
Requires installing and maintaining agents on all managed machines
Agents allow for continuous monitoring and state enforcement
Can provide more detailed control and feedback during updates
Examples: Chef, Puppet
AGENT VS AGENTLESS
Agentless Infrastructure
No need to install any agents. The tool directly communicates with the server
(e.g., via SSH or APIs)
Define the desired state for the infrastructure
Use existing protocols to apply configurations without needing an agent
----
Simplifies setup as no additional software is required
Ideal for environments where you don’t want to install or manage agents
Typically used for one-time configuration applications rather than ongoing
management
Examples: Ansible, Terraform, Pulumi
PUSH VS PULL
Push Configuration
The controlling server pushes configurations to the destination systems
Define the configuration to be pushed to the target system
Push updates from a central server to the target infrastructure
----
The central server actively pushes configurations
Immediate and centralized control over the target systems
Suitable for environments where quick, real-time updates are necessary
Examples: Terraform, AWS CloudFormation, Ansible, Pulumi
PUSH VS PULL
Pull Configuration
The target systems pull the configuration from the central server
Define the desired state, and make it available for the systems to pull
The system autonomously pulls its configuration at regular intervals
----
The target systems control when and how updates are pulled
Ideal for environments where systems need to operate autonomously and
update periodically
Suitable for large-scale systems or environments requiring less direct control
Examples: Chef, Puppet
CONFIGURATION
LANGUAGE/CONFIGURATION FILE
FORMAT
Terraform: HashiCorp Configuration Language (HCL2)
AWS CloudFormation: JSON, YAML
Pulumi: TypeScript, Go, Python, C#, Java, or YAML
Ansible: YAML
Chef: Ruby DSL
Puppet: Puppet DSL
INFRASTRUCTURE AS CODE:
ADVANTAGES
Reducing time and costs
frees people from manual infrastructure management
Documentation and testing
constantly document the work being done for each instance of the infrastructure
better understanding of one's own infrastructure,
More standardized, stable and scalable environments
environments that are stable, and can scale rapidly and automatically
Security, disaster recovery
security standards and policies can be implemented and followed across all
stages of development and production, without the need for a review at each
step
CHALLENGES AND CRITICAL ISSUES IN
THE IAC
Outdated tools
In the case of new cloud functionalities, there may be a delay before they are implemented
in the IaC management tool we use
Understanding IAC
how they work and their key principles, if you're familiar with programming languages like
Python or Ruby, you still need to understand the specific logic and rules used in IaC
Maintenance with large groups
difficulties in maintaining its functions when used by very large groups of developers
Access and Permit Management
The definition of roles and permissions in large organizations is complex and difficult
IAC WITH TERRAFORM
Infrastructure as Code (IaC) with Terraform
simplifies the process of managing infrastructure by
allowing you to define, provision, and manage
infrastructure using code.
Terraform, created by HashiCorp, is one of the most
popular IaC tools, and it follows the declarative
approach, meaning you define what infrastructure
you want, and Terraform takes care of how to
provision and manage it
IAC WITH TERRAFORM
You specify the desired state of your infrastructure in
configuration files (written in HCL - HashiCorp Configuration
Language)
Terraform then calculates the necessary steps to achieve and
maintain that state
Providers:
Terraform interacts with various cloud providers (like AWS, Azure,
Google Cloud, etc.), on-premise systems, and other services via
providers
Each provider exposes resources you can configure in your code
(e.g., EC2 instances, S3 buckets for AWS)
IAC WITH TERRAFORM
Resources:
Resources are the basic building blocks in Terraform. They define the
infrastructure components like servers, networks, databases, etc
Example: aws_instance for EC2 instance, aws_s3_bucket for S3 storage
Modules:
Modules are reusable groups of resources that are organized and can be
shared across different configurations. They allow you to organize code
for reusability and simplicity
Example: A module could define a network with subnets, VPC, and
security groups
IAC WITH TERRAFORM
State:
Terraform maintains a state file that records the current state of the
infrastructure it manages. This state is used to track which resources have
been created, modified, or destroyed
The state file can be stored locally or remotely (e.g., in a cloud storage
bucket) for team collaboration
Execution Plan:
Terraform uses the plan command to preview changes before they are
applied to the infrastructure
Example: When you modify the configuration files, you run terraform plan
to see what resources will be created, updated, or destroyed.
IAC WITH TERRAFORM
Apply Changes:
After reviewing the plan, you can run terraform apply to execute
the changes and create/update the infrastructure accordingly
Idempotency:
Terraform is idempotent, meaning if you run the same configuration
again, it will make the infrastructure match the desired state
without causing errors or re-creating resources unnecessarily.
STEPS TO USE TERRAFORM FOR IAC
Install Terraform:
Download and install Terraform from the official website: Terraform
Installation
Write Configuration Files:
Create .tf files to define the desired infrastructure. A basic
configuration might look like this (for creating an AWS EC2
instance):
STEPS TO USE TERRAFORM FOR IAC
provider "aws" {
region = "us-east-1"
}
resource "aws_instance" "example" {
ami = "ami-12345678"
instance_type = "[Link]"
}
STEPS TO USE TERRAFORM FOR IAC
Initialize Terraform:
In the directory containing your configuration files, run terraform
init to initialize the working directory, download required providers,
and set up the backend for the state file
Plan Changes:
Run terraform plan to preview what changes will be made based on
your configuration
STEPS TO USE TERRAFORM FOR IAC
Apply the Configuration:
Execute terraform apply to apply the changes and provision the
resources
Verify the Infrastructure:
Once applied, check your cloud provider's console (e.g., AWS
Management Console) to see the created resources
STEPS TO USE TERRAFORM FOR IAC
Modify Infrastructure:
Update your .tf configuration files to make changes to the
infrastructure
Run terraform plan and terraform apply to update the infrastructure
Destroy Infrastructure:
To destroy the resources managed by Terraform, use terraform
destroy
This will remove all resources defined in the configuration files.
EXAMPLE: TERRAFORM WORKFLOW
Configuration File ([Link]):hcl
provider "aws" {
region = "us-west-2"
}
resource "aws_instance" "my_instance" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "[Link]"
}
TERRAFORM COMMANDS
terraform init
terraform plan
terraform apply
terraform destroy
IAC WITH DEVOPS PIPELINES
Infrastructure as Code (IaC) with DevOps Pipelines combines the
benefits of automated infrastructure management with the
automation of software delivery. By integrating IaC into DevOps
pipelines, you can ensure that your infrastructure is versioned,
consistently deployed, and tightly integrated with the rest of your
application development and deployment processes.
IAC WITH DEVOPS PIPELINES
WHY USE IAC WITH DEVOPS PIPELINES?
Consistency and Reproducibility: IaC ensures that infrastructure is
deployed in a consistent manner every time, which is critical in DevOps
practices where consistency across environments is essential
Automation: By automating both infrastructure provisioning and
software delivery, you eliminate manual intervention and reduce errors
Speed and Efficiency: Automated pipelines can speed up both
infrastructure and application updates, enabling faster delivery cycles
(CI/CD)
Collaboration: IaC integrates infrastructure management directly into
the DevOps workflow, allowing development, operations, and security
teams to collaborate more effectively.
KEY COMPONENTS OF IAC IN DEVOPS
PIPELINES:
Version Control:
IaC Code (e.g., Terraform, Ansible) is stored in a version-controlled
repository (e.g., Git).All infrastructure configurations, changes, and
history are tracked in Git or other version control systems (VCS), just
like application code
CI/CD Pipeline Integration:
IaC tools like Terraform, CloudFormation, or Ansible can be
integrated into your Continuous Integration/Continuous Deployment
(CI/CD) [Link] CI/CD pipeline automates building, testing, and
deploying both the application and infrastructure.
KEY COMPONENTS OF IAC IN DEVOPS
PIPELINES:
Pipeline Steps for IaC:
Infrastructure Provisioning: The pipeline provisions or updates
infrastructure automatically when changes are made to the IaC configurations
Application Deployment: Once the infrastructure is ready, the pipeline
deploys the application on the newly provisioned resources
Infrastructure Testing: Infrastructure can be tested (e.g., using Terraform’s
plan command) to validate that the desired state matches the actual state
before deployment
Infrastructure Destruction: After testing or during certain environments
(e.g., in testing/staging), infrastructure can be destroyed using tools like
terraform destroy
EXAMPLE WORKFLOW FOR IAC WITH
DEVOPS PIPELINES
Code Commit:
Developers write code for both the application and the infrastructure (e.g., in
Terraform .tf files).They commit the code changes (including infrastructure changes) to
the version control system (e.g., GitHub, GitLab).
CI/CD Pipeline Trigger:
A change to the repository triggers the [Link] pipeline is typically defined using
tools like Jenkins, GitLab CI/CD, GitHub Actions, CircleCI, or Azure DevOps.
Provisioning Infrastructure (IaC):
The pipeline starts by initializing the IaC tool (e.g., terraform init for Terraform).It checks
for any changes to the infrastructure and compares the desired state against the
current [Link] the desired state differs (e.g., new resource or updated resource), it will
generate an execution plan (e.g., terraform plan).The pipeline applies the plan
(terraform apply) to provision or update the infrastructure.
EXAMPLE WORKFLOW FOR IAC WITH
DEVOPS PIPELINES
Application Build and Deployment:
Once the infrastructure is provisioned or updated, the pipeline
proceeds with the application [Link] application is built, tested,
and deployed to the infrastructure (e.g., deploying to an EC2 instance,
Kubernetes, or a container service)
Automated Testing:
Both infrastructure and application can be tested automatically
Infrastructure Testing:
Check that infrastructure is correctly provisioned and meets the
required specifications
EXAMPLE WORKFLOW FOR IAC WITH
DEVOPS PIPELINES
Application Testing:
Unit tests, integration tests, and end-to-end tests can be executed to ensure the
application works as expected on the provisioned infrastructure
Continuous Monitoring:
The pipeline can integrate with monitoring tools to continuously check the health
of the infrastructure and application. If there are any issues, alerts are raised, and
the team can trigger another pipeline run for remediation
Destruction/Teardown:
For testing environments, infrastructure can be destroyed at the end of the
pipeline using commands like terraform destroy. This ensures that resources aren’t
left running unnecessarily, optimizing costs (especially in cloud environments).
