Azure での仮想マシンに対する cloud-init のサポート

適用対象: ✔️ Linux VM ✔️ フレキシブルなスケール セット

この記事では、Azure でのプロビジョニング時に仮想マシン (VM) または Virtual Machine Scale Sets を構成するための cloud-init のサポートについて説明します。 これらの cloud-init 構成は、Azure によってリソースがプロビジョニングされた後の最初の起動時に実行されます。

VM のプロビジョニングとは、指定した VM Create のパラメーター値 (ホスト名、ユーザー名、パスワードなど) が Azure によって渡され、VM の起動時に使用できるようにするプロセスのことです。 "プロビジョニング エージェント" によって、これらの値を使用して VM が構成され、完了時に報告されます。

Azure では、2 つのプロビジョニング エージェント cloud-init と Azure Linux エージェント (WALA) がサポートされています。

cloud-init の概要

cloud-Init は、Linux VM を初回起動時にカスタマイズするために広く使用されている手法です。 cloud-init を使って、パッケージをインストールしてファイルを書き込んだり、ユーザーとセキュリティを構成したりすることができます。 cloud-init は初回起動プロセスの間に呼び出されるので、構成を適用するために追加の手順や必要なエージェントはありません。 #cloud-config ファイルやその他の入力の形式を正しく設定する方法について詳しくは、cloud-init のドキュメント サイトをご覧ください。 #cloud-config ファイルは、base64 でエンコードされたテキスト ファイルです。

cloud-init はディストリビューション全体でも有効です。 たとえば、パッケージをインストールするときに apt-get install や yum install は使用しません。 代わりに、cloud-init ではインストールするパッケージの一覧をユーザーが定義できます。 cloud-init によって、選択したディストリビューションに対してネイティブのパッケージ管理ツールが自動的に使用されます。

Microsoft は、動作保証済み Linux ディストリビューションのパートナーと協力して、cloud-init 対応のイメージを Azure Marketplace で利用できるようにする作業を行っています。 これらのイメージによって、cloud-init のデプロイと構成が、VM および仮想マシン スケール セット とシームレスに動作するようになります。 まず、Microsoft では動作保証済み Linux ディストリビューションのパートナーおよび上流と共同作業を行い、Azure 上の OS で cloud-init が機能するようにします。次に、パッケージが更新され、ディストリビューションのパッケージ リポジトリで一般公開されます。

cloud-init が Azure 上のサポート対象 Linux ディストリビューションで利用できるようになり、パッケージ、そしてイメージがサポートされる場合、次の 2 つの段階があります。

• "Azure での cloud-init パッケージ サポート" には、どの cloud-init パッケージ以降がサポートされているか、またはプレビュー段階であるかが記載されています。そのため、カスタム イメージの OS でこれらのパッケージを使用できます。
• "cloud-init 対応イメージ" には、イメージが既に cloud-init を使用するように構成されているかどうかが記載されています。

Canonical

RHEL

• Gen1 イメージと Gen2 イメージの両方を含む、RHEL 7 (バージョン 7.7) および RHEL 8 (バージョン 8.1) 以降の他のすべての RedHat SKU は、cloud-init を使用してプロビジョニングされます。 cloud-init は、RHEL 6 ではサポートされていません。

Oracle

• Gen1 イメージと Gen2 イメージの両方を含む、Oracle 7 (バージョン 7.7) および Oracle 8 (バージョン 8.1) 以降の他のすべての Oracle SKU は、cloud-init を使用してプロビジョニングされます。

SUSE SLES

Debian

現在、Azure Stack では、cloud-init 対応のイメージのプロビジョニングがサポートされています。

cloud-init と Linux エージェント (WALA) の相違点

WALA は、VM のプロビジョニングと構成および Azure 拡張機能の処理に使われる、Azure プラットフォーム固有のエージェントです。

既存の cloud-init のお客様が各自の現在の cloud-init スクリプトを使用したり、新しいお客様が cloud-init の豊富な構成機能を利用したりできるようにするために、Linux エージェントではなく cloud-init を使うように VM 構成タスクの強化が行われています。 Linux システム構成用の cloud-init スリプトが既にある場合、cloud-init でそれらを処理できるようにするために追加の設定は必要ありません。

cloud-init は Azure 拡張機能を処理できないため、拡張機能を処理するにはイメージでは WALA が引き続き必要ですが、プロビジョニング コードを無効にする必要があります。 cloud-init によってプロビジョニングするように変換される動作保証済みの Linux ディストリビューション イメージの場合、WALA がインストールされ、正しくセットアップされます。

VM を作成する際、プロビジョニング時に Azure CLI --custom-data スイッチを指定しないと、cloud-init または WALA では、VM をプロビジョニングして既定値でデプロイを完了するために必要な最低限の VM プロビジョニング パラメーターが取得されます。 --custom-data スイッチを指定して cloud-init の構成を参照した場合、カスタム データに含まれているものはすべて、VM 起動時に cloud-init で利用可能になります。

VM に適用される cloud-init の構成には時間制限がなく、タイムアウトによってデプロイが失敗することはありません。これは WALA には当てはまりません。カスタム データを処理するように WALA の既定値を変更した場合、VM のプロビジョニング合計時間は許容値の 40 分を超えることはできません。超えた場合、VM Create は失敗します。

UDF ドライバーを使用しない cloud-init VM のプロビジョニング

cloud-init 21.2 以降では、cloud-init を使用して UDF ドライバーを使わずに Azure で VM をプロビジョニングすることができます。 イメージで UDF ドライバーを使用できない場合は、Azure Instance Metadata Service で使用できるメタデータが、VM をプロビジョニングするために cloud init によって使用されます。 このオプションは、SSH キーとユーザー データに対してのみ機能します。 プロビジョニングの間にパスワードまたはカスタム データを VM に渡すには、UDF ドライバーを使用する必要があります。

cloud-init 対応の仮想マシンのデプロイ

cloud-init 対応の仮想マシンのデプロイは簡単であり、デプロイの間に cloud-init が有効なディストリビューションを参照するだけです。 Linux ディストリビューションのメンテナンス担当者は、cloud-init を有効にし、Azure で発行された基本イメージに cloud-init を統合する必要があります。 デプロイするイメージが cloud-init 対応であることを確認した後は、Azure CLI を使ってイメージをデプロイできます。

このイメージをデプロイする最初のステップは、az group create コマンドでリソース グループを作成することです。 Azure リソース グループとは、Azure リソースのデプロイと管理に使用する論理コンテナーです。

次の例では、myResourceGroup という名前のリソース グループを eastus に作成します。

az group create --name myResourceGroup --location eastus

次に、現在のシェルで cloud-init.txt という名前のファイルを作成し、次の構成を貼り付けます。 この例では、ローカル コンピューター上にない Cloud Shell でファイルを作成します。 任意のエディターを使用できます。 sensible-editor cloud-init.txt と入力してファイルを作成し、使用可能なエディターの一覧を表示します。 任意のエディターを使用します。 一般的な選択肢は、nano、vim、ed などがあります。 cloud-init ファイル全体 (特に最初の行) が正しくコピーされたことを確認してください。

ファイルを終了し、エディターに従ってファイルを保存します。 終了時にファイル名を確認します。

最後のステップでは、az vm create コマンドで VM を作成します。

次の例では、ubuntu2204 という名前の VM を作成し、既定のキーの場所にまだ SSH キーが存在しない場合は SSH キーを作成します。 特定のキーのセットを使用するには、--ssh-key-value オプションを使用します。 --custom-data パラメーターを使用して、cloud-init 構成ファイルを渡します。 現在の作業ディレクトリの外部に構成ファイル cloud-init.txt を保存していた場合には、このファイルの完全パスを指定します。

az vm create \
  --resource-group myResourceGroup \
  --name ubuntu2204 \
  --image Canonical:UbuntuServer:22_04-lts:latest \
  --custom-data cloud-init.txt \
  --generate-ssh-keys 

VM が作成されると、Azure CLI はデプロイ固有の情報を表示します。 publicIpAddress を書き留めておきます。 このアドレスは、VM へのアクセスに使用されます。 VM が作成され、パッケージがインストールされて、アプリが開始されるには、少し時間がかかります。 Azure CLI がプロンプトに戻った後にも引き続き実行するバック グラウンド タスクがあります。 SSH で VM に接続し、トラブルシューティングのセクションで説明されている手順を使って、cloud-init のログを見ることができます。

ARM テンプレートでパラメーターを渡すことによって、cloud-init 対応の VM をデプロイすることもできます。

cloud-init のトラブルシューティング

VM のプロビジョニングが済むと、cloud-init は --custom-data で定義されているすべてのモジュールとスクリプトを実行して、VM を構成します。 構成のエラーまたは漏れをトラブルシューティングする必要がある場合は、 /var/log/cloud-init.log にある cloud-init のログで、モジュール名 (たとえば、disk_setup や runcmd) を検索する必要があります。

cloud-init のログについて詳しくは、cloud-init のドキュメントをご覧ください。

テレメトリ

cloud-init は、使用状況データが収集されて Microsoft に送信され、製品やサービスの改善に役立てられます。 テレメトリは、プロビジョニング プロセス (VM の最初のブート) 中にのみ収集されます。 収集されたデータは、プロビジョニング エラーを調査し、パフォーマンスと信頼性を監視するのに役立ちます。 収集されるデータには、識別子 (個人識別子) は含まれません。 詳細については、「プライバシー ステートメント」もご覧ください。 収集されるテレメトリの例は次のとおりです (これは完全なリストではありません): OS 関連の情報 (cloud-init バージョン、ディストリビューション バージョン、カーネル バージョン)、重要な VM プロビジョニング アクションのパフォーマンス メトリック (DHCP リースの取得時間、VM の構成に必要なメタデータの取得時間など)、cloud-init ログ、dmesg ログ。

現在、テレメトリ収集は、cloud-init を使用するマーケットプレース イメージの大部分で有効になっています。 cloud-init の KVP テレメトリ レポーターを指定することで有効になります。 Azure Marketplace イメージの大部分では、この構成はファイル /etc/cloud/cloud.cfg.d/10-azure-kvp.cfg にあります。 画像の準備中にこのファイルを削除すると、この画像から作成されたすべての VM のテレメトリ収集が無効になります。

10-azure-kvp.cfg のサンプル コンテンツ

reporting:
  logging:
    type: log
  telemetry:
    type: hyperv

次のステップ

cloud-init による問題のトラブルシューティング。

構成変更の cloud-init の例については、以下のドキュメントをご覧ください。

• VM に他の Linux ユーザーを追加する
• 初回起動時にパッケージ マネージャーを実行して既存のパッケージを更新する
• VM のローカル ホスト名を変更する
• アプリケーション パッケージのインストール、構成ファイルの更新、キーの挿入