Leveraging Pack to increase speed and flexibility in Ketch
With the release of Ketch 0.3.0 there are a lot of exciting new features, but the one I’d like to introduce today is the implementation of Pack into Ketch.
With the release of Ketch 0.3.0, there are a lot of exciting new features, but the one I’d like to introduce today is the implementation of Pack into Ketch.
I’m Davis French, a new software engineer at Shipa. I have a background working on backend systems in both Golang and Rust. My time at Shipa so far has been spent maintaining and contributing to our open source project, Ketch.
Ketch is an application delivery framework that makes it simple for users to deploy and manage applications without having to deal with any of the overhead (YAML files, helm charts, etc.) normally associated with deployments.
What effects has the addition of Pack had on Ketch? It has led to many improvements in the code and the user experience. However, before we get into that, we need to understand what Pack is.
What is Pack?
Pack is a tool maintained by the Cloud Native Buildpacks Project that is used to build an OCI compliant image without the need for the user to define their own Dockerfile. To do this, Pack makes use of a builder that is composed of several buildpacks. These groups of buildpacks are tested against your code until a match is found, and then that match is used to build your application’s code. Each of the included buildpacks contributes to the application’s final image, like setting an environment variable or installing a dependency. In this sense, you can almost think of each buildpack as a separate command in a Dockerfile.
Ketch already had the ability to build from source, but it required the use of an additional platform type specification to know what to use to build your application. Now, by leveraging Pack, Ketch is able to use builders to automatically build your application meaning no more platforms. The default builder is set to
heroku/pack:20, which offers a wide range of buildpacks covering a large variety of code bases. In the event that the default does not fit your project, it is possible to specify a different builder using the optional
— builder flag under the
ketch app deploy command, which is now responsible for creating and deploying an app. Along with this, it is also possible to provide a list of additional buildpacks for a deployment with the optional
— build-packsflag. While these additions alone add a great deal of flexibility to any source deployments, developers aren’t limited to the Cloud Native Computing Foundation approved builders and can provide their own builders and buildpacks.
The flexibility offered by Pack also works in conjunction with the optional
ketch.yaml file that provides for finer grained control over other deployment details. The
ketch.yaml file allows the user to configure networking on a process level, and also gives them the ability to specify deployment hooks, which make it possible to run commands at different stages of an application’s deployment.
Utilizing Pack also has the additional benefit of tremendously speeding up the process of building your application’s code. To demonstrate this, I will be building a go project titled go-sample. The go-sample repo is a simple server that will print a message when the server is visited. Currently, building the project in Ketch 0.2.1 will take several minutes, and subsequent builds don’t result in significantly faster build times.
Building the same application with Ketch 0.3.0 results in a build time of around a minute, but this is assuming that the builder’s image needs to be pulled.
Creating a new application from the same source code with the builder image already present will result in even quicker build times ranging from 20 to 30 seconds.
Incorporating Pack into Ketch also allowed me to greatly decrease the amount of code needed to build from source. Pack is incredibly straightforward to use and requires little more than populating a BuildOptions structure and using it as the argument for the client’s Build method. All of the code that was previously needed in Ketch to make an image out of the provided source code is now handled entirely by the buildpacks/pack go package.
The inclusion of Pack into the newest release of Ketch has led to a more streamlined and nuanced control over deployments from source, as well as improved build times and a lot less code. This is just one of a few new features in Ketch 0.3.0, and I think the others will be just as appreciated as this one.
I’m a backend developer with a strong interest in golang. Always looking for opportunities to learn inside and outside of coding.