The document discusses infrastructure as code (IAC) and its principles and categories. Some key points: - IAC treats infrastructure like code by writing code to define, deploy, and update infrastructure. This allows infrastructure to be managed programmatically. - Common categories of IAC include ad hoc scripts, configuration management tools like Ansible and Puppet, server templating tools like Packer, and server provisioning tools like Terraform. - Benefits of IAC include automation, consistency, repeatability, versioning, validation, reuse, and allowing engineers to focus on code instead of manual tasks. - AWS offers CloudFormation for provisioning AWS resources through templates. Other tools integrate with Cloud

1. Infrastructure as Code

3. Starts with WHY?
DevOps is not a job title, a division, or a particular technology. It's a set
of processes, ideas, and values to make software delivery vastly more
efficient.

4. DevOps Core Values
• Four core values of DevOps are:
• Culture
• Automation
• Measurement
• Sharing
• Infrastructure as Code contributes to one of four DevOps core values,
that is automation.

5. What is Infrastructure as Code?
• The idea behind infrastructure as code (IAC) is that you write and
execute code to define, deploy, and update your infrastructure. This
represents an important shift in mindset where you treat all aspects of
operations as software, even those aspects that represent hardware
(e.g., setting up physical servers). In fact, a key insight of DevOps is
that you can manage almost everything in code, including servers,
databases, networks, log files, application configuration,
documentation, automated tests, deployment processes, and so on
• Infrastructure as code is about treating infrastructure as a software
system

6. Infrastructure as Code

7. Principles of Infrastructure as a Code
• System are easily reproduced
• System are disposable : treat as cattle, not pets
• Systems are consistent
• Processes are repeatable
• Design is always changing - dynamic

8. Categories of Infrastructure as a Code (IAC)
• Ad Hoc Scripts
• Configuration Management Tools
• Server Templating Tools
• Server Provisioning Tools

9. Ad Hoc Scripts
• The most straightforward approach to automating anything is to write an ad hoc
script.
• You take whatever task you were doing manually, break it down into discrete steps,
use your favorite scripting language (e.g., Bash, Ruby, Python) to define each of
those steps in code, and execute that script on your server

10. Configuration Management Tools
Chef, Puppet, Ansible, and SaltStack are all confguration management
tools, which means they are designed to install and manage software on
existing servers

11. Configuration Management Tools
With configuration management tools, we have much better advantages than using
ad hoc scripts
• Code conventions : enforces a consistent, predictable structure, including
documentation,file layout, clearly named parameters, secrets management,
and so on
• Idempotence : Code that works correctly no matter how many times you run
it is called idempotent code
• Distribution : Ad hoc scripts are designed to run on a single, local machine.
Ansible and other configuration management tools are designed specifically
for managing large numbers of remote servers

12. Server Templating Tools
An alternative to configuration management that has been growing in
popularity recently are server templating tools such as Docker, Packer,
and Vagrant. Instead of launching a bunch of servers and configuring
them by running the same code on each one, the idea behind server
templating tools is to create an image of a server that captures a fully
self-contained “snapshot” of the operating system, the software, the
files, and all other relevant details

13. Server Templating Tools - Example

14. Server Provisioning Tools
Whereas configuration management and server templating tools define the
code that runs on each server, server provisioning tools such as Terraform,
CloudFormation, and OpenStack Heat are responsible for creating the
servers themselves. In fact, you can use provisioning tools to not only create
servers, but also databases, caches, load balancers, queues, monitoring,
subnet configurations, firewall settings, routing rules, SSL certificates, and
almost every other aspect of your infrastructure

15. Benefit of IAC
• Self Service : Entire deployment process can be automated and engineers can write their
own deployment codes when necessary.
• Speed and Safety : Computer can provision multiple infrastructure with codes faster than
human can. Proper infrastructure as code technology enable consistency and
repeatability, make it less prone to error.
• Documentation : As long as everyone in your team can read the code, you don't have to
guess how the existing infrastructure was provisioned
• Version Control : You can see the history of your infrastructure evolution simply by
taking a look at your IaC git commits.
• Validation : If you build your infrastructure with code, you can do review, automated
tests, or any other practices aimed at reducing defects on your code.
• Reuse : You can package your deployments into modules and enable your team to reuse
documented and battle tested code instead of starting from scratch every time.
• Happiness : IaC allows you to do what you do best (writing code) and computer to do
what it does best (automation).

16. Immutability
• Mutable : Changes to code will update existing infrastructure.
• Immutable : Changes to code will create new infrastructure, most of
the time.

17. Procedural vs Declarative
• Procedural : We write code to tell computer how to do something.
The code specifies step-by-step, how to achieve some desired end
state.
• Declarative : We write code to tell computer what needs to be done
and let it figure out by itself how to achieve that. We just need to
specify our desired end state, and the IAC tool itself is responsible for
figuring out how to achieve that state.

18. Master vs Masterless
• Master : Require a master server to store the state of your infrastructure
and distribute updates. Every time we want to update something in our
infrastructure, we use a client (e.g., a command-line tool) to issue new
commands to the master server, and the master server either pushes the
updates out to all the other servers, or those servers pull the latest updates
down from the master server on a regular basis
• Masterless : May also require a master server (for instance, AWS/GCP API
server does act like a master server when you run Terraform codes), but
does not require you to manage it. For example, Terraform communicates
with cloud providers using the cloud provider’s APIs, so in some sense, the
API servers are master servers, except they don’t require any extra
infrastructure or any extra authentication mechanisms (i.e., just use our
API keys)

19. Agent vs Agentless
• Agent : Require us to install an agent software on the nodes you want
to configure. Drawbacks : Bootstrapping process, maintenance and
security.
• Agentless : Does not require us to install an agent software on nodes
you want to configure.

20. Comparison

21. Ansible
• It's a simple automation language that can perfectly describe an IT
application infrastructure in Ansible Playbooks.
• It's an automation engine that runs Ansible Playbooks
• Agentless
• Learn more about Ansible : Ansible Up and Running
• Practice using the Lab Manual provided

22. Terraform
• An open source tool created by HashiCorp.
• Writen in the Go programming language.
• A tool for building, changing, and versioning infrastructure safely and efficiently
• Practice using this resources :
• https://hackernoon.com/introduction-to-aws-with-terraform-7a8daf261dc0
• https://blog.gruntwork.io/a-comprehensive-guide-to-terraform-b3d32832baca
• https://medium.com/slalom-technology/a-complete-gcp-environment-with-
terraform-c087190366f0
• https://wilsonmar.github.io/terraform/
• https://github.com/artberri/101-terraform
• Learn more about Terraform : Terraform Up and Running

23. Why Terraform?

24. Why Terraform?
• Terraform supports 250+ providers, has easier syntax (HCL), has
native support for modules and remote states, has teamwork related
features, is an open-source project
• Provides a high-level abstraction of infrastructure, unifies the view of
resources
• Supports the modern datacenter (IaaS, PaaS, SaaS)
• Separates planning from execution (dry-run)
• Provides a workflow which is technology agnostic
• Manages anything with an API

25. Terraform Workflow Example

26. Terraform State File
• Real world mapping of
resources
• Track metadata of
resource and its
dependency with respect
to other resources
• State is exposed - Protect
your state file at all cost!
• Teams collaborate via state
files

27. Local Terraform Usage
Pros
• Simple
Issues
• No backup of state files
• Not even possible to collaborate in a
team setting
• Different developers have different
Terraform environments
• Doesn’t integrate into a CI/CD
workflow

28. Solution – Remote Backend using S3
• No backup of state files
• Not even really possible to collaborate
in a team setting
• Different developers have different
Terraform environments
• Doesn’t integrate into a CI/CD
workflow

29. Solution : Atlantis
https://www.runatlantis.io/

30. Convert visual AWS diagram into Terraform configurations
https://medium.com/faun/modules-tf-convert-visual-aws-
diagram-into-terraform-configurations-e61fb0574b10

31. Using Multiple Tools Together
• Provisioning plus configuration management
Example: Terraform and Ansible. We use Terraform to deploy all the underlying
infrastructure, including the network topology, data stores, load balancers, and servers. We
then use Ansible to deploy our apps on top of those servers.
• Provisioning plus server templating
Example: Terraform and Packer. We use Packer to package our apps as virtual machine
images. We then use Terraform to deploy : servers with these virtual machine images and
the rest of our infrastructure.
• Provisioning plus server templating plus orchestration
Example: Terraform, Packer, Docker, and Kubernetes. We use Packer to create a virtual
machine image that has Docker and Kubernetes installed. You then use Terraform to deploy
: a cluster of servers, each of which runs this virtual machine image and the rest of our
infrastructure, including the network topology data stores and load balancers. Finally,
when the cluster of servers boots up, it forms a Kubernetes cluster that we use to run and
manage our Dockerized applications.

32. AWS Proprietary IAC - CloudFormation

33. AWS IAC - CloudFormation
• Currently, we have been doing a lot of manual work in AWS 
• All this manual work will be very tough to reproduce:
• In another region
• In another AWS account
• Within the same region if everything was deleted
• Wouldn’t it be great, if all our infrastructure was… code?
• That code would be deployed and create / update / delete our
infrastructure
• Example : https://aws.amazon.com/blogs/mt/leveraging-immutable-
infrastructure-nubank/

34. AWS CloudFormation
• CloudFormation is a declarative way of outlining our AWS
Infrastructure, for any resources (most of them are supported).
• For example, within a CloudFormation template, we can say:
• I want a security group
• I want two EC2 machines using this security group
• I want two Elastic IPs for these EC2 machines
• I want an S3 bucket
• I want a load balancer (ELB) in front of these machines
• Then CloudFormation creates those for us, in the right order, with the
exact configuration that we specify

35. AWS CloudFormation Example

36. AWS CloudFormation
• AWS CloudFormation introduces two concepts: The template, a JSON or
YAML format, text-based file that describes all the AWS resources we need
to deploy to run our application and the stack, the set of AWS resources
that are created and managed as a single unit when AWS CloudFormation
instantiates a template.
• If all resources is not created properly a rollback occurs and all the
resources are deleted.
• If a successful stack is deleted, all resources are deleted.
• Other tools :
• https://github.com/cloudtools/troposphere  Library to create AWS
CloudFormation descriptions
• https://github.com/awslabs/goformation  Go library for working with AWS
CloudFormation

37. Benefits of AWS CloudFormation
• Infrastructure as code
• No resources are manually created, which is excellent for control
• The code can be version controlled for example using git
• Changes to the infrastructure are reviewed through code
• Cost
• Each resources within the stack is tagged with an identifier so you can easily see how
much a stack costs you
• You can estimate the costs of your resources using the CloudFormation template
• Savings strategy: In Dev, you could automation deletion of templates at 5 PM and
recreated at 8 AM, safely

38. Benefits of AWS CloudFormation
• Productivity
• Ability to destroy and re-create an infrastructure on the cloud on the fly
• Automated generation of Diagram for your templates!
• Declarative programming (no need to figure out ordering and orchestration)
• Separation of concern: create many stacks for many apps, and many layers. Ex:
• VPC stacks
• Network stacks
• App stacks
• Don’t re-invent the wheel
• Leverage existing templates on the web!
• Leverage the documentation

39. How CloudFormation Works
• Templates have to be uploaded in S3 and then referenced in
CloudFormation
• To update a template, we can’t edit previous ones. We have to reupload a new
version of the template to AWS
• Stacks are identified by a name
• Deleting a stack deletes every single artifact that was created by CloudFormation.

40. Deploying CloudFormation Templates
• Manual way:
• Editing templates in the CloudFormation Designer
• Using the console to input parameters, etc
• Automated way:
• Editing templates in a YAML file
• Using the AWS CLI (Command Line Interface) to deploy the
templates
• Recommended way when you fully want to automate your flow

41. CloudFormation Designer

42. CloudFormation Building Blocks
• Templates component
• Resources: your AWS resources declared in the template (MANDATORY)
• Parameters: the dynamic inputs for your template
• Mappings: the static variables for your template
• Outputs: References to what has been created
• Conditionals: List of conditions to perform resource creation
• Metadata
• Templates helpers:
• References
• Functions

43. AWS CDK
• Use the AWS CDK to define our cloud resources in a familiar programming
language. The AWS CDK supports TypeScript, JavaScript, and Python. The AWS
CDK also provides Developer Preview support for C#/.NET, and Java.
• Developers can use one of the supported programming languages to define
reusable cloud components known as Constructs. You compose these together
into Stacks and Apps
https://docs.aws.amazon.com/cdk/latest/guide/home.html

44. Infrastructure as Code Is Not Just for the Cloud
• Infrastructure as code has come into its own with cloud, because it’s difficult to
manage servers in the cloud well without it. But the principles and practices of
infrastructure as code can be applied to infrastructure whether it runs on cloud,
virtualized systems, or even directly on physical hardware.
• We use the phrase “dynamic infrastructure” to refer to the ability to create and
destroy servers programmatically. Cloud does this naturally, and virtualization
platforms can be configured to do the same. But even hardware can be
automatically provisioned so that it can be used in a fully dynamic fashion. This is
sometimes referred to as “bare-metal cloud.
• It is possible to use many of the concepts of infrastructure as code with static
infrastructure. Servers that have been manually provisioned can be configured
and updated using server configuration tools. However, the ability to effortlessly
destroy and rebuild servers is essential for many of the more advanced practices
we discussed before.

45. Putting it All Together
Managing AWS Infrastructure as Code using Ansible, CloudFormation,
and CodeBuild : https://programmaticponderings.com/2019/07/30/managing-aws-
infrastructure-as-code-using-ansible-cloudformation-and-codebuild/

46. Q and A + Hands On Labs