Red Hat OpenShift Spain 2022 OpenShift Commons Gathering at KubeconEU, 17 May 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: From Cloud Foundry to Openshift Fully Automated Migration Adam Flower Thomas De Vos HCL Technologies

Description

From Cloud Foundry to Openshift Fully Automated Migration
Speakers Adam Flower & Thomas De Vos (HCL Technologies)

OpenShift Commons Gathering Kubecon EU
May 17, 2022 Live from Kubecon EU in Valencia, Spain

Full Agenda here: https://commons.openshift.org/gatherings/OpenShift_Commons_Gathering_at_Kubecon_Europe_2022.html

Learn more at: https://commons.openshift.org

A

I'm alan flower from hcl I'm joined by thomas devos.

A

We're here to show you something quite interesting today. This is the first time you would have seen this um in our industry, we're at an event called cubecon right, and it's easy to think that in the world of kind of container orchestration platforms, kubernetes is the only platform that counts.

A

In fact, there are two significant container orchestration platforms in our industry, kubernetes and cloud foundry. How many people here have ever ever heard of a project called cloud foundry, a lot of people? Okay, what's happened in our industry over the last two or three years is the the gravitational pull towards kubernetes has been overwhelming right. It is now the de facto uh orchestration platform and openshift, of course, is the market's most dominant containerization platform. Today, what we're going to show you now is fully automated migration from cloud foundry to openshift.

A

If there is one request that we've heard more than anything else in our industry over the last two years, it's from cloud foundry users who are desperate to leave a stagnating legacy platform and move all of their workloads to openshift. You may be familiar with products like pivotal cloud foundry.

A

You may have heard of products like vmware tanzu. You may be an ibm bluemix or cloud foundry user. These are all commercial distributions of cloud foundry.

A

So what we've built is a fully automated journey to take you away from cloud foundry to open shift. We're announcing today at this show support for all of the major commercial cloud, foundry implementations, pivotal cloud, foundry, vmware, tanza and so on, but we also support migration to openshift from any other kubernetes platform. This is fully automated no human intervention, migration, which we are going to demo to you, you're, going to see a demo where we migrate stateful, as well as stateless production, workloads from a live cloud.

A

Foundry platform, it's running in our lab today in dallas, and we're going to show you how we move from cloud foundry to openshift the openshift instance we're using is, is running on google. This is a fully automated journey.

A

We automate absolutely everything. You only have to make three clicks and we do the work for you. We do complete vulnerability scanning, so we're checking for the consistency and the security of any workloads that come across to openshift, and this is a fully automated journey. The best thing I can say to you is rather than me talk about it. We're going to show you this. It is so straightforward and thomas if you'd like to join me and maybe take over and maybe just describe what we're.

B

Going to show, I think sure, can you hear me.

B

No not yet! No, you can hear me. Are we awake? Yeah? Perfect, that's good! Okay! So um thank you, alan, so much for for the the introduction over here, sir, I would like to demonstrate over here live how we can migrate a cloud foundry workload onto openshift, and so this is the demo setup I have over here. For you, we have the kubernetes migration platform kmp deployed onto jl on gcp, first and foremost, kmp tax, with a couple of agents deployed on a vm, and the purpose of those agents is to keep connectivity going with.

B

In this case, tas, like alan, was saying in dallas into our cloud native labs and on the right hand, side. You see that the the target, which is open shift I'm going to bring up now the drawing application which is running on on task, I'm going to try to move the workload and the data onto openshift.

B

I can't see this very well.

B

B

So this is the kubernetes migration platform. I have currently defined two agents, as I earlier said, the first one is the openshift one and you can see here the end point. The end point is connected to open shift. It does the automatic discovery over here and also I have an end point configured here and connected to the um to vmware tanzu. um So you can see I have over here one application deployed. This is a springboot application, has a a backhand or managed service name of my sql.

B

This is the drawing application I was talking about, and hopefully I will try to bringing my creative skills over here and do some drawing over here see it's a bit more difficult with this mouse, but okay, hello, kubecon.

B

B

B

Anyone else has better artistic skills than myself, yeah.

A

I think we get it all right.

B

Okay, perfect, that's good, so this is kind of the application. I am storing the state of this fantastic drawing into my sequel. Next, I need to kind of go to my kubernetes migration platform. I am going to define um a plan and a plan is nothing more than defining.

B

What do I minor migrate from and to so over here I give it a friendly name, openshift comments, and I want to migrate all the applications deployed into the default space. In this case, there's only one application to open shift.

B

I have my plan created, and the next thing I need to do is just simply click on my grade. So now the migration has started the intelligence behind the kubernetes migration platform has started. What are we doing over here? We are first and foremost discovering what applications we have running in this case. One application is a drawing application. We are getting all the artifacts, we are getting all the binaries and we're downloading this into a central place from here we're creating a new docker file in order to create a container image.

B

The container image is currently being created in the background once that has been created we can deploy, we will store it in there and we will store it in um in docker hub and the reason we're storing this in docker hub, because we need to create as well a set of manifest files to deploy into openshift we're creating those money file and manifest files from the ground top with a reference to the new container image that we have created, but we also have discovered that we have a mysql database, so this is a little bit more trickier.

B

We need a request from client foundry. The end point of that managed service. We are. We have discovered that we have a mysql database. We also have support for postgres. We also have support for redis at this moment in time.

B

Once we know what type of database we have, we get all the metadata database tables. We get also the data out of it. We store it again into a central place. Now we have all the artifacts. Now we can start recreating this in openshift, we are having a sync module that syncs the data between that central place into kubernetes.

B

We have created a new instance into a namespace on um on kubernetes, in this case on openshift, so the migration is currently happening. The other thing that we're doing is to creating a number of kubernetes manifest files. We are trying to match the storage networking, endpoints egress dns, all these kind of good things onto openshift. We have a lot of intelligence built built in there in order to kind of map.

B

In order to map whatever was there deployed into cloud foundry and also in in openshift, I suspect that this migration will take about three minutes: the same kind of automatic migration we do as well for kubernetes or any commercial kubernetes platform onto openshift. So once this is running, are there any questions.

B

No okay, let's see there's.

A

One question here left hand side at the rear.

B

B

Sorry, I can't hear you very well.

B

We're just migrating the binary so we're getting all the artifacts the javascripts, whatever has been deployed, yeah we're creating. I mean we're recreating the original container that was been running into kind of cloud foundry and now we're creating a new container, and we should restore this in docker hub and not the source code.

B

We're going to have to migrate, indeed the source code manually, if that's what you would like to do yeah, but I guess that goes into your normal software engineering process anyway, yeah it's completed so here you can see after three minutes and 19 seconds. The migration has been completed successfully.

B

The only proof in the putting over here now is that we go to my my open shift cluster and see if this one actually happened successfully.

B

So let me open this one and yes indeed, I do have now a drawing app in deployed into a namespace. Let me have a look at the end point over here and here you go. Application fully migrated automated in three minutes 19 seconds. Thank you.

B

It's encrypted into a central repository: that's right, yeah! So we are here um in the coming three days as well. At kubecon we are at boot g1 as part of hdl. So if you have any more questions either for the cloud foundry, 2, kubernetes migration or you have further questions around any commercial kind of kubernetes migration onto openshift, we're more than welcome to show this more in detail or, if you or, if you have more detailed questions, feel free to to come over. Thank you so much.

A

A