Overview¶

You've been hired as a DevOps engineer by Only Cats Incorporated. They're a website that provides only pictures of cats. They've recently noticed that HTTP status codes are getting popular in Google searches, so they're investing in producing a website that showcases their cat pictures combined with HTTP status codes.

It's a critical marketing product for them!

Only Cats Incorporated want to use only the latest, modern DevOps principles and tools. That means our goal will be to build out the AWS based infrastructure using Terraform, provision it using Ansible, and automate it using GitLab CI.

The MVP¶

For now all management want is a basic MVP. They're not looking for a feature complete result at this point in time. They just want to prove it can be done. For now they're just looking for a solution that includes:

• Infrastructure As Code (IAC)
• Configuration As Code (CAC)
• Continuous Integration (CI)
• Continuous Delivery (CD)

They also want a sort of Git workflow: when a change is made to either the IAC, CAC or the application, automation takes over and builds applies the changes for us.

All this means we need to do a few things:

• Design a basic architecture
• Write a simple Golang based application to serve our new HTTP status code cat images
• Write Terraform HCL to build the infrastructure based on the architecture
• Write an Ansible Playbook to configure the compute resources to host our application
• Configure GitLab CI pipelines to react to code changes

And the end result? We can serve our HTTP cats status code images via an AWS backed infrastructure that's built on IAC, provisioned with CAC and automated with CI/CD.

Easy.

The Structure¶

Like most books we have chapters and sub-chapters. And like most computer science related books we have code to write, files to create, procedures to follow, and tasks to get done before progressing. Let's talk about how we've structured the processes and procedures in this book so that you can identify the key parts of each (sub) chapter and make sure you're not missing some important steps.

Code¶

Throughout the book we're going to be writing code. A lot of code. That's somewhat obvious given the tools we'll be working with, but what's not obvious is this book won't make the entire code available for download ahead of time. Instead the reader, the student, is expected to write out the code as they progress through the book. Some might figure this an odd decision, but I think it's best for the learning of the reader.

Having all of the code up front can be overwhelming, so instead let's write out the code as we and get a better, deeper understanding of what's happening.

Languages¶

We'll be writing in a few languages:

• Golang (.go)
• HashiCorp Configuration Language (HCL; .tf)
• Yet Another Markup Language (YAML; .yml or .yaml)

The scope of this book isn't to teach you these languages in depth, with the possible exception of HCL because that's a language that was (originally) built for Terraform.

Presenting the Code¶

Because we'll be writing a lot of code there is a certain convention I've used to organise my thinking around the code and present it to you. For each chapter that involves writing code, and that's pretty much all of them, there will be a sub-chapter called, "Source Files".

The "Source Files" section is then broken down into further sub-sections, each talking about, describing and finally presenting you with the code for each individual file we'll be producing, no matter how simple or small it is. Here's an example...

We'll be writing a lot of Terraform code, so the Terraform chapter has a sub-chapter called "Source Files". There's a further sub-chapter called main.tf which talks about the main.tf file. Simple enough. Let's talk about how these pages are then further broken down.

File Details¶

At the top of each page that discusses a particular code file you'll find a table like this:

This table gives us the information we need to completely understand what file it is we're about to discuss, where it can be found inside of the repository and indeed what repository to locate it in.

The "Why?"¶

Each page that discusses source code will cover the "Why?" of the code - "Why are we writing this?" This, in turn, will also cover what the code does, the problem is solves, allowing you to understand what you can expect from the code.

Breakdown¶

This section of each source code page will breakdown the code and discuss important bits of it in detail.

Sometimes this section won't go over the entire file, from top to bottom. Instead it might just focus on a few points of interest to help you understand what's happening and then present you with the solution (below.)

The Solution¶

When writing out code, whether it's Terraform, Go, etc., there will be a section in that (sub) chapter called "The Solution". This section will give you the final code and describe a few things you need to do, such as...

1. Which Git repository to start working in
2. What filename to use when creating the source file
3. What code to place in that file, which can be copy/pasted if you so desire
4. Committing the code to the Git repository and pushing the changes

Committing Code¶

Once you have the solution and you've written it to disk, inside of your repository, this section of the page will remind you to commit your work and demonstrate how-to commit the specific file you've been reading about.