On the heels of the recent announcement of Red Hat Linux becoming available on Azure, I feel like it’s the perfect time to share our recent experience delivering Red Hat Enterprise Linux (RHEL) solutions to our customers on Azure. If you’ve been around the industry for a while this may seem counterintuitive but there is actually robust support for Linux on Microsoft’s Azure cloud. Today, Azure provides endorsed VM images for the popular Ubuntu, the nascent CoreOS, Oracle Linux, SUSE/openSUSE, and CentOS via OpenLogic, but very conspicuously, no Red Hat Enterprise Linux. Microsoft supports these endorsed distributions and they even have a very capable Linux team which has been helpful in my experience. I’ve heard rumblings that as much as 40% of VM’s on Azure are running Linux – this clearly isn’t the Microsoft of old.
Azure has settled firmly into the number two spot in the cloud wars with Amazon’s venerable AWS still firmly out in front. They’ve become Amazon’s only real competitor by being the cloud that appeals to enterprise sensibilities. Microsoft has significant CIO mindshare and those CIO’s are quick to trust them with the cloud more readily than AWS in many cases, something Matt Asay highlighted in Info World earlier this year. If Microsoft’s software presence in the enterprise is a key cloud growth driver, then Red Hat, who’s products are along side Microsoft’s in nearly all the same organizations, is a natural extension.
This particular customer case involves a mid-sized enterprise with RHEL requirements and a strategic desire to adopt Azure as a cloud platform. This company’s IT leadership had been working on a strategic vision to leverage the cloud (they’re all doing this at this point), they trusted Azure as they’re subject to PCI-DSS compliance and other standards, use Active Directory, Exchange (some Office 365), and other Microsoft products, and had identified their QA environments as an optimal jumping off point. This is a really common scenario since initial cloud deployments are most successful with lower risk, non-production workloads. However, in this situation the customer’s production environment was running Red Hat 5x, a version for which the CentOS analog isn’t even supported on Azure, yet RHEL 5x was a hard requirement for the QA environment on Azure and thus dictated the relative success or failure of the cloud initiative.
Luckily, we run a substantial amount of Linux on Azure in addition to a 50/50 Linux/Windows split in our own data centers. This background gave us confidence that we could get RHEL 5x running and stable inside Azure. The first step was to construct a custom RHEL 5.11 Azure VM image to meet their specs and this is best done inside a Hyper V environment.
1. Creating Custom Linux VHD in Hyper V for upload to Azure
Microsoft has very good documentation as well as blog posts on building custom OS images for Azure, including instructions for some specific Linux distributions. A few things to be mindful of:
- Use standard partitions when installing RHEL and NOT LVM.
- Register the OS with RHN so you can use Yum and update key packages.
- You’ll likely have to install LIS 4.0.7 and not 4.0.11 as the latter doesn’t have an install package for RHEL 5.11.
- Azure requires OpenSSL v1.0+ which is not supported on RHEL 5. However, Azure is really looking for the Heartbleed patch that was part of OpenSSL 1.0 which was backported by Red Hat into 5x. You should be able to Yum Update OpenSSL and bring it to 0.9.8 with the correct patch levels that work with the Windows Azure Agent.
- Waagent requires Python 2.6 which is isn’t available on RHEL 5x. You’ll need to either use the EPEL repository or build your own rpm from source. My recommendation would be that you do the former.
2. Upload deprovisioned VHD to Azure
Once you go through the cleanup steps of the custom image and finalize everything with the ‘waagent –deprovision’ command (think sysprep for Linux), you’re ready to upload your VHD to Azure. You’ll want to make sure you create a container inside a storage account in Azure and then within that container with a valid DNS name. This will be the uri you point your VHD upload to.
Once you’ve got your storage account and container setup you can upload the VHD using Azure Powershell. Again, Microsoft has some great documentation on performing this action. Once Azure Powershell is all linked up to your Azure subscription the command is very simple:
Add-AzureVhd -Destination <BlobStorageURL>/<YourImagesFolder>/<VHDName> -LocalFilePath <PathToVHDFile>
3. Create Image in Azure From VHD and Deploy Initial VM
Once you have your VHD up there it’s pretty simple to create a new image from it. Once that image is created it’s available to you when you’re creating a new Virtual Machine from the Gallery. You’ll want to provision a VM with that image right away to make sure that the Waagent is interacting appropriately with Azure.
Azure Resource Manager Deployments
For enterprises to truly leverage the cloud’s scale and efficiency and not just ‘lift and shift VMs’, their environments need to be implemented with a cloud-native mindset. This means thinking about automation, thinking about resources as ephemeral, and right-sizing resources to fit needs knowing scale comes easy. With the custom RHEL 5.11 image operational on Azure it was time to fully implement their environment. Working with their internal infrastructure, network, app dev, and security teams, we put together the comprehensive requirements and implementation plan for for the QA environment. For enterprises to adopt the cloud, there needs to be a translation of enterprise security policies and standards to the cloud environment. We use Azure Resource Manager (ARM) to accomplish this.
With ARM we can build declarative JSON templates that define every aspect of the environment. Our customer has specific requirements around user access controls, subnet configuration, VPN configuration, as well as the desire to have workloads spin up and down on a schedule to control costs. Our team took their requirements and built out ARM templates that defined their unique requirements and brought them a level of deployment consistency they don’t even have in their own data center. For our customer to deploy an entire multi-tier, AD integrated, and compliant QA environment, all their infrastructure team needs to do is run a single Azure Powershell command. Additionally, we have tools that capture logs of these processes and enforce the consistency in policy and configuration.
The Business Case
This has been an interesting technical case study in that we worked around dependencies and other technical issues to get a clean and certified version of RHEL 5.11 running and stable on Azure but that obscures how transformative this deployment is to the existing business.
- QA environment spin-up went from days to hours.
- Not only are they not having to buy and maintain hardware but the cloud resources they’re now using are right-sized and they’re using automation to ensure the servers are running only when they need them.
- With ARM and the automation we’ve built for them they actually have more consistency in their cloud environment in Azure than they do on premise.
- The speed and cost savings has funded other innovative projects which solidifies the cloud business case.
Companies don’t need to adopt a micro-services architectures or be running the latest software to reap the benefits of cloud transformation. Viewing the cloud as simply a new, modestly less expensive, place to put virtual machines obscures the fact that those cost savings pale in comparison to those arising from automation, agility, consistency, and the ability to coordinate complex infrastructure operations faster than ever. Gaining an orientation around the cloud beyond new virtual machines, a cloud-native orientation, if you will, is a key factor in extending cloud transformation to business success.
