Welcome to our next video. In this video, what I want to do is I want to come just a little bit closer to understanding what happens when we deploy a new application to OpenShift from our source code. In a previous guided exercise, what do we did was, we had our source code and we deployed it to OpenShift. But we know that OpenShift builds on top of Kubernetes. We know that in Kubernetes, pods build or use container images. If you're not familiar with Kubernetes, I definitely recommend taking a look at one of our previous courses where we delve a little bit deeper on Kubernetes. But right now, just know that pods use container images. A container image is essentially a binary package that contains the application layer as well as everything that the application needs in order to execute. The pod takes this container image and instantiate it and executes it. There's a bit of a mismatch. We gave OpenShift source code and OpenShift created a pod that expects a container image. How is it possible? Well, there is a hint. When we were cleaning our project or namespace in the previous guided exercise, we clicked the Build View, and we were deleting BuildConfig resource. This suggests that there is some kind of a build happening. Let's take a look at what kind of a build is happening in OpenShift. When we have our source code, what we are doing is we are using this process called Source to Image or S2I for short. On one hand, we have source code, which is the input to the build process. Then there is this build process that happens. As the output, we have an image. This solves a little piece of our mystery. We input our source code. We execute this S2I build process and therefore the pod gets its own image and the constraint of the pod is satisfied. What happens with this Source to Image build process? We have solved one mystery. Pod gets its image because the container image is created in the S2I build process. What happens in the S2I build process? The S2I build process requires what we call the S2I builder image. Remember that in the previous guided exercise, what do we did was we clicked the developer catalog. We clicked the JavaScript language, and we clicked the Nodejs builder image. That's because we were selecting the Source to Image method. What do we have is essentially Git repository and we want to build it into an image. What happens is that, this builder image kicks off a build process. In the build process, the build process clones the repository. That's step number 1. It gets the source code. It downloads all of the dependencies. Let's actually take a look at our Nodejs application. In our Nodejs application, the build process takes a look at our package.json file. It determines all of the dependencies of our application from the package.json file and downloads them. In our example, in our previous guided exercise, it was just the Express package. After this is done, we have an application, then we can execute. We have the Nodejs runtime and we have the application source code with all of its dependencies. We can combine this basing Nodejs runtime with our application and we can create a container image. This build process pushes a new container image. We have our new container image. Where do we push this container image? Well, we push it to a built-in container registry. Well, where's the container registry built in? It's built in to the OpenShift platform. It's internal to OpenShift. At this point, OpenShift can say, "We have a new image," and there is a deployment or a deployment config waiting for this image and this pod can use this new image that we have just created. In a very simplified manner, this is the S2I process. We're going to delve a little bit deeper into the S2I process a little bit later. But for now, this is how we can think about the S2I process. This brings us to one of the problems or one of the challenges that we want to resolve, which is updating our application. How do we update an application that was deployed by using the S2I process? There are essentially two ways that we want to mention right now. The first one is essentially manually. What does it mean to manually update our S2I application? First of all, when we talk about updating our application, we are talking about modifying its source code. We have to, as a prerequisite to modifying the application or updating the application, we have to modify the source code and we have to push the modification into the repository. In our case, it can be GitHub, it could be a different Git repository you want. Then you as a developer, go to the web console and you manually click a button. You say, I want a new build. What happens then? Well, you kick off a new build process, and so everything that we have configured before is there. So we still have our Git URL, this remote, for example, GitHub URL. We still have configured our branch, we still have configured our context directory in the Git repository. But the new built downloads the repository again. There's a new Git clone which means it gets the latest code changes, which means it can get the latest application. Then it builds a new container image, and when we have our new container image, what happens is OpenShift is notified. In the internal registry, we get new container image, and therefore OpenShift is smart enough to know that what do we probably want, most likely what we want is to update our deployment. Then there is automatic OpenShift spawns in your pod with a new container image. If the new pod is successful in spawning, if the new container image can start running, then OpenShift automatically scales down the previous deployment, the version 1 deployment. That was the manual trigger of the build. What we can also do is utilize this webhook mechanism. This webhook mechanism is a way to call back certain code or to execute certain code when something happens. For example, GitHub implements webhooks. In GitHub, you can execute certain actions after, for example, somebody pushes new comments to your repository, and this is exactly what we want. For example, imagine that we want to redeploy our application every time somebody pushes a new comment because a new comment means that somebody changed the application. What we can do is we can leverage or utilize this webhook mechanism that GitHub implements, and we can tell GitHub after every comment event call a URL, and this URL will be OpenShift URL. On this, when we call this OpenShift URL, OpenShift will automatically rebuild our application. Let's take a look. We are updating our application code on GitHub, and this is identical. We push your code change on GitHub. Here we configure GitHub with the webhook mechanism. We have an OpenShift URL and we say to GitHub after every comment call this OpenShift REST API, call this OpenShift URL. After this, everything stays the same. After this OpenShift kicks off a new build process, and everything stays the same. The build process clones the Git repository from GitHub, builds a new container image, attempts to scale up the pod with the new container image. If it is successful, then it scales down the old pod. The only thing that has changed is who is pushing the Build button and how. In the previous scenario, I as a developer or you as a developer are pushing the button. In this scenario, GitHub is virtually pushing the button, and the button is nothing more but the URL, and GitHub is pushing the button by using a webhook trigger. But the concept is the same. The way we do it is slightly different. Depending on what you want, different applications might have different use cases and might be suitable more for different style of updating. These are our two styles of updating our S2I application. Let's take a look at how these work in our next guided exercise.
