Ansible のハンズオン環境を受付から構築まで自動化してみた

はじめに

弊社では、自動化推進の一環として、社内向けにAnsible のハンズオン環境を提供しています。

本ハンズオン環境は弊社の検証基盤である、Lab as a Service（以下「LaaS」）に構築されており、「Ansible Training」 というメニューで提供されています。

工数削減やサービス品質向上などを目的とし、構成管理ツールであるAnsibleとTerraform を使い、環境構築を自動化しました。

本記事では、どのように自動化を行ったのかをご紹介致します。

LaaS とは

LaaS は、お客様との共同検証専用の環境として、オンプレミスとアマゾンウェブサービス（AWS）及び Microsoft Azure などのパブリッククラウドサービスを接続したマルチクラウド環境を用意しているサービスです。

LaaS を使うことにより、以下のメリットがあります。

• 個別設備の準備が不要で、マルチクラウドをベースとした様々な先端テクノロジーを確認可能
• システムを把握するためのシナリオベースのガイドを提供
• DXに向けて設計した新ICT基盤にまとめて触れることでシステム検討時間の短縮
• 自社環境におけるPoCを実施する前にシステムや運用のコツを獲得
• システム実現に関わるセキュリティリスクを事前把握して対策手法を検討
• ネットワンの専門家からの技術的アドバイスを得られる

詳しくはこちらのプレスリリースもご参照ください。

Ansible Training とは

Ansible Training はAnsible の検証と学習を目的としたLaaS のメニューです。
※ 2022年1月現在、弊社社員のみの利用に限られています。

以下のような構成の環境になっており、リソースはAWS上に展開されています。

自動化後の構築フロー

はじめに、環境構築自動化後の全体構成を紹介します。

LaaS利用申請から環境払い出しまでの流れは以下のようになっています。

各コンポーネントの説明は後述しています。

1. 利用者がLaaS申請ポータルから「Ansible Training」 メニューを申請
2. LaaS 管理者による承認
3. 利用開始前に環境の自動構築
4. 環境構築が終わると、利用者に対しアクセス情報をチャットで通知

図中に記載の通り、LaaS 申請ポータルは弊社内のフレームワークを用いたWebアプリケーションです。

自動化前の課題

本メニューでは段階的に自動化を行っており、初期リリース時点ではAWS へのデプロイのみがTerraform により自動化されていました。

しかし、以下のような課題がありました。

• LaaS申請ポータルとIPアドレス管理台帳をもとにした、デプロイ前のパラメーター設定
• 人手によるTerraform 実行
• 人手によるLaaS申請ポータルの更新（利用者が参照するアクセス情報の更新）

本メニューの利用者数も増え、運用工数が大きくなったことから、構築から削除までの自動化を実施しました。

自動化する際のポイント

自動化を行う際は、いきなり手順の一部を自動化するのではなく、全体最適を見据え、計画、実行することが重要になります。

そのため、ファーストステップとして、現状の運用フローを整理します。

お客様の自動化を検討する際にはVSM（Value Stream Mapping）を使い、作業手順の一連の流れを可視化します。

今回は開発と運用担当が同一チームに所属しており、開発者が運用フローをある程度理解できたいたことから、VSMは作らず、運用担当者と手順書ベースで自動化箇所の検討を行いました。

単に手順の全てを自動化するのではなく、手順の見直しや、自動化によって手順そのものを削除できないかを検討します。

また、自動化の効果を計るために、自動化前の工数を記録しておきました。

ソフトウェアコンポーネント

Ansible Tower

Ansible Tower はAnsible の管理をGUI上で行える、Red Hat社の製品です。

Ansible Tower を用いると、インベントリや認証情報、Ansible実行時の設定などをジョブテンプレートという形で視覚的に設定できます。

その他にも、Ansible Tower API を用いて、他のサービスと連携可能です。

今回の例では、LaaS 申請ポータルとAnsible Tower を連携することにより、ユーザーから利用申請をもとに自動で構築が行われます。

その他Ansible Tower については、ページ下部の関連ページに記載の匠コラムもご参照ください。

Terraform OSS

Terraform はHashiCorp社が提供するIaCを実現するためのソフトウェアです。

今回はOSSのものを利用して、AWSへEC2インスタンスをデプロイするために使用しています。

NetBox（OSS）

前述のとおり、Ansible Training ではリソースをAWS上にデプロイします。

VPCやIPアドレスの管理を行う必要があるため、Ansible 実行時のSoT（Source of Truth）として、DCIM/IPAM ツールであるNetBox を使用しています。

NetBox はAPI を提供していますが、Ansible Collection としてPlugin やModule が利用可能なため、こちらを利用します。

各コンポーネントの連携

Ansible Towerが中心となり、各コンポーネントと連携し、自動化が実行されます。

元々あったTerraform はAnsible によって実行されます。

また、Terraform に設定するパラメーターはNetBox で管理されており、これもAnsible を介してTerraform に渡されます。

Ansible TowerとLaaS 申請ポータルとの連携部分では、set_stats モジュールを利用することで、実行結果の受け渡しを行っています。

これにより、構築時の情報を申請ポータル側で保持し、削除時に利用できます。

自動化の効果

自動化対象選定時に手順書をベースに見積もったPT/LT（デプロイと削除に関わる運用作業）の削減時間を以下の表にまとめています。

PTは約68%、LTは約98% 削減できました。

自動化を行ったことにより作業時間そのものを削減できましたが、待ち時間であるLT の方がより多く削減できたことが読み取れます。

実際に計測した訳ではなく、手順書ベースに概算で算出したことに注意は必要ですが、全体最適を考えた自動化を行うことでより大きな効果を得ることができます。

まとめ

弊社検証基盤であるLaaS における、自動化の取り組みをご紹介致しました。

Ansible Towerを中心として、各コンポーネントを連携させることにより、社内システムからパブリッククラウドへのリソースデプロイを自動化しました。

また、自動化の手順やポイントを紹介すると共に、Ansible Towerを用いることで高度な自動化が実現可能なことがお分かり頂けたかと思います。

商標について

• 記載されているロゴ、システム名、製品名は各社及び商標権者の登録商標あるいは商標です。

※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。