Hello! Today, we’re going to dive deep into GitOps, which has become the pinnacle of modern DevOps and an essential operating model in cloud-native environments. π
If you read through this for about 10 minutes, you’ll perfectly understand everything from why GitOps emerged to its actual implementation principles.
GitOps, in one sentence, is defined as “an infrastructure and application operating model that uses Git as the ‘Single Source of Truth’.”
In the past, when developers wrote code and handed it over, operations teams would manually connect to servers, type commands, or run complex scripts. However, as systems grew larger, it became difficult to track “who changed what and when.”
To solve this problem, Weaveworks first proposed the concept of GitOps in 2017. The idea is to apply Git, which we use for code management, directly to infrastructure management. π‘

π 4 Core Principles of GitOps
The reason GitOps means more than just “using Git” is due to its following four strict principles.
- Declarative Description π
- Instead of “increase servers by 3 (imperative)”, it describes, “the final state of the system should be 3 servers (declarative)“. YAML file format is primarily used.
- Versioned and Immutable π
- All configuration states are stored in Git. Change history remains, allowing rollback to a previous state at any time.
- Automatically Applied π€
- Human intervention is not required in the process of applying the ‘desired state’ stored in Git to the actual environment. It synchronizes automatically.
- Continuous Reconciliation βοΈ
- The system continuously monitors in real-time whether the current state matches the state defined in Git. If someone manually modifies a setting, the system detects it and reverts it to the Git state.
βοΈ How Does GitOps Work? (Push vs Pull)
There are two main models for implementing GitOps. The Pull model is particularly considered the essence of GitOps.
1. Push Model (Traditional CI/CD)
This is the traditional method using Jenkins or GitHub Actions. When code is updated, the CI tool directly sends commands to the operating environment (Kubernetes, etc.) to “push” the updates. This has a security weakness as the external CI tool requires access rights to the operating environment.
2. Pull Model (True GitOps)
An ‘agent (Operator)’ is installed within the operating environment. This agent periodically checks the Git repository (Polling), and if changes occur, it pulls them in and applies them itself.
- Key Tools: Argo CD, Flux
- Advantages: Highly secure as there’s no need to expose operating environment credentials externally.
π₯ Why Should You Use GitOps? (Key Advantages)
Adopting GitOps significantly boosts team productivity. π
- Fast and Secure Deployment: A single git push deploys even the infrastructure, speeding things up. If an issue arises, it can be instantly restored with git revert.
- Strong Security: Developers do not need direct access to the operating server (K8s cluster, etc.). Only Git permissions need to be managed.
- Visibility and Audit: Git logs serve as a work journal. It’s 100% transparent who changed which infrastructure settings.
- Knowledge Assetization: No need to ask, “How was the server configured?” The YAML files in the Git repository are the latest documentation.
π οΈ Tech Stack to Get Started with GitOps
GitOps typically consists of the following technology combinations.
- Infrastructure: Kubernetes (best compatibility with GitOps) βΈοΈ
- Git Repository: GitHub, GitLab, Bitbucket π
- CD Tool: Argo CD (most popular), Flux CD π
- Config Management: Helm, Kustomize (for managing environment-specific settings) π οΈ
π§ Considerations When Adopting GitOps (Challenge)
Of course, like all technologies, it’s not without its challenges. β οΈ
- Password Management: Sensitive information like DB passwords should never be uploaded to Git in plain text. Sealed Secrets or HashiCorp Vault like separate security solutions must be integrated.
- Git Repository Design: Strategic consideration is needed on whether to keep application code and infrastructure configuration code in the same repository or separate them. (Separation is usually recommended.)
- Cultural Change: A team agreement and cultural establishment are essential that all changes must be performed only through Git PR (Pull Request).
π Conclusion
GitOps is not merely a choice of tools, but a philosophical shift to ‘treat operations like software development.’ In the journey towards cloud-native, GitOps is no longer an option but an essential milestone.
We hope today’s content helps you upgrade your infrastructure operations! π
Leave a Reply