GitOps is a development methodology that advocates using versioned files in source control repositories to define and manage your infrastructure. Expressing your architecture as declarative files provides a way to inspect your system’s current configuration, merge changes from multiple contributors, and rollback to an earlier state.

So far this approach sounds similar to Infrastructure as Code (IaC). GitOps is more than mere IaC though: a successful implementation will incorporate an automated mechanism to apply your config files to live infrastructure components. Merging changes should cause your infrastructure’s state to transition towards that described by the revised repository content.

This requires a bridge between your source control platform and your infrastructure provider, allowing the current state to be communicated between the two. There are different ways in which this bridge can be implemented, each placing a unique set of responsibilities on the platforms involved. In this article we’ll look at the Agent-based (or Pull-based) deployment model, then compare it to a Push-based approach.

What’s An Agent?

Agent-based GitOps refers to running a process inside your infrastructure that facilitates your deployments. The process is responsible for maintaining communication with the source control platform that hosts your IaC files.

An Agent is an active part of your infrastructure. It’ll periodically connect to your Git repository, check for changes, and pull new commits into your deployment environment. The agent will subsequently take action to apply the fetched changes to its surroundings, triggering the appropriate state transition.

Agents can provide extra features such as built-in deployment monitoring, logging, and alerting. These keep you continuously informed of activity within your infrastructure. The agent handles integration with your existing tools to surface relevant information in the appropriate places.

The agent model differs from the conventional view of Continuous Integration and Continuous Deployment (CI/CD) by cutting out the concept of the trigger-bound pipeline. Instead there’s an automated reconciliation loop that fetches changes as they become available. New commits and merges only indirectly prompt a change to your infrastructure. It could be some time before the agent acquires the new data.

Several vendors offer agents that can be used to implement GitOps workflows. GitLab now advocates the approach as its preferred way to deploy to Kubernetes, via the GitLab Agent for Kubernetes. The agent connects to a GitLab instance from within your cluster, then facilitates two-way communication to rollout changes and send information back to your repositories.

Flux by Weaveworks is another option which works with any Git repository and includes alerting capabilities. Flux is now an incubator project within the Cloud Native Computing Foundation (CNCF). It runs as a Kubernetes operator that picks up changes made to your connected Git repos.

Agent Advantages

Agent-based GitOps has multiple advantages which make it appealing to a variety of stakeholders. First there’s the clear distinction between responsibilities: your source control platform is unchanged and doesn’t need to concern itself with connections to your infrastructure. The Agent needs to be supplied with repository credentials but is otherwise self-sufficient. Once it’s running, it’s narrowly focused on detecting and applying changes.

This separation of concerns can help you pinpoint problems and reason about deployment failures. You can generally discard the source control platform straightaway. If it’s up and your main branch contains the correct changes, discrepancies in your infrastructure’s actual state must be down to an agent synchronization issue.

Agents also offer a higher degree of automation than Push-based GitOps. To successfully adopt a Push-based flow, you’ll need to configure your repository with credentials for your infrastructure and craft CI pipelines that run the correct scripts to transmit your changes. Those scripts will need to be copied across all your projects, maintained over time, and carefully handled to protect your sensitive credentials.

Agent-based systems come without these concerns. Once an agent’s installed, you benefit from a robust deployment model that’s less susceptible to change. There are far fewer variables concerning connection to a Git repository than successful access to a production environment like a Kubernetes cluster. Hence it makes sense to pull changes from the simpler system into the more complex one.

Another benefit is the positive security impact of agents. They run inside your infrastructure so you can avoid opening it up to outside access. While you will need to expose your Git repository, this is far less risky than providing a door into your production environment. Exposure of a GitHub project token is only likely to leak source code and your IaC files – a serious occurrence but one that pales in comparison with the thought of losing a production Kubernetes account token. That could lead to data theft, subsequent extortion, and irrecoverable system compromise.

What About Push-Based GitOps?

The alternative strategy is the Push-based model where changes are fed to your infrastructure by your source control platform or an intermediary system. The communication is initiated by something running outside the deployment environment. Pushes force the infrastructure to receive a new state from the controlling server.

Push-based GitOps is usually implemented within your CI pipelines. You’re using this model if you have a pipeline that’s configured with a Kubernetes cluster connection and use kubectl apply to create deployments. Another example is a pipeline which runs rsync to synchronize your repository’s content to a remote host.

The limitations of this approach lie in its inability to offer the advantages associated with agents which we covered above. You need to manually configure each repository with an appropriate infrastructure connection, open up your environments to external access, and take responsibility for maintaining your deployment scripts over time.

Push-based GitOps still has some unique benefits though. One significant factor is its inherent familiarity: you can keep using the tools you already know and rely upon in development, such as kubectl, helm, and docker. This helps to minimize differences between local and live deployments.

Error handling can be simpler too. Push-based approaches tend to feel more synchronous which can be helpful in identifying the sequence of events leading up to a failure. While agents give you a clear starting point (the agent itself), you’re then left to filter through the events corresponding to that agent’s activities. Those events may cover dozens of distinct projects and reconciliation cycles. Being able to start from a specific CI pipeline run can therefore be helpful in providing immediate feedback while debugging.

Finally there’s an argument that the Push-based model is actually more adaptable to future infrastructure changes. Adopting Pulls means you’re coupling your system to the specific expectations of your selected agent. This can quickly complicate matters if you need to deploy to a new platform where that agent’s not supported. A scripted Push-based approach is more flexible here. It lets you cater for multiple distinct environments by incorporating conditional logic that takes the correct actions for the target platform.

Summary

Agent-based GitOps refers to running an active component within your infrastructure that reaches out to your source repository to fetch and apply changes. This inverts the Push-based model where you run scripts within CI pipelines to create deployments and apply state changes.

The Push workflow is common, easily understood, and holds some significant attractions. However agent-driven “pulls” are gaining more attention across the cloud ecosystem as vendors and developers come to recognize their benefits.

Adopting a Pull-based approach can reduce maintenance over time, improve the security of your environments, and help you identify failures when changes aren’t getting applied. Agents can also simplify set up of peripheral features like alerts and metrics aggregation, accelerating your DevOps adoption path without manually piecing together complex CI scripts.