{"id":97254,"date":"2020-10-17T02:42:32","date_gmt":"2020-10-17T00:42:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/prosti-openshift-my-nedostatochno-czenili-tebya-i-prinimali-kak-dolzhnoe"},"modified":"2020-10-17T02:42:32","modified_gmt":"2020-10-17T00:42:32","slug":"prosti-openshift-my-nedostatochno-czenili-tebya-i-prinimali-kak-dolzhnoe","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/prosti-openshift-my-nedostatochno-czenili-tebya-i-prinimali-kak-dolzhnoe","title":{"rendered":"Sorry, OpenShift, we didn't appreciate you enough and took you for granted.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

This post was written because our employees had quite a few conversations with clients about application development on Kubernetes and the specifics of such development on OpenShift.<\/p>\n

\"Sorry,
\n
\nWe usually start with the thesis that Kubernetes is simply Kubernetes, while OpenShift is a Kubernetes platform, similar to Microsoft AKS or Amazon EKS. Each of these platforms has its own advantages tailored to specific target audiences. After this, the discussion usually shifts to comparing the strengths and weaknesses of specific platforms.
\n<\/a><\/noindex>
\nOverall, we thought about writing this post with a conclusion like, \"Listen, it doesn\u2019t really matter where you run your code, on OpenShift or on AKS, EKS, some custom Kubernetes, or any Kubernetes,\" (for brevity, let\u2019s call it KUK)<\/i> \u2014 it\u2019s really just as simple on both.<\/p>\n

Then we planned to take a simple 'Hello World' example and show what is common and what the differences are between KUK and Red Hat OpenShift Container Platform (hereafter referred to as OCP or simply OpenShift).<\/p>\n

However, as we were writing this post, we realized that we have become so accustomed to using OpenShift that we hardly recognize how it has grown and evolved into an amazing platform that has become much more than just a Kubernetes distribution. We tend to take the maturity and simplicity of OpenShift for granted, overlooking its greatness.<\/p>\n

In general, the time for active reflection has come, and now we will step-by-step compare the deployment of our 'Hello World' on KUK and OpenShift, doing so as objectively as possible (though, we may express some personal opinions on the subject). If you are interested in a purely subjective opinion on this matter, you can read it here (EN)<\/a><\/noindex>. In this post, we will stick to the facts and only the facts.<\/p>\n

Clusters<\/h3>\n

\nSo, for our 'Hello World', we need clusters. Let's immediately say 'no' to any public clouds to avoid paying for servers, registries, networks, data transfer, etc. Accordingly, we choose a simple single-node cluster on Minikube<\/a><\/noindex> (for KUK) and Code Ready Containers<\/a><\/noindex> (for the OpenShift cluster). Both of these options are really simple to install, but will require quite a lot of resources on your laptop.<\/p>\n

\"Sorry,<\/p>\n

Building on KUK<\/h3>\n

\nSo, let's get started.<\/p>\n

Step 1 - Let's build our container image<\/h4>\n

\nLet\u2019s start by deploying our 'Hello World' on minikube. For this, we will need:<\/p>\n

    \n
  1. 1. Installed Docker.<\/li>\n
  2. 2. Installed Git.<\/li>\n
  3. 3. Installed Maven (actually, this project uses the mvnw binary, so this is optional).<\/li>\n
  4. 4. The source code itself, i.e., a clone of the repository github.com\/gcolman\/quarkus-hello-world.git<\/a><\/noindex><\/li>\n<\/ol>\n

    \nFirst, we need to create a Quarkus project. Don\u2019t worry if you\u2019ve never worked with the Quarkus.io site\u2014it\u2019s easy. Just select the components you want to use in your project (RestEasy, Hibernate, Amazon SQS, Camel, etc.), and then Quarkus will automatically set up the Maven archetype and deploy everything on GitHub without any input from you. That\u2019s literally just one click of the mouse\u2014and it\u2019s done. This is why we love Quarkus.<\/p>\n

    \"Sorry,<\/p>\n

    The simplest way to build our 'Hello World' into a container image is to use the quarkus-maven extension for Docker, which will handle all the necessary work. With Quarkus, this has become really easy: you add the container-image-docker extension and can create images using Maven commands.<\/p>\n

    .\/mvnw quarkus:add-extension -Dextensions=\"container-image-docker\"\n<\/code><\/pre>\n
    \nAnd finally, we build our image using Maven. As a result, our source code turns into a ready-to-run container image that can be executed in a container runtime environment.<\/p>\n
    \"Sorry,<\/p>\n
    .\/mvnw -X clean package -Dquarkus.container-image.build=true\n<\/code><\/pre>\n
    \nAnd that\u2019s it; now you can run the container with the command docker run, mapping our service to port 8080 for access.<\/p>\n
    docker run -i --rm -p 8080:8080 gcolman\/quarkus-hello-world\n<\/code><\/pre>\n
    \"Sorry,<\/p>\n
    Once the container instance has started, you just need to check with the curl command that our service is working:<\/p>\n
    \"Sorry,<\/p>\n
    So, everything works, and it was really easy and straightforward.<\/p>\n
    Step 2 \u2013 pushing our container to the container image repository<\/h4>\n
    \nSo far, our created image is stored locally in our local container repository. If we want to use this image in our K8s environment, we need to place it in another repository. Kubernetes doesn\u2019t have such functionalities, so we will use Docker Hub. Firstly, it\u2019s free, and secondly, (almost) everyone does it.<\/p>\n
    It\u2019s also very simple; all you need is an account on Docker Hub.<\/p>\n
    So, let\u2019s log into Docker Hub and push our image there.<\/p>\n
    \"Sorry,<\/p>\n
    Step 3 \u2013 starting Kubernetes<\/h4>\n
    \nThere are many ways to build a Kubernetes configuration to run our 'Hello World', but we will use the simplest one because that\u2019s just who we are...<\/p>\n
    First, let\u2019s start the minikube cluster:<\/p>\n
    minikube start\n<\/code><\/pre>\n
    <\/p>\n
    Step 4 \u2013 Deploying our container image<\/h4>\n
    \nNow we need to transform our code and container image into Kubernetes configurations. In other words, we require a pod and deployment definition pointing to our container image on Docker Hub. One of the simplest ways to accomplish this is by running the create deployment command, specifying our image:<\/p>\n
    \"Sorry,<\/p>\n
    kubectl create deployment hello-quarkus --image=gcolman\/quarkus-hello-world:1.0.0-SNAPSHOT\n<\/code><\/pre>\n
    \nWith this command, we instructed Kubernetes to create a deployment configuration that should include the pod specification for our container image. This command will also apply this configuration to our Minikube cluster, creating a deployment that pulls our container image and launches a pod in the cluster.<\/p>\n
    Step 5 \u2013 Opening access to our service<\/h4>\n
    \nNow that we have the container image deployed, it's time to consider how to configure external access to this Restful service, which is indeed programmed in our code.<\/p>\n
    There are several ways to do this. For example, we can use the expose command to automatically create the necessary Kubernetes components, such as services and endpoints. Essentially, that\u2019s what we will do by executing the expose command for our deployment object:<\/p>\n
    kubectl expose deployment hello-quarkus --type=NodePort --port=8080\n<\/code><\/pre>\n
    \nLet's pause for a moment on the \u201c--type\u201d option of the expose command.<\/p>\n
    When we perform expose and create the components necessary for running our service, we need, among other things, to ensure that external access can connect to the hello-quarkus service, which resides within our software-defined network. The parameter type<\/b> allows us to create and connect things like load balancers to route traffic into this network.<\/p>\n
    For example, specifying --type=LoadBalancer<\/b>, we automatically initialize a load balancer in the public cloud to connect to our Kubernetes cluster. This is, of course, fantastic, but it\u2019s essential to understand that such a configuration will be tightly bound to a specific public cloud and will be more challenging to transfer between Kubernetes instances across different environments.<\/p>\n
    In our example, --type=NodePort<\/b>, meaning that the service call is made using the node's IP address and port number. This option allows not to use any public clouds but requires a number of additional steps. First, you need your own load balancer, so we will deploy an NGINX load balancer in our cluster.<\/p>\n
    Step 6 \u2013 Setting up the load balancer<\/h4>\n
    \nMinikube has a number of platform-specific features that simplify the creation of necessary components for external access, such as ingress controllers. Minikube comes with an NGINX ingress controller, and all we need to do is enable and configure it.<\/p>\n
    minikube addons enable ingress\n<\/code><\/pre>\n
    \nNow, with just one command, we can create an NGINX ingress controller that will operate within our minikube cluster:<\/p>\n
    ingress-nginx-controller-69ccf5d9d8-j5gs9 1\/1 Running 1 33m\n<\/code><\/pre>\n
    <\/p>\n
    Step 7 \u2013 Configuring ingress<\/h4>\n
    \nNow we need to configure the NGINX ingress controller to accept requests for hello-quarkus.<\/p>\n
    \"Sorry,<\/p>\n
    \"Sorry,<\/p>\n
    And finally, we need to apply this configuration.<\/p>\n
    \"Sorry,<\/p>\n
    kubectl apply -f ingress.yml\n<\/code><\/pre>\n
    \"Sorry,<\/p>\n
    Since we're doing all this on our computer, we simply add the IP address of our node to the \/etc\/hosts file to direct HTTP requests to our minikube on the NGINX load balancer.<\/p>\n
    192.168.99.100 hello-quarkus.info\n<\/code><\/pre>\n
    \nThat's it, now our minikube service is accessible from the outside through the NGINX ingress controller.<\/p>\n
    \"Sorry,<\/p>\n
    Well, that was easy, right? Or not quite?<\/h3>\n
    \"Sorry,<\/p>\n
    Running on OpenShift (Code Ready Containers)<\/h3>\n
    \nNow let's see how this is done on the Red Hat OpenShift Container Platform (OCP).<\/p>\n
    As with minikube, we choose a single-node OpenShift cluster scheme in the form of Code Ready Containers (CRC). Previously, this was called minishift and was based on the OpenShift Origin project, and now it is CRC built on Red Hat's OpenShift Container Platform.<\/p>\n
    Here we must say, 'OpenShift is wonderful!'<\/p>\n
    Initially, we thought to write that development on OpenShift is no different from development on Kubernetes. And in essence, that's true. But while writing this post, we recalled how many extra steps are required when you don't have OpenShift, and that's why it is, as we repeat, wonderful. We love when everything is easy, and the way our example deploys and runs on OpenShift compared to minikube inspired us to write this post.<\/p>\n
    Let's go through the process and see what we need to do.<\/p>\n
    So, in the minikube example, we started with Docker\u2026 Wait, we no longer need Docker to be installed on the machine.<\/p>\n
    And we don't need a local git.
    \nAnd Maven is not needed either.
    \nAnd there's no need to manually create a container image.
    \nAnd there's no need to find a container image repository.
    \nAnd there's no need to install an ingress controller.
    \nAnd configuring ingress is also unnecessary.<\/b><\/p>\n
    You got it, right? To deploy and run our application on OpenShift, none of the above is required. The process looks like this.<\/p>\n
    Step 1 \u2013 Start your OpenShift cluster<\/h4>\n
    \nWe use Code Ready Containers from Red Hat, which is essentially the same as Minikube, but with a full single-node OpenShift cluster.<\/p>\n
    crc start\n<\/code><\/pre>\n
    <\/p>\n
    Step 2 \u2013 Build and deploy the application in the OpenShift cluster<\/h4>\n
    \nThis is where the simplicity and convenience of OpenShift shine. As with all Kubernetes distributions, we have many ways to launch an application in the cluster. And, as in the case of K8s, we deliberately choose the simplest option.<\/p>\n
    OpenShift has always been built as a platform for creating and running container applications. Building containers has always been an integral part of this platform, so there are plenty of additional Kubernetes resources for related tasks.<\/p>\n
    We will use OpenShift's Source to Image (S2I) process, which has several different methods to take our source code (or binary files) and turn it into a container image that runs in the OpenShift cluster.<\/p>\n
    For this, we need two things:<\/p>\n