Buildpacks – Laboratory

Cloud Native Buildpacks are an evolution of the buildpacks technology that made developer-centric platforms like Heroku and Cloud Foundry so popular. By default, buildpacks allow you to supply your code and then “automagically” inspect it to identify a builder image that knows how to build the application. For example, a pom.xml may cause a Maven buildpack to be used. The resultant application is then packaged into a run image.

Buildpacks are another excellent option for speeding up your inner loop. The disadvantage of buildpacks is that they require a local Docker daemon and tend to be considerably slower to rebuild than a solution like Jib or Ko. However, they are smart enough to use caching of dependencies to avoid the complete rebuilds you would have when using a Dockerfile. The big advantage of buildpacks is that you just need to provide the code and they do the rest; you don’t need to touch a Dockerfile, and buildpacks support a wide range of languages.

Comparison of Container Build Tools

Table 10-2 summarizes the difference between the container build tool options.

Deploy to a Development Container Runtime

Once the container is built and is available in a container registry, it can be redeployed to the container runtime for testing and verification. I will discuss the pros and cons of using the different container runtimes that Google Cloud uses in later chapters, but in the context of what is best for your inner loop, here are options that Skaffold supports.

Local Kubernetes

By default, Cloud Code comes with Minikube, a local Kubernetes cluster. This is the easiest and quickest container runtime to deploy and test your containers. It is also used as an emulator for Cloud Run.

Alternatives for local Kubernetes include Kind, k3d, and Docker Desktop.

Using a local Kubernetes is great if you have poor internet access or work offline, as you don’t need to wait for your container image to be uploaded to a remote repository. It is also likely the cheapest option. I like working on a modest laptop, and running local Kubernetes uses a lot of resources and battery, which is a downside.

Minikube is also included with the Cloud Console Editor and Cloud Workstations.

Shared GKE

If you work in a team, you could have access to a shared Google Kubernetes Engine (GKE) cluster. This could be centrally managed and shared by giving each developer their namespace to deploy to. While this may make sense for a team, it is likely not the best option for an individual developer as, most of the time, it will be idle but costing you money.

Tip

Don’t use GKE; use GKE Autopilot or Cloud Run, especially for development workloads.