This post is the second part of a three-part series on provisioning SAP HANA Cloud databases from Kyma and Kubernetes. Part one covered the main concepts of BTP runtime environments, including Kyma and Kubernetes. This post describes how to provision HANA Cloud instances from a Kyma environment. Part three covers the same topics from a (non-Kyma) Kubernetes environment.
To work through the steps in this blog post, you will need a BTP subaccount with the Kyma environment enabled. Here is my setup, for a subaccount called, with a complete lack of imagination, "kyma".
One immediate difference you might notice is that, while Cloud Foundry administration tasks and views are built into the BTP Cockpit, the Kyma environment provides a link to a separate Console. This difference shows elsewhere: in general, while you can manage Cloud Foundry apps from within the BTP Cockpit main page, you will manage Kyma and Kubernetes environments from their own tools (graphical console or command line tools).
The interface between the Kyma Kubernetes environment and BTP is provided by two components. An SAP BTP Service Operator in Kyma communicates with a dedicated instance of Service Manager in the BTP subaccount. Service definitions created in Kyma then get acted on by Service Manager.
The BTP Cockpit "instances and subscriptions" page for the subaccount shows the dedicated Service Manager instance. You should not have to interact directly with this instance at all.
This section describes how to provision a HANA database instance from the Kyma dashboard. The following section describes how to do the same thing using the kubectl command-line tool.
To group together related resources and services, Kubernetes uses namespaces. There is a default namespace, which you could use, but here we will create a separate namespace for our HANA Cloud activities. You can do this from the Kyma dashboard by going to Namespaces in the navigation pane, clicking Create Namespace, and giving a name of hana-cloud.
From within the hana-cloud Namespace in the Kyma dashboard, choose Service Management > Service Instances in the navigation pane, and click Create Service Instance.
For a HANA Cloud instance, you do need to specify some parameters such as memory and storage space. For this reason, it is as well to go directly to the YAML tab of the Create Service Instance dialog, and paste in YAML content such as this:
The apiVersion, kind, serviceOfferingName and servicePlanName are all fixed for HANA database instances. The other parameters are up to you, within the limits of what HANA accepts.
The generateSystemPassword parameter is, so far as I know, unique to Kubernetes at the moment, and it avoids having to keep system passwords in a plain text file. Later on, we'll see how to get the password from a Kubernetes secret.
You should see a service instance with name "hana-instance-tom" in the Kyma dashboard. If you go to the BTP Cockpit and look at the Instances and Subscriptions page, you should see a service instance with name "hana-instance-tom-ex" being created. This will take some time to finish creation.
When it is created, you cannot delete this instance from HANA Cloud Central or from the BTP Cockpit: you must delete it from Kyma by deleting the service instance in the Kyma dashboard or using the kubectl command-line tool.
You create service bindings to define connection parameters for the HANA database. You can create a couple of types of service binding to HANA databases. Here we create a service binding that will expose the generated password for the DBADMIN system user.
From the Kyma dashboard, go to Service Management > Service Bindings in the navigation pane, and click Create Service Binding. Again, go to the YAML tab and enter this YAML
The name and external name again represent the way this binding is represented in Kyma (name) and in the BTP subaccount (externalName). The scope and credential-type parameters declare that this binding will provide the DBADMIN password.
Kubernetes keeps confidential items like passwords and certificates in what it calls "secrets". Once the service binding is created, you can get the password from Configuration > Secrets in the navigation pane. Click the secret hana-binding-tom-secret. and then click Decode to display the values, as shown here:
The other kind of binding you may wish to create is to get information such as the host name and port number. You can do this with the following YAML content:
You now have the information needed to provide connection parameters for the HANA database.
As an alternative to the Kyma dashboard, you can use the kubectl command-line tool to define and query the namespace, service instance, service binding and secret resources in your Kyma environment. This section assumes you have the kubectl CLI installed.
Authorization to access the Kyma environment from kubectl is provided using KUBECONFIG, which is a configuration file. For proper documentation, see the Kubernetes docs, here I will just rush through the basics.
To set up the KUBECONFIG for the Kyma environment, open the BTP Cockpit, go to the subaccount of interest, click the Kyma environment, and click KubeconfigURL to download the configuration file as kubeconfig.yaml.
If you would rather do this from a command line, you can do so with a curl command, supplying the KubeconfigURL as argument:
Whether on Windows or Mac or Linux, you should then copy the file to a suitable location (a folder for your project) and then define an environment variable KUBECONFIG that points to the file. On Linux, this would be something like this:
Then the first kubectl command you execute will use this file to authenticate you against the Kyma environment, and log you in.
If you want to extract the password in a single command, you can do the following:
This blog post shows how to provision HANA Cloud database instances into a Kyma namespace using the Kyma dashboard or the kubectl CLI. For more information see the documentation here. A follow up blog post will show you how to set up the SAP BTP Service Operator and the Service Manager for you to provision instances from your own Kubernetesl landscape.
Prerequisite: a Kyma environment in BTP
To work through the steps in this blog post, you will need a BTP subaccount with the Kyma environment enabled. Here is my setup, for a subaccount called, with a complete lack of imagination, "kyma".
One immediate difference you might notice is that, while Cloud Foundry administration tasks and views are built into the BTP Cockpit, the Kyma environment provides a link to a separate Console. This difference shows elsewhere: in general, while you can manage Cloud Foundry apps from within the BTP Cockpit main page, you will manage Kyma and Kubernetes environments from their own tools (graphical console or command line tools).
The interface between the Kyma Kubernetes environment and BTP is provided by two components. An SAP BTP Service Operator in Kyma communicates with a dedicated instance of Service Manager in the BTP subaccount. Service definitions created in Kyma then get acted on by Service Manager.
The BTP Cockpit "instances and subscriptions" page for the subaccount shows the dedicated Service Manager instance. You should not have to interact directly with this instance at all.
The BTP Cockpit instances and subscriptions page, showing the service manager and the Kyma environment.
Provisioning from the Kyma dashboard
This section describes how to provision a HANA database instance from the Kyma dashboard. The following section describes how to do the same thing using the kubectl command-line tool.
Create a namespace
To group together related resources and services, Kubernetes uses namespaces. There is a default namespace, which you could use, but here we will create a separate namespace for our HANA Cloud activities. You can do this from the Kyma dashboard by going to Namespaces in the navigation pane, clicking Create Namespace, and giving a name of hana-cloud.
Create a Namespace from the Kyma dashboard
Create a HANA database service instance
From within the hana-cloud Namespace in the Kyma dashboard, choose Service Management > Service Instances in the navigation pane, and click Create Service Instance.
Create a service instance in the Kyma dashboard
For a HANA Cloud instance, you do need to specify some parameters such as memory and storage space. For this reason, it is as well to go directly to the YAML tab of the Create Service Instance dialog, and paste in YAML content such as this:
apiVersion: services.cloud.sap.com/v1
kind: ServiceInstance
metadata:
name: hana-instance-tom
spec:
serviceOfferingName: hana-cloud
servicePlanName: hana
externalName: hana-instance-tom-ex
parameters:
data:
memory: 30
vcpu: 2
generateSystemPassword: trueThe apiVersion, kind, serviceOfferingName and servicePlanName are all fixed for HANA database instances. The other parameters are up to you, within the limits of what HANA accepts.
The generateSystemPassword parameter is, so far as I know, unique to Kubernetes at the moment, and it avoids having to keep system passwords in a plain text file. Later on, we'll see how to get the password from a Kubernetes secret.
You should see a service instance with name "hana-instance-tom" in the Kyma dashboard. If you go to the BTP Cockpit and look at the Instances and Subscriptions page, you should see a service instance with name "hana-instance-tom-ex" being created. This will take some time to finish creation.
When it is created, you cannot delete this instance from HANA Cloud Central or from the BTP Cockpit: you must delete it from Kyma by deleting the service instance in the Kyma dashboard or using the kubectl command-line tool.
Create a Service Binding to the HANA instance
You create service bindings to define connection parameters for the HANA database. You can create a couple of types of service binding to HANA databases. Here we create a service binding that will expose the generated password for the DBADMIN system user.
From the Kyma dashboard, go to Service Management > Service Bindings in the navigation pane, and click Create Service Binding. Again, go to the YAML tab and enter this YAML
apiVersion: services.cloud.sap.com/v1
kind: ServiceBinding
metadata:
name: hana-binding-tom
spec:
serviceInstanceName: hana-instance-tom
externalName: hana-binding-tom-ex
secretName: hana-binding-tom-secret
parameters:
scope: administration
credential-type: PASSWORD_GENERATEDThe name and external name again represent the way this binding is represented in Kyma (name) and in the BTP subaccount (externalName). The scope and credential-type parameters declare that this binding will provide the DBADMIN password.
Kubernetes keeps confidential items like passwords and certificates in what it calls "secrets". Once the service binding is created, you can get the password from Configuration > Secrets in the navigation pane. Click the secret hana-binding-tom-secret. and then click Decode to display the values, as shown here:
The secret containing the DBADMIN password.
The other kind of binding you may wish to create is to get information such as the host name and port number. You can do this with the following YAML content:
piVersion: services.cloud.sap.com/v1
kind: ServiceBinding
metadata:
name: hana-binding-tom-2
spec:
serviceInstanceName: hana-instance-tom
externalName: hana-binding-tom-2-ex
secretName: hana-binding-tom-secret-2You now have the information needed to provide connection parameters for the HANA database.
Provisioning from the command line
As an alternative to the Kyma dashboard, you can use the kubectl command-line tool to define and query the namespace, service instance, service binding and secret resources in your Kyma environment. This section assumes you have the kubectl CLI installed.
Authorization to access the Kyma environment from kubectl is provided using KUBECONFIG, which is a configuration file. For proper documentation, see the Kubernetes docs, here I will just rush through the basics.
To set up the KUBECONFIG for the Kyma environment, open the BTP Cockpit, go to the subaccount of interest, click the Kyma environment, and click KubeconfigURL to download the configuration file as kubeconfig.yaml.
Download the KubeConfig YAML file to provide your authorization to Kyma
If you would rather do this from a command line, you can do so with a curl command, supplying the KubeconfigURL as argument:
> curl https://kyma-env-broker.cp.stage.kyma.cloud.sap/kubeconfig/<guid>; > kubeconfig.yamlWhether on Windows or Mac or Linux, you should then copy the file to a suitable location (a folder for your project) and then define an environment variable KUBECONFIG that points to the file. On Linux, this would be something like this:
> export KUBECONFIG=/home/username/hana-cloud-k8s/kubeconfig.yamlThen the first kubectl command you execute will use this file to authenticate you against the Kyma environment, and log you in.
From then on, here are commands you can use to create the namespace, service instance, and service binding. The contents of the yaml files are the same as those above.
> kubectl create namespace hana-cloud
> kubectl apply -f hanadb.yaml -n hana-cloud
> kubectl apply -f hanabinding.yaml -n hana-cloud
> kubectl get secret hana-binding-tom-secret -n hana-cloudIf you want to extract the password in a single command, you can do the following:
> kubectl get secret hana-binding-tom-secret --namespace hana-cloud '--template={{.data.password}}' | base64 --decodeSummary
This blog post shows how to provision HANA Cloud database instances into a Kyma namespace using the Kyma dashboard or the kubectl CLI. For more information see the documentation here. A follow up blog post will show you how to set up the SAP BTP Service Operator and the Service Manager for you to provision instances from your own Kubernetesl landscape.
- SAP Managed Tags:
3 Comments
