This is a book is a catalog of DevOps tools. It's full of real-world hands-on examples, and each chapter will dive into a different tool or process. At the end of each, you'll be able to say, “now I know what this is about, and now I can make a decision whether it is a worthwhile investment.”

The DevOps Toolkit: Catalog, Patterns, And Blueprints

Preface

Unlike my other books where I typically dive into a single tool or a single process, this time, I chose a different approach. Instead of going to great lengths trying to help someone become proficient in one thing, this time, I am trying to give you a quick introduction into many different tools and processes. We will skip the potentially lengthy discussions and in-depth exercises. What I want, this time, is to help you make decisions. Which tool works the best for a given task? What should we explore in more depth, and what is a waste of time? The goal is not to learn everything about a tool in detail but rather to dive into many concepts and a plethora of tools right away. The aim is to get you up-to-speed fast while producing useful “real world” results. Think of each chapter as a crash-course into something with the outcome that you can use right away.

Introduction

You might have already used one of the tools to manage your infrastructure as code. That might have been Terraform, or something else. Or, maybe you didn’t. If that’s the case, you might be wondering if there is anything wrong with creating your cluster through a browser-based console provided by your hosting vendor. The short answer is “yes”. It’s very wrong.

Infrastructure as Code (IaC)

Since we already had a brief overview of Terraform, we’ll skip the potentially lengthy introduction and go straight into the exercises. That will help you make a decision whether Terraform is the right choice for managing resources in Google Cloud Platform (GC) and give you sufficient base knowledge that you’ll be able to extend on your own.

Creating And Managing Google Kubernetes Engine (GKE) Clusters With Terraform

The goal of this book is to guide you through decisions. It aims to get you up-to-speed fast with a technology or a process. Since we already had a brief introduction into Terraform, we’ll skip the potentially lengthy introduction and go straight into the exercises. That will help you make a decision whether Terraform is the right choice and give you sufficient base knowledge that you’ll be able to extend on your own.

Creating And Managing AWS Elastic Kubernetes Service (EKS) Clusters With Terraform

Creating And Managing Azure Kubernetes Service (AKS) Clusters With Terraform

There is more material about this subject waiting for you on the YouTube channel The DevOps Toolkit Series . Please consider watching one of the videos that follow, and bear in mind the list will likely grow over time.

There Is More About Infrastructure as Code (IaC)

A long time ago in a galaxy far, far away… we were copying files into servers. That wasn’t that bad, mostly because our needs were relatively simple. We’d had a couple of servers, we were releasing once a year (or even less frequently), and we did not worry that much about many of the things that we consider bare minimum today. If we were advanced enough, we might go crazy and create a ZIP file with all the files we’d need, use SSH to copy them to servers, and uncompress them. That was about it. That’s what we did, and that worked just fine. But that was many years ago. You, dear reader, might not have been even born at that time.

Packaging, Deploying, And Managing Applications

Every operating system has at least one packaging mechanism. Some Linux distributions use RPM or APT. Windows uses Chocolatey, and macOS uses Brew. Those are all package mechanisms for operating systems. But why does that matter in the context of Kubernetes?

Using Helm As A Package Manager For Kubernetes

There Is More About Packaging, Deploying, And Managing Applications

This might be an excellent place to take a break from infrastructure, Kubernetes, Helm, and other topics we explored previously. This time, we will create a productive local development environment.

Setting Up A Local Development Environment

Serverless computing is the future. Or, maybe, it’s just the hype. It’s hard to tell right now, mostly because we do not yet know what serverless is. For some, it is about developing functions (nano services?). For others, it is about not worrying about infrastructure. Some claim that serverless is all about reducing cost, while some say that it is about scalability.

Exploring Serverless Computing

We will not go into a detailed explanation of what managed Functions as a Service (FaaS) means. We already explained it briefly, and you are soon going to get a hands-on experience that will likely provide more insight than any theory would. For now, just remember that we are focused on managed services, which are those maintained by others, and that we are exploring FaaS defined as “give me code as input.” Other serverless flavors might come later.

Using Managed Functions As A Service (FaaS)

Using Managed Containers As A Service (CaaS)

We already explored a few Containers as a Service solutions. We saw the pros and cons of using AWS ECS with Fargate, Azure Container Instances, and Google Cloud Run. All those solutions were managed CaaS. They are provided and managed by other vendors. When using them, we do not need to think about the underlying infrastructure, services, plumbing, scaling, and other things not directly related to developing applications. By using managed CaaS, we are externalizing most of the work required for the successful deployment and management of our applications.

Using Self-Managed Containers As A Service (CaaS)

There Is More About Serverless

A long time ago in a galaxy far, far away… We used to store logs in files. That wasn’t so bad when we had a few applications, and they were running on dedicated servers. Finding logs was easy given the nature of static infrastructure. Locating issues was easy as well when there was only an application or two. But times changed. Infrastructure grew in size. Now we have tens, hundreds, or even thousands of nodes. The number of applications increased as well. More importantly, everything became dynamic. Nodes are being created and destroyed. We started scaling them up and down. We began using schedulers, and that means that our applications started “floating” inside our clusters. Everything became dynamic and volatile. Everything increased in size. As a result, “hunting” logs and going through endless entries to find issues became unacceptable. We needed a better way.

Using Centralized Logging

Almost everything we do ends up with a deployment of an application or a suite of apps. Today, that looks like an easy task. Virtual machines and, later on, Cloud greatly simplified deployments, and Kubernetes brought them to the next level. All we have to do is execute kubectl apply and voila. The application is running together with all the associated resources. If it needs storage, it is mounted. If it needs to be used by other apps, it is discoverable. Metrics are exposed, and logs are shipped. Our apps became fault-tolerant and scalable. They are deployed without any downtime, and they can roll back automatically if there are potential issues.

Deploying Applications Using GitOps Principles

Argo CD describes itself as “a declarative, GitOps continuous delivery tool for Kubernetes.” That is, in my opinion, wrong and misleading. Argo CD is not a “continuous delivery tool”. Much more is needed for it to be able to claim that.

Applying GitOps Principles Using Argo CD

There Is More About GitOps

Ahem, Excuse Me ... We will go through progressive delivery, and we will go through it fast so that we can get to the “real deal” quickly. This might be the fastest introduction to a subject, so get ready. 

Applying Progressive Delivery

We are going to explore one of the flavors of progressive delivery using Argo Rollouts . So, it probably stands to reason that a quick explanation of the project is in order.

Community Questions