The DevOps Toolkit: Catalog, Patterns, And Blueprints
Close
    • The DevOps Toolkit: Catalog, Patterns, And Blueprints
    • Catalogs, Patterns, And Blueprints
    • I Need Your Help
    • Who Are We?
    • About The Requirements
    • Off We Go
    • Going Back In Time
    • Back To Present
    • Using Terraform To Manage Infrastructure As Code (IaC)
    • What Are We Going To Do?
    • Preparing For The Exercises
    • Exploring Terraform Variables
    • Creating The Credentials
    • Defining The Provider
    • Storing The State In A Remote Backend
    • Creating The Control Plane
    • Exploring Terraform Outputs
    • Creating Worker Nodes
    • Upgrading The Cluster
    • Reorganizing The Definitions
    • Destroying The Resources
    • Preparing For The Exercises
    • Exploring Terraform Variables
    • Creating The Credentials
    • Storing The State In A Remote Backend
    • Creating The Control Plane
    • Exploring Terraform Outputs
    • Creating Worker Nodes
    • Upgrading The Cluster
    • Reorganizing The Definitions
    • Destroying The Resources
    • Preparing For The Exercises
    • Exploring Terraform Variables
    • Creating The Credentials
    • Storing The State In A Remote Backend
    • Creating The Control Plane
    • Exploring Terraform Outputs
    • Creating Worker Nodes
    • Upgrading The Cluster
    • Dealing With A Bug That Prevents Upgrade Of Node Pools
    • Reorganizing The Definitions
    • Destroying The Resources
    • Defining A Scenario
    • Preparing For The Exercises
    • Creating Helm Charts
    • Adding Application Dependencies
    • Deploying Applications To Production
    • Deploying Applications To Development And Preview Environments
    • Deploying Applications To Permanent Non-Production Environments
    • Packaging And Deploying Releases
    • Rolling Back Releases
    • What Did We Do Wrong?
    • Destroying The Resources
    • Which Operating System Is The Best For Laptops?
    • Installing Windows Subsystem For Linux (WSL)
    • Choosing A Shell
    • A Short Intermezzo
    • Choosing An IDE And A Terminal
    • Using Oh My Zsh To Configure Z Shell
    • Going For A Test Drive With Oh My Zsh
    • What Should We Do Next?
    • There Is More
    • Deploying Google Cloud Functions (GCF)
    • Deploying Azure Functions (AF)
    • Deploying AWS Lambda
    • To FaaS Or NOT To FaaS?
    • Choosing The Best Managed FaaS Provider
    • Personal Thoughts About Managed FaaS
    • Discussing The “Real” Expectations
    • Deploying Applications To Google Cloud Run
    • Deploying Applications To Amazon Elastic Container Service (ECS) With Fargate
    • Deploying Applications To Azure Container Instances
    • To CaaS Or NOT To CaaS?
    • Personal Thoughts About Managed CaaS
    • Using Knative To Deploy And Manage Serverless Workloads
    • Self-Managed Vs. Managed CaaS
    • About Vadim
    • Why Not Using The ELK Stack?
    • Using Loki To Store And Query Logs
    • Destroying The Resources
    • Discussing Deployments And Environments
    • Off We Go
    • Installing And Configuring Argo CD
    • Deploying An Application With Argo CD
    • Defining Whole Environments
    • Creating An Environment As An Application Of Applications
    • Updating Applications Through GitOps Principles
    • Destroying The Resources
    • Installing And Configuring Argo Rollouts
    • Exploring Argo Rollouts Definitions
    • Deploying The First Release
    • Deploying New Releases Using The Canary Strategy
    • Rolling Back New Releases
    • Exploring Prometheus Metrics And Writing Rollout Queries
    • Exploring Automated Analysis
    • Deploying Releases With Fully Automated Steps
    • What Happens Now?

Introduction

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.

I will assume that you don’t have time to read hundreds of pages to learn something that you are not even sure is useful. Instead, I will guess that you got up to one hour to read a summary, and then decide if a tool is worthwhile a more significant investment.

This is a catalog of the tools, and the processes I believe are useful in this day and age. I will try to transfer what I think works well and what might have been the right choice in the past but is not optimal anymore.

Nevertheless, even if the scope of this book is different than others, some things are still the same. This is not a book with lots of theory. Sure, there will be some text you might need to read, but most of the content consists of hands-on exercises. I always believed that the best way to learn something is through practice, and I am not giving up on that. This is a book full of real-world hands-on examples, and each chapter will let you dive into a different tool or a process. At the end of each, you will be able to say, “now I know what this is about, and now I can make a decision whether it is a worthwhile investment.”

Think of this book as a catalog, combined with patterns and blueprints.

I Need Your Help

I will do my best to accommodate different needs. For example, if we need a Kubernetes cluster, you will find examples for at least a few flavors (e.g., GKE, EKS, AKS, Minikube, and Docker Desktop). If we need a cloud provider, there will be examples in at least the three major ones (e.g., AWS, GCP, and Azure). And so on and so forth. Nevertheless, there is always a limit to how many variations I can include. Yet, if you do feel that the one you are using is not represented, I will gladly add it (if I can). You just need to let me know.

While we are on the subject of including stuff, I prefer to drive this material by your needs. I want to hear back from you. What is the tool you would like me to explore? What did I miss? What are you interested in? Please let me know and, if that is something I feel confident working with, I will do my best to extend the material. This book will grow based on your feedback. The critical thing to note is that I want to keep it alive and to keep adding tools. But, I will do that only if you tell me to. So, it’s up to you to let me know what to add. And, to do that, you will need a way to contact me. So, here it goes.

Please join the DevOps20 Slack workspace and post your thoughts, ask questions, or participate in a discussion. If you prefer a more one-on-one conversation, you can use Slack to send me a private message or send an email to viktor@farcic.com. All the books I have written are very dear to me, and I want you to have a good experience reading them. Part of that experience is the option to reach out to me. Don’t be shy.

If none of those communication channels work for you, just Google my name, and you’ll find others. Honestly, any way you prefer to reach me is OK. You can even send a courier pigeon.

Who Are We?

Before we dive further, let me introduce you to the team comprised of me, Viktor, and another guy, which I will introduce later.

Who Is Viktor?

Let’s start with me. My name is Viktor Farcic. I currently work in Codefresh. However, things are changing and, by the time you are reading this, I might be working somewhere else. Change is constant, and one can never know what the future brings. At the time of this writing, I am a Principal DevOps Architect.

What else can I say about myself? I am a member of the Google Developer Experts (GDE), Continuous Delivery Foundation Ambassadors, and Docker Captains groups. You can probably guess from those that I am focused on containers, Cloud, Kubernetes, and quite a few other things.

I’m a published author. I wrote quite a few books under the umbrella of The DevOps Toolkit Series. I also wrote DevOps Paradox and Test-Driven Java Development. Besides those, there are a few Udemy courses.

I am very passionate about DevOps, Kubernetes, microservices, continuous integration, and continuous delivery, and quite a few other topics. I like coding in Go.

I speak in a lot of conferences and community gatherings, and I do a lot of workshops.

I have a blog TechnologyConversations.com where I keep my random thoughts, and I co-host a podcast DevOps Paradox.

What really matters is that I’m curious about technology, and I often change what I do. A significant portion of my time is spent helping others (individuals, communities, or companies).

Now, let me introduce the second person that was involved in the creation of this book. His name is Darin, and I will let him introduce himself.

Who Is Darin?

My name is Darin Pope. I’m currently working at CloudBees as a professional services consultant. Along with Viktor, I’m the co-host of DevOps Paradox.

Whether it is figuring out the latest changes with Kubernetes or creating more content to share with our listeners and viewers, I’m always learning. Always have, always will.

About The Requirements

You will find the requirements near the beginning of each chapter. They vary from one subject to another, and the only constants are a laptop, Git, and a Bash terminal.

I’m sure that you already have Git. If you don’t, you and I are not living in the same century. I would not even mention it, if not for GitBash. If you are using Windows, please make sure that you have GitBash (part of the Git setup) and run all the commands from it. Other shells might work as well. Nevertheless, I tested all the commands on Windows with GitBash, so that is your safest bet. If, on the other hand, you are a macOS or Linux user, just fire up your favorite terminal.

Every chapter starts from scratch and ends with the destruction of everything we created. That way, you should be able to go through any chapter independently from others. Each is self-sufficient. That should allow you to skip the parts you’re not interested in or to revisit others when in need to refresh your memory. An additional benefit of such destruction is that if you choose to run things in the cloud, you will not waste money when not working on the exercises.

Off We Go

Typically, publishers would tell authors to write an introduction at the end, when all the chapters are written. That way, the author can summarize to the reader what to expect and can give an impression of being in control. However, I don’t have a publisher, so I can ignore such advice. I have no idea what I will write about, and I am not in control. All I know is that I want to transmit the knowledge I have, as well as to use this opportunity to improve myself. As such, I do not have a clue about the scope. I do not know even what the next chapter will be about. I am yet to pick the first tool I will explore.

I will probably pick a few tools, and then I’ll wait for your suggestions.

Given all that, I don’t know whether you are reading this book while it is still in progress, or you picked it up after it was completed. I hope it is the former case. If it is, don’t pay much attention to the index. It is supposed to grow, and the direction greatly depends on whether you will suggest something or not. Expect updates. I will be publishing additional chapters as soon as they are finished.

All in all, this is the beginning of an adventure. I do not know where I am going. All I know is that I hope to enjoy the journey and that you will find it useful to retrace the steps I will be taking.

Community Questions