SAP Cloud Connector deployed on SAP Kyma
Content of this blog
Connecting your SAP on-premise systems to SAP BTP requires the SAP Cloud Connector (CC) for a secure connection. For testing purposes it can be handy to have a CC running 24/7. Instead of searching for a box to install it on, why not on Kyma?
This blog explains the steps necessary from CC download, container image creation and finally deployment on Kyma runtime
1. Download of SAP Cloud Connector
It all starts with downloading the cloud connector. As we just aim for a test installation we pick the portable package. You can download it from the SAP development tools site for Linux with x86_64 architecture.
Could we automate the download in the container through curl? Certainly yes, I’m not sure if the license allows this way of obtaining the packaging. If you know, you can enhance the image accordingly.
2. Container image creation
Now, create an empty
Dockerfile in that folder and open it in the editor. I suggest to build it upon a Java 11 image which is still very lean.
#Build SAP Cloud Connector image FROM bitnami/java:11-debian-10 WORKDIR /usr/sapcc COPY . /home RUN apt update && \ apt install lsof && \ apt install nano EXPOSE 8443/tcp
If you are not familiar with Docker: FROM tells the baseline image to be used, a lean Debian Linux with Java 11 pre-installed (OpenJDK). WORKDIR creates the directory which will be opened if you tty into the container at runtime. With COPY the cloud connector packages goes into the home folder. Then we unstall lsof (needed by CC and not part of the image) and nano as an editor (not needed, just in case you want to open up a textfile later at runtime).
Finally the port 8443 which is the standard CC port is exposed, so that the container can be reached from outside.
Do you know how Kyma/ Kubernetes retrieves your image? It is pulled from a container registry! I use Docker Hub in this example but many more alternatives exist. If you have not registered yet, please do an get a user name.
Now we are good to build the image with
$ docker build -t <your-registry-and-username>/java11-sapcc:1.0 .
This can take a few minutes to download the data and building the image. Next, we push the local image to the registry for example with
$ docker push <your-registry-and-username>/java11-sapcc:1.0
Done, ready to deploy on Kyma!
3. Kyma Deployment
I assume you know how to get Kyma running on BTP (free trial is available!) or as your own cluster. If you want to go through first steps there are great tutorials out there.
Create a new file in your folder and name it e.g.
sap-cc-deployment.yaml. Looking at how to build the deployment we go step by step.
We need a namespace without Istio sidecar injection. That is because SAP CC works on https port already and we want to expose it to the internet directly.
apiVersion: v1 kind: Namespace metadata: name: dl-sapcc labels: istio-injection: disabled ---
3b. Persistent Volume Claim
Cloud Connector needs some persistence (PVC) to store configuration data. So here it is:
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: sapcc-pvc namespace: dl-sapcc spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi ---
3c. Deployment of our image
The important part – deploy the image in a pod as a container and reference it to the PVC’s volume.
--- apiVersion: apps/v1 kind: Deployment metadata: name: sap-cloud-connector namespace: dl-sapcc spec: replicas: 1 selector: matchLabels: app: sapcc-app template: metadata: labels: app: sapcc-app spec: containers: - name: sap-cc-image image: <your-registry-and-username>/java11-sapcc:1.0 imagePullPolicy: Always ports: - containerPort: 8443 resources: requests: memory: "512Mi" cpu: "250m" limits: memory: "1Gi" cpu: "500m" volumeMounts: - mountPath: /usr/sapcc name: sapcc-volume command: ["/bin/sh"] args: ["-c", "if [ ! -f /usr/sapcc/go.sh ]; then tar -xzof /home/sapcc*.tar.gz && rm /home/*.tar.gz; else echo Already installed, starting; fi; ./go.sh"] volumes: - name: sapcc-volume persistentVolumeClaim: claimName: sapcc-pvc ---
After the container started up, this unpacks the CC package if not already done before (e.g. the pod restarted once already) and then calls the start script.
3d. Service as load balancer
Next step is the service which connects to the container and exposes port 8443 through a load balancer IP to the internet.
apiVersion: v1 kind: Service metadata: labels: app: sapcc-app name: sappcc-service namespace: dl-sapcc spec: ports: - name: "adminport" port: 8443 targetPort: 8443 type: LoadBalancer selector: app: sapcc-app
3e. Add DNS entry
To be able to reach the service’s load balancer a DNS entry is handy – that way no IP address must be typed. You can do this entry either in Kyma 2.0 UI’s DNS Entry menu or by modifying the service from 3d with the below annotations:
apiVersion: v1 kind: Service metadata: annotations: dns.gardener.cloud/dnsnames: dlcc.<your-kyma-cluster-name>.k8s-hana.ondemand.com dns.gardener.cloud/ttl: "600" dns.gardener.cloud/class: garden labels: app: sapcc-app name: sappcc-service namespace: dl-sapcc spec: ports: - name: "adminport" port: 8443 targetPort: 8443 type: LoadBalancer selector: app: sapcc-app
Save the file with all elements in it and run this command on your Kyma cluster:
$ kubectl apply -f sapcc-deployment.yaml
You should now be able to call the SAP Cloud Connector on Kyma and attach it to your on-premise systems and SAP BTP.
This was a simple example of deploying a workload to Kyma where the application is exposed by load balancer. A production instance of SAP Cloud Connector will likely run on-premise since your on-premise production systems are not exposed to the internet.