Red Hat OpenShift Pipelines | OpenShift, 8 Jun 2022

Previous Meeting

⏯

youtube image

►

From YouTube: The Level Up Hour (E65) | DevSecOps with OpenShift Platform Plus

Description

This episode will introduce OpenShift Platform Plus that provides container security (RHACS), multi-cluster management (RHACM), enterprise container Registry (Quay) and show how the combined value helps embracing a multi-cluster DevSecOps approach.

Want to learn more?
https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus?sc_cid=7013a000002qG1GAAU

Try Red Hat OpenShift: https://red.ht/3uYcuhU

Follow us:
Randy Russell https://red.ht/rrr-linkedin
Jaafar Chraibi https://twitter.com/ChraibiJc
OpenShift https://twitter.com/openshift

Subscribe to Red Hat's YouTube channel: https://www.youtube.com/redhat/?sub_confirmation=1

What is the Level Up Hour?
Every other Wednesday at 9am ET we stream live demos on how Red Hat Enterprise Linux (RHEL) users and admins can benefit their organizations and improve their careers by learning how to use containers, Kubernetes, and Red Hat OpenShift.
Learn more at https://red.ht/leveluphour
Level Up Hour on GitHub https://github.com/level-up-hour/

About OpenShift:
Red Hat OpenShift is an open source container application platform based on the Kubernetes container orchestrator for enterprise application development and deployment.
OpenShift on redhat.com https://red.ht/3uXIbaQ
OpenShift on github https://github.com/openshift/

#RedHat #OpenShift #RHEL #tluh

00:00 Intro
00:57 Welcome + Today’s topic
03:32 What is OpenShift PlatformPlus?
08:56 [DEMO] Multi-cluster devsecops pipeline with ACS, ACM, Quay, GitOps and Tekton
18:03 Questions
25:52 How Advanced Cluster Security integrates w/ OpenShift Platform Plus
40:25 Recap
51:55 Outro

A

A

Let's get into the big topic of open source, something that we.

B

Actually have an open culture.

A

What is that process that a developer or, let's say.

B

Has the kubernetes.

A

And good morning, good evening, good afternoon, wherever you might be and welcome to the level hour, where level up hour, where we talk about all things, containers, kubernetes and, of course, openshift so make sure to like subscribe and share so that everybody knows that we're out here. Talking about these topics.

B

And we have a really great topic.

A

Today, uh today we are going to be talking about openshift platform plus now uh you know, openshift, obviously, is a very important part of what we talk about and so we're going to delve into a little bit about uh about what brings the plus in there and uh to tell us a little bit more about that is my co-host uh jafar travie good afternoon jafar.

B

Yeah, hello, everyone and uh hi renji uh thanks for joining us for yet another episode, uh and yesterday uh our show would be on a little bit more than just openshift, so um uh you've probably heard about uh devsecops- and uh you know this approach where you can combine not only dev devops uh things, automation, but also try to instill uh security all the way uh within your practices.

B

So that's what we are going to have a look at today, so uh I will first introduce the openchief platform plus and then we will have a look at a quick demonstration that shows how all the beats work together.

B

So it's not necessarily an end-to-end demonstration, but really we'll focus on explaining how things are created, how things are integrated together and you know basically give you all the information you need to get started. If you are looking to use this wonderful set of tools.

A

Great well, you know it's interesting thinking about the evolution of open shift where uh we now have single node openshift, with which you can call openshift platform minus openshift. And then you have object platform plus, which brings some things that you know it's not just about devsecops, but it's a great way to illustrate it, but really bring some things that if you are going big, you know big with openshift. I think that's that's sort of the thing that I associate with it.

A

The plus puts the big in there so take it away, jafar and and tell us a little bit about what the components are and what you know kind of what makes what puts the plus in openshift platform plus.

B

Sure so, as you know, uh red hat has been in the kubernetes landscape for since the beginning, and since then, we've seen, um I would say, the ecosystem evolve and our customers started by adopting small clusters, then bigger clusters, then more clusters, and then we we started to see that multi-cluster pattern where customers wanted to have maybe small form clusters dedicated to specific areas or specific teams or domains or geographies, etc.

B

We also so a need for a more reliable, highly available uh registry that will play a key role within that multi-cluster strategy, because if you are having tens or or hundreds of clusters- and they are spread around the different geographies, uh it doesn't really make sense to rely on just one single copy of the registry, as uh you used to when you had only one cluster that you were.

B

You had to worry about, so uh red hat has made several acquisitions throughout the years uh and also, I would say, inherited some very cool uh tools from the uh I would say, the ibm, acquisition and merging of some parts of the engineering and so openshift plus basically extends the openshift platform with uh with the four new capabilities. The first one is multi-cluster management, with what we call red hat acm.

B

The second one is with security for containers with the red hat advanced cluster securities or what we call acs.

B

The third one is red hat play, so that brings them geogra geographically, replicated highly available uh container registry that also integrates security scanning and finally, and that's a integration that was done. I think so a few months ago. It also gives you openshift data foundation, essentials, which is basically uh our openshift storage but limited in terms of usage and size. But it's a, I would say, a very good foundation to start your your openshift plus journey. So again, what those uh tools bring together is uh uh this ability to uh to embrace a multi-cluster?

B

I would say devsecops approach, because you're really able to build your applications, um store them in a secure registry that is accessible everywhere with the high availability, then make sure that the containers are continuously or the images are continuously scanned for security vulnerabilities.

B

uh It allows you also to have a single pane of glass with the decentralized view that both acm and acs bring. So when you are managing, uh maybe hundreds of applications across tens of clusters, or even thousands of uh so we have some some customers yeah, we have customers who actually run tens of thousands of containers a day on their different openshift clusters, and you know at some point in time you you really cannot uh go and try to log on on each and every cluster.

B

You really need something that gives you a centralized dashboard and that's what acm and acs do from two different perspectives. The acm would focus on what clusters we have.

B

Are there any updates any policy violations, any governance, issues etc and acs will bring the centralized security view. Do we have any uh network? Do we have any threats? Do we have any unsecured uh or images that have vulnerabilities that are being run on on those clusters, etc? And odf brings that you.

A

B

Highly uh trustable storage back-end for all of those components, all right. So with that being said, um I wanted to really focus on um showing you what this looks like within uh the tooling. um So we're gonna have a look at different uh solutions.

B

We're gonna talk about how to install them and we're gonna talk about what capabilities they offer and also how they fit together, because it's not just a bundle where you you buy things at a better price. It's really an integrated solution set that when they are all combined br, they bring uh value together uh thanks to the integration that have been created by the the red hat engineering, all right. So, um let's uh dive into the uh the details.

B

So, uh as uh we said in the introduction, uh openshift platform plus is of course uh intended for multiple use cases. It's not just devsecops, but when you think about devsecops, there are many capabilities that you need that are fulfilled by those uh combined set of tools, and that's the use case that I wanted to show uh for this uh for this session.

B

So um what we're going to look at is basically a a cicd pipeline that takes our application code from a git repository.

B

Does some application scanning then use some third-party solutions to check if there are some vulnerability issues in terms of code etc? Then we will build the application into a container image that would get pushed to uh quay, so quay is installed on openshift. We are not using kudos io in in this case, we are really using a containerized quay instance that runs on openshift itself.

B

Then afterwards, once everything is finished, we want to have some security gates that are maintained by acs, where once the image is in the registry, we want to make sure that there are no blocking or critical vulnerabilities.

B

If everything is fine, then we can move on and deploy the application to multiple clusters. So what we're going to be using for today's demo is so. I have two clusters, one where all the tools run, and I consider it, I would say- also the dev environment, where basically, my building of the application happens, but there's a second cluster which is staging or production, calling whatever you want, but just you know, we can't think uh of it as one or 100 clusters.

B

It doesn't really matter because the tools that we provide bring that scaling capability where we are going to build things in one cluster and propagate those applications to the hundreds of clusters that are under management, and I will explain how the whole tool chain uh allows us to do that. So, first, let's start by looking at what we call the operator hub or the installed operators, and what we will see here is that we have several operators that are already installed in here, so um the the ones that we need. We have red hat quay.

B

We have acs, we have or also acm so acs being the security solution, uh acm being the cluster management, uh openshift pipelines being the git ups tool that we will use to deploy the applications to remote clusters.

B

We have also openshift pipelines, which is our distribution um of the tekton upstream project. So it's and I'll.

A

Interrupt for a moment to say that we did have a very good uh episode talking about uh uh openshift pipelines in which jafar walked us through that particular technology. Please continue yeah.

B

Sure so uh yeah, so what techton brings uh just as a summary, because I'm sure that not everybody is familiar with all of the tooling that we provide, but this this one allows us to use kubernetes as the ci cd engine itself and that's basically the pipeline that we were looking at before.

B

So uh what we have here again, we have the red hat quay registry, which is installed, but we do provide a very nice way of integrating openshift with a remote quay instance by making sure that whenever you build your containers on that cluster, that has the integration. It will automatically push all the images to the query registry. So, let's, let's uh post for a second and think about it differently. So if you are using openshift with the native image with the native container registry, there are a lot of integrations and automated tasks that happen.

B

So you have all the role based access that happens automatically. You have all the namespace management. That is also happening nature because it's all running within the same cluster. But when you, when you have a separate query instance, you you need to basically synchronize the content of your openshift namespaces, your users, your roles, etc uh with that remote registry and that could have been a bit tedious because you would have to set up like your hundreds of namespaces uh and such and thanks to uh the red hat quay bridge operator.

B

And it does what it says.

A

So it's basically a bridge between.

B

Your openshift cluster and your remote quay instance there's what we call a query integration and basically, when, when you install the operator and create that point integration, you say that whenever you push new container images uh to any namespace within the openshift cluster, it's going to be it's not going to be pushed to the local registry, but instead it's going to be pushed to that way. Registry that you have here, and um so let's have a look at that query registry uh that we have so that we have running on the cluster itself.

B

So, as you can see, uh the first thing we can notice is that there are uh a lots of organizations that are actually mimicking what we have within openshift itself. So if I, if I look at you, know organization, I have the openshift cicd namespace. I have the openshift crda organization and basically this is because the equate bridge operator constantly monitors the namespaces that we have within openshift and automatically creates those in kuwait as organizations.

B

So you have them the ability to push and pull your content from openshift to quay and from quay to deploy those to uh openshift namespaces. So if we look at any of those organizations, quay will also automatically set up some default. Robot accounts and robot accounts are actually you know, users that are um created to uh to to basically allow you to push and pull from the registry.

B

uh Traditionally, when you use openshift itself, there are some default service accounts that are used for those operations, and let me show you an example on, for example, the cicd namespace.

B

So if we go to this user management service accounts, we traditionally have those um default service accounts that are created by openshift, which are the deployer, which are the default which is used for anything unless specified differently. We have the builder, which is in charge of building the container images and pushing them to the registries, and then we have the deployer, who has read access to the registry, to be able to pull the container images and deploy them on the namespaces.

B

And the interesting thing is that if we look at those basically they have automatically inherited from those secrets that have been created by openshift.

B

So now these service accounts that we have on the openshift namespaces are automatically allowed to push and pull from the corresponding namespaces in quay, and you don't have to do anything manually on your own. It's fully automated there's an operator there's a controller that looks for any changes and if you make changes create use, but new namespaces is going to reflect that in queer as well. So I believe there are some questions, so, yes, we can pause for a second and take those.

A

Yeah, so, uh first of all we have one: that's. Can you share the pipeline task, ammo.

B

Yeah sure so um this um content is going to be available is actually available on the github repo, so I will say: send you the links to the repo, so I can have a look at it.

A

All right and then we had a question that uh uh you know, there's been news that stack rocks has been open source, and so in that case, how is acs different from stack rocks.

B

Well so uh scs again with, uh as with any of the uh red hat tools, there are some, so the first thing is of course uh supportability. So uh the the first one is called a community project.

B

The latter one is a product distributed by red hat and it's, I would say exactly the same thing for all of the the red hat tools. um There can be some differences in the functionalities that are provided in in some some tools.

B

I'm not necessarily familiar with the acs drifts between the acs and the upstream project, but.

A

B

Usually you have one, I would say some. You can have some differences, uh especially if it's not a red hat upstream project, if it's a red hat stream project, usually it's very close to what we have, except that you don't get the qa the certification and support and all of those things.

B

But if it's an upstream project, it's a bit different. So, for instance, if we take tekton tekton is not a project just by red hat. We are contribut contributor to that and as such we do use tecton, as I would say, a core engine with openshift pipelines.

B

But we extend that with some capabilities that don't exist upstream, such as the ability, for instance, to look at the pipelines and maybe even go and edit those pipelines with a graphical editor that we provide in here, etc. So very nice capabilities that don't exist in the community projects when it's not a red hat solution right and.

A

Then we have one more one more and then we can. uh We can get back to to our walk through this, and that is uh aaron was asking. Is there a standard not like that's standard, a standard way to handle semver in a pipeline? How do you inform the pipeline test? What the version number should be when the image is tagged.

B

Yeah, so I I don't think, there's a standardized way of sorry yeah standard, there's no standard way of doing that, but you should definitely have a standardized way of doing that within your organization, so uh things can be a combination of so, for instance, if you are you tagging your container images with application versions and such things, then you could use those uh to tag your your you know your pipelines, your images and make sure that there's a standard. I don't know how referring to say normal clutter, meaning that it's a.

B

Standardized way of naming yeah, it's a naming convention or a naming standard within the organization. So you know that you need to pull whatever application.

B

So you can have, for example, three letters that identify your application. Then you have the version of the application. Then you have whatever other meaningful things, but in the end, what matters is that we are going to use several tags to be able to push and pull the images. But at some point we are also going to have to resolve the pull spec or the sha of the container images when we are going to use argo cd, for instance, to tell it which container image it needs to use when doing the deployment.

B

There are some um standards um in in being built um when it comes to building things like software built material. That allows you to understand what components you have in your application and that you could ship as a version package, for instance. So there are things that you can rely on, but there's no like one go-to way of doing that.

B

But yeah to your point, you definitely need to have a standardized way of uh putting those things together, because in the end you you'd want to automate that and if you want to automate that you need to be able to say. Okay, so I need to pull this information and this information combine them, and that makes my full uh string that I need, for example, to pull my my images, etc, all right so um yeah. So let's go back to our uh to our set of tools.

B

So um so the first thing that we did within the the pipeline again is that we have cloned a repo here. We we used a tool called crda code, ready analytics which allows you to scan application source code for vulnerabilities, uh and then we are doing some third-party tools, like uh maven uh code analysis using solar cube, for instance. So this is just a demo, but basically your pipeline should have those type of you know: integration, functional tests before uh you know deploying your application or you know releasing.

B

uh I would say your code analysis, then releasing applications then doing some security gates, then doing some functional tests, etc. So, um okay, let's go ahead and see what happens so here with the build image we do have um the.

B

I would say the source to image process that builds the application from nexus that we have here and creates a containerized image out of it, and if we go back to the uh quay registry, that's the one that we see here so that whole pipeline takes about 20 minutes to run. So I didn't want to run it in here.

B

So I have a previous version that has been kicked off and you can see that this is the image that has been uh stored within the openshift within the query registry and that we will later on reference to deploy that container image. So what's important here is that this is the manifest that we are going to use to reference this image when we are going into the git ups approach.

B

Okay, so um enough with the quay and open shift integration, let's go a bit further and go to the red hat acs integration, so acs, as you can see here, is a security management tool for uh for openshift, and it can help handle multiple clusters. It can show you vulnerability management for your uh containerized image images. It can show you uh if you have some container images that are running somewhere on your clusters.

B

It can show you the most vulnerable cves.

B

uh It can also show you if there are some policy violations across the board, etc, and so um so this is the one that we have the the the spring bed technique and when using acs uh with policies, you have uh basically two options. You have an option to say that you want this policy to be just a.

B

You know, a an information and it's going to to pop up an event and show you warnings, etc, or you want you can set it to be a blocker policy, meaning that it's going to fail uh whatever uh task or pipeline you have in there.

B

So um since I wanted the pipeline to go through, I disabled the the blocking part of it, but if, if I enable that, then the application won't be able to proceed into the different environments unless I make the changes and make sure that there are no violations in there, so the way it works is within openshift.

B

We have a few yaml tasks, so take some tasks that are embedding the the roc ctl command line, which is the acs command line that allows you to basically scan images remotely and check if there are any violations regarding that and also using cube linter, it can also check the deployment files, for instance, making sure that you are not deploying application with applications with elevated accounts and elevated security context and such things so yeah. These are the security gates that we are using in here with acs.

B

um Okay. So now let's uh go a bit uh forward, so I don't know how much time we have left but.

A

B

Yeah so acs, basically, as I mentioned, uh has this nice integration with uh with quay as well. So we can have a look at it and uh if we look at the integrations part, we can see here that there's uh a clay integration here that allows us to connect to a uh remote registry and that's basically, when you create that integration, you can point to a questions and have acs automatically scan the content of that registry.

B

So yeah. Basically you can say I want to create a new integration. Here's the endpoint, here's my admin uh user, password that I need to be able to do things on that registry. There's another one as well, which is, I would say for quail, I o, but you can also use it for quay. So this is where I have configured mine and if you use this integration, you can specify what type of integration you want to use. Do you want to scan the the do?

B

You want to use the acs scanner to scan the content of that registry, or do you want to to use the registry scanner itself if it has uh scanning capabilities so uh yeah? Basically, here you have to provide an oauth token that is generated by quay, and then the integration uh allows you to from acs directly scan the content of the query registry.

A

B

Yeah, that's about uh the, I would say the acs integration that I wanted to to uh to show you. So uh just one final thing in terms of integrations, because that's also the thing we want to talk about is uh because we are using the cli to interact with acs to get the results from acs.

B

You need to generate an api token that get passed to the task that is running in the pipeline and that's basically how the command line works. You give it the token and point it to the acs registry uh just to the acs endpoint and the image that you want to scan, and then it gives you back the results.

B

So uh all right. So now that we have spoken about the uh acs tukway integration, uh let's have a look at and the pipeline to acs integration using the command line and the the token let's go back and see what happens uh afterwards within the pipeline. So yeah we see we have scanned the image. Everything is fine. Now there's something that says: update deployment and basically what it does is.

B

If we look at this task, it's going to make some changes to the git ups repository for for the application to change the uh manifest of the container that we want to deploy. So, let's pause for a second, and let me show you what we have in terms of get ups to understand a bit more. What's going on. So if I log into argo cd- and this is an argo cd instance that is deployed using the openshift, get ups operator on openshift itself- I can see two things.

B

I can see that I have two applications defined in here in angle cd and if I go back to the clusters, I can see that I have two clusters that are registered this one being the ink cluster, because whenever you install openshift gear ups, it automatically introspects the cluster on which it runs and re-just registers it as a target cluster.

B

But because we are in a multi cluster configuration here. um We want to be able to target the other clusters as well from argo cd, and this is not something that you would get out of the box with openshift uh or with argo cd in openfifth, because it's tied to the cluster that it knows only or you would have to manually add those clusters.

B

And if you have tens or hundreds of clusters it can become, I would say, a bit more complicated to manage those uh clusters. So here's where the the red hat engineering came with came up with a very clever integration, where we are using acm, which is the multi-cluster management tool to basically register all of those clusters that are under management in acm within argo cd. And let me show you real quick how this happens.

B

So if so, we are now in the red hat acm ui, and we can see that we have several clusters, the one, the the one on which acm runs and a remote one that has been added to uh under management to our cluster and the very cool uh feature that I like with uh acm.

B

Is this notion of cluster sets where, basically, you can define those cluster sets? Cluster sets and tag them with this openshift getups annotation and basically any cluster that falls under that cluster set would automatically be added to uh the argo cd instance that runs on openshift. So it's a very clever way of instead of having to manually synchronize your clusters whenever you create them, etc, they can automatically be tagged in those cluster sets and acm will automatically configure ago cd to register them as target clusters, and that's basically what we get in here.

B

So that's very nice, because now, if I'm managing hundreds of clusters in acm, I know that I can automatically use those as targets within the argo cd instance to do my.

A

Githubs deployments.

B

From from openshift, so that's I would say, very cool integration between acm and open shift, get ups, slash, angle, cd, okay,.

A

So, now that we have that.

B

um Let's go back to our uh namespace uh open shift, get up namespace.

B

From our cluster and what we have here is this notion of application set.

A

B

And so because we have that native integration between openshift and argo cd, so all you have to do is create an application definition on your openshift namespace and it will automatically put that definition into argo cd. So you can have uh you know this uh fully yaml based configurations of your uh openshift angle, cd instances and that's the two instances that you see here back to argo. So I have the dev application and the staging application.

B

Let's have a look at the dev application definition here and what it says is I'm basically targeting this cluster, which is the local one in the devsecops dev namespace.

B

There's a spring pet clinic project for that and, most importantly, there's a git url for the resources that we want to deploy and that points to a local gox instance that we have here. So it says that we are using um a customized approach where basically, we are deploying the content of environments, slash dev, so let's have a look at that and see what's in there.

B

So when we are using a get ups approach, uh usually you don't pull. uh You don't put the application.

B

Resources files within the application code: it's usually two separate repositories, one for the application source code itself and one for the uh gear ups resources that you need to deploy with things such as the the deployments, the routes, the users etc. So if we look.

A

B

Here we can see that we have this environments folder where we have a dev and staging, and if we look at the dev, that's basically the one that has been updated by the pipeline two hours ago. And if we look at the difference uh in here, it's basically that the pipeline automatically updated the uh environment file to point to the new uh image that has been pushed to quay. So if you remember when we were looking at the image, if we look at the manifest here, it's uh 47e or zero here, 47 e0.

B

If we go back to the ci here, that's the same shot that we are pointing at here. So basically, what it does is the pipeline will update the manifest and argo cd because argo cd is continuously looking at this github's repository to see. If there are changes it will automatically trigger the deployment of that new container image into the target environment.

B

And if we look at ago city here, we can see that uh you know it's synced, the application in the devsecops cluster in the ocp in in the first cluster, and if we look at the staging application, it's pointing to the same git repo, but instead of the dev folder, it's pointing to the staging folder and it's targeting the other openshift cluster as a destination.

B

So that's basically what happens the if we go back to the pipeline here, the pipeline should be.

B

Here so uh it's going to point to the.

B

Yeah, so this is going to update the manifest and then this task will trigger the uh the um synchronization of argo cd, but of course you can also have a uh an automatic uh synchronization, uh but basically what this task does is it's just triggers the ago cd deployment and waits for it to finish so um yeah. I think that's it uh in terms of integration, just as a recap, we saw that we have so everything is running on one openshift cluster in terms of solutions.

B

We have query registry, we have openshift pipelines, we have open shift gear ups, we have acs and acm. So all of those have been deployed to openshift as using the operators.

B

Then there's a couple of integration that have been set to make all of those tools uh work together. So there's the the quay bridge operator to automatically push and pull images from the remote way and not from the default openshift image registry.

B

Then there's the acs to query integration that allows to scan the images there's the pipeline to acs integration that allows you to pull the image scan results directly from acs and use those as gates to decide if the pipeline should move forward or fail, and then there's the integration between acm and argo cd. That allows us to register all of those class all or a subset of clusters that are under sem management within argo cd and then use them as target deployments for our applications.

A

Well, so jafar, let let me kind of pose a thought experiment and you might you might kind of reach through your monitor and smack me for for asking it. But let's.

B

A

We were trying to accomplish something similar without this particular set of tooling.

B

A

Much manual process would we actually have to undertake to do this if we didn't have the sort of those discrete steps that you just talked about about. You know basically being able to have the quay registry and and working separately from the default and being able to manage that quake registry in a way that you know gives you that control and then the integrations between acs and quay and the integrations between acm and and walk us through a little bit about what that.

A

What that's like in the absence of those you know, where are you going to bump into problems.

B

Yeah, so um um so what we? What we've seen here is, I would say, the combined value proposition of those tools all together, but keep in mind that um first of all, uh these tools can work with other things as well. I mean you are not forced to use those there's.

A

A long list of integrations there.

B

Yes, exactly the thing is that when we, when you use our products together- and I would say that's the basis of any good engineering- is that it should make it easier to use, because we are providing a set of automations that make it easier for you as an administrator as a user etc. So, that's I would say the value proposition is that we are taking care of some opinion. Opinionated integrations that make it easier for you, of course,.

B

If you don't have that, you would need to set up those things manually or create scripts that do that and of course it always takes time. So just the example that I uh gave with regards to synchronizing users, you know the role-based access from openshift to a distant registry.

B

uh It's not something that we provided with the first version, uh of course, because the first version was okay, there's quay there's an acquisition, but then we thought about okay. So how can we make it easier for our users and we came up with the quai bridge integration to basically automate all the manual integration steps that you needed to do uh before? So I I would say: uh yes, it's definitely more complicated.

B

uh If you don't have those helpers, that's not necessarily something that you know cannot be done. Yeah, yeah, absolutely.

A

B

Gonna take some more time and some more um you know hands-on to to be able to do that and.

A

Well, you know the thing: that's that caught my ear, you said. Well, you know you could write some scripts and you know I used to love writing scripts. I still like writing scripts occasionally, but you know it's right once maintained forever and in a sense, but.

B

A

Away from that sort of bespoke custom tailored, I wrote this thing: you're.

B

Really putting.

A

It putting it on us to maintain it and make all these things work, and it just.

B

A

Body of work that you would otherwise have to undertake to spend time on.

B

Yeah exactly and just to to emphasize on that and to give you a clear, clear example of what we do with our engineering is. We have definitely embraced the operator pattern. You know in full, so all of our solutions that we saw here are installed using operators, and that means that it's very easy to automate and to deploy uh using a githubs approach where you, you are not writing scripts, but you are just describing this is the desired state that I want. I want to have this operator deployed in that version.

B

I want to have that other operator and, of course, you you can customize the deployment of all of those tools using more sophisticated yaml files, but basically what this allows you to do at some point is you can have, for instance, and we do that a lot and there's also, for example, the uh some validated patterns that we provide that do that and basically you can have a central cluster where you have acm or argo cd and because everything we configure and deploy on openshift can be described as yaml.

B

You can say: okay, so here's a new cluster, it's a fresh freshly created cluster, now go ahead and apply all of those settings that you have defined in the yaml repository in the githubs repositories and make it compliant with whatever configuration I need. So you can say I want those 10 operators to be configured. I want it to be integrated with quay, etc, etc, and that's basically, I would say the value with our tooling and the I would say. The approach that we have taken with operators is that it does allow you to do that.

B

Some tools might not be based on operators and they might require you to trigger some binary installations, or you know scripts or whatever, and of course, it's always more sophisticated to apply a github approach. When you have you know this type of programmatic approach to installing and configuring.

A

Well, you know, and I mean aside from.

B

A

There's also just the risk of it not actually working the way you expect, whereas this is going to be a much more predictable approach to getting it done.

B

Sure, and- and so this is a maybe a little bit ahead of time, but there's a what we call the validated patterns that will allow us to even uh more simply deploy all of those components uh using openshift.

B

So basically, uh instead of having to install all of those tools together, we will ship a pattern that does everything for you on the target, openshift cluster and it's it becomes even simpler than how it is.

A

Well, this has been as always, extremely informative.

B

I am going to.

A

Make a little pitch here that uh you know, red hat does offer training and certification on openshift in general, but I'm actually very excited to share. You know, since we started this conversation around the concept of openshift platform, plus that we already have some training and certification on openshift data foundation, which is related, and then we actually coming out this summer. We are going to have training and certification on uh uh acm and acs and quay right.

A

So if these topics that uh jafar dug into a bit today are of interest and if you're, looking perhaps in your organization to make that step uh a little deeper into openshift with what you know, openshift platform plus provides, uh you know, take a look and see what we've got on offer, because that's going to that's going to help you with a lot of these things that uh that jafar talked about today, so jafar. uh What else would you like for us to to mention? uh You know unless we get some questions?

A

B

If there are any questions, please feel free to ask. Let me find the uh some people asked about some cicd yaml examples. um So let me share with you some of those but yeah. If there are any questions, please go ahead and just ask.

A

B

A

B

The first link that you can share randy that an example of a tecton-based ci cd, there's one, which is a bit more sophisticated.

B

So no questions everything was crystal clear.

A

It was very comprehensive, sir.

B

Yeah, I think people are are knocked down by yeah.

A

They might have to they might have to play that back through, but actually you know the thing is it's one of the wonderful things is that it's incredibly yeah, it's incredibly visual and I think that's one of the things is that you can actually follow along with something that's pretty complex, and so on that note, unless you have a last parting thought, I I think we are about concluded on this subject of uh uh get secops and openshift platform plus.

B

All right, so thank you very much and wish you a good day.

A

All right, thank you, everybody and again like subscribe and share, and we will see you in a couple of weeks thanks for joining us.

A

A