Storing YAML in Git records changes. GitOps adds an agent that observes the running system and reconciles it with the declared state. Use the four principles to decide how application source, deployment configuration, review and controller access fit together.
Starting with this article, we increase the depth by targeting readers who already know Kubernetes. If you are unfamiliar with Pods, Deployment, Services, and kubeconfig, it is recommended that you go through the site’s Kubernetes lab first. Readers who only need to use the existing Git basics can also use the collaboration/server section above.
Git · GitOps All Series · 20 / 24
On this page
Connecting the Four Principles to Operational Actions
OpenGitOps v1.0.0 introduces the principle of declaring a desired state, preserving change history, and having the agent retrieve it automatically and continuously adjust it. The table below interprets the principles in accordance with the structure of this series.
| principles | Meaning in this exercise |
|---|---|
| declarative state | Record deployment replicas, images, etc. in YAML |
| Versions and constant history | Identification of criteria by reviewed commits and image digest |
| Automatically imported by agent | Argo CD reads Git repositories |
| continuous adjustment | Repeated observation and processing of differences between Git and clusters |
The way CI records settings in Git and then runs kubectl apply once may be a structure without a controller that continuously adjusts it. Either approach can be used, but they are not called the same construct when describing recovery and permissions. The original text of the principles can be found at OpenGitOps.
Divide permissions between app code and operational declarations
Training uses two repositories: gitops-demo is a code repository for learning Python testing and CI, and gitops-config is a repository containing nginx deployment examples. It is a configuration designed to relieve complex app build settings while clearly serving as CI learning and Kubernetes tuning practice.
gitops-demo/
greeting.py
test_greeting.py
Jenkinsfile
.github/workflows/ci.yml
gitops-config/
environments/
dev/
deployment.yaml
bootstrap/
project.yaml
application.yamlDividing the distribution repository makes it easier to review permissions to develop apps and permissions to change the operating environment separately. You can start with just one repository, but you’ll need to carefully decide on the owner of each route, the required reviews, and the scope of what the controller reads. Increasing the number of repositories is not a goal in itself.
In bootstrap/, the administrator places a definition to register in Argo CD, and the application reads only environments/dev. Just because you have a bootstrap file doesn’t mean it will be applied automatically. In particular, permission to modify AppProject and Application is restricted separately as it is linked to distribution permission.
Start in a development environment and advance to operations
Initially, create only one place, environments/dev. When operational practice becomes necessary, add a separate review rule with the prod path. Even if you use the same image, the replica, resource, and connection target are different, so check the change diff.
앱 CI → 검증된 이미지 digest 생성
↓
개발 설정 PR → 개발 환경 검증
↓
같은 digest의 운영 설정 PR → 승인 → 운영 컨트롤러 조정There is also a way to map one branch to one environment, but you need to cherry-pick and manage branch differences. Here, we use main’s environment-specific directory so that the values to be promoted are visible in the diff. Before reducing duplication with Helm or Kustomize, we first check operation with a small original YAML.
Controllers should not have any power either.
Set the Git read key, target cluster, and allowed namespaces and resources. You should review whether anyone with write access to the storage can deploy any resources to the cluster. AppProject in Part 21 narrows the source and destination scope, but does not replace the cluster’s RBAC and network perimeter.
For Argo CD’s distribution repository separation and Git change flow, refer to the official best practice . In the next installment, we’ll look at manual synchronization with the first diff, with default automation turned off for a moment.
Previous · [Git and GitOps 19] Plan CD: Approval, Artifact Promotion and Image Digests · Next · [Git and GitOps 21] Deploy with Argo CD: Installation, Projects and Git Access · series list and example file
