Now that you're familiar with SQL and how that works, in this cut, it excites, we're going to take a look at how it all works in a real OpenShift cluster. What we aren't going to do, is we are going to download the OC command line utility. If you have followed our previous courses that we're focused on upstream Kubernetes, and you are familiar with KubeCTL and in fact, you might have used KubeCTL with OpenShift. OpenShift is fully compatible with KubeCTL. However, KubeCTL does not enable you to use all of the OpenShift capabilities from the command line. What we are going to do with OC is use the new app command, which right away enables us to use SQL to build and deploy SQL application from the command line. Then we're going to go into the web console. In the web console, we're going to check the application, and we're going to trigger a new built manually. Finally, what we are going to do, is we're going to leverage the web hook concept that we explored in the lecture. We're going to configure GitHub, which implements this webhook concept. We are going to leverage the OpenShift SQL URL, such that with every new change to Github. Every time we push something to GitHub, Github is going to invoke this URL of OpenShift. This signals to OpenShift that it needs to rebuild our application. In essence, what we are going to do is automatically trigger a rebuilt of our application whenever we push a new change to our GitHub repository. What do we need to do all of that? First of all, what we need to do is, do my favorite thing, which is install the command line interface. The OC command line interface. How do we do that? Let's take a look at our OpenShift console. OpenShift console comes with this helpful toolbox or this question mark toolbox. One of the links that it provides, is the command line tools. Now, depending on what system you use, you can download the OC for Linux, for Mac, or for Windows. Download the OC for your operating system. I have already downloaded the OC for my operating system, which is Linux. The next step is to unzip the OC binary. Let's do that in the terminal. On the Linux operating system, the binary comes in the tar archive. Let me untar it. What this has done is it has created this OC binary in my current directory. I can actually ls for it. I see that I can list the OC binary and in fact, I can also execute it right away. I can specify./OC, and I can save version on the client side, and it returns some version, and therefore, I can execute the OC binary. The problem with this approach is that I can only execute it by knowing the full path. What I've done here, I have cheated a little bit. I know the full path, but what I'm using is the full path is in this current directory, which signals the first stop and forward slash. Now what do we want to do, is we want to be able to use the OC binary from anywhere on the system. For example, if I change to a different repository, different directory, I want to be able to just say, OC and right now, I cannot do that, because my system does not know where the OC is. We can do that by placing the oc binary on our path. This is another step in our installation procedure. On the macOS or Linux, we can use, for example, the /usr/local/bin. On the window system, this is a bit more complicated and that's why we have provided this documentation link. Essentially, what you need to do is either place the oc binary on a Windows system. Either place the oc binary into one of the directories that is already on your path or simply create a new directory and place that new directory onto your path environment variable. I am on the Linux system. I can simply copy the oc into usr local bin. Let's do that. At this point, I should be able to actually use oc. I can simply say oc, and I've got some result. In fact, I can delete the local version of oc that I have unpacked and I can re-execute the oc version and I will still get the result, which means that this oc is actually from our path. So if you cannot execute this command, oc version/client, there are two possibilities; either you need to reload your Visual Studio Code or you have misplaced your oc binary, for example, either is not on your path or the directory that you want to put on your path, you have not, for example, on the Windows system and so you need to put that directory on your path. Right now I have my oc binary installed. That's a great news. Can we deploy our application? Well, the problem that we have right now is that the oc binary does not know which OpenShift cluster to communicate with. In reality, you can use one oc binary to communicate with multiple clusters. For example, you could download an application to a stage cluster. You could then have a ticket to configure an application or to update an application to a production cluster. Then you might logout and login back to your stage cluster and do some work over there, etc. Right now if I tried to do anything with my oc binary, it doesn't know which cluster to communicate with, which makes sense to me. We need to authenticate with our with our OpenShift cluster. How did we do that? The easiest version, again, is to return to our web console. I can click at my username, and I can click the Copy Logging Command. This brings me to a Window where I need to re-authenticate. That's perfectly fine. After re-authenticating, I can display a token. Now, this token is sensitive, treat it as your password. It is time-bound. If it leaks, is not the worst thing in the world. But again, if somebody steals or gets to this token, they can do something to your cluster depending on the privileges of the user, so treat it with respect, treat it as you would treat your password. Do not put this token in your GitHub, for example, or anywhere else that is visible to other people. We can display this token and we can copy the login command. After I copy the login command, I can paste it in my terminal. Because oc is on my path, I can simply execute oc login. There we go. If I scroll, basically, the OC has provided me with some feedback, and I have logged in to the sandbox environment because I'm using the sandbox environment, and as I'm using a certain user, and this user has two projects available to the user. One project is myUser-dev, the other project is myUser-stage. That is excellent. We have our command line utility ready, installed, authenticated, so let's take a look at what do we need to do next. At this point what do we want to do is we want to create a new branch, and this new branch is called update-app. Let's create our new branch, and this branch is for our hello-nodejs, so what we want to do is change to our DO101x. Let's create our branch. From main, create new branch, update-app, and there we go, we are on our update-app branch, and we can push the branch. There we go, this branch is now in our remote repository. This branch because we have pushed it, it is now in our fork in GitHub. That's excellent. Now, what we want to do is we want to deploy a new application. The application is going to be named version, that's just a name of the application that we are going to be using. We are going to be using our fork, so we are going to be using our fork GitHub repository, we are going to be using the DO101x-app , or DO101x-apps, then there is the pound symbol, then there is the update-app, so this is the branch that we have just created, this is how you signal the branch name in the command line, and then we specify the context directory. The context directory is a version which is the name of the directory which we want to build. Finally, we are invoking OC and we are building a new application. This is a lot of information. Maybe if you've never used command line interface, this might seem like a lot, but it's actually quite simple, so let's break it down. Let's start with very simple thing that we know, we are starting with OC. When we are using OC, what do we want to do with OC? We want to create new application. At this point we should know that the command to build a new application is the new-app. We have our OC new-app, then, what do we want to do? We want to name it. How do we name our application? Well, there is a help for flag or option rather, --name. We can use --name, and the name for our application is going to be version. Then, we will set the GitHub URL, so let's check our GitHub URL. The GitHub URL should be the HTTPS GitHub URL, so this is the URL to your fork. That's all well and good. Let's delete the.git, which is not necessary, and then we have to specify the branch name, so this is the #update-app. We have our OC, we are creating new-app, the name is version, we have our URL, and finally, we want to build the application in the context directory called version. Let's use the option context-dir and the context directory is version. What it will do? It will build this application. There is some at the JS and there is some package to JSON, so this is a Node.js application. It seems like a very simple application, basically that simply has one endpoint which returns some text. We have our OC new app command. Let's execute it. This OC utility has returned a lot of texts. Especially in the beginning, a lot of users tend to skip a lot of texts, especially when there is a lot of text at once. But this is actually very important and I would definitely advise that when you see a lot of text, the first thing that you might find helpful is to see what it actually says, rather than then going away from it. Though the impulse might be of some people to turn away from it. It might be useful to see what it actually says. We see that we found some image in an image stream. The image is called OpenShift Node.js. This seems really good. Because we know that our application is based on Node.js, so It seems like our OpenShift S2Y image, or S2Y build Image, found the Node.js builder image for our application. We see that we have our Node.js match. We see that we have our Source Control URL. We see that the resulting image will be pushed to an image stream with the tag version latest. We can also use OC start build to trigger a new build, so that's great. We are creating some resources, which is the image stream build config, deployment, and service. Note that there is no route and so this application will not be accessible from the Internet. This has been a lot of text from one simple command. It seems like we have done a lot by one simple command. Let's take a look in our web console and in the web console, I see the version application. In the version application, I see that there's actually a build running. After a while, the build has finished successfully and we have our part that is running successfully. What do we do now? Well, the problem was that we have no route, and so we cannot test our application. Previously when we created the application via the web interface, we could select whether we want to expose the application or not. That's several ways how we could expose the application. One of the way, even at this point, would be to go to the administrator perspective, select the networking routes and we could create a route here. That's one way. Let me switch back to the developer perspective. A much easier way that doesn't require the knowledge of the annual files or any of underlying details of the application, is to move back to the command line interface and use OC again. We know that basically the OC new app application or command rather created a deployment. How do we know that? We know that from the text that we have read. [NOISE] I have the deployment. On top of that, we also know that the OC new app application created a service. [NOISE] You can verify this actually in the web console as well. The service connects to the deployment. However, there's no route. There is no route. What we can do is we can use a different command that comes with OC, which is expose. This is the same command that comes with Cube CTL. However, in OC, we can expose services and when we expose services, this creates routes. OC expose service and the service name is version. This will create a new route. I can clear all of this. Now if I go back to my topology view, I see that I have my open URL button which just appeared. I have my route. If I select my route, I see that this is the version 1 of the application. This is all well and good. Let's take a look at our text. One thing that I didn't want to stop at, is that this OC new app command is quite long. I mentioned in the beginning that when we have very long commands, we break the commands with the backslash character. This backslash character is used on Unix systems. On the Windows system, use the backticks character. Alternatively, just like I did, do not break the long commands, it depends on your preference. I just wanted to point it out. If you have Windows, if you use Windows, this of this character will not work on your Windows PowerShell. We have tested our application. It seems to be working. We have exposed our service. The service is named version, and that's why the OC expose worked. We are using OC binary with the OC binary, we are using the expose command. What are we exposing? We are exposing a service. What is name of the service that we are exposing? The name of the service that we are exposing is version. That's why the whole command is OC expose Service version or OC expose Service/version, and the two are equivalent. Then we can open the URL and we see Version 1 of the application. Then we can simply change the text. We can change it from version 1 to version 2. I have changed it. After this, we have to push this change into our remote repository. Remember that what we are doing is we are pushing this to the Update app branch. Let's switch to our source control view. We have one change. The change is in the version directory because that's what we are building. There is one change. There is a modified file called app.js. Let's stage the change. Do we have any coming message update app version tool? Let's use that. We can commit this message or we can commit this comment, we can commit this stage changes. We can push the new commit. At this point, we have modified the application. However, the application in our OpenShift cluster still uses the version 1. In fact, when I take a look at the topology, there is still only one part running. There's still one build. There is no other build in the topology view that I can see. What we can do is we can simply trigger a new build. We can trigger a build in multiple ways. One way is to simply start a new build from here. Another way is to click the build here. We are in the developer view. We click "Build". Then we have our version build and we can start a build. The two are equivalent. We can start a new build. This brings us to our version 2 build. We can return to our topology view and click our version application. We see that there is a Build number 2 that has just started. Let's wait until Build number 2 has completed. Build number 2 was completed. We have our new pod which is running. Let's take a look at our previous route. We see that this is version 2 is now showing. We have successfully updated our application. This is really good. We are capable of deploying our application to OpenShift from GitHub, from our source code by using the command-line interface, which is incredibly powerful, and we are capable of manually updating it. Now, what we can do is set up a GitHub trigger. What we can do is set up the webhook trigger for GitHub. Let's navigate to our DO101x-apps repository. In the repository, let's click "Settings", "Webhooks", and let's add a new webhook. At this point, what we are configuring is basically which URL will GitHub call every time there is some event. What we are configuring is which event shall GitHub react to and what URL will GitHub invoke. What we need to do is we need to get a URL of the OpenShift cluster that we want to invoke. This is not only URL of the OpenShift cluster, this is the URL of the specific Build configuration that we want to rebuild. It makes sense to return to the web console and take a look at the Builds menu. We select our version BuildConfig and over here, when I scroll down, I see that we have two webhooks at the bottom of the screen. Let me make it a bit bigger. We have a specifically GitHub webhook and a generic webhook. These webhook URL are obfuscated, so the secret here is obfuscated. But what I can do is I can copy the URL with secret. I've done that and let me return to the GitHub interface. At this point, what I can do is I can set the content type, and the content type should be the application JSON, and the payload URL is the URL that we have just copied. That's great, and I can add the webhook. After I add it, let's refresh the page and it seems that the webhook trigger, the initial trigger has been successful. It seems like the webhook has been configured successfully and after every push, GitHub is going to invoke the URL and the URL will lead to the version Build configuration, which means that it will trigger a build for the version application. Let's test that. Let's change the version 2 to version 3. This is our app.js in the version directory. This means we have some changes, so let's stage them. Let's create a new comment. Let's update the application to version 3. We created a new comment and we push the new comment. We've pushed the new comment. Let's take a look at our Builds. Suddenly I see version_3. Now, I did not trigger this Build manually, but GitHub triggered this build for me. When I take a look at the Webhook that I have just created, I see two recent deliveries. One of them was the initial delivery that GitHub tested whether the Webhook is correct and another of these deliveries has been my push to the repository. Let's take a look at the topology. I see that my Build 3 has been completed. Let's take a look at my URL. There we go. We have rebuilt our application and now any changes that I make to the application will automatically trigger a rebuild of the application and automatically propagate to the OpenShift cluster and I can test them in the OpenShift cluster. This is an incredibly powerful technique. It comes with pros and cons depending on your workflow. In some situations, for example, in a production environment, unless you have a really robust testing suite, you probably don't want to automatically rebuild your applications in production environment. However, in some staging or development environment, with every change and push that you make, you might want to see the changes in production or in production like environment as soon as possible. Imagine that you have development environment and you want to get feedback as soon as possible so that you are confident that your changes work before you can deploy them to production environment. That is all for our guided exercise. Now, let's clean up. What do we do to clean up? Well, first of all, let's delete the Webhook. In our Webhooks, in our GitHub repository, I can simply delete the Webhook that I have just created and after that, this means that every change that I make to the repository will not trigger the build-config. This is one piece of our cleanup. Then basically what we want to do is we want to delete all of the objects that we have created by the oc new-app command. Previously, what we have done is we have gone through the user interface or through the web console and we have deleted these one-by-one. Well, now we don't have to do that because we have our command line interface. This is exactly what I love about command line interface. You notice that one thing that the oc new-app command does is it tags all of the objects with a label and the label is called app equals something, app equals name. In our case, the name of the application was version. We can get all of the objects that we have created by using oc get all. oc returns to me everything that the oc new-app has created. We would have to manually delete the service, the deployment, the build-config, a number of build, the image stream, and a route. What we can do now that we have the command line interface is instead of get, we can issue the delete command. Obviously, delete all. There we go. Our project is clean and we are ready to take a look at our next lesson and next guided exercise. I'll see you in the next lesson.
