Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Infrastructure as Code - Getting Started, Concepts & Tools


Published on

An Infrastructure as Code presentation for vBrownBag

Published in: Software
  • Be the first to comment

  • Be the first to like this

Infrastructure as Code - Getting Started, Concepts & Tools

  1. 1. Infrastructure as Code Getting Started, Concepts & Tools Lior Kamrat
  2. 2. Hi, my name is Lior Kamrat (AKA “Leo” or LK) • Azure Cloud Solutions Architect @ Microsoft • I used to work @ VMware • Double VMware VCDX #230 for both CMA & DCV • Virtual Design Master Panelist • POP! Funko Collector • I blog at • I tweet @LiorKamrat
  3. 3. Disclaimer: Please forgive me about all this “Buzzword Bingo” you are about to witness. It will be technical, with demos, I promise! Also, this is not a Terraform brownbag, we have one coming next month as part of the “API Zero to Hero” vBrownbag track.
  4. 4. Our menu for today… • The “Iron & Cloud Age” of IT • What is Infrastructure as (from) Code? • Tooling Categories • Packer Demo • Mutable & Immutable Infrastructure • Imperative Code vs. Declarative Code • Terraform Provisioning Demo • A word about the desired state • IaC Stack Deployment Approach • The Major (cross-platform) Players • Terraform vs. All The REST • Terraform Enforcement Demo • Good vs. Evil
  5. 5. The Iron (or bronze) Age • Around 1200 BC and 600 BC, depending on the region you were at. • Dominant toolmaking material was iron. The Iron Age of IT • In the “iron age” of IT, systems were directly bound to physical hardware. • Provisioning and maintaining infrastructure was manual work, forcing teams to spend their time pointing, clicking, and typing to keep the gears turning. • Because changes involved so much work, change management processes forced careful up-front consideration, design, and review work. Getting it wrong was expensive!
  6. 6. The “Cloud Age” of IT • Where all the cool kids are now “DevOps” • When you no longer “script”, you just “code” Enters “Infrastructure as Code”… • Apps have been decoupled from the physical hardware. • Routine provisioning and maintenance can be delegated to software systems, freeing the humans from drudgery. • Changes can be made in minutes, if not seconds. • Change management can exploit this speed, providing better reliability along with faster release cycles.
  7. 7. What Is Infrastructure as (from) Code? • Infrastructure as code (IaC) is an approach to infrastructure automation based on practices from software development. • It emphasizes consistent, repeatable routines for provisioning and changing systems and their configuration. • Changes are made to definitions and then rolled out to systems through unattended processes that include thorough validation.
  8. 8. Tooling Categories Ad Hoc Scripts Configuration Management (CM) Tools Server Templating Tools Server Provisioning Tools
  9. 9. Ad-Hoc Scripts • The most straightforward approach to automating anything is to write an ad hoc script. You take manual work and break it down into steps Choose your favorite scripting language Define and write each of those steps in code Execute that script
  10. 10. Configuration Management Tools • Chef, Puppet, Ansible, and SaltStack are all configuration management tools, designed to install and manage software on existing servers. • Coding conventions – Consistent & predictable structure, file layout, clearly named parameters, secrets management, etc. • Idempotent Code – Continuously executing the same code repeatedly while producing the same result. • Distribution – Unlike ad hoc scripts, CM tools are designed specifically for managing large numbers of remote servers.
  11. 11. Server Templating Tools • Growing in it’s popularity, are server templating tools such as Docker, Packer, and Vagrant. • 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. • And move on to your deployment step in your pipeline… • Server templating is a key component of the shift to immutable infrastructure. Server Image Container Image
  12. 12. Servers (or “resources”) Provisioning Tools • Provisioning tools such as Terraform, Azure Resource Manager Templates, AWS CloudFormation and OpenStack Heat are responsible for creating your servers. • You can use this tools not only create servers, but also other resources such as databases, load balancers, firewall settings, storage, etc. • Multi-Platform And so much more…
  13. 13. Demo Time! Capture Azure VM Image
  14. 14. Mutable & Immutable Infrastructure Mutable Infrastructure • Infrastructure will be continually updated, patched and tuned to meet the ongoing needs of the purpose it serves. • CM tools such as Chef or Puppet typically default to a mutable infrastructure paradigm. • Over time, as you apply more and more updates, each server builds up a unique history of changes. • As a result, each service becomes slightly different than all the others, leading to configuration drift and can result to bugs which can be difficult to diagnose and reproduce. App 1.0 Service 1.0 Service 1.0 Service 1.0 Service 1.0 Service 1.0 Service 1.0 Service 1.0 Service 1.0 Service 1.0 App – Configuration Drift Service 1.0 Service 1.0 Service 1.0 Service 1.1 Service 1.0 Service 1.0 Service 1.0 Service 1.0 Service 0.9
  15. 15. Mutable & Immutable Infrastructure Immutable Infrastructure • Using Terraform to deploy machine images created by Docker or Packer, result “changes” to be deployments of a completely new app version. • Reduces the likelihood of configuration drift bugs, makes it easier to know exactly what software is running on each server. • Automated testing are more effective, as an immutable image that passes your tests in the test environment is likely to behave exactly the same way in the production. • Blue / Green App 1.0 Service 1.0 Service 1.0 Service 1.0 Service 1.0 Service 1.0 Service 1.0 Service 1.0 Service 1.0 Service 1.0 App 2.0 Service 2.0 Service 2.0 Service 2.0 Service 2.0 Service 2.0 Service 2.0 Service 2.0 Service 2.0 Service 2.0
  16. 16. Mutable & Immutable Infrastructure App 1.0 Service 1.0 Service 1.0 Service 1.0 Service 1.0 Service 1.0 Service 1.0 Service 1.0 Service 1.0 Service 1.0 App 2.0 Service 2.0 Service 2.0 Service 2.0 Service 2.0 Service 2.0 Service 2.0 Service 2.0 Service 2.0 Service 2.0 App 1.0 Service 1.0 Service 1.0 Service 1.0 Service 1.0 Service 1.0 Service 1.0 Service 1.0 Service 1.0 Service 1.0 App – Configuration Drift Service 1.0 Service 1.0 Service 1.0 Service 1.1 Service 1.0 Service 1.0 Service 1.0 Service 1.0 Service 0.9 Mutable Immutable• The Pets and Cattle debate. • One approach is not necessary better then the other, it depends on your use-case. • With the mutable approach, the team needs to be aware of the infrastructure “history”. • Generally speaking, the immutable approach is better for stateless applications. • Immutable drives no deviation and no changes. It is what it is.
  17. 17. Imperative Code vs. Declarative Code My house is #9 and will be on the right Leave the house Get in the the car Drive straight on Morty Blvd. for 3km Turn right on Rick street and drive for 5 blocks AKA “The How” Imperative (procedural): Defines specific commands that need to be executed in the appropriate order to end with the desired conclusion. 1 2 3 4 5
  18. 18. Imperative Code vs. Declarative Code My address is: 9 Rick Street, Tel-Aviv Israel 4580800 AKA “The What” Declarative (functional): Defines the desired state and the system executes what needs to happen to achieve that desired state.
  19. 19. A word about the desired state Example: Ansible Playbook Example: Terraform Plan 15 Servers 10 Servers
  20. 20. Demo Time! Provision Azure VM with Terraform
  21. 21. IaC Stack Deployment Approach Push Masterless Agentless Pull Master Agent
  22. 22. Pull / Master / Agent Pros: • Central place where you can manage the status of your infrastructure. • Some tools provide a web interface for the master server. • Puppet Enterprise (PE) console • Chef management console • Scalability Cons: • Requires a daemon to be installed on all machines and a central authority to be setup. • Extra infrastructure • Maintenance • Security • Difficult to manage – moving parts, availability, etc. Chef Client Chef Server Target servers installed with Chef agent
  23. 23. Push / Masterless / Agentless • A client contacts the nodes and sends updates as they are needed. • When a change is made to the infrastructure, each node is alerted of this and then run the changes. Pros • Simple to manage and setup Cons • No central control plane Terraform Client API Calls
  24. 24. The Major (cross-platform) Players Tool Tool Type Infrastructure Architecture Approach Manifest Written Language Configuration Management Mutable Pull Declarative Domain Specific Language (DSL) & Embedded Ruby (ERB) Configuration Management Mutable Pull Declarative & Imperative Ruby Configuration Management Mutable Push Declarative & Imperative YAML Configuration Management Mutable Push & Pull Declarative & Imperative YAML Provisioning Immutable Push Declarative HashiCorp Configuration Language (HCL)
  25. 25. Terraform vs. All The REST • Cloud-Agnostic (well, kinda…) • The “terraform plan” command • State Management • Terraform Modules • HashiCorp Configuration Language (HCL) • There is more… As part of the vBrownbag “API Zero to Hero” series, Byron Schaller & myself will run the “Exploring Terraform APIs” session next month.
  26. 26. Demo Time! Azure Security Enforcement with Terraform
  27. 27. Good vs. Evil To support and enable change Changes to systems are routine Invest time on valuable things Users can define, provision, and manage the resources they need Easily and quickly recover from failures Improvements are made continuously Solutions are implemented and constantly being tested Being an obstacle or a constraint Drama or stress for users or IT Spend time on repetitive tasks IT staff dependency Running like headless chickens Expensive patching and risky “big bang” projects Talk about solutions in meetings and documents
  28. 28. Thanks & Happy coding!