Sounds crazy, right? At the end of this article, I will prove with a video that this is possible. What we want to achieve is to see our code as fast as possible running in Kubernetes after we've pushed it to our GIT-Repository.
But let's first have a look at a traditional deployment:
➡️ Push your changes to the repository to trigger a build job
1) Buildcontainer starts and installs all requirements
2) Fetch the code on the Buildcontainer
3) Build the actual software
4) Build the Docker image
5) Push the Docker image
6) Trigger an update on Kubernetes (ArgoCD or similar)
7) Pull the new build Image
8) Run the new image and wait for the health check to come up.
Seems like a lot of work. This means a lot of time passing by and a lot of potential failures in this chain.
How about just keeping the essential steps:
➡️ Push your changes to the repository to trigger a webhook
1) Fetch the Code
2) Build the actual software
3) Run the Code.
That's exactly how Kubero works.
Kubero is an free and open-source PaaS for Kubernetes. It comes with a UI, API, and CLI and connects directly to your GIT repository. Therefore it is also possible to automatically start a preview instance within 14 seconds.
But there are even more benefits: Kubero uses official maintainer images to build and run the code. No need to write and maintain a Dockerfile.
The maintenance of the CI/CD pipeline is also eliminated since all these tasks are performed by Kubero. Kubero itself is automatically maintained as it is an operator with a single UI-Container.
But you might be wondering what happens when there are hundreds of pods running in production. Building the app for every running pod is not efficient. Thats why Kubero supports running pre built images too.
And finally the proof:
Oldest comments (0)