LinkedIn
Twitter
The latest version of Apigee Hybrid added Helm support, which makes it easier to integrate with popular CI/CD tools such as ArgoCD. In this article we will discuss two integration patterns.
ArgoCD Application with Helm Chart
ArgoCD supports Helm charts directly. It can pull the charts from a Helm repository or Git repository and apply the values.yaml provided either locally or from a different repository.
The following are the high-level steps to set it up:
- Add the Helm repository or Git repository hosting the Apigee Helm charts to an ArgoCD project. Make sure that ArgoCD has the permissions to pull the files.
- Create one ArgoCD application per Helm chart. Reference the repos defined in step 1, specify the chart version, and add appropriate values.
- Sync the ArgoCD applications in sequence to deploy the Apigee Hybrid environment. This can be done via the ArgoCD console, command line interface, or by setting up a GitOps workflow.
After the initial deployment is completed, we can set up the Apigee ArgoCD applications to monitor the Helm repository or Git repository and automatically sync up.
GitOps Style Approach for deploying Apigee Hybrid with ArgoCD
The diagram below describes the main steps to setup Apigee hybrid with helm charts using ArgoCD in a GitOps style manner.
The primary steps to set this up are below:
- Install cert-manager within the cluster (if it does not exist).
- Install the Apigee hybrid CRDs (custom resource definitions).
- Create the applications for each of the Apigee hybrid components in ArgoCD.
- Deploy each of the ArgoCD applications into the cluster and observe the pods being created.
- Monitor the created Kubernetes resources for each of the Apigee hybrid components.
ArgoCD Applications
Here is a sample ArgoCD application that deploys Apigee Operator from the Helm chart repo and pulls the values file from a Git repo’s dev branch:
In the above example, the Apigee chart is hosted in the public Helm repo us-docker.pkg.dev/apigee-release/apigee-hybrid-helm-charts, while the input values are hosted in a separate Git repository testrepo. This approach separates the public helm charts from the environmental specific configuration parameters.
We can also create an ApplicationSet or App of Apps to orchestrate the multiple helm charts deployment, leverage ArgoCD ‘waves’ feature to group the Apigee helm charts into different orders in deployments. However, this is more complicated and requires careful planning and execution.
During our tests, we found the changes in values.yaml file do not always trigger a sync in ArgoCD applications automatically, sometimes you may need to force the sync.
Another drawback is that all the templating is done by ArgoCD during runtime, sometimes it is hard to track down the changes affected by a particular value modification.
These limitations lead to the other approach we will discuss below.
GitOps with Helmfile and ArgoCD
Helmfile is an open source tool that handles helm charts deployment in a declarative way, it can be used to keep a directory of chart value files and maintains changes in a revision control system such as Git. When integrated with ArgoCD, it provides an automated CI/CD workflow that applies the desirable state with better visibility and reproducibility.
So the other approach to deploy Apigee Hybrid is to use the Helmfile template command to generate all-in-one Kubernetes manifest files from the Helm charts and input values, then check them into a Git repository for use with ArgoCD or other Kubernetes continuous deployment tools.
ArgoCD is set up to monitor the Kubernetes manifests in the Git repo and deploy the charts to the target cluster. Git hub tracks the changes in the Kubernetes manifests and it is more transparent on the exact changes to be applied during the approval process.
Here are high level steps when use this approach:
- Create a helmfile to list the repositories and release information;
- Create values files and check in to private repositories;
- Run helmfile command with templating option to generate Kubernetes manifests in a target directory;
- Check in the newly created Kubernetes manifests files to a Git repository;
- Configure ArgoCD applications to monitor the Git repository used in step 4, pull the files and apply if a change is detected.
Step 3 and 4 above can be automated with Continuous Integration tools, when a change in helmfile or in values occurs, the CI tool runs the helmfile command and check in the updates in Git repository.
A sample Helmfile looks like this:
The overrides.yaml file in the above example is located in the local directory where the helmfile command runs. Helmfile uses needs to establish the dependency relationship between the helm releases. Helmfile can deploy the helm releases defined in the git repository.
A sample command in step 3 looks like this:
This will generate all Kubernetes manifests under the output directory:
In a manual process, the output directory is a local Git directory, we can use git diff to check the changes made to the Kubernetes manifests. Once all changes are good to go, we can commit and push the changes back to the Git repository, and create a pull request. This process can be automated with CI tools, check out helmfile, run helmfile commands, check in files and create pull requests, then leave the review and approval for manual process. Once review and approval are done, changes will be merged into the target branch and ArgoCD will be triggered.
ArgoCD is set up to monitor the changes in the Git repo and takes actions. ArgoCD can be configured to automatically sync and apply the changes. For certain components we may also use manual sync so that we can have time to verify its dependent components are fully functional. ArgoCD in this case is only responsible to sync the target cluster to the desired state defined in the Git repo, there’s no templating or other changes in ArgoCD, the Git repository becomes the source of truth.
A sample ArgoCD app looks like this:
The configuration Git repository can be private so that sensitive information is protected. There are ArgoCD plug-ins that can be used to protect the information, and control the sync process, etc.
Conclusion
In this document, we discussed two ways to deploy Apigee Helm charts with ArgoCD, one uses the helm charts directly and the other leverages helmfile tool to generate the Kubernetes manifests then ArgoCD simply deploys them. Both follow the GitOps model with different granularity, and additional continuous integration tasks can be used to fully automate the deployment and update processes.
