Azure Update ManagementでGCPのVMにパッチを適用する（RHEL編）

# はじめに
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と接続出来るそうです。
今回は特に制限していません。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/604991/0ff38d5f-9841-7161-9d1b-17d79cd57a38.png" width=75%>

### wgetのインストール
Azure ポータルにLog Analyticsエージェントのインストールコマンドが用意されているのでそのコマンドを実行すれば良いのですが、
`wget`がVMに入っていなかったので、まずは`wget`をインストールします。
VMにsshでログインしてインストール。

```bash
yum install wget

～～～省略～～～

Installed:
  wget.x86_64 0:1.14-18.el7_6.1
```

### Log Analyticsエージェントのインストール
次にLog Analyticsエージェントをインストールします。
AzureポータルからLog Analytics→エージェント管理→Linux サーバー でコマンドをコピーします。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/604991/9c7af0ff-6894-bf5f-1ced-9cf726bbcdb8.png" width=80%>
コピーしたコマンドをVM上で実行

```bash
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→更新プログラムの管理 ページの `マシンの管理` をクリックします。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/604991/70951ae9-9164-8f79-a340-8f465e7e6037.png" width=80%>

接続するマシンを選択し `有効化` ボタンを押下します。
今回は1台しかVMが存在しないため、「使用可能なすべての……」を選択しています。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/604991/6e01edec-ba00-6412-926a-837e98c09596.png" width=60%>
これで接続完了となります

# パッチ適用
Log Analyticsと接続後、ある程度時間が経過しないとパッチ適用に失敗します。
筆者が試した際は20～30分程度経過後に成功しました。

## パッチ適用スケジュール設定
`更新プログラムの展開のスケジュール` をクリックします。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/604991/8274d82a-c94a-dc32-81a2-79dba7180818.png" width=80%>
諸々設定していき、 `作成` ボタンを押下します。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/604991/37f72f21-f456-e253-f98b-cd4c39d1d1d1.png" width=35%>
スケジュールされました。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/604991/c6d0c881-5cc8-4af6-ca59-a38c0529aa37.png" width=90%>

## 結果確認
待っているとターミナルにメッセージが表示されました。
Update Managementからの命令で再起動するようです。

```bash
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!
```

再起動の有無はスケジュールの設定の中で選択できます。
今回は `必要に応じて再起動` を選択しています。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/604991/51391eb5-c236-72d4-fa94-83ab26651638.png" width=25%>

誤って停止しているVMも含めてしまったので失敗となっていますが、対象のVMは適用完了しています。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/604991/27b66842-bfeb-06bd-fe1d-2a1a2fed5625.png" width=80%>
VM上でも確認してみます。

```bash
# 更新前
google-cloud-sdk.x86_64                     301.0.0-1                      @google-cloud-sdk

# 更新後
google-cloud-sdk.x86_64                     302.0.0-1                      @google-cloud-sdk
```

ポータル上で最新となっている事が確認できました。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/604991/0b8a424b-f3a2-e9fa-dd8e-26a59a56ef66.png" width=100%>

# おわりに
Azureポータルでパッチの管理が出来るのは非常に便利ですね。
マルチクラウドやハイブリッドクラウド環境でもパッチ管理を統合出来れば運用負荷も軽減されるのではないでしょうか。