[MUSIC PLAYING]
MIKE COLEMAN: Hi.
I'm Mike Coleman, a developer advocate here at Google Cloud.
And in this video, I want to show you
how you can use Migrate for Anthos
to migrate IBM WebSphere applications to containers
in just a few clicks.
We'll start by looking at the system requirements.
Then I'll provide a quick overview
of the migration process.
Then we'll jump into an actual migration.
Now, this video is part of a series on Migrate for Anthos.
So if you haven't checked out those first videos
in the series, you might want to go back and watch those,
as this video builds on them.
You can find the link in the description.
[MUSIC PLAYING]
Before we get started, I wanted to clarify that in this video,
I'm discussing the migration of traditional IBM WebSphere
Application Server and IBM WebSphere Application Server
Network Deployment applications rather than IBM WebSphere
Liberty apps.
Keep that distinction in mind when
you hear me say WebSphere Application Server.
Migrate for Anthos lets you modernize app workloads running
in WebSphere Application Servers by converting them
to application containers.
You can then deploy the app containers
to GKE or Anthos clusters on Google Cloud,
Anthos clusters on VMware, and Anthos clusters on AWS.
A WebSphere Application Server VM can contain multiple apps.
Migrate for Anthos helps you automate the modernization
of WebSphere Application Server apps
to containers by discovering deployed apps in the source VM
and automatically suggesting the configuration
for the modernization.
With Migrate for Anthos, you migrate each app
to its own container.
This allows you to test and deploy the migrated apps
individually rather than having to test and deploy
multiple apps together.
Regardless of whether or not your source
apps were running WebSphere Application Server or WebSphere
Application Server Network Deployment,
the resulting container image will be the official IBM
WebSphere Application Server traditional container image.
And for those of you wondering, the original responsibilities
of network deployment-- clustering, scheduling,
version roll-outs, request routing, et cetera--
will now be offloaded to Kubernetes.
Migrate for Anthos supports the migration of apps
hosted on the following versions of IBM WebSphere Application
Server--
WebSphere Application Server traditional 8.5.5.x
and WebSphere Application Server traditional 9.0.5.x.
Migrate for Anthos extracts two types
of configurations from the VM--
the configuration for each application
and the configuration of the target profile,
which defines the runtime environment of a WebSphere
Application Server, including ports, the Java virtual machine
settings, et cetera.
The Migrate for Anthos software automates the use
of the IBM WebSphere Application Server Migration Toolkit
for application binaries to discover, assess, and generate
migration reports, as well as creating configuration scripts.
Before you can start a migration,
you must upload the toolkit to a Google Cloud Storage
bucket in your account.
Check the documentation for more information on this procedure.
When migrating WebSphere Application Server apps,
the processing cluster can be deployed on Google Kubernetes
Engine or an Anthos cluster on Google Cloud, VMware, or AWS.
Regardless of where the cluster runs,
it must use a Cloud Storage bucket
as the repository for the resulting migration artifacts.
For more information on creating a processing cluster,
check out the first video in this series.
You can find a link in the description below.
And be sure to read the docs to get the full details on all
the system requirements.
With the prerequisites out of the way,
let's take a look at the general migration flow.
First, you're going to add a migration source, which
represents the source platform from which
you will be migrating.
Then you're going to create the migration.
And that specifies the VM you're actually going to migrate.
You'll edit your migration plan, including
selecting the WebSphere Application Server
app that you want to migrate.
And you should migrate one WebSphere Application Server
app per migration.
Then you're going to actually perform the migration
to generate the app container artifacts,
and then review those artifacts in preparation
for building the deployable app image.
Now, use the migrated artifacts to build
a container for your migrated app,
and then deploy your migrated app to your target cluster.
Finally, test the migrated app and validate the migration.
Note that if your source VM has multiple apps,
you're going to need to repeat steps 3
through 7 for each application you wish to migrate.
Also, you may have noticed if you've watched previous videos,
there's not an explicit step to assess the application using
the Discovery tool.
That's because the assessment happens
when you run the migration.
All right.
Let's go ahead and jump into an actual migration.
We're going to take a source VM and extract
a single application from that VM,
then deploy it to a GKE cluster following the basic flow
that I just outlined.
As you can see in the Cloud Console,
I've actually already created my migration processing cluster
and my migration source.
I've also gone in and I've stopped my WebSphere VM.
With those things out of the way,
I'm all ready to start by creating the actual migration.
And to do that, I'll move into the Cloud Shell
and issue the migctl create command.
Most of these parameters are pretty straightforward,
but I wanted to point out this app-type property
at the bottom.
That's where we specify that we're actually migrating
a WebSphere application.
Creating a migration is going to take a few minutes,
so I'm going to pause the video, and I'll
come back when it's done.
With the migration assessment completed,
I wanted to show you the application discovery
report that was generated.
It's stored up in a Cloud Storage bucket.
So let's navigate to the actual report and load it up.
Now, I'm not going to go through the report in detail.
I just want you to know that it's available to you,
and that it will give you a bunch of information
on the applications that were scanned.
Let's move back into Cloud Shell.
And I need to download and edit my migration.yaml.
So I'll use migctl get migration.
And then I'm going to go in and edit that file,
and here are these path variables.
Now, they represent the applications
that were found during the scanning process.
And I only need one of them.
You only migrate one application at a time.
So I'm going to delete this query.ear path location here.
And then the other thing I want to do
is I want to go down to the default app name
and change that from WebSphere to something else.
So I'll make that change here.
And I'll actually make the change
for the name of the Docker image that's created as well.
We use migctl to upload our updated migration plan,
so that when we execute the migration in the next step,
these new settings are used.
And so let's go ahead and do that.
I'll clear the screen.
And then I'm going to use migctl to execute the migration plan
and generate my migration artifacts.
This will take a few minutes, so I'm going to pause the video,
and I'll rejoin when it's done.
migctl is finished, so let's go ahead and grab those artifacts
using migctl get-artifacts.
I will list out the directories so you
can see which was created.
We've got a Docker file, our application's .ear file,
and this wsadmin.py file.
This is where a bunch of settings for your application
will be held.
And you may need to edit that, depending on your application.
Finally, there's a build script that
automates the creation of our Docker image
and uploads it to the Container Registry.
I'll go ahead and execute our build script.
The build file takes several minutes to run.
I've sped up the video so you can see what's
happening in the background.
It's going to pull the base Docker image.
Then it runs through the configuration of the WebSphere
server, including copying in the application.
And then finally, it pushes that completed container image up
into the Registry.
Now I'm going to go ahead and edit the deployment.yaml file,
which by default provides a headless cluster IP
service which is only accessible from within the cluster.
I'm going to change that to type LoadBalancer
so we can access our service externally.
All that's left to do now is to actually deploy
the application, and we'll do that using kubectl apply -f
deployment_spec.yaml.
That's going to deploy that deployment
spec we just looked at.
So we're going to create a service,
we're going to create a deployment,
and then we can check the status of those
by using kubectl get pods and kubectl get service.
Now, from the service, we can grab the external IP address
here and see that our application, a movie
rental service, is up and running in our browser.
And that's all it takes to migrate
a WebSphere application running in a VM
to running on Kubernetes.
There you have it.
We've successfully migrated an application
from WebSphere Application Server running in a VM
to a container running on GKE.
If you haven't already, be sure to like and subscribe,
as we'll be adding additional videos to the series.
And feel free to check out Migrate for Anthos
up on Google Cloud today.
[MUSIC PLAYING]