Overview of GitOps
GitOps is taking forward the DevOps best practices and principles used for application development and implementation to infrastructure automation.
The main idea behind the GitOps methodology is to have a Git repository that consists of a declarative description of the production environment infrastructure and an automated process to make our production environment identical to that defined in the Git repository.
To support this rapid deployment, infrastructure should be elastic by providing high performance and consume less cost. This will increase the demand for managing the infrastructure as well as infrastructure automation. GitOps follow the principles to manage infrastructure and application configuration over git repository and make Git a single source of truth. It automatically manages the infrastructure provisioning and deployment on git pull requests.
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 are the Challenges of GitOps?
The existing methods for infrastructure configuration management have some issues. Difficult to manage implicit infrastructure, its state, and configurations. It makes it difficult to investigate how and where your application is running. Sometimes make rollback challenging to roll back faulty changes done.
Eventual consistency of the configuration. Even with the centralized configuration, the actual configuration and a declared one can drift with manual operations.
Umbrella chart helps to deploy a full dependent stack over a cluster. But sometimes, it becomes punishing to reconfigure the charts, interrupt the isolation of charts, and increase load over the cluster.
What are the Solutions for GitOps?
Gitops with ArgoCD
ArgoCD follows the declarative approach and acts as an agent to provide continuous delivery automation tools in the GitOps lifecycle.
Technology/Solution Architecture of GitOps
GitOps continuous deployment with ArgoCD.
- API Server
When users interact with ArgoCD, either GUI or CLI, The interaction is possible with the API server component of ArgoCD.
- Repository Server
Internal service that maintains a local cache of Git repository. Mainly responsible for generating and returning Kubernetes manifest.
- Application Server
The Kubernetes controller continuously monitors the live state of the application with the desired state of application inside the git repository. It detects the OutofSync application and takes the correct action.
Description: The primary purpose of ArgoCD is to provide support to GitOps as a continuous delivery tool in the Kubernetes environment. The heart of ArgoCD is the Application Controller, That continuously monitors the running applications state and compares that with the live application state against the desired target state defined in the Git repository or, in simple terms comparing the actual state(app running in Kubernetes cluster) with the desired state(in Git).
As we know, the GitOps phenomenon rely on a single source of truth that is Git, and when it comes to Application definitions, configurations, and application deployment and lifecycle management should be automated. Environments should be declarative and version-controlled, auditable, and easy to understand. All these we can achieve with the help of ArgoCD.
A set of operating principles, and a collection of practices that enable application development teams to deliver changes Click to explore about, Continuous Integration and Continuous Delivery
Use Cases of GitOps
- Developer pushes updated application source code to the git repo.
- Git repo contains the Gitlab CI, which will build docker files, push docker image to the registry and update kubernetes manifest files(Present in different repo or branch) with the updated docker image.
- The kubernetes manifest files git repo is registered with the ArgoCD application with auto-sync on.
- Now the ArgoCDs’ component Application Controller compares the current application state with the desired state of the application from Git.
- The updated application is deployed over the kubernetes version with the help of ArgoCD.
- Now when each time the application code changes over git repo, steps 1→ 5 apply in sequence.
When developers store application source code
ArgoCD app-of-apps pattern
When deploying multiple applications over the cluster, the app-of-apps pattern will be the best solution. This directly fetches applications from the Git repository. This method overcomes all the challenges encountered in umbrella charts like it maintains the isolation of applications and supports accessible reconfiguration applications.
Your Git repository layout should look like this:
├── Chart.yaml├── templates│ ├── guestbook.yaml│ ├── helm-dependency.yaml│ ├── helm-guestbook.yaml│ └── customize-guestbook.yaml└── values.yaml
Now you have to manage only the above-given files instead of managing each application's helm chart.
Results
The gitops, with the help of ArgoCD, provide great support. Git could play the role of continuous integration, and ArgoCD plays the role of continuous deployment. Both together solve many real-life problems of seamless deployment of applications. This could be the solution for Continuous Integration and Continuous Deployment.
How XenonStack can help you?
We strongly follow the gitops approach to deploy the applications in a microservice environment. This approach is not only a reliable solution but also helps in providing frequent release of the application.
- Discover more about Application Development on ArgoCD with GitOps
- Click to explore about DevOps Assembly Lines and CI Pipelines
