Azure Linux 4.0は、Microsoft Azure上の仮想マシンとVirtual Machine Scale Setsで利用できるMicrosoft管理のLinuxディストリビューションです。今回のポイントは、Linux kernel 6.18 LTS、dnf5、更新された主要ライブラリによりOS基盤が刷新された一方で、現時点ではパブリックプレビューであり、本番利用ではなく検証・移行準備に使うべき段階だという点です。Azure VMやVMSSでLinux標準イメージ、ゴールデンイメージ、CI/CD、パッケージ更新、セキュリティ設定を管理しているチームは、早めに検証環境で差分を確認しておくと、GA後の移行判断がしやすくなります。(Microsoft Learn)
Azure Linux 4.0 Public Previewの要点
Azure Linux 4.0は、Azure向けに構築・保守される軽量なLinuxディストリビューションで、Azure Virtual MachinesとVirtual Machine Scale Setsへの展開を前提にしています。Azure Marketplaceではmicrosoftazurelinuxパブリッシャーから提供され、VM単体だけでなく、スケールアウトするワークロードではVMSSへの展開も想定されています。(Microsoft Learn)
ただし、最初に押さえるべき判断基準は「本番投入するか」ではなく「本番投入前に何を検証するか」です。Azure公式のプレビュー定義では、In previewはすべてのAzure利用者が非運用環境で使用・テストできる状態を指します。また、Azure Linux 4.0のドキュメントでも、プレビューは評価とテスト目的に限定され、本番環境には適していないと明記されています。(マイクロソフト Azure)
そのため、既存のUbuntu、Red Hat Enterprise Linux、SUSE、Debianなどをすぐ置き換えるというより、次のような検証テーマに向いています。
| 検証テーマ | 確認すべきこと |
|---|---|
| 標準Linuxイメージの候補評価 | Azure標準化、Microsoftサポート、運用ツールとの相性 |
| VMSSの新規展開 | 自動スケール、ローリング更新、OSイメージ更新の流れ |
| ゴールデンイメージ作成 | 追加パッケージ、セキュリティ設定、監視エージェントの組み込み |
| CI/CD・IaC対応 | Terraform、ARM/Bicep、Azure CLIのイメージ指定変更 |
| アプリ互換性確認 | glibc、OpenSSL、Python、systemd、SELinuxの影響 |
何が変わるのか
Azure Linux 4.0の大きな変更点は、Azure上で動かすLinux基盤として、カーネル、パッケージ管理、主要ライブラリが現代化されたことです。公式ドキュメントでは、Linux kernel 6.18 LTS、glibc 2.42、OpenSSL 3.5.4、systemd 258.4、Python 3.14.3、rpm 6.0.1、dnf5などが主要コンポーネントとして示されています。(Microsoft Learn)
| 項目 | Azure Linux 4.0での変更 | 管理者・開発者への影響 |
|---|---|---|
| カーネル | Linux kernel 6.18 LTS | 新しいハードウェア、GPU、AIアクセラレータ、Hyper-V統合の検証が必要 |
| パッケージ管理 | dnf5を採用 | tdnf前提のスクリプト、Dockerfile、CIパイプラインを確認 |
| 主要ライブラリ | glibc、OpenSSL、systemdなどを更新 | ネイティブ依存、暗号化設定、サービス起動順序の確認が必要 |
| RPM基盤 | rpm 6.0.1 | 署名検証、社内RPM、リポジトリ運用の確認が必要 |
| セキュリティ | SELinux、firewalld、鍵認証などの既定値が重要 | 従来の「とりあえず動かす」設定では失敗する可能性 |
特に影響が出やすいのは、パッケージ管理まわりです。以前のAzure Linuxで使われていたtdnfを直接呼び出すスクリプトがある場合、Azure Linux 4.0ではdnf5またはdnfへの更新を前提に確認する必要があります。DNF5は依存関係解決の高速化やメモリ使用量の削減を狙った新しい実装で、yumやdnfに近い操作感を維持しつつ、内部挙動が異なるケースがあります。(Microsoft Learn)
対象になる範囲
今回のPublic Previewで中心になる対象は、Azure Virtual MachinesとVirtual Machine Scale Setsです。Azure Linux 4.0イメージはAzure Marketplaceのmicrosoftazurelinuxパブリッシャー配下で公開されており、x86_64 Gen2ではmicrosoftazurelinux:azurelinux-4:4:latest、ARM64 Gen2ではmicrosoftazurelinux:azurelinux-4:4-arm64:latestを使用します。x86_64 Gen1はプレビューでは利用できません。(Microsoft Learn)
| アーキテクチャ | VM世代 | URN | 判断ポイント |
|---|---|---|---|
| x86_64 | Gen2 | microsoftazurelinux:azurelinux-4:4:latest | 標準的な検証候補 |
| x86_64 | Gen1 | プレビューでは利用不可 | 既存Gen1前提の設計は見直し |
| ARM64 | Gen2 | microsoftazurelinux:azurelinux-4:4-arm64:latest | ARM系VMサイズでの性能・互換性検証向け |
Azure Linuxはオープンソースですが、MicrosoftのサポートとライフサイクルのコミットメントはAzureシナリオに適用されます。具体的には、Azure Linux VM、VMSS、AKSコンテナホスト、コンテナイメージが対象で、ベアメタル、ISOイメージ、オンプレミス、他クラウドでの利用はサポート対象外とされています。カスタムイメージも、ゼロからビルドするのではなく、事前構築済みのAzure Linuxイメージをベースにする前提で考えるべきです。(Microsoft Learn)
まず確認すべき設定とコマンド
Azure Linux 4.0を試す前に、対象リージョンでMarketplaceイメージが見えるかを確認します。公式ドキュメントでは、Azure CLIでパブリッシャー、オファー、SKU、バージョンを確認する方法が示されています。(Microsoft Learn)
# パブリッシャー配下のオファーを確認
az vm image list-offers \
--publisher microsoftazurelinux \
--location eastus
# azurelinux-4 のSKUを確認
az vm image list-skus \
--publisher microsoftazurelinux \
--offer azurelinux-4 \
--location eastus
# SKU 4 のバージョンを確認
az vm image list \
--publisher microsoftazurelinux \
--offer azurelinux-4 \
--sku 4 \
--all
# latestの詳細を確認
az vm image show \
--urn microsoftazurelinux:azurelinux-4:4:latest検証用VMをAzure CLIで作成する場合は、Marketplaceイメージとしてmicrosoftazurelinux:azurelinux-4:4:latestを指定します。公式のVM作成例でも、Azure CLI、ARMテンプレート、Terraformで同じイメージ参照を使う方法が示されています。(Microsoft Learn)
az group create \
--name rg-azurelinux4-test \
--location eastus
az vm create \
--resource-group rg-azurelinux4-test \
--name vm-azurelinux4-test \
--image microsoftazurelinux:azurelinux-4:4:latest \
--admin-username azureuser \
--generate-ssh-keysARMテンプレートやBicep、Terraformで標準化している環境では、イメージ参照を固定値で書いているか、変数化しているかを確認してください。検証段階ではlatestが便利ですが、再現性が必要な検証では、実際に取得したバージョン番号を控えておくと、後から差分を追いやすくなります。
管理者が確認すべき運用上の注意点
本番環境ではなく検証環境で使う
最も重要なのは、Public Previewを本番運用の標準OSにしないことです。プレビューは評価・テスト用であり、Azure Linux 4.0固有のサポート期間や更新ポリシーの詳細はGA前に公開される予定とされています。ライフサイクル面では、月次セキュリティ更新、重大・高深刻度CVEの優先対応、カーネルや主要パッケージの計画的な更新が示されていますが、具体的なサポート期間はGA前の情報確認が必要です。(Microsoft Learn)
本番に近い検証を行う場合でも、接続先データベース、個人情報、業務クリティカルな処理は切り離し、性能試験や起動試験、パッケージ互換性確認に目的を絞るのが安全です。
Gen1 VM前提の設計を見直す
x86_64のGen1イメージはプレビューでは利用できません。既存のテンプレートやVMSS定義がGen1前提の場合、単にイメージURNを差し替えるだけでは展開できない可能性があります。検証前に、VM世代、Trusted Launch、Secure Boot、既存ディスク方式、バックアップ設計を確認してください。
OSディスク容量を明示する
Azure Linux VMのディスクサイズは5GBに設定されるため、用途によってはOSディスク拡張が必要です。公式ドキュメントでは--os-disk-size-gbパラメーターで拡張する方法が示されています。ログ、エージェント、ミドルウェア、パッケージキャッシュを入れる検証では、初期値のままだと容量不足を原因に失敗することがあります。(Microsoft Learn)
az vm create \
--resource-group rg-azurelinux4-test \
--name vm-azurelinux4-test \
--image microsoftazurelinux:azurelinux-4:4:latest \
--admin-username azureuser \
--generate-ssh-keys \
--os-disk-size-gb 64VMSSでは更新方式を先に決める
VMSSでAzure Linux 4.0を使う場合、OS更新は「イメージベース」と「パッケージベース」のどちらを中心にするかを先に決めます。Azure Linuxの更新ドキュメントでは、新しいAzure Linuxイメージで再デプロイするイメージベース更新と、実行中のVMにパッケージ更新を適用する方式が整理されています。VMSSではOSイメージの自動アップグレードを使い、新しいイメージバージョンをスケールセットへ展開する選択肢もあります。(Microsoft Learn)
| 更新方式 | 向いているケース | 注意点 |
|---|---|---|
| イメージベース更新 | ゴールデンイメージ、VMSS、Immutableに近い運用 | イメージ作成と段階的ロールアウトの仕組みが必要 |
| パッケージベース更新 | 小規模検証、実行中VMの個別更新 | 全台同時適用を避け、監視とロールバックを用意する |
| VMSS OSイメージ自動アップグレード | 大規模なスケールセット運用 | Rolling更新、ヘルス確認、アプリ側の冗長性設計が必要 |
注意したいのはdnf-automaticです。公式ドキュメントでは、dnf-automaticはカーネル更新後にVMを再起動しないこと、段階的ロールアウトなしで広範囲に有効化すると停止につながる可能性があることが警告されています。自動更新は便利ですが、VMSS全体へ一斉に適用するのではなく、ステージング、監視、ロールバックとセットで設計しましょう。(Microsoft Learn)
開発者が確認すべき互換性
開発者が最初に見るべきなのは、アプリケーションが依存しているランタイムとネイティブライブラリです。Azure Linux 4.0ではglibc、OpenSSL、Python、systemdなどが更新されているため、Python拡張、C/C++依存、暗号化ライブラリ、サービス起動定義に影響する可能性があります。(Microsoft Learn)
確認の優先順位は次のとおりです。
| 確認対象 | 具体的な確認例 |
|---|---|
| パッケージインストール | dnf installで必要なパッケージが取得できるか |
| CI/CD | tdnf、microdnf、yum前提の処理が失敗しないか |
| ネイティブ依存 | glibcやOpenSSL更新でビルド・実行が通るか |
| systemd | サービスファイル、依存関係、起動順序が想定通りか |
| コンテナ連携 | ホストOSに依存するマウント、ログ、エージェントが動くか |
| 監視・運用 | Azure Monitor、Defender、Log Analytics、独自エージェントが動くか |
yumやtdnfの互換シンボリックリンクは用意されていますが、DNF4やmicrodnf固有の挙動に依存するエッジケースは注意が必要です。特に、戻り値、出力形式、キャッシュ削除、プラグイン、リポジトリ切り替えをスクリプトで細かく制御している場合は、コマンド単位で検証してください。(Microsoft Learn)
セキュリティ設定でつまずきやすいポイント
Azure Linux 4.0では、セキュアな既定値が重視されています。公式ドキュメントでは、最小限のパッケージセット、鍵ベースのSSH認証、firewalldの有効化、SELinux Enforcing、パッケージとリポジトリメタデータのGPG署名などが説明されています。(Microsoft Learn)
実務で起きやすい失敗は、既存Linuxと同じ感覚で「アプリが動かないからSELinuxを無効化する」「通信できないからファイアウォールを止める」と判断してしまうことです。検証段階では、まず拒否ログを確認し、必要なポリシーやポートだけを調整するほうが、GA後の標準化に向いています。
| 症状 | よくある原因 | 確認ポイント |
|---|---|---|
| SSH接続できない | パスワード認証前提、NSG、公開鍵設定ミス | 公開鍵、NSG、Azure Bastion、管理者ユーザー |
| アプリのポートに接続できない | firewalldまたはNSGで未許可 | OS側とAzure側の両方で許可 |
| サービスがファイルにアクセスできない | SELinuxポリシーの拒否 | auditログ、ラベル、サービス権限 |
| パッケージ導入に失敗する | リポジトリ設定、GPG署名、プロキシ | /etc/yum.repos.d/と/etc/dnf/dnf.conf |
| 脆弱性対応方針が決められない | Preview段階の扱いが曖昧 | 検証環境限定、GA後のライフサイクル確認 |
なお、FIPS 140-3については、Azure Linux 4.0の主要コンポーネント表で「進行中」とされ、認証が必要なワークロードでは認証済みリリースを使うよう示されています。規制要件があるシステムでは、プレビュー版で本番相当の適合判断をしないよう注意してください。(Microsoft Learn)
移行・展開の進め方
既存環境をAzure Linux 4.0へ移すかどうかは、いきなりOSを差し替えて判断するのではなく、ワークロード単位で段階的に評価します。
| ステップ | 作業内容 | 完了条件 |
|---|---|---|
| 検証VMを作成 | Marketplaceイメージから単体VMを作成 | SSH接続、基本コマンド、更新確認ができる |
| 依存パッケージを確認 | アプリに必要なRPM、外部リポジトリ、ビルド手順を確認 | CI/CDで再現可能 |
| セキュリティ設定を確認 | SELinux、firewalld、SSH、監査ログを確認 | 無効化せずに動作できる |
| 監視・バックアップを確認 | Azure Monitor、Defender、バックアップ、ログ転送を確認 | 既存運用と同等に観測できる |
| VMSSで小規模展開 | 少数インスタンスのステージングVMSSを作成 | ローリング更新とロールバックを確認 |
| 判断を記録 | 使う条件、使わない条件、未解決課題を整理 | GA後に採用可否を判断できる |
移行判断では、技術的に動くかだけでなく、運用チームが更新・監視・障害対応できるかを確認してください。特にVMSSは、一台ずつ手作業で直す運用と相性が悪いため、イメージ作成、スケールセット更新、ヘルスチェック、ロールバックをセットで検証する必要があります。
採用に向いているケース、まだ待つべきケース
Azure Linux 4.0は、Azure上でLinux基盤をMicrosoft管理のディストリビューションへ寄せたい組織にとって有力な選択肢です。一方で、プレビュー段階では本番システムの移行先として急いで採用するものではありません。
| 判断 | 向いているケース |
|---|---|
| 早めに検証すべき | Azure VM/VMSSの標準Linux候補を探している |
| 早めに検証すべき | ゴールデンイメージやIaCを整備している |
| 早めに検証すべき | dnf5、SELinux、Azure最適化カーネルの影響を把握したい |
| まだ待つべき | 本番ワークロードをすぐ載せ替えたい |
| まだ待つべき | FIPSなど厳格な認証要件がある |
| まだ待つべき | x86_64 Gen1前提の古いテンプレートを使っている |
| まだ待つべき | 特定ディストリビューションの認定やISVサポートが必須 |
よくある疑問
既存のAzure Linux環境は自動で4.0になりますか？
通常、既存VMのOSイメージが勝手に別メジャーバージョンへ置き換わる前提で考えるべきではありません。Azure Linux 4.0を使うには、MarketplaceイメージやIaCのイメージ参照、VMSSのモデル、ゴールデンイメージ作成プロセスを明示的に変更して検証します。
UbuntuやRHELの代わりになりますか？
用途によっては候補になりますが、単純な置き換えではありません。パッケージ名、サポート契約、ISV認定、運用手順、セキュリティ基準が異なるため、まずは新規ワークロードや標準イメージ候補として検証するのが現実的です。
VMSSで使う場合、どこを重点的に見ればよいですか？
イメージ更新、ローリングアップグレード、ヘルスチェック、アプリの起動時間、スケールアウト時の初期化処理を重点的に確認します。VMSSでは、1台だけ成功しても十分ではありません。複数台を段階的に入れ替えたときに、ロードバランサー、監視、ログ、アプリのセッション管理が破綻しないかを見る必要があります。
パッケージ管理はyumのままでもよいですか？
互換性のためにyumやdnf、tdnfがDNF5へディスパッチされる構成はありますが、長期的にはdnf5またはdnfを前提にスクリプトを整理するのが安全です。特にCI/CDやDockerfileでtdnfを直接使っている場合は、Azure Linux 4.0検証時に修正対象として洗い出してください。(Microsoft Learn)
次に取るべき行動
Azure Linux 4.0 Public Previewは、今すぐ本番移行するための発表ではなく、Azure VMとVMSSのLinux基盤を将来どう標準化するかを検証するための材料です。まずは検証用サブスクリプションまたは専用リソースグループで単体VMを作成し、次にVMSS、IaC、パッケージ更新、監視、セキュリティ設定の順に確認しましょう。
最初のチェックリストは次の5つで十分です。
- 対象リージョンでAzure Linux 4.0イメージを取得できるか
- x86_64 Gen2またはARM64 Gen2で展開できるか
tdnf前提のスクリプトやCI/CDがないか- SELinux、firewalld、SSH鍵認証を無効化せずに運用できるか
- VMSSでイメージ更新とロールバックを再現できるか
この5点を確認しておけば、GA後に「使えるかどうか」を慌てて判断するのではなく、「どのワークロードから使うか」を計画的に決められます。
コメント