- SAP Managed Tags:
With the latest CAP major release 6 for
For the first release of CAP on Kyma, our goal was to support “extension” projects:
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
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:
(Source: CAP documentation → Deploy to Kyma/K8s)
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
As a prerequisite, you need to install the
You can create a container image for your service with a
No
The buildpack approach was already followed by Heroku and Cloud Foundry, but things are done in a different place:
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.
Everything that runs or happens on Kubernetes is described with resource files. They are formatted as YAML files, but JSON is possible as well.
Example:
Kubernetes
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.
With the
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
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.
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
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
The configuration of the Helm chart is stored in the
Let’s have a brief look at the Kubernetes resources provided by the Helm chart:
Your service gets into action using a Kubernetes
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.
Example:
This creates a secret containing the credentials in the cluster:
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
For example:
Now, you can run your application with the real XSUAA instance. For example, with CAP Node.js:
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
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
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
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.
cds and 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.Scope
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.
Runtime Needs
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.
Deployment
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 (or docker compatible) and the pack tools.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
No
Dockerfile needed!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.
Example:
busybox-pod.yaml:apiVersion: v1
kind: Pod
metadata:
name: busybox
spec:
containers:
- name: busybox
image: busybox
args:
- sleep
- "3600"
Kubernetes
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.
With the
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
chart/values.yaml file. cds add helm creates this file with defaults based on your CAP project’s configuration. The content is similarly structured like an mta.yaml file.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.
Example:
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.For example:
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
Enable ;-).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.Learn More
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”.
Examples
Further, CAP samples have been extended for Kyma deployment:
The End
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.
10 Comments
