Good things come in many flavors, and so do Linux distributions.

To create a successful cloud migration plan, you need a good understanding of the components and variables of the system that you want to migrate to the cloud.

In this chapter, you will learn about the relevant terminology and technical details of various Linux distributions to help you plan successful migrations to Azure. Even though all the distributions are based on the same operating system, each of them has its own small technical details that require detailed knowledge to successfully prepare for a migration. Along with the introduction to the distributions, we will have a look at the licensing options, as well as the differences between free and commercial open-source software. Commercial Linux distributions have various add-on features and support options. We will also cover some typical use cases for different distributions.

The final section of this chapter is Linux on Azure, and it starts with a discussion of the Microsoft-endorsed distributions and the scope of support provided by Microsoft. The support is shared between Microsoft and the Linux vendor. We will also cover the licensing models in Azure for Linux virtual machines and what the potential savings for the customer are with each model. We will conclude this chapter with a demonstration using the Azure CLI to find details on VM images; this is useful if you want to see a list of available images on Azure.

This chapter will cover the following topics:

• Linux licensing and open-source business models
• Popular Linux distributions
• Linux on Azure: benefits, licensing models, support

By the end of this chapter, you will have learned the necessary tips and tricks for moving Linux subscriptions to the cloud. Let's start our discussion by exploring Linux licenses.

This section focuses on commercial Linux distributions. If you are using only free community editions of Linux, such as CentOS or Debian, some of the content may not be applicable to you.

Open-source licenses

How do you make money from something that is free? To answer that, we must look back and see what it means when we say something is open source.

Linux distributions and the Linux kernel are open source, but at the same time, they are covered by copyright laws. To make things very complicated, there are numerous open-source licenses covering different parts of a Linux distribution. Some components may be covered by a GNU General Public License (GPL), some by an Apache License (APL), and some by an MIT license. To make this even more complex, it is important to realize that there may be multiple versions of the same license and that they may not all be compatible with each other or with any other license whatsoever.

At this point, it is enough to understand that all Linux distributions are covered by an open-source license. This means you have the right to download the source code of all the software included in a Linux distribution. What you can do with the source code is out of the scope of this book, since we are not creating our own Linux distributions. In this book, we do not have to go into the details of various open-source licenses and copyright laws.

Enterprise agreements

When talking about commercial open source, and specifically commercial Linux distributions, the term enterprise agreement is something you will need to familiarize yourself with before thinking about moving your Linux servers to Azure. We might often skip reading the terms and conditions of such agreements before accepting them with a simple click of a mouse, but it's important to read them.

An enterprise agreement for commercial Linux vendors typically states that you agree to pay to use their software according to their latest price lists and to follow the rules of where and how you can use the software. It also says many other things, but since this is not a software procurement book, we will not go into those details. However, it might make sense for you to have a conversation with your software purchasing team to check if they know the contract details.

Linux subscriptions

What proprietary software vendors call "licenses" can be loosely referred to as "subscriptions" in the Linux world. Technically these are, of course, two different things, but in a typical sales conversation, you may hear someone talk about Linux licenses—and as we learned earlier, those are not the licenses you are looking for.

Subscription practically means the right to download, use, and update a commercial Linux distribution. It very often also comes with a technical support service with varying service level agreements. In order to subscribe to such a service, you will need to sign a contract with a commercial Linux vendor on behalf of your employer. This contract is usually referred to as an enterprise agreement, and it typically comes with some additional obligations. One of these obligations is to follow the rules of the service subscription agreement.

For example, the subscription rules for Red Hat Enterprise Linux state that you may only use the software on your own infrastructure. Practically, this also includes hosted environments, which are considered rented infrastructure. Public clouds are not considered as your own infrastructure and you will need to inform Red Hat if you want to move your Linux servers to the public cloud.

SUSE has very similar subscription rules. As mentioned, it is a very good idea to check the contracts with your software purchasing department to ensure that you are following the rules.

With Ubuntu, the concept of subscriptions is a bit different; you do not need a subscription to use it at all. In this case, the subscription refers to a professional support service contract from Canonical, the company behind Ubuntu. In addition to the free Ubuntu Linux, Canonical also offers Ubuntu Pro, their commercial Ubuntu image on Azure.

Figure 2.1 illustrates the differences between licenses, subscriptions, and support contracts of commercial and community Linux distributions:

Figure 2.1: The differences between licenses, subscriptions, and contracts

Enough of licenses and subscriptions. Let's take a look at the actual Linux distributions.

Various Linux server distributions have gained quite a stable market share over the years. Corporate users usually standardize on one or two distributions depending on the business applications they use. Red Hat and SUSE are the two most famous enterprise Linux development companies and vendors and they both have similar offerings around the Linux operating system area. Nowadays, the third commercial Linux vendor, Canonical, is playing in the same category. Their Ubuntu Linux used to be best known as a developer workstation distribution, and it has quickly gained popularity as a production server operating system as well. Coupled with Canonical's commercial support offering, Ubuntu Linux is a great alternative to the two leading enterprise Linux distributions.

Red Hat was founded in 1993 when Bob Young and Marc Ewing joined forces and created Red Hat Software. In 1999, Red Hat went public on the New York Stock Exchange (NYSE). Before its acquisition by IBM in 2019, Red Hat had acquired dozens of small open-source companies, such as Cygnus (cross-platform tools), JBoss (Java middleware), Qumranet (the creators of KVM virtualization technology), Makara (a PaaS platform, the first version of OpenShift), ManageIQ (a hybrid cloud orchestrator, the first version of CloudForms), InkTank (the creators of Ceph storage technology), Ansible (a popular automation toolkit), and CoreOS (a small Linux distro for containers).

The complete acquisition list consists of more than 30 companies that most of you have probably not heard of, since the brands have been merged with Red Hat's other product lines. Red Hat Enterprise Linux (RHEL) is a very popular platform nowadays, especially for Java middleware JBoss products, as is the commercial Kubernetes packaging, OpenShift, since both are published by Red Hat as well.

SUSE was founded a year before Red Hat, in 1992, and became the first company to market Linux to enterprise customers. Rolard Dyroff, Burchard Steinbild, Hubert Mantel, and Thomas Fehr first named the company Gesellschaft für Software und Systementwicklung mbH and used the acronym SuSE, which came from the German phrase Software- und System-Entwicklung, meaning software and systems development. The first version of their product was an extension of the then-popular Slackware Linux distribution. In 1996, they released their first Linux distribution, based on the already-forgotten Linux distribution Jurix, and deviated from Slackware.

Over the years, SUSE has been acquired and changed names several times, most notably by Novell in 2003 and EQT Partners in 2018. SUSE itself acquired Hewlett Packard Enterprise's (HPE's) OpenStack and CloudFoundry assets in 2017, as well as Rancher Labs—a company known for its Kubernetes management platform—in 2020. Today, SUSE Linux Enterprise Server (SLES) is a very common platform for SAP system deployments.

For non-commercial use, it seems like Ubuntu is the clear winner if you look at the number of deployments. Ubuntu is based on Debian, once a very popular Linux distribution for server workloads.

CentOS, being fully compatible with RHEL, is also popular since it's typically used by RHEL professionals on their hobbyist projects and other work that doesn't have an enterprise-level budget available.

Over the years, there have been many popular Linux distributions for desktop use, but they have not gained popularity on server use cases. We will not be covering those in the scope of this book since Linux on Azure usually refers to using server operating systems.

In the next section, we will go into the details of using free and commercial Linux distributions on Azure, with a particular focus on RHEL, SLES, and Ubuntu Pro. However, most of the content is applicable to their free versions CentOS, openSUSE, and Ubuntu as well.

In Chapter 1, Linux: History and future in the cloud, we mentioned that Microsoft came up with the motto "Microsoft ♡ Linux." On Azure, Linux mainly refers to the different Linux distributions that are supported on Azure. Microsoft Azure supports common Linux server distros including RHEL, CentOS, Ubuntu, Debian, SLES, openSUSE, Oracle Linux, and Flatcar Container Linux. You can find the up-to-date list and much more about Linux on Azure at this landing page: https://azure.com/linux.

If the operating system that you are looking for is not on the list or you need to have a customized or pre-configured image, feel free to visit Azure Marketplace where you can browse through hundreds of images that may suit your requirements.

If the Azure Marketplace images do not meet your organization's standards or requirements, you can create and upload your own images to Azure:

Figure 2.2: Azure Marketplace

Figure 2.2 is a view of Azure Marketplace, showing some of the different types of pre-configured images that are available.

Benefits of Linux on Azure

Deploying in the cloud is no different from what you are used to on-premises; you will be able to work with the Linux OS in the cloud in the same way as with an on-premises server. You can use the commands and tools that you are already acquainted with and add more packages as required.

You can use out-of-the-box features such as cloud-init, Azure Automation Runbooks, and Azure Custom Script Extension for Azure Resource Manager templates to automate configuration management during the deployment phase itself. By using these tools, administrators will be able to save time that would have been spent on lengthy and repetitive configuration management tasks.

As the environment is already set up and ready to log into, you do not have to go through the lengthy installation process that you used to do in the case of on-premises hypervisors while creating VMs. The credentials will be supplied during the Azure VM creation and, once the VM is deployed, you can log in and start using the VM.

Since all deployments are integrated with Azure Monitor, you can monitor all the metrics associated with the VM, such as CPU usage, disk write, disk read, network out, network in, and so on. Azure exposes the Metrics API, so you can further utilize the developed dashboards to monitor the metrics of your mission-critical workloads. Along with the metrics, Azure provides an agent that can be installed on your Linux VMs known as the OMS agent. Using this agent, you can ingest syslogs, auth logs, and custom logs such as Apache logs to an Azure Log Analytics workspace. Once the data is ingested, you can use the Kusto Query Language (KQL) to analyze the logs.

From a security standpoint, you can improve the security posture of your infrastructure using Azure Security Center. Azure Security Center can detect threats and provide policy insights and recommendations for your deployments.

Additionally, we can now make use of Azure Active Directory Login for Linux VMs. This eradicates the management overhead and security risk of managing local user accounts on each Linux machine; users can sign in to Linux VMs with their corporate credentials.

From this non-exhaustive list of advantages, we see that Linux on Azure offers the best of both worlds; you get all the customization features of Linux and at the same time all the features and benefits provided by Microsoft Azure.

Linux on Azure is very generic; the "on Azure" suffix can apply separately to each distro. For example, you should take "Red Hat on Azure" to mean all the Red Hat products that are supported on Azure. You might think RHEL is the only offering from Red Hat that is available on Azure, but you can also find other products such as Azure Red Hat OpenShift, Red Hat JBoss Enterprise Application Platform, Red Hat Gluster Storage, Red Hat OpenShift Container Platform, Red Hat CloudForms, and Red Hat Ansible Automation. You can see that all the major product lines of Red Hat are available on Azure; this is a clear example of how large organizations promote their products to Microsoft Azure. You will see similar approaches from other vendors, as in "SUSE on Azure" and "Ubuntu on Azure," which stand for the products supported by the respective vendors in Azure.

Note

Check out the product lines available on Azure for the following vendors:

• Red Hat product lines available on Azure: https://Azure.com/RedHat
• SUSE product lines available on Azure: https://Azure.com/SUSE
• Ubuntu on Azure: https://Azure.com/Ubuntu

Microsoft recommends using endorsed Linux distributions in Azure to host your production workloads. The rationale for this is that all endorsed images are maintained by the most well-known Linux vendors in the world, such as Red Hat, Canonical, SUSE, and so on; basically, endorsed images are images published by these vendors. The complete Linux support matrix can be reviewed at https://docs.microsoft.com/troubleshoot/azure/cloud-services/support-linux-open-source-technology#linux-support-matrix.

You can also bring your own images to Azure if you do not want to use an endorsed image. You may even customize Azure images using the Azure Image Builder tool, which is based on Hashicorp Packer: https://docs.microsoft.com/azure/virtual-machines/image-builder-overview.

One key point to note here is that Microsoft provides support to endorsed distributions only. Having said that, let's take a look at how the technical support for Linux on Azure is arranged.

Linux support scope

Microsoft provides support for the endorsed Linux distributions on Azure, and if there is a need to engage the vendor, they will be engaged on your behalf depending on the scenario. For example, if there is an issue with the image of Ubuntu 18.04 LTS and Microsoft cannot fix it, they will engage Canonical (the publisher of Ubuntu) to check the scenario. Here are some of the key points that you should keep in mind when engaging Microsoft Support.

Microsoft's technical support team can help you mainly in Linux troubleshooting scenarios—for instance, if you are unable to connect to a Linux VM with SSH, or unable to install a package. The Linux vendor may have to be engaged for issues related to the Linux image itself. For this Microsoft has joint support and engineering agreements with Linux vendors such as Red Hat, SUSE, and Canonical.

Always get your Linux administrator involved while working with Microsoft Support. In most troubleshooting scenarios, you might need superuser (often referred to as sudo) permissions, which only the admins will have.

Linux offers more room for customization than any other operating system available. Some organizations use custom Linux kernels or modules that cannot be supported by Microsoft Support. Although kernel-related issues are resolved by collaborating with the Linux vendor, in this scenario, even the vendor may not be able to help as they can typically only support the official kernel versions published by themselves.

Azure Advisor and Azure Security Center provide different security-, cost-, high availability-, and performance-related recommendations for our workloads. Following these recommendations is one of the best practices to run your workloads effectively on Azure. However, for performance tuning and optimization, customers may need to contact the vendor for resolution.

As mentioned earlier, Microsoft Support helps you to troubleshoot issues. This applies to the free Azure support, which is officially called "Basic" and is included for all Azure customers. If you need help to design, create architecture, or deploy applications on Azure, you have the option to purchase additional support, which ranges from development support to business-critical enterprise support plans. The paid plans include various levels of design and architecture support, and you can read more about them here: https://azure.microsoft.com/support/plans/.

Another option to get help with Azure design, architecture, and other technical questions is to engage with Microsoft's sales and partner teams, namely the Customer Success Unit (CSU) and One Commercial Partner (OCP). These teams are able to assist named commercial customers and partners. It is good to remember that these organizations are not replacements for Microsoft Support but are part of Microsoft's Global Sales and Marketing organization. To get in touch with the technical staff of the CSU and OCP teams, you should contact your named Microsoft account manager.

A third and very popular option is to talk with the large network of Microsoft partners. They are able to provide a broad range of advisory, consulting, implementation, and operational assistance for Azure in general as well as Linux on Azure. Many of these partners are also partnered with some of the Linux vendors mentioned in this chapter. The easiest way to locate Microsoft partners is to use the Microsoft solution provider search tool: https://www.microsoft.com/solution-providers/home.

Note

Along with the endorsed Linux distribution support, Microsoft also provides production support for certain OSS technologies such as PHP, Java, Python, Node.js, MySQL, Apache, Tomcat, and WordPress. This list is subject to change and the technical support available may be very limited.

Now that we are familiar with the scope of Azure Technical Support, let's look at how pricing works on Azure.

Licensing on Azure

In Azure, there are three licensing models: pay-as-you-go (PAYG), Azure Hybrid Benefit, and prepay. We will look at how these models vary and what the benefits are, starting with the PAYG model.

The pay-as-you-go model

As the name implies, in the PAYG model, customers are charged for the license as they use resources. For example, if you run a VM for 12 hours, you will see charges for:

• 12 hours of compute (which includes vCPU, RAM, and so on).
• 12 hours of Linux "license" or "subscription" use (if you are using distros such as RHEL or SLES that require a paid subscription).
• The cost of a public IP address (if needed).
• The cost of egress network traffic.
• The cost of storage.

Usually, in the Azure Pricing Calculator (https://azure.microsoft.com/pricing/calculator/), when you select a Linux VM that is running RHEL or SLES, you will be able to see the license cost. If you are using Ubuntu/CentOS, there will be no license cost. In Figure 2.3, you can see that for an RHEL VM there are compute and license costs under PAYG. The calculation is for 730 hours of consumption:

Figure 2.3: Licensing cost for RHEL from the Azure Pricing Calculator

On the other hand, if we pick Ubuntu/CentOS, the license cost will not be there, as shown in Figure 2.4:

Figure 2.4: Licensing cost does not apply to Ubuntu

To summarize, in PAYG, customers pay based on how long a VM runs. When the VM is deallocated, the compute cores are not utilized, which means no charges are incurred for compute cores or the license. This model is ideal for VMs that are deployed for testing and will be running for a short period of time, but if you have VMs running 24/7/365, this might not be the ideal model, as the license cost will keep on accumulating based on hours used. In these cases, it is better to go with the Azure Hybrid Benefit or prepay plans for potential savings.

Azure Hybrid Benefit

If you revisit the screenshot of the pricing calculator in Figure 2.3, you can see another option under Software (Red Hat Enterprise Linux), one that reads Azure Hybrid Benefit. Previously, Azure Hybrid Benefit was referred to as a licensing benefit available for Windows Server and SQL VMs by which customers can bring their own Windows Server and SQL licenses to Azure. Using this method, the licensing cost is nullified, and customers can utilize the licenses that they had already purchased from their software assurance or volume licensing. In November 2020, Azure Hybrid Benefit was made generally available for Linux.

Using Azure Hybrid Benefit, you can migrate your existing RHEL and SLES servers to Azure with bring-your-own-subscription (BYOS) billing. Normally, in the case of the PAYG model, you pay for both infrastructure (compute + storage + network) costs and software (license) costs. Since you are bringing your own subscription here, though, the software cost is nullified, and you pay only for the infrastructure, which drastically reduces the cost of hosting in Azure. You can convert your existing VMs under the PAYG model to BYOS billing without any downtime, which also means that the redeployment of these services is not required at all. When your BYOS expires, you can convert these VMs back to the PAYG model as required.

All RHEL and SLES PAYG images on Azure Marketplace are eligible for Azure Hybrid Benefit. However, if you are choosing a custom image or any RHEL/SLES BYOS images from Azure Marketplace, those are not eligible for the benefit.

Red Hat customers can follow the instructions below to get started with Azure Hybrid Benefit. Before we start, there are some prerequisites:

• You should have active or unused RHEL subscriptions that are eligible for Azure usage.
• You should have enabled one or more active or unused subscriptions for Azure usage with the Red Hat Cloud Access program. Red Hat Cloud Access is a program offered by Red Hat. Using this, you can run eligible Red Hat product subscriptions on Red Hat certified cloud providers such as Microsoft Azure, Amazon Web Services, and Google Cloud.

If you meet the prerequisites, the next step is to start using Azure Hybrid Benefit. Here are the steps you need to follow:

1. Choose one of the active or unused RHEL subscriptions and enable it for use in Azure. This is done from the Red Hat Cloud Access customer interface. Red Hat customers will be able to access this by logging in to https://www.redhat.com/technologies/cloud-computing/cloud-access. Only the subscriptions we enroll here are eligible to use Azure Hybrid Benefit.
2. Linking the subscription was the primary step; we can specify that the VMs use the RHEL subscription during the creation stage, or we can convert existing VMs.
3. During the creation of the VM, you can opt to use the existing RHEL subscription as shown in Figure 2.5:
   

   Figure 2.5: Enabling Azure Hybrid Benefit during VM creation

4. We can also convert existing VMs to Azure Hybrid Benefit without the need to redeploy. This can be achieved from the Configuration pane of the VM as shown in Figure 2.6:

Figure 2.6: Converting existing VMs to Azure Hybrid Benefit

Once this process is complete, in your Azure usage, you will see that the cost for the VM has dropped significantly. The process of attaching the RHEL subscription to Azure VMs can be done from the CLI and ARM templates as well if you would like to do this programmatically.

As mentioned earlier, customers have the freedom to switch back to a PAYG model whenever their RHEL subscriptions expire. Conversion back to the PAYG model is also done via the Configuration pane of the VM.

For SUSE customers, the process of attaching is pretty much the same; however, registration for using SUSE subscriptions is done via the SUSE Public Cloud program.

This model is ideal for customers who have active or unused RHEL or SUSE subscriptions that they purchased from the respective vendors and who would like to utilize these in the cloud for potential savings over the PAYG model.

In this model, we were using the subscription that we purchased from Red Hat or SUSE and attaching it to use with our Azure subscription. However, in the prepay model, which we are going to cover next, we will be purchasing Red Hat or SUSE software plans directly from Microsoft.

Prepay for Azure software plans

The final option under Software (Red Hat Enterprise Linux) in the Savings Options section of the Azure Pricing Calculator is 1 year reserved. Figure 2.7 demonstrates the 1-year software plan being selected for Red Hat:

Figure 2.7: Calculating a software plan cost from the Azure Pricing Calculator

In this model, customers can buy software plans directly from Microsoft for a term of 1 year and they can also renew if required by term-end. One catch here is that the plan amount should be paid upfront. In Figure 2.7, you can see that this has been mentioned in the cost; the moment a customer purchases a software plan from Azure, that charge will be added to the next invoice as an upfront cost for the next year.

Another key point to keep in mind here is that cancellation or exchange of these plans is not allowed. This means you should be buying the right plan for your workload. For example, if your product is SLES Priority for 2-4 vCPUs, you should purchase SLES Priority for 2-4 vCPUs. If you were to purchase SLES for HPC 1-2 vCPUs instead of SLES Priority for 2-4 vCPUs by mistake, then you would not get the benefit and you would not be able to return or exchange this plan. A piece of advice here is to understand your workload and buy accordingly.

The software plan can be purchased from the Reservations pane in Azure, the very same place where we purchase reserved instances for Azure VMs, databases, and so on. The benefit will be applied automatically to the matching workload and no mapping is required.

For instance, if you have three SLES Priority instances, each with 4 vCPUs, then the right plan for you is SLES Priority for 2-4 vCPUs. Depending on the quantity you purchase, the discount is applied automatically to the instances. Assume that we purchased two SLES Priority for 2-4 vCPU plans; then, two out of three VMs will get the benefit and the remaining one will remain in the PAYG model. If you need the third one's cost also covered by the plan, then you need to buy another plan of the same kind. This new plan will automatically attach to the remaining VM.

Like Azure reserved instances, the software plans are a "use it or lose it" benefit. This means that if you deallocate all your VMs and the plan is not able to find a suitable VM to attach to, the benefit will be in vain. You cannot carry forward the unused hours.

Note

You can avoid losing the benefit in the case of a migration by opening a billing support case on the Azure portal.

You should always do proper planning for your workloads before buying software plans to ensure that the most cost-effective plan is selected. Reiterating some of the considerations that we should be keeping in mind:

1. The plan is ideal for 24/7/365 workloads; other servers need a billing support change request. If the plan is not able to discover the appropriate SKU, the utilization of the plan will be zero and you will lose a benefit.
2. No return or exchange is possible. Buy the right plan based on the product and vCores your VM has; buying the wrong plan or the wrong number of CPUs will result in a loss of money.
3. For SUSE plans, only certain SLES versions are supported. Make sure you check the version you are running using the cat/etc/os-release command and match with the documentation available here: https://docs.microsoft.com/azure/cost-management-billing/reservations/understand-suse-reservation-charges#discount-applies-to-different-vm-sizes-for-suse-plans.
4. The plan's costs are upfront and will appear on your next invoice.

In the next section, we will conclude the licensing part of the chapter with a helpful comparison of these licensing models and their benefits.

Savings comparison of licensing models

In the previous section, we saw the different types of licensing models that are available for your Linux workloads in Azure (refer to Chapter 1, Linux: History and future in the cloud). Here, we are going to make a comparison from the perspective of a customer and look at the savings percentage for each model.

For demonstration purposes, we will be using the cost of an RHEL D2v3 VM running in East US for 730 hours in US dollars. At the time of writing, the cost of the software is $43.80 and $35.00 per month for the PAYG and prepay software plan models respectively. We are not taking into account the Azure Hybrid Benefit monthly charge as this subscription is bought from the respective model. If you are already partnered with Red Hat or SUSE, you could get some discounts on these subscriptions. Now let's do the math; Table 2.1 shows the cost per month for each model:

Table 2.1: Azure licensing model comparison

If we plot these values on a graph and calculate the savings percentage for a year, we will get a graph like the one shown in Figure 2.8:

Figure 2.8: Calculating savings for licensing models

The value may look small, but this is only for a single VM; in an enterprise environment where there will be thousands of VMs, the potential savings are very high.

Each model has its own use case scenarios:

• PAYG is ideal for testing or development where you are not planning to keep the VM running 24/7.
• Azure Hybrid Benefit is appropriate if you have license subscriptions from Red Hat or SUSE and would like to use them in the cloud.
• Prepay software plans are perfect for customers who do not have RHEL or SUSE subscriptions and would like to get some discounts on the software cost. However, this is a long-term commitment with Microsoft.

Using Azure Reserved Instances, customers can also get a discount on the compute cost. In short, if you combine Azure Hybrid Benefit or a prepay software plan with Azure Reserved Instances, the overall savings percentage will be boosted to 50-70%. You can read more about Azure Reserved Instances for VMs here: https://docs.microsoft.com/azure/cost-management-billing/reservations/save-compute-costs-reservations. As this is not a licensing model, but more of a cost optimization technique, we will not cover this topic in this chapter. However, when we discuss assessment and migration in Chapter 3, Assessment and migration planning, we will discuss how to optimize cloud costs.

Now that we are familiar with the licensing models, let's see how we can use the Azure command-line interface (CLI) to find the versions of available distros.

Available distros

In the introduction of the Linux on Azure section, we saw that Microsoft Azure supports common Linux distros such as Red Hat, Ubuntu, SUSE, CentOS, Debian, Oracle Linux, and CoreOS. We also saw how we can make use of Azure Marketplace to find the appropriate image as per our organization's requirements. Table 2.2 displays the endorsed distros and the vendors/publishers who are providing these images:

Table 2.2: Endorsed Linux distributions on Azure

Though generic version numbers are given in the preceding table, it is very easy to find the image name and version from a publisher using the Azure CLI. In order to use the Azure CLI, we need to install it on our workstation. The Azure CLI can be installed on Linux, Mac, or Windows systems. If you are using the Cloud Shell in the Azure portal, by default the Azure CLI is installed for you.

Assuming that we are using a local computer (an Ubuntu computer, for example), we need to install the Azure CLI. You can find the specific installation steps depending on your operating system here: https://docs.microsoft.com/cli/azure/install-azure-cli. For simplicity of demonstration, we will install the Azure CLI on an Ubuntu instance:

1. Microsoft has developed a script to run the installation in a single shot, which makes it convenient for beginners to ramp up quickly. If you prefer to perform this step by step, the Microsoft documentation has instructions for that as well. For Ubuntu, the installation can be done using the following command:

   curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash

   The output is shown in Figure 2.9:

   

   Figure 2.9: Azure CLI installation on Ubuntu

2. The next step is to log in to our account from the Azure CLI in order to connect our Azure account to the Azure CLI. This can be accomplished by running the az login command. The console will prompt you to open a browser window and provide a code to complete the authentication process, as shown in Figure 2.10:
   

   Figure 2.10: Logging in to Azure using the Azure CLI

3. In a browser window, you must enter the code shown in the terminal (as shown in Figure 2.10) and sign in using your credentials. Once signed in, the terminal will show all the subscriptions you have access to, as seen in Figure 2.11. If you do not want to authenticate using the code, you can log in using a service principal where you will be using the client ID and client secret as the username and password, respectively. Also, you can use Managed Identity if required:
   

   Figure 2.11: Logged in to Azure

   Now we will see how we can get information on the available VM images. The primary command used here is az vm image.

4. To list the images (offline) for the VMs/VMSSs that are available on Azure Marketplace, you can use az vm image list. The response will be in JSON and we can format it to a table by appending the -o table parameter to the command. This will list offline cached images as shown in Figure 2.12:
   

   Figure 2.12: Listing the VM images available

   To update the list and display all images, you can append the –all parameter to the command and call the command again.

   The preceding command may take a minute or two to refresh the list of all available images. Usually, when we query the image list, it is recommended to use the publisher or SKU or offer parameters, so that the search is limited to a set of images and the results can be retrieved very easily.

   In the next steps, we will be seeing how we can find the publisher, offer, or SKU for an image and use it in our az vm image list to narrow down the search.

5. In order to find the list of all publishers, we can use the az vm image list-publishers command. Location is a required parameter here, as some publishers publish only to a specific region, so it's recommended to check that the publisher has published to the region you are planning to deploy to. The following is the output:
   

   Figure 2.13: Listing publishers in a region

6. For example, the publisher for Ubuntu is Canonical. If we want to list all the offers provided by this publisher, we can use the following command:

   az vm image list-offers -p Canonical -l eastus -o table

   Here the location is a required parameter, as offers may vary depending upon location. The output will be similar to the one shown in Figure 2.14:

   

   Figure 2.14: Listing images from the Canonical publisher in East US

7. Let's pick an offer; for instance, UbuntuServer. Now we need to list the SKUs to find the available SKUs for the image. We need to pass the publisher, offer, and location to the az vm image list-skus command in order to list the SKUs. The aforementioned parameters are mandatory for this command, so the final command will be as follows:

   az vm image list-skus -l eastus -p Canonical -f UbuntuServer -o table

   The output is as shown in Figure 2.15:

   

   Figure 2.15: Listing SKUs available for the Canonical UbuntuServer offer in East US

8. Now we know the publisher, offer, and SKU. Let's use these values in the az vm image list command to see the available versions of an image. Here we will be using Canonical as the publisher (-p), UbuntuServer as the offer (-f), and 19_04-gen2 as the SKU (-s). Combine these and call the following command:

   az vm image list -p Canonical -f UbuntuServer -s 19_04-gen2 --all -o table

   This will list the image version available for the specified publisher, offer, and SKU combination. The following is the sample output:

   

   Figure 2.16: Listing versions of an image for a specific publisher, offer, and SKU combination

9. We can use urn from the output in the az vm image show command to get the details of the VM image as shown in Figure 2.17:
   

   Figure 2.17: Finding VM image details

10. The same urn can be used in our az vm create command to create a VM with that particular image version. A quick illustration has been given in Figure 2.18:
    

Figure 2.18: Creating a VM using URN

Before we conclude, please check Table 2.3, which lists all the commands we used in the preceding steps for quick reference:

Table 2.3: Commands used for the hands-on exercise

In this hands-on exercise, we queried the image list to find the available images and created a VM using that. We learned how to narrow down the search using parameters such as publisher, offers, and SKU.

Although we used the Azure CLI to accomplish this task, if you are using PSCore or PowerShell, you can make use of the Azure Powershell module to perform the same operations. The documentation for this is available here: https://docs.microsoft.com/powershell/module/az.compute/get-azvmimage?view=azps-5.2.0.

With that, we have reached the end of this chapter, and we will now summarize the topics we have discussed so far.

In the first chapter, we learned that there are different distros or flavors of Linux available depending on the user requirements. This chapter was more of an overview of popular Linux distributions and how Linux on Azure works. We also talked about commercial and free open-source software.

There are several advantages to using commercial distributions of Linux. Since we are paying for these subscriptions, it is expected that they provide additional features that are not found out of the box in free distributions. These add-ons include support, extra modules, and extended customization options. This chapter threw light on these areas as well.

We looked closely at Linux on Azure. We started off with Azure Marketplace and the plethora of images it has. After that, we introduced the term "endorsed distributions"; this is where Microsoft works with different vendors such as Red Hat, Canonical, and SUSE to bring their Linux images to the cloud. Microsoft recommends using an endorsed image for your production deployment. We also discussed the technical support matrix and the scope of support given by Microsoft Support. We saw some scenarios where vendors need to be engaged for the resolution to a problem.

After covering the Linux distros on Azure, we talked about the licensing models available in Linux and which one is best for you depending on the type of deployment. We also plotted a graph to portray the potential savings in each of the models. The last part of the chapter was more hands-on, where we saw how we can use the Azure CLI to find the different VM images available on Azure. However, the range of choice does not stop here; if you are not able to find the image you are looking for, Azure allows you the freedom to bring your own image.

Linux on Azure is an extensive topic and there are many books that clearly discuss how Linux administration can be done on Azure. This book is geared more toward the migration and assessment of Linux workloads. The licensing models and distros were explained to help you understand how things are done in the Azure realm.

In the next chapter, we will start to talk about migration. Many organizations begin to move to the cloud without proper assessment or planning. Planning and assessment are the cornerstones of migration and they need to be done properly before moving to the cloud. The planning phase is more about getting to know the capacity and checking prerequisites, while assessment is done using assessment tools to verify whether your workloads are ready for Azure or if they need any sort of refactoring first. With that said, we will talk more about these strategies and steps in the next chapter. Keep on reading!