February 13, 2023

Updating TBS Dependencies in TAP

TLDR – as of January 26th, you will need to update your TBS dependencies if you are building Spring Boot applications. This is related to the linked Known issue in TAP 1.4 but also effects previous versions of TAP. Preface A few days ago i was working on some TAP related testing, and all of a sudden a workload which always worked, started to fail on me. I could figure out why my app was failing, so i started to look into what was going on. quickly i saw that the build itself was failing for my container, and a saw the following error message: [creator] unable to invoke layer creator [creator] unable to contribute spring-cloud-bindings layer [creator] unable to get dependency spring-cloud-bindings [creator] unable to download https://repo.spring.io/release/org/springframework/cloud/spring-cloud-bindings/1.10.0/spring-cloud-bindings-1.10.0.jar [creator] could not download https://repo.spring.io/release/org/springframework/cloud/spring-cloud-bindings/1.10.0/spring-cloud-bindings-1.10.0.jar: 401 [creator] ERROR: failed to build: exit status 1 After some quick searching on the internet i stumbled upon the following blog post , which describes a change being made in the spring artifactory instance, where they are removing anonymous access for downloads of released artifacts, and instead people should pull these from maven central. The issue I was hitting was due to the fact that the Spring boot buildpack that is part of the TAP 1.4 release, is still trying to pull down the spring-cloud-bindings dependency from the spring registry, and I happened to be testing things, during one of the brown-outs, ahead of the final removal of anonymous access on January 26th 2023. Solving The Issue While TAP releases versions on a quarterly release cycle, as well as patch releases which typically help solve these types of issues every month, Tanzu Build Service, which is the underlying project used in TAP for building images, releases new buildpacks and dependencies, on a very frequent basis, in order to patch CVEs, bump dependencies, add new features, add new buildpacks etc. As VMware Tanzu Buildpacks, use paketo buildpacks as the base for most of the buildpacks, I looked to see if the Paketo Spring Buildpack had already solved this issue, and indeed i found that this had been fixed in the 5.22.1 release of the buildpack. From there through some simple browsing of the Tanzu Buildpacks documentation i found that not only had an upstream release been cut by Paketo solving this issue, but also that VMware had already released a Tanzu Buildpack release for downstream consumption which incorporates this fix as well. So now that I found that a new release is available, it was time to figure out how to update by TBS dependencies. While i could just update the relevant buildpack, I decided that if im already updating dependencies, I might as well update the whole set of dependencies available, as its always best to stay inline with the latest patches. To do this VMware have a very detailed document in the TBS documentation which is also liked to from the TAP documentation. With all that information, lets go through the general steps I used. Download the descriptor YAML from Tanzu Network The dependency bundles, and there relevant descriptor files can be found at the following URL In my case I used the version 100.0.396 which was the latest version at the time. The file I downloaded was the descriptor-100.0.396.yaml file which is the full dependencies descriptor, however you could also use the lite-descriptor-100.0.396.yaml file if you so desire. Relocating the dependencies to my local registry In line with the best practice from VMware for TAP, which is to relocate all images to your own registry and not to depend on the VMware public registry, I decided to relocate the dependencies. Step 1 – login to your registry and to the Tanzu Network registry export MY_REGISTRY_URL=harbor.vrabbi.cloud export MY_REGISTRY_REPO=tbs/full-deps docker login registry.tanzu.vmware.com docker login registry.pivotal.io docker login $MY_REGISTRY_URL Step 2 – Relocate dependencies export DEP_VERSION="100.0.396" imgpkg copy -b registry.tanzu.vmware.com/tbs-dependencies/full:$DEP_VERSION \ --to-repo $MY_REGISTRY_URL/$MY_REGISTRY_REPO Step 3 – Update Dependencies to be pulled from my registry imgpkg pull -b $MY_REGISTRY_URL/$MY_REGISTRY_REPO:$DEP_VERSION -o ./tbs-deps kbld -f ./tbs-deps/.imgpkg/images.yml \ -f ./tbs-deps/tanzu.descriptor.v1alpha3/descriptor-$DEP_VERSION.yaml \ > ./tbs-dependencies-from-my-registry.yaml Step 4 – Update the dependencies in my cluster kp import -f ./tbs-dependencies-from-my-registry.yaml With this done, we have now successfully updated TAP to use the new buildpacks, build and run images, and all the new and fancy changes that have been added by the TBS team since the TAP 1.4 release came out. Summary Updating dependencies is a process one should do on a regular basis in order to always stay as secure and up to date as possible. TAP lets us easily update our dependencies out of band from TAP releases, which is great, and allows us to perform the updates we need as frequently as we need to, without the need to constantly be chasing after the next TAP release the second it is released, just to get the security patches we have been looking for. While the above process seems like quite a few steps and includes some manual tasks around download the dependency file from Tanzu Network, this can easily be automated using the Pivnet CLI, and the whole process can be easily automated using whatever CI/CD tools you use. Hopefully this helps you if you run into this issue specifically, or really in any case, where you want to update dependencies out of band from a TAP release.

Preface

A few days ago i was working on some TAP related testing, and all of a sudden a workload which always worked, started to fail on me.

I could figure out why my app was failing, so i started to look into what was going on.

quickly i saw that the build itself was failing for my container, and a saw the following error message:

    [creator]     unable to invoke layer creator
    [creator]     unable to contribute spring-cloud-bindings layer
    [creator]     unable to get dependency spring-cloud-bindings
    [creator]     unable to download https://repo.spring.io/release/org/springframework/cloud/spring-cloud-bindings/1.10.0/spring-cloud-bindings-1.10.0.jar
    [creator]     could not download https://repo.spring.io/release/org/springframework/cloud/spring-cloud-bindings/1.10.0/spring-cloud-bindings-1.10.0.jar: 401
    [creator]     ERROR: failed to build: exit status 1

After some quick searching on the internet i stumbled upon the following blog post , which describes a change being made in the spring artifactory instance, where they are removing anonymous access for downloads of released artifacts, and instead people should pull these from maven central.

The issue I was hitting was due to the fact that the Spring boot buildpack that is part of the TAP 1.4 release, is still trying to pull down the spring-cloud-bindings dependency from the spring registry, and I happened to be testing things, during one of the brown-outs, ahead of the final removal of anonymous access on January 26th 2023.

Continue reading this post at VRABBI'S BLOG where this post was originally published.

Filter Tags

Tanzu Community Content