Integrating Infrastructure as Code Into a Continuous Delivery Pipeline

We’re here to talk about integrating infrastructure as code into a continuous delivery pipeline. We’ll start by defining infrastructure as code then explain some of the problems it solves. 

Defining Infrastructure as Code (IaC)

Infrastructure as code (IaC) is the approach that takes proven coding techniques used by software systems and extends them to infrastructure. Later in the post, we’re going to cover in more detail what those techniques are.

Challenges Without IaC

Before we get to what the actual techniques that comprise IaC are, it’s important to cover some of the challenges and problems it’s meant to solve.

• Configuration Drift. If you’re provisioning servers manually it’s pretty much a given that, at some point, they’ll get out of sync.
  
  
• Snowflake servers. That’s the consequence of the last point. When configurations get out of sync, you end up having “snowflake” servers. That is, servers that are unique, hard to replicate, and no one knows how to manage them.
  
  
• Human error. If you don’t have things in version control people will make mistakes, and it’s going to be hard to identify who made the mistake as well as rolling it back to a previous good point.
  
  
• Time to complete. Manually provisioning servers is a slow process.

Continuous Delivery

Let’s now define “continuous delivery.” But instead of coming up with a definition myself, let’s use the definition by Jez Humble, author of Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, released in 2010:

Continuous delivery is the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way.

With continuous delivery, we’re able to achieve a Single Piece Flow: that means taking a single piece of functionality, or a bug fix, and taking it from the start to the production environment. That way, problems are caught earlier in the process.

Considerations & Best Practices

We’re now going to cover some of the considerations and best practices mentioned before.

Source Control

Everything should be in source control. Not only the production code, but also the provisioning code, CI job definitions, etc.

Code Accessibility

This point is a consequence of the next one. If everything is in source control, it means that it’s accessible by everyone in the organization.

Modularize

You should modularize your infrastructure code, and version the modules of your infrastructure code.

Collaboration

All of the points above enable and encourage collaboration.

Code and Test as Documentation

You should use the code itself and its tests as documentation, instead of relying on offline documentation that easily gets out of sync.

Security Patterns

Now let’s turn our focus to some of the main security patterns of IaC.

• CIS benchmark automation. If you’re writing Docker files or creating Docker containers, CIS has some benchmarks and scripts out of the box you can run to check for security issues.
  
  
• Building hardening policies around your infrastructure code, so when you’re provisioning them you know they are secure.
  
  
• Static scanning. Adopt static scanning, both as part of your pipeline but also as part of your code.

Security Considerations

Let’s now look at some important security considerations.

• Dynamic scanning: these are tests that are run dynamically against the production environment.
  
  
• Secrets management. Everyone has secrets that they need to manage, such as AWS keys. There are tools available to help you manage those.
  
  
• Artifact signing and verification. If you generate and consume docker images, it’s important to get them signed, so you can later verify they’re the true artifact.

Compliance

Compliance is a concern, especially in highly regulated industries, such as finance and health-care. But even if you’re not in these industries, you also have to care about regulations such as GDPR. The recommendation here is to treat compliance as code, instead of having to rely on paperwork.

Tools you can use to help you include Chef InSpec, and HashiCorp Sentinel.

Summary

It’s now time for a quick recap of what we’ve seen.

We started out by defining IaC (infrastructure as code), explaining that it means applying effective coding techniques to infrastructure. We’ve also explained the problems which IaC solves. After that, we’ve presented the definition of CD (continuous delivery.)

Then, we proceeded to cover considerations and best practices when it comes to IaC, covering concepts like version control, modularization, and code as documentation.

After that, we’ve turned our focus to security, covering patterns and considerations. At last, we’ve covered compliance, explaining why it’s important and sharing some tools recommendations.

You can check out Adarsh Shah’s talk “Integrating Infrastructure as Code into a Continuous Delivery Pipeline” below.