In the early stages of designing or implementing GitOps, it can be daunting to think about the various tools and practices you might need. You want to be sure you’re designing a robust and scalable workflow for managing infrastructure and application deployments. And you don’t want to bring anything in that will overcomplicate processes or make it harder for your team to release code changes.
One way to narrow your focus is to look for tools and practices that will support your deployment practices. The major consideration is whether you utilize a push-based or a pull-based approach. Both have their pros and cons, and the one you use will impact the tools and processes you include in your GitOps strategy.
Automating Workflows and Infrastructure
First, let’s review two core DevOps practices: Infrastructure as code (IaC), and automation with Continuous Integration and Continuous Delivery (CI/CD).
IaC is a technique for deploying and managing infrastructure through code instead of a series of manual steps or interactive process. This approach is not limited to just infrastructure primitives or managed cloud services–it is applicable to all manageable aspects such as configuration files, software installations, network and security policies and so on. Commonly referred to as “X as Code,” this type of unified management provides a templated and documented desired state for your deployment.
CI/CD is a methodology and set of common practices allowing developers to rapidly and reliably deliver quality and securely coded applications. To embrace CI/CD is to embrace a culture where development teams can stay sharply focused on the business and end user requirements by implementing automation at the right stages of the software development lifecycle.
In software development, integration is the process of committing changes to code in a repository. Continuous Integration (CI) is the process of automatically validating the changes, by building, testing, and packaging the updated application code in a reliable and consistent way. Triggering a CI workflow on every push event provides a smoother, faster development process, since bugs, security vulnerabilities, and conflicts can be discovered before the changes are deployed to an environment.
A Continuous Delivery (CD) workflow takes over after a successful completion of the CI workflow. This is the automated and consistent process of delivering the updated application code to a selected environment.This can be a workflow that facilitates deploying the application directly onto staging or production servers, or shipping a new release to a container registry or mobile distribution platform.
These are central themes here around automating developer workflows. A GitOps approach relies on these core DevOps practices and puts them into operation. By leveraging a git repository as a single source of truth for IaC definition files, and utilizing automation pipelines, you can effectively version control the desired state of your infrastructure.
Here’s where we come back to your deployment practices: deciding whether push or pull-based is the best fit for your application and GitOps strategy.
Comparing Push vs. Pull-based Architecture
Push-based, or agentless, is the more traditional approach in which changes are pushed to the selected environment by an external CI/CD client such as Jenkins or CircleCI. This can be preferable for non-Kubernetes environments, or environments with a mixture of workload types that would make running separate agents and webhooks on each component cumbersome.
Pros:
- Simpler to implement across multiple types of workloads in a single environment.
- Standardization of deployment methodology between different environments (i.e. cloud-native and on-premise).
- Tooling flexibility since most CI/CD frameworks leverage a push-based model.
Cons:
- CI/CD client doesn’t have observability to know if changes deployed successfully, or if servers-side issues occurred as a result.
- Additional tooling may need to be installed (i.e. kubectl, Helm, Docker, Ansible, Terraform, SSH) for the CI/CD client to deploy the changes.
- Requires giving the CI/CD client external access to the environment, which increases risk of security and compliance issues.
Pull-based or agent approach works in the opposite direction by making the environment part of the CD pipeline. An agent or operator watches the git repository for changes, then pulls and applies them. This task is also performed anytime the agent detects a configuration drift from the single source of truth. This approach works particularly well with Kubernetes-native environments.
Pros:
- The agent/operator has observability on the environment’s current state and deployment status.
- Better security and simplified compliance because the environment only requires permission to view the source.
- Quick detection of configuration drift from manual human intervention or other sources.
Cons:
- More complex for non-Kubernetes deployments.
- Requires tooling designed to work with specific environment types.
As you begin to plan your GitOps strategy, consider how different deployment strategies will support your application. Both push and pull-based approaches have their advantages and are suitable for different scenarios. There are many tools and practices to consider, and with some perspective you will know what the right solution is for your team and your stack.
Looking for more information? Download our free GitOps Strategy ebook, or get a free consultation with an Akamai cloud computing expert.
Comments