4. » 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
5. » Client Server Architecture
» Easy to propagate
configuration changes.
» Instances mostly look
identical.
» Long running server.
» Can face issues of
Configuration drift.
Configuration Management Tools
8. » Infrastructure Provisioning.
» Configuration of new
instances.
» Delays at server runtime for
server configuration.
» Possible failure of server
configuration at runtime.
Challenges in the Cloud
13. » Declarative style for infrastructure as code
» Supports multiple cloud providers
» Easier to adopt for new teams
» Open source
» Under active development
Why Terraform
15. » Sample web app on EC2 instance
» AMI for spring-boot-app
Demo
16. » 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?
17. » 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
22. » Supporting multiple environments
⋄ Per environment tfstate (recommended)
⋄ Keep state as minimum as possible
⋄ Read only state
⋄ Use profiles
Demo
23. » Using modules to dry out Terraform code
⋄ Relative modules
⋄ Terraform Variables
⋄ Modules with versions
Demo
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.
Simple instance without name
Add name incrementally
Add security group