Overview

Skill Level: Intermediate

This recipe - co-authored with Rene Meyer - demonstrates how to deploy a dockerized Node.js event data consumer and its related data warehouse presently running on the public IBM Cloud Container Service to an instance of IBM Cloud Private.

Ingredients

Software Requirements


Recipe Requirement
Get the set up ready, by covering the following 3 IoT Recipes:

 

Step-by-step

  1. Introduction

    The recipe ‘Process Elevator device data using the Watson IoT Platform and Node.js Consumers‘ showed how to implement, test and deploy a Node.js consumer application that read event data from the Watson IoT Platform and stored it in a DB2 Warehouse database on Cloud database. A second recipe titled ‘Dockerize an Elevator event data consumer using Docker and the IBM Cloud Container Service‘ demonstrated how you could dockerize the consumer application using Docker and then deploy it to the IBM Cloud Container Service in a public IBM Cloud.

    This recipe will take you through the steps needed to deploy the application in a Hybrid Cloud architecture where the IBM Watson IoT service is running on IBM Cloud (public) and the IoT consumer and its associated data warehouse for holding IoT event data on IBM Cloud Private. There are basically 3 tasks involved in this: create and configure a Db2 service on IBM Cloud Private, push the Docker image to the IBM Container Registry on IBM Cloud Private and re-configure and redeploy the IoT consumer application to the IBM Cloud Container Service on IBM Cloud Private. However, rather than doing it with as few steps as possible (starting with the most complex one), we will take you through a process that gradually allows you to migrate the application from public to private Cloud, starting with the easiest tasks and then introduce more advanced operations one by one.

    In this recipe you will therefore go through the following steps:

    1. Get started by installing the required tools.
    2. Deploy the IoT consumer application to IBM Cloud Private. The database will still remain in the public Cloud and the Docker image will remain on Docker Hub. This will introduce you to the user interface of IBM Cloud Private.
    3. Deploy the IoT consumer application to IBM Cloud Private using an image from the IBM Container Registry on IBM Cloud Private. This will need the image to be pushed to the registry first.
    4. Create a Db2 service on IBM Cloud Private, including persistent storage, and then create the target database table on that service.
    5. Deploy the IoT consumer application to IBM Cloud Private using the local image and database. Test that the data are now stored in the database on IBM Cloud Private rather than on the database in the public Cloud.
    6. Introduce a Kubernetes service that can be used to test that the IoT consumer applications are up running and responding to messages.

     

    Before we go into these details we will briefly introduce the architecture of the solution in the next section.

  2. Architecture

    In the pre-requisite recipe ‘Dockerize an Elevator event data consumer using Docker and the IBM Cloud Container Service‘ you turned an IoT event data consumer application developed using Node.js into a Docker Container which was then deployed to Kubernetes using the IBM Cloud Container Service on IBM Cloud (public). The Node.js consumer application read data from the Watson IoT Platform and stored the most current status for each elevator in a dedicated database table (ELEVATOR_STATUS) in the Data Warehouse managed by the Db2 Warehouse on Cloud service. From there, the status information was used e.g. by IBM Cognos Analytics to monitor if the elevators were up running or not.

    02.1-Public-Cloud-Deployment-Architecture

    All services, be it the IBM Watson IoT Platform, the IBM Cloud Container Service or the IBM Db2 Warehouse on Cloud were running in the public IBM Cloud. In this recipe we shall relocate the dockerized event data consumer and its related data warehouse from a public Cloud to a private Cloud using IBM Cloud Private, which results in the following Hybrid Cloud Architecture:

    02.2-Hybrid-Cloud-Deployment-Architecture

     The relocation will take place in 3 steps:

    1. In a first step the IoT event data consumer application will be relocated from the Kubernetes cluster running in the public Cloud to a Kubernetes cluster running on IBM Cloud Private. The image and the database will remain in the public Cloud.
    2. In a second step the deployment will be changed to pull the Docker image from a private Container Registry running on IBM Cloud Private rather than using the image that was pushed to the Docker Hub in the previous recipe. Before this can be done, the image must of course be pushed to the private registry.
    3. In a third and last step the deployment is changed to use a private Db2 database hosted on IBM Cloud Private. This step requires that the database is provisioned first, that there is persistent storage volume allocated with the database and that the target database table has been created.

     

    During this recipe you will get to deploy the consumer application using a variety of available mechanisms:

    1. The initial deployment will take place using the IBM Cloud Private dashboard and can reuse the Kubernetes deployment description defined in the previous recipe.
    2. The second step where a local Docker image is used is done using Docker, Kubernetes (kubectl) and Db2 Command Line Interface from the terminal window on your desktop.
    3. The third step is done using Kubernetes and Db2 Command Line Interface.

     

    IBM Cloud Private provides the following components:

    • Enterprise-ready distribution of Kubernetes
    • Common services for identity and access management, log aggregation and analysis, monitoring, alerting, auditing, and certificate, and key management.
    • Cloud Foundry an optional paid add-on, enabling organizations to create web-centric applications that need to run in a more flexible runtime like Kubernetes.
    • Containerized versions of IBM middleware, data, and analytics that are optimized to run on IBM Cloud Private, and are a part of the offering’s content catalog.

    The following figure shows the main components of IBM Cloud Private with Kubernetes, Common Services, Cloud Foundry, and IBM middleware, data, and analytics services:

    02.4-IBM-Cloud-Private

    In this recipe we shall use the Kubernetes based container platform and the Db2 service of the Common Services. The latter is part of the IBM Cloud Private service Catalog.

  3. Getting Started

    Before you can deploy the application to IBM Cloud Private you need to go through a couple of preparation steps:

    1. Install client tools on your desktop (if not already done)
    2. Download Kubernetes YAML files from GitHub.
    3. Install IBM Cloud Private (or obtain access to an instance of IBM Cloud Private)

    To prepare the development environment on your local machine, you need the following client tools:

    1. IBM Cloud Command Line Interface
    2. Atom (or Visual Studio Code)
    3. Firefox or Google Web Browser
    4. Docker Command Line Interface
    5. Kubernetes Command Line Interface

     

    Go through step 3 of the recipes “Process Elevator device data using the Watson IoT Platform and Node.js Consumers” and “Dockerize an Elevator event data consumer using Docker and the IBM Cloud Container Service” to get the client tools installed on your desktop. This step is of course superflous if you have already gone through those recipes. We installed the tools on an Ubuntu Linux 64 bit virtual machine.

    Go through Steps 3 and 6 of the recipe “Process Elevator device data using the Watson IoT Platform and Node.js Consumers” to retrieve the credentials in the VCAP file and to create a data warehouse and a table (ELEVATOR_STATUS) for storing device data. The credentials and connection information in the VCAP file are crucial. Download the file to the working directory.

    Also download the Docker and Kubernetes configuration files from GitHub from the following repository: https://github.com/EinarKarlsen/iot-consumer-kubernetes.  Extract the zip file and move the files to your working directory that contains the Node.js application. Start Visual Studio Code or ATOM in that directory.

    Install IBM Cloud Private or gain access to IBM Cloud Private. The instructions for doing so are found in the IBM Knowledge Center on the page titled ‘Installing IBM® Cloud private‘. You may also consult the recipe ‘Install IBM Cloud Private Single Host on Ubuntu 16.04‘.

     

  4. Deploying the Node.js Consumer Application to IBM Cloud Private

    This part of the recipe are concerned with two things: taking the first steps with the IBM Cloud Private user interface and getting the IoT Consumer deployed on IBM Cloud Private as-is, without any changes to the specification such as using a local registry or a local database. You will need the URL for IBM Cloud Private as well as the deployment definition in ‘kubernetes/iot-consumer-deployment.yml’ from the previous recipe. Once you have obtained that do the following:

    1. Start to log into IBM Cloud Private by entering the URL for IBM Cloud Private in the Web Browser
      04.1-Log-into-IBM-Cloud-Private
    2. Enter user name and password and click Log In.
    3. View the dashboard showing the utilization of the resources.
      04.2-View-Dashboard
    4. Select the icon in the top left part of the screen. This will show the drop down menu.
      04.3-Catalog
    5. There are menu items e.g. for Platform, Workloads and Security. Select the last menu item named Catalog to see the Helm chart offerings.
    6. Select the menu item Workloads>Deployments. This will show you the current list of deployments.
      04.4-Deployments
    7. Click the ‘Create Resource‘ link in the upper right corner of the IBM Cloud Private dashboard, which will open up a dialog for creating a new Kubernetes resource.
      04.5-Create-Resource-Dialog
    8. Copy the content of the file ‘kubernetes/iot-consumer-deployment.yml’ to the clipboard and paste it into the dialog.
      04.6-Create-IotConsumer-Deployment
    9. Click Create and wait for the resource to be created:
      04.7-IoT-Consuemr-Deployed
    10. Click the link iotconsumer-dp to get the details of the pod and scroll down to the end to see the number of pods:
      04.8-IoT-Consumer-Pods
    11. Select the 3 dots to the right of one of the pods and invoke the Remove command to kill the pod.
      04.9-Remove-Pods
    12. In the popup dialog, just click Remove Pod to accept the removal.
      04.10-Automatic-Pod-Creation
    13. Observe that whereas the pod gets killed, a new is immediately created so that the actual number of pods corresponds to the desired (and specified) number of pods.
    14. Click one of the pods to get the pod details.
    15. In the next window showing the pod details, click the Log tab to see the log file:
      04.11-Get-Consumer-Logs
    16. Return to the view that shows you the list of deployment.
      04.17-Deployments
    17. For the deployment iotconsumer-db, select the Edit command
      04.18-Change-Replicas
    18. Change the deployment definition from 2 replicas to 3 replicas and click Submit.
    19. Observe that the number of pods increases:
      04.19-One-new-Pod
    20. Redo step 18 and 19 and change the number of replicas back to 2.

    The IoT consumers are up running and waiting for data. To see if everything works as it should, start the elevator simulator application in the IBM Cloud dashboard so that it starts generating data for the IoT consumers. Then wait some time until the elevator simulator starts displaying messages in the log saying that it has updated the database. You can also check that the application works as it should by opening the console of the Db2 Warehouse on Cloud service and then explore the content of the table ELEVATOR_STATUS.

    04.16-Elevator-Status-Table

    Check that the TIMESTAMP column shows the current time and that all data is there for the elevators.

    Depending on the system that you are using you may have one or more Kubernetes nodes running. You can check that in a few couple of steps:

    1. Select the menu item Platform > Nodes:
      04.4-Nodes
    2. View the number of nodes. In this case there is only one Kubernetes node.
    3. Select a node to view the node details:
      04.6-Node-Details
    4. Scroll down to see the pods running on the node.

     

    This completes the first step. Changing the deployment from an IBM Cloud (public) instance to an IBM Cloud Private was quite straightforward and did not imply any changes to the deployment definition.

  5. Relocating the Docker Image to the IBM Container Registry

    The previous section used the image on Docker Hub to deploy the application. A better solution – dealing with a private Cloud – would be to use a private registry. In this section you will change the deployment so that it uses IBM Private Registry by going through the following steps:

    1. In the command line interface, connect kubectl to IBM Cloud Private.
    2. Follow the procedures described on the web page ‘Test an insecure registry‘ to secure your registry or alternatively to use the registry over an unencrypted HTTP connection.
    3. Log into Docker, tag the image appropriately and then push it to the private registry on IBM Cloud Private.
    4. Change the deployment definition of the application to use the private registry and then redeploy the application.

     

    To connect the command line interface to the private cloud instance do the following:

    1. In the IBM Cloud Private User Interface, click the icon for the user in the upper right corner:
      05.1-Configure-client
    2. Select the menu item Configure Client.
    3. In the resulting dialog Configure kubectl dialog, click the Page icon to copy the configuration parameters to the clipboard.
      05.2-Configuration-Commands
    4. Paste the configuration commands into your terminal window and run them. This will establish the connection to IBM Cloud Private:
      05.3-CLI-Configuration
    5. Test that kubectl and the connection to IBM Cloud Private works
      kubectl version
      kubectl get nodes

     

    Before you can push the image to the registry on IBM Cloud Private, you will need to follow the procedures described on the web page ‘Test an insecure registry‘ to secure your registry using a TLS certificate. Alternative, you can choose to use self-signed certificates, or use your registry over an unencrypted HTTP connection. In our case, if we had used an unencrypted HTTP connection, the following commands would be needed:

    docker --insecure-registry=docker-registry.example.com:8080 login https://docker-registry.example.com:8080

    {
    "insecure-registries" : ["mycluster.icp:8500"]}

    Next step is to get the image pushed to the private registry on IBM Cloud Private using the command line.  The article ‘Getting started with Private Registry hosted by IBM Bluemix‘ lists a few commands for getting started with the IBM Private Registry. In the current case you can simply do the following in a terminal window:

    1. Pull the docker image for the IoT event data consumer from Docker Hub to your desktop:
      docker pull einarkarlsen/iotreceiver
    2. Log into Docker using the name of your cluster:
      docker login mycluster.icp:8500
    3. Enter your user id and password for IBM Cloud Private.
    4. Tag the Docker image by prefixing the image name with ‘<cluster-name>/<your-user-name>/’ as shown below:
      docker tag iotreceiver mycluster.icp:8500/admin/iotreceiver:version1.0
    5. Push the Docker image to the registry:
      docker push mycluster.icp:8500/admin/iotreceiver
      05.4-Tag-and-Push-Image
    6. Wait until the image is pushed to the IBM Container Registry.
    7.  You can check that the image has been uploaded by selecting Platform > Images in the IBM Cloud Private dashboard:
      05.5-Images

    Now that the image has been uploaded to the local Registry it is a quite simple task to change the Kubernetes deployment file for the IoT consumer to use the local image rather than the one on Docker Hub, and then update the running application to use that image:

    1. Select the menu item Workloads>Deployments in the IBM Cloud Private user interface. This will show you the current list of deployments again.
      05.7-Edit-Deployment
    2. For the deployment iotconsumer-dp click the 3 dots to the right to open up the menu. Then select Edit to edit the deployment object.
    3. Change the image field as shown below (using the name for your cluster and your user ID):
      05.8-Changed-Deployment-Object
    4. Click Submit.
    5. Select the deployment iotconsumer-dp and scroll down to view the list of pods:
      05.9-Intermediate-pods
    6. Observe that there is an intermediate state where the existing pods are being removed and the new ones are created.
    7. Eventually the number will match the specified number of replicas in the deployment object, which in this case is 2:
      05.10-Final-pods

    You can achieve the same effect using a text editor and the command line on your local desktop. You will need to open up the deployment object, e.g. using Visual Studio Code or ATOM, and then update the image field accordingly:

    05.6-Kubernetes-Deployment-Object

    Having done this, submit the following commands in a terminal shell:

    kubectl get pods
    kubectl get deployments
    kubectl set image deployment iotconsumer-dp *=mycluster.icp:8500/admin/iotreceiver:version1.0

    Alternatively you could also edit the deployment definition using the command line. The Kubernetes online document for Deployments contain a comprehensive list of commands and use cases for managing deployments.

  6. Setting up the Data Warehouse on IBM Cloud Private

    In this section you will provision a local instance of IBM DB2 to take the role of the Data Warehouse for the application. In order to achieve this you will need to go through 3 steps:

    1. Provision storage for the database.
    2. Provision the database itself using a Helm chart in the catalog.
    3. Retrieve the URL and credentials for the new database.
    4. Create the target database table named ELEVATOR_STATUS to store information about current elevator status.

     

    The last step will provide you with the information needed to re-configure the deployment definition of the IoT consumer application to use the local database rather than the remote on IBM Cloud.

    For an elaborated description on how to work with Db2 in context of IBM Cloud Private we refer to the recipes ‘Db2 Integration into IBM Cloud Private 2.1‘ and ‘Deploy Db2-Dev into IBM Cloud Private 1.2‘. This recipe also contains instructoins on how to create the persistent storage step by step. More general description can be found in the following two references:

     

    The Persistent Volume needs to be pre-created prior to installing the chart if persistance.enabled=true and persistence.dynamicProvisioning=false (default values, see persistence section). It can be created by using the IBM Cloud Private UI or via a yaml file as the following example:

    apiVersion: v1
    kind: PersistentVolume
    metadata:
    name: <persistent volume name>
    spec:
    capacity:
    storage: 20Gi
    accessModes:
    - ReadWriteOnce
    hostPath:
    path: <PATH>

     The persistent storage in our case have been named mydb2, with capacity and access mode as shown below:

    06.1-Storage

    06.2-Persistent-Volume-Claim

    Having configured the persistent storage to be used by the database time has come to provision the database itself. For testing purposes we will use Db2 Developer Edition rather than Db2 Warehouse since it requires significantly less resources. To configure and provision Db2 go through the following steps:

    1. Select the Catalog menu item from the menu in the top left corner of the IBM Cloud Private User Interface.
    2. Select the chart named ibm-db2oltp-dev.
      06.3-DB2-Chart
    3. This will open up the page describing the service – as well as information on how to create the persistent storage:
      06.3a-Configuration-Start-Page
    4. Click Configure to start configuration of the chart. This will open up a window for entering the configuration parameters of the service.
    5. Provide a name for the database (in our case it is simply ‘mydb2’):
      06.4-DB2-Configuration-Basics
    6. Select the check button “I have read and agreed to the license agreements”.
    7. The secret field need to be filed in with a secret:
      06.5a-Certificate-URL
    8. Visit ‘http://ibm.biz/db2-dsm-license’ by reviewing and accepting the terms and conditions.
      06.5-Certificate
    9. Select and copy the key. Back in the Configuration page for Db2, paste it into the secret field.
    10. Scroll down and enter the instname (‘mydb2’ in our case) and password.
    11. Scroll down and set databaseName e.g. to ‘mydb2’:
      06.6-DB2-Configuration-Volume
    12. Configure the data persistent data volume as shown above entering the data volume name, existingClaimName and size (2 Gi).
    13. Click the Install button and wait for dialog saying that the installation is complete.
      06.8-Configuration-Complete
    14. Select Workloads > Helm Releases from the top left menu – or alternatively just click the View Helm Release button in the dialog – to view the Helm release:
      06.9-Completed-Deployment
    15. Select the Helm Release to view the details:
      06.10-View-Detail
    16. Select the deployment as shown above:
      06.11-Deployment-Pods
    17. Scroll down and select the Pod as shown above
    18. Click the Logs tab to view the log:
      06.12-View-Deployment-Logs

    You have now provisioned the Db2 database on IBM Private Cloud. You will however need to obtain the credentials for the database so that you can configure the Kubernetes deployment definition to use the database on IBM Cloud Private rather than on the public IBM Cloud. To achieve this do the following:

    1. Select the Workloads > Helm Releases menu item in the menu on the top left corner of the IBM Cloud Private User Interface.
    2. In the list of Helm releases, select the database (‘mydb2’) that you just provisioned.
    3. Scroll down to the end of the page:
      06.13-Get-Database-URL-from-UI
    4. Enter the last part of the text in the terminal window:
      export NODE_PORT=$(kubectl get --namespace default -o jsonpath="{.spec.ports[0].nodePort}" services mydb2-ibm-db2oltp-dev);
      export NODE_IP=$(kubectl get nodes --namespace default -o jsonpath="{.items[0].status.addresses[0].address}");
      echo jdbc:db2://$NODE_IP:$NODE_PORT/mydb2
    5. This will provide you with the IP address of the node port and the port number which is needed when configuring access to the database.
      06.14-Get-Database-URL-from-CLI

    Notice: you will indeed be able to determine the value of NODE_IP and NODE_PORT using the IBM Cloud Private user interface as well. If you go back to step 17 above, then you will see that the information is also provided by the Ingress IP and Port fields of the screenshot.

    The Db2 database is now provisioned with an associated volume and database. However, there is no target database table yet in the database (which in our case is simply called ‘mydb2’).

    1. List the pods using kubectl and then use kubectl exec to get into the container for Db2 to execute commands:
      kubectl get pods;
      kubectl exec -it <podname> bash;

      06.15-Bash-Login-to-DB2-Pod
    2. Change the user, enter your password (if requested) and get a list of Db2 commands:
      su - <DB2 instance name>
      db2 ?
    3. Connect to the database that was created when provisioning Db2 and list the number of tables. It should be empty:
      db2 connect to mydb2
      db2 list tables
    4. Create the table ELEVATOR_STATUS by invoking the following command first
      db2 - t
    5. The command will take you into the command line processor of Db2 and allow you to enter SQL statements directly.
      06.17-Create-db-table
    6. Enter the SQL statement that creates the ELEVATOR_STATUS table on a single line of text (see the code below for a complete definition of the table).
    7. Enter the QUIT command to get out of the Db2 command line processor:
      QUIT;
    8. Check that the table has been created by entering the following db2 command again:
      db2 list tables
    9. To get out of the command shell of the container you just need to type exit.  However, stay in the container for a while until it has been tested that the IoT consumer pods store the data in the database as they are supposed to do. This can be done with the following SQL query (for now the table should be empty):
      select * from mydb2.elevator_status;

    You can find additional DB2 command of interest by consulting the Command Reference, the online Tutorial or alternatively the Cheat Sheet.

    CREATE TABLE ELEVATOR_STATUS (
        DEVICEID VARCHAR(64) NOT NULL,
        DEVICETYPE VARCHAR(64),
        MOTORTEMP BIGINT,
        CABINSPEED BIGINT,
        CABINTEMP BIGINT,
        CURRENTFLOOR BIGINT,
        DIRECTION BIGINT,
        DOOROPEN INTEGER,
        LOAD BIGINT,
        MAINTENANCEREASON VARCHAR(128),
        MAINTENANCESTOP INTEGER,
        NUMBEROFFLOORS BIGINT,
        STATE VARCHAR(32),
        TIMESTAMP VARCHAR(128) NOT NULL,
        DATEVALUE BIGINT
    );

  7. Deployment using Db2 Database on IBM Cloud Private

    The IoT event data consumer, the local registry as well as the database for storing the current status of the elevators have now been completed. We have furthermore tested that the IoT event data consumer works with a remote as well as a local registry. Time has therefore come to change the deployment to use not only the local registry but also the local database.

    To do this, go through the following steps:

    1. In Visual Studio Code or ATOM, open the file ‘kubernetes/iot-consumer-deployment-localregistry.yml’ and save it as file ‘kubernetes/iot-consumer-deployment-localdb.yml’:
      07.1-Deployment-Spec-for-Private-DB
    2. Change all the environment variables that are relevant for the database to use the properties of the local database.
    3. Save the file

     

    This completes the required changes to the deployment definition.

    Next you will need to update the running deployment on IBM Cloud Private to use the changed deployment specification. Some techniques for doing this are described in the article ‘Kubernetes – Rolling Updates with Deployment‘.  We will keep things simple:

    1. Enter the following command in a new terminal window to apply the updates to the deployment:
      kubectl apply -f kubernetes/iot-consumer-deployment-localdb.ym --record
      07.2-Kubectl-Deploy-IoT-Consumer
    2. Notice: you may have to configure the terminal window to connect to IBM Cloud Private as described in the beginning of section 5 first.
    3. You can check the effect as usual and observe that the pods are changing using
      kubectl get pods;
    4. You can check the status and the rollout history using the following commands:
      kubectl rollout status deployment iotconsumer-dp
      kubectl rollout history deployment iotconsumer-dp

      07.6-Rollout-history
    5. Start following (-f) the log of all pods for the IoT consumer application with the following command:
      kubectl logs -f deployment/iotconsumer-dp
      07.3-Kubectl-Logs-Connected

    This completes the deployment of the IoT consumer to use the local database on IBM Cloud Private.

    Last step is to check that the deployment works as intended and that data are actually stored in the database:

    1. In IBM Cloud, start the elevator simulator application again so that it starts generating event data that can be consumed by the IoT consumer pods.
    2. Wait until the application has started in IBM Cloud.
    3. Observe in your terminal window that new log messages are generated saying that records are inserted into the database:
      07.4-Database-Records-Written

    Finally, check that the database table ELEVATOR_STATUS has indeed been filled with current data:

    1. List the pods using kubectl and then use kubectl exec to get into the container for Db2 to execute commands:
      kubectl get pods;
      kubectl exec -it <podname> bash

      06.15-Bash-Login-to-DB2-Pod
    2. The kubectl exec command will allow you to enter command line commands inside the container of the Db2 database.
    3. Change the user, enter your password (if requested) and get a list of Db2 commands:
      su - <DB2 instance name>
      db2 ?
    4. Connect to the database that was created when provisioning Db2 and list the number of tables. It should be empty:
      db2 connect to mydb2
      db2 list tables
    5. Enter the following command to take you into the command line processor of Db2 and allow you to enter SQL statements directly
      db2 - t
    6. In the terminal window for the Db2 container that you opened in the last section, submit the following SQL statement:
      select * from mydb2.elevator_status;
      07.5-Database-Table
    7. Enter the QUIT command to get out of the Db2 command line processor:
      QUIT;
    8. Enter exit to get out of the Db2 container.

    This completes the deployment of the IoT consumer, the image and the database to IBM Cloud Private.

  8. Defining a Service for the Application

    As we have seen Kubernetes Pods are mortal. They are born and when they get killed, new pods are created to take their place.  While each Pod gets its own IP address, even those IP addresses cannot be relied upon to be stable over time. While the actual Pods that compose the backend set may change, the frontend clients should not need to be aware of that or keep track of the list of backends themselves. The Kubernetes Service abstraction enables this decoupling. A Kubernetes Service is an abstraction which defines a logical set of Pods and a policy by which to access them.

    In this (optional) part of the recipe we will briefly show you have to create a Kubernetes service for the IoT consumer pods that can be used to test if the consumer application is alive and able to respond to messages. The service specification has been predefined for you in the file ‘kubernetes/iot-consumer-service.yml’. To deploy and test it do the following:

    1. Open the file ‘kubernetes/iot-consumer-service.yml’ to view the definition of the service:
      08.1-Service-Definition
    2. Invoke the following command from a command line (alternatively, create the new resource using the IBM Cloud Private user interface):
      kubectl apply -f kubernetes/iot-consumer-service.yml
    3. In the IBM Cloud Private user interface, select Workload > Services from the top left menu:
      08.3-List-of-Services
    4. Select the service named iot-consumer-svc:
      08.4-Service-Details
    5. Click the hyperlink for the NodePort:
      08.5-Service-URL
  9. Conclusion

    The recipe has demonstrated how to relocate a dockerized IoT consumer application, it’s associated Docker image and it’s database for storing IoT event data from IBM Cloud to IBM Cloud Private. The resulting architecture is that of a hybrid cloud architecture, where some components such as the IBM Watson IoT Platform are running in IBM Cloud (Public) whereas other – more data sensitive components – are running in IBM Cloud Private. To achieve this, we used the IBM Container Service, IBM Container Registry and IBM Db2 running on IBM Cloud Private.

  10. Acknowledgement

    This recipe represents joint work between Rene Meyer and Einar Karlsen.

Join The Discussion