 Hello everyone. I hope everyone feels a bit more awake having a coffee after the break Today, I want to talk to you about OpenShift Hive Maybe not everyone from you will know Hive But we use Hive at world pay a little bit about ourselves and my name is Burns I'm the principal container platform engineer at world pay I moved from Berlin to London in 2013 and started working with OpenShift in Kubernetes around four years ago and joined world pay beginning of last year At world pay I manage a small team and we run OpenShift container platforms on clouds and We do that for an internal microservice applications I'm here today to tell you about how and why we shifted to OpenShift Hive which improved our efficiency and Started creating a global platform for us No wrong one. There we go. I'm Matt. I've been working on Kubernetes and OpenShift for around four years I'm working with Bernal at world pay So before we start with OpenShift Hive, let me tell you a little bit about world pay Maybe some of you have heard already FIS and world pay merged mid of last year and we're now a part of FIS World pay itself is a part of merchant solution and we said alongside banking and capital market solutions from FIS and OpenShift became an essential part in merchant solution for us to provide the PCI compliant platform To run our internal microservices So let me talk about our journey to OpenShift 4 because I think that's might be very interesting for everyone so as a small team for us it was very important that we need to work very efficiently and Like reduce administrative overheads We had to experience with some OpenShift 3 that's like we didn't want it to to manage our infrastructure And our cluster provisioning separately So for us that was like very painful of you know, like it was very time-consuming and a lot of like manual steps OpenShift 4 was like great for us like it addressed like some of the issues But like we felt like the installer like it's It's it didn't scale it's for us. It was like we wanted to we knew we wanted to have multiple clusters And like we had like like I said a small team of team members so far us that didn't scale So we were looking for something something missing There was something missing and we were looking actually for like something was more IP API driven so having a cluster management and And we actually wanted to run cattle clusters and not pets anymore like what we did with OpenShift version 3 so This all started basically a year ago and when we became involved with the OpenShift 4 beta program and We increased our collaboration with red heads and alongside with stats Sort of beta engagement is how we found Hive actually And it was very surprising for us like hearing about Hive like we never heard about it before so we we ask Guys from red head and London actually if they knew Hive and actually not many of them knew at that time So but we were pretty excited about like the capabilities and features OpenShift Hive has so we started using it for our OpenShift 4 deployment Basically Hive is an API driven cluster provisioning and Management operator and this was exactly what we were looking for so we quickly Extended the capabilities Around Hive and like build a whole ecosystem around it to actually manage our OpenShift 4 clusters I will hand over to Matt now and he will talk you through the cluster deployment with Hive So we went about Installing the Hive operator onto a single management cluster So this management cluster would have all the details of the other clusters which we're going to deploy using Hive And we're able to actually define one of our clusters within a custom resource called a cluster deployment So within that manifest we'll be able to describe all the different details of the cluster so the VPC subnet the sizes and everything which it looks like and when we apply that to the Kubernetes cluster which runs the Hive operator It will then go ahead and spin up our cluster and look after the reconciling of that cluster and the data Stay operations around it Which is short demo So this is on our Hive cluster and we've got to manifest here, which is a cluster deployment this is the alpha version of it and Within that we've got some labels one of them being one of our own which will define the environment So we've called it an engineering environment And we've also got some references to secrets like our AWS account credentials We're going to be deploying it to AWS in the EU West one region And it's got those other secrets like the Red Hat pool secrets It'll look very familiar to anybody who has installed a Openshift for cluster. It's very similar to that install config and Then we're just describing what the compute looks like the worker sizes and nodes what AZs are going to be in So when I apply this manifest the Hive operator be watching for this custom resource and it will Set about Some actions in order to install it so we'll download the actual binary installer It will take our secrets which are held in this management cluster It'll inject those into a pod which will actually do the installation of this cluster So we can see here when I do get cluster deployments We can see that it's not yet installed. It was only created 11 seconds ago I do get pods and we can see that there is a image set pod and a provision of pod So the image set one's going to pull down all the resources which which I need from quay and Within the installer you'll see both familiar log entries from this sort of terraform bootstrapping process Which the installer does So it's going to take around 45 minutes and we can see that it's working in AWS It's creating our VPC and it's starting that bootstrapping process And Hive isn't just on AWS So this could be on any of the cloud providers or on-prem Many from which you can do with a normal installer you can do with Hive in this example. We're just sharing AWS And here we can see that the bootstrapping process has complete We've got our new control plane which has taken over the management of our cluster and we've got some work That's coming up At this point the installation of the cluster is done and we finished our day one activities I've just created the thing we might be using this as a test cluster to test some new configuration or doing some development It could be for any purpose it for our team, but since it's all on the same management cluster We all have accesses management cluster We can get access to secrets like what the admin password for it and how it's set up So it's a good collaboration or central collaboration area for us to go to So I can grab the secret login and hey press it. There's my open shift for cluster Great So we created an open shift for cluster with Hive but What comes next? Like we how do we manage the configuration of these clusters actually because this was the day two operations like what we what we needed also and how we do that with hundreds of configuration manifests and with multiple clusters and how we do promotions and Like the biggest problem actually what we face from an open shift version threes like how do we avoid configuration drift? and Hive helped us by using sync sets and It basically regularly reconciles the configuration of all our clusters Which are And which are subscribed to and keep them basically synchronized Matt now we'll show you guys how we use sync sets was Hive So another custom resource which is available to us and on our hive cluster is called a sync set So within this we've basically got one big manifest which contains all of our smaller manifest so within that we might have some configuration items like A daemon set or machine config which will change our NTP time to sync with our on-prem Area or something like that and what we want to do is in a similar way Which we would subscribe a single machine to say stable in young or unstable or testing repository we want to use a similar sort of methodology to upgrade our different clusters So we might do a little bit of development in an engineering cluster We'll keep that in sync with our IAC repo in GitHub And then when we're ready we'll create a release and then we'll actually create a single immutable sync set Which we can then promote through to higher environments Making the actual sync sets It's quite difficult though because it's just a massive Manifest so what we went about doing was creating a generator We should be able to look at a particular directory Walk through it take all the smaller manifest which are in there and generate our one big manifest Which we can then apply to our hive cluster If you're interested in that we can show that later. So here's a demo Hopefully it's actually running So within this particular directory and this emulates what our IAC repo would look like We've got two folders patches and resources so patches for any existing resources for instance We don't want any of our customers to be self-provisioning into our environment So we do a patch there and we've got some resources where we're going to say set up AD authentication into our open shift for environments set up some secrets those kinds of things We've got a little binary here Which will run in this directory and that will create our one big manifest Which has all the different resources and patches which are available and to us there One argument to it is The actual match labels so we showed a label earlier where we defined what type of environment My cluster was going to be so we want to target all clusters which are in that sort of environment So that could be a pre-prod environment or prod environment for saying any cluster which has those labels So we've applied it now to our hive cluster so the hive operators recognize this and we can see what the status of this particular sync set is Against our Cummins demo cluster and then within there you'd have all the different clusters which matched this sync set So we can see here that we've got a lot of Applied success for each one of the manifests which are within the sync set. So it happily went to that cluster Thank you Matt Yeah, so that basically led us off like using a type of GitOps model to manage our clusters So the cluster configuration So the cluster deployment and the configuration actually is stored in Git and our engineers basically applying changes to the platform only via a single repository There are no manual changes to the platform anymore Which helps us avoiding drift what I've mentioned before And like the the big advantage actually is like we bundle our changes into releases So you have seen that before it's like we can pin environments to particular releases basically Our ci tool is basically generating The manifest and applying them automatically to our management cluster And then basically Hive is running on on that as Matt explained that so the rest is basically only doing Hive It's pushing down the sync sets was a configuration down to the clusters Which are subscribed to and Yeah, I think the only thing additionally to mention is that we also manage our promotions to higher environments through our ci tooling So the benefits for us at world pay Like I mentioned the Hive operator like helped us to adopt the GitOps delivery model This had a big impact actually on on the team itself It's everyone started to be become more like a software engineer and we shifted left And actually started focusing on other things like writing tests so we really like Focus on like test different test driven development For our platform But we also benefited actually from and the closer relationship actually we have was rat heads and the community Our internal developers benefited From the improved self-service capability of open shift forward was great But also of Hive because now everything is in code like Like adjusting quota changes of the namespace is now just a pr basically into our cluster repository And as I mentioned before we have released channels and we're able to do control promotions of all our changes and I think Do you have anything to add no And actually that's it. Thank you guys. I hope this was interesting If you have any questions grab us in the next coffee break or later today. Yeah, and we'll do as I