Using Jenkins on Google Compute Engine for Distributed Builds
This is a guest blog by Vic Iglesias, cloud solutions architect, Google. View the original blog post .
Continuous integration has become a standard practice across a lot of software development organizations, automatically detecting changes that were committed to your software repositories, running them through unit, integration and functional tests, and finally creating an artifact (JAR, Docker image or binary). Among continuous integration tools, Jenkins is one of the most popular, and so we created the Compute Engine Plugin , helping you to provision, configure and scale Jenkins build environments on Google Cloud Platform (GCP).
With Jenkins, you define your build and test process, then run it continuously against your latest software changes. But as you scale up your continuous integration practice, you may need to run builds across fleets of machines rather than on a single server. With the Compute Engine Plugin, your DevOps teams can intuitively manage instance templates and launch build instances that automatically register themselves with Jenkins. When Jenkins needs to run jobs but there aren’t enough available nodes, it provisions instances on-demand based on your templates. Once work in the build system has slowed down, the plugin automatically deletes your unused instances, so that you only pay for the instances you need. This autoscaling functionality is an important feature of a continuous build system, which gets a lot of use during primary work hours and less when developers are off enjoying themselves. For further cost savings, you can also configure the Compute Engine Plugin to create your build instances as Preemptible VMs , which can save you up to 80% on per-second pricing of your builds.
Security is another concern with continuous integration systems. A compromise of this key organizational system can put the integrity of your software at risk. The Compute Engine Plugin uses the latest and most secure version of the Jenkins Java Network Launch Protocol (JNLP) remoting protocol. When bootstrapping the build instances, the Compute Engine Plugin creates a one-time SSH key and injects it into each build instance. That way, the impact of those credentials being compromised is limited to a single instance.
The Compute Engine Plugin lets you configure your build instances how you like them, including the networking. For example, you can:
Disable external IPs so that worker VMs are not publicly accessible
Use Shared VPC networks for greater isolation in your GCP projects
Apply custom network tags for improved placement in firewall rules
The plugin also allows you to attach accelerators like GPUs and local SSDs to your instances to run your builds faster. You can also configure the plugin to use our wide variety of machine types which match the CPU and memory requirements of your build instance to the workload, for better utilization. Finally, the plugin allows you to configure arbitrary startup scripts for your instance templates, where you can do the final configuration of your base images before your builds are run.
If you use Jenkins on-premise, you can use the Compute Engine Plugin to create an ephemeral build farm in Compute Engine while keeping your Jenkins controller and other necessary build dependencies behind your firewall. You can then use this extension of your build farm when you can’t meet demand for build capacity, or as a way to transition your workloads to the cloud in a practical and low-risk way.
Here is an example of the configuration page for an instance template:
Jenkins and continuous integration are powerful tools for modern software development shops, and we hope this plugin makes it easier for you to use Jenkins on GCP. For instructions on getting this set up in your Google Cloud project, follow our solution guide .
Stay up to date
We'll never share your email address and you can opt out at any time, we promise.