Skip to content

Latest commit

 

History

History
371 lines (262 loc) · 13.2 KB

README.md

File metadata and controls

371 lines (262 loc) · 13.2 KB

Test Kpack

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:

  1. Kpack itself (the Kubernetes resources for Kpack)
  2. 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 Overview

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.

Exploring Kpack

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

.Net Core Image Build with Kpack CLI

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

.Net Core Image Build with Kubectl

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

Java Image Build with Kpack CLI

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

Java Image Build with Kubectl

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

Next (Explore Cartographer) ->