Linux on Azure

Understanding Linux on Azure

Azure is Microsoft’s cloud platform, but Linux is a first‑class citizen there. Most of the Azure services you’ll use as a Linux admin or DevOps engineer work the same way across distros, but there are Azure‑specific tools and patterns that are important to know.

This chapter focuses on:

• How Linux fits into Azure’s compute model
• Azure‑specific agents and extensions for Linux
• Common deployment and management workflows
• Storage, networking, security, and monitoring considerations particular to Linux VMs on Azure

You should already be familiar with general cloud concepts from the parent chapter “Cloud Computing with Linux.”

Common Azure Linux Use Cases

You’ll typically see Linux on Azure used for:

• Web and API hosting: Nginx/Apache, Node.js, Python, Go, Java apps on:
• Azure Virtual Machines (IaaS)
• Azure App Service for Linux (PaaS)
• Azure Container Apps or AKS (Kubernetes)
• Containers and orchestration:
• Azure Kubernetes Service (AKS) running Linux nodes
• Container Instances or Container Apps using Linux images
• Data and analytics workloads:
• Self‑hosted databases (PostgreSQL, MariaDB)
• Big data stacks (Hadoop/Spark) on Linux VMs or HDInsight (Linux‑based)
• DevOps and CI/CD agents:
• Self‑hosted runners/agents on Linux VMs or containers (GitHub Actions, Azure DevOps)

From an OS perspective, you’re mostly dealing with standard Linux distributions, just running in Azure’s environment.

Supported Linux Distributions on Azure

Azure supports many Linux distributions with validated images in the Azure Marketplace. The most common:

• Ubuntu (Canonical) – very popular for general workloads and AKS nodes
• Red Hat Enterprise Linux (RHEL) – common in enterprises with RHEL support contracts
• CentOS Stream / AlmaLinux / Rocky Linux – RHEL‑compatible community distros
• SUSE Linux Enterprise Server (SLES) and openSUSE
• Debian
• Oracle Linux
• Specialized images (security‑hardened, preconfigured app stacks, etc.)

Key Azure‑specific points:

• Marketplace images are preconfigured with:
• Azure Linux Agent (waagent)
• Cloud‑init (usually) for first‑boot configuration
• Integration with Azure networking and storage drivers
• Custom images:
• You can create your own image (Packer, az image create, or from an existing VM) and use it across a subscription.

When in doubt, start with an official Ubuntu LTS or RHEL/SLES image, depending on your organization’s standards.

Azure Compute Options for Linux

Linux Virtual Machines (IaaS)

Azure VMs are the most direct way to run Linux in Azure. Key aspects for Linux:

• VM SKUs (sizes):
• General purpose (D‑series, etc.) for web/apps
• Compute-optimized (F‑series) for CPU‑heavy workloads
• Memory‑optimized (E‑series, M‑series) for databases/in‑memory workloads
• Storage‑optimized (L‑series) for heavy disk I/O
• Generation (Gen 1 vs Gen 2):
• Newer images are usually Gen 2 (UEFI boot, larger disks, some security features like vTPM).

Linux VM creation ties into:

• Selecting an image (e.g. UbuntuServer 22.04-LTS)
• Choosing auth method (SSH keys strongly recommended)
• Attaching OS disk and optional data disks
• Placing the VM in a Virtual Network (VNet) and subnet

Azure App Service for Linux

App Service allows you to deploy code (not full VMs). Linux‑specific features:

• Run on managed Linux containers:
• Built-in runtime stacks (Node, Python, PHP, .NET, etc.)
• Or custom Docker images from registries (Docker Hub, ACR)
• You manage app code and configuration, not the underlying OS.

Useful when:

• You don’t need full OS control
• You want PaaS features like autoscaling, deployment slots, zero‑downtime deploys

Azure Kubernetes Service (AKS) with Linux Nodes

AKS uses Linux for most node pools (Windows node pools are optional). Linux aspects:

• Node pools run a supported Linux distro (often Ubuntu or Azure Linux).
• You manage containers and Kubernetes objects; Azure manages the control plane.
• You still may need OS‑level knowledge for:
• DaemonSets / node‑level agents
• Security hardening of node images
• Debugging node issues via SSH or kubectl debug

Knowing standard Linux administration helps when you drop down from Kubernetes abstractions to the underlying nodes.

Azure Linux Agent and Extensions

Azure Linux Agent (`waagent`)

The Azure Linux Agent integrates your VM with Azure:

• Handles:
• Provisioning (injecting SSH keys, hostname, user)
• Network configuration
• Reporting health and status
• Some storage and diagnostics tasks

On most distros it’s installed and enabled by default:

• Package names: walinuxagent or azure-agent
• Config: /etc/waagent.conf
• Service: typically waagent or walinuxagent (systemd unit)

You rarely manage it directly, but you should know:

• Stopping/disabling it can break interactions with Azure (e.g. extensions, status reporting).
• Logs are often in /var/log/waagent.log for troubleshooting provisioning issues.

VM Extensions on Linux

VM Extensions are small agents/scripts that Azure runs inside your Linux VM to perform tasks such as:

• Install/configure monitoring (Azure Monitor, Log Analytics)
• Configure security (Azure Defender extensions)
• Reset SSH credentials or reset access
• Bootstrapping configuration management (Ansible, Chef, Puppet, DSC)

From Linux, you don’t usually run them directly; you:

• Enable extensions during deployment (ARM/Bicep/Terraform/CLI)
• See them as processes/services inside the VM
• Debug with logs in /var/log/azure/ (directory path can vary by extension)

---

Authentication and Access to Linux VMs

SSH Keys vs Passwords

For Linux on Azure, SSH keys are the standard:

• Strongly recommended to disable password SSH logins:
• Configure at deploy time (most portals and tools have a “SSH public key” option).
• OS‑level setting in /etc/ssh/sshd_config:
• PasswordAuthentication no
• PermitRootLogin no (usually already disabled)
• You typically:
• Generate a key pair on your local machine (ssh-keygen).
• Provide the public key to Azure when creating the VM.
• Azure injects the key into the Linux user’s ~/.ssh/authorized_keys.

Azure Bastion and Just-in-Time Access

Azure offers Bastion and Just-in-Time (JIT) access to reduce direct exposure:

• Azure Bastion:
• Lets you connect to Linux VMs over SSH using the Azure Portal, without exposing SSH on the public internet.
• Your VM has only private IPs; Bastion acts as a managed jump host.
• Just-in-Time (JIT) VM access:
• Limits how long SSH (port 22) is open.
• You request access for a short time window; NSG rules open and then close automatically.

For Linux admins, this changes how you connect, but inside the VM it’s just regular SSH.

Deploying Linux on Azure

Deployment Tools

Common ways to deploy Linux VMs and related resources:

• Azure Portal:
• Good for learning and one-offs.
• Step‑by‑step VM creation wizard.
• Azure CLI (az):
• Cross‑platform; often used in scripts and CI.
• Examples:
• List images:
• az vm image list --publisher Canonical --offer UbuntuServer --all
• Create VM:
• az vm create --resource-group RG --name myvm --image UbuntuLTS --size Standard_B2s --admin-username azureuser --ssh-key-values ~/.ssh/id_rsa.pub
• Azure PowerShell:
• Alternative to CLI, especially on Windows.
• IaC (Infrastructure as Code):
• ARM/Bicep templates
• Terraform (covered by the IaC chapter)
• Used to define Linux VMs, VNets, security rules, and attached disks in a reusable way.

Cloud-Init for Linux Configuration

Most Azure Linux images support cloud-init:

• Runs at first boot to configure:
• Users and SSH keys
• Packages to install
• Files to write
• Commands to run once
• On Azure, you provide cloud-init data as Custom Data when creating the VM.
• From the OS perspective:
• Config files often under /var/lib/cloud/ and /etc/cloud/.
• Logs under /var/log/cloud-init.log and related files.

Cloud‑init is a key tool for consistent Linux configuration at creation time, separate from later configuration management tools.

Storage Options for Linux on Azure

OS and Data Disks

Each Linux VM has:

• OS Disk:
• Contains / and the OS.
• Implemented as a Managed Disk (backed by Azure Storage).
• Usually a premium SSD for performance.
• Data Disks:
• Additional block devices you mount in Linux.
• Show up as /dev/sdX or /dev/nvmeXn1 depending on SKU and generation.
• Commonly used to store application data, databases, logs, etc.

Linux‑specific tasks:

• Partition and format disks (e.g., fdisk, parted, mkfs.ext4).
• Mount them (e.g., /mnt/data) and add entries to /etc/fstab for persistence.

Ephemeral Disks and Temp Storage

Some Azure VM types offer ephemeral OS disks or temporary storage:

• Ephemeral or temp disks:
• Very fast but non‑persistent; data can be lost on reboots, deallocation, or migration.
• Good for:
• Caches
• Temporary files
• In Linux, often mounted at /mnt or /mnt/resource (naming may differ by image).

You must not store critical data on these disks; use managed data disks or Azure storage services instead.

Integrating with Azure Storage Services

Beyond local block devices, Linux workloads on Azure often use:

• Azure Files:
• File shares that can be mounted over SMB or NFS (preview/region‑dependent).
• Linux can mount with mount -t cifs or mount -t nfs depending on configuration.
• Blob Storage:
• Object storage, not block or file.
• Accessed via:
• SDKs
• CLI tools (az storage blob ...)
• FUSE drivers or blobfuse (for mounting as a filesystem in some designs).

These are especially relevant when you want data shared across multiple Linux VMs or containers.

Networking for Linux on Azure

Azure Networking Basics for Linux VMs

Each VM NIC is attached to a VNet and subnet:

• Private IPs by default, optional public IP.
• Network Security Groups (NSGs) control allowed inbound/outbound traffic.

Linux‑side networking is mostly standard:

• Network interfaces are configured via:
• systemd-networkd, NetworkManager, or distro‑specific tools.
• Cloud‑init or the Azure Linux Agent normally sets initial config.
• IPs and DNS settings typically come from Azure DHCP within the VNet.

When troubleshooting connectivity:

• Check NSG rules and Azure side first.
• Then check Linux firewall (iptables, nftables, firewalld, ufw) and service bindings.

Load Balancing and Inbound Access

For Linux services exposed to the internet:

• Azure Load Balancer:
• Layer 4 (TCP/UDP) load balancer.
• Common for simple setups (e.g. Nginx on multiple Linux VMs).
• Application Gateway:
• Layer 7 HTTP/HTTPS reverse proxy and WAF.
• Terminates SSL, does path‑based routing to Linux backends.

Your Linux instances simply listen on ports; you configure listeners, backends, and health probes in Azure.

Security Considerations for Linux on Azure

Using Managed Identities from Linux

Azure Managed Identities let your Linux VM authenticate to Azure services without storing credentials:

• System‑assigned or user‑assigned identities.
• From Linux, you call the IMDS endpoint:
• URL: http://169.254.169.254/metadata/identity/oauth2/token
• Special headers: Metadata: true
• Then use the token to access Azure APIs and services (e.g., Key Vault, Storage).

This avoids hard‑coding secrets in config files on the VM.

OS-Level Hardening in the Azure Context

Many Linux hardening practices still apply, but Azure adds:

• Carefully scope NSG rules and avoid wide 0.0.0.0/0 allows.
• Prefer Bastion/JIT to expose SSH only when necessary.
• Use Azure Policy to enforce:
• Minimum OS versions
• Allowed images
• Disk encryption requirements

From inside Linux:

• Keep system updated via your distro’s package manager.
• Consider CIS or vendor hardening guides tailored for Azure.

Disk Encryption

Azure provides disk encryption options:

• Server-side encryption (SSE):
• Transparent at the storage layer; default for managed disks.
• Azure Disk Encryption (ADE) with Linux:
• Uses dm-crypt/LUKS under the hood, integrated with Azure Key Vault.
• Requires a supported distro and agent configuration.

From the OS view, this often looks like standard LUKS/dm-crypt devices, but you manage keys and policies via Azure.

Monitoring and Diagnostics for Linux on Azure

Azure Monitor and Log Analytics Agent

Azure Monitor integrates with Linux VMs using agents:

• Azure Monitor Agent (AMA) – the newer, unified agent.
• Legacy OMS/Log Analytics Agent (being phased out).

On Linux:

• Agents run as system services (e.g. azuremonitoragent).
• Collect:
• Syslog entries
• Performance data (CPU, memory, disk, network)
• Custom logs if configured

Data is sent to Log Analytics workspaces, where you query logs using Kusto Query Language (KQL).

OS-Level Logs and Integration

Important Linux logs that tie into Azure monitoring:

• /var/log/syslog or /var/log/messages – general system logs.
• /var/log/auth.log or /var/log/secure – authentication/audit.
• /var/log/waagent.log – Azure Linux Agent.
• Extension‑specific logs under /var/log/azure or extension paths.

Azure Monitor can be configured to collect specific files and paths, so understanding the Linux logging layout is essential.

Backups, Scaling, and High Availability

VM Backups

Azure Backup supports Linux VMs:

• Consistent snapshots of OS and data disks.
• Application‑consistent backups may need:
• Pre/post scripts
• Database‑specific actions (e.g. fsfreeze, DB flush)

From inside Linux, there’s usually no special agent you run manually; Azure backup extensions handle coordination.

Scaling Linux Workloads

Approaches to scale Linux services:

• VM Scale Sets (VMSS):
• Group of identical Linux VMs managed as a unit.
• Use autoscaling rules (CPU, queue length, custom metrics).
• Often combined with Load Balancer or Application Gateway.
• PaaS / Containers:
• App Service for Linux, AKS, Container Apps handle scaling transparent to the VM OS.

Your Linux image must be stateless or externally store state (databases, file shares, etc.) for easy scaling.

Practical Tips for Working with Linux on Azure

• Prefer SSH keys, disable password logins, and use Bastion or JIT.
• Learn the Azure CLI basics (az vm, az network, az disk) for Linux VM management.
• Use cloud-init for initial configuration, and a configuration management tool afterwards if needed.
• Understand how managed disks map to Linux block devices, and use /etc/fstab correctly.
• Keep an eye on:
• /var/log/waagent.log for provisioning issues.
• Azure Portal metrics for CPU, disk, and network.
• Use managed identities instead of storing secrets in config files on Linux.

This knowledge lets you combine your Linux skills with Azure’s platform features to build secure, manageable, and scalable systems.