In the last series of blogposts I did all kind of cool stuff with a TIBCO BusinessWorks Container Edition (BWCE) application docker image on a local Kubernetes cluster (Minikube). This blogpost we are taking things even to a higher level with OpenShift Origin, which is the community edition of Red Hat OpenShift Enterprise!
What is OpenShift?
“OpenShift Origin is an open-source distribution of Kubernetes optimized for continuous application development and multi-tenant deployment. OpenShift adds developer and operations-centric tools on top of Kubernetes to enable rapid application development, easy deployment and scaling, and long-term lifecycle maintenance for small and large teams.” (source: https://github.com/openshift/origin)
OpenShift in a nutshell is a layer (PaaS) on top of Kubernetes and Docker with additional functionality, tools and cool features like source-to-image (S2I). S2I generates a new Docker image using source code and a builder Docker image automatically. OpenShift focusses on enabling people & projects from a functional point of perspective by enabling rapid product development (easy deployment and scaling, automation, continuous delivery, self-service platform etc.).
Like we mentioned before in the intro OpenShift Origin is the open-source community edition of Red Hat OpenShift. The enterprise (on-premise or private cloud) version is called Red Hat OpenShift Enterprise (duh!) and the SaaS-solution is called Red Hat OpenShift Online.
1. Installation of OpenShift Origin (from now on OpenShift) is quite easy on a Mac with the package manager homebrew using the following command:
MacBook-Pro:~ ruben.middeljans$ brew install openshift-cli
2. After installing OpenShift we simply startup the cluster by running the following command:
MacBook-Pro:~ ruben.middeljans$ oc cluster up Starting OpenShift using openshift/origin:v3.6.0 ... -- Checking OpenShift client ... OK -- Checking Docker client ... OK -- Checking Docker version ... OK -- Checking for existing OpenShift container ... OK -- Checking for openshift/origin:v3.6.0 image ... OK -- Checking Docker daemon configuration ... FAIL Error: did not detect an --insecure-registry argument on the Docker daemon
Error! Your local docker registry needs to be configured to accept communication from the OpenShift’s Docker Registry, by default it will be listening on port 80 and be insecure (you may be required to provide a secured registry in which case I recommend following the OpenShift documentation on Accessing The Registry Directly). To allow Docker to communicate with an insecure registry we simply add the –insecure-registry option to your docker daemon service configuration, and include the port specifier.
After this we can rerun the “cluster up” command:
MacBook-Pro:~ ruben.middeljans$ oc cluster up Starting OpenShift using openshift/origin:v3.6.0 ... OpenShift server started. The server is accessible via web console at: https://127.0.0.1:8443 You are logged in as: User: developer Password: <any value> To login as administrator: oc login -u system:admin
3. Now login into OpenShift with the provided credentials:
MacBook-Pro:~ ruben.middeljans$ oc login -u system:admin Logged into "https://127.0.0.1:8443" as "system:admin" using existing credentials. You don't have any projects. You can try to create a new project, by running oc new-project <projectname>
4. At this point OpenShift notices that there are no projects defined. A project in OpenShift contains multiple objects to make up a logical application. A project allows a community of users to organize and manage their content in isolation from other communities.
So the first thing to do is create a project, this can be either done using the command-line user interface (CLI) or using the web console. In this example we will be using the CLI:
MacBook-Pro:~ ruben.middeljans$ oc new-project helloworldbwce \ > --description="This is our helloworldbwce project on OpenShift" \ > --display-name="helloworldbwce" Now using project "helloworldbwce" on server "https://127.0.0.1:8443".
5. Now that we created a project we can create an OpenShift/Kubernetes deployment object. Notice that we need to use the Docker image with “v1” and not “latest”! Otherwise, if you do not specify a version of your image, it will be assumed as “latest”, with pull image policy of “always” correspondingly, which may eventually result in “ErrImagePull” as you may not have any versions of your Docker image out there in the default docker registry (usually DockerHub) yet.
MacBook-Pro:~ ruben.middeljans$ oc run helloworldbwce-node --image=helloworldbwce:v1 --port=8080 deploymentconfig "helloworldbwce-node" created
Notice that the difference with Kubernetes here is that within Kubernetes a deployment is simply called “deployment” whether in OpenShift it is referred to as a “deploymentconfig”. The syntax here is slightly different.
6. To verify the creation of the deploymentconfig we simply run the following command:
MacBook-Pro:~ ruben.middeljans$ oc get deploymentconfig NAME REVISION DESIRED CURRENT TRIGGERED BY helloworldbwce-node 1 1 1 config
Again instead of running the Kubernetes command “kubectl get deployments” we use the slightly different OpenShift variant “oc get deploymentconfig“.
7. Run the following command to view the Kubernetes Pod that was created by the deploymentconfig:
MacBook-Pro:~ ruben.middeljans$ oc get pods NAME READY STATUS RESTARTS AGE helloworldbwce-node-1-pgf7w 1/1 Running 0 3m
The command in OpenShift to view the pods is the same as the command in Kubernetes.
8. To make the OpenShift/Kubernetes pod accessible to the internet we need to create both a service and a route. An OpenShift/Kubernetes service serves as an internal load balancer. It identifies a set of replicated pods in order to proxy the connections it receives to them. An OpenShift route makes your service publicly available by merely using a hostname.
> To create a service for exposing our deploymentconfig run the following command:
MacBook-Pro:~ ruben.middeljans$ oc expose deploymentconfig helloworldbwce-node --type=LoadBalancer service "helloworldbwce-node" exposed
> To verify the creation of the service, run the following command:
MacBook-Pro:~ ruben.middeljans$ oc get services NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE helloworldbwce-node 172.30.109.5 172.29.169.195,172.29.169.195 8080:30167/TCP 6s
> To create a route on the service we just created run the following command:
MacBook-Pro:~ ruben.middeljans$ oc expose service helloworldbwce-node route "helloworldbwce-node" exposed
> To verify the creation of the route, run the following command:
MacBook-Pro:~ ruben.middeljans$ oc get routes NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD helloworldbwce-node helloworldbwce-node-myproject.127.0.0.1.nip.io helloworldbwce-node 8080 None
9. Since we are still using the same the TIBCO helloworld application which contains a RESTful API we can fire up a browser and head to the Swagger UI (which TIBCO BW6 and BWCE generates by default for each RESTful API, still awesome!).
Notice that the OpenShift route we created provides a hostname and no port, it basically eliminates the need for using a specific port and resolved internally the hostname to the specific service and port (30167) that it exposes. The services will then make sure that port 30167 is rerouted to the port on the pod (8080).
10. And last but not least, we can bring down the OpenShift cluster by running the following command:
MacBook-Pro:~ ruben.middeljans$ oc cluster down