こんにちは！第5サーバ事業部のマディです！

本記事のターゲット

・Ansible初学者
・実務でAnsibleを活用しているエンジニア
・Windows Updateの効率化を検討している方
・Ansible導入を検討している方

はじめに

定期的に対応が必要となるWindows Update。必要な作業だと分かってはいるものの、時間がかかる上、OSの再起動も必要なため、少し億劫に感じる人も多いのではないでしょうか。それが複数台、複数環境となれば。。。

本記事で紹介するplaybookを活用すれば、1回のコマンド実行でWindows UpdateからOS再起動、再起動後の更新プログラムの確認までが可能となります。

尚、実環境で実装する場合は、OS再起動を伴うため十分な検証を実施した後に実装することをおすすめします。

playbook記載例と詳細

playbook記載例

- name: ①Windows Updateの実行
  win_updates:
    category_names: '*'
    state: installed
  register: result_win_update

- name: ②Windows Updateの結果出力
  debug:
    msg: "{{ result_win_update }}"

- name: ③OS再起動
  when: result_win_update.changed
  win_reboot:

- name: ④更新プログラムのチェック（更新後）
  win_command: usoclient StartInteractiveScan

4つのタスク（①～④）で実施することができます。
下記にタスクごとのポイントを紹介します。

①Windows Updateの実行

- name: ①Windows Updateの実行
  win_updates:
    category_names: '*'
    state: installed
  register: result_win_update

このタスクでは、win_updatesモジュールを使用して、更新プログラムのインストールを行っています。

「category_names」は、更新を行うWindows Updateの種類（カテゴリ）を指定します。
ここで特定のカテゴリを指定した場合、そのカテゴリの更新プログラムのみが対象となり、それ以外のカテゴリの更新プログラムはインストールされません。
本記事のように「*（アスタリスク）」を指定した場合、カテゴリを問わず全ての更新プログラムがインストール対象となります。

「state」は、win_updatesモジュールが行う動作を指定します。以下3つが指定可能です。

（1）installed：更新プログラムをインストールする。
（2）downloaded：更新プログラムをダウンロードする。
（3）searched：更新プログラムを検索する。

デフォルトでは、「installed」が指定されているため、特に指定しない場合はインストールが行われます。

「register」は、Ansibleにおいて汎用的に用いられるモジュールの一つで、タスクの実行結果を指定した変数名で変数化します。
今回であれば、win_updatesモジュールの実行結果を「result_win_update」という変数に格納しています。
以降のタスクで大きな役割を果たすので覚えておいてください。

②Windows Updateの結果出力

- name: ②Windows Updateの結果出力
  debug:
    msg: "{{ result_win_update }}"

このタスクでは、debugモジュールを使用して、①のタスクで得られた結果をplaybookの実行ログに出力します。
「msg: "{{ result_win_update }}"」と指定することで、先ほど変数化した中身を表示することができます。

このタスクは、Windows Updateに直接関係するものではないので、あっても無くてもどちらでも良いものとなります。
ただ、「どの更新プログラムがインストールされたか」がひと目でわかるので、個人的にはあった方が良いかなと思います。

③OS再起動

- name: ③OS再起動
  when: result_win_update.changed
  win_reboot:

このタスクでは、win_rebootモジュールを使用して、OS再起動を行います。
「when」は、Ansibleにおいて汎用的に用いられる条件設定で、条件がTRUEの場合のみそのタスクを実行します。

今回は、「result_win_update.changed」という条件を指定していますが、これは
> 「①のタスク（result_win_update）が“changed”の場合に実行する」
という条件となります。

もっと噛み砕いて言えば、
> 「更新プログラムがインストールされた場合のみOS再起動を行う」
ということになります。

Ansibleはタスク実行で何かしらの変更が行われた場合、“changed”というステータスを返します。
今回であれば、何かしらの更新プログラムがインストールされた場合は“changed”、特にインストールされなければ“ok”というステータスを返すことになります。

①のタスクで、タスクの実行結果を「result_win_update」という変数に格納しましたが、この変数の中身にはこのステータス情報が含まれており、そのステータスを見てOS再起動を行うか判断します。

何故このような条件を付けるかと言うと、
もしこの条件を付けなかった場合、更新プログラムのインストールが行われていない（=何もしていない）のにOS再起動が行われてしまうからです。
不要なOS再起動を防ぐために必要な条件設定というわけです。

尚、「changedの場合のみ実行する」という条件は、“notify”と“handler”というAnsibleの機能を用いることでも実装可能です。こちらの方が使い勝手が良い部分もあるかもしれないので、気になる方は是非調べてみてください。

▼参考

④更新プログラムのチェック（更新後）

- name: ④更新プログラムのチェック（更新後）
 win_command: usoclient StartInteractiveScan

このタスクは、win_commandモジュールを使用して、更新プログラムのチェックを行います。

win_commandモジュールは、PowerShellなどで使われるコマンドをAnsibleで実行するためのモジュールです。したがって、今回指定している「usoclient StartInteractiveScan」はAnsibleでのみ使われる特別なものではなく、PowerShellのコマンドの一つとなります。

「usoclient StartInteractiveScan」というコマンドは、「Windows Update画面の“更新プログラムのチェック”を押下する」と同じ働きをします。（下記画像赤枠）

このタスクを行うことで、上記画像に記載のある「最終チェック日時」が最新のものになります。

余談
ところで、勘の良い方はこのタスクを見て下記のような疑問を抱くかと思います。
> 「win_updatesモジュールでインストールして、OS再起動を行ったのなら自動的に最新状態になるのでは？？」

私も最初はそう思っていましたが、実はそうではありませんでした。。（実体験）

今回のplaybookを用いて更新プログラムをインストールし、OS再起動後に上記画像の画面に行くと、インストール前と同じ状態になっていました。
win_updatesモジュールの役割に「更新プログラムのチェック」という動作がないのかもしれません。
実際、OS再起動後にwin_updatesモジュールを“state: searched”で指定して実行したものの状況に変化はなかったので。。。

ただ、更新プログラムがインストールされることは確実なので、もし不要であれば④のタスクは無くても問題はありません。

おわりに

個人的には「AnsibleとWindowsの相性はあまり良くない」と考えていたので、Windows Updateを自動化できるplaybookが完成した時は少し驚きました。Windows Updateという単純だけど時間がかかる作業がコマンド一つで完結することのメリットはかなり大きいと思います。
Ansibleに慣れてしまえばかなり重宝できるものだと思うので、ぜひご活用いただければ幸いです。

参考文献

ALHについて知る

↓ ↓ ↓　採用サイトはこちら　↓ ↓ ↓

↓ ↓ ↓　コーポレートサイトはこちら　↓ ↓ ↓

↓ ↓ ↓　もっとALHについて知りたい？　↓ ↓ ↓