An operating model for building cloud native applications.
Persona: Cluster Admin - Cluster Repository
Persona: Developer - Development Repository
GitOps works by using Git as a single source of truth for declarative infrastructure and applications.
Your cluster monitors and automatically updates itself to reconcile differences between current and desired state.
With Git at the center of your delivery pipelines, developers use familiar tools to make pull requests to accelerate and simplify both application deployments and operations tasks to Kubernetes.
This allows you to write once and deploy many times to identical clusters.
Create repositories for the cluster administrator and application developers.
You will have to set up namespaces before deploying the application. This should be done as the cluster administrator.
You should create a namespace called
podinfo-app that podinfo can be deployed into but without running
You can look at the sample cluster config as a baseline for cluster-wide components that are likely to be required for later challenges.
Deploy an application to your cluster(s) without running
A sample application - podinfo manifest has been provided that will show information and allow you to access certain functions. This manifest shouldn’t require any changes before being deployed.
Discussion Point 1 Discuss the advantage and disadvantages of using a GitOps approach, you may want to touch on delivering updates, managing multiple clusters, secrets management, security and access management and the benefits of having multiple source code repositories.
Discussion Point 2 Discuss in your team other good practices you can use on the cluster administrator repository
Stretch Can you make connections to a private GitHub repositories?
Hint: Ensure you use SSH auth with a GitOps URL in the format
email@example.com:<org>/<repo>.gitand you can view error logs using
kubectl logs -n <namespace> <pod>
- You have a repository owned and used for:
- Cluster Administrators
- Application Developers (either 1 repository per resource group or 1 folder per resource group)
- Cluster-wide services are controlled by a GitHub repository (you could be running cert-manager, aad-pod-identity from the sample - or simply creating a namespace)
- The sample application is running on your cluster and is publicly accessible
- Discussion of using a GitOps approach and practices around repository management
- What is GitOps - WeaveWorks?
- Enable GitOps
- namespaces and RBAC
- GitOps Operator Parameters
- Sample Cluster Config
- AAD Pod Identity
- Cert Manager
Help us improve
Azure Citadel is a community site built on GitHub, please contribute and send a pull requestMake a change