A decade of best practices says that config is code, and that code should always be stored in version control. Git has moved the state of the art forward in development and now it is paying that benefit forward to Ops.
The adoption of microservices means that developers are not only responsible for writing the code, but also for its deployment. With monoliths, changes to applications were large, infrequent, and required a lot of coordination. But now with microservices, small and frequent code changes can be deployed by independent teams at any time to a running app.
A “you build it, you own it” development process requires tools that developers know and understand. “GitOps” is our name for how we describe modern best practices for high velocity application development with cloud native tools.
What is GitOps?
GitOps builds on DevOps with Git as a single source of truth for declarative infrastructure and applications - the whole system.
Kubernetes is just one example of many modern tools that are “declarative”. Declarative means that configuration is guaranteed by a set of facts instead of by a set of instructions, for example, “there are ten redis servers”, rather than “start ten redis servers, and tell me if it worked or not”.
By using declarative tools, the entire set of configuration files can be version controlled in Git. This means that Git is the source of truth and that an entire infrastructure can be reproduced from Git.
Over the few years at Weaveworks we’ve learned that success came down to getting three things right:
- Having a completely automated delivery pipeline that can roll out changes to your infrastructure when changes are made to Git. (Read more about The GitOps Pipeline)
- Operating a fast paced business 24/7 requires monitoring and observability baked into the beginning. Security is of critical importance. (Learn more about GitOps Observability)
- Everything has to be version controlled and stored in a single source of truth from which you can recover. (More details for Operations by Pull Request)
GitOps empowers developers to embrace operations
The GitOps core machinery in Weave Cloud is in the CI/CD tooling and the critical piece is continuous deployment (CD) and release management which supports Git-cluster synchronization. Weave Cloud deploy is designed specifically for version controlled systems and declarative application stacks. Every developer can use Git and make pull requests and now they can use Git to accelerate and simplify operational tasks for Kubernetes as well.
A developer adds a new feature to his app and pushes it to GitHub as a pull request which triggers the GitOps pipeline to deploy to production:
Observability is a pipeline catalyst
Observability can be seen as one of the principal drivers of the Continuous Delivery cycle for Kubernetes since it describes the actual running state of the system at any given time. The running system is observed in order to understand and control it, and new features and fixes are pushed to git and feeds the pipeline:
Git-centric tools accelerate delivery
Our goal is to help teams accelerate delivery. We provide Git-centric tools that unify pipelines with observability in ways that make developers love operations.
The role of a GitOps dashboard in Weave Cloud is to enable observation and to speed up both the understanding and validation of the system, and to suggest mitigating actions. This accelerates the operations cycle.
In the GitOps pipeline model, Git is the design centre. It plays the central role of “source of truth for everything in the system” - code, config and the full stack. That means any developer can use Github and can join the team and ship a new app or make changes easily. CI, build and test services are necessary for constructing deployable artefacts. But in the GitOps pipeline, the overall orchestration of delivery is coordinated by the deployment and release automation system - triggered by updates to repos. At Weaveworks, these principles are built into Weave Cloud and allows for a fast path from laptop to production.
For further reading we recommend our blog series on GitOps: