Ansible Advent Calendar 2019 12日目の記事になります。
Windows Updateを自動化するためにAnsibleを使うことを提案したので、その内容を共有させていただきます。なお、この記事を投稿した前日も手動Windows Updateに苦しめられておりました。手動Windows Updateは滅びなくてはいけない。
背景
弊社ではWindows Serverメインで運用しており、数人で毎月Windows Updateをするという業務があります。月ごとに実施台数は変わりますが、合計すると年間約1500回分のWindows Updateを実施しています。手動で。
このWindows Update作業でいくつか問題点を認識しており、なんとかしたいと考えていたところ、赤い帽子の営業さんがAnsibleを紹介しにやってきてくれました。
教えていただいたAnsibleと出会って4ヶ月ほど、katacodaやもくもく会などで勉強させていただき、ある程度使い方を把握したためWindows Update自動化に取り組んでいきました。
作業手順
現在のWindows Updateは以下の手順となっています。ちなみに手順書などありません、口頭伝承です。
- 対象サーバにリモートデスクトップ接続
- Windows Updateﾎﾟﾁｰ
- サーバ再起動（アップデートが無くても）
- アップデートが無くなるまで1～3を繰り返す
- Windowsイベントログにエラーが出ていないか確認
- エラーがあれば担当者判断でリーダーに報告
問題点
オペミスの温床
サーバへの接続から手作業で行っているため、稀に良くある「対象と違うサーバにログオンして作業してしまう」というミスが発生します。
最近はそのようなミスは無いようですが（自分の入社以前にあったらしい）、いつ起きてもおかしくない現状は問題です。
ログ確認内容が担当者依存
「どのようなエラーログの場合は対処する」といったマニュアルもないため、Windowsイベントログにどんなエラーが出ていようと、担当者の判断で無かったことになります。完全に担当者個人の暗黙知として蓄積されています。
このようなことから、作業後の確認品質にバラつきが出てしまいます。
精神的苦痛
本音はこれです。
Windows Update自体はとても簡単です。単調です。それ故、作業時間が長いほど苦痛です。ほとんどが待ち時間です。本当にこれがイヤでイヤでイヤでイヤで…。
提案した対策法
AnsibleによるWindows Update自動化
まず初めに手作業を極力無くすため、Ansibleを使ってWindows Updateを自動化しました。
AnsibleにはWindows Update用のモジュールが提供されており、また今回やりたいことも明確（Windows Update+必ず再起動）だったため、比較的簡単にPlaybookは作成できました。
また、Ansibleだけでは運用する上で足りない機能が多かったためAWXも導入しました。KubernetesやOpenshiftといったハイカラな基盤は弊社には無いため、必然的にdocker-composeでのデプロイとなっています。
ログ確認方法の変更
AnsibleによるWindows Update自動化の仕組みを提案したところ、「自動化して作業者が減ってしまうとWindows Update後のログ確認作業の負担が増える」というコメントがありました。「Windows Update」と「ログ確認」をセットで担当者が作業しているものを、自分の提案は「Windows Update」だけ自動化しようとして「ログ確認」が手作業で残る形だったため、「Windows Update」をする人数は減らせても「ログ確認」の1人あたりの作業負担が増えてしまう自動化となっていました。
唐突な反省
最初の提案では「できるところから自動化しよう」という良く言われる手法を参考に自動化を実現しようとしたのですが、作業全体を見渡せていない自動化の実現方法となっていました。「技術的に自動化できるところ」ではなく「運用として自動化できるところ」を意識すべきだと反省しました。
上記コメントを受け、Elasticsearch+Kibanaを使ったログ集約サーバを構築して、ログ確認の方法を変えること考えました。そもそも今回の件に関係なくログ集約しとくべきでは
各サーバにログオンしてログ確認するのではなく、ログを一箇所に集約して確認することで担当者が少なくても負担が減るようにしました。
また、ElasticsearchとKibanaもAnsibleで構築できるようにroleを作成しました。
Elastic公式サイトに載っているインストール手順をroleに落とし込んだだけになりますが、まさに「Ansibleで構築自動化している！」感を味わえて楽しかったです。
ログ収集ツールインストールの自動化
ログ集約先をElasticsearchとしたので、ログ収集ツールはWinlogbeatを選択しました。WinlogbeatはElasticsearchと同じくElastic社が提供しているプロダクトでWindowsイベントログを簡単に収集してくれるツールです。インストールや初期設定が簡単という点から選択しました。
こちらもAnsibleでWindows Serverへのインストールを自動化しました。やることは「zip取得→解凍→installスクリプト実行→設定変更→サービス起動」だったのでrole作成は簡単かと思ったのですが、ツールのバージョンアップデートを考慮する仕組みの構築が難しく断念してしまいました。
ElasticsearchやWinlogbeatのインストールを自動化することでサーバ作業の負担も大きく増えないことをアピールでき、ログ確認方法の変更を受け入れてもらいやすくなったと思います。
結果
「AnsibleによるWindows Update自動化」および「Elasticsearchによるログ収集」（＋Winlogbeatインストール自動化）を提案し、なんとか次回のWindows Updateから実践するお許しを得られました。
今回提案した仕組みを導入できるのは次回のWindows Updateになるため、本記事の執筆時点ではまだ実戦投入に至らず効果測定を記載できずに申し訳ありません。
課題
「担当者依存のログ確認」が未解決
Elasticsearch導入によりログ集約できたのですが、ログ内容の確認自体は依然作業者が行うようになっています。担当者を少なくできればログ確認の品質もブレが減りそうですが、完全に自動化できていません。これにはホワイトリストかブラックリストを用意して対処しようかと考えています。
WSUS配布しか対応していない
今回作成したWindows Update用のRoleはWSUSで配布されるものしか対応できていません。そのため、配布されないアップデートを適用する手順は手動のままとなっています。対処は検討中です。
Windows Updateの順序を決められない
クラスタ構成のサーバに対しては順序を決めてWindows Updateを施したいのですが、現状は対応できていません。Ansible Tower/AWXのワークフローテンプレートを使えば比較的楽に順序を持たせてWindows Updateができそうです。