Poll: What best describes your role?
β Security
β Infrastructure / Platform
β Release
β Test
β Software
β Other
@joatmon08 | 7
Slide 8
Slide 8 text
By the end of this training, youβll be able to....
β Define & express infrastructure as code
β Write tests for infrastructure as code
β Build a delivery pipeline for infrastructure as
code
β Evaluate the practices and patterns to apply in
an organization
@joatmon08 | 8
Slide 9
Slide 9 text
What is infrastructure
as code?
@joatmon08 | 9
Slide 10
Slide 10 text
Infrastructure
Software, platform, or hardware that delivers or
deploys applications to production.
@joatmon08 | 10
Slide 11
Slide 11 text
@joatmon08 | 11
Write down
steps for
your
infrastructure
changes.
Slide 12
Slide 12 text
@joatmon08 | 12
Write down
steps for
your
infrastructure
changes.
(Maybe)
Test
changes in
development
environment.
Slide 13
Slide 13 text
@joatmon08 | 13
Write down
steps for
your
infrastructure
changes.
Wait for
change
approval.
(Maybe)
Test
changes in
development
environment.
Slide 14
Slide 14 text
@joatmon08 | 14
Write down
steps for
your
infrastructure
changes.
Wait for
change
approval.
Apply the
change to
production
system.
(Maybe)
Test
changes in
development
environment.
Slide 15
Slide 15 text
π
best case: no one else is making changes and you didnβt break anything
@joatmon08 | 15
Slide 16
Slide 16 text
π₯
worst case: your change conflicts and something broke everything
@joatmon08 | 16
Slide 17
Slide 17 text
Infrastructure as Code (IaC)
The process of automating infrastructure changes in
a codified manner.
It applies practices such as version control and
continuous delivery.
@joatmon08 | 17
Slide 18
Slide 18 text
@joatmon08 | 18
Write
infrastructure
changes in a
codified
manner.
Slide 19
Slide 19 text
@joatmon08 | 19
Write
infrastructure
changes in a
codified
manner.
Commit
changes to
version
control.
Slide 20
Slide 20 text
@joatmon08 | 20
Write
infrastructure
changes in a
codified
manner.
Commit
changes to
version
control.
Test
changes in
development
environment.
Slide 21
Slide 21 text
@joatmon08 | 21
Write
infrastructure
changes in a
codified
manner.
Wait for code
review.
Commit
changes to
version
control.
Test
changes in
development
environment.
Slide 22
Slide 22 text
@joatmon08 | 22
Write
infrastructure
changes in a
codified
manner.
Wait for code
review.
Deploy the
change to
production
system.
Commit
changes to
version
control.
Test
changes in
development
environment.
Slide 23
Slide 23 text
Use Cases
β Provisioning
β Configuration Management
β Image Building
@joatmon08 | 23
Slide 24
Slide 24 text
Which of the following is not infrastructure as code?
A. Shell script to install a binary
B. Documentation outlining steps in a UI
C. Python code to add a VLAN to a network switch
D. AWS CloudFormation stack
@joatmon08 | 24
Slide 25
Slide 25 text
Which of the following is not infrastructure as code?
A. Shell script to install a binary
B. Documentation outlining steps in a UI
C. Python code to add a VLAN to a network switch
D. AWS CloudFormation stack
E. Potentially all of the above
@joatmon08 | 25
How do I write
infrastructure as
code?
@joatmon08 | 27
Slide 28
Slide 28 text
Imperative or Declarative?
Imperative
β How should you make the
change?
β Use Cases:
β Configuration
Management
Declarative
β What change are you
making?
β Use Cases:
β Provisioning
β Image Building
@joatmon08 | 28
Slide 29
Slide 29 text
Mutability or Immutability?
Mutability
β Change resource in-place
β Less time to change
Immutability
β Change new resource,
remove the old one
β Less downtime due to
(potential) failure
@joatmon08 | 29
Slide 30
Slide 30 text
Code or Configuration?
Code
β Programming language
β Declarative / imperative
β Use client SDK for
infrastructure
β Less opinionated, more
flexibility
Domain-Specific Languages
(DSLs)
β Usually part of a tool
β Declarative
β Often considered
configuration
β More opinionated, less
flexibility
@joatmon08 | 30
Slide 31
Slide 31 text
Exercise: Create a
network and a server
on the network.
Tools: HashiCorp Terraform, Google Cloud Platform
github.com/joatmon08/olt-infrastructure-as-code
@joatmon08 | 31
Slide 32
Slide 32 text
βCleanβ Infrastructure as Code
β Version control
β Linting and formatting
β Naming
β Variables and constants
β Parametrize dependencies
β Keeping secrets
@joatmon08 | 32
Slide 33
Slide 33 text
β
Q&A
@joatmon08 | 33
Slide 34
Slide 34 text
How do I share
infrastructure as
code?
@joatmon08 | 34
Slide 35
Slide 35 text
Modules and Dependencies
Modules
β Subsets of infrastructure
resources
β Grouped by business
domain, function, or
operational scope
Dependencies
β Relationship between a set
of infrastructure resources
β High-level resource depends
on a low-level one.
@joatmon08 | 35
Slide 36
Slide 36 text
Patterns for Modules
β Singleton : all configuration in one place
β Composite: build resources on each other
β Factory : commonly created resources
β Prototype : set of defaults for other modules
β Builder : select resources to build
@joatmon08 | 36
Slide 37
Slide 37 text
Principles for Dependencies
@joatmon08 | 37
Inversion of
Control
High-level
resource calls
low-level
resource
Dependency
Inversion
Use a layer of
abstraction to
pass
attributes
Dependency
Injection
Slide 38
Slide 38 text
Exercise: Refactor a
configuration with
patterns and principles
Tools: HashiCorp Terraform, Google Cloud Platform
github.com/joatmon08/olt-infrastructure-as-code
@joatmon08 | 38
Slide 39
Slide 39 text
β
Q&A
@joatmon08 | 39
Slide 40
Slide 40 text
How do I test
infrastructure as
code?
@joatmon08 | 40
Slide 41
Slide 41 text
@joatmon08 | 41
end-to-end
integration
contract
unit
Testing Strategy
Cost in time, effort, and
resources increase as you
go up the pyramid.
Slide 42
Slide 42 text
@joatmon08 | 42
end-to-end
integration
contract
unit
Testing Strategy
Statically analyzes infrastructure
configuration to verify values defined
match expected changes.
Slide 43
Slide 43 text
@joatmon08 | 43
end-to-end
integration
contract
unit
Testing Strategy
Validate the output of a low-level
dependency matches input to high-level
resource.
Slide 44
Slide 44 text
@joatmon08 | 44
end-to-end
integration
contract
unit
Testing Strategy
Run against one or more resources to
verify changes apply successfully.
Slide 45
Slide 45 text
@joatmon08 | 45
end-to-end
integration
contract
unit
Testing Strategy
Run against entire system to check if it
supports an expected workflow.
Slide 46
Slide 46 text
@joatmon08 | 46
end-to-end
integration
contract
unit
Testing Strategy
manual
Run unique tests, especially
for devices that cannot be
automated.
Slide 47
Slide 47 text
Exercise: Write a unit,
contract, integration,
and end-to-end tests
Tools: HashiCorp Terraform, Google Cloud Platform,
pytest
github.com/joatmon08/olt-infrastructure-as-code
@joatmon08 | 47
Slide 48
Slide 48 text
β
Q&A
@joatmon08 | 48
Slide 49
Slide 49 text
β
Break
@joatmon08 | 49
Slide 50
Slide 50 text
Where does it fit into
my infrastructure
development
lifecycle?
@joatmon08 | 50
Slide 51
Slide 51 text
Delivery Pipeline
Expresses a workflow with a set of stages to build,
test, deploy, and release infrastructure as code.
Its stages can facilitate continuous delivery or
deployment.
@joatmon08 | 51
Slide 52
Slide 52 text
Exercise: Create a
delivery pipeline to
deploy to production
Tools: GitHub Actions
github.com/joatmon08/olt-infrastructure-as-code
@joatmon08 | 52
Slide 53
Slide 53 text
Branching Models
Feature-based
New change?
New branch.
@joatmon08 | 53
Trunk-based
New change?
Push to main branch.
Slide 54
Slide 54 text
Put the steps in order for feature-based
development.
@joatmon08 | 54
Create a branch.
Commit changes
to branch.
Rebase changes
from main to
branch.
Merge changes
from branch to
main.
Slide 55
Slide 55 text
Trunk-based development
@joatmon08 | 55
Commit changes
to local main
branch.
Rebase changes
from remote
main to local
main branch.
Push changes to
remote main
branch.
Slide 56
Slide 56 text
Where should tests go in this feature-based
delivery pipeline?
@joatmon08 | 56
main
branch create
feature
branch
feature
branch
commit
changes
open pull
request
deploy to
testing*
merge pull
request
deploy to
production
unit tests
integration
tests
integration
tests
end-to-end
tests
* Tests for each pull request may run in a separate
environment or a shared testing environment.
Slide 57
Slide 57 text
Where should tests go in this trunk-based delivery
pipeline?
@joatmon08 | 57
main
branch
commit &
push
changes
deploy to
testing
deploy to
production
integration
tests
unit tests
integration
tests
end-to-end
tests
end-to-end
tests
Slide 58
Slide 58 text
β
Q&A
@joatmon08 | 58
Slide 59
Slide 59 text
How do I enforce its
cost, compliance,
and security?
@joatmon08 | 59
Slide 60
Slide 60 text
Infrastructure as code can be...
Secure
β Least privilege
β Protect sensitive information
β Encrypt in-transit and at-rest
β Access logging
β Network access
Industry best practices:
https://ncp.nist.gov/repository
@joatmon08 | 60
Compliant
β Naming
β Tags
β Access control
β Logging
Organization (and regulatory)
standards.
Slide 61
Slide 61 text
Exercise: Write a test
to check infrastructure
as code compliance.
Tools: HashiCorp Terraform, Google Cloud Platform,
pytest
github.com/joatmon08/olt-infrastructure-as-code
@joatmon08 | 61
Slide 62
Slide 62 text
Which is not a valid technique to help you reduce
your infrastructure cost?
A. Tag with an infrastructure expiration date
B. Build a cost estimation test
C. Remove infrastructure across regions
D. Use smaller resource types
E. Renegotiate with your infrastructure provider
@joatmon08 | 62
Slide 63
Slide 63 text
Which is not a valid technique to help you reduce
your infrastructure cost?
A. Tag with an infrastructure expiration date
B. Build a cost estimation test
C. Remove infrastructure across regions
D. Use smaller resource types
E. Renegotiate with your infrastructure provider
@joatmon08 | 63
Slide 64
Slide 64 text
β
Q&A
@joatmon08 | 64
Slide 65
Slide 65 text
How do I rollback
failed changes?
@joatmon08 | 65
Slide 66
Slide 66 text
True or false? Infrastructure as code does not
support rollback.
A. True
B. False
@joatmon08 | 66
Slide 67
Slide 67 text
True or false? Infrastructure as code does not
support rollback.
A. True
B. False
C. Eh, itβs more like roll forward...
@joatmon08 | 67
Slide 68
Slide 68 text
Failed Changes
You want to minimize the blast radius of a failed
change.
This makes it easier to roll forward and localize fixes.
@joatmon08 | 68
Slide 69
Slide 69 text
Rolling βForwardβ
@joatmon08 | 69
New
machine
image fails
application.
Find last
working
machine
image.
Update and
commit last
machine
image.
Unit test.
Deploy to
testing.
Integration
&
end-to-end
test.
Deploy to
production.
Slide 70
Slide 70 text
Canary Deployment
@joatmon08 | 70
Copy production server
configuration.
Paste and
rename to
canary
server.
Set new
image for
canary
server.
Deploy
canary
server.
Send 10%
of requests
to canary
server.
Debug
errors and
problems.
Fix problem, roll out to
production servers.
Delete
canary
server.
* Test or debug changes
Slide 71
Slide 71 text
Blue-Green Deployment
@joatmon08 | 71
Copy blue
network.
Paste and
rename to
green
network.
Test green
network.
Deploy
servers to
green
network.
Direct traffic
to green
servers.
Wait for
regression
test.
Delete blue
network.
* Implement changes with large blast radius.
Slide 72
Slide 72 text
Feature Flags (AKA Feature Toggles)
@joatmon08 | 72
Set variable to
enable_new_network
to false.
Ready to
create a
new
network.
Set variable to
enable_new_network
to true.
* Stage or hide changes during trunk-based development.
Create a
new
network.
Slide 73
Slide 73 text
β
Q&A
@joatmon08 | 73
Slide 74
Slide 74 text
Conclusion
@joatmon08 | 74
Slide 75
Slide 75 text
Recap
β Define & express infrastructure as code
β Write tests for infrastructure as code
β Build a delivery pipeline for infrastructure as
code
β Evaluate the practices and patterns to apply in
an organization
@joatmon08 | 75