Use GitOps to combine infrastructure and application services

The GitOps operational framework is built around the developer experience and is designed to help teams manage infrastructure and applications by using the same tools and processes that they use for software development. With GitOps in the real world, however, there are lots of tools for accomplishing different tasks. This can raise questions such as Which tools should I use? and How should I use them? This article describes what GitOps is and introduces you to the control plane, which contains tools to help you manage infrastructure and application configurations when putting GitOps into practice.

Core concepts

GitOps uses Git as a single source of truth for declarative infrastructure and application code. It evolves DevOps best practices (such as version control, collaboration, compliance, and CI/CD) and Infrastructure as Code (IaC) to perform operations on infrastructures and modern cloud-native applications. It does this by putting the descriptive code for cloud infrastructures and applications into Git repositories for processing and version control. You then use automation to apply any changes to the infrastructure.

GitOps can be applied not just to classic infrastructures such as virtual machines (VMs), but also to Kubernetes, network configurations, application definitions, and resources that are described by config files and applied to an environment through automation. This means that GitOps incorporates IaC as well as Network as Code, Configuration as Code, Security as Code, and more.

Argo CD is a Kubernetes-native declarative continuous delivery (CD) tool that follows the GitOps methodology.

Crossplane is an open source Kubernetes add-on that transforms your cluster into a universal control plane. With Crossplane, platform teams can assemble infrastructures from multiple vendors, and application teams can consume higher-level, self-service APIs without having to write any code.

Putting it all together

With GitOps, the application source code and declarative environment configuration are stored in a Git repo. You review the application source code and make changes by using a pull request. Your continuous integration (CI) pipeline detects the changes and triggers the build into an artifacts repository. Your site reliability engineer (SRE) makes changes to the environment configuration in the Git repo and merges the changes after the review process.

The control plane includes Argo CD and Crossplane. You can use Argo CD to deploy and upgrade Crossplane providers, and to deploy and manage your cloud-native applications. Meanwhile, Crossplane extends your Kubernetes cluster to support infrastructure orchestration through different types of providers based on your config file. For example, provisioning a virtual private cloud (VPC), Kubernetes, or Red Hat OpenShift platform environment from IBM Cloud through provider-ibm-cloud, deploying infrastructure from Amazon Web Services (AWS) through provider-aws, or deploying resources from Google Cloud Platform (GCP) through provider-gcp. If your config file is updated, then Argo CD can detect the changes and get the update through a pull change. The same thing happens to the image file where Argo CD detects the modification and gets it through a pull image.

Just to clarify, in the control plane, Argo CD is responsible for deploying and upgrading Crossplane providers. Crossplane provisions infrastructure resources through the Crossplane providers. Argo CD deploys and synchronizes your application with the infrastructure that is provisioned by Crossplane. Argo CD detects the change through Git, which works as a single source of truth for declarative infrastructure and applications.

With declarative descriptions in a Git repo, you can manage all of your resources from the infrastructure layer to the application layer, as illustrated in the following diagram of an IBM Cloud example.

GitOps practice example

Practice example

Kubernetes is a basic requirement for Argo CD and Crossplane. With the Argo CD application, you can combine the infrastructure and application service. For example, let’s say you are using OpenShift in an instance where your control plane is running. Here are the steps for the example implementation:

  1. Install Argo CD. With OpenShift, you just need to install the Red Hat OpenShift GitOps Operator, which already contains Argo CD.

  2. Install Crossplane. In this example, you need to install the Upbound Universal Crossplane (UXP) Operator in the same manner that you installed the OpenShift GitOps Operator.

    With Argo CD and Crossplane installed, your control plane is ready.

  3. Deploy provider-ibm-cloud through Argo CD as follows:

     apiVersion: argoproj.io/v1alpha1
     kind: Application
     metadata:
      name: provider-ibm-cloud
      namespace: openshift-gitops
      finalizers:
        - resources-finalizer.argocd.argoproj.io
     spec:
      project: production
      source:
        path: ibmcloud   #crossplane ibmcloud provider code path that manages the IBM Cloud Kubernetes Service or Red Hat OpenShift on IBM Cloud instance
        repoURL: git@github.ibm.com:example/gitops-practice.git #change to the repo where the provider is in
        targetRevision: HEAD
      destination:
        server: https://kubernetes.default.svc
      syncPolicy:
        automated:
          selfHeal: true
          prune: true
    

    After you install and configure the provider-ibm-cloud, you should be able to provision resources from IBM Cloud. For the purpose of this practice example, let’s say that you provision an OpenShift cluster that has an IP address of https://your.target.infrastruture.IP.

  4. Deploy your application to the target OpenShift cluster by using Argo CD as follows:

    apiVersion: argoproj.io/v1alpha1
    kind: Application
    metadata:
      name: apps
      namespace: openshift-gitops
      finalizers:
        - resources-finalizer.argocd.argoproj.io
    spec:
      project: production
      source:
        path: rebot-shop  # change to the path where your application is
        repoURL: git@github.ibm.com:example/gitops-practice.git  #the repo for your application
        targetRevision: HEAD
      destination:
        server: https://your.target.infrastruture.IP  #the target cluster where your application is deployed to
        namespace: production
      syncPolicy:
        automated:
          selfHeal: true
          prune: true
          allowEmpty: true
        syncOptions:
        - CreateNamespace=true
    

After your code is ready, you can put the previous config file into a YAML file and then deploy it in Argo CD. Then you can provision the infrastructure, even if you don’t care where the infrastructure is from, and automatically manage your application. This allows you to focus on your core application — which is the main reason for using GitOps!

Summary

This article started by exploring basic GitOps concepts and introduced you to the Crossplane and Argo CD open source tools. We then demonstrated how Crossplane can help you assemble infrastructure resources from multiple vendors and how Argo CD can help you manage Crossplane and Kubernetes applications.

Providers extend Crossplane to enable infrastructure resource provisioning. You can use the existing providers that are provided by Crossplane, such as provider-ibm-cloud, provider-aws,provider-gcp, provider-azure, and provider-rook. You can also write your own providers if you prefer.

The practice example showed you how to provision infrastructure resources from IBM Cloud through Crossplane. If you want to know how to deploy infrastructure resources from another cloud vendor, you can find detailed information in the Crossplane community.

For more information about GitOps, check out these resources: