Ansibleで大変だったIssueとCIの管理　モジュール、Role、Playbookをワンパッケージで共有できる「Collections」

Ansible 2.9の大きな課題「Ansible本体とモジュールが1つのリポジトリで管理」

大嶋健容（以下、大嶋）：では私から、軽くAnsible Collectionsの概要のお話をしようと思います。

その前に、「そもそもCollectionって何ぞや？」という方がおそらくけっこういるのかなと思ったので、まず、Collectionsの概要を5分ほど簡単にお話しようと思います。よろしくお願いします。

自己紹介です。大嶋といいます。「Red Hat」で、Ansibleを中心にした自動化の支援をするコンサルタントをしています。

個人的に、前職からVMwareとかを使ったインフラ基盤みたいなものを作って、自動化をしていた手前もあって、VMwareが好きで、Red Hatの社員ですがなぜかVMwareのvExpertを持っているという、ちょっと不思議な感じでやっています。

さっそくですが、今みなさんが使っているのはAnsible 2.9だと思うのですが、現状のAnsible 2.9と、2.10、今後のバージョンの違いのところですね。課題と特徴について少しお話をします。

従来のAnsible 2.9は課題がいくつかあって、その中でも大きな1つは、Ansible本体とモジュールが1つのリポジトリで管理されていて、かつそれがワンパッケージで提供されていたところです。

これの何が課題かというと、下のほうにも書いているのですが、Ansibleにはモジュールがすごくたくさんあって、それを1つのリポジトリで管理してしまっている手前、Issuesの数がすごく多かったり、プルリクエストがバーっと、モジュールごとに来るので、それの管理が大変だったり、テストのところですね。CIの部分の管理が非常に大変でした。

CI環境で特にどういうところが大変だったか、課題だったかというと、アップストリーム側です。CI環境は事前にアップストリーム側が用意した環境でやる必要があって、すべてのモジュールが、自分たちの開発している品質面でパスする環境かと言われるとそうではなくて、できるところまでやりましょうというかたちで進めていました。

また、モジュールの修正も、大きな1つのリポジトリでやっていたのですが、新規機能やバグフィックスをリリースするのはAnsibleのリリースサイクルに合わせる必要がありました。

例えば、Ansibleのマイナーバージョンが出た次の日に、モジュールのバグフィックスをやったとしても、それが反映されるのは、次のAnsibleのリリースで、それまで待つしかないのが課題でした。

今モジュールが、どんどん増えているのですが、その増加に対する対応がやはり不十分という課題ですね。

また、先ほどもお話ししたとおり、リリースサイクルに合わせる必要があって、モジュールの開発者の人たちは、瞬時にバグフィックスを直したらリリースしたいのですが、Ansibleに依存して、それがなかなかできないというジレンマがありました。

課題解決のためにAnsible 2.10以降は軽量化

そこで、アップストリーム側がとったのが、このAnsible 2.10以降の特徴です。この課題を解決するためにはこうしていこうというのが、次のところになっています。

今どうなっているかというと、Ansible本体と最低限のモジュールにそぎ落としして、軽量化しています。

今は「ansible-base」と言われるものが2.10で、次の「ansible-core」が、2.11の名前なのですが、今はこのように変更されています。

今まで含んでいたモジュール類が、このCollectionという単位で外出しになりました。

今は、本体と最低限のモジュールがワンパッケージ化されています。それで提供されているとお話はしたのですが、実は、Collectionsが含まれているAnsibleバージョンというのがあって、それがAnsible 3.ペケペケと4.ペケペケになっています。

こちらは、本体プラス最低限のモジュール、プラスCollectionsの対比表です。3だとどのようなCollectionがインストールされるのか、4だとどういうものがインストールされるのかは、GitHubのリポジトリで管理されているので、興味がある方はのちほどご参照ください。

Ansibleと本体とCollectionのリリースは、これで非同期で対応可能になって、リリース速度の加速が見込めるようになりました。

今までワンパッケージで管理していたモジュールが個別化されたので、利用者はAnsible本体プラス最低限のモジュールと、必要に応じてCollectionsを取捨選択してインストールできます。

Collectionsの特徴ですが、ここも簡単にお話しすると、Collectionごとに独立したので、それも独立したリポジトリで管理が可能になりました。

独立して管理ができるようになって、何がうれしくなったかというと、先ほどの煩雑化していた管理画面で、IssuesやプルリクエストがCollection単位で管理ができるようになったことと、リポジトリ単位で管理ができるので、CIの作り込みも、各々のCollectionの開発者たちで自由にできるようになったことです。

かつ、Collection単位でバージョンの管理とか、リリースサイクルが決められるようになりました。Collectionsというパッケージの中では、モジュールだけではなくて、Roleだったりフィルターだったり、あとはPlaybookだったりを1つにまとめて提供できるようになっています。

Collectionsの配布の方法と商用サポート

配布方法ですね。Collectionsの配布の方法ですが、Roleの配布方法と一緒で「Ansible Galaxy」などから配布が可能となっています。Collectionsのパッケージをtarballにして、Galaxyに登録することで、Galaxy経由で自作のCollectionを配布することが可能です。

あとは、GitHubとか、GitLabのリポジトリから直接ダウンロードしてインストールすることも可能になっています。

Collectionが個別化して開発できるようになりましたよという話をしてきたのですが、次はこれが商用目的の場合だとどうなるかについて少しお話しします。

Collectionという1つのパッケージで管理ができるようになったので、商用目的の場合でもCollection単位でRed Hatで認証申請が可能になりました。

あとは、Collectionsの商用サポートですね。Red Hatのページを見てもらうと、商用であればこれがサポートされているよというリストが載っています。Ansible Galaxyからダウンロードするものは、基本的にはコミュニティサポートだと思ってもらえれば差し支えないです。

最後ですが、サポートバージョンですね。CollectionsがどのAnsibleでサポートされているかですが、基本Ansible 2.9をお使いのみなさまであれば、Collectionsが問題なく使えます。

ただ1点注意なのですが、各Collectionによってサポートしているバージョンが、実は微妙に違います。例えばAnsible 2.9.18であれば、その2.9.18がCollectionでサポートされているかは、リポジトリのREADMEに書いてあるので、そこを確認いただければと思います。

私からは、簡単にCollectionsの概要についてお話ししました。開発の経験談については、セイコーソリューションズ株式会社の中山さんからお話をいただこうと思いますので、よろしくお願いいたします。

Collections対応前は独自パッケージを用意してお客さまに提供

中山真一（以下、中山）：では、「対応してみたベンダー 体験談」ということで、セイコーソリューションズ中山から発表したいと思います。

ソフトウェアエンジニアをしていて、担当製品のAnsible Module等の開発をしています。

今日お話しする内容ですが、Ansible Collectionsという仕組みができたので、国内の各ベンダーさまのAnsible対応の加速の一助になるというところを狙いとしています。

モジュールの増加が、やはりAnsibleの「パワフル」というところを支えているし、できることが広がると思っているので、開発者の方にとって有益な情報であれば幸いだと思っています。

ユーザー数は、Ansibleの利用者に対して開発者が圧倒的に少ないと思っています。内容が直撃して参考になるという方は、実は少ないかもしれませんが、対応するベンダーが増えると、その後ろに喜ぶユーザーがたくさんいるのかなと考えています。

担当の製品ですが、ニッチなネットワーク機器の対応をしています。「Ansible Webinar」があるのでよかったら参照してみてください。

ここまでの対応背景ですが、2019年4月に、AnsibleModuleは初回リリースをしています。2020年2月に行われた、ディベロッパー部で「はじめて対応してみた話」として、ネットワーク機器のモジュール開発の話もしているので、興味のある方は資料も参照してもらえればなと思います。

今日の内容ですが、なぜCollections対応することになったか、対応前はどういう体制であったのか、実際対応してみた開発の話と、会社として対応しようとした背景を少しできればなと考えています。

まず背景の、対応前の開発や、どういうふうに提供していたかですが、対応前は私たちは独自のパッケージを用意して、お客さまに提供する方法をとっていました。

オープンソースとしてAnsibleに含まれないモジュールだったので、ユーザーのAnsible環境に製品用のモジュールをインストールすることで、利用可能にしていました。

なので、独自にパッケージを作って、インストーラーも用意して、モジュールやプラグインをお客さまに提供して、インストールして、直接Ansibleのソース上に入れるというアプローチをとっていました。

Collection対応のきっかけと目的

開発の課題は、Ansibleのバージョンアップ追従で、バージョンごとにソースの構成が変更になったり、機能追加があったりで、そこに都度対応していくのが非常に大変でした。

ソースツリー自体が変更になってしまう時もありますし、Ansibleの機能追加によって、ファイルの修正が必要だったりと、Ansible側の機能追加に対応していくのに、ソースのツリーがすぐ変わってしまうところは、開発していくうえでけっこう大変でした。

ただ、対応していかないと一部機能が使えなくなることも発生していたので、ここは常々課題だなと感じていました。

ほかにはユーザーへの提供方法ですね。ここはお客さまの入り口になるのですが、これまでは会社のホームページからフォームを入力して提供するとか、お客さまのところに訪問した際に直接案内して提供するというところですね。

提供方法は、ユーザーごとに個別にアクセスして送付していました。このあたりもホームページ経由で、Ansible用のドキュメントを使っていましたが、それもフォームを入力してダウンロードしていたのが、Collection対応前です。

実際に2019年4月にAnsible 2.7対応でリリースしましたが、Ansibleのバージョンアップに追従していくために、都度都度、開発が必要になりました。

最初はその機能追加等々があって、がんばっていたのですが、Ansibleのバージョンアップに追従するためだけにいろいろやっていくのが、だんだん大変になってくるのが実感としてありました。

そんな中、2.10のリリース頃にAnsible Collectionsの実装が本格的に始まりました。

ここですね。対応したいなと思ったところですが、Collectionsの特徴ですね。

モジュールの修正など、機能追加ごとにAnsibleのリリースに対応する必要がありました。非同期で対応できるというところがありましたが、オープンソースのAnsibleについては、確かにそうだっただろうなと思っています。

ただ、私たちはオープンソース側にソース用意していないので、ここはそこまで変わらないかなと思います。

そのかわり、ベンダーのモジュール類を、Collectionという単位で外出しできるというところ。Ansibleの本体側に移動しないで管理できるので、ここはやはり対応していきたいところです。

あとは、インストールもAnsible Galaxyというコマンドになるので、そのあたりも対応していくとよいかなと思っていました。

また、提供面でも、社内工数の削減という意味で、Ansible Galaxyからのダウンロードとか、GitHubに公開とか、比較的クローズな今の状況からオープンになることで、なにかプラスの方向に働くんじゃないかなという期待もありました。

ユーザーからすると、Ansible Galaxyのサイトからダウンロードしてインストールするという、ほかのベンダーのモジュールと同じようなオペレーションができるところが利便性の向上につながるかなと思っていました。

また、ユーザーからもCollectionsに対応してという声はあったと思います。私たちにとっても、Ansible Galaxyにアップロードして、そこからダウンロードして使うというところで、独自に配布していたところから、もともとのAnsibleツールにあったものと同じように扱えるようになるので、うれしいなと思っていました。

開発では公式ドキュメントやブログを活用

主に開発面の話になりますが、開発にあたっては、公式ドキュメントでGalaxy用のユーザーガイドや、ディベロッパーガイドがかなり充実していて、非常に参考になりましたし、実際にAnsible Collectionsのリポジトリですでに公開されているモジュールは非常に参考になりました。

また、対応するタイミングで、ここで紹介しているブログもあって、本当に助けられたなと思っています。

いざ、開発を始めるというところですが、まずNameSpaceやバージョンを決めます。このNameSpaceは、「galaxy.yml」という定義で指定するのですが、ここのNameSpaceをどうするかを最初考えるところがやや悩みました。

個人でモジュールを作って公開するのではなく、会社として対応するので、どういうNameSpaceにするべきか、非常に調整等々が大変だったし、悩んだし、苦労しました。

私たちの会社は、ネットワークベンダーというよりもほかのもののイメージが強かったりするので、そのあたりを使っていいのかというところが、やや大変でした。

ほかの会社の方が対応する時も、商標云々とか、いろいろケアするところはあると思うので、そのあたりの確認は必要かなと思います。会社として対応する時は、そういうところを考えなくてはいけないと思いました。

通常、Ansible Galaxyにログインして公開しようとすると、Ansible Galaxyのログインユーザー名がNameSpaceとして割り当てられるのですが、申請すると任意のNameSpaceが取得できるので、今回は申請してNameSpaceを取りました。

バージョン名なども、独自にリリースしたバージョンがあったので、その続きをAnsible Collectionでも使うというところでは、ここはベンダー独自でもいいのかなと思います。

また、実際に公開したあとを考えて、Ansible Galaxy自体を社内にも構築しました。

Ansible Galaxyの本番サイトは、一度アップロードしたらモジュールは消せず、同じバージョンも再アップできないので、やはり公開前に社内で確認しなければいけないところがありました。

実際に、オープンソースで構築方法が公開されているので、モジュールの動作確認、社内検証、こうやって使うというところも併せて社内で作っておくのは必要だったかなと思っています。

あとは、Collectionのドキュメントですね。ドキュメントセクションがソースの中にもあるのですが、そこからrst形式のファイルを自動生成してくれます。また、Galaxyのサイトで各ベンダーさんのモジュールを見ると、よく表やバージョン名が表示されていると思うのですが、このあたりはよしなに、マークダウンに反映してくれるツールがあって、非常に使いました。

「Ansibleコレクションのモジュール作ってみた」というエントリーと併せて、昨年の「Advent Calendar」でこのあたりの情報があって、こういったブログ等がなかったらこのあたりのツールも知らなかったので、非常に参考になりました。ちょっと紹介しておきます。

あと、これは独自モジュールの時からそうしておくべきだったのですが、今後対応していって、メンテナンスしていくところもあって、テスト自動化のところはあらためて作りました。

いわゆるGitを使って、ペケペケアクションするところまではまだ来ていないのですが、Ansible Collectionの対応にあわせて、テストの自動化の実行部分は構築しました。

実行の一部はAnsibleで、それが合っているかどうかはスクラッチで作成しました。Ansibleのバージョンアップごとに、実行結果が微妙に変わったり、エラーのログもあるので、差分抽出も可能なかたちです。

テスト内容は、全モジュールの全オプションを実機と連携して行うとか、社内で構築したGalaxyからモジュールを落としてきて動くとか、Ansible Galaxy自体のコマンドのオペレーションなどができるようにしています。

また、テスト関連で「ansible-test sanity」というコマンドですね。このあたりもコードを作りながらやっていくうえでは必要だったかなと思います。静的コードチェッカーなのですが、ドキュメントセクションと実際のコードが一致しているか、モジュールオプションの選択肢、デフォルト値、型が合っているかどうかも含めて確認してくれるので、モジュール開発のうえで必要なツールかなと思います。

実際の開発途中は、先ほど話したtestのsanityを流しながら作って、モジュールを固める時は、バージョン名を与えて、Build用のPlaybookを流して固めます。

実際に「.tar.gz」のかたちでできるので、それをGalaxyの社内用の配布サイトにアップロードして確認していくというところを、開発時は行っていたかなと思います。

オープンソースでの公開は会社としてもよい経験になった

開発のテクニックの話は以上で、実際にオープンソースで公開する時はどうだったかというと、私たちの会社の基本的な考えとして、オープンソースで公開するものは公開情報として扱うというポリシーをまず決めました。

それによって、やりやすくなったかなとは思います。会社としても公開すること自体がなかなかない経験だったので、いろいろな確認は行ったのですが、部門の内外含めて、リスクばかりを言うようなこともなく後押しするような声が多かったのは、非常に助かったと思っています。

ただ、開発して認定して公開するのがOKになったあとに、GitHubや、Galaxyに上げるというフローはとっていました。

会社によっては、公開することに抵抗があるところもあると思いますが、Ansible Collectionsは、Ansible Galaxyコマンドを使って、ファイルを指定したインストールも可能なので、必ずしもGitHubやGalaxyに公開しなくても、Ansible Collectionsに対応できるかなと思っています。

公開する時には、開発したソースはGitHubにアップして、tarballはGalaxyにアップしてお客さまに提供するのが、今の仕組みかなと思っています。

最近のリリースというところで、けっこう間が空いてしまった時期もあったのですが、2.11も対応してリリースできて、ようやく、引き続きAnsibleをサポートしていく体制が整ってきたかなと思っています。

標準化されたAnsible Collectionsというエコシステムのルールに従ってやっていくことで、やることが明確になってよかったのかなと思っています。

継続してメンテナンスできる体制になってきたことを実感

最後は、会社としてどう考えているかというところと、まとめになりますが、会社としては、Ansible対応は、製品の付加価値向上がもともとの位置づけでした。

実際にこのモジュールで、お金取るどうこうはあまり考えてなかったので、Collections対応や、オープンソースとして公開するところで、社内で意見がぶつかることはあまりなかったと思います。

こういったエコシステムに対応することで、ユーザーさんにとって使いやすくなるんじゃないかなという考えのもと行ってきました。

また、対応するモジュール等々も、これをきっかけに公開情報に変更したり、少しずつオープンにしていけているかなと思っています。

Ansibleに対応して約2年ぐらい経ったのですが、利用ユーザーも少しずつ増えてきているので、対応できるタイミングとしてはよかったと感じています。

最後に、まとめですが、こういったCollectionsに対応するところですね。いろいろ取り組んで、まだまだ改善点は多いし、特にCI/CDをもっと改善していかなくてはと思っていますが、継続してメンテナンスできる体制になってきたなと思っています。

オープンソース公開などをはじめとした社内のノウハウも蓄積したし、新しいことをやるいいきっかけになったのかなと思っています。

Ansibleのバージョンアップ自体はこれからもあるし、提供する私たちも新しい技術をどんどん学んでいかなくてはいけないので、そのあたりの技術を楽しみながら、引き続きメンテナンスしていければなと思っています。

資料内でもあった、Ansibleのコミュニティの方がイベント等で公開している情報は、私自身すごく助けられて、こういった開発ができています。

運用の使い方と比べて、こういった開発視点の情報はまだまだ少ないと思うので、Collections対応を考えている方に、今日お話しした体験談が少しでも役立ったら幸いと思っています。

以上です。ご清聴ありがとうございました。