This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.
Look at Azure as a platform for running your Linux virtual machine and open source database workloads. Check out options for how you can lift and shift existing VMs and databases to Azure and modernize them using cloud native approaches. Matt McSpirit, from the Azure engineering team, joins Jeremy Chapman to show how Azure supports open source platforms across operating systems, with different Linux distros as well as their publishers and open source databases.
Azure has been working with Red Hat, SUSE, Canonical, Flat Car, Elastic and HashiCorp, and open source databases like MySQL, Postgres, Cassandra, MariaDB for years. More than 60% of our marketplace solutions run on Linux, and we support open source native PaaS services, as well. Beyond the workload level, we contribute back to the upstream Linux and Kubernetes communities that many of the modern and cloud native architectures rely on.
01:09 — Run Linux VMs in Azure
03:01 — Move an open source app from on-prem into Azure
06:04 — How to migrate VMs
07:36 — How to move database into Azure
10:52 — Repackage your VM to run as a container
12:40 — Configure an app
13:31 — Other options
14:48 — Wrap up
To find information related to Linux running on Azure, check out https://azure.com/Linux
Go to Azure migrate and test out a migration at https://aka.ms/azuremigrate
Find the tools to migrate your data stores at https://aka.ms/datamigration
Deploy Red Hat solutions on Azure at https://Azure.com/RedHat
Run SUSE Linux on Azure at https://Azure.com/SUSE
For more on Azure, go to https://Azure.com/AzureMigrate
Unfamiliar with Microsoft Mechanics?
We are Microsoft’s official video series for IT. You can watch and share valuable content and demos of current and upcoming tech from the people who build it at Microsoft.
- Subscribe to our YouTube: https://www.youtube.com/c/MicrosoftMechanicsSeries?sub_confirmation=1
- Join us on the Microsoft Tech Community: https://techcommunity.microsoft.com/t5/microsoft-mechanics-blog/bg-p/MicrosoftMechanicsBlog
- Watch or listen via podcast here: https://microsoftmechanics.libsyn.com/website
Keep getting this insider knowledge, join us on social:
- Follow us on Twitter: https://twitter.com/MSFTMechanics
- Follow us on LinkedIn: https://www.linkedin.com/company/microsoft-mechanics/
- Follow us on Facebook: https://facebook.com/microsoftmechanics/
- Up next, we’ll look at Azure as a platform for running your Linux virtual machine and open source database workloads, from your options for how you can lift and shift existing VMs and databases to Azure, and also modernize them using cloud-native approaches. So, today I’m joined by Matt McSpirit from the Azure engineering team, and also no stranger to Microsoft Mechanics. Welcome back.
- Hi, thanks for letting me back on.
- And thanks for joining us today. So, we wanted to do a show based on Azure support for open source platforms across operating systems, with different Linux distros and also their publishers and open source databases. You might be surprised that more than 50% of the workloads running in Azure are actually running on Linux VMs.
- Yeah, that’s right. And we’ve been working with Red Hat, SUSE, Canonical, Flat Car, Elastic and HashiCorp, and open source databases like MySQL, Postgres, Cassandra, MariaDB, and more for years. And it’s actually more than 60% of our marketplace solutions that run on Linux, and we support open source native PaaS services too. Then beyond the workload level, we also contribute back to the upstream Linux and Kubernetes communities that many of the modern and cloud native architectures rely on.
- Okay. So let’s unpack this a bit more starting with your options then that we have for running infrastructure in VMs. So, if you’re a Linux shop maybe running multiple platforms, what’s the best way to think about running Linux VMs in Azure?
- Well, nearly every business or organization out there is running on multiple platforms. So there isn’t really a concept of a pure Linux shop or a Microsoft shop these days. And both platforms have a lot of pros and cons, and we’ve done a ton of work for performance, reliability, manageability, and security to make Azure the best home for running any open source workload. Now, starting at the foundational level; as I mentioned, we’re working with the leading Linux distros to optimize the kernels for Azure, including tuning the kernel for a Hypervisor, providing updates and patches and performance enhancements for running open source databases. And we also work closely with Red Hat for managed services like Azure Red Hat OpenShift, and SUSE with SAP enhancements. So we want to make sure when you bring your workloads to Azure, there’s benefit in every step of the way, from onboarding to operation, and you gain more security than you may have had on premises, in your private cloud or in another cloud. And whether you’re starting green field or bringing what you’ve already got running through Azure, we’ve got you covered.
- Okay, so spinning up a couple of VMs, I think from Azure is pretty straightforward. But, what if you got dozens or hundreds of VMs that constitute your apps, how would I bring those into Azure?
- Well, Azure Migrate is, as we know, your one-stop shop in Azure for bringing in virtual machines, databases, complete applications, even entire VMware sites into Azure. And of course, you can rebuild or rehydrate everything using automation for the apps you install in VMs running in Azure. And those will work the same as you’d expect. But unless you’ve fully automated that process, you’ll likely save a ton of time using Azure Migrate.
- Great. So, let’s make this real though. Can you show us how you’d move an open source app then from an on-prem system into Azure?
- Sure. Now, first I’ll start by showing you our app called Airsonic. It’s an open source Java app that you can find on GitHub and it’s used to host podcasts, as you can see here. Now, it’s running in an on-prem VMware environment and consists of a frontend VM running on Apache Tomcat on Ubuntu, and a backend VM with MySQL also running on Ubuntu. And I want to migrate and modernize the app. So here’s what I’m going to do. We want to start by lifting and shifting the frontend VM into Azure. Now, as I mentioned, the backend database is running in MySQL on a Linux VM. And instead of lifting and shifting that, I’m going to migrate the data directly from in the VM, into Azure MySQL, a PaaS service, so that I don’t have to worry about managing that VM once the data’s in Azure. And finally, we’ll take the frontend VM from the first step and containerize it so that it runs as a container in the Azure Kubernetes Service. And this step is all about modernization and being able to take advantage of cloud native, scalable compute. And of course, that last step of containerizing the app, well, you can do that from anywhere. It doesn’t need to be currently residing in Azure. I just wanted to start by showing you a lift and shift VM-to-VM migration, because it’s probably where most people will start. So, I’m in Azure Migrate, I’ve already performed a VM discovery on my on-premises, VMware environment. And you can see we’ve got hundreds of Linux virtual machines here.
- Right. And by the way, if you want to see how that process works for Azure Migrate, we’ve got a complete step-by-step guide. So check out our recent show on Azure virtual machine migration using Azure Migrate. Now the process is the same by the way, for both Linux as well as Windows.
- Absolutely. So in my case, since I’ve already run the discovery, I just need to search for the VMs I want to migrate. So in this case, I’m going to search for Woodgrove, and you’ll see that these two VMs that make up our app both are running Ubuntu with two cores and four gigs of RAM. And if I click into software inventory, for this one you’ll see everything running in each machine. I can also see dependencies, which is all the TCP/IP traffic connecting to our VM. This way I can ensure I migrate everything I need to. Now looking at Port 3306, you’ll see my SQL server. And if I switch tabs to my assessment and click into assess Azure VM, then edit our assessment properties, you’ll see all of the options for basic properties, VM size and pricing. Now I’m going to close that and next, I’ll create an assessment using those two VMs. I’ll give it a name, AirsonicPAYG, pay as you go. Now I’ll create a group with my two VMs and I’ll call it Airsonic. Then I’ll search for Woodgrove again, select my two VMs and finally hit create assessment. Now, if I click into the assessment, you’ll see the details for Azure readiness, with cost details for storage and compute. And when I click into Azure readiness, I can also see the recommended VM size, in my case both the standard F1. If I click into cost details, you’ll see the cost estimates broken down by compute and storage. Now I can tweak all of these values, but everything looks good to me and we can start migrating.
- So now that you have the assessment complete, how do you go about doing the actual migration?
- Well, with Azure Migrate, you could move both these VMs and the tools even scale to thousands of VMs if you’ve got a load of apps. But in my case, I’m only replicating the one VM for the front end. So, I’m still in Azure Migrate and below the assessment tools are the migration tools. So I’m going to click into replicate. I’m going to choose my virtualization platform, in this case VMware, select my appliance and hit next. And here I could import my assessment to migrate. But since I just want to migrate the one VM, I’ll specify the settings manually. I’m going to search again for Woodgrove and choose the Airsonic frontend VM and hit next. And here I need to enter standard options in Azure as the target settings, like location, subscription, VNet, etc. Now to save time everything’s filled in, and so I’m going to hit next. Now I can choose my VM size and I’ll just pick a standard D2a_v4 and hit next. I’ll keep all selected in the disks tab, and hit next. And now I’m ready to replicate. So let’s go ahead and do that. That’ll save the contents of the VM into my storage account. And back on the Azure Migrate tab, you’ll see our replication has started. If I click into it I can test from here, but to save a step, I’m just going to go straight into Migrate. Select my server and hit migrate, and in just a moment, it’s now a running clone of my original VM. And as you can see, it’s running now in Azure. Here, I could just continue using the on-premise database if I needed to keep it on-prem, but I’d just need to make sure this VM could reach it, and then just redirect the app’s DNS settings to this new IP.
- Okay. So in this case, your app is still running, but now you’ve got the front end as a VM in Azure, but the database is left running as VM in your on-prem environment. So, how would I move the database then into Azure?
- Well, we’ve got tools that can help with that as well. So, instead of replicating and migrating as a VM, I’m going to convert it to the PaaS service. That way in the future, I don’t need to worry about managing that underlying VM. So let’s do that. We’ll use the Azure Database Migration Service to migrate our databases contents to Azure MySQL. Now DMS works for both MySQL and Postgres. The first thing I needed to do in this case was create a MySQL instance in Azure, which I have done in advance. Now in the MySQL workbench, I set up a tab for my source VMs database on-prem and one for my target in Azure. Knowing the source, I can see all of my tables, but in the target you’ll see there aren’t any tables. Now using the CLI I’ll run a MySQL dump against my source database. Enter the source database password. And with this command, I can see it’s already created a dump, and this is a pretty small database. Now I just need to import the dump I just created into our target database in Azure with this command containing the address. I’ll enter the target’s database password, and this is just copying a schema and a table structure over to the target instance, but not the data yet. And once my dump has moved into the target, I can go back to the my SQL workbench, and in the target database tab I’ll refresh and I can now see all of my tables are there. But they’re still empty, so let’s fill them. So next I’ll head over to the database migration service in Azure. I’ve already created a DMS instance in advance, but now I’ll create a migration project. I’ll give it a name, Airsonic test migration. I’ll choose the target server type and you’ll see additional options here, including Postgres and Mongo, but we’re using MySQL. And now I’ll hit create and run activity. It’s going to ask me for source details, server name or IP. I’ll enter the IP. I’m going to keep Port 3306 into my username, root, and my password, and then I’ll move to the target settings. So I’m going to paste in the server name, its address, my username, Airsonic admin and password. And now I can choose the databases I want to migrate. I only need to move the Airsonic one. So next, I’ll configure the migration settings and you’ll see DMS found our 36 tables. I’ll take a look at everything and keep all the tables selected and move on to the summary. And now I just need to give the activity a name, Airsonic migration 1, and hit start migration. Now I can monitor everything here, but since our database is only a little bigger than two MB, if I hit refresh, you’ll see it’s complete. Now, if I click into it, you’ll see my tables are all complete as well. So now, it’s up and running in our Azure instance. And if you have a large database, we’ve got super fast, parallelized, Azure DMS migration for MySQL, where we’ve been able to burst up to 188 GiB per hour, which is great to minimize the servicing window. And if you need to, you can even migrate deltas between the first and final migration. Now, finally, we would normally update the connection strings so our app knows about the new location of our database. But we’re going to wait, because I want to modernize the front end to run in containers, and that’s going to take just a few minutes. But this will also open up better scalability, and I won’t need to maintain the Ubuntu VM.
- So how do you repackage or convert then your front end VM and everything inside of it so it can run as a container in Azure without having to rewrite the app?
- So for that, I can use another tool from Azure Migrate called app containerization to containerize the front end VM without needing to rewrite the application. So under explore more in the Web apps to Container section, I’ll click into app containerization. And you’ll see this works with ASP.NET apps running in AKS and Java web apps running on Apache Tomcat. Now from there, I’ll download the tool and with it running, I’ll need to specify the app type, in our case, Java. I’m going to walk through the pre-recs and make sure SSH is enabled, then continue. And now I need to log in with my Azure credentials, select my tenant and subscription and continue. And now I can enter the IP address or fully qualified domain name of my server. And I’ll use the IP here and enter the username and password. Now, once I validate connectivity, I can continue and that will discover the apps running on my server, and you’ll see it found our Airsonic app. So I just need to select it and enter the target container, Airsonic V1. And here, I’ll take a look at the parameters. I’ll keep all of these settings and check all the boxes for username, password, and URL and click apply. Now I need to make a slight edit to the app folder location to map everything correctly. So I’ll add a new folder and enter the path. Then I’ll change the target storage to a persistent volume and save my changes. And now we can move on to the build. Now I just need to choose my Azure container registry and select my container. I’ll hit build. And after a moment, it succeeds. So now I can move on to deployment specifications, where I just need to select my AKS cluster called Contoso-AKS, and then continue. Now I’ll specify my file share with subscription, storage account, and the file share. Now to save time, I’ve configured these in advance. Now in the deployment configuration, I need to configure the app. So here’s where I can check the prefix string, ports, replicas, load balancer type, and I’ll keep what’s there, and enter my username, password, and the URL. I’ll keep the storage config as it is, and I’ll hit apply. And now we’re ready to deploy. So I’ll do that, and once it’s finished, I can click into the link here and see the public IP and the resources. And just to test this out, I’m going to go into kube control and run a get service command, and you’ll see our Airsonic containers running along with the external IP and port that we just saw. So now let’s try this in the browser. I’m going to paste in the address and there’s our app, and I’ll make sure everything works and it’s looking good. So now we’ve migrated our app into Azure and even modernized it to use MySQL PaaS and cloud native containers. So it’s going to be way more scalable and easier to manage.
- Okay. So now that your app is running in Azure, what are some of the other things that you can do?
- Well, there’s a lot. But to look at just a few highlights, firstly, there are a ton of options to take advantage of for high availability. So those start with VM options for availability sets and availability zones for redundancy, all the way to disaster recovery solutions to ensure your services are as resilient as you need them to be. Now moving OpenStack into the management layer, we’ve also integrated Linux and open source databases. So, all the scaling and elasticity in Azure works for Linux, such as virtual machines scale sets, diagnostics monitoring and software update management are all built in. You can use the Azure portal to manage all of the Linux-based services. And you can take advantage of proactive security with Azure Defender and the Azure Security Center to keep your infrastructure and your data protected. Plus, there are AI and ML capabilities that can be applied to your Linux stack, enhancing your application and workloads with cognitive services or machine learning services. And if your organization uses managed Linux services, we’ve worked closely with Red Hat and SUSE to offer unique, integrated support experiences where you can raise tickets and our support team will work with Red Hat or SUSE support teams to triage cases together. And in fact, Azure is the only cloud service doing that today.
- Right. And these are just a few examples of how Microsoft is working with the open source community. So Matt, if anyone is watching and they want to get started, what do you recommend?
- To find just about everything related to Linux running on Azure, check out azure.com/linux. And once you’re ready to test out a migration, you can get to Azure migrate at aka.ms/azuremigrate. And to find the tools to migrate your data stores, check out aka.ms/datamigration. We’ve also got a ton of learning content available on Microsoft Learn.
- Thanks Matt, for the comprehensive overview and look at what Microsoft’s doing with the open source community and also how you’d bring your open source apps into Azure. Of course, keep watching Microsoft Mechanics for the news and deep dives in the latest tech. And be sure to subscribe if you haven’t already, and thanks so much for watching.