クラウド・コンピューティングが一般的となり、デジタルトランスフォーメーション（DX）の重要性が問われるなか、ITインフラ環境の柔軟で迅速な構築・管理が求められている。
このようなOperation Modernizationへの要求に対応すべく、インフラリソースもアプリケーションと同じようにコードで管理し、それを元に自動で構成する仕組み、いわゆるInfrastructure as Codeの利用が始まっている。
Infrastructure as Codeでは、ソフトウェア開発で培われてきたバージョン管理やテストの考え方が適用されていることが特徴である。
筆者はITシステムのインフラ構築・運用を主に担当しており、前述のようなInfrastructure as Codeを利用したAutomation技術を取り入れるべく、社内メンバーとともに学び、スキルアップを図っている。
本稿では、構成管理ツールの1つである Ansible（Ansible AWX）を題材に、社内メンバーでチームを結成して、Automation技術を学ぶために行った実際のタスク活動について紹介する。
AnsibleはRed Hat社が開発するITインフラの構成管理ツールである。構成管理ツールにはChef、Puppet などほかにも製品が存在するが、本タスク活動の題材に選んだ理由としては、チームメンバーが普段から Ansible に携わっていること、もしくはこれから活用する立場にあることが挙げられる。
Ansible AWXは、Ansible上にWebベースのUIを提供し、REST API等の機能も利用できるAnsible Towerに対するアップストリーム版の位置づけとなる。
本タスク活動では、以下の目標を掲げて活動に取り組んでいるので、それぞれ紹介していきたい。
（1）Automation技術を前提とした運用・構築スキルを習得する
Proof of Concept（概念実証）環境としてAnsibleサーバーを構築し、実際に手を動かしながら学ぶ。
（2）既存のものをいったん否定し、再構築することを経験する
Ansible Playbookの作成作業をシステム化（自動化）し、Ansible利用のハードルを下げる
PoC環境を準備・構築し、実際に手を動かしながら学ぶ
Ansible AWXの活用
我々はスキル習得に際してPoC環境を構築し、その環境で実際に手を動かして学ぶことを目的とした。そこで複数名のメンバーで環境を利用できるように、IBM Cloud環境に仮想サーバーインスタンスを準備した（図表1）。
PoC環境ではIBM Cloudに検証用の仮想サーバーを2台構築しており、Red Hat Enterprise Linux （以下、RHEL）にAnsible AWX を導入している。
当初はAnsible Towerを検討していたが、コスト面での制約などがあり、OSSであるAnsible AWXの利用を決定した。学習目的として使用する分には、とくに支障はなかった。TowerとAWX の違いについては、RedHat社のページを参照いただきたい（AWX と Red Hat Ansible Tower の比較）。
Ansible AWXサーバーの操作対象である「ターゲットノード」には、Windows Serverを準備した。Ansible AWXを導入したRHELサーバーも、「コントロールノード」兼「ターゲットノード」として検証に利用した。
またシステム構成のポイントとして、インフラ構成のコード管理のためGitHubにコードを保管し、検証環境と同期するようにしている。
Infrastructure as Codeを実践するために、CI/CDサイクルを取り入れることは重要であり、Ansibleを利用する際にはコード管理をどうするのか、事前に検討しておくことが有効である。
Ansible TowerにはAutomation Webhookという機能があり、専用のツールを導入することなくCI/CDを実現できる。Automation Webhookについては本タスク活動でも利用しているので、その点については後述する。
Ansible Playbookの作成自体を自動化し
Ansible利用のハードルを下げる
本タスク活動での一歩踏み込んだテーマとして、Ansible Playbookを作成する作業を自動化した点について紹介する。
図表2に示すとおり、Ansibleを利用したインフラ構成変更の「本来の作業の流れ」では、設計フェーズで作成した環境定義書等のパラメータシートから、Playbook （Ansibleのどのモジュールを使うか、など）の内容を検討し、Playbookを作成する。その後、AnsibleサーバーでPlaybookを実行するという流れとなる。
Infrastructure as Codeの利用では、サーバーの状態はコードのみで管理することも考えられるが、成果物としての設計書をExcel等で残す例は依然として多く見られる。
我々のアプローチでは、「どうすれば作業全体の手間をより省けるか」を中心に考えた。そこで具体的には、「あらかじめ用意したパラメータシートに値を入力しておき、変換プログラムを実行して、AnsibleのPlaybookを生成する」という仕組みを作成することにした。
変換プログラムを実行することで、パラメータシートの設定値を抽出して変換し、PlaybookとなるYAMLファイルを生成するまでの処理を実行し、人手の介入を減らすことで、工数削減、作業ミス削減、そして作業の簡略化を達成した。
これによりAnsibleに関する深い知識を必要とせずに、Playbookの作成までを可能とする。
どのようにPlaybookを自動生成するか
次に前述した変換プログラムについて、どのような考え方で作成したのかを掘り下げて説明する。
AnsibleのPlaybookはYAML形式で記述され、インデントによるデータ階層構造が表現されていることが特徴である。
このように一定の規則に従って記述されていることで、プログラムのアウトプットとしては扱いやすくなる。
自動生成にあたり検討すべきは、インプットとなるパラメータシートのフォーマットであると考えられる。我々の活動としてもプログラムを作成する前に、パラメータシートのフォーマットを定義することから始めている。
サンプル例をもとに、自動生成を検討した流れを具体的に示す。
（1）初めにマニュアルで、目的とするAnsibleモジュールを調査する。図表3の例ではWindows OSのユーザーアカウントを作成し管理する「win_user」というモジュールを対象にしている。「win_user」のパラメータをマニュアルで確認し、必要な項目を検討する。
（2）必要な項目を決定したら、それに対応するようにパラメータシートのフォーマットを決定していく。図表4の例では、シートのA列（name）~I列（description）までのパラメータを採用し、それに対応した設定値を入力できるようにしている。
ここで気を付けておくべきポイントとして、以下が挙げられる。
・Excelの1セルが1つのパラメータの設定値となるようにする。セルの結合などを行うと、プログラムからデータとして扱うことが難しいためである。
・抽出するデータの始めと終わりが分かるようにする。例では[user]、[end] という文字をセルに記載しており、このセルが検索範囲の“最初”と“最後”である、ということを変換プログラムが判別できるようにしている。
（3）マニュアルでTaskの記述例を参照し、インデントなどのルールを把握する。図表5の例ではgroupsの定義でインデントが1段階深くなっていることがわかる。プログラムでYAMLファイルへ書き出すときには、groups行のインデントを深くするように対応する。
（4）ここまででPlaybook記述のルールはある程度把握できているので、ExcelからYAMLファイルの変換プログラムを作成していく。図表6の例ではExcelシート3行目のA列～I列までを順に抽出して、その次の行（4行目）へ対象を移動、という具合に繰り返しの処理を作成することになる。
以上のような流れで、他のモジュールについても同様に検討し、変換プログラムの作成を進めた。タスク活動の検証では、Linux、WindowsのOS設定を対象のモジュールとしたが、他のプラットフォームやミドルウェアのモジュールについても同様の考え方で進められる。
Automation Webhookを利用したCIの実現
Infrastructure as Codeによりスピード感のあるインフラの構築や管理を実現するため、継続的インテグレーション（Continuous Integration、CI）の考え方をITインフラの分野にも取り入れる必要性が生じている。我々の活動でもこの点を考慮し、検証環境を構成しているので紹介する。
Ansible Towerのversion 3.6から「Automation Webhook」という機能が利用可能になっており、Ansible AWXでも同様に利用できる。
「Automation Webhook」はJenkins、Travis CI などの専用のCIサーバーを利用せずとも、GitHubリポジトリとリンクして動作し、GitHubからのイベントでジョブを自動的にトリガーできる機能である。概要については、RedHat社のページを参照してほしい（Red Hat Ansible Automation Platform 向け Automation Webhook の概要）。
我々は、前述した自動変換プログラムが正しく動作してPlaybookを生成できることを確認するため、以下のようなユースケースを想定してテストを行った（図表7）。ちなみにパラメータシートが作成され、サーバーへuploadされた状態から開始としている。
① 検証機で変換プログラムを実行してPlaybookを生成、所定のディレクトリへ配置する
② GitHubへPlaybookをpushする（GitHub上にあるリモートリポジトリに反映）
③ ②をトリガーにWebhookの機能でAnsible AWXへジョブ開始が連携される
④ Playbookが実行され、ターゲットノードのサーバーの構成変更が行われる
⑤ Ansible AWXおよびターゲットノード実機上で、処理結果が意図する状態になっているかを確認する
変換プログラムは最初から正しく動いたわけではなく、いくつかのバグフィックスの対応をしながら進めていった。上記のような小さなサイクルであっても、素早く「修正・テスト・結果確認」が可能な環境を実現できたことは、インフラコードの開発に際してもメリットを実感できた。
Webhook利用のためGitHubとの同期については、図表8のようにローカルリポジトリをAnsible AWXのProjectディレクトリとし、リモートのGitHubリポジトリと同期するようにした。
main.ymlが実際の処理（task）内容を記述しているファイルなので、設定を変更する際のテストを実行する場合には、このファイルを置き換えてgit pushを行うことで、ジョブが実行されることになる。
以上のとおり、社内でのタスク活動を題材にAnsibleを実際に操作し、スキルアップを図った事例を紹介した。
Automation技術が躍進する中で、工夫を取り入れつつInfrastructure as Codeのプロセスを体現できたことは、活動メンバーとしても自動化を推進していくための学びがあったと考えている。
今後もAutomation技術はさらに普及し、活用の広がりが期待される領域である。本稿がこれからAnsibleを学び、活用する読者の方へのヒントとなれば幸いである。
著者
勝又 裕矢氏
日本アイ･ビー･エムデジタルサービス株式会社
インフラサービス事業部
社会・産業統括本部 社会・産業第四本部 第六システム部
ITスペシャリスト
2009年、日本アイ・ビー・エム・サービス株式会社 （IJDS統合前の前身）に入社。
お客様システムのインフラ基盤の運用に従事しながら、AIX、Linux、等のインフラ設計・構築に携わる。近年はAnsibleなどITインフラ管理の自動化技術を活用するための取り組みを行っている。
［i Magazine・IS magazine］
