そのAnsible Playbook，本当に実環境で動くの？

次のセッションは、OpenStackのミートアップやカンファレンスではお馴染みのNTTの露崎氏のセッションだ。「そのAnsible Playbook，本当に実環境で動くの？」と題されているように、Ansibleの設定実行ファイルであるPlaybookを実際の環境で実行する際のテストの方法に関して、実際に使っている経験を解説している。

Ansibleの難しいところとして挙げた仕様上の問題点

このスライドでは、Pythonで開発されているAnsibleの根本的な仕様に由来する問題点を挙げている。特に扱う対象がサーバーやネットワークデバイスであるということを考えると、単純なスペルミス、タイプミスでも環境が壊れてしまうことを解説している。またインタープリター言語であるため、静的なチェックが行えないということも説明している。

また実際にNTTでの所属部署において、自動化の一環としてCI/CDについてはGitHub Actionsを使っている理由についても解説を行った。ここではコンテナ系のCI/CDツールではなく、実行単位が仮想マシンをベースにしたCI/CDのツールであるGitHub Actionsを推している理由を解説した。

GitHub Actionsを使ってAnsibleをテスト

サンプルとしてAnsibleのコマンドラインを挙げて説明し、認証やテスト環境、スキップしたいタスクにタグを付けて設定するなどを説明した。

実際のコマンドラインの例を使って解説

また実際に運用を行う中で遭遇したトラブルについても、例を挙げて解説した。3つ目の例ではMySQLを内部で使っているツール（Slurm）を取り上げ、MySQLのマイナーバージョンアップ時に非互換な変更がなされたことで立ち上がらなくなったという例を解説した。この例では、Ansible側では何も変えてないのにシステムが動かなくなったわけで、エンジニアにとっては悪夢のような状況であったことがわかる。

何も変えてないのにトラブルが起こるという例を紹介

次にAnsibleのテスト自動化による効果を解説し、開発スピードが加速したことを紹介した。

テスト自動化の効果。開発から実装が継続的に行えるようになった

露崎氏は、GitHub Actionsを利用し始めてから「修正はバージョンアップにまとめて行う」というやり方から継続的に小さな修正を実装できるようになったと語り、開発のコミット数が平準化されているというグラフを使って説明した。

最後にAnsibleの良さと静的テスト、動的テストに対する知見を紹介してセッションを終えた。このセッションは、実際にNTTの中で得られた経験をベースにしているだけに、よりリアルな教訓として受け止められるのではないだろうか。どちらのセッションも運用エンジニアとしては知りたかったポイントだろう。ただNTTの事例については、そのシステムの規模や組織の構成、背景などを理解した上で応用する必要があるだろう。システムの規模などが異なる組織で単純に真似てみても、簡単には上手くいかないと思われるからだ。