Infrastructure as Code - Getting Started, Concepts & Tools
•Als PPTX, PDF herunterladen•
1 gefällt mir•2,343 views
An Infrastructure as Code presentation for vBrownBag
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Infrastructure as Code - Getting Started, Concepts & Tools
Ähnlich wie Infrastructure as Code - Getting Started, Concepts & Tools (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Infrastructure as Code - Getting Started, Concepts & Tools
- 1. Infrastructure as Code Getting Started, Concepts & Tools Lior Kamrat
- 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 imallvirtual.com • I tweet @LiorKamrat
- 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. 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. 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. 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. 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. Tooling Categories Ad Hoc Scripts Configuration Management (CM) Tools Server Templating Tools Server Provisioning Tools
- 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. 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. 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. 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. Demo Time! Capture Azure VM Image
- 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. 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. 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. 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. 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. A word about the desired state Example: Ansible Playbook Example: Terraform Plan 15 Servers 10 Servers
- 20. Demo Time! Provision Azure VM with Terraform
- 21. IaC Stack Deployment Approach Push Masterless Agentless Pull Master Agent
- 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. 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. 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. 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. Demo Time! Azure Security Enforcement with Terraform
- 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
Hinweis der Redaktion
- For those of you who are interested in history, you know that there was an age in history called “The Iron or the Bronze Age” somewhere around 1200 BC and 600 BC, depending on the region. The dominant toolmaking material was iron – Weapons, jewelries, cookware, etc.
- The great thing about ad hoc scripts is that you can use popular, general-purpose programming languages and you can write the code however you want. The terrible thing about ad hoc scripts is that you can use popular, general-purpose programming languages and you can write the code however you want.
- Coding conventions – Enforces a consistent, predictable structure, including documentation, file layout, clearly named parameters, secrets management, and so on. Idempotence Code that works correctly no matter how many times you run it is called idempotent code. Writing an ad hoc script that works once isn’t too difficult; writing an ad hoc script that works correctly even if you run it over and over again is a lot harder. Distribution – Ad hoc scripts are designed to run on a single, local machine. Puppet and other configuration management tools are designed specifically for managing large numbers of remote servers.
- The idea behind server templating tools is to 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.
- “Every other aspect of your platform” – Since this depended on terraform providers which are open-sourced, not every resource or platform out there is available.
- A word about Packer vs. Docker build Packer builds Docker containers without the use of Dockerfiles. By not using Dockerfiles, Packer is able to provision containers with portable scripts or configuration management systems that are not tied to Docker in any way. It also has a simple mental model: you provision containers much the same way you provision a normal virtualized or dedicated server.
- For example, if you tell Chef to install a new version of OpenSSL, it’ll run the software update on your existing servers and the changes will happen in place. Mutable Infrastructure Essentially, it means the infrastructure will be continually updated, tweaked, and tuned to meet the ongoing needs of the purpose it serves. Configuration management tools such as Chef, Puppet, Ansible, and SaltStack 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 server becomes slightly different than all the others, leading to subtle configuration bugs that are difficult to diagnose and reproduce.
- Using the term “immutable” to describe this pattern can be misleading. “Immutable” means that a thing can’t be changed, so a truly immutable server would be useless. As soon as a server boots, its runtime state changes—processes run, entries are written to logfiles, and application data is added, updated, and removed. It’s more useful to think of the term “immutable” as applying to the server’s configuration, rather than to the server as a whole. This creates a clear line between configuration and data. It forces teams to explicitly define which elements of a server they will manage deterministically as configuration and which elements will be treated as data. A good example will be this days mobile phones that have batteries that cannot be replaced. So instead of upgrading devices in the field, those devices are now immutable and the whole device needs to be replaced. This provides a level of consistency that makes support easier. Immutable Infrastructure If you’re using a provisioning tool such as Terraform to deploy machine images created by Docker or Packer, then most “changes” are actually deployments of a completely new app version. Since every deployment uses immutable images on fresh servers, this approach reduces the likelihood of configuration drift bugs, makes it easier to know exactly what software is running on each server. It also makes your automated testing 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 environment. Blue-green deployment is a technique that reduces downtime and risk by running two environments, usually representing different application version and also called Blue and Green.
- Pets Servers that are treated as indispensable or unique systems that can never be down. Typically they are manually built, managed, and “hand fed”. Cattle Arrays of servers, that are built using automated tools, and are designed for failure, where no one, two, or even three servers are irreplaceable.
- Imperative (Procedural) is the “how”. It’s a historical approach which uses the “I don’t trust you, give me the actions” parameters in explicit steps. Procedural code does not fully capture the state of the infrastructure: Reading through Ansible templates is not enough to know what’s deployed. You’d also have to know the order in which those templates were applied. Had you applied them in a different order, you might have ended up with different infrastructure. You have to know the full history of every change that has ever happened. Procedural code limits reusability: The reusability of procedural code is inherently limited because you have to manually take into account the current state of the infrastructure. Since that state is constantly changing, code you used a week ago may no longer be usable because it was designed to modify a state of your infrastructure that no longer exists. As a result, procedural codebases tend to grow large and complicated over time.
- Declarative (Functional) is “the what. “This is what I need, I can’t be bothered telling you how to get there” parameters. The how is handled by the interpreter/engine not the administrator. The sys admin describes a desired end state and the tool attempts to reach it. Regardless of how I get to your house, what really matters is the car I drive. Am I going to drive an imperative stick shift car or a declarative automatic car. Enough metaphors? Before we dive into code, it’s important to realize that many declarative approaches have some sort of imperative abstraction layer. An automatic car has some sort of abstraction layer over shifting gears.
- With Terraform declarative approach, the code always represents the latest state of your infrastructure. At a glance, you can tell what’s currently deployed and how it’s configured, without having to worry about history or timing. This also makes it easy to create reusable code, as you don’t have to manually account for the current state of the world. Instead, you just focus on describing your desired state.
- Pull / Master / Agent The server being provisioned (node) runs an agent (daemon) that asks a central authority (master) if/when it has any updates that it should run. Requires a daemon to be installed on all machines and a central authority to be setup. Pros: Central place where you can see and manage the status of your infrastructure. Some tools provide a web interface (Chef Console, Puppet Enterprise Console) for the master server. Scalability Cons: Extra infrastructure Maintenance Security Difficult to manage – moving parts, availability
- Pull / Master / Agent The server being provisioned (node) runs an agent (daemon) that asks a central authority (master) if/when it has any updates that it should run. Requires a daemon to be installed on all machines and a central authority to be setup.
- Terraform in Atlas
- Modules in Terraform are self-contained packages of Terraform configurations that are managed as a group. Modules are used to create reusable components in Terraform as well as for basic code organization.