John Senegal – Red Hat Demo: Jumpstart Your Development With GitLab and OpenShift
Taking an idea and moving it to production can involve several tools, sometimes a tool for every stage. Managing the integrations, compatibility issues, and different service level agreements can make development more complex and unpredictable. One way to improve predictability of the development environment is by deploying the Gitlab Runner operator for Red Hat® OpenShift® .
In this session, you will learn how GitLab Certified Runner Operator can be installed into OpenShift from the OpenShift Operator Hub. This gives development and SRE (Site Reliability Engineering) teams a simple deployment mechanism for the GitLab Runner as they spin up new projects, allowing you to:
– Build and not worry about tooling.
– Enable predictability in your development lifecycle.
– Accelerate the process of moving from concept to production.
Deploying GitLab and Red Hat together supports the customer’s journey to Dev/Ops and cloud native application development, while delivering the powerful CI/CD platform needed to build and run your applications.
Transcript
Hello, everyone, welcome to GitLab. Commit. I hope you're getting out of it everything that you were expecting so far.
My name is John Senegal. I'm from RedHat. I'm a solution architect.
That's part of the Global Pardoner Alliances organization. I'm here to show you a demo of GitLab and Open Shift together. But before we get started with the demo, let me talk to you a little bit about the partnership.
Well, why does GitLab and RedHat makes sense? Digital Transformation is calling for more and more workloads to become cloud native. As these workloads transform, so are the processes that are needed to develop, build and deploy them together.
GitLab and local sheriff form a perfect platform for developing and deploying these workloads. For those of you who don't know, RedHat, ownership is a hybrid cloud. Kubernetes platform.
Well, what does that mean? Simply means ownership is not just another Kubernetes distro. It is one hundred percent Kubernetes, but it's a lot more.
It contains features such as developer services. We're called Ready Workspaces, a service mesh cluster management services such as logging and monitoring. On top of all of this opens up runs across any infrastructure in enterprise enterprises using whether it is physical, virtual, public cloud or private cloud.
This gives enterprises the greatest flexibility and security as they move workloads to the cloud. You are here to GitLab commit, so it's obvious that you are aware of GitLab value. They provide a comprehensive platform that meets the needs of dev ops teams delivering solutions to the cloud.
The features that stand out the most to us at RedHat is the Optimized Kubernetes deployment. This is the one thing this one of the things that you get to see today in the demo. Well, what is it that we do together?
First of all, together we are building a bridge between traditional application development to cloud native application development. GitLab, of course, supports both traditional app development as well as dev ops. Open Shirt provides the tooling and infrastructure to not only develop cloud native apps, but also to build, deploy, execute and manage them.
For starters. What are we doing? For starters, we build a GitLab runner operator.
Well, what does that mean? We know today that there's a variety of ways to install a runner and to improve in any cluster. That's nothing new.
This operator is a new install method that allows demarks teams to deploy a runner while inside an open Shift Cluster. What's more important about this runner operating, though, is that it lays the groundwork for automated operations of the runner, such as auto updates on new releases, auto recovery, self healing, etc.. We're also in the process of building an operator that would bring the same capabilities to the labs or.
We might ask, what is an operator? For those of you who don't know, I'll give you just a little bit about an operator and operators, essentially, and automation to automate all the manual steps required for day one and day two operations for a that is application. In this case, our GED lab runner is that application.
An operator has a maturity model that spans from a simple install all the way to self-heating. During this demo, you see we get load runner operator in action. Well, now the GED lab run.
Our operator is only responsible for deployment of runners when there's potential for this operator to grow in maturity over time. Well, let me tell you about exactly what you'll see in the demo. You'll see in the demo the installation of the lab runner operator, the creation of a runner object instance, a peek into the open source code, ready workspaces, a CI/CD pipeline running in GitLab.
You'll also get to see the runner execute those pipeline jobs. And hopefully the application that I've created is a demo for. Well, let's get into the demo.
Ok, for the demo, we're start here in the open shift console, you'll see I'm an administrator of you. Open Shift also has a developer view within the administrative review. You'll see the cluster and then the administrator.
You are allowed to manage all of the resources that exist in the communities cluster. In our case, what we're interested in is installing the get lab run our operator. So we start here with the operator Hub.
The operator hub is essentially a marketplace of operators. These operators are responsible for all of the operations. Regarding the applications that we manage here.
You can select by different categories or you can filter by a particular name. We have over one hundred operators, over one hundred different partners that we're working with to build these operators. And this number just grows over time for our purposes.
We'll search on your lap and you'll see GitLab operator shows up directly in any open shift cluster deployment. And what you'll see is here's the operator page that describes the operator, what it does, where's the repository? As you'll see, the capability of an operator is described here.
In our case, the runner operator that we have here is only a basic install at this point. But as I said, there is potential to grow into all of these other phases as needed. So I'll simply go here.
I've chosen the right project and I'll install this operator. It has a several different options. We'll just take these defaults and you'll see now that our operator is getting deployed and installed and now it is installed.
So let's go on and to the next step. So now that we have one operator, if you see here, and an operator describes exactly how the operator is using what you have to do, one of the first things you have to do before you create a runner instance in the open Shift, you have to create a secret. This secret requires a token from GitLab and this token allows GitLab and the runner to communicate securely.
So what we'll do is we'll go into our GitLab instance. We'll go to settings, we'll go to CI/CD, we'll go to runners, will expand the runners and we'll basically just grab this token. So once this token is grabbed, we can go back into open Shift now and we can create a secret.
The secret we're going to create here is just a simple key value secret. The name of this secret, as you can see, already created one was runner tokens secret. The key is runner registration token open.
And I'll just paste in the value that I copied from GitLab. At this point our secret is created and now we can go back into installed operators, we can go in to GitLab and now we can go and create a runner. You see, there's no runners created at this point.
So now we'll go on and created a runner. I'll give it a name of. It led.
Limit runner, we're going to connect to our lab instant and we're going to use this as our token to communicate with good. So now let's go proceed and create a runner. So now you see GitLab commit runner.
It's initializing in a few minutes, it'll be created. All right, we see that our GitLab runner is now created. And so now we have a connection between this open Shift cluster and our GitLab instance.
All right. So now that the runners are in place, let's take a look at our project. We'll actually go through a real exercise of creating a change in our entire project.
So I have a simple project here that has a simple node GS application that displays something to the screen as a browser. So what we'll do here is you've you've seen the files here. And now I'll show you a little bit about code ready workspaces.
If you look at this and you'll notice you'll see that I've pulled in this project from GitLab being a clone of it. And so now I have my project files all here. One of the things that's part of of GitLab is this CI/CD pipeline, so as part of this process of making changes, we're going to commit a change from this idea and that change is going to be pushed into the lab repo.
And from that change that's going to initiate this pipeline to get created in this pipeline, you'll see a typical opposition pipeline that goes on development of staging and production. And in our cases, we just have three stages build package and deploy. So we'll be done with that rather quickly.
This is called Ready Workspaces. This is a development environment built into open ocean that's available to open Shift users, developers. This is a cloud based idea.
I have no reliance on anything within my own laptop or in some hardware that I have packaged into my desk. Everything that I need for the development of application is within an ownership cluster that I can manage and have access to from any browser. So let me make a quick change in here so that we can see this all in action.
So I'll say I want to change this from GitLab Commit Express to express demo. Let's now make this change. You'll see that an M comes here, which means this file has been modified.
So let's go to our source code control, which is good. And what we'll do is stage these changes. So now at this stage, the changes on stage will go on now to commit those changes in order to commit those changes.
We'll have to give it a message, we'll just say added demo. Ok, so now those changes are committed, but now we need to push this into our people. So now we'll push them into our report, which requires us to log on.
To the people, and then we'll have to enter a password. That I will copy. And paste in here.
Ok, so now we're connected to our people, you see our changes have now been pushed up to the lab server. We can go to the server and look at our file and will see that demo is now added to this file. All right.
In addition to that, now that we've committed those changes, we can now go look at our pipelines. And what you'll notice is that we have a pipeline that is running. So here we're in the prepare phase of this pipeline.
This is the job that's running and what we're doing in this prepare phase is essentially creating all of the objects that we need to execute. So you'll see that we're logging on. This is all output from the runner.
We're logging on to open shifts inside the open shift cluster and we're applying all of the elements, so we're creating a bill, config, deployment config, image, stream route and service. So all of this is happening as part of this runner job. OK, next phase is Build.
So now we're in the process of executing the build within the open shear environment. This build is going to take a second or so. Ok, our job has now completed, there are other parts of of this job and we have package also, so the package part is complete.
So we look at the output where essentially we are now pushing this new image that has been created into the registry. That's the package part of the process. And there's a deployed part of the process.
And let's take a look at that. So what's happening now is we are logging on again, changing to the right project and we're executing a rollout of our deployment configuration. So essentially from the get lab perspective.
This particular pipeline is complete. Each one of these steps were completed through the runner execution of commands with an open Shift, which means that they're all successful from an open shift, from a GitLab perspective, and everything should be. Ready in the open shift environment, so let's have a look at our objects that have been created in our dev environment, so let's see what we have here.
You can see that we have our test. We have our test. Our test pot that's running a minute ago, we have our deployment config, so let's take a look from a developer perspective, we can go into the project.
We have our application here from a previous run of our deployment config. But as you can see, our application now is now started up and available. The pod is ready.
We have our route that's been executed. So now. We should be able to go in.
And open up this application. And see the results of our achievements now, you see, you get lab express demo and the application has been updated. That completes our demo for the day.
Thank you for listening in and paying attention to what we're doing between GitLab and open Shift. I'll be around if you have any questions and look for us to be doing a lot more in terms of this partnership. Thank you.
And continue to enjoy your life and.