Introduction to GitOps and Continuous Delivery
Before jumping on to the GitOps and Continuous delivery part, we should first know why we should care about it in the first place. GitOps is a philosophy or set of practices that allow developers to take on activities that IT operations typically handle. GitOps encourages us to use declarative specs to design and observe systems, eventually forming the foundation of everything. Continuous everything refers to but is not limited to continuous integration (CI), testing, delivery, deployment, analytics, governance, and many more. This blog will learn more about GitOps in more detail, along with Continuous Delivery and its Compliance. So, let's hop into it!
What is GitOps?
GitOps is a method for managing Kubernetes clusters and delivering applications introduced in 2017 by Weaveworks. GitOps makes declarative infrastructure and applications operate by utilizing Git as a single source of truth. Software agents can notify on any divergence between Git and what's running in a cluster with GitOps. If there's a difference, Kubernetes reconcilers will update or roll back the cluster based on the situation. Developers utilize familiar tools to create pull requests to accelerate and simplify application deployments and operations duties to Kubernetes when Git is at the heart of your delivery pipelines.
You only need to update the repository to deploy a new application or update an old one; the automated process will rest. It's like having cruise control when it comes to managing your production applications.
GitOps uses Git as a single source of truth for infrastructures like declarative infrastructure and applications. Click to explore about, Gitops Tools | Principles | Benefits | Use Cases
What is the single source of truth in Git?
Kubernetes is only one of several current cloud-native tools that are "declarative" and can be handled as code, thanks to GitOps. Declarative means that a set of facts rather than a set of instructions guarantees configuration. You have a single source of truth with your application's declarations versioned in Git. Your programs can then be quickly deployed to Kubernetes and rolled back. Even more significant, your cluster's infrastructure can be reliably and swiftly replicated in the event of a disaster.
What are the benefits of GitOps?
Listed below are the benefits of GitOps:
Productivity Improvements
Mean Time to Deployment is sped up using continuous deployment automation and an integrated feedback control loop. The team can ship 30-100 times more changes per day, resulting in a 2-3-fold increase in overall development production.
Developer Experience Enhancement
Without knowing the internals of Kubernetes, developers may utilize familiar technologies like Git to manage upgrades and features to Kubernetes more quickly. Newly hired developers can come up to speed fast and start working within days rather than months.
Increased Reliability
You get stable and repeatable rollbacks with Git's revert/rollback and fork capabilities. Because your entire system is defined in Git, you can recover from a meltdown using a single source of truth, cutting your mean time to recovery (MTTR) from hours to minutes.
Standardization and Consistency
You have consistent end-to-end processes throughout your business because GitOps provides a single model for making infrastructure, app, and Kubernetes add-on modifications. Pull requests entirely drive your continuous integration and continuous deployment pipelines, and your operations chores are reproducible thanks to Git.
Easier Compliance and Auditing
Compliance and auditing are simplified because modifications are tracked and logged securely. You may also compare a trustworthy definition of the state of the cluster with the actual running cluster using comparison tools.
Continuous Integration vs Continuous Deployment has recently been the town's talk, and there are quite mixed thoughts on which one is better. Click to explore about, Continuous Integration vs Continuous Deployment
Push-based vs. Pull-based Deployments
The deployment approach for GitOps can be implemented in two ways push-based and pull-based deployments. The distinction between the two deployment kinds is how the deployment environment matches the desired infrastructure. Pull-based approaches should be chosen whenever possible because they are deemed more secure and better practices for implementing GitOps.
Push-based Deployments
Popular CI/CD technologies like Jenkins, CircleCI, and Travis CI implement the Push-based deployment technique. The application's source code and the Kubernetes YAML required to deploy the app are stored in the application repository. The build pipeline is initiated whenever the application code is updated, and it generates the container images before updating the environment configuration repository with new deployment descriptors.
Changes to the environment configuration repository trigger the deployment pipeline. This pipeline is in charge of applying the environment configuration repository's manifests to the infrastructure. It is critical to provide credentials to the deployment environment while using this method. When conducting automated provisioning of cloud infrastructure, a Push-based deployment is unavoidable in some instances. Another thing to bear in mind is that the deployment pipeline is only activated when the environment repository changes when utilizing this strategy. It is unable to detect any deviations in the surroundings from the ideal state. This means there must be some form of monitoring in place so that if the environment does not match what is stated in the environment repository, action can be taken.
Pull-based Deployments
The pull-based deployment method follows the same principles as the push-based strategy, but the deployment pipeline is different. When new code is pushed to an application repository, for example, traditional CI/CD pipelines are triggered by an external event. The operator is introduced with the pull-based deployment method. It replaces the pipeline by regularly comparing the planned state in the environment repository to the actual state in the deployed infrastructure. When the operator notices a discrepancy, the infrastructure is updated to reflect the environment repository. In addition, the image registry can be checked to see if there are any new versions of images to deploy.
This option, like the push-based deployment, updates the environment anytime the repository changes. Changes in the operator, on the other hand, might be seen in both directions. Any changes to the deployed infrastructure that aren't documented in the environment repository are reversed. Making all direct changes to the cluster impossible ensures that all changes are traceable in the Git log.
The difficulty of push-based deployments, in which the environment is only updated when the environment repository is updated, is solved with this shift in direction. This does not, however, imply that you may go without any surveillance. Most operators support sending emails or Slack notifications if the environment cannot be brought to the intended state for whatever reason, such as when a container image cannot be pulled. Furthermore, you should set up monitoring for the operator, as there is no way to automate the deployment process without it.
The operator should always be located in the same environment or cluster as the application that is being deployed. This avoids the god-mode found with the push-based method, where the CI/CD pipeline knows the credentials for making deployments. External services do not need to know any credentials if the deploying instance is located within the same environment. The deployment platform's authorization mechanism can be used to limit the permissions for completing deployments. This has a significant impact on security. RBAC configurations and service accounts can be used with Kubernetes.
Automate the process of Machine Learning from model building to model deployment in production. Click to explore about, Continuous Delivery of Machine Learning Pipelines
Continuous Delivery and GitOps Workflow
The GitOps core machinery is in its Continuous Integrations /Continuous Delivery tooling, with continuous deployment (CD) supporting Git-cluster synchronization being the most important aspect. Workflow for creating or updating a new feature as follows:
- For review, a pull request for a new feature is submitted to GitHub.
- A colleague looks at the code and approves it. The code is merged to Git when it has been reviewed and re-approved.
- The Git merge starts the CI and builds a process that tests before building a new image and storing it in a registry.
- The Cloud Deployment Automator monitors the image registry for new images, pulls them from the registry, and updates their YAML in the config repo.
- The cluster's out-of-date status is detected by the Cloud Deployment Synchronizer (installed on the cluster). It deploys the new feature to production after pulling the revised manifests from the config repo.
Adding Compliance and Security to the mix!
Let's look at our compliance and security requirements in more detail! Enterprise organizations must not only meet their stringent requirements, but they may also be subject to government laws.
A standard list of software delivery compliance and security requirements is as follows:
- Access Control: Control who can deploy what in which environment.
- Audit Trail: Keep track of all changes to the environments, including who made what changes and why.
- Approval Process: Changes to specific settings require approval from authorized persons before they can be implemented.
How GitOps solve the compliance complexities?
- Access Control: Only those with write access to an environment's configuration Git repo are allowed to deploy to that environment.
- Approval Process: For sensitive situations, we can allow Jenkins to create a Pull Request (PR) for the development team, but only authorized individuals can merge it. This results in a very smooth approval procedure with minimal setup time.
- Audit: Git is naturally good at keeping track of changes because it is a version control system. Each Git commit contains a message that describes the change and identifies the person who made it.
Conclusion
In this blog, we learned about GitOps, why it is called Single Source of Truth, and its benefits. We then learned about different types of deployments, i.e., push and pull. Then we went on to learn about the workflow of CI/CD with GitOps.And at the end, we added Compliance and Security to it and how GitOps solve these compliance complexities.
- Discover more about Continuous Integration and Continuous Delivery
- Read more about AWS CI and CD for Drupal Applications
