インフラ構築における課題
近年のデジタルトランスフォーメーション（DX）の流れのなかで、ITシステムにはより迅速かつ効率的な管理の手法が求められている。本稿では、オンプレミスのインフラ環境という観点でAnsibleを活かしたサーバー構築自動化について解説する。
昨今のインフラ構築の現場で指摘される課題としては、IT需要の多様化に伴うサーバーの種類や台数の増大が挙げられる。
ハードウェアセットアップ以降の一般的なインフラ構築の手順では、OSを新規導入し、各種サーバーで共通する設定、サーバー種別ごとに固有となるOSやミドルウェアの設定を実行したうえで、意図したとおり構成されているかをテストする。
手順書どおりに人がコマンド操作する従来の構築手法では、案件の複雑さにもよるが、1台当たり半日～1日程度かかることが多い。また手動作業では、操作ミスや抜け・漏れは避けがたい。そうしたなかで各々のサーバーの設定品質を担保しようとすれば、テストや修正作業で膨大な工数を費やすことになる。
これらの点から、従来手法では数十台・数百台という大規模環境の構築や、ビジネス・アジリティを支えるような短期間での構築には対応できない。
この課題への対応策としては、各工程にそれぞれ特化したツールを組み合わせ、構築全体を自動化するソリューションが有効である（図表1）
。
OSの新規導入に関しては基盤ごとに適したツールがあり、クラウド環境であればTerraform、オンプレミス環境であればRed Hat Enterprise Linux（RHEL）用のKickstartやUbuntu用のPreseedなどのツールが挙げられる。
また構築後のテストには、ServerspecやTestinfraを利用できる。そしてとくに作業負荷が大きくなりがちなOSやミドルウェアの設定を担うのが、AnsibleやChefなどの構成管理ツールである。
構成管理ツールでは、手順書やスクリプトのように「どのような操作をするか」ではなく、構成対象のサーバーが「どのような状態であるべきか」を定義する。
そしてそれを実際の状態と比較し、異なっていれば「あるべき姿」へ収束させるという特徴（冪等性＝べきとうせい、と呼ばれる）を備える。
つまりサーバーのあるべき状態をコード化し、継続的にそれをサーバーに反映して管理することで、単に初回の構築が自動化できるだけでなく、ドキュメント誤記などに伴うサーバー再構築・変更作業が発生した場合にも、コードの該当箇所を修正して再実行することで対応できる（図表2）。
こうした構成管理ツールのなかでも、すでにデファクトとして定着しているのがAnsibleである。他ツールがプログラミング言語でのコーディングが必要であるのに対し、AnsibleではYAMLというシンプルなテキスト・フォーマットで管理できる。これが、Ansibleが支持される理由の1つである。
これにより比較的学習コストが低く済み、コードの可読性も維持しやすい。また構成対象の各サーバーに対し、エージェントと呼ばれるクライアントソフトを導入・設定する必要がないというのも大きな利点と言える。
構築時に限定するか
トータルに自動化するか
このような利点のあるAnsibleであるが、実際の現場で適用するに際しては、目的に応じて大きく2つの使い分けができる。
1つは、構築時限定のツールと割り切り、極力作り込みを避けてローコストで利用する方法である。
たとえば、Playbookの冪等性（何度実行しても同じ状態に収束するという特性）を担保せず、既存のシェルスクリプトやOSのコマンドをそのまま実行する。
またプロジェクト終了後に組織間での横展開や運用段階への引き継ぎを考慮に入れないことで、コーディング規約やドキュメント整備に必要な調整を省く、などが挙げられる。
この場合のメリットは準備に時間がかからず、低コストでインフラ自動化を実現できることである。とくにAnsibleを適用するシステムがソフトウェアのサポート終了といった種々の理由で陳腐化するリスクを考慮した場合、仕組みづくりにコストをかけないことでそうしたリスクを回避できる。
一方で、Ansible本来の用途である運用の自動化にまでは踏み込まないため、効果としては限定的になる。
もう1つは、構築後の運用まで一貫して自動化する方法であり、組織横断的な運用の標準化も視野に入れたより大掛かりな取り組みとなる。技術的にはバージョン管理システムや他ツールと連携させることで、Playbookやパラメータの修正が入るたびに、自動でサーバーの構成・テストが実施されるインフラCI（Continuous Integration）の仕組みを整備できる。
とくに後者は、「システムの品質を保ちながら、要件の変化に素早く対応していく」という次代のインフラとしての目標を達成するうえで不可欠な取り組みであり、それだけ効果も大きい。ただしその分、乗り越えるべきハードルも高い。
ユーザーが構成管理ツールによるインフラ自動化の実績をもたない場合は、構築時限定のツールとして使用することで、まずは自動化のノウハウや実績を積んだうえで、適用範囲を拡大していくことを検討してほしい。
ここからは、構築時限定のツールとしての使い方に焦点を当て、オンプレミス環境での事例を踏まえたAnsibleの活用方法について解説する。
Ansibleの事例と活用の勘所
事例の概要
ここで取り上げる事例は、数百台規模のサーバー新規構築案件である。IBM Zの論理区画上のLinuxを対象にしたシンプル・エージェントレスといった特徴に加え、ユーザー内の別プロジェクトでもすでに実績があったため、Ansibleが採用された。
またユーザーとの要件の取り決めや、横展開の際の調整コストなどを考慮し、できるだけ作り込みを避けた構築時限定のツールとしての扱いとなった。
具体的には、Playbookの作りやすさを優先してユーザー内での既存手順に沿った実装とし、メンテナンス性や冪等性を担保しないことで準備にかかるコストを低減した。結果として、従来の手動手順の5分の1程度の工数で構築を完了している。
この事例から言えるのは、Ansibleを実際の現場で活用するには、単にPlaybook開発のノウハウだけではなく、それ以外の周辺の仕組みも合わせて整えることが重要という点である。以下にその仕組みのなかでも勘所となる、ドキュメントとテストのあり方について言及する。
勘所1. ドキュメントとの連携
Ansibleでは、構成定義書（Excel形式）としてドキュメントで管理されているサーバーの構成をコード化して管理できる。しかし長年の文化や組織・メンバー間のスキルのばらつきなどから、構成定義書自体を直ちに廃止することは困難な場合も多い。
そのため、とくにAnsibleを構築限定用ツールとして素早く活用したい場合、構成定義書自体は残したまま、それをAnsibleが読み込める形式に変換して利用することが落とし所となる。
具体的にはExcel VBAやスクリプト言語によって構成定義書のパラメータを読み込み、それを変数ファイルとしてYAML形式で出力しAnsibleサーバーに配置する。Playbookはこの変数ファイルを参照することで対象サーバーの設定を実行する（図表3）。
前術した事例では、PythonでExcelファイルをパースするライブラリーを利用しつつ実装している。
この仕組みを採用する際には、構成定義書がYAML形式への変換するプログラムで読み込めるようなフォーマットであることが前提となる。いわゆるExcel方眼紙のようなフォーマットでは表として扱うことができず、プログラムでは処理できない。
また定義されているパラメータがどのように変数ファイルとして出力され、どのようにPlaybookで処理されるのかまで見据えたうえでフォーマットが標準化されていると、スムーズにPlaybook開発を進められる。
図表4は構成定義書からPlaybookへパラメータが渡される一例である。
構成定義書には各ディレクトリのパラメータと、そのディレクトリがそれぞれのサーバーに存在するか否かがpresent/absentの値として定義されている。
たとえば、/bootディレクトリはserver2列でpresentとして定義されているため、server2用の変数ファイル内の項目（directory_items）にパラメータがKey-Value形式で出力されている。
PlaybookではこのKeyを参照することで（e.g., item.dirname）、サーバーごとに適切な設定を実行する。
このように、ドキュメントがAnsibleとの連携を前提とした作りになっていれば、Playbookもシンプルで統一された実装にできる。
勘所2. 結果の正確性の担保
Ansibleでは原則としてサーバー構成のあるべき姿を定義するため、実行に成功していれば、サーバーの状態は正しく設定されているように思える。
しかしAnsibleの処理として成功しているからと言って、意図どおりに設定できているとは限らない。Playbook自体の不備で一部の処理をスキップしていたり、実行対象のサーバーが間違っているなど、自動化の仕組み自体を人が作り上げている以上、想定外の事態は必ず発生すると考えたほうがいい。したがって、テストは必須の要素となる。
テストに関しても構築と同様の理由で自動化が有効である。ただしUT、IT、STといったフェーズやPlaybook自体のテスト、構築後の実機のテストなどさまざまな切り口があるなかで、最も負荷が高く重要となるのが、個々の実機のパラメータや挙動の確認である。
これに関するテストツールとしては、Ansible自体を用いることも可能であるほか、ServerspecやTestinfraなどが優れた機能を有している。
どのツールを用いるにせよ、個々のサーバーの正しいパラメータとしては構成定義書を参照することになる。
前述の事例では、構成定義書から変換した変数ファイルをAnsibleで読み込んで構築しつつ、同じ変数ファイルをテストツールでも読み込めるように実装して、構成定義書どおりの設定となっていることを確認している。
ただしこの仕組みは構成定義書に誤りがないことを前提としているので、複数人体制での網羅的なドキュメントレビューが求められる。
またツールを疑って、結局あとから人がレビューする、といった無駄を避けるため、テストツールの結果に対するできるだけ網羅的なレビューもあらかじめ実施しておきたい。
これを最小限の労力でこなす工夫としては、まず「開発環境APサーバー」のように、用途が同じで設定項目も共通しているサーバーグループのなかから、それぞれ1台ずつ代表サーバーを選出して最初に構築しておく。
そこにテストツールを実行し、実行結果がすべての項目をパスしていると確認したうえで、さらに実機の状態をコマンド等で取得しながら構成定義書と突き合わせ、両者の間に不一致がないかをレビューする。
ここまで確認できていれば、残りのサーバーではテストツールの実行だけで、全台同じレビューをしたのに近い状態となる。
このような地道なプロセスを踏むことにより、最終的に品質を担保しながら自動化の恩恵を最大限に享受できる。
以上本稿ではオンプレミス環境におけるインフラ構築という観点から、Ansibleによる自動化がもたらす効果や現場での活用の勘所について解説した。
ITシステムの老朽化による莫大な損失の可能性が指摘される「2025年の崖」に新型コロナウイルスの影響が重なり、DXへの対応が急務となるなか、Ansibleをはじめとする自動化の仕組みは今後さらに普及していくと見込まれる。本稿が、その際の検討の一助となれば幸いである。
著者
加村 圭史朗
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
クラウド・ソリューション
クラウド・プラットフォーム #2
ITスペシャリスト
2016年に日本アイ・ビー・エム システムズ・エンジニアリング入社。入社以来、Linux on IBM Z、Ansible、OpenShiftなどの技術支援を担当。
