Infrastructure as Code - Getting Started, Concepts & Tools

Editor's Notes

• #6: 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.
• #10: 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.
• #11: 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.  
• #12: 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.
• #13: “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.
• #14: 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. 
• #15: 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.
• #16: 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.
• #17: 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. 
• #18: 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.
• #19: 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.
• #20: 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.
• #22: 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
• #23: 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.
• #24: Terraform in Atlas
• #27: 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.