Standarized workflow to deploy, configure, monitor, update IaaC – the repository contains declarative descriptions of the desired state of the infrastructure ... and automation makes the production enviroment match the repository
State is 1. Declarative, 2.Versioned, 3.Approved changes = applied changes, 4. Correctness aware with alerts.
Let deployment and integration be separate. Developers release, operators deploy.
Leverage Git as a single source of truth and the connection between dev and ops.
- Deployment is done via the usual tools and applications, e.g., helm charts, custom templates. Not the commands themselves, i.e., kubectl, API
- Everything is versioned
- Complete trail of changes and observability via git logs
- If source code release is faulty, rollbacks are done by commits (or revert), not operating on the cluster
- Cluster credentials are kept inside the cluster where they are used (see Flux) thus a more secure setup
- Changes to infra are managed through repo permissions and version control
- Disaster recovery is simpler, point a given repo to a different AZ
- Deploying applications and replicating to all infrastructure is centralized and straighforward
Read more:
GitOps what you need to know
Learn what is GitOps and how you can implement GitOps workflows to reliably run Kubernetes in production and at scale. Also find out why GitOps is the more secure way to deploy apps to Kubernetes.
