Important the commands below assume you have a terminal window open in the same directory as this file.
Kpack is a system that builds container images from source code and publishes them to a registry. Kpack uses Cloud Native Buildpacks (https://buildpacks.io/) to build container images from source. Cloud Native Buildpacks started as a collaboration between Heroku and Pivotal(now VMware) and are now the CNCF's recommended method for building container images.
Buildpacks can inspect source code from many languages and frameworks, determine if any particular buildpack can make a contributions to the image, and then build the image. For Java projects, buildpacks can recognize Gradle or Maven projects. Build packs exist for many other languages including .Net Core (C#, F#, etc.), NodeJS, Go, Ruby, etc.
Cloud Native Buildpacks define a standard API for creating and executing buildpacks. Another project - Paketo Buildpacks (https://paketo.io/) - provides open source buildpack implementations for many languages.
Note that the app toolkit installed two packages related to Kpack:
- Kpack itself (the Kubernetes resources for Kpack)
- Kpack dependencies - which is a Kpack configuration that will build containers for Java, .Net Core, Python, Go, and NodeJS. Source for the Kpack dependencies is here: https://github.com/vmware-tanzu/package-for-kpack-dependencies
As with Knative, you can define image builds with a CLI (kp
), or with Kubectl. The kp
CLI is a bit limited in that
it can only work with the default service account. That's OK for this workshop, but may not be enough in a production
deployment. Also, the kp
CLI is not currently supported on ARM based Macs (M1, M2).
Feel free to try one or all of the options below!
Kpack is open source here: https://github.com/pivotal/kpack. There are a few important terms to learn with Kpack:
Term | Meaning |
---|---|
Cluster Store | A Collection of build packs |
Cluster Stack | A base build and run image |
Builder/ Cluster Builder | A combination of a store and stack. Also specifies the order in which build packs are checked |
Kpack is, essentially, a Kubernetes based system for running build packs and publishing the resulting image. Kpack will offer source code to the configured build packs and the build packs will determine if they can operate on that source. If so, the build pack will contribute to the final image. It is very common for more than one build pack to be involved in the production of an image.
You can also run build packs outside of Kubernetes. For example, Spring Boot includes support for running build packs during a Maven/Gradle build.
Display cluster stores installed and their versions:
kp clusterstore list
Display detailed information about a cluster store:
kp clusterstore status default -v
Display cluster stacks installed and their versions:
kp clusterstack list
Display detailed information about a cluster stack:
kp clusterstack status default -v
Display cluster builders installed and their versions...
kp clusterbuilder list
Display detailed information about a cluster builder...
kp clusterbuilder status default
If you have the Kpack CLI installed, you can create images from the command line:
Powershell...
kp image create dotnet-sample `
--tag harbor.tanzuathome.net/tce/kpack-dotnet-sample `
--git https://github.com/paketo-buildpacks/samples `
--git-revision main `
--sub-path ./dotnet-core/aspnet
MacOS/Linux Shell...
kp image create dotnet-sample \
--tag harbor.tanzuathome.net/tce/kpack-dotnet-sample \
--git https://github.com/paketo-buildpacks/samples \
--git-revision main \
--sub-path ./dotnet-core/aspnet
You can follow the build with this command:
kp build logs dotnet-sample
The build will be slow the first time it runs because the buildpack will need to download all the dependencies (like a .Net SDK!). Subsequent builds would be faster. Once the build completes, an image will be published. You can get the full image address with the following command:
kp image list
For me, the image was harbor.tanzuathome.net/tce/kpack-dotnet-sample@sha256:e64109703a5293b55882d524d98690ebb73d6d775fd60c286149b1f360de5eba
.
Now we can deploy that image with Knative (you will need to change this command to use the image you built):
Powershell:
kn service create dotnet-sample `
--image harbor.tanzuathome.net/tce/kpack-dotnet-sample@sha256:e64109703a5293b55882d524d98690ebb73d6d775fd60c286149b1f360de5eba `
--pull-secret registry-credentials
MacOS/Linux Shell:
kn service create dotnet-sample \
--image harbor.tanzuathome.net/tce/kpack-dotnet-sample@sha256:e64109703a5293b55882d524d98690ebb73d6d775fd60c286149b1f360de5eba \
--pull-secret registry-credentials
Note that we have to specify the image pull secret this time as we are pulling from a private registry.
You should be able to access the application at http://dotnet-sample.default.127-0-0-1.nip.io/
Once you are finished experimenting, you can delete the service with the following command:
kn service delete dotnet-sample
Look at the file kpack-test-image-dotnet.yaml. This file contains a definition for a Kpack "Image" - importantly it contains a path to the source code in Git, and a tag for where the image should be published.
Important: You must change the image tag in this file before proceeding!
Create the image with the following command:
kubectl apply -f kpack-test-image-dotnet.yaml
You can follow the build with this command:
kp build logs dotnet-sample
If you do not have the "kp" CLI installed, you can obtain the build logs with the following commands (assuming your build pod is named the same as mine). The build works through a series of init containers before the final container "completion" is started. The commands below show the order of execution of the containers at the time of this writing:
kubectl logs spring-pet-clinic-build-1-build-pod -c prepare
kubectl logs spring-pet-clinic-build-1-build-pod -c analyze
kubectl logs spring-pet-clinic-build-1-build-pod -c detect
kubectl logs spring-pet-clinic-build-1-build-pod -c restore
kubectl logs spring-pet-clinic-build-1-build-pod -c build
kubectl logs spring-pet-clinic-build-1-build-pod -c export
kubectl logs spring-pet-clinic-build-1-build-pod -c completion
The build will be slow the first time it runs because the buildpack will need to download all the dependencies (like a .Net SDK!). Subsequent builds would be faster. Once the build completes, an image will be published. You can get the full image address with the following command:
kp image list
If you do not have the "kp" CLI installed, you can obtain the full image with the following command:
kubectl get cnbimage
For me, the image was harbor.tanzuathome.net/tce/dotnet-sample@sha256:f2da339367a7410f6f397288d540465b1446887fc08c727efeb4ddfde8325ae0
.
Now we can deploy that image with Knative (you will need to change this command to use the image you built):
Windows Powershell:
kn service create dotnet-sample `
--image harbor.tanzuathome.net/tce/dotnet-sample@sha256:f2da339367a7410f6f397288d540465b1446887fc08c727efeb4ddfde8325ae0 `
--pull-secret registry-credentials
MacOS/Linux:
kn service create dotnet-sample \
--image harbor.tanzuathome.net/tce/dotnet-sample@sha256:f2da339367a7410f6f397288d540465b1446887fc08c727efeb4ddfde8325ae0 \
--pull-secret registry-credentials
Note that we have to specify the image pull secret this time as we are pulling from a private registry.
You should be able to access the application at http://dotnet-sample.default.127-0-0-1.nip.io/
Once you are finished experimenting, you can delete the service with the following command:
kn service delete dotnet-sample
If you have the Kpack CLI installed, you can create images from the command line:
Powershell...
kp image create spring-pet-clinic `
--tag harbor.tanzuathome.net/tce/kpack-java-sample `
--git https://github.com/spring-projects/spring-petclinic `
--git-revision 82cb521d636b282340378d80a6307a08e3d4a4c4
MacOS/Linux Shell...
kp image create spring-pet-clinic \
--tag harbor.tanzuathome.net/tce/kpack-java-sample \
--git https://github.com/spring-projects/spring-petclinic \
--git-revision 82cb521d636b282340378d80a6307a08e3d4a4c4
You can follow the build with this command:
kp build logs spring-pet-clinic
The build will be slow the first time it runs because the buildpack will need to download all the dependencies (like a .Net SDK!). Subsequent builds would be faster. Once the build completes, an image will be published. You can get the full image address with the following command:
kp image list
For me, the image was harbor.tanzuathome.net/tce/kpack-java-sample@sha256:7eb23df634e494ecab677434c506b1ad63f42225dd29f86b8848f45cace942b1
.
Now we can deploy that image with Knative (you will need to change this command to use the image you built):
Powershell:
kn service create java-sample `
--image harbor.tanzuathome.net/tce/kpack-java-sample@sha256:7eb23df634e494ecab677434c506b1ad63f42225dd29f86b8848f45cace942b1 `
--pull-secret registry-credentials
MacOS/Linux Shell:
kn service create java-sample \
--image harbor.tanzuathome.net/tce/kpack-java-sample@sha256:7eb23df634e494ecab677434c506b1ad63f42225dd29f86b8848f45cace942b1 \
--pull-secret registry-credentials
Note that we have to specify the image pull secret this time as we are pulling from a private registry.
You should be able to access the application at http://java-sample.default.127-0-0-1.nip.io/
Once you are finished experimenting, you can delete the service with the following command:
kn service delete java-sample
Look at the file kpack-test-image-java.yaml in this directory. This file contains a definition for a Kpack "Image" - importantly it contains a path to the source code in Git, and a tag for where the image should be published.
Important: You must change the image tag in this file before proceeding!
Create the image with the following command:
kubectl apply -f kpack-test-image-java.yaml
You can follow the build with this command:
kp build logs spring-pet-clinic
If you do not have the "kp" CLI installed, you can obtain the build logs with the following commands (assuming your build pod is named the same as mine). The build works through a series of init containers before the final container "completion" is started. The commands below show the order of execution of the containers at the time of this writing:
kubectl logs spring-pet-clinic-build-1-build-pod -c prepare
kubectl logs spring-pet-clinic-build-1-build-pod -c analyze
kubectl logs spring-pet-clinic-build-1-build-pod -c detect
kubectl logs spring-pet-clinic-build-1-build-pod -c restore
kubectl logs spring-pet-clinic-build-1-build-pod -c build
kubectl logs spring-pet-clinic-build-1-build-pod -c export
kubectl logs spring-pet-clinic-build-1-build-pod -c completion
The build will be slow the first time it runs because the buildpack will need to download all the dependencies (like a Java SDK!). Once the build completes, an image will be published. You can get the full image address with the following command:
kp image list
If you do not have the "kp" CLI installed, you can obtain the full image with the following command:
kubectl get cnbimage
For me, the image was harbor.tanzuathome.net/tce/spring-pet-clinic@sha256:d150b6b0b9a28d72795efb2f9e6c1a353eeec84691e965cb110d787215f8941c
.
Now lets deploy that image with Knative (you will need to change this command to use the image you built):
Windows Powershell:
kn service create spring-pet-clinic `
--image harbor.tanzuathome.net/tce/spring-pet-clinic@sha256:d150b6b0b9a28d72795efb2f9e6c1a353eeec84691e965cb110d787215f8941c `
--pull-secret registry-credentials
MacOS/Linux:
kn service create spring-pet-clinic \
--image harbor.tanzuathome.net/tce/spring-pet-clinic@sha256:d150b6b0b9a28d72795efb2f9e6c1a353eeec84691e965cb110d787215f8941c \
--pull-secret registry-credentials
Note that we have to specify the image pull secret this time as we are pulling from a private registry.
You should be able to access the application at http://spring-pet-clinic.default.127-0-0-1.nip.io/
Once you are finished experimenting, you can delete the service with the following command:
kn service delete spring-pet-clinic