-
TAP 1.6 – What’s New
TAP 1.6 is a huge release with some really awesome new features, both brand new components, as well as improving the experience around existing ones.
In this series of posts, we will take a look at some of the key new features in TAP 1.6 including:
Brand New Components:
- Local Source Proxy
- Tanzu Developer Portal Configurator
- Artifact Metadata Repository Observer
- CVE Triage flow via Tanzu insight CLI
Improved Features
- Supply Chain Backstage Plugin Improvements
- Crossplane Upgrade
- New Bitnami Services
- AppSSO Improvements
- Tanzu CLI Management Improvements
- TBS Improvements
- App Live View Improvements
- GitOps Installation using Vault
- App Scanning 2.0
- Namespace Provisioner Improvements
- Metadata Store Improvements
- IDE Plugin Improvements
This is only a partial list and many other updates have been made, but these are the key ones that I believe are truly impressive to see.
It never stops to amaze me, the speed at which VMware are pushing in these new features in TAP, making it a truly amazing one of a kind offering!
-
VMware Explore 2023 Las Vegas – Recap
TLDR
This years VMware Explore in Las Vegas was an amazing conference filled with great content and an overall really good vibe.
The announcements that were made during the conference were extremely interesting and it is great to see the deep investment VMware are making in the AI world together with Nvidia with the whole Private AI Foundation announcement.
VMware also announced the changes in the Aria and Tanzu spaces, which while again we need to get used to new names, and rebranding of products, I believe is actually a much more cohesive and powerful separation of the products and focuses between the 2 suites of products, which will ultimately be better for VMware customers.
Tanzu News
As part of the conference this year, VMware announced the new model of the Tanzu Portfolio, which is now focused on both Cloud Native Applications and platforms, as well as on Multi Cloud Management.
Within the New and revamped Tanzu, we now will find 2 main offerings:
- Tanzu Application Platform (TAP)
- Tanzu Intelligence Services (TIS)
Tanzu Application Platform
TAP, which should not be confused with what was known as TAP till this conference, as that is only a part of it. the new TAP is actually the combination of the previous TAP, together with TMC, TSM and the new and truly amazing Tanzu Application Engine (more details in a dedicated post)!
Tanzu Intelligence Services
TIS includes different tools including (Wavefront, ah no Tanzu Observability, ah no Aria Operations for Applications, ah no Tanzu Insights), Cloud Health as well as new and exciting features to be added in the near future which will enable for continuous and highly optimized intelligence services for constant optimization of our environments.
Aria Updates
While last year the buzz of aria was multi cloud, the vast majority of the multi cloud features like Hub and Graph were moved to be part of Tanzu, and Aria is refocusing on the core elements it started from which is the intial vRealize Suite of tools (vRA, vROPS, vRLI and vRNI), and is refocusing mostly on Private and Hybrid clouds.
Broadcom
at the conference it seemed to be made pretty clear the benefits that this acquisition will bring, and I believe that while only time will tell, the opportunities this acquisition can bring are huge for all of VMware and broadcoms customers. hopefully with the right execution, and the right amount of time for adjustments, the market will realize how great this move was for all parties.
Summary
The conference included some amazing content, and its truly great to see the innovation coming out from VMware!
-
TAP 1.6 – Tanzu CLI Improvements
Across the Tanzu portfolio as a whole, their has been a major effort for a long time to build a truly cohesive and user friendly experience for operators and developers.
Since the early days of TKG, and since the beginning of TAP, the Tanzu CLI has been a key element of how users interact with the platform.
While TKG, TAP and recently TMC as well, all were using Tanzu CLI as the base CLI for their products, each product had its own releases of the CLI, which were often incompatible with one another, and the distribution of the CLI was not simple, as it had to be downloaded from Tanzu Network, and no automated installation, or package manager support existed.
VMware understood this challenge, and did a complete rearchitecture of the CLI in terms of package and plugin management, as well as distribution of the CLI, and now in TAP 1.6 we are seeing the fruit of this long awaited new Tanzu CLI!
With TAP 1.6 and on, Tanzu CLI is now a separately released product / tool, which is not only available on Tanzu Network, but also as a github release artifact, as well as it being made available in all main package managers such as brew, apt, yum, and choco.
The Tanzu CLI now also offers an easy way to download and upgrade the product specific plugins via the new concept of plugin groups.
To show how great this new UX is, lets take an example of a windows user, that has choco package manager setup on their machine, and needs to use Tanzu CLI for TKG 2.2, TMC and TAP 1.6:
choco install tanzu-cli tanzu plugin install --group vmware-tkg/default:v2.2.0 tanzu plugin install --group vmware-tmc/tmc-user tanzu plugin install --group vmware-tap/default:v1.6.1
This experience is truly a game changer, and makes enablement and getting users onboarded to TAP in particular as well as all of the Tanzu products, so much easier, and a much more polished UX.
The new CLI model also makes airgapped support easy with the ability to relocate the plugins to an airgapped OCI registry via a simple download command and then one more simple upload command:
tanzu plugin download-bundle --to-tar /tmp/plugin_bundle_complete.tar.gz tanzu plugin upload-bundle --tar /tmp/plugin_bundle_complete.tar.gz --to-repo `registry.example.com/tanzu-cli/plugin`
Once images are relocated, all an end user needs to do to get the plugins, is to run one more command before installing the plugins as usual which is to set the URI for the internally hosted plugins:
tanzu plugin source update default --uri registry.example.com/tanzu-cli/plugin/plugin-inventory:latest
As you can see, this is a huge improvement over previous releases, and will make the overall getting started experience so much smoother!
Summary
It is really great to see the whole Tanzu picture coming together, and having the unified CLI experience, will hopefully be just the first step in the direction of truly making the better together story a reality!
-
TAP 1.6 – New Bitnami Services
In TAP 1.5, VMware added the integration with Crossplane for dynamic backend service provisioning.
With TAP 1.5, we also got a few OOTB Bitnami backed offerings that utilize this Crossplane integration. Now in TAP 1.6, this integration has been expanded to also support MongoDB and Kafka.
These 2 new services integrate easily with spring boot applications using spring cloud bindings, as well as a bunch of other languages and frameworks, which have implementations for the service binding specification for kubernetes.
While many organizations will end up building their own offerings for backing services that are more tailor made for their exact needs and requirements, having more and more OOTB offerings is an amazing thing.
These OOTB offerings allow for a quick and easy way to get started using service bindings, and can be expanded on, and customized to your needs, as you mature with your adoption of the platform.
just as was the case with the previous version of the bitnami services in TAP 1.5, we can not only use the open source Bitnami based charts, but you can also easily integrate this with charts provided via VMware Application Catalog, which is the commercial offering based on the Bitnami catalog, with some really great security, manageability, and traceability benefits.
Overall, this is a addition to the product which may go un-noticed by many, but the simple fact that just as in TAP 1.5 i could simply run:
tanzu services class-claim create my-psql \ --class postgresql-unmanaged \ --paramater storageGB=10
and get a PostgreSQL cluster up and running, and ready to be bound to my application, you can now run the same for mongodb or kafka, my simple changing the name of the class:
tanzu services class-claim create my-mongo \ --class mongodb-unmanaged \ --paramater storageGB=10 tanzu services class-claim create my-kafka \ --class kafka-unmanaged \ --paramater storageGB=10
The simplicity of the UX, with the huge power and flexibility it provides, is truly amazing!
I’m really happy to see this offering is still growing with every release, and can’t wait to see what will be coming in future releases as well to keep on enhancing this amazing feature of TAP!
-
TAP 1.6 – App Live View Improvements
One of the great features in TAP Developer Portal (previously TAP GUI) since the initial release, has been the app live view plugin, which can help visualize actuator data from spring based java applications as well as steeltoe based dotnet core applications.
In TAP 1.6, Application Live View (ALV) has been enhanced with 2 key new features
- Per User RBAC for secure access to sensitive operations
- Spring native support
Lets dig a bit into each of these enhancements and see what is in store for us in this release!
Per User RBAC for sensitive operations
In TAP 1.5, the ALV components were enhanced to add in an additional layer of security around exposure of accelerator data.
While actuator data can be extremely helpful when debugging or simply monitoring an application, depending on the settings you have configured, for which actuator endpoints to expose, it can also be a security risk to have such powerful access to manipulate an application live through Tanzu Developer Portal (TDP).
ALV now has split the endpoints exposed into the regular actuator endpoints and the “sensitive” endpoints. this seperation allows for what was made the default in TAP 1.5, which is that only non-sensitive endpoints are visualized in TDP by default.
While this is great from a security perspective, we loose out by default from having the ability to run actions that may be extremely helpful such as downloading a heap dump or thread dump, or changing the log levels on a live running pod.
With TAP 1.6, we can now not only toggle this setting like in TAP 1.5 to allow or disable sensitive endpoints, but we can actually allow this feature for a subset of users, while denying it for the rest of our user base.
This is done via standard kubernetes RBAC resources, using a custom resource and verb pairing:
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: alv-execute-sensitive-op-role rules: - apiGroups: ['appliveview.apps.tanzu.vmware.com'] resources: - sensitiveoperationsaccesses verbs: ['execute']
With that Cluster Role applied to you cluster you can start creating role bindings for specific users to utilize this role as such:
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: scott-alv-admin namespace: dev-team-1 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: alv-execute-sensitive-op-role subjects: - kind: User name: "scott@vrabbi.cloud" apiGroup: rbac.authorization.k8s.io
While this is a great feature, to gain full usage of it, and really see the benefits, you must have a very specific setup.
By default in TAP, access to the kubernetes clusters from the UI, is performed by using a shared service account token which is placed in your TAP values file. If this were to be how you configured your environment, the setting mentioned above, does not help very much, as all users once logged into the TDP, will use the same credentials to access the cluster.
With that said, TAP provides us with the ability to use per user authorization to the kubernetes clusters, however this does require using the same OIDC provider for your cluster as well as for TDP itself. This method is documented for GKE and for EKS, however it should be possible to get it to work with other kubernetes distributions as well, as long as the same OIDC client setup is used for both the cluster and TDP.
Spring Native Support
The other new feature in ALV in TAP 1.6 is support for native compiled Spring based applications.
Spring native apps, are becoming a really popular and paradigm shifting topology organizations are starting to adopt. While not all apps can be compiled today to spring native, due to either dependencies which are not compatible yet, or simply some internal logic which doesn’t support it within your own code, the ability to compile your app into native machine code, with a lightweight JVM replacement via GraalVM, and then being able to save magnitudes of memory and CPU usage, as well as much shorter startup times, makes using Java so much more practical, and powerful, when dealing with micro services and other cloud native architectures, in which size and performance, and speed of startup truly are the name of the game.
While native apps are now supported in TAP 1.6 within ALV, it is important to note that not all actuator endpoints are available yet. I’m sure that with future releases, more and more endpoints will be integrated into ALV, making the experience even better than it is right now!
-
TAP 1.6 – GitOps RI With Hashicorp Vault
In TAP 1.5, a new installation model was introduced based on a GitOps model, utilizing the Carvel toolset under the hood, to power it all.
With TAP 1.6, beyond overall bug fixes, and nice changes to the overall UX of the GitOps Installation method, a really key feature that has been added, is the integration with Hashicorp Vault.
The GitOps installation model, requires us to use a secret management solution as some of our TAP values are indeed very sensitive and can’t simply be pushed to git.
In TAP 1.5, we had 2 options. we could use Mozilla SOPs, which is the easiest method, in which we encrypt fields within a YAML file using a key pair, and then pushg the encrypted files to git. We then provide the private key to decrypt the content to the GitOps tooling in our cluster, which is responsible for decrypting the content and applying the needed configuration.
The other option we had in TAP 1.5, was the use of External Secrets Operator (ESO) which is included in TAP, and configuring ESO to use AWS Secrets Manager for storing our sensitive values. In this scenario, the GitOps tooling would pull down the sensitive data from AWS Secrets Manager using ESO, and then deploy what is needed to our cluster.
What’s new in TAP 1.6, is the support for my favorite, and probably the most commonly used secrets manager today in the kubernetes ecosystem which is Hashicorp Vault.
This is enabled, just like the AWS Secrets Manager solution, via TAP’s ESO integration.
While this may seem like a small feature, it truly is a game changer and opens up huge opportunities for customers that are either on prem, or multi cloud users, where having a cloud agnostic solution like Vault, is a much more viable solution then using a cloud specific offering.
The new integration includes a set of easy preperation scripts for creating the needed roles and policies within Vault as well as on the cluster itself to enable the integration.
While setting up the GitOps installation can take a bit more time then the manual installation method, and adds a level of complexity, the day2 management and benefits it provides, far outweigh the added upfront complexity, which also to be honest, is not too difficult to understand and perform.
Summary
This is another small enhancement in the way ESO is being integrated into TAP, and I’m truly looking forward to seeing more and more secret management capabilities and integrations in future releases!
-
TAP 1.6 – TAP GUI Supply Chain Plugin Updates
The Supply Chain Visibility plugin in Tanzu Developer Portal (TDP) which is formerly know as TAP GUI, is a key element of the TAP solution.
This plugin enables the visibility of our workloads “path to production” as it traverses through the cartographer supply chain.
In TAP 1.6, there are a few key enhancements that have been made, which enhance the usability, and overall UX of using this plugin.
the main new features i want to call out in this post are:
- New Log Viewer
- Deliverable Status
- SBOM downloading
In previous versions of TAP we had a very simple log viewer interface for the different steps within a supply chain that logs were relevant for, such as testing pipelines and image builds.
While the previous log viewer worked it had some drawbacks that made it quite difficult to use in advanced scenarios.
In TAP 1.5 for example, if you had a testing pipeline with multiple tasks, only the logs from the first task were shown. another issue was the build logs for the kpack image build were all streamed together from all containers in one view, which made understanding which step failed sometimes a difficult task. There were also no logs for the config writer step which was unfortunate.
In TAP 1.6, the log viewer was completely revamped, and not only those issues above were solved, but we also got the ability to see the side by side view of a log from a task in tekton and the script content which is run by that tekton task, making debugging much easier and streamlined.
Source Tester Log Viewer:
Image Build Logs:
Config Writer Logs:
As can be seen, the new log viewer is a huge improvement and it makes the overall UX much smoother than before!
The next major update for the plugin is actually in the overview page of the plugin.
Previously, you could see the workload status and basic details as well as which clusters the deliverable was applied to in the overview table, but the deliverable status itself was not shown.
Now in TAP 1.6, we hav a new field introduced to show us the deliverable status! While this may seem like a small feature, the ability to have a birds eye view of the overall status of my CI and CD status of all my workloads at one glance is awesome!
The final major feature i want to highlight for the supply chain plugin in TDP is a great new feature in the security realm.
This new feature allows you to download the Software Bill of Materials (SBOM) from the Supply Chain plugin directly. This allows you to easily with a single click, obtain the SBOM in SPDX or CycloneDX formats which are stored in the metadata store as a result from source code and image scanning steps in a supply chain!
This feature is great, and the ability to download in all of the major industry standard formats, allows for integrating easily with the wider security ecosystem, no matter which formats they work with.
Summary
As can be seen, this release of the plugin includes some great updates, with enhanced usability at the forefront!
I’m truly excited to see where this plugin goes in the future, as the product keeps maturing and growing, and as backstage enables more and more opportunities and extension points for plugins like this!
-
TAP 1.6 – AppSSO Improvements
Managing SSO for applications is a complex task, and since TAP 1.4, we have had a great feature called AppSSO, which is aimed at helping make the story of SSO integration much easier for developers and operators.
In TAP 1.6, a major effort was put into AppSSO to make it even more streamlined, and simple to use, while also exposing some more new advanced features, which can be very handy when needed.
In TAP 1.6 the main changes in AppSSO include:
- Cluster Workload Registration Class
- Cluster Unsafe Test Login
- Custom Claim Mappings
- Configurable token expiry settings
Lets go over what each of these improvement entails and what use cases they can help with.
Cluster Workload Registration Class
This integration is extremely exciting to see. With this new API, we can easily integrate AppSSO with Crossplane and the Services Toolkit components to allow for dynamic service provisioning of OIDC clients from an auth server!
It exposes an
AuthServer
as a ready-to-claim AppSSO service offering, making it really easy for developer to create new clients for an auth server on demand!When you create a ClusterWorkloadRegistrationClass (cwrc) resource, this will create behind the scenes a Crossplane
Composition
and a Services ToolkitClusterInstanceClass
.The composition itself templates out a new CRD which is also part of this new offering caller a WorkloadRegistration.
While in the past we had the ClientRegistration API, the new API, is more portable, and easily can be promoted between environments without changes to the spec, supporting a GitOps approach which is always the preferred approach in the Kubernetes world.
As we have the ability via the service toolkit to limit permissions to users, for specific classes, and each cwrc creates a new class which is tied to a specific auth server, we can easily manage RBAC and permission boundaries for different IDPs we use, in multi tenant scenarios, while still providing a simple and clean UX for a self service offering to our developers which is awesome!
While more complex and advanced feature can be added, lets take a look at a simple example of what this could look like:
CWRC Resource
apiVersion: sso.apps.tanzu.vmware.com/v1alpha1 kind: ClusterWorkloadRegistrationClass metadata: name: dev-sample spec: base: spec: authServerSelector: matchLabels: env: dev
Creating a new client
apiVersion: services.apps.tanzu.vmware.com/v1alpha1 kind: ClassClaim metadata: name: dev-sample-01 spec: classRef: name: dev-sample parameters: workloadRef: name: my-workload redirectPaths: - /redirect/uri
As you can see, the new API is extremely simple to use and understand, and can open up some amazing opportunities for offering a truly self service SSO offering to your end users.
While this is great for production, and more advanced setups, in dev environments or POCs, we often simply want something that just works. The above APIs are simple, but still require configuring the auth server and understanding more low level details than we want to deal with in dev environments. This is where the next new feature comes in.
Cluster Unsafe Test Login
This new API is the recommended way to get started with AppSSO in non production environments.
The new CRD ClusterUnsafeTestLogin (cutl) is so simple, it does not even have a spec!
the only element which is configurable is the name.
apiVersion: sso.apps.tanzu.vmware.com/v1alpha1 kind: ClusterUnsafeTestLogin metadata: name: demo
When you apply the above resource to a cluster, a few things will be created for you. First an Auth Server with an internal unsafe IDP will be deployed. next a token signing key will be generated, and finally a ClusterWorkloadRegistrationClass (cwrc) will be created, which will in turn create a ClusterInstanceClass and a Composition as mentioned above.
The auth server is configured in this setup with an http only issuer URI and allows all CORS origins. While this is definitely not a production setup, it makes integrating into your apps much easier, and removes all of the auxiliary issues from the time of development, making it much easier to get started, and to make sure the SSO elements are working for you as expected, and then you can switch to a more production ready setup, with a real backing IDP, more secure CORS configurations and of course TLS only communication.
The auth server which gets deployed as part of a CUTL, includes a single user with the username “user” and the password “password”.
Once you apply a CUTL resource, you can then create a class claim just like with a CWRC as seen above.
apiVersion: services.apps.tanzu.vmware.com/v1alpha1 kind: ClassClaim metadata: name: dev-sample-01 spec: classRef: name: demo parameters: workloadRef: name: my-workload redirectPaths: - /redirect/uri
This new API truly makes getting started on integrating SSO into you apps a breeze, and makes the barrier of entry to AppSSO so much lower!
While these past 2 features focused on simplifying the API and consumption of AppSSO, the next 2 improvements are for more advanced use cases, but are truly amazing to see, and actually can be game changers in certain environments.
Lets take a look at the one I am most excited about which is custom claim mappings support!
Custom Claim Mappings
With this new capability, service operators can control which claims appear in an Auth Server issued ID Token, and how to obtain this value from an upstream identity provider.
Recently when working on a project where i needed to test 4 different OIDC providers, i learned that the 4 claims which this specific app needed, only one of them was the same accross the different OIDC providers. While all data was there, every provider named their claims differently (group / groups / group_names / Groups), (full_name, name, fn, Full_Name) and so on.
While this may seem like a simple issue to solve, it actually is not easy, as within an application i need to look at a specific field in an ID Token to extract the data i need to know who this user is, and what permissions they should have.
This issue gets even more complex when working with an upstream IDP which is not OIDC based, such as LDAP or SAML.
With this new feature, we can now at the Auth Server level, perform mappings between upstream fields, and the claims on the Auth Server generated tokens!
for example, if i want to standardize on the name “groups” for my groups claim, yet i am using workspace one which provides this data as “group_names”, i can simply set the following in my Auth Server:
spec: identityProviders: - name: wso-idp openid: idToken: claims: - fromUpstream: "group_names" toClaim: "groups"
This simple yet extremely powerful feature is a huge boost to the AppSSO tooling which opens up awesome opportunities for integrations.
While the above works for external IDPs such as OIDC, LDAP and SAML, the configuration for internal unsafe IDPs in an auth server is a bit different, but also easy to configure.
spec: identityProviders: - name: test-users internalUnsafe: users: - username: joe password: "password" roles: - "dev" claims: given_name: "joe" family_name: "rosenberg" middle_initial: "A" email: "joe@vrabbi.cloud" alt_address: "123 Awesome Street" - username: wendy password: "password" roles: - "operator" claims: alt_address: "456 Cool Street" middle_initial: "T"
As you can see here, we simply configure per user, the custom roles and claims they should have in their ID tokens. With this ability, we can easily simulate real world test cases, even when using an internal unsafe IDP!
There is one more new feature in AppSSO in TAP 1.6, which while it may sound less interesting and exciting, it makes the offering more secure and more tunable to whatever your security teams requirements are.
Token Expiry Settings
In TAP 1.6, we now have the ability to configure the token expiry settings at a per auth server level for access, id, and refresh tokens.
The default expirations set by AppSSO are 12 hours for access and id tokens, and 30 days for refresh tokens.
In order to configure these settings, you just need to add the following to your auth server manifest:
spec: token: accessToken: expiry: "5m" idToken: expiry: "5m" refreshToken: expiry: "8h"
The time durations can be provided in seconds (s), minutes (m), or in hours (h). this means that for example the default 30 days for refresh tokens is actually set as “720h”.
Summary
As can be seen, a lot of effort was put into AppSSO in this release, making the integration tasks easier and more streamlined, and also improving on the capability set, and adding new and improved functionality to help all personas involved.
I’m really excited about these new features and can’t wait to see them being used in the wild!
-
TAP 1.6 – Metadata Store Improvements
The Metadata Store has been a key element in a secure supply chain within TAP since the GA of TAP, and it provides a central location where all CVE data and SBOMs are stored for our source code and images.
In TAP 1.6, we get a great new set of functionality in the metadata store, allowing for us to now have vulnerability reports stored per build and not just a single report per workload image.
This new feature can be extremely beneficial, as it allows us to perform queries and figure out in which version a specific vulnerability was first introduced, as well as a really great ability to understand which CVEs TBS for example with new dependencies was able to solve for us without the need to change anything in our source code!
The aggregated report is not gone, we simply now also have per build reports, giving us the best of all worlds!
While this may seem like a small feature, it actually truly is huge, and is a huge milestone down the path to being able to perform full end to end tracability and attestation for our supply chains, as well as providing a clear and simple API to be able to gain truly important insights on the development flows within our organization.
This new functionality, combined with the new data being included in the Metadata Store DB via AMR, can open up endless opportunities for data driven decision making and reporting for TAP, which simply has not been possible till today.
Summary
While this new functionality is API/CLI accessible only today, I truly hope to see this integrated into a UI flow in a future release, where we could do diffs between reports of an image and gain clear visibility of the changes between specific image builds in a clear and concise manner!
-
TAP 1.6 – Local Source Proxy
One of the best new features, if not the best new feature in TAP 1.6, is the introduction of a new component called Local Source Proxy (LSP).
One of the main challenges we have seen with rolling out TAP, is that while TAP aims to provide an abstraction above kubernetes, making the infrastructure invisible to the developer, the amount of infra level config that is needed on the developers machine, just to get started was a nightmare.
From installing Tanzu CLI from Tanzu network, to getting the right access to a kubernetes cluster and configuring the correct kubeconfig, and then above all of that, the user needed docker on their machine, as well as credentials to access the image registry of choice within the organization in order to do iterative development, as the OCI registry is used as a conduit for passing the source code form the developers IDE to the remote cluster.
In TAP 1.6, a huge amount of this has been solved. I have another post in which i go into detail on the new Tanzu CLI, and in this post we will be talking about LSP which solves the docker issue.
Now in TAP 1.6, my developers no longer need access to the image registry from their machines, and don’t need to have docker either!
LSP is a new components which has been integrated into the entire inner loop tooling. With LSP, when a developer begins a new inner loop development by use of the Tanzu apps CLI, or from the IDE plugins, instead of the source code being uploaded to the image registry from their machine, a port forward is opened between the LSP service on the cluster and their machine which serves as a inline proxy for the apps plugin to push the code too, which in turn mushes it to the image reigstry, however as this happens from within the cluster, a single registry credential is needed to be configured for LSP itself, and no developer ever needs access to it!
This new method, also works with ECR which is great, as the flow currently with ECR is even worse, sue to the fact that amazon do not allow for repo creation on push, and that meant that in nearly all cases, developers needed to pre-create repositories in ECR for every new microservice, making their lives much more entangled in the infrastructure then it ideally should be.
The new LSP model, works really well, and after testing it for a few weeks, i can say that it truly is a game changer for the developer experience, especially when onboarding developers to TAP, as its one less thing they need to deal with.
I was working with a customer on TAP recently where they have harbor configured with OIDC based authentication, which due to how Harbor works, requires their developers to login to the Harbor UI every few hours, and then login via the CLI again, just in order to do inner loop development. This new feature provided by LSP will greatly simplify the DevEx, and make the context switching and overall cognitive load much more reasonable for the average developer.
Summary
It is really great to see the improvements in this area, and i believe that these types of changes are what will truly help make the adoption of TAP a much smoother process, making developers truly happy, as well as giving operators the control and governance they need, without standing in the way of the developers.
-
TAP 1.6 – TBS Improvements
Tanzu Build Service (TBS) is a key component of TAP, allowing for building images directly from source code without needing to write and maintain docker files.
TBS itself is built upon the opensource project kpack which till recently was hosted under the pivotal github repo, and recently was donated to the Cloud Native Buildpacks project and is now located at https://github.com/buildpacks-community/kpack.
In TAP 1.6, TBS has a few changes that should be noted.
The first major change is the removal of the Ubuntu Bionic stack, making the Jammy stack the officially supported option, now that ubuntu bionic is EOL from canonical. As Jammy was made the default in TAP 1.5 it should not cause any issues, but if you are using the bionic stack, be warned!
The next major change, is the way you install the full dependencies package. In TAP the full TBS dependencies which are required in air gapped environments, and strongly recommended in production environments even when internet access is available, are packaged in a separate carvel package repository, and installed as another package install alongside TAP.
Previous to TAP 1.6, the versioning of the package repository and package itself were based on the version of the TBS package within TAP and not on the TAP version itself. Now with TAP 1.6 and on, the versioning is the same as the TAP version, making the process easier to manage.
Another key difference in the installation is that previously you did not need to pass any values into the TBS full dependencies package install, but in TAP 1.6 and on, you need to pass values to the package which should be the same values file that you provide to TAP itself.
With all that out of the way we can now talk about the feature im truly excited about which is the introduction of the new Buildpack and ClusterBuildpack CRDs.
Previously in Kpack, we had 3 main system level CRDs:
- ClusterStack – the pairing of a build and a run image which are used to build your images
- ClusterStore – a cluster scoped resource that references multiple buildpackages.
- ClusterBuilder / Builder – resources to define and create Cloud Native Buildpacks builders all within the kpack api. basically a pairing between a store and a stack.
While this model worked, the clusterstore caused a bunch of issues, and had some limitations and pain points, as well as management overhead.
As per the Buildpack CRD RFC:
The ClusterStore being the single location for all buildpack images used in multiple builders makes managing the available buildpacks within kpack cumbersome. Adding new buildpacks requires modifying an existing resource and removing buildpacks requires carefully selecting the buildpack image to remove from the list of buildpackage images. The
kp
cli was built to handle this complexity but, thekp
cli should not be a prerequisite to managing buildpacks within kpack.
The ClusterStore being a monolithic specification of all available buildpacks leads to performance issues within kpack. If the list of available buildpacks within a ClusterStore is lengthy the reconciliation of a single ClusterStore can take considerable time. If a single buildpack within the ClusterStore is unavailable reconciliation will fail which will cause the entire contents of the ClusterStore to be unavailable.With that background we can now see why a new solution was needed.
To solve these issues, Kpack has introduced a new set of CRDs, Buildpack and ClusterBuildpack, both providing the same functionality just one at the namespace scope and one at the cluster scope.
A Buildpack CR is simply a CR pointing at the OCI image of the relevant buildpack, these buildpack CRs are now referenceable within a builder directly, without the need of working with stores.
As of TAP 1.6, the new TBS configuration uses this new set of APIs instead of the previously used ClusterStore APIs.
While this may seem like a backend detail which should not really matter to most, and that may indeed be the case, it allows for less errors and a better performing platform, and it also allows for easier integration of third party or custom homegrown buildpacks.
A good example of this is when i had a use case to add a third party buildpack which enables installing apt packages into images.
When i did this in previous TAP versions, i needed to package my own Cluster Store, and then also update my builder accordingly, now with TAP 1.6, i can simply add the new buildpack resource and reference it in the builder, with no need to rebuild and package a cluster store which is a tedious process.
This model opens up a much easier path to extending TBS with custom buildpacks which is a great option to have in your toolbelt for the day that you need it.
Summary
While these changes may not be game changing things you will interact with daily, the subtle yet continuous improvements in these components such as TBS, are great to see, and all form together what in my opinion is the most mature and full featured Developer Platform offering on the market!