If we exclude the case of entering AWS key, our Jenkins setup is fully automated. Kubernetes plugin is preconfigured to support Pods running in other Namespaces, Google and AWS clouds will be set up if we choose to use them, credentials are copied to the correct locations, and they are using the same encryption keys as those used to encrypt the credentials in the first place. All in all, we're finally ready to work on our continuous deployment pipeline. The next chapter will be the culmination of everything we did thus far.

Please note that the current setup is designed to support "one Jenkins master per team" strategy. Even though you could use the experience you gained so far to run a production-ready Jenkins master that will serve everyone in your company, it is often a better strategy to have one master per team. That approach provides quite a few benefits.

If each team gets a Jenkins master, each team will be able to work independently of others. A team can decide to upgrade their plugins without fear that they will affect others. We can choose to experiment with things that might cause trouble to others by creating a temporary master. Every team can have fine-tuned permissions on the Namespaces that matter to them, and no ability to do anything inside other Namespaces.

The productivity of a team is often directly proportional to the ability to do things without being limited with the actions of other teams and, at the same time freedom not to worry whether their work will negatively affect others. In Kubernetes, we get that freedom through Namespaces. In Jenkins, we get it by having masters dedicated to teams.

The Helm Chart we created is a step towards multi-master strategy. The Jenkins we installed can be considered dedicated to the team in charge of the go-demo-3 application. Or it can be devoted to a bigger team. The exact division will differ from one organization to another. What matters is that no matter how many Jenkins masters we need, all we have to do is execute helm install for each. Given enough resources in the cluster, we can have a hundred fully operational Jenkins masters in only a few minutes time. And they will not be Jenkins masters waiting to be configured, but rather masters already loaded with everything a team needs. All they'd need to do is create Pipelines that will execute the steps necessary for their application to move from a commit into production. That's the subject of the next chapter.

One more chapter is finished and, like all the others, the next one will start from scratch. Please use the commands that follow to clean up the resources we created or, if you're using a temporary cluster, go ahead and destroy it.

 1  helm delete $(helm ls -q) --purge
 2
 3  kubectl delete ns 
 4      go-demo-3 go-demo-3-build jenkins

If you created a VM using Vagrant, I suggest you suspend it instead of destroying it. That way we'll preserve the same credentials and will be able to reuse those we stored in cluster/jenkins/secrets/.

 1  cd cd/docker-build
 2 
 3  vagrant suspend
 4
 5  cd ../../

Take some time to enjoy what we accomplished so far. The next chapter will be the culmination of our efforts.