{"id":2567,"date":"2024-09-06T08:22:46","date_gmt":"2024-09-06T08:22:46","guid":{"rendered":"https:\/\/www.aviator.co\/blog\/?p=2567"},"modified":"2025-09-25T13:02:24","modified_gmt":"2025-09-25T13:02:24","slug":"choosing-between-pull-vs-push-based-gitops","status":"publish","type":"post","link":"https:\/\/www.aviator.co\/blog\/choosing-between-pull-vs-push-based-gitops\/","title":{"rendered":"Choosing Between Pull vs. Push-Based GitOps"},"content":{"rendered":"\n
\"\"\/<\/figure>\n\n\n\n

GitOps has become essential in cloud-native deployments, particularly with Kubernetes. This article dives into the two primary GitOps approaches\u2014push and pull\u2014exploring their architectures, tools, and best use cases.<\/p>\n\n\n\n

What is GitOps?<\/h2>\n\n\n\n

At its core, GitOps leverages Git as a single source of truth for defining and managing your infrastructure and application deployment. It bridges the gap between development and operations using Git repositories as the primary deployment control mechanism. Changes to your system are made by updating your Git repository, with automation tools applying these updates to your environment.<\/p>\n\n\n\n

How does GitOps Work?<\/h2>\n\n\n\n

GitOps can be implemented using two main approaches: push and pull. In the push approach, CI\/CD tools directly send changes from the Git repository to the environment. On the other hand, the pull approach uses GitOps operators to fetch changes from the repository and apply them to the environment.<\/p>\n\n\n\n

Push-Based GitOps<\/h2>\n\n\n\n

The push-based approach in GitOps is akin to the traditional CI\/CD pipelines<\/a>. In this model, a CI\/CD tool actively pushes changes from the Git repository to the target environment. This method gives you more control over the deployment process but requires more setup and maintenance.<\/p>\n\n\n\n

\"push-architecture\"\/<\/figure>\n\n\n\n

Popular tools for push-based GitOps include Jenkins<\/a>, GitHub Actions<\/a>, GitLab CI\/CD<\/a>, CircleCI<\/a>, and Buildkite<\/a>.<\/p>\n\n\n\n

Jenkins vs. GitHub Actions<\/h3>\n\n\n\n

Jenkins offers extensive customization and complex pipeline support but requires dedicated infrastructure. GitHub Actions provides easy setup, a better UI, and a seamless GitHub repository integration, making it ideal for GitHub users, though with less deep customization.<\/p>\n\n\n\n

Below is a comparison table highlighting the key differences between the two tools:<\/p>\n\n\n\n

\"\"\/<\/figure>\n\n\n\n

Implementation with GitHub Actions<\/h3>\n\n\n\n

Consider a microservices architecture with multiple applications. You can set up a GitHub Actions workflow that triggers on every push to the main branch. For example, this workflow can:<\/p>\n\n\n\n

    \n
  1. Run unit and integration tests<\/a>.<\/li>\n\n\n\n
  2. Build Docker<\/a> images for your services.<\/li>\n\n\n\n
  3. Push the images to a container registry.<\/li>\n\n\n\n
  4. Deploy the updated images to your Kubernetes cluster using kubectl<\/em> commands.<\/li>\n<\/ol>\n\n\n\n

    This straightforward approach works well for teams already using GitHub for source control.<\/p>\n\n\n\n

    This tutorial will use Azure AKS as the managed Kubernetes cluster. Let us start by creating a repository in GitHub.<\/p>\n\n\n\n

    \"\"\/<\/figure>\n\n\n\n

    Add the Azure and Docker secrets required for the pipeline to access the platforms.<\/p>\n\n\n\n

    \"\"\/<\/figure>\n\n\n\n

    Now, create an application server locally. We are using an Express server<\/a> in app.js<\/b> for this tutorial.<\/p>\n\n\n\n

    const express = require('express')\nconst app = express()\nconst port = 3000app.get('\/', (req, res) => {\n  res.send('This is an app for Push-based GitOps!')\n})app.listen(port, () => {\n  console.log(`Example app listening on port ${port}`)\n})<\/p><\/code><\/pre>\n\n\n\n
    Create a Dockerfile to containerize the application.<\/p>\n\n\n\n
    FROM node:latest\nWORKDIR \/usr\/src\/app\nCOPY package*.json .\/\nRUN npm install\nCOPY . .\nEXPOSE 3000\nCMD [\"node\", \"app.js\"]<\/p><\/code><\/pre>\n\n\n\n
    Add the following pipeline code in .github\/workflows\/pipeline.yaml<\/b>.<\/p>\n\n\n\n
    name: CI\/CD Pipelineon:\n  push:\n    branches:\n      - mainjobs:\n  build:\n    runs-on: ubuntu-latest    steps:\n    - name: Checkout code\n      uses: actions\/checkout@v3    - name: Set up Docker Buildx\n      uses: docker\/setup-buildx-action@v3    - name: Log in to Docker Hub\n      uses: docker\/login-action@v3\n      with:\n        username: ${{ secrets.DOCKER_USERNAME }}\n        password: ${{ secrets.DOCKER_PASSWORD }}    - name: Build and push Docker image\n      uses: docker\/build-push-action@v5\n      with:\n        context: .\n        push: true\n        tags: ${{ secrets.DOCKER_USERNAME }}\/push-gitops:latest  deploy:\n    runs-on: ubuntu-latest\n    needs: build    steps:\n    - name: Checkout code\n      uses: actions\/checkout@v3    - name: Set up Kubectl\n      uses: azure\/setup-kubectl@v3\n      with:\n        version: 'latest'    - name: Azure Login\n      uses: azure\/login@v1\n      with:\n        creds: ${{ secrets.AZURE_CREDENTIALS }}    - name: Set up AKS context\n      run: az aks get-credentials --resource-group ${{ secrets.AZURE_RESOURCE_GROUP }} --name ${{ secrets.AKS_CLUSTER_NAME }}    - name: Deploy to AKS\n      run: kubectl apply -f k8s<\/p><\/code><\/pre>\n\n\n\n
    The above pipeline creates a docker image of the code, pushes it to DockerHub, and finally deploys the kubernetes manifest files in the cluster on every code push to the main branch.<\/p>\n\n\n\n
    Create a Kubernetes manifest file in k8s\/deploy.yaml<\/b> to deploy the containerized application in the Kubernetes cluster.<\/p>\n\n\n\n
    apiVersion: v1\nkind: Service\nmetadata:\n  name: push-svc\nspec:\n  selector:\n    name: push-pod\n  type: LoadBalancer\n  ports:\n    - protocol: TCP\n      port: 3000\n      targetPort: 3000\n---\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  name: push-deploy\n  labels:\n    name: push-deploy\nspec:\n  replicas: 2\n  selector:\n    matchLabels:\n      name: push-pod\n  template:\n    metadata:\n      labels:\n        name: push-pod\n    spec:\n      containers:\n        - name: push-container\n          image: <your-docker-username>\/push-gitops:latest\n          ports:\n            - containerPort: 3000<\/code><\/pre>\n\n\n\n
    Finally, create .gitignore <\/b>and .dockerignore <\/b>files and add the node_modules<\/b> directory to avoid large file transfers to the repository and the container.<\/p>\n\n\n\n
    After completing all the above steps, initialize a local git repository for the project, commit the changes, create the \u201cmain\u201d branch locally, and push the code on your remote repository.<\/p>\n\n\n\n
    git init\ngit commit -m \"push-gitops\"\ngit branch -M main\ngit remote add origin <your-remote-repository-url>\ngit push -u origin main<\/code><\/pre>\n\n\n\n
    Verify the pipelines are successfully executed in the actions tab in GitHub.<\/p>\n\n\n\n
    \"\"\/<\/figure>\n\n\n\n
    Get the external IP of the \u201cpush-svc\u201d service created on the cluster to verify the application deployment.<\/p>\n\n\n\n
    \"\"\/<\/figure>\n\n\n\n
    Enter the external IP of the service in the browser with the port to verify the application.<\/p>\n\n\n\n
    \"\"\/<\/figure>\n\n\n\n
    Pull-Based GitOps<\/h2>\n\n\n\n
    In a pull-based GitOps model, a GitOps operator (e.g., FluxCD<\/a> or ArgoCD<\/a>) running within your environment that continuously checks the Git repository for changes. When a change is detected, the operator pulls these changes and applies them to the environment.<\/p>\n\n\n\n
    \"\"\/<\/figure>\n\n\n\n
    FluxCD vs ArgoCD<\/h3>\n\n\n\n
    FluxCD and ArgoCD differ mainly in user experience, customization, and integration. ArgoCD provides a polished UI and features like ApplicationSets and automated rollbacks, which are ideal for ease of use. FluxCD, though more complex, is a more flexible and modular approach, making it suited for teams needing advanced customization.<\/p>\n\n\n\n
    Here’s a table summarizing these differences:<\/p>\n\n\n\n
    \"\"\/<\/figure>\n\n\n\n
    Implementation with ArgoCD<\/h3>\n\n\n\n
    After setting up ArgoCD in your Kubernetes cluster, you can connect it to your Git repository. ArgoCD monitors the repository for any changes to the manifest files, and synchronizes the application with the desired state defined in Git.<\/p>\n\n\n\n
    Let us create a new repository on GitHub.<\/p>\n\n\n\n
    \"\"\/<\/figure>\n\n\n\n
    Set up ArgoCD on your Kubernetes Cluster using their Getting Started<\/a> guide and create an ArgcoCD deployment pipeline. <\/p>\n\n\n\n
    apiVersion: argoproj.io\/v1alpha1\nkind: Application\nmetadata:\n  name: argo-pipeline\n  namespace: argocdspec:\n  project: default\n  source:\n    repoURL: <your-git-repository>\n    targetRevision: HEAD\n    path: k8s\n  destination:\n    server: https:\/\/kubernetes.default.svc\n    namespace: pull-gitops\n  syncPolicy:\n    syncOptions:\n    - CreateNamespace=true\n    automated:\n      prune: true<\/p><\/code><\/pre>\n\n\n\n
    This pipeline gets triggered whenever there is a difference between the manifest files in the k8s <\/b>directory of the remote repository and the actual state of the cluster. It brings the actual state of the cluster as configured in the manifest files of the k8s <\/b>directory. Apply this pipeline in the Kubernetes cluster.<\/p>\n\n\n\n
    Copy all the files except node_modules <\/b> we made in the push-based approach to the pull-based approach.<\/p>\n\n\n\n
    Change the .github\/workflows\/pipeline.yaml<\/b> with the following code:<\/p>\n\n\n\n
    name: CI Pipelineon:\n  push:\n    branches:\n      - main\n    paths-ignore:\n      - 'k8s'jobs:\n  build:\n    runs-on: ubuntu-latest    steps:\n    - name: Checkout code\n      uses: actions\/checkout@v3    - name: Set up Docker Buildx\n      uses: docker\/setup-buildx-action@v3    - name: Log in to Docker Hub\n      uses: docker\/login-action@v3\n      with:\n        username: ${{ secrets.DOCKER_USERNAME }}\n        password: ${{ secrets.DOCKER_PASSWORD }}    - name: Build and push Docker image\n      uses: docker\/build-push-action@v5\n      with:\n        context: .\n        push: true\n        tags: ${{ secrets.DOCKER_USERNAME }}\/pull-gitops:${{ github.sha }}  deploy:\n    runs-on: ubuntu-latest\n    needs: build    steps:\n      - name: Checkout repository\n        uses: actions\/checkout@v4\n      - name: Update deployment.yaml\n        run: |\n          sed -E -i \"s\/<your-github-username>\/pull-git[a-zA-Z0-9:\/-]+\/<your-github-username>\/pull-gitops:${{ github.sha }}\/g\" k8s\/deploy.yaml      - name: Stage changes\n        run: git add k8s\/deploy.yaml      - name: Set Git user identity\n        run: |\n          git config --global user.email \"<your-github-email>\"\n          git config --global user.name \"<your-github-username>\"      - name: Commit changes\n        run: git commit -m \"Update k8s manifest\" k8s\/deploy.yaml      - name: Push changes\n        uses: ad-m\/github-push-action@master\n        with:\n          github_token: ${{ secrets.GIT_TOKEN }}\n          branch: main<\/p><\/code><\/pre>\n\n\n\n
    The above yaml is just for continuous integration, which builds a docker image with a unique image tag and updates the k8s directory with a new docker image for the ArgoCD pipeline to get triggered.<\/p>\n\n\n\n
    Change the app.js<\/b> response to identify the server deployed using the pull-based approach.<\/p>\n\n\n\n
    const express = require('express')\nconst app = express()\nconst port = 3000app.get('\/', (req, res) => {\n  res.send('This is an app for Pull-based GitOps!')\n})app.listen(port, () => {\n  console.log(`Example app listening on port ${port}`)\n})<\/p><\/code><\/pre>\n\n\n\n
    Leave the remaining files similar to the push-based approach. <\/p>\n\n\n\n
    We don\u2019t need the credentials of the Kubernetes cluster in GitHub for this approach. Just create a personal access token with the repository level access and add it as a secret.<\/p>\n\n\n\n
    \"\"\/<\/figure>\n\n\n\n
    After completing all the above steps, initialize a local git repository for the project, commit the changes, create the \u201cmain\u201d branch locally, and push the code on your remote repository.<\/p>\n\n\n\n
    git init\ngit commit -m \"pull-gitops\"\ngit branch -M main\ngit remote add origin <your-remote-repository-url>\ngit push -u origin main<\/code><\/pre>\n\n\n\n
    Verify that the pipeline is successfully executed.<\/p>\n\n\n\n
    \"\"\/<\/figure>\n\n\n\n
    Go to the ArgoCD Web UI and verify that that pipeline is in sync with the latest commits.<\/p>\n\n\n\n
    \"\"\/<\/figure>\n\n\n\n
    Get the external IP of the \u201cpull-svc\u201d service created on the cluster to verify the application deployment.<\/p>\n\n\n\n
    \"\"\/<\/figure>\n\n\n\n
    Enter the external IP of the service in the browser with the port to verify the application.<\/p>\n\n\n\n
    \"\"\/<\/figure>\n\n\n\n
    Now that we have implemented both the GitOps approaches, let us summarize how they differ, when to use the pull approach, and when to use the push approach.<\/p>\n\n\n\n
    Push vs. Pull-based GitOps<\/h2>\n\n\n\n
    The push and pull approaches in GitOps differ in control, setup complexity, and deployment speed. The push approach offers centralized control through CI\/CD tools, allowing for high flexibility with customizable pipelines but requiring a more complex setup. In contrast, the pull approach uses GitOps tools for decentralized automation, providing a more straightforward setup and automated rollbacks but with moderate deployment speed due to polling intervals.<\/p>\n\n\n\n
    \"\"<\/h3>\n\n\n\n
    When to Use the Push Approach<\/h3>\n\n\n\n