{"id":474,"date":"2021-03-16T06:42:15","date_gmt":"2021-03-16T06:42:15","guid":{"rendered":"https:\/\/rejupillai.com\/?p=474"},"modified":"2026-04-13T00:08:46","modified_gmt":"2026-04-13T00:08:46","slug":"migrate-vm-to-container-on-kubernetes","status":"publish","type":"post","link":"https:\/\/rejupillai.com\/index.php\/2021\/03\/16\/migrate-vm-to-container-on-kubernetes\/","title":{"rendered":"Auto-magically in minutes, migrate VM apps to Container on Kubernetes"},"content":{"rendered":"\n

One of the most commonly adopted cloud-migration strategy is to lift and shift applications from on-premise to the cloud. Perhaps a state missing in the below CMM is called “Cloud Washed”, a prevalent industry practice in which legacy apps are re-branded as cloud apps, by just moving them out to the cloud. I would place it at the bottom. In my opinion apps should move to cloud, not just for a better cost optimization but also to exploit the elasticity and get the speed, agility and nimbleness required to release new features to market faster, cheaper and smarter. And that’s what Cloud Native Apps do.<\/p>\n\n\n\n

\"\"
Cloud maturity model (CMM)<\/figcaption><\/figure>\n\n\n\n

Brownfield challenge<\/h3>\n\n\n\n

In a brownfield environment, the biggest challenge in adopting modern applications principles is refactoring apps, that is going back to design board, breaking open the app, applying 12 (15) factors, correctly finding bounded contexts and more. Wait, wasn’t the app already in its midlife, and would possibly be sunsetted in couple of years ? So what is the immediate value realised after all this pain ?<\/p>\n\n\n\n

What if you could,<\/p>\n\n\n\n

find a middle ground ?<\/p>\n\n\n\n

benefit from the goodness of a “platform” ?<\/p>\n\n\n\n

migrate your legacy app into containers, with no\/minimal to moderate dev effort, and better yet, automatically run it on a modern system like Kubernetes ?<\/p>\n\n\n\n

forward engineer, from source to production and gradually adopt continuous delivery practices for the app ?<\/p>\n\n\n\n

repeat it for more apps with confidence, like in a “migration-factory” ?
<\/p>\n\n\n\n

Goal<\/h3>\n\n\n\n

This blog shows how Google Cloud’s Migrate for Anthos<\/a> (M4A) help solve the problem without breaking a sweat. I will demonstrate with absolutely zero changes to the app<\/strong>, and with few clicks how I moved a WordPress app backed by MySQL from a VM running on compute engine to a StatefulSet Pod running on Kubernetes. <\/p>\n\n\n\n

Let’s begin<\/h3>\n\n\n\n

Step 1 : Deploy the VM App (Source)<\/h4>\n\n\n\n

Google Cloud Marketplace<\/a> is home to numerous open source, paid products and solutions that you could deploy to Google Cloud. Under the hood, the solutions are packaged as Deployment Manager<\/a> Jinja\/Python scripts, GCP’s IaC solution. The MarketPlace also provides easy customization, so you can choose the T-shirt size for the VMs and disks, that best suite your need. But for now let’s just “Click to Deploy”.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Step 2 : Review that app<\/h4>\n\n\n\n
\"\"
GCE VM<\/figcaption><\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n

Step 3 : Configure M4A and Migrate<\/h4>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Step 3.1 : Processing Clusters<\/h5>\n\n\n\n

Processing cluster is the Target GKE<\/a> Kubernetes cluster. Create a new one or deploy to an existing cluster.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
Step 3.2 : Sources<\/h5>\n\n\n\n

The source is where the VM App resides.In our case the WordPress VM on GCE. As you will see from the dropdown, M4A supports VMware, AWS and Azure <\/code>along with Google Cloud. For other clouds, M4A requires additionally the setup of Migrate for Compute <\/a>(M4C). I would plan to demonstrate that later, as an addendum or Part-B to this post.<\/p>\n\n\n\n

\"\"
define source<\/figcaption><\/figure>\n\n\n\n
Step 3.3 : Migration<\/h5>\n\n\n\n

Provide the required details, along with the intent to migrate only the image, data or both<\/code>. After creating migration, run the migration.<\/p>\n\n\n\n

\"\"
migration setup<\/figcaption><\/figure>\n\n\n\n
Step 3.4 : Review generated artifact<\/h5>\n\n\n\n

This is where things get interesting. The tool automatically creates the necessary artifacts including a Dockerfile for the Container App, a Kubernetes Deployment spec YAML. It also automatically pushes a Base Image, and a container Image (for the app) to Google Container Registry<\/a> (GCR) within the projects’ repository.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
Step 3.5 : Voila ! The app is migrated…<\/h5>\n\n\n\n
\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n

What lies beneath ? <\/h3>\n\n\n\n

Let’s do an analysis of what just happened, and what did the tool do under the hood ?<\/p>\n\n\n\n

4.1 : Review M4A CRDs & Pods<\/h5>\n\n\n\n

M4A CRDs is deployed to the Target “Processing Cluster”, chosen in the above Step 3.1. The M4A CRDs and Pods can be viewed here.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

This is the core M4A infrastructure that helps migrate the app, create disks and generate artefacts such as Dockerfile and K8s Deployment manifest. Let’s review them.<\/p>\n\n\n\n

4.2 : Review Pods, Services and StatefulSet<\/h5>\n\n\n\n

Because there is a MySQL Database backing the WordPress app, the Container app is implemented as a StatefulSet. This is indicated when user chooses \"data\" or \"image & data\" <\/code>while configuring the migration in Step 3.3. When any of the latter 2 is chosen, the migration tool will create a PersistentVolume<\/code> (PV) in Kubernetes and map the GCE Persistent Disk <\/a> attached to the WordPress VM.<\/p>\n\n\n\n

By default there is no Ingress \/ Service type LoadBalancer deployed as part of the generated manifest, so you will have to expose the Pod WebService using one of the methods.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
4.3 : Review PV, PVCs and StorageClass<\/h5>\n\n\n\n

M4A extracts the Persistent Disk <\/code>(Google) associated with the VM or incase of a VMware environment, the .vmdk <\/code>disk and stream-migrate it to GCP project hosting the cluster. <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
4.4 : Dockerfile <\/h5>\n\n\n\n

Dockerfile<\/p>\n\n\n\n

# Please refer to the documentation:\n# https:\/\/cloud.google.com\/migrate\/anthos\/docs\/dockerfile-reference\n\nFROM anthos-migrate.gcr.io\/v2k-run-embedded:v1.6.2 as migrate-for-anthos-runtime\n\n# Image containing data captured from the source VM\nFROM gcr.io\/reju-anthos-bank\/wordpress-multisite-1-vm-non-runnable-base:3-14-2021--12-2-31 as source-content\n\n# If you want to update parts of the image, add your commands here.\n# For example:\n# RUN apt-get update\n# RUN apt-get install -y \\\n# package1=version \\\n# package2=version \\\n# package3=version\n# RUN yum update\n# RUN wget http:\/\/github.com<\/strong>\n\nCOPY --from=migrate-for-anthos-runtime \/ \/\n\n# Migrate for Anthos image includes entrypoint\nENTRYPOINT [ \"\/.v2k.go\" ]<\/code><\/pre>\n\n\n\n
Notice that M4A creates a multi-stage build with a base-image that represent the M4A-runtime. The relevant filesystem source is extracted from the VM and it becomes part of the new container image represented by source-content<\/code><\/p>\n\n\n\n
Forward engineering with CI\/CD <\/h3>\n\n\n\n
In Step 4.4, you can add \/ replace content of the File system via RUN\/ADD\/COPY. This provides an extension to not just migrate a running VM environment to a running container, but also help us to make new modifications or patches to the application, which opens up all new possibilities to further enhance the build & deploy pipelines via CI\/CD.<\/p>\n\n\n\n
Assess, what are good candidate apps for M4A<\/h2>\n\n\n\n
There are 2 tools for Linux<\/a> and Windows<\/a> environment that comes handy to determine if your application is a good candidate for M4A to seamlessly migrate the app. The fit score tells what level of manual effort may be expected pre\/post migration. A score of > 7 is a good fit for M4A with moderate to no dev efforts. Like in this example we didn’t require to do any changes at all.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
m4a-fit-collect.sh runs the commands like netstat, hostname, systemctl, service, ps, lsof<\/code> etc… to determine the state of the VM and the processes that are running and ports to which they write. In addition the relevant files are copied into the tarball for analysis from \/etc\/* and \/proc\/* directories. A full list can be found here<\/a><\/p>\n\n\n\n
Application Portfolio Analysis & Migration Path<\/h2>\n\n\n\n
Tool supported assessments, both at an app (VM) level like m4a-fit-collect.sh<\/code> and at a portfolio level, like Stratozone<\/a> helps you develop an app migration strategy for the cloud.  But broadly put together, an enterprise may have a combinations of some of the below applications, and bucketing them can help identify what applications can be a better fit for M4A.  COTS\/ISV, J2EE, IIS .NET (migrated to Windows Containers), WebSphere, JBoss, Tomcat, J2EE Apps, Web Apps, Portals & CMS like WordPress, Drupal etc.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Conclusions<\/h2>\n\n\n\n
We saw how Migrate for Anthos <\/a>can help significantly speed up the journey of a legacy application to Container on Kubernetes, without even changing a line of code. While this may not necessarily be true for complex application and hence doing a pre-assessment with a fit-score analysis is useful. <\/p>\n\n\n\n
It is also not required that all applications must move to cloud. You could modernize on-premise and get the same result using Anthos On Prem.<\/p>\n\n\n\n
Thanks for reading ! <\/p>\n","protected":false},"excerpt":{"rendered":"
One of the most commonly adopted cloud-migration strategy is to lift and shift applications from on-premise to the cloud. Perhaps a state missing in the below CMM is called “Cloud Washed”, a prevalent industry practice in which legacy apps are re-branded as cloud apps, by just moving them out to<\/p>\n","protected":false},"author":1,"featured_media":482,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[],"class_list":["post-474","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-google-cloud","ct-col-2"],"_links":{"self":[{"href":"https:\/\/rejupillai.com\/index.php\/wp-json\/wp\/v2\/posts\/474","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rejupillai.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rejupillai.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rejupillai.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rejupillai.com\/index.php\/wp-json\/wp\/v2\/comments?post=474"}],"version-history":[{"count":49,"href":"https:\/\/rejupillai.com\/index.php\/wp-json\/wp\/v2\/posts\/474\/revisions"}],"predecessor-version":[{"id":553,"href":"https:\/\/rejupillai.com\/index.php\/wp-json\/wp\/v2\/posts\/474\/revisions\/553"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/rejupillai.com\/index.php\/wp-json\/wp\/v2\/media\/482"}],"wp:attachment":[{"href":"https:\/\/rejupillai.com\/index.php\/wp-json\/wp\/v2\/media?parent=474"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rejupillai.com\/index.php\/wp-json\/wp\/v2\/categories?post=474"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rejupillai.com\/index.php\/wp-json\/wp\/v2\/tags?post=474"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}