INFRASTRUCTURE AS CODE kief@thoughtworks.com Cloud Practice Lead - - PowerPoint PPT Presentation

▶
infrastructure as code kief thoughtworks com cloud
SMART_READER_LITE
LIVE PREVIEW

INFRASTRUCTURE AS CODE kief@thoughtworks.com Cloud Practice Lead - - PowerPoint PPT Presentation

Feb 03, 2023 574 likes •979 views

INFRASTRUCTURE AS CODE kief@thoughtworks.com Cloud Practice Lead (UK) DevOps, Continuous Delivery, Agile Ops Twitter: @kief Book: http://oreil.ly/1JKIBVe Site: http://infrastructure-as-code.com June 2016 AGENDA CONTEXT Motivations

slide-1
SLIDE 1

INFRASTRUCTURE AS CODE

slide-2
SLIDE 2

kief@thoughtworks.com Cloud Practice Lead (UK)

DevOps, Continuous Delivery, Agile Ops Twitter: @kief Book: http://oreil.ly/1JKIBVe Site: http://infrastructure-as-code.com

June 2016

slide-3
SLIDE 3

AGENDA

CONTEXT

  • Motivations
  • Challenges

INFRASTRUCTURE AS CODE

  • Key Practices
  • Simple Pipeline
  • Scaling Pipelines
slide-4
SLIDE 4

SPEED

Get something to market quickly Iterate it Continuously improve it

slide-5
SLIDE 5

TECHNOLOGY

Cloud, automation, etc. lowers barriers for making changes

slide-6
SLIDE 6

DANGER

Security Performance Stability Compliance Maintainability

slide-7
SLIDE 7

SECRET

High quality services rely on the ability to make changes quickly

slide-8
SLIDE 8

GOAL

Be able to make changes Rapidly, Frequently, and Responsibly

slide-9
SLIDE 9

CHALLENGES

slide-10
SLIDE 10

SERVER SPRAWL

Creating new servers is the easy part

slide-11
SLIDE 11

CONFIGURATION DRIFT

Servers start

  • ut identical

But changes accumulate

  • ver time
slide-12
SLIDE 12

AUTOMATION FEAR CYCLE

slide-13
SLIDE 13

INFRASTRUCTURE AS CODE

“Applying software engineering tools and practices to infrastructure”

slide-14
SLIDE 14

UNATTENDED AUTOMATION

Tools run on a schedule to apply, re-apply, and update configuration

BENEFITS OF UNATTENDED:

  • Discover problems quickly
  • Force yourself to fix those

problems

  • Force yourself to improve

your tools and processes

  • Discourages “out of band”

changes

slide-15
SLIDE 15

AUTOMATE SERVER UPDATES

Automation isn’t just for new servers! Configuration synchronization Run Chef, Puppet, Ansible, etc. on a schedule Immutable servers Apply changes by rebuilding servers Containerized servers Apply changes by deploying new container instances

slide-16
SLIDE 16

RE-USE & PROMOTE DEFINITIONS

Re-use the same definition files across environments for a given application or service

DEV STAGE PROD Playbooks, Cookbooks, Manifests, templates, etc.

slide-17
SLIDE 17

TEST INFRASTRUCTURE CHANGES

Preventing DevOops

INFRA TEST DEV TEST PROD

slide-18
SLIDE 18

PIPELINES

Using Continuous Delivery pipelines to manage infrastructure

slide-19
SLIDE 19

WHAT?

Terraform, Puppet, etc. Changes are made and committed to VCS Tools are run on agents to apply changes to environments Changes are only promoted after passing tests & authorization

slide-20
SLIDE 20

WHY?

Validates changes to infrastructure before applying them to production Confidence for frequent, small improvements to infrastructure Limit direct changes to infrastructure

slide-21
SLIDE 21

TESTING

Correctness Security policies Performance Stability

slide-22
SLIDE 22

GOVERNANCE

The process for applying changes is auditable Changes can be traced back to commits Automation ensures processes are followed Authorization can be required as needed

slide-23
SLIDE 23

SIMPLE

An example with a fairly simple environment

slide-24
SLIDE 24

VPC Subnet

10.0.0.0/16

Security Group

1.1.1.0/16 -> :443

DEFINING A SIMPLE ENVIRONMENT

ANSIBLE PLAYBOOK Server configuration TERRAFORM FILE Environment structure APPLICATION SOURCE Deployable application

slide-25
SLIDE 25

SIMPLE PIPELINE DESIGN

BUILD STAGE TEST STAGE QA STAGE PROD STAGE

Application Ansible Terraform

Deploy application, configuration, and infrastructure

slide-26
SLIDE 26

SCALING

Handling more complex infrastructure

slide-27
SLIDE 27

ALIGN INFRASTRUCTURE DESIGN TO TEAMS

Ensure teams can make the changes they need easily and safely

slide-28
SLIDE 28

COMPLEX ENVIRONMENTS

Infrastructure involving multiple teams

slide-29
SLIDE 29

FAN-IN PIPELINE

ServiceA ServiceB ServiceC SYSTEM TEST QA PROD BUILD BUILD BUILD

SERVICE

TEST

SERVICE

TEST

SERVICE

TEST

slide-30
SLIDE 30

DECOUPLED PIPELINES

ServiceA TEST BUILD ServiceB TEST BUILD ServiceC TEST BUILD QA PROD QA PROD QA PROD

slide-31
SLIDE 31

DEPENDENCIES

ServiceA TEST BUILD ServiceB QA PROD TEST BUILD QA PROD Create test instance of provider Implement Consumer Driven Contract (CDC) Tests Use mocks and stubs

slide-32
SLIDE 32

ISSUE: DUPLICATION

Multiple teams using similar systems, e.g. database clusters

slide-33
SLIDE 33

RE-USE BY FORKING DEFINITIONS

Disadvantages:

  • Divergence and

Inconsistency Advantages:

  • Avoid tight coupling
  • Handles diverse requirements
slide-34
SLIDE 34

RE-USE WITH DEFINITION LIBRARIES

Challenges:

  • Avoid tight coupling, so teams

aren’t blocked when making changes

  • Ownership of code shared by

multiple teams Guidance:

  • Use separate pipelines for

each

  • Use CDC & other dependency

testing strategies

slide-35
SLIDE 35

LIBRARY PIPELINE

Server AMI BUILD Service TEST BUILD TEST

Test shared definitions before pulling them into dependent pipelines

slide-36
SLIDE 36

ISSUE: SHARED ELEMENTS

LOAD BALANCER

ServiceA VIP ServiceB VIP Shared infrastructure definitions Service-specific infrastructure definitions

slide-37
SLIDE 37

SHARING ELEMENTS

Avoid monoliths - optimize to simplify making changes

slide-38
SLIDE 38

OUTCOMES

  • Quickly provision and

evolve infrastructure

  • Effortlessly roll out fixes
  • Keep systems consistent

and up to date

  • Spend time on high value

work

slide-39
SLIDE 39

Book: http://oreil.ly/1JKIBVe Site: http://infrastructure-as-code.com Twitter: @kief

kief@thoughtworks.com Cloud Practice Lead (UK)

DevOps, Continuous Delivery, Agile Ops