Our Continuous Integration (CI) approach is one of “zero-infrastructure overhead”. To accomplish this goal, we utilize GitHub Actions to build and push a microservice’s associated container images to Docker Hub for public consumption. The GitHub Actions workflows are defined in the owning repository’s
Our GitOps approach focuses on a single-repository, environment-per-subdirectory model which can be forked and cloned to replicate deployments to other clusters and environments. The reference implementation utilizes Kustomize as its templating technology to utilize the
app-deploy.yaml files, provided by each individual microservice, as a base and then layer in environment-specific configuration and credentials as needed.
Our Continuous Delivery (CD) approach, the topic of this chapter, focuses on a GitOps-based delivery model, using a GitHub repository as a single source of truth for the deployment, management, and operations of our running application components. In this model, we have the flexibility to use multiple open-source technologies to apply the single source of truth from a given GitHub repository onto a desired cluster environment.
One of the main tools used in this space is a GitOps-focused continuous delivery project named ArgoCD. As documented by the IBM Garage for Cloud team, ArgoCD can monitor GitHub-based projects and apply changes stored in that repository’s YAML files to a running Kubernetes-based cluster.
We have documented our general GitOps strategy & methodology for generation of deployment source configuration files in the GitOps chapter of this manual, while the details of our ArgoCD-based deployments of those GitOps-based artifacts are covered in the ArgoCD deployments section below.
Our main continuous delivery pattern operates on the same principle of “zero-infrastructure overhead” as our continuous integration implementations. This allows us to be agile, adaptable, and efficient in what we deploy where. ArgoCD is a perfect companion to this principle, as we do not need additional long-running CD infrastructure to monitor either a source environment or a target deployment environment. Our CI process sits with our code (on the same hosted infrastructure), while our CD process sits with the target deployment environment (on the same Kubernetes-based cluster).
To utilize ArgoCD in this manner, we leverage the Appsody-based, Kustomize-extended Kubernetes YAML files that define the necessary
OpenLibertyApplication custom resources our application’s microservices require. ArgoCD will handle deploying the entirety of a single
environment subdirectory, as defined in the GitOps repository. For details on how the environments subdirectory and its component files are structured, refer to the peer GitOps Environments chapter of this manual.
An ArgoCD application is created on the ArgoCD server inside the target environment that can read from the GitOps repository. ArgoCD can also deploy between clusters, which does come in handy in certain use cases, but remember our squad’s goal of “zero-infrastructure overhead”, so we deploy from ArgoCD into the same cluster it is deployed on the majority of the time. The ArgoCD application is a Custom Resource Definition, comprising of the details necessary to determine the remote code repository URL, the branch of the code to use, the target namespace, and any formatting capabilities that are necessary.
ArgoCD then handles automatically (or manually) syncing and applying the deployments into the target namespace with the state that is described in the Kustomized YAMLs from the desired environment’s subdirectory in the remote GitOps repository.
- Ensure all necessary Kubernetes ConfigMaps and Secrets have been created in the namespace in which the application will be running. This may vary depending upon your level of exposure to the public Internet, as well as cluster tenancy.
- Ensure ArgoCD has been deployed to the local cluster with connectivity to the Internet. Reference: ArgoCD Operator Documentation
Using the ArgoCD dashboard
- Access the ArgoCD Dashboard via it’s exposed Route in the
argocdnamespace. This should be in the form of
- Depending upon your cluster and ArgoCD, you will have specific login credentials. Login as directed and click NEW APPLICATION.
- Enter the following parameters for the
devenvironment of the reference implementation and click CREATE.
- Application Name:
- Project: Select
defaultfrom the drop-down
- Sync Policy: Select
Automaticfrom the drop-down
- Repository URL:
- Cluster: Select
in-cluster (https://kubernetes.default.svc)(this is our local cluster)
- Namespace: Your desired target namespace
- Click the Directory section label and select Kustomize
- Application Name:
- Once the application is successfully created inside ArgoCD, you can click the application tile to see the latest status of the ArgoCD-managed, GitOps-deployed microservice instances. It should begin synchronizing immediately upon creation.
- As ArgoCD applies the desired configuration to the cluster, you should see the pods of the microservices being created:
kubectl get Pods
Using the command-line interface
ArgoCD provides a command-line interface as well, however we are not covering that in this reference implementation. Once you are satisfied with the ArgoCD dashboard-based deployment pattern, you can reference the ArgoCD Getting Started docs for further details on using the ArgoCD CLI and CRD YAMLs for programmatic interaction.
Once your ArgoCD-deployed application instances are deployed, synchronized, and running, you are ready to run the Integration Tests to validate your environment!