Local Kubernetes Development simplified with Skaffold
In one of our previous blogs Skaffold — Kubernetes-native app development simplified,we talked about the basics of Skaffold and how it is responsible for quick & automated deployment of Kubernetes applications. Skaffold is an amazing tool when it comes to working around application source code locally while having it continually updated. And, simultaneously it also gets prepared for testing in the local or remote Kubernetes clusters. As a developer, all of us must be running large Kubernetes cluster withhundreds of QA cluster nodes. In this blog, I will try to elaborate more on using Skaffoldto create a separate kube (isolated environment) for both development and testing as per the requirements. This provides developers and testers with the freedom to run their tests easily without hindering cross commits between multiple developers. Jenkinsbeing an open source automation server that automates the parts of software development here triggers the CI/CD pipeline only when a pull request is made into the mainline branch.
Hackernoon in one of its interesting blogs has represented a visual of the master branch and it’s working as below -
Whenever a developer is about to complete an application feature, a pull request is made which triggers the Jenkins CI/CD pipeline. Now consider a scenario where a developer wants to get the code deployed as well as tested without creating a pull request, do you think it will be possible? The answer is no. Even if the team finds out a solution for the developer, the developer still has to wait until the build gets deployed. Now, what if during the deployment the CI/CD pipeline fails? DevOps looks after the failures but for a considerable time the development and testing would have to wait and this can impact the deliverables.
With the increase in project complexity, there is always a need to have some solutions for continuous development. Something quicker than continuous integration where you can get the changes with each commit on your local machine and do not have to wait & check the CI stage status. Minikube is one such solution where you have to build aDocker image whenever a commit is made. Then you can go on and change the manifests files with the images created.
When it comes to the local development of the Kubernetes environment you can trust Google Skaffold. It is easy to use and does not require much in-depth technical knowledge. As soon as you run a single command on your local you can instantly see the changes on your namespace.
When to use Skaffold and how it can help you speed up the local development?
Consider that you are having multiple microservices where each developer is working on them separately. Few developers are working on the front-end (React) and few of them on the back-end (Node.js) services which might have a separate database for each of them respectively. Your product has been deployed into production successfully. But your work doesn’t end here as you are also responsible to speed upthe DevOps process. This is important as your team would be waiting to test the CI pipelines and get it deployed into the QA environment to get the feedbacks. This wait for the commit results leads to wastage of your team’s time. DevOps is all about getting recurring feedbacks about your process, codes, and testing. What if you could somehow speed up the feedback arrival process? Here, I would like to mention that before heading toward Skaffold you should have a very clear understanding of the CI/CD process along with the basic knowledge of YAML. Whenever changes are required to be done in the microservice just create a feature/fix branch.
In this blog, to explain how you can run the continuous integration I have created a pull request into master as depicted in the image mentioned earlier. Now, let’s discuss how you can start with Skaffold continuous development on your local machine. First, clone your microservices on your local machine and create a skaffold.yaml file. Below I have cloned two microservices one is for the front-end and the other one for the back-end. You should have a similar repository structure while using the Skaffold. The repository should have a Dockerfile, Kubernetes manifests or Helm charts, skaffold.yaml, and at last a service source code.
Microservice-1 repository…read more.
