In the previous chapter, we have discussed Continuous Delivery and Continuous Deployment in length. If you haven’t read it yet, here’s the link to it:
In this chapter, we are going to talk about GitOps.
GitOps is defined as a way of implementing Continuous Deployment for cloud-native applications. It focuses on a developer-centric experience when operating infrastructure by using tools developers are already familiar with, including Git and Continuous Deployment tools.
The definition above doesn’t say much, does it? But, even if you haven’t heard of the concept quite often, chances are, you probably have already been using it:
In earlier chapters, we have covered Continuous Integration (CI), why testing is essential to CI, and how to manage versions with CI.
If you haven’t read those chapters yet, here are some links:
After your code is automatically integrated into your source code management system with high-quality tests in place, the next step you want is to deploy them to an environment, and hopefully in an automated fashion. This is where Continuous Deployment kicks in.
CD can mean both Continuous Delivery and Continuous Deployment.
We read and hear these two terms a lot, and you might get asked quite often…
We all know a thing or two about versioning already.
If you are a Windows user, you probably know Windows 7, 8, and 10.
If you use a mac, you probably are familiar with macOS 10.14, 10.15, or the latest 11 (maybe you know them by the code instead of a number like macOS Mojave, Catalina, and the Big Sur.)
Apparently, people like to put a number to the software. Why is this important?
A version is basically like a contract: it assures you, if you use this version number, if it behaves like this today, it will continue behaving…
Martin Fowler defines Continuous Integration (CI) as follows:
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily — leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.
Why does it matter to DevOps? Again, it’s related to velocity — being able to merge frequently is the foundation of deploying…
What is the most important technical aspect in a smoothly running DevOps setup (or even, in general, in a typical software development lifecycle)?
In fact, this is a tough question because, in fact, all aspects are equally important:
Offered by the Cloud Native Computing Foundation in collaboration with The Linux Foundation, the CKA is one of the most hands-on certifications you can get on cloud/DevOps.
Currently, there a whole lot of certifications that only ask you text-based multiple-choice questions and give you a title like “architect” or something to that effect — which I don’t think is the way how “architect” works. No wonder nowadays, when people hear the word “architect,” they often think of some guy who has never written any single line of code in the past 10 or even 20 years sitting behind his desk…
Terraform is the de facto “Infrastructure as Code” tool to manage your cloud infrastructure automatically.
If you are unsure about the idea of “Infrastructure as Code,” please check out my article here:
To know more about Terraform and the best practices, please check out the official website here and my blog article here:
The Terraform Associate certification is for Cloud Engineers specializing in operations, IT, or development who know the basic concepts and skills associated with open source HashiCorp Terraform.
At the moment, there are three certifications under the HashiCorp Infrastructure Automation Certification series, and they are Terraform, Consul, and…
In the previous chapter, we covered the history and development of configuration management, what it is, and why we need it. If you haven’t read it yet, before jumping right into the tools that do configuration management, I highly recommend you to give it an overview first:
A few new tools emerged to solve the aforementioned manual/shell configuration management problems. They are so popular and successful now that when we talk about configuration management, we are invariably talking about one or some of them: puppet, salt, chef, ansible.
Initially released in 2005, after 16 years, it’s still quite popular, and…
If you are using servers as building blocks in your infrastructure (instead of containers, for example), you need to manage those servers.
For instance, in a typical web application setup, you might have three types of servers:
In those frontend servers, you install HTTP servers like Nginx, and you put your SSL certificate there.
In the backend servers, you might install python and deploy your python applications there.
In the database servers, you install and maintain a cluster of Postgres, for example.
You can already see that different types of servers might use different operating systems, and…
In my previous article, we had an overview of secret managers, why do we need them, and some best practices on using them. A quick link if you haven’t read it yet:
In real-world projects, you might use secret managers in many ways. For example, you can integrate it with your Terraform infrastructure code; you can integrate it with your configuration management tools, or CI/CD pipelines, or even in your apps, etc.
And, given the rise of Kubernetes, the secret management in Kubernetes becomes more and more important, so I decided to give this specific use-case a dedicated chapter to…
Sr. DevOps Consultant | Global Financial Services | Professional Services at AWS