How we killed our Jenkins đź’€
Github Action + Self-hosted Runners helped us toss our old Jenkins
Jenkins is a great tool. It has been with me since the beginning of my career as a developer. You can do everything or in other words, there is nothing that Jenkins cannot do. From automating repetitive tasks to crypto mining.
But when I started to focus on operational topics like Kubernetes, Docker and Helm and was responsible for the continuous deployment and integration of our micro services, I saw this tool from a different perspective.
Github Actions: A New Hope
Too often I found myself searching for documentation for hours. Too often, delivery stopped because plug-ins were updated or could not be loaded when starting up.
Each time the desire for something better grew within me. When the beta phase of Github Action began last year, I wasn’t really convinced at first. But I quickly let Github Actions do small tasks and so I grew in confidence that this could be an alternative to Jenkins. Finally, a tool that I didn’t have to worry about and that all developers could use.
We quickly switched one project after another to Github Actions. The team quickly recognized the advantages of the Github Actions and independently created and modified the pipelines.
But there were also things that weren’t going so well. Our builds were very slow at first. The overview was missing because the individual steps of the pipeline were distributed in different Github projects. And finally, of 61 projects, seven remained that still had to be built in Jenkins. In order to be able to build these seven projects, they must have access to our development environment.
The moment when Github self-hosted runners appeared
As the name suggests, Github also offers you the option of hosting your own runners on which the action is carried out. This has several advantages.
You can determine the underlying instance and thus CPU and RAM in order to maintain speed during construction processes. In addition, these runners run in our own environment and not in the Azure cloud like those hosted by Github. So now I run the self-hosted runners in our development environment and thus solve our last problems. Fortunately, there is a solution for every problem in the Kubernetes world. And I found this one:
I quickly built myself a Helm chart, as it wasn’t available for the runner-controller and the runner-deployment yet. Then Flux releases the runner-controller and the runner-deployment together with the required cert-manager. And finally I built a custom Docker image based on the runner in which Maven is contained.
FROM summerwind/actions-runner-dind:v2.273.5
ENV LC_ALL=C
ENV JAVA_TOOL_OPTIONS='-Dfile.encoding=UTF-8'
RUN sudo apt update -y \
&& sudo apt install -y openjdk-11-jre-headless maven \
&& sudo rm -rf /var/lib/apt/lists/*Ready for Action
In our Github organization I set up a runner group for our team and added the self-hosted runners by configuring them. I helped the initiators of the runner-controller project a little and thereby hope to give something back to the community.
The runner controller provides a horizontal runner autoscaler, comparable to the horizontal pod autoscaler. This means that runners are created or removed again as required.
And finally, it arrived. The day there was no more Jenkins. Sometimes I miss the times when I was greeted after my vacation with the words: “Thank God you’re back. You absolutely have to take care of the Jenkins first”. But only for a moment…
