We are, finally, finished designing the first iteration of a fully functioning continuous deployment pipeline. All the subjects we explored in previous chapters and all the problems we solved led us to this point. Everything we learned before were prerequisites for the pipeline we just created.

We succeeded! We are victorious! And we deserve a break.

Before you run away, there are two things I'd like to comment.

Our builds were very slow. Realistically, they should be at least twice as fast. However, we are operating in a tiny cluster and, more importantly, go-demo-3-build Namespace has limited resources and very low defaults. Kubernetes throttled CPU usage of the containers involved in builds to maintain the default values we set on that Namespace. That was intentional. I wanted to keep the cluster and the Namespaces small so that the costs are at a minimum. If you're running a cluster in AWS or GCE, the total price should be very low. It should probably be less than a cup of coffee you had while reading the chapter. On the other hand, if you are running it locally, the chances are that you don't have a laptop in which you can spare much more CPU for the cluster (memory should be less of an issue). In either case, the critical thing to note is that you should be more generous when creating "real" production pipelines.

The second and the last note concerns the VM we're using to build and push Docker images. If you're using AWS or GCE, it was created dynamically with each build. If you recall the settings, the VMs are removed only after ten minutes of inactivity. Please make sure that period passed before you destroy your cluster. That way, we'll let Jenkins destroy the VM for us. If, on the other hand, you created a local VM with Vagrant, please execute the commands that follow to suspend it.

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

That's it. We reached the end of the chapter. Feel free to destroy the cluster if you're not planning to continue straight away.