Thursday, July 23, 2015

Clustering Jenkins with Kubernetes in the Google Container Engine

While we’ve already discussed how to use the Google Container Engine to host elastic Jenkins slaves, it is also possible to host the master itself in the Google Container Engine. Architecting Jenkins in this way lets Jenkins installations run more frictionlessly and reduces an administrator’s burden by taking advantage of the Google Container Engine’s container scheduling, health-checking, resource labeling, and automated resource management. Other administrative tasks, like container logging, can also be handled by the Container Engine and the Container Engine itself is a hosted service.

What is Kubernetes and the Google Container Engine?
Kubernetes is an open-source project by Google which provides a platform for managing Docker containers as a cluster. Like Jenkins, Kubernetes’ orchestrating and primary node is known as the “master”, while the node which hosts the Docker containers is called a “minion”. “Pods” host containers/services should on the minions and are defined as JSON pod files.


The Google Cloud Platform hosts the Google Container Engine, a Kubernetes-powered platform for hosting and managing Docker containers, as well as the Google Container Registry, a private Docker image registry hosted on the Google Cloud Platform.  The underlying Kubernetes architecture provisions  Docker containers quickly, while the Container Engine creates and manages your Kubernetes clusters.

Automating Jenkins server administration
Google Container Engine is a managed service that uses Kubernetes as its underlying container orchestration tool. Jenkins masters, slaves, and any containerized application running in the Container Engine will benefit from automatic health-checks and restarts of unhealthy containers.
The how-to on setting up Jenkins masters in the Google Container Engine is outlined in full here.


The gist is that Jenkins master runs from a Docker image and is part of a Kubernetes Jenkins cluster. The master itself must have its own persistent storage where the $JENKINS_HOME with all of its credentials, plugins, and job/system configurations can be stored. This separation of master and $JENKINS_HOME into 2 locations allows the master to be fungible and therefore easily replaced should it go offline and need to be restarted by Kubernetes. The important “guts” that make a master unique all exist in the $JENKINS_HOME and can be mounted to the new master container on-demand. Kubernetes own load balancer then handles the re-routing of traffic from the dead container to the new one.
The Jenkins master itself is defined as a Pod (raw JSON here). This where ports for slave/HTTP requests, the Docker image for the master, the persistent storage mount, and the resource label (“jenkins”) can all be configured.
The master will also need 2 services to run to ensure it can connect to its slaves and answer HTTP requests without needing the exact IP address of the linked containers:
  • service-http - defined as a JSON file in the linked repository, allows HTTP requests to be routed to the correct port (8080) in the Jenkins master container’s firewall.
  • service-slave - defined in the linked JSON file, allows slaves to connect to the Jenkins master over port 50000.


Where do I start?
  1. The Kubernetes plugin is an open-source plugin, so it is available for download from the open-source update center or packaged as part of the CloudBees Jenkins Platform.
  2. Instructions on how to set up a Jenkins master in the Google Container Engine are available on GitHub.
  3. The Google Container Engine offers a free trial.
  4. The Google Container Registry is a free service.
  5. Other plugins complement and enhance the ways Docker can be used with Jenkins. Read more about their uses cases in these blogs:
    1. Docker Slaves with the CloudBees Jenkins Platform



Tracy Kennedy
Associate Product Manager
CloudBees 

Tracy Kennedy is an associate product manager for CloudBees and is based in Richmond. Read more about Tracy in her Meet the Bees blog post and follow her on Twitter.

On-demand Jenkins slaves with Kubernetes and the Google Container Engine

In a previous series of blogs, we covered how to use Docker with Jenkins to achieve true continuous delivery and improve existing pipelines in Jenkins.


The CloudBees team and the Jenkins community have now also created the Kubernetes plugin, allowing Jenkins slaves to be built as Docker images and run in Docker hosts managed by Kubernetes, either on the Google Cloud Platform or on a more local Kubernetes instance. These elastic slaves are then brought online as Jenkins schedules jobs for them and destroyed after their builds are complete, ensuring masters have steady access to clean workspaces and minimizing builds’ resource footprint.

What is Kubernetes and the Google Container Engine?
Kubernetes is an open-source project by Google which provides a platform for managing Docker containers as a cluster. Like Jenkins, Kubernetes’ orchestrating and primary node is known as the “master”, while the node which hosts the Docker containers is called a “minion”. “Pods” host containers/services should on the minions and are defined as JSON pod files.


The Google Cloud Platform hosts the Google Container Engine, a Kubernetes-powered platform for hosting and managing Docker containers, as well as the Google Container Registry, a private Docker image registry hosted on the Google Cloud Platform.  The underlying Kubernetes architecture provisions  Docker containers quickly, while the Container Engine creates and manages your Kubernetes clusters.

Elastic, custom, and clean: Kubernetes slaves
As the demand on a Jenkins master increases, often so too do the build resources required. Many organizations architect for this projected growth by ensuring that their build/test environments are fungible, and therefore easily replaced and templated (e.g. as Docker images). Such fungibility makes slave resources highly scalable and resilient should some go offline or new ones need to be created quickly or automatically.


Kubernetes allows Jenkins installations to leverage any of their Docker slave images as templates for on-demand slave instances, which Jenkins can ask Kubernetes to launch as needed. The Kubernetes plugin now supports launching these slaves in any Kubernetes instance, including the Google Cloud Platform’s Container Engine.


Once a Kubernetes Pod running the slave container is deployed, the Jenkins jobs requesting that specific slave via traditional labels are built inside the Pod’s slave container. Kubernetes then brings the slave’s Pod offline after its build completes.


Where do I start?

  1. The Kubernetes plugin is an open-source plugin, so it is available for download from the open-source update center or packaged as part of the CloudBees Jenkins Platform.
  2. The Google Container Engine offers a free trial.
  3. The Google Container Registry is a free service.
  4. Other plugins complement and enhance the ways Docker can be used with Jenkins. Read more about their uses cases in these blogs:
    1. Docker Slaves with the CloudBees Jenkins Platform



Tracy Kennedy
Associate Product Manager
CloudBees 

Tracy Kennedy is an associate product manager for CloudBees and is based in Richmond. Read more about Tracy in her Meet the Bees blog post and follow her on Twitter.

Wednesday, July 22, 2015

Jenkins Container Support Juggernaut Arrives at Kubernetes, Google Container Registry

TL; DR:
Jenkins now publishes Docker containers to Google Container Registry.
Use Kubernetes to run isolated containers as slaves in Jenkins.


Last month, I wrote about exciting news with Jenkins namely its support for Docker. This month, I am happy to announce that Jenkins continues on its march for container technology support by providing support for Kubernetes.
Overview of all technology components in this blog:

Kubernetes
Kubernetes is a system to help manage a cluster of Linux containers as a single system. Kubernetes is an open source project that was started by Google and now supported by various companies such Red Hat, IBM and others.


Kubernetes and Docker
As teams graduate beyond simple use cases with Docker, they realise that containers are not really meant to be deployed as a single unit.The next question is, how to do you start these containers across multiple hosts, how can these containers be grouped together and treated as a single unit of deployment? This is the use case that Kubernetes solves.


Google Container Registry
The container registry is a service by Google to securely host, share and manager private container repositories and is part of the Google Container Engine service.

Interplay of these technology pieces


Kubernetes, Google Container Registry, Docker and Jenkins
While Kubernetes focusses on the deployment side of Docker, Jenkins focuses the entire lifecycle of moving your docker containers from development to production. If a team builds a CD pipeline, the pipeline is managed through Jenkins which moves the containers through the pipeline (Dev->QA->Prod) and the containers finally deployed using Kubernetes. Thus, the four technologies make for a powerful combination for building CD pipelines.


Kubernetes and Jenkins announcement
With Docker, I talked about 2 meta-use cases  
  • Building CD pipelines with Docker and 
  • Using Docker containers as Jenkins slaves.



Today, the Jenkins community brings both stories to the Kubernetes.


Use case 1: Building CD pipelines with Google Container Registry
The first use case enables teams to work with Google Container Registry (GCR). The community has taken the Docker Build and Publish plugin and extended it so that builds can publish containers to GCR. Details on this blog.


Use case 2: First class support for Jenkins Workflow
Jenkins Workflow is fast becoming the standard way to build real world pipelines with Jenkins. Build managers can use the Workflow DSL to build these pipelines The community has provided support for Kubernetes by adding a kubernetes DSL that launches a build within a Kubernetes cluster.


Use case 3: Running docker containers as Jenkins slaves through Kubernetes
One of the common issues in Jenkins is isolating slaves. Today, if an errant build contaminates the build machine, it may impact downstream builds. If these slaves are running as Docker containers, any “leakages” from previous builds is eliminated. With the Kubernetes plugin and Docker Custom Build Environment plugin, Jenkins can get a build slave from Kubernetes and run builds within the containers.


What’s Next?
The CloudBees and Google teams have collaborated on these plugins and you can expect to see more efforts to support more use cases between Jenkins and Kubernetes. Some of these use cases, involve piggy-backing on the Docker support released by the community (for example Docker Traceability and Docker Notifications plugin).

If you are a developer and want to contribute to this effort reach out on the Jenkins developer alias (hint talk to Nicolas DeLoof ;-))


Closing Thoughts:
The OSS community has innovated in the last couple of months, they have quickly added support for Docker and Kubernetes and have established Jenkins as the premier way to build modern real world continuous delivery pipelines.

I hope you have fun playing with all the goodies just released.

Where do I start?





Harpreet Singh
Vice President of Product Management 
CloudBees

Harpreet is the Vice President of Product Management and is based out of San Jose. Follow Harpreet on Twitter

Orchestrating deployments with Jenkins Workflow and Kubernetes

In a previous series of blogs, we covered how to use Docker with Jenkins to achieve true continuous delivery and improve existing pipelines in Jenkins. While deployments of single Docker containers were supported with this initial integration, the CloudBees team and Jenkins community’s most recent work on Jenkins Workflow will also let administrators launch and configure clustered Docker containers with Kubernetes and the Google Cloud Platform.

What is Workflow?
Jenkins Workflow is a new plugin which allows Jenkins to treat continuous delivery as a first class job type in Jenkins. Workflow allows users to define workflow processes in a single place, avoiding the need to coordinate flows across multiple build jobs. This can be particularly important in complex enterprise environments, where work, releases and dependencies must be coordinated across teams. Workflows are defined as a Groovy script either within a Workflow job or checked into the workspace from an external repository like Git.


Docker for simplicity
In a nutshell, the CloudBees Docker Workflow plugin adds a special entry point named Docker that can be used in any Workflow Groovy script. It offers a number of functions for creating and using Docker images and containers, which in turn can be used to package and deploy applications or as build environments for Jenkins.


Broadly speaking, there are two areas of functionality: using Docker images of your own or created by the worldwide community to simplify build automation; and creating and testing new images. Some projects will need both aspects and you can follow along with a complete project that does use both: see the demonstration guide.

Jenkins Workflow Deployments with Kubernetes
As mentioned in the previous blog, the Google Cloud Platform also supports pushing Docker images to the Google Container Registry and deploying them to the Google Container Engine with Kubernetes.

Jenkins Workflow now also supports using the Google Cloud Platform’s Container Registry as a Docker image registry. Additionally, it also exposes a few new Kubernetes and Google Cloud Platform-specific steps to complement Workflow’s existing Docker features. These steps allow Jenkins to securely connect to a given Kubernetes cluster, as well as remotely instruct the Kubernetes cluster manager to launch a given Docker image as a container in a Kubernetes Pod, change existing settings like the target cluster or context, and set the target number of replicas in a cluster.


Where do I start?

  1. The Workflow plugin is an open-source plugin, so it is available for download from the open-source update center or packaged as part of the CloudBees Jenkins Platform.
  2. The CloudBees Docker Workflow plugin is another open-source plugin available in the OSS update center or as part of the CloudBees Jenkins Platform.
  3. The Google Cloud Registry Auth plugin is an open-source plugin developed by Google, so it available to download from the open source update center or packaged as part of the CloudBees Jenkins Platform.
  4. The Kubernetes plugin is another open-source plugin  available from the open-source update center or packaged as part of the CloudBees Jenkins Platform.
  5. The Google Container Engine offers a free trial.
  6. The Google Container Registry is a free service.
  7. Other plugins complement and enhance the ways Docker can be used with Jenkins. Read more about their uses cases in these blogs:
    1. Docker Slaves with the CloudBees Jenkins Platform
    2. Docker Custom Build Environment plugin




Tracy Kennedy
Associate Product Manager
CloudBees 

Tracy Kennedy is an associate product manager for CloudBees and is based in Richmond. Read more about Tracy in her Meet the Bees blog post and follow her on Twitter.