As you maybe know we (Niklas, Harald and I) created an example project called Cloud Native Starter that contains example implementations related to Cloud Native applications with Microservices. I will use one of the example implementations in that blog post.
I structured the blog post in following sections.
The simplified solution
The example implementation in a Vue.js fronted application
This blog post is about, how to setup a self-signed SSL certificate for an encrypted (https) communication with a Cloud Foundry application on IBM Cloud, if you are at a Hackathon. Keep in mind you don’t need to implement additional code inside of your Cloud Foundry application in this scenario. All is managed by IBM Cloud and you don’t need to modify your source-code. You need to have installed OpenSSL on your local machine and this example shows the setup on MacOS and Safari. You also need a Pay-As-You-Go or Trial-Account for the IBM Cloud to setup custom domain and ssl.
A certificate from a certificate authority can be costly, if you aren’t able to use a free certificate authority like for example “Let’s encrypt” supported by your domain provider. In my case the domain provider GoDaddy doesn’t support to request certificates directly from “Let’s encrypt”.
One easy solution to avoid additional costs is to create a self-signed certificate. This solution works well, if you only want to test and develop during a Hackathon and you have a very small count of users and you can give them the guidance to use the self-signed SSL certificate in their browser. As you can see you need to upload self-signed SSL certificate in this simplified picture.
This blog post is a short cheat sheet, how easy it is to configure/setup a custom domain for a Node-RED example instance on IBM Cloud for a Cloud Foundry App. To do this you need a Pay-As-You-Go or Trial-Account for the IBM Cloud.
The image below shows my Node-REDNode.js instance in IBM Cloud and the invocation in a browser.
Kubernetes Operators are an awesome way to simplify work for developers to setup and maintain complex applications in Kubernetes or Red Hat OpenShift.
The IBM Cloud Operator provides you the ability to bind IBM Cloud services to your applications running in Kubernetes or RedHat OpenShift and create, update, and delete IBM Cloud services from within the cluster by calling Kubernetes APIs, instead of needing to use several IBM Cloud APIs in addition to configuring your app for Kubernetes.
That example shows how to bind an existing Cloudant service instance in IBM Cloud to an application running in Red Hat OpenShift. The content of the example is related to the usage of the Red Hat OpenShift with IBM Cloud Open Labs. In these labs you can use a preconfigured OpenShift environment for four hours at no charge to run workshops by your own. By the way, here you can find the related source code for the examples.
Ask your human Operator to do all the complicated ugly work for you!
… or write your own Operator, if you are the expert and you know how the complicated ugly work, works in detail. This is how you can make sure it works in the future 😉
For those of you who don’t know Kubernetes Operators in combination with Ansible, let me just give you a very simplified description from my point of view:
Even a student with minimal knowledge of Kubernetes should be able to install a highly complex container-based application on top of Kubernetes or OpenShift. Eliminate the manual interaction effort as much as possible to deploy, run, and maintain your containerized application on Kubernetes or OpenShift with your Operator implementation.