Infrastructure as Codeによるパラメータシート脱却プロジェクト

みなさんは、エクセルで作られたパラメータシートの管理にお困りではないですか？

• 最新バージョンのパラメータシートがどれなのか分からないので探す。
• 見つけたパラメータシートの値が合っているかを確認するために、それぞれの機器へログインする。
• 間違っていたらパラメータシートを書き直す。

大変ですよね。

このブログでは、（Infrastructure as Code： IaC）によってパラメータシート文化から脱却しよう、というわが社の取り組みについてご紹介します。

プロジェクト発足経緯

ネットワンシステムズでは、「netone on netone」 と社内で呼んでいる、”ネットワン社内でユースケースを作りお客様に展開して行こう”という活動があります。今回はインフラ基盤の実装に関わる要件定義、設計、構築業務を行っているシステム技術部を舞台にして実施しました。

IT人材の不足が叫ばれる昨今、同じ作業の繰り返しから卒業して新しい事にチャレンジする時間を作りたい、という要望はどの企業も持っている課題です。当社のシステム技術部も例外に漏れず、どうにかエンジニア工数を削減できないかと頭を悩ませていました。そこで、目を付けたのが IaC です。IaCとはソフトウェア開発で実施されてきたプロセスをインフラの世界に適用し、インフラの構成情報、構築・運用に関わる手順をコード化する事です。

インフラにIaCを取り入れるメリット

IaCを取り入れるためには、日々の構築・運用文化そのものを変えていかなければならないという大きなハードルがあります。しかし、我々にはインフラにIaCを取り入れる事による大きなメリットが３つ見えていました。

1. 構築が自動化される
2. 構成管理が容易になる
3. パラメータシート文化から脱却できる

1. 構築の自動化

今回のプロジェクトでは、Ansibleというインフラ構成自動化ツールを利用しました。AnsibleはインベントリとPlaybookという2つのファイルで実行します。インベントリとは、設定対象機器のリストファイル、Playbookとは設定状態を定義したファイルになります。この2つのファイルを指定して実行することで対象機器に設定が自動で投入されます。またAnsibleによってインフラ情報を取得することも可能です。

ここでのポイントは下図のPlaybookにあります。Ansibleは自動化を行うという目的に留まらず、yaml形式という構造化されたテキストファイルでインフラの状態を表現できるというメリットがあります。またキーに対する値を変数にすることで、別で変数ファイルを作成し、エクセルでパラメータシートとして表現していたファイルの代わりにyaml形式の変数ファイルとして扱えるようになります。これが 2. 構成管理の容易さへと繋がっていきます。

2. 構成管理が容易になる

Ansibleにより、Excelのようなバージョン管理しにくいバイナリファイルからテキストファイルになったことで、gitのようなバージョン管理ツールでの管理が可能になり、バージョン間の差分の可視化や、ロールバック、GitLabによるプロジェクト管理が可能になります。また、ここで冒頭にあるパラメータシートの問題点すべてが解決できます。

GitLabによるバージョン差分の可視化

３．パラメータシート文化からの脱却

Yaml形式などの構造化されたテキストファイルはアプリケーションによる加工が容易なため、従来のExcelパラメータシートに代えてWebアプリケーションなどでのプレゼンテーションが可能になります。更にはAIを使った自律型のインフラへの可能性も広がります。

パラメータシート脱却プロジェクト

では、実際に我々が実施したプロジェクトの中身を見て行きましょう。

1. スキル

まず初めに取組んだのは、IaCを実現するためのスキルの習得です。

今回必要なスキルはAnsibleとGitLabでした。GitLabについては、社内でHandsOn形式の勉強会を開催しましたが、Ansible習得については、Ansibleユーザー会というコミュニティで開催される勉強会に参加しました。あえて外部の勉強会に参加することで、オープンソースの空気に触れ、新たな自動化活用法を見出す糸口としました。

2. Playbook

次に取り組んだのがPlaybookの作成です。

Playbookは、Ansibleのドキュメントにベストプラクティスがあり、ディレクトリ構成などは、このベストベストプラクティスに従って作成するのが望ましいとされています。しかし、組織のAnsible習熟度、また運用方法に適切でなければ、必ずしも従う必要はありません。

今回はコードの再利用と、システム技術部全員で利用するための分かりやすさ、Ansibleを触り始めたばかり、という点を踏まえ、includeを使ってPlaybookを読み込む前に、include_varsを利用し変数が必要な場合に都度読み込む形をとりました。実施したいタスクと変数の部品を並べて書けば、様々なパターンに対応できます。

3. パラメーターシート

IaCのメリットにおいても述べたとおり、Excelのパラメータシートが構造化されたテキストファイルになったことにより、PDFに出力する事もできるWebアプリケーションが完成しました。

まとめと今後の展開

IaCをインフラに適用することのメリットは、自動化だけでなく、構成管理が容易になりパラメータシート文化から脱却できるという大きな変化です。これによって、肉体的にも精神的にも負荷が減り、生産性が上がり、時間ができることで新たなチャレンジが生まれ、業績が上がる機運も高まるのです。

約3か月でプロジェクトの方向性を決め、技術習得、Playbook、パラメータシートに変わるwebアプリケーション等の部品が出来上がりました。今後はお客様先でのPlaybook適用、部全体にまたがったIaCの活用、作成した部品を繋げるためのパイプライン作成など実際に利用していくフェーズに入っていきます。その中で、壁が次々と出てくることが予想されます。

しかし我々は、１つ１つ克服しながらInfrastructure as Codeの世界を実現していきます。FY19の終わりには、壁をどう克服したか、みなさまに続報をお伝えできればと思います。

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