Announcing Google Cloud buildpacks—container images made easy
As a developer building a new application, you want to focus on writing code, not containerizing it. And if you already use containers, you know that creating a good, secure container image can be complicated and time-consuming. Today we’re launching broad support across Google Cloud for buildpacks—an open-source technology that makes it fast and easy for you to create secure, production-ready container images from source code and without a Dockerfile.
At the center of this release are a collection of open-source buildpacks and builders. Based on the CNCF buildpacks v3 specification, these buildpacks produce container images that follow best practices and are suitable for running on all of our container platforms: Cloud Run (fully managed), Anthos, and Google Kubernetes Engine (GKE). These buildpacks are production hardened and tested; they have been used at scale powering most builds for App Engine and Cloud Functions since March.
You can use buildpacks in several ways: First, if you haven’t already fully adopted containerization, buildpacks are a way to use the latest container runtime and delivery platforms. They’re also useful for quick projects when you don’t have time to properly vet and customize a Dockerfile that you might find in the wild.
You can try out the Google Cloud buildpacks right now. To do a complete source-to-deploy with a Go project, Buildpacks, and Cloud Run, just click on the ‘Run on Google Cloud’ button.
(Go, Java, Node, Python, and .Net are supported. They might need additional configuration to build properly.)
Or, if you don’t want to install anything, you can run a buildpack based build in Cloud Build, and then easily deploy to Cloud Run:
How do buildpacks work?
Buildpacks are distributed and executed in OCI images called builders. Each builder can have one or more buildpacks. The builder of the Google Cloud buildpacks that we are releasing today is available gcr.io/buildpacks/builder.
Builders have the ability to auto-detect the language of your source code. This is accomplished by a `bin/detect` executable in the buildpack. The detection scripts are invoked in a particular order and stop once an appropriate number of buildpacks have opted in to the build. For example, most Node.js buildpacks look for the presence of a packages.json file. You can also manually specify which buildpack to use, thereby skipping the auto-detection step.
Once the buildpack has been selected, its `bin/build` is executed. This script transforms your source code into an executable artifact, typically performing actions such as installing dependencies or compiling code.
The output of this build step is then added on top of a “run” OCI base image, creating a final container image which can then be run on the platform of your choice.
Google Cloud buildpacks
Google Cloud’s buildpacks are optimized for security, speed, and reusability. They allow you to build both apps and functions into container images. When building a function, they package it using Google Cloud’s open-source Functions Framework.
Google Cloud buildpacks use a managed base Ubuntu 18.04 base image that is regularly scanned for security vulnerabilities; any detected vulnerabilities are automatically patched. This ensures that when you build your source code with buildpacks, it will be as secure as possible.
Google Cloud buildpacks can also be customized with additional system packages or to meet your development team’s particular needs.
The buildpacks themselves are all written in Go. Rather than create a single buildpack for each language, you can combine smaller, modular buildpacks together. For example, there is an NPM buildpack which (unsurprisingly) installs node packages. This is of course used for Node.js builds, but it can also be used for other languages and frameworks that use NPM packages (Ruby on Rails, for example).
Broad support in Google Cloud
In addition to the open-source buildpacks, we support buildpacks across a range of our products:
App Engine – Buildpacks are now the default mechanism for source deployments on most newer App Engine runtimes. Notably, buildpacks enable source-based Java deployments (previously only JAR-based deploys were supported). All newly released runtimes will use buildpacks moving forward.
Cloud Functions – Like App Engine, buildpacks are the default mechanism for building deployed functions.
Cloud Code – Cloud Code IDEs can build your source code with buildpacks and deploy the resulting containers directly to GKE.
Skaffold supports live development with buildpacks. As you edit your source code, buildpacks can continuously re-build your app, allowing you to preview changes in a local instance of your app.
Related Google News:
- Next-gen virtual automotive showrooms are here, thanks to Google Cloud, Unreal Engine, and NVIDIA March 23, 2021
- Celebrating Women’s History Month at Google Canada: Meet Sylvie LaPerrière March 23, 2021
- Customize notification frequency with more options in Google Chat and Chat in Gmail March 22, 2021
- New and improved Google Chat UI on the web March 22, 2021
- Find files shared with you using updated search operators in Google Drive March 22, 2021
- Changes to Google Drive search operators may alter your Google Vault search results March 22, 2021
- Alternate runtimes makes it easier to build Google Workspace Add-ons, now generally available March 22, 2021
- Evolving Google Workspace Add-ons with Alternate Runtimes March 22, 2021