Bozobooks.com: Fullstack k8s application blog series
GitOps for BookInfoService Quarkus Application with GitHub actions and ArgoCD
Chapter 5: In this blog, we will build the pipeline to build and deploy the Book Information service that we implemented in Chapter 3. We will be using GitHub Actions for Build and ArgoCD to deploy to our local cluster.
--
In Chapter 4 we walked through the overall GitOps architecture and approach, Please read that chapter, before u go any further. In that chapter, we also created the base infrastructure.
In this blog, we will write the pipeline code for the BookInfoService microservice. The following is the logic for the CI/CD pipeline, that we will be implementing in this blog. We will be implementing a multi-stage workflow, one for Dev and one for Production (AWS). We will cover the production workflow in another blog. We will have a human-interaction approval before we promote the build to production.
Let's go through the steps of creating the workflow
First of all, we need to create a GitHub actions workflow. For that go to the application Git repository, and select the “Actions” tab, you should see the “New workflow” button as shown in the below screenshot
Click on the “New workflow” button, this will take you through the process of creating a workflow. Select an empty workflow.
Lets create two environments (as we will be implementing a multi-stage workflow). To create environments, we have to go to Settings->environment, and create two environments — “development” and “production”. For production, we will set a protection-rule for production. The below screenshot shows the environments
Lets now walk through the development workflow code, you can find the complete code here
- Line 12 — we are specifying the trigger as
on pushof the code. - Lines 13 — we are specifying the target branch.
- Line 18 — we are specifying that this workflow can also be invoked manually, with
workflow_dispatchconfiguration parameter - Line 23–27— we are setting the environment variables, that will be used in the workflow.
- Line 30 — suggests that this is a DevDeploy stage. We will be having 2 stages in the workflow, the first one is to deploy to the development environment and the second one is to deploy to the production environment, and between these two deployments, we will have human approval, before we promote the dev build to production. As you saw earlier in the chapter, we defined these environments and for production, we defined the protection rule.
There are multiple strategies for promoting the code from dev to production, which are little advanced, that we use at the enterprise scale. To keep this blog more easy to understand, we are using simple buildnumber-based multi-stage deployment. There are other strategies like Branch-based promotion, tag-base promotion etc, which we will not go through
- Line 36–37 — We are checking out the latest code
- Line 39–42 — We are generating a new build number
- Line 42–45 — We are printing the generated build number
- Line 47–58 — We are firing a slack notification with the build status using the
ravsamhq/notify-slack-action@v2plugin, and passing the slack webhook we created in Chapter 4 - Line 60–67 — We are moving in the application folder, and building a native build using maven
./mvnw package -Dnativeafter that, we are printing the current docker images before we build a new docker image with the native image that got generated in line #64. We are once again logging the docker images, to compare and make sure the new image is created (for debugging purposes).
- Line 69–80 — We are once again sending a slack notification, with the status
- Line 82–86 — We are logging into the docker hub using the secrets that we defined in Chapter 4.
- Line 89–92 — We are tagging the image, that we built in Line #66, and pushing this image to DockerHub
- Line-94–105 — We are sending a slack notification with the status
- Line 107–114 — We are invoking the Infrastructure workflow, passing the build number. Refer to Chapter 4, on how we configured the dispatch API.
This will invoke the Infrastructure workflow. Following is the screenshot of the infrastructure workflow. (This is created in the infrastructure code repository as a separate action). You can find the code here
Line 5–8 — We are defining the dispatch type. deploy-book-info-service-infra-updated-build, and this is the same used when we invoked the dispatch from the application workflow
- name: Invoke book-info-service Infra GitOps pipe
run: |
curl -H "Accept: application/vnd.github.everest-preview+json" \
-H "Authorization: token ${{secrets.API_TOKEN_GITHUB}}" \
--request POST \
--data '{"event_type":\
"deploy-book-info-service-infra-updated-build", \
"client_payload": { "buildnumber": "'"$BUILD_NUMBER"'" }}' \
https://api.github.com/repos/abvijaykumar/book-library-kube-infra/dispatchesLine 16–17 — We are checking out the infrastructure code (Kubernetes manifests)
Line 24–32 — We are using fjogeleit/yaml-update-action@main a plugin to update dev/bozobooks-manifests/deployment-manifests/book-info-service-deployment.yaml, updating the image property with the latest building number, and pushing it back to the main branch.
This change will trigger the ArgoCD in the dev cluster, as it is listening to the changes in this Infrastructure code, and will refresh the cluster with the latest deployment
There you go, this is how the application automatically gets built and deployed. We will be including application testing and infrastructure code testing as part of this pipeline in a separate blog so that we have a completely automated pipeline. We will also be exploring resiliency testing in the coming chapters.
Find below a quick screenshot demo of how a git push triggers the workflow and the slack notifications, that we get on the status
Find below the screenshot of the ArgoCD sync. Once all the blogs are done, I will record a full video with voice-over, and release it on youtube.
That's all for now..see you soon..take care and have fun…
Please leave your feedback and comments…
