At the center of Cloud Code is Skaffold, a Google open source project that automates your inner loop, building, pushing, and deploying your containerized application. Skaffold aims to tighten and highly optimize your inner loop, giving you instant feedback while developing. It is a flexible tool for building a laboratory.
When configured and run, Skaffold takes the source code from your project, automatically builds the code, and packages the artifacts into a container using a mechanism of your choice. It then tags the container and makes it available for deployment. For a remote Kubernetes cluster, for example, this means automatically pushing the container to a remote repository. Skaffold then automates the task of redeploying the new container to the runtime, Kubernetes or otherwise.
Efficiently Building Containers
The most significant bottleneck in an inner loop with containers is building the container itself. Fortunately, Skaffold supports several options.
Using a Dockerfile
The most common way of building a container is to write a Dockerfile and use a Docker daemon on your local machine to create the container image. The problem with this is that adding this containerization step may add minutes to your inner loop, making it a disaster for productivity. The only time you used this in previous chapters was in Chapter 9 when you built a container for the UI. You want to keep the loop to seconds. Fortunately, there are other options available to streamline and automate the process.
Jib
If you are building applications in Java, Jib is a Google open source project that lets you build OCI-compliant containers using a Maven or Gradle plugin. You used this for the fact service in Chapter 7.
Jib does not require Docker to be installed and doesn’t need a Dockerfile. By default, Jib uses an OpenJDK base container image containing a Java runtime, although you can specify any base container you like. Jib then adds layers containing your application, much like adding the filling to a sandwich. It also automates the step of pushing the new image to a repository.
When building a Java container using a Dockerfile, dependencies are downloaded and the entire application is rebuilt as one layer. The great thing about Jib is that it creates multiple layers for the application in the container. Jib is then smart enough to know which dependencies or classes have changed and swaps in a thin layer with the changes, leaving the rest of the container image as before. This means building containers is fast, and containers are not rebuilt unnecessarily.
Ko
Ko is a similar project for Go developers. Like Jib, Ko is a fast container builder. It is great if your application is a single Go executable without dependencies required in the base image. By default, Ko uses the minimal distroless base image, although, like Jib, this can be changed. Again, it does not require Docker to be installed on your machine and supports multiplatform builds. You have not used Ko yet in this book, preferring to use buildpacks for the Go services; however, Ko is much faster than buildpacks.
