An Argonaut’s Journey

Genesis

It all began in late 2020 with a flurry of reports about Docker being faraway from Kubernetes. However what did all of it imply? Analysis ensued. It seems, solely Dockershim was being deprecated, now totally eliminated in v1.24. The next quote caught my eye.

One factor to notice: In case you are counting on the underlying docker socket (/var/run/docker.sock) as a part of a workflow inside your cluster in the present day, transferring to a unique runtime will break your potential to make use of it. This sample is commonly referred to as Docker in Docker. There are many choices on the market for this particular use case together with issues like kaniko, img, and buildah.

Weren’t we utilizing Docker in Docker (dind) in Jenkins for all our employee nodes? Certainly. We had been utilizing dind.

This might be an ideal alternative to overtake our Steady Integration Steady Supply (CICD) with cloud native approaches comparable to kaniko, GitHub Actions, Argo Workflows, Tekton pipelines, ArgoCD, and Flux.

Background

We are utilizing Jenkins kubernetes plugin with monolithic containers for our staff. These photographs ranged between 3.5GB and 6.0GB in measurement. These containers had Java, Maven, Node, Chrome, Helm, Ansible, and extra. Consequently, it grew to become tough to handle these employee photographs. Moreover, Jenkins jobs would dangle momentarily as kubernetes pulled down new containers in the event that they weren’t current.

Many sources had been allotted to those staff starting from 1 core and 3Gi to 12 core and 30GI. To maintain prices down, we used preemptible nodes. This could disrupt Jenkins jobs with damaged connections and dangling staff. The job would must be rerun. A lower than stellar buyer expertise, and extra toil for us.

Jenkins runs as a single pod and isn’t resilient. It can’t scale horizontally, solely vertically. For essentially the most half, it runs fantastic, nevertheless, there have been cases the place it has gone down. Jenkins being stateful, requires a persistent quantity. One time, inodes had been exhausted and no person was capable of run their jobs. This required troubleshooting and handbook intervention to resolve.

Our Jenkins shared library has change into extra complicated over time—dealing with Helm 2 and three, Vault, deployments (kubernetes, cloud capabilities, and cloud run), DNS, Slack notifications, and extra. Troubleshooting and updating the shared library is tough, even for its maintainers. The library has change into uncared for and barely touched.

Lastly, the Jenkinsfiles and helm charts had been coupled with the appliance code in a single git repository. We had department safety enabled on our repositories and minor adjustments to Jenkinsfiles or Helm charts would require ready for unrelated Pull Request checks to run.

Technical debt was excessive. Issues had been tough to keep up.

Discovery

We wished to implement GitOps to benefit from infrastructure as code, git as a supply of fact, drift detection, and computerized decision. We learn comparability articles and watched DevOps Toolkit for ArgoCD and Flux, the principle contenders in GitOps for kubernetes.

On the time of analysis, Flux didn’t have a Consumer Interface, was restricted to a single repository per set up, and was Command Line Interface oriented, all of which weren’t user-friendly. ArgoCD had a pleasant UI, supported Single Signal On, allowed multi-tenancy, and had a single pane of glass view. In our opinion, ArgoCD was the clear winner.

A pipeline was required to construct our photographs and exchange all of our Jenkins jobs. Tekton and Argo Workflows had been to be evaluated. GitHub Actions was opted out because of its unreliability and outages on the time. Moreover, it couldn’t discuss to our inside endpoints with out establishing inside runners and lacked a single pane of glass view.

Tekton had a big neighborhood, an lively and expansive hub, and was a spine for JenkinsX. Argo Workflows had a small catalog and CodeFresh had a hub of its personal for workflows. Argo Occasions additionally appeared attention-grabbing with GitHub triggers to fireplace off workflows.

Finally, we selected Argo Workflows and Occasions because of the tight coupling with ArgoCD and the whole Argo Mission. This did require spending extra time to construct out our workflows, however we felt it was price it to have a correct basis and Jenkins might handle the work till we stood Argo up.

Wanting Again

A yr into our Argo journey, we now have arrange most of our cluster bootstrap with ArgoCD, even ArgoCD-ing ArgoCD (argo-ception). Argo Workflow templates had been created for constructing containers with kaniko, sending Slack messages, updating utility units, refreshing, syncing, and ready for ArgoCD functions, updating DNS, and deploying cloud capabilities and cloud run functions. We now have migrated a handful of current functions to ArgoCD, all of the whereas onboarding new ones. We even powered an insights and analytics e-newsletter with Argo Workflows!

Wanting Ahead

We have migrated our core functions and are persevering with emigrate off of Jenkins. A complete cluster refresh is in retailer, together with our containerd migration, as soon as we migrate all our apps to ArgoCD. Ultimately, we want to even handle our infrastructure with ArgoCD and Crossplane.

Argo has graduated the Cloud Native Computing Basis, proving its robustness and validating our choice to make the most of Argo. Argo will empower us to do many thrilling issues with ease. We’re wanting ahead to implementing right-sizing, value optimizations, coverage as code, infrastructure as code, and extra. Keep tuned for extra articles!