CAP on Kyma – Deploy your CAP apps to SAP BTP, Kyma Runtime
With the latest CAP major release 6 for
cds-dk, you can deploy your CAP application on the Kyma Runtime of SAP Business Technology Platform (SAP BTP). The Kyma Runtime is the SAP-managed offering for the Kubernetes based Kyma cloud-native application runtime.
For the first release of CAP on Kyma, our goal was to support “extension” projects:
- Single-tenant CAP service (Node.js / Java)
- SAP HANA database
- SAP Fiori elements or SAPUI5 freestyle UIs
- Authentication based on XSUAA
- Connectivity to cloud and on-premise systems
As usual, we went beyond the pure technical enablement: we wanted to make it as easy as possible for you to get your application on the Kyma Runtime.
But let’s start with the technical enablement, the runtime stuff.
The runtime support was not a big deal. As CAP applications run on your local machine and on Cloud Foundry, why shouldn’t it be possible to run them in another environment like Kyma? There must be a Node.js or Java execution environment for sure. But this is easy to achieve with containers. Differences are in the interaction between platform and applications.
An important aspect is how applications get access to external services, such as the SAP BTP services.
In the environment variable
VCAP_SERVICES, Cloud Foundry provides service bindings as JSON to applications. This mechanism exists neither in Kubernetes nor in Kyma. Service credentials are stored in secrets and can be injected into environment variables or into the file system of an application.
We thought that it would be good to have something that might allow interoperation with non-SAP BTP services as well. Ideally, an open standard. We’ve chosen servicebindings.io, which is closest. Read more about it in the blog post The new way to consume Service Bindings on Kyma Runtime.
Once we had ensured that CAP runs and could access SAP BTP services, we started looking for a good deployment experience. Deployment on Kyma – and on Kubernetes in general – includes the following tasks:
- Build container images for your application
- Push container images to a container registry
- Apply Kubernetes resources for your application (using the pushed container images)
(Source: CAP documentation → Deploy to Kyma/K8s)
Containerize Your Application
SAP recommends Cloud Native Buildpacks, such as provided by the Paketo Buildpacks to build container images. You might wonder if this really is the way to do it, everyone seems to use
Dockerfiles. That’s true, but buildpacks have some convincing benefits that make your life easier.
As a prerequisite, you need to install the
docker compatible) and the
You can create a container image for your service with a
pack command like this:
pack build $CONTAINER_REGISTRY/cpapp-srv --path gen/srv \ --buildpack gcr.io/paketo-buildpacks/nodejs \ --builder paketobuildpacks/builder:base
The buildpack approach was already followed by Heroku and Cloud Foundry, but things are done in a different place:
- Cloud Foundry:
cf pushuploads your application files to the staging service within the Cloud Foundry cluster. The staging service builds the container image and stores it in Cloud Foundry’s built-in registry.
- On the Kyma Runtime, this process happens out-of-cluster. First, you build the container image and second, you upload it to some container registry. Unfortunately, SAP has no such offering.
You have the choice between various cloud and self-hosted container registry offerings available. You just need to make sure it is secure and reliably accessible from the Kyma cluster.
Play the Kubernetes API
Everything that runs or happens on Kubernetes is described with resource files. They are formatted as YAML files, but JSON is possible as well.
apiVersion: v1 kind: Pod metadata: name: busybox spec: containers: - name: busybox image: busybox args: - sleep - "3600"
kubectl command line lets you bring this resource into your cluster:
kubectl apply -f busybox-pod.yaml
Under the hood, this sends a request to the Kubernetes API that checks the resource and activates it in the cluster. An operator watching for changes picks it up and brings it to live.
Pod resource, you run a single container image that executes the waits for an hour and terminates after that.
The image is downloaded from the specified container registry. By default, Docker Hub is used if no registry is specified. In this example, only the image name
busybox is provided.
So, once your service’s container image is available in the container registry, you can apply the resource files for your application.
There are different ways to structure and apply resource files. Our choice is Helm.
The CAP Helm Chart
Helm allowed us to create a set of reusable and configurable deployment files for CAP applications. See section Customize Helm chart in the CAP documentation for more details. With the CAP tooling installed, you can add the Helm chart to your project by just running
cds add helm.
The Helm chart contains all the required Kubernetes resources for deploying your application, SAP HANA database content and HTML5 applications, as well as creating instances of SAP BTP services and consuming them.
You can even update the Helm chart later with another run of
cds add helm.
The configuration of the Helm chart is stored in the
cds add helm creates this file with defaults based on your CAP project’s configuration. The content is similarly structured like an
Let’s have a brief look at the Kubernetes resources provided by the Helm chart:
Your service gets into action using a Kubernetes
Deployment resource. This resource supports having multiple instances of the same service and has zero-downtime upgrade built-in. The SAP HANA and HTML5 deployments are done using
Jobs. Don’t search for them after successfully installing the Helm chart. They get cleaned-up if everything worked well.
Using SAP BTP Services
You might wonder how to create SAP BTP service instances from Kyma. Let me take you to a short journey to the past: In former times, the SAP BTP services were registered in the Service Broker of Cloud Foundry landscapes. But SAP has already freed the services from the Cloud Foundry chains. Nowadays, services are registered in the SAP Service Manager that isn’t limited to Cloud Foundry. You can connect a Kyma Runtime – or in general any Kubernetes – cluster with an SAP BTP subaccount. The SAP BTP Service Operator in your Kyma cluster does the connection to the SAP Service Manager. It is automatically installed and configured by enabling the Kyma Runtime.
The SAP BTP Service Operator has custom resource definitions for creating service instances and service bindings. Service bindings create secrets that are injected into the applications’ pods. I’ve already explained that.
apiVersion: services.cloud.sap.com/v1alpha1 kind: ServiceInstance metadata: name: cpapp-xsuaa spec: serviceOfferingName: xsuaa servicePlanName: application
apiVersion: services.cloud.sap.com/v1 kind: ServiceBinding metadata: name: cpapp-srv-auth spec: serviceInstanceName: cpapp-xsuaa
This creates a secret containing the credentials in the cluster:
kubectl get secrets
NAME TYPE cpapp-srv-auth Opaque
The CAP Helm chart lets you configure your required services without the need to write these files.
But even without deploying your application, you can test with those Kubernetes provisioned SAP BTP services. As you can do for Cloud Foundry, you can connect your local application to them using
cds bind. Just add the
--on k8s option.
cds bind --to cpapp-srv-auth --on k8s
Now, you can run your application with the real XSUAA instance. For example, with CAP Node.js:
cds watch --profile hybrid
Why Kyma Runtime?
So, that’s all nice and good, but why should I bother about Kyma Runtime?
Kubernetes is a mature cloud platform with convincing concepts and functionality built-in. But even more important, it is the de-facto industry standard for running containerized workloads. It has a huge and vibrant ecosystem.
The Kyma Project adds service mesh, serverless, eventing, and observability functionality on top of it by using established open source technology.
SAP provides you with a managed offering of all of that embedded in the SAP BTP. You just need to click on
Added Value on Top of Kubernetes: The Service Mesh
Services meshes are good examples how Kubernetes extensions can add value. Istio is a service mesh that builds on Kubernetes and is included in Kyma. It’s a programmable, secure network within your Kubernetes cluster.
For example, you can use it to secure the communication between services. Let’s say you have a shopping application, which consists of a Bookshop and an Order service, and you want to ensure that the Order service can only be called from Bookshop. With Istio that’s possible with some configuration – you guess it: resource YAML files. No programming required!
The Bookshop just calls
http://order/.... Istio injects sidecar containers that run side-by-side with your applications’ containers, and take over the external communication for them. By that, the HTTP request from Order is sent through a mTLS tunnel and for the Order service it ensures that it accepts only requests from Bookshop. Istio generates and distributes the required certificates automatically. You don’t need to care for that.
Try it Yourself
You can learn how to deploy a CAP application with the Deploy Your CAP Application on SAP BTP Kyma Runtime tutorials, which are part of the SAP BTP end-to-end tutorial series.
If you’re new to CAP, you should create the tutorial application from scratch with the Build an Application End-to-End Using CAP, Node.js and VS Code tutorial mission:
Alternatively, you can start with the prepared application from the
cap-roles branch of the tutorial’s examples repository.
You will find more information in the new Deploy to Kyma/K8s guide as part of the revamped Deployment Cookbook in the official CAP documentation “capire”.
Further, CAP samples have been extended for Kyma deployment:
That’s it. I hope you’ve enjoyed reading this blog. I’m looking forward to hearing from you about your first hands-on experience with CAP on the Kyma Runtime.
thank you for this blog post.
You stated that currently only single tenant apps are possible. Will and if yes when will multitenancy be possible?
You can build multi tenancy applications on Kyma Runtime. It works the same way like it works for CF. See the CAP Multi tenancy Cookbook for general CAP multi tenancy documentation.
However, we do not yet have support in our Helm chart. That means you need to add the required Kubernetes resources, such as the SaaS registry and the Service Manager instance, yourself. You can just put them into the chart folder along with the templates provided by "cds add helm". We consider to add it with one of our next relases.
One important remark wrt. Service Manager. You need to create the Service Manager "container" instance in CF. Otherwise you won't be able to create HDI container instances.
There are a few resources on multi tenancy on Kyma available. For example:
I haven't reviewed them, but I would assume that they provide good guidance.
thanks for the valueable answer. Good to know that there is already a solution and you work on further simplicity.
In the context of this blog post, does it mean SAP is moving away from Cloud Foundry in general and specifically for CAP? Does SAP intend to stop support for applications deployed to BTP Cloud Foundry in future?
Thanks for this great question. We are not moving away from Cloud Foundry and do not stop support for applications deployed to SAP BTP, Cloud Foundry runtime.
As we evolve Kyma as a K8s-based runtime along our unified runtime strategy, it is of equal importance to support CAP on Kyma as a first-class citizen in multi-cloud.
The Cloud Foundry runtime and the Cloud Foundry based services will not go away. The Cloud Foundry based services are planned to be made consumable in Kyma as well, so that customers have full flexibility.
Thanks for your content.
Could you please share the advantages of CAP on Kyma against CAP on CF Runtime ?
The advantage of running CAP on Kyma is that you can make use of all the Kyma und Kubernetes functionalities and its ecosystem. I gave Istio as an example in the article.
A good platform choice depends on the project's needs and also on its scale.
Very useful blog Uwe! Thanks for sharing this with community.
How can we access tables and other hana objects which are part of a different HDI container in Kyma? In CF we could just add a connection in the mta.yaml file but how to do the same in Kyma?
You can create additional service bindings to your HDI containers.But because HANA Cloud doesn't yet support Kyma and Kubernetes, you need to create a secret with the credentials of the HDI container for each of them.
The secret needs to service binding metadata with which you can access it in your CAP application. See example script to create the secret.
In the Helm chart (values.yaml), just add the additional bindings.