When using Jenkins within your cluster as a Dockerized service to chain-build all other images, it is important for me to mention a common pitfall where you will inevitably have the issue with new deployments where Jenkins is not available initally since at the cluster initialization stage no images are usually available in the registry and the default Jenkins Docker image is not configured in any way. On top of all this, since you often need an already-running Jenkins instance to build a newer Jenkins image, you will be in the the classic Catch-22 situation. You may have a reflex to build Jenkins manually as a followup deployment step, but you must resist the urge to do so if you want to really have infrastructure that is mostly hands-off.

The general workaround to this is problem of bootstrapping Jenkins on a clean cluster has generally been something as shown in the following diagram:

The cluster deployment is done first to ensure that we have a way t build our bootstrap image, and the Docker Registry is used to store the image after it is built. Following this, we build the Jenkins image on any available Docker Engine node and push it to the registry so that the service will have the right image to start with. If needed, we then launch the mentioned service using the same configuration management tool (like Ansible) or the orchestration tooling and wait for the auto-start job that will build all other remaining images which should populate the registry with all the other images needed to run the full cluster. The basic idea here is to do the initial bootstrap through CM tooling and then let the Jenkins service rebuild all the other images and (re)start the tasks.