はじめに
Azureのパッチ管理サービス（機能？）のAzure AutomationのUpdate Managementを使ってGCP（GCE）のVMに対してパッチ適用してみます。
この機能はパッチファイルを配信するのではなくVMに設定されている方法で更新するため、リポジトリやWindwos Update（WSUS）にアクセス出来ないとパッチ適用ができないので注意が必要です。
https://docs.microsoft.com/ja-jp/azure/automation/automation-update-management
今回はRed Hat Enterprise Linux 7で試してみます。
Log Analyticsワークスペースと接続
Update Managementを利用するにはLog Analyticsのワークスペースに接続する必要があります。
そのため、GCEのVMにLog Analyticsエージェントをインストールします。
Azure Virtual Machinesの場合はポータルからLog Analyticsに接続することでエージェントが自動インストールされますが、
その他のサーバはLog Analyticsエージェントを手動でインストールします。
https://docs.microsoft.com/ja-jp/azure/azure-monitor/learn/quick-collect-linux-computer
Log Analyticsエージェントのインストールには色々要件があるので確認して適宜セットアップしてください。
https://docs.microsoft.com/ja-jp/azure/azure-monitor/platform/log-analytics-agent
GCE VMインスタンス作成
GCPのコンソールからVMを作成しました。
送信ポートの443が開いていればLog Analyticsと接続出来るそうです。
今回は特に制限していません。
wgetのインストール
Azure ポータルにLog Analyticsエージェントのインストールコマンドが用意されているのでそのコマンドを実行すれば良いのですが、
wgetがVMに入っていなかったので、まずはwgetをインストールします。
VMにsshでログインしてインストール。
yum install wget
～～～省略～～～
Installed:
wget.x86_64 0:1.14-18.el7_6.1
Log Analyticsエージェントのインストール
次にLog Analyticsエージェントをインストールします。
AzureポータルからLog Analytics→エージェント管理→Linux サーバー でコマンドをコピーします。
コピーしたコマンドをVM上で実行
wget https://raw.githubusercontent.com/Microsoft/OMS-Agent-for-Linux/master/installer/scripts/onboard_agent.sh && sh onboard_agent.sh -w <YOUR WORKSPACE ID> -s <YOUR WORKSPACE PRIMARY KEY>
Update Managementの設定
Automation→更新プログラムの管理 ページの マシンの管理 をクリックします。
接続するマシンを選択し 有効化 ボタンを押下します。
今回は1台しかVMが存在しないため、「使用可能なすべての……」を選択しています。
これで接続完了となります
パッチ適用
Log Analyticsと接続後、ある程度時間が経過しないとパッチ適用に失敗します。
筆者が試した際は20～30分程度経過後に成功しました。
パッチ適用スケジュール設定
更新プログラムの展開のスケジュール をクリックします。
諸々設定していき、 作成 ボタンを押下します。
スケジュールされました。
結果確認
待っているとターミナルにメッセージが表示されました。
Update Managementからの命令で再起動するようです。
Azure Update Management initiated a reboot after an update run.
The system is going down for reboot at Mon 2020-07-27 05:44:57 UTC!
再起動の有無はスケジュールの設定の中で選択できます。
今回は 必要に応じて再起動 を選択しています。
誤って停止しているVMも含めてしまったので失敗となっていますが、対象のVMは適用完了しています。
VM上でも確認してみます。
# 更新前
google-cloud-sdk.x86_64 301.0.0-1 @google-cloud-sdk
# 更新後
google-cloud-sdk.x86_64 302.0.0-1 @google-cloud-sdk
ポータル上で最新となっている事が確認できました。
おわりに
Azureポータルでパッチの管理が出来るのは非常に便利ですね。
マルチクラウドやハイブリッドクラウド環境でもパッチ管理を統合出来れば運用負荷も軽減されるのではないでしょうか。