Immutable
Infrastructure with
Terraform
- Prashant Kalkar & Rahul Baphana
(Expert Talk - Pune - 9 June 2017)
1.
DevOps Journey
Limited hardware, manually managed.
On Premise Hardware
» Limited hardware
» Configured generally once.
» Long running.
» Servers might not look identical.
» Change propagation requires changes in all the
server instances.
» Manageable with small no of servers.
On-Prem Hardware
» Client Server Architecture
» Easy to propagate
configuration changes.
» Instances mostly look
identical.
» Long running server.
» Can face issues of
Configuration drift.
Configuration Management Tools
1.1
Rise of Clouds
» Elastic
» Disposable resources.
» On-demand
» Cost effective
Cloud properties
» Infrastructure Provisioning.
» Configuration of new
instances.
» Delays at server runtime for
server configuration.
» Possible failure of server
configuration at runtime.
Challenges in the Cloud
2
Immutable Infrastructure
Machine Image /
Container
Ubuntu
Chef / Puppet
client
Manages
EC2 Instances
Configuration
Management Tool
App artifact
Java
Tomcat
Logstash client
Mutable Infrastructure
Machine Image /
Container
Ubuntu
Server Templating Tools App artifact
Java
Tomcat
Logstash client
EC2 Instances
Chef / Puppet
client
Manages
EC2 Instances
Configuration
Management Tool
App artifact
Java
Tomcat
Logstash client
Immutable Infrastructure
3
Terraform
» Declarative style for infrastructure as code
» Supports multiple cloud providers
» Easier to adopt for new teams
» Open source
» Under active development
Why Terraform
3.1
Terraform Demo
» Sample web app on EC2 instance
» AMI for spring-boot-app
Demo
» No client-server
» Terraform tfstate (show command)
» Resource dependency & Parallel Execution
» Terraform failures
» Incremental changes
» Non-managed infrastructure is invisible to Terraform
How Terraform is working?
» Remote state
» State locking
» Practices :
⋄ Use centralise server to apply Infrastructure changes
⋄ Always apply Terraform on a pushed code base
⋄ Branches or no branches?
Using Terraform in a team
» Rolling deployments
» Output variables
Demo
Launch
Config-1
Rolling
Deployment
Launch
Config-1
Launch
Config-2
Rolling
Deployment
Launch
Config-2
Rolling
Deployment
» Supporting multiple environments
⋄ Per environment tfstate (recommended)
⋄ Keep state as minimum as possible
⋄ Read only state
⋄ Use profiles
Demo
» Using modules to dry out Terraform code
⋄ Relative modules
⋄ Terraform Variables
⋄ Modules with versions
Demo
THANKS!
Any questions?

Immutable infrastructure with Terraform

Editor's Notes

  • #4 Limited hardware They are generally configured once with required applications. Once created test to use them for long period of time. Long running servers - Need to keep them running. Instances might not look identical.
  • #16 Simple instance without name Add name incrementally Add security group
  • #17 Failures : Availability zone failure in demo 03
  • #19 Environments
  • #23 Demo for variables Environment tfstate
  • #24 Modules in Environments