 Good morning guys. Sorry for the delay. There was some problem, but I have few more minutes for the demo. I am Mohit. I'm based out of India and I work at Red Hat as a senior software engineer. And my talk today is basically that how you can configure your developer environment and deploy application open shift on Azure. This talk will mostly focus on that how the deployment is done on Azure. The same thing can be replicated on any other public cloud instance like AWS, GCP, or even on your local system using Red Hat code ready containers. So I'll just move forward. Okay. So the cloud support which we provide is if you go to cloud.redhat.com and if you go inside OpenShift installs, you will find all those providers which are AWS Azure cloud and even the code ready containers. This Red Hat code ready containers is basically to run your OpenShift for instance on your local workstation. And this is currently the only way where you can run OpenShift for locally right now. So what's the advantage if we want to deploy our application on OpenShift on Azure? The thing is it is fully managed. It's a partnership between Red Hat and Microsoft and they work together to provide this interface. It empowers developers to innovate a lot. For example, as a developer, I need to test my code that how that works on Azure instance or even on AWS instance on any public cloud instance. So it empowers the developers to quickly test their application so that you can figure out that what steps needs to be done. You're not worried about going to the system administrators or any other people who are working on Ansible script or something just to see how the code works. So it is very useful for the developers. So the main question people have that who are the target audience for this? Is this just for everyone? Is it just specific to some people in the team or how is it? So the answer for this is the real king makers here are the developers. They are going to write their project. For example, I'm writing a code in Node.js or even I'm writing a code in Java or Python, whatever it is. I am the real king maker that how I want to my code to be deployed in any application. What is the type of ID I select? What is the type of command line tools I have? These all decisions are being made by the developers and eventually they are the real king makers. So if we want to support them, we have to have a fully managed support given by Red Hat to them that how you can deploy your open shift instance on various platforms. So this talk will cover mostly on that. I have a small demo based on that and I will explain you how that stuff works. So this is the entire gist of today's demo, how you can deploy OpenShift on Azure. So the thing which we get is we have a lot of productivity because you can quickly test your application directly from your ID itself. For example, if you have to deploy a Node application on OpenShift on Azure, you need various CLI tools, different IDs. You need to understand that where the code is deployed, are the builds running, are the configuration file there, is the deployment config present. What are the logs? Is anything broken? So you did not switch between different terminals, different interfaces. Everything can be done directly from your ID itself. So right now we are targeting IDs like Visual Studio Code, IntelliJ and Eclipse J. So these three IDs are supported currently. We have an extension which can run on all three instances which will have the same UI, same user experience. And you can directly deploy your code from ID itself. You can see the build configurations. You can see the deployment configs. You can follow the logs. You can show the logs. You can even debug your Node.js application directly from your instance and that application is currently deployed on Azure instance. So that interface is entirely focused to your ID. What are the advantages which we have is if right now I am running an OpenSheet instance and say I am running an OpenSheet instance 4.2 and suddenly I decide let's try test it out on OpenSheet 4.3. So few days back we released a new version of OpenSheet 4.3 and as a developer I need to test my code. Does it work on 4.3? So with this we can update our clusters directly from the console dashboard and that's just a simple two-step click and you are easy to go. The next part is how you can do the deployment of it. For example if I am deploying my Node.js application and next I want to connect to a MongoDB service. Do I need to again restart everything? The answer is no. You just need to add a service to that component, link it and everything will work seamlessly and everything from the ID right now. What about the scaling of it? For example right now I have a master and a three node cluster but I need to add more and connect them and see if will it work on a very big production environment. So that thing also can be done directly from your ID itself. So everything from your ID is being provided here. And this is a basic image that how that works. Supports any platform and whatever base image which we have selected to deploy that OpenSheet application. It's uniform and it's agnostic to any language and runtime. For example right now I am giving an example of Node.js but it will work for any Java application, any Python, any Go application. It is just language agnostic and it will work seamlessly. So this is basically the simulation which we have that if as a developer I am developing something very quickly and deploying it, what value is it giving to my company? It is enhancing the developer experience for my company. The developers who are working in that company can productively increase their workflow and see this Node application takes certain amount of time. This Java application takes certain amount of time. If we have connected those applications to a database, how much time does it take? And we can simulate that same environment, the time taken to the production environment. So that basically increase the developer workflow. So whatever changes which we make currently to the Node.js application is directly... For example I have a Git repository where it has quotes and every day my development team makes multiple comments and everything. So do I need to do all the push simultaneously? No, it will take a watch on it once the repository is connected. And as soon as there are new changes, it will continuously push to the cluster and all the time your cluster will be updated. And the same goes with the build and deployment configs. If the build is broken, there will be a new build which automatically starts. If the deployment config is broken, the deployment config automatically starts. And you can see all this directly from your ID working on your code itself. So you will not make multiple switch to the command line, go and see OCC, show logs or whatever it is. Everything from your ID itself. So the idea is develop anything, anytime and anywhere. So wherever you are, you might need this ID itself. Install that extension in your ID and just try to deploy applications wherever you want on any public cloud instance or even on your local OpenShift run. So now coming to the demo part, we have a VS Code extension for OpenShift which is known as OpenShift Connector. The same name is available on Eclipse instance and even on IntelliJ. There are preferences for developers who want to work on an IntelliJ instance or a VS Code instance. And now we have Eclipse instance which is browser based ID. The same extension will work seamlessly on all those three. And the name of the extension is OpenShift Connector. We do a three sprint cycle so every three weeks we have a new release with new features available. And it's completely open source and available on VS Code Marketplace. So right now I'm going to showcase you a demo that how this works. Let me just switch the term. Okay, so this is my, can you see the fonts or should I increase it? Sign right? Okay, so this is my basic VS Code instance. There is nothing up and running. So if you see this is the OpenShift instance connector which is present. If you go to the Marketplace and if you go here and search OpenShift. So this is the connector which is available. You just have to, when you search it, you just have to install it for my currently installed. And once you install it, this icon will be available on the left-hand side panel. You just have to go here. Okay, once you go here, you can see this is the login button which basically allows you to provide your credentials. For example, if you have OpenShift instance running somewhere, you have the API and the username and the password. Once you go to the login button, it will ask you to, do you want to log into a new cluster? You say yes. And then you have to provide this credentials. And then, for example, right now I have been logged into these all instances. So for example, if as a developer I'm trying to test on multiple instances, I need not, again, remember all of them. This extension will store all of them for you. For example, I now have to switch to some other instance. I want to do this. And I like to add a username. So I say QBadmin. And once I log into the first time, my extension will prompt me, should I save the username password somewhere in the configuration so that whenever you do a new login every time, you need not enter the password every time. So it's stored there. If you want, you can say no and manually enter the password every time. Or if you say yes, it stores that way. So she successfully logged into the cluster. And this is my cluster which is running on Azure. And these are all the projects which are listed there, right? So let's go ahead and do a small demo. I'll create a small React.js application which will basically list out what is the current weather present across the world. You can just enter your city name and we'll let you know which, what is the weather. And the React.js application has the Node.js component inside it. So I'll go here and I'll send a new project and I'll say defconns.burno. 2020. So you see a new project is created and I'll go and create a new component and a new service. So what's the difference between a component and a service? Components are basically your applications which are running and the services are basically your database which needs to be linked to that component. So it's a new component and I create an application. So there are three ways where you can create a component. One is you can directly provide your Git repository to that component and it will automatically fetch the Git repository and it will create a component out of it. The second thing is you can also provide your JAR file. For example, I am working on a Java application which has a binary file into it and I want that binary file to be used to create a component. I can use that. And the last part is whatever project is there in my workspace directory, I want that directory to be used as a component. So there are three different ways. So the demo I am going to show you how you can do it for the Git repository. So let me just get the URL for the Git repository. So this is the React application which is hosted on GitHub. I will just copy this URL. I'll go here, I'll click on Git repository and then it asks me to select a context folder. So every component will have a specific context folder for itself where it will reside and create its configuration file. And in that context folder, that configuration file can also be passed to a different VS code instance or a different developer. And he just have to copy that configuration file and all those instances will be loaded on his system. So this provides the sharing of the code or sharing of the environment. For example, as a developer, I have tested out all my scenarios and I want other team to just test it out and see if that works. So that team did not again start from scratch. He can directly use that configuration file and everything will be as it was in the previous developer's case. So I'll add context folder and I'll just create a new folder, demo, depth pump and I'll add here. And now I'll paste my Git repository which I cloned. Now it will automatically fetch what are the branches which are available to my Git repository. For example, in my Git repository, I have multiple branches and I have to test a specific branch. I need not test the master, I just need to test a specific branch. I can even specify that. But for my case, there is only one branch, so I'll just provide that. But if you have multiple branches and you have to test a specific one, it will provide you that also. So I go here. Now I have to provide the component name. So I say react weather. Now it will ask me to select the component type. So the component type basically is what is the runtime which we are using. Is it a GoLang project? Is it a Java project? Is it a Node.js project? So for our case, it is Node.js. So I'll just select this Node.js. And even what type of Node version we want to support? Do we want to use the latest one or is there a specific version of Node? We want to select, so we can use that way. I'll select 10. So you see there is a button react has been successfully created. So right now what happens is this is getting created at your VS code instance. It has not been posted as your instance. So to post that, we need to, if you see here, it is not posted. So before that, I'll just go and explore the route for this. I'll go ahead and do a route. So I'll say URL1234. And so the route is successfully created. Now after all this, I'll just go here and I'll say push. So this push basically does it start whatever configuration which we have, whatever application is there, it will start pushing this to the open shift on Azure instance. Because we are connected to that instance and it will directly post to that. It takes some amount of time based on their internet speed. But basically it allows you to see what is the current workflow, is the company initialized, what is the status of it, and waiting for the build to be finished. And this experience is consistent across IntelliJ and Eclipse J. So as a developer community, people work on, they have preferences for different IDs. And this works seamlessly on all of the three. And even if right now I'm trying to demo on OpenShift on Azure, but I have the same cluster running on AWS also and the workflow will be same. So once we have this component deployed, I'll just show. So for the demo, I have already previously created the same component here. So let's go to the dashboard. So if you see, this is the cluster ID which has been created and the provider here is Azure. And this is the version of OpenShift which we are running. Now this is the administrator view where you can see what are the events which are happening, what is the commit history and everything. Now if you go to the developer preview. So this is one of the things which we have added in OpenShift 4.x is the developer console where you can see all the perspective of the application which are running. So if you see, I had this Node.js application. What are the builds here? What are the services here? What was the route which was exposed to it? Every information is provided here. And from here also you can see what are the build configurations. And if you go here and see the deployment configs, the pods and everything specific to your cluster. And this is how your simple Node.js application is deployed on an Azure instance. And as a developer you can see is my code working on a public cloud instance or not. So we'll wait for the build to finish. So as I said, this extension is agnostic to the language which we support. This works on any languages, but currently the support mostly is for Node.js and Java. And we have added a debug feature where you can debug your Node.js application and Java application. So the debug feature is only available to these two languages. But the component creation and all other stuff are available for any language which the developer prefers. So it will take some time, I guess, for the build to finish. But meanwhile, so this is how the application will look. So if you see this is the application which the URL which was exposed to it. And this application is running on an Azure instance. And with one simple push command, everything is deployed on an Azure instance. You need not worry about it. For example, let's demo. Let's see what's the weather in Burno today. And I say this is a simple React application which has a Node.js component at the back end. That's it. So if you say get weather, okay. So the weather today is minus 2, which is pretty cold, okay. Okay, let's me see what's the weather in London. I hope it will not sunny, but still. Okay, it's fine. So this is a basic simple application. Let's see what's the weather in my country. Very good. So this is a simple application which I demoed that how you can deploy your simple application directly on an Azure instance. The same workflow will be there when you deploy your application directly on AWS instance. Okay, so if you see here, my changes have been triggered. The URL has been created. So this is the latest. This was the demo which I showed right now what previously I have created it. So now once this is created, let's go and open it and see. This will also work on the same lines. I said open and this is also the same application. So with one simple click, your application is up and running on your Azure instance. Now, as I said that you can also see all this configuration here. So if you go here and see, you can even add a storage to your class component. For example, if you are working on a very multiple cluster, you want to add storage into that. You can add storage. You can see logs of the cluster. If you say so logs, this will basically define that. What are the logs which were running for that NodeJS instance? If I need to follow the logs, I can follow those logs also. So whatever instance I could have done from my browser, whatever instance I could have done from my administrator view from say from my pods, my deployment, my deployment company, everything can be done from your ID also. I can even link multiple components. For example, I have a frontend component working in NodeJS. I have a backend component working in Java and I want to link them together. I have to create a game based out of it. So what I'll do, I have multiple components. I'll just say link component. It will figure out, ask me which component I need to link and that's it. It will link and I have to just push the component again and that's it. Your backend and your frontend will be automatically linked. The same goes with the service. If I have a Java application which has to connect to a MySQL database, the same way I just create a new service from MySQL and just link it. That's how simple it is. Even in the future, I want to unlink a component and link some other component. That can also be done. So all those actions are provided in your ID itself. You need not switch between different terminals or different interfaces just to work on your cluster. And this is the latest addition which we have. You can now debug your application directly from your ID itself. For example, you have added multiple breakpoints and you want to debug it. So right now you are debugging your application directly on the application which is hosted on Azure instance. So for a developer, it becomes easy that how that productivity will increase if you are working on OpenShift on Azure or OpenShift on AWS or wherever that OpenShift instance is hosted. So if you go to Marketplace, VS Code Marketplace, this is the name of the extension and this is the number of installs which happens. So there is also a detailed demo which is available on YouTube. If you have some time or you want to find out what exact small features are, you can just have a look at that. We are available on Gitter and if people have any queries or any questions they want to ask, they can let us know. So this was the project which I created, FConpoint 2020, and you can see the Node.js application is available here. And these are the different builds which are running. I can start my new build directly from here or even from my ID. I can even see what services are running on what port it is running. Do I need to switch the port and what routes are being exposed to the external? I think that's it for the small demo. And if you have any questions, any specific thing you want to ask me at the time. And the code is available at GitHub. GitHub slash redhat developer slash VS Code OpenShift tools. So yeah. So the question here is what are the next languages we are targeting to extend support like debug features and everything. So I would say we are targeting Golan right now. And it depends upon if there is a specific request on GitHub issue or something, but Golan will be the next one which we are targeting to support the debug feature. And the other part of this extension is it works very seamlessly with redhat code ready containers. So you just have to install the version of redhat code ready containers from OpenShift downloads and just start that version and do that login as I showed you in the start. And that's it. It will basically connect to that. So if you go here, so these are the different environments which we support. Azure, AWS, GCP and redhat code ready containers. If you go redhat code ready containers, you just have to download whatever version of, if you're working on Windows, if you're working on Mac or Linux, whatever it is, just download that. Do a start and you just need a pull secret for that because once you run that code ready containers, you have to provide a pull secret for it to connect to the redhat registry and download the images. So once you have that, you just have to copy this pull secret. And that's it. You're connected to OpenShift for instance and then start working on this view. So if, yeah. So right now they get the image from query.io and those are supported on the real images, and those mirror images will also be available on Fedora and CentOS. So those images can also be used by the people who do not want to go via redhat registry. But maybe in the future we'll have a provision where you can specifically provide a custom image and that has to be signed by some set period authority and that can be brought on. So one more small view I would like to show you is, so this is the Kubernetes view which we have. This is the cluster which I had created and if you go to the projects, and this was the project which I was working from here also, you can directly open this project in the console. So you need not remember what project name was. You can directly open that specific project directly in your console. So you need not switch between administrative view and go to that project, select the dropdown, you can directly do it from the ID itself. And if you go to the workload section and in the deployment section, if you see. So if you see, this is the deployment config and I need to see what logs are there. You can directly see the logs here itself. You can even delete this deployment config here itself and you can directly open this deployment config in the console directly from your ID itself. You will not switch between different dropdowns and everything. That deployment config will be automatically selected, the deployment config will be selected and you can see all those information. And the same goes for the build configs, the story, the configuration and everything. For example, if you have a build config and I need to start my build directly from my ID, I need not go to the console dashboard and then select that application and then start build. I can just know that, okay, this is my build config and I'll just do start build and everything will start automatically from here. For example, if I do a start build here and see a new build has been started. Now if you go to open in console, see, as soon as I did a new build, a new build has been started and up and running here. So everything is directly done from your ID. So as a developer, you do not worry about different terminologies. You need to worry about your code and where you have to deploy your code. Do you have your Azure instance up and running? Just push that code and that will be automatically deployed on Azure instance, even on your AWS or Google Cloud instance. So that is how simple it has been made for developers to push their codes directly on an OpenShift instance running on a public cloud. Okay, I think that's what I had for the demo and if we have any more questions, I'll be happy to answer them.