In the previous blog, I demonstrated how to deploy a Pulsar cluster using operators. The operators make Pulsar deployment much easier than the installation using Terraform or Ansible.
In this blog, I will demonstrate how to use ArgoCD to control Pulsar Custom Resources (CRs) by monitoring the GitHub branch/tag. In Part 1, you can see that the CRs stored in your local environment work properly in a demo/poc environment. When dealing with a production system, you will face configuration or infrastructure drift (too many chefs in the kitchen situation). GitOps uses git mechanisms to control CR versions in GitHub repositories with branches or tags. This allows you to easily control, roll back, and upgrade the configurations of your deployment, or find related historical changes.
1. Create a GitHub repository (pulsar-ops in this example) to keep track of the CRs. ArgoCD will track the changes in a folder of a branch, so I put all the CRs under the default folder.
3. Now I can go to the ArgoCD Web UI to create a Pulsar cluster app. Log in to ArgoCD, create a new app with the following information, then click CREATE. Note that for Revision, I used Tags for demo. You should use branches in your production environment.
4. After the app is created, ArgoCD will scan the specific tag/branch (hashcode) and sync the CRs to deploy the Pulsar cluster as we did in Part 1 using kubectl apply -f. The app detail shows the progress of the deployment.
5. A few minutes later, ArgoCD will display the synced status and you can find all the manifests and their relations. Once everything is green, ArgoCD will keep watching the tag/branch and make sure the current cluster state matches the CRs in the tag/branch. If someone manually modifies the CRs or other generated manifests (kubectl edit <cr.yaml>), ArgoCD will detect the drift and change the CR back to match the tag/branch. The only way to change the configuration of the cluster is using git operations.
6. Next, use git push and submit pull requests to control the CR details, such as adding JVM options and changing replicas of CRs. If everything works well, ArgoCD should be able to detect the changes and auto-apply the operation changes.
7. Change the image version from 126.96.36.199 to 188.8.131.52 and commit the changes.
8. After committing the changes, retag the commit to v2.9 and push with the force option.
12. Run the git commands to force retagging the new commit to v2.9 and to force pushing it to the remote origin branch. Note that I used --force to retag the change. In your production environment, you should go through the PR and review process.
deployment git:(main) git add default/br-cluster.yaml
deployment git:(main) git commit -m 'scale up broker to 3'
[main 32e0468] scale up broker to 3
1 file changed, 1 insertion(+), 1 deletion(-)
deployment git:(main) git tag -a -f v2.9 32e0468
deployment git:(main) git push origin v2.9 --force
Counting objects: 100% (8/8), done.
Delta compression using up to 10 threads
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 516 bytes | 516.00 KiB/s, done.
Total 5 (delta 2), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
+ fc5fb8d...13bf247 v2.9 -> v2.9 (forced update)
13. Once the code is pushed to the same tag, you should find the new broker (my-broker-2) running in the ArgoCD web UI.
With ArgoCD and GitHub, you can control Pulsar CR changes in an elegant way. Moreover, you can easily roll back and approve configurations, or find the change history from the GitHub repository.
In the next blog Part 3, I will demonstrate how to containerize Pulsar client apps using Dockerfiles. In Part 4, I will demonstrate how to use kpack to build Pulsar client apps without local Docker builds.
More on Apache Pulsar
Pulsar has become one of the most active Apache projects over the past few years, with a vibrant community driving innovation and improvements to the project. Check out the following resources to learn more about Pulsar.
YuWei Sung is a Solutions Engineer at StreamNative. His career portfolio includes urban planning/geospatial analysis, data mining/machine learning, and distributed data systems. He has been in the field (presales, postsales, and a bit of support) for about a decade (EMC, Dell, Pivotal, VMware, and Yugabyte).