Google have created a Kubernetes-based open source reference implementation that automates the building of custom Google Compute Engine VM images with Jenkins and Packer. The primary goal of this work is to demonstrate how to add image creation into a build pipeline for continuous delivery, and produce artifacts that may provide increased reliability and reduced speed of VM initialisation.

The Google Cloud Platform blog proposes that many applications deployed to the cloud require the customised provisioning of virtual machine (VM) instances. Examples of this type of provisioning include configuring the operating system, installing language runtimes, and orchestrating remote logging for the instance. There are several approaches to provisioning, including the traditional method of connecting to each VM via SSH and running arbitrary commands, and the more modern 'automated sysadmin' variant that utilises provisioning tools such as Puppet, Chef or Ansible for bootstrapping during the VM initialisation process. The former process is manual and error-prone (often creating 'snowflake' servers), and the later process can result in lengthy installation times or be affected by software package repository availability.

An alternative to boot-time instance provisioning is to create a custom VM base image, using a tool such as Hashicorp's Packer. This process consists of a one-time (but repeatable) provisioning of a VM instance, from which a 'snapshot' is created that can be used to initialise an arbitrary number of VMs on-demand. This process avoids the need to provision an instance during VM initialisation, and so can increase reliability and reduce boot times.

The Google Cloud Platform team have released a technical solution paper and open source reference implementation that describes in detail how to automate image builds via Google Compute Engine (GCE) using open source technology such as Jenkins, Packer, and Kubernetes. The reference implementation can be used as a template to continuously build images for GCE or Docker-based applications. Images are built in a central project, and then may be shared with other projects within an organisation. The Google Cloud Platform blog proposes that ultimately this automated image build process can be integrated as a step in an organisation's continuous integration (CI) pipeline.

InfoQ spoke with Evan Brown, solutions architect at Google Cloud Platform, and asked several questions about the automated image building technical paper and reference implementation.

InfoQ: We notice that you are providing a fully open source container/cloud continuous delivery pipeline, in comparison with some other vendors who only provide this as a SaaS offering. Could you share your thinking behind this?

Brown: We had two goals in mind when we put this together. First, the topic of building custom images has been around as long as cloud. In this solution we wanted to address custom images - especially immutable images - at a time when containers are very popular, but VMs are still important. How can we help our customers do this valuable thing - automate the creation of immutable images - and make it useful for both Google Compute Engine VMs as well as Docker containers? The second goal was to do more than have a philosophical conversation about how this implementation might look, and instead provide a functional, open source reference that customers can use to understand the concepts.

InfoQ: The RI is using open source tooling such as Jenkins and Hashicorp's Packer. Was it a conscious decision to leverage this work, rather than developing something in-house?

Brown: Using Jenkins and Packer in the implementation was a conscious decision. In fact, some of the legwork to enable this was done months ago with a Googler's contributions to Packer as well as through Google's contribution of multiple open source plugins to Jenkins. We contribute to projects that customers use and love, and it's exciting to bring a few them together to uniquely address a new problem like immutable image automation.

InfoQ: The pipeline currently only offers deployment to Kubernetes - would you be keen to support other platforms running in Google Cloud Platform, such as Mesos frameworks?

Brown: The sample implementation on GitHub is designed to run on Kubernetes and Google Container Engine, but the three Docker images that power the core functionality can run wherever Docker runs, including Mesos. We chose Container Engine because it would give us a Kubernetes cluster in about 3 minutes, and let us tear it down even faster. This means a customer can touch and use this sample and tear it all down in less than a half hour. And the next day they can tweak some things to fit their environment, stand up the cluster again and experiment some more. Also, the design of the system really lent itself to running on Kubernetes. There are these 3 layers - the SSL termination proxy (nginx); the Jenkins leader/UI; and the Jenkins build agents - that are easily represented as Docker containers, and Kubernetes just made it simple to deploy and manage them together. And there's lot of exciting work being done by Carlos Sanchez on the Kubernetes Plugin for Jenkins that will be great to use down the road.

InfoQ: If any of the InfoQ readers would like to contribute to this project, what's the best way to get involved?

Brown: We love contributors! A contribution could be some code or improvements to the documentation - so fork the repo on GitHub and send a pull request. Other valuable contributions are bug reports or feature requests - we're tracking those on GitHub issues. And then there's me - @evandbrown - on Twitter if your contributions or feedback fit in 140 characters!

InfoQ: Many thanks for your time. Is there anything else you would like to share with the InfoQ readers?

Brown: Thanks for the questions! I'd emphasize to readers that this solution and implementation we published is assembled from a lot of incredible open source projects, including Packer, Jenkins, Kubernetes, Docker, and many, many great Jenkins plugins. If you've got ideas for improving them, or are just looking to contribute code or documentation, those are great places to pitch in.

Further information about the Google's automated image build reference implementation can be found on the Google Cloud Platform blog, or the project's Github repository.