Welcome to our next section, and in this section we are going to be talking about OpenShift. What OpenShift is and why we'd want to use OpenShift and we are finally going to be deploying some applications to OpenShift. Let's start with introducing Red Hat OpenShift container platform. Right now, what I want us to think about is, I want us to conceptually think of OpenShift as a platform. It is a platform that Red Hat built. Red Hat took Kubernetes and if you've taken our previous courses, you should be quite familiar with Kubernetes. Everything that's Kubernetes does, 100 percent Openshift does as well. We took Kubernetes and we added features on top of Kubernetes. From the perspective of this course, I would like us to think at least for now, of OpenShift as a platform that simplifies the process of built and deployment of our applications for us. OpenShift is a platform that tries to get out of our way and let us, the software engineer, focus on our workflow. We work in Git and we create our comments. We create our applications. We push our code and OpenShift can automatically pick up these new comments, build our application, and automatically deploy these applications. As a developer what I want to do is I want to focus on writing the application. What I expect from Red Hat OpenShift at this point is to take care of my application, build it, and deploy it. We're going to take a look at how we can do that. Of course, there are a couple of caveats or bunch of works with Git. That's why we spent so much time on Git and Git is quite central to OpenShift from our developer/software engineering perspective. We have to use some supported languages, that not every single programming language is supported on OpenShift. For example, we have languages like Java, we have ruby, we have python, we have PHP,.NET, Node.js, and others. There are a number of very popular Cloud native languages or languages that many Cloud native engineers and developers use nowadays that are supported in OpenShift and that is excellent. But if you are using maybe some less popular language, you cannot expect OpenShift to enable you this workflow. Platform architecture wise. To be able to use OpenShift, of course we have to be able to deploy OpenShift somehow. We have to get OpenShift somewhere somehow, and there are several ways of doing that. We can use the Red Hat OpenShift Online offering, which essentially we can come to Red Hat and we say, I don't care about anything except for giving me a logging page or give me credentials and I want to use OpenShift. You make it available, you make it fast, you make it scalable. I just want to use it. This is a platform as a service offering similar to a number of other Cloud providers such as AWS and Google Cloud that can provide these offerings for Kubernetes that it provides the same offering for OpenShift. Similarly, we can use the Developer Sandbox, and as the name suggests, this is a Developer Sandbox. This is an environment used for studying purposes. For learning purposes. Most commonly for developers, and in this course, this is exactly what we're going to be using. We're going to be taking the Developer Sandbox, we're going to create an account at developers.redhat.com. We're going to provision our own Developer Sandbox, where we are going to develop and deploy our code. Last but definitely not least, of course, if you're interested, for example within your organization or company, school, etc. You can of course deploy the Red Hat OpenShift Container Platform as a standalone software on your own infrastructure. Basically, Red Hat says, "Here is the software." You get your own machines, you get your own infrastructure, you maintain the networking, you maintain the virtual machines. You get any supported configuration and you deploy the software on it and then it will work. Obviously, each of these has certain advantages and disadvantages. For now, for our purposes, the Developer Sandbox is free and it fits the needs of this course perfectly. From the perspective of an application, of course, as I said, OpenShift builds on Kubernetes, and if you have taken our previous courses, you know that Kubernetes deploys pods. A pod is the smallest deployable unit of Kubernetes and it's the same with Red Hat OpenShift. Pod is the smallest deployable unit in OpenShift. A pod runs one or more containers. A container is simply an isolated process. So we have a pod, within that pod, we have our application code. This application code requires some type of dependencies. This could be, for example, if our application is Node.js application, it probably has some Node.js packages, such as Express or some other packages, but we also have to have some Node.js runtime. We have to have the runtime that executes our JavaScript files in order to execute our codes and all of these- All of these together create one container, and a pod encapsulates one or more containers. In this course, usually one pod means one container. In OpenShift, a pod has its own IP address, a pod has its own storage, a pod is independent from any other pods. A pod is a very important concept in OpenShift. How does that work? As a developer, what do we do? Is we push our code into Git. Once we have coded our application, we can go, for example, into the web application, web UI, which is right here, and we can create our application, and In the web UI, we can select a number of parameters. We can say, create an application from this Git URL and I want this application to be managed by this deployment. This deployment will deploy a number of pods, and it is on this branch or that branch. I want this application to be available on the Internet, for example, etc. Sometimes you do not want an application to be available on the Internet, such as a database, and other times you do want the application to be available through the Internet, like the front end application. Once you do that, the web UI, for example, but not necessarily web UI, but it's one way to create an application. In the web UI, you can figure, for example, the branch name, devenv-version, and so the web UI fetches the appropriate Git repository, checks out the branch, checks out the appropriate directory, and if it finds everything that it should, and if it finds a supported language, it creates the application and in the end spawns a pod. The pod is running. When the pod is finally running, this is when you can access your application. We have a number of OpenShift resource types and OpenShift resources. For now, we can just stay with the pods. A pod is where the application is running, so that's your container, and a container is your isolated process with its own unique IP address and its own unique storage. A pod is ephemeral by default. That means that by default, unless specified differently, it is not persistent. This is a pod, very important OpenShift resource type. A route is a different resource type which associates your pod with a public URL. If you want to expose your application, you create a route and that route will associate your pod with a URL. For now I think this is just about enough for resource types, but we will definitely delve deeper into all of the resource types. If you have taken our previous courses, for example, for the kubernetes course, all of the resource types on kubernetes apply to OpenShift, a deployment manages pod, service, routes requests to pod. A route is similar to ingress. That's the basic workflow of deploying an application by using the web UI.
