Ansible Night Online 2021.02に参加しました。
2021/2/10 19:00-21:00に開催された、Ansible Night Onlineに参加しました。
ブログ枠で応募していたこともあり、参加レポートを書かせていただきます。
アーカイブはこちらから。
- 全体を通して
- 『AnsibleFest2020 Recap』～技術トピックのまとめ～さいとうひでき さん
- 『組織で自動化に着手する前に行うべきだと感じた3つの下拵え』鎌田 健司 さん
- 『極度自動化したいといわれて困った話 ～某自動化推進チームの場合～』ウォーカー イアン さん
- ～ここからLTセッション～
- 『チームでPlaybook開発する時の心構え/仕組みづくり』jiro01030 さん
- 『Ansible Towerをみんなで使うためにやったこと』hito58 さん
- 『MSP企業でAnsibleを浸透させる難しさ』10key3 さん
- 『モジュール開発と運用』naka-shin1 さん
- 『AnsibleとCloudFormationの組み合わせでトレーニング環境を運用している話』 mito さん
- 『自滅のAnsible』しゃういち さん
- 運営に関連したInformation
- 謝辞とまとめ
全体を通して
今回は、メインテーマが「運用」にまつわる点だったこともあり、皆様の様々な苦労話が盛りだくさんで語られていました。
私は業務でAnsibleを全く使っていないこともあり、Ansibleに特化した話では実感がないのですが、他のプロダクトなどで自動化の推進を検討したこともあり、「同じようなことで苦労するだろうな」というのは実感していました。
やはり、皆さん口をそろえて「銀の弾丸ではない」とおっしゃられていたのがとても印象的でした。
運用回というのもありますが、割と最近学んだITILv4の「従うべき(7つの)原則」と共通する部分があるなあと感じました。以下がその原則です。
- 価値に着目する
- 現状から始める
- フィードバックをもとに反復して進化する
- 協働し、可視性を高める
- 包括的に考え、取り組む
- シンプルにし、実践的にする。
- 最適化し、自動化する
特に、4～7番目に該当する内容を皆様お話しされていたなあと思います。上記は順番も重要で、「自動化」は最後なんですよね。その前に最適化があります。
もし興味を持たれた方がいらっしゃれば、ぜひITILv4も学んでみていただければと思います。
『AnsibleFest2020 Recap』～技術トピックのまとめ～さいとうひでき さん
www.slideshare.net
Red Hatの「怪しくない」さいとうさんによる、Ansible Fest 2020の中の技術セッションの中から気になった点として、以下の2つの技術トピックをご紹介いただきました。
- Private Automation Hub
- Ansible Runner/Ansible Builder/Receptor
この内容ですが、最後のReceptor以外は、昨年のAnsibleアドカレの最後を締めていただいた、赤帽エンジニアブログの以下の記事でもご紹介いただいていましたね。
Private Automation Hub
すごく簡単に書くと、コミュニティ版のAnsible Galaxyサイトとも、Red HatさんのAutomation Hubとも異なる、完全にプライベートなAnsible Galaxyを立てられる機能とのことのようです。
OSSのGalaxy NGをベースに開発が進められているプロダクトとのこと。現状はまだ商用利用の品質までには達していないようですが、動くには動くとのことです。
また、単純にプライベートなCollectionsを置くだけでなく、上述したコミュニティ版のAnsible GalaxyやRed HatさんのAutomation Hub上に公開されているコンテンツのキャッシュも可能なようです。
Collectionsの入手はansible-galaxyコマンドで実施しますが、その接続先はansible.cfgで定義可能であり、その接続先としてPrivate Automation Hubを設定することも可能とのこと。 自組織で利用するGalaxyの入手元を一元管理できる、という意味ではとても有益だなと思いました。
Ansible Runner/Ansible Builder/Receptor
前半二つは、Ansible実行環境のコンテナ化！というのがメインテーマです。
- Ansible Builderで、Ansible実行間環境のコンテナイメージを行う
- Ansible Runnerで、Ansible Builderで作成したコンテナ環境を利用してPlaybookを実行する
Ansible Runnerの次期バージョンが2.0で、そこからコンテナベースの実行環境に対応する、とのこと。
不勉強なため、それまでのAnsible Runnerがどんな目的で活用されており、どんな環境に対応できていたのかなどが把握できていないため、また調べてみようと思います。
Receptorは、20スライド目に概要図がありますが、Ansibleのコントロール環境と実行環境を分離しつつ、コントロールノードからメッシュネットワークを経由してPlaybookやモジュール、認証情報などを転送し、ワーカーノードで実行する、という構成が可能なようです。
大規模な環境での分散実行に活用するものなのかな？とも思っていましたが、単純にコントロール環境と実行環境が分離できる、ということでもあるので、コントロール環境から直接接続できない、これまでは踏み台などを経由して実行していたような環境に対してのPlaybook実行などでも利用できるのかもしれません。
これ、Towerだけでなく、今後コミュニティ版のAnsibleでもこのような構成が利用可能になる、ということもありえるのでしょうかね…？
『組織で自動化に着手する前に行うべきだと感じた3つの下拵え』鎌田 健司 さん
www.slideshare.net
お次は鎌田健司さんから、以下の3つの「下拵え」をテーマにしたお話を聞くことができました。
- 上司に対しての下拵え
- 自動化対象選定の下拵え
- チームでの自動化開発に向けた下拵え
冒頭にお話しされていた「ペットと家畜」のお話がとても印象深かったです。
ググッてみたなかでは、このサイトがわかりやすくまとまってるなと思いました。
書籍では、インフラCI実践ガイドなんかにもこのあたりのことは書かれていますね。
パブリッククラウドで利用可能なコンピュータリソースについては家畜として利用可能になるケースも多いと思いますが、 私のメインのお仕事はネットワーク機器関連なので、物理的なハードウェアありきなところもあり、「家畜」にしづらいところだよなあと感じています。
今回のプレゼンはNWに特化したお話ではありませんでしたが、お仕事ではNWの自動化に取り組まれているということもあり、ペットと家畜の線引きを実NW環境ではどうやって考えられてるのか、細かいお話を伺ってみたいなあと思いました。Ansible飯にも参加したのですが、そのあたりのお話ができなかったので、機会を見つけてお話を伺いたいなと思いました。
- 心理的安全性が大事！
- 現在の業務分析／運用見直しは必須である点や、その実現手法
- 必ずしも効率化につながるものではない点（保守工数は無視できない）
- すべてを自動化するのではなく対象の見極めが重要である点
- 自動化を属人化させないためにも、事前に決めておいたほうがいいルール
など、「自動化ツールを入れたから全部よくなるでしょ！」という幻想を打ち砕きながらも、それでも前に進むための準備に関するノウハウが盛りだくさんなお話でした。
プレゼンの中で「少量のPlaybookでも、Assertが300行くらいある」というお話がありましたが、その裏事情などもツイートしていただいていました。また参考にさせていただきます。
私の書くPlaybook/Roleでassertが300行とかになる理由はコチラ。(使う変数は全て型や危険な値が入力されていないか確認している事が大きい)https://t.co/SeMcYM8JwT
— GardCruger (@Gard_Cruger) 2021年2月11日
『極度自動化したいといわれて困った話 ～某自動化推進チームの場合～』ウォーカー イアン さん
Ansible Automates 2019でとても素晴らしいプレゼンをされていた、株式会社JALインフォテック ATLASチーム リーダーのイアンさんによる、ATLASチームの歩みと今後の展望に関するお話を聞くことができました。
「Automation Tooling And Standards」略して「 ATLAS」という、自動化に特化した組織を編成されているJALインフォテックさんの、自動化に関する取り組みは毎度勉強になります。
やはりここでも、前述の鎌田さんのプレゼンと同じく、「ペットと家畜」のペットモデルからの脱却や、「現状把握」から始めることの重要性や実現手法などがうたわれていました。
この2件のプレゼンは、両者ともRedHatさんのディスカバリーセッションなどのサービスを利用されているようでした。
自組織だけの力で進めることができるケースもあるとは思いますが、やはりこれまでかけてきたサンクコストに引きずられてうまく業務見直しができなかったりするケースも多いと思います。自組織での業務分析が難しい場合には、うまく外部のリソースを活用することが重要だなと改めて思います。
順調に歩んでこられているATLASチームに見えますが、現在の課題はGUIでしか操作できないミドルウェアの自動化とのこと。また、「自動化の効果がないから」ということで利用されなくなってしまっているというケースも発生しているとのことでした。
鎌田さんのセッション、イアンさんのセッションに共通する点として、やはり「自動化の効果や向いている範囲、それを進めるにあたって想定される課題を組織全体で合意しておくこと」の重要性を改めて感じました。
～ここからLTセッション～
『チームでPlaybook開発する時の心構え/仕組みづくり』jiro01030 さん
www.slideshare.net
いろいろあってLTトップバッターになったのは、jiro1030さん！
チームでPlaybook開発をされた際に、役割分担やGitに関するスキトラやレビューのルールを決めたものの、レビューの指摘などでモチベーションや作業効率が下がってしまったとのこと。
改善のために、レビューなど人手でのエラーチェックではなく、仕組としてエディタ(VSCode)のansible-lintを活用することで、非常に効果があったとのこと。
また、品質を担保するためにAzurePipelineを活用したインフラCIのパイプラインを作成されたそうです。詳細な内容は以下のQiita記事をご参照ください。
最後のまとめで「メンバーのモチベーションの維持が何より大事」と書かれていました。
仕組みで解決できる部分と、そうでない部分があります。
仕組みで解決できない部分の作業があるからこそ仕組みが生きるわけなので、仕組み「だけ」に注目するのではなく、チームとしての心理的安全性を高めていく努力は常に必要だなと改めて感じました。
『Ansible Towerをみんなで使うためにやったこと』hito58 さん
Ansible Towerの運用を楽にするために以下の工夫をされているとのことで、その具体的な背景についてお話を伺うことができました。
Playbookの実行内容によっては、同じホストに対して直接操作する場合もあれば、コントローラ経由で操作する場合もある環境とのことでした。必要なパターン毎にインベントリを定義していると、Tower ライセンス数を決めるhosts数が実サーバ台数よりも多くなってしまい、余計なライセンス費用が掛かってしまうという課題があったそうです。
そのため、インベントリを共通にしたうえでグルーピングやPlaybook上での呼び出し方で課題を解決されたようです。
後者のリポジトリ周りは、同じ環境が作りやすいのはよいですね！
ただ、現在学習中の箇所でもあるので、良い/悪いについてコメントできず…人に説明できるようになってから改めて参考にさせていただこうと思いました。
『MSP企業でAnsibleを浸透させる難しさ』10key3 さん
夜間メンテに関するカイゼンに端を発して、定型作業の自動化、設定対象のグループ化、業務の標準化をトライされたものの、5年たってもうまく浸透していない、とのことで、なぜ浸透していないのかという点に関しての考察を発表いただきました。
割と自分もよくやりがちなのですが、「便利だから使ってほしい」という思いだけが先行してしまうと、周りが付いてこないということはよくあると思います。
10key3さんも、前半の発表を聞いて思うところがあるとおっしゃっていたように、組織全体で方向性を定めながら、ちゃんと適応対象を見極めて、必要となるスキルギャップや環境面の不足も補ったうえで、安心して自動化に取り組めるような状態を維持することが重要そうですね。
『モジュール開発と運用』naka-shin1 さん
セイコーソリューションズのなかやまさんの、Ansibleモジュール開発に関するお話！
運用担当の目線では、Playbook～モジュール間が主に触れ合うポイントとなり、モジュール開発者視点ではモジュールへ引き渡される引数とそこから実ターゲットとの間が大事な部分となるため、立ち位置によって重要視するポイントが異なるそうです。
しかしながら、運用側ではどのような形になっていると使いやすいか？という点を主眼において、モジュール開発をしていただいているとのこと。利用者の一人として頭が下がります。
実例として挙げていただい【戻り値の中に、「投入したコマンド」も入れてほしい】というのは、要望を上げた方の気持ちはとてもよくわかります。
自分が使うことを考えると、知恵が足りないだけかもしれませんが、戻ってきたものの中だけで必要な情報が完結できると、とても楽だと思います。
ぜひぜひ、今後も利用者の意見に耳をかたむけていただけると嬉しいです！
なかやまさん、フクロモモンガの写真、もっとTwitterに掲載してくださいｗ
『AnsibleとCloudFormationの組み合わせでトレーニング環境を運用している話』 mito さん
APコミュニケーションズでのトレーニング環境をどのように構築・提供しているか、というノウハウをご紹介いただきました。
組み合わせているプロダクトとしては、CloudFormationとAnsibleとのことで、各々の特徴を生かして役割分担をさせながら、IaCで環境構築を実施されているそうです。
このLTでも「環境の初期化よりも毎回構築のほうがとても効率的である」というお話が出てきました。ここもペットと家畜の考え方ですね。
私もよく会社で検証環境を作ったりはするのですが、モロにペットな状態になってまして、耳が痛いところです。
環境構築にかかる時間や、冪等性を担保できないモジュールの利用方法などまだまだ改善点があるそうですが、IaCのベースができているので改善もしやすそうですね。
また、「自動化により、裏側の事情への意識が薄くなっていた」という反省点があったそうです。
このあたり、検証環境だけでなく本番環境の運用で利用する場合の懸念点にもなりますよね。「Playbookの実行ならできる」けど裏側の事情が把握できていないと「何かトラブルが起こった時に対応できない」という問題は顕在化しそうで、裏側の仕組みの把握も含めて自動化を活用していく必要があるなと改めて感じました。
『自滅のAnsible』しゃういち さん
www.slideshare.net
本当はLTトップバッターだったのが、様々なトラブルがあってトリとなったこの発表。
チェンジニアさんは普段のTwitterでのつぶやきもあり、どんなLTをされるのかワクワクしながら聞かせていただきましたが、見事に予想を裏切られましたｗ
内容としては、駆け出しでネットワークはあまり知らないエンジニアさんがやってしまった事故に対しての悲惨な再発防止策…（↓)
これで、事故防止のために「Playbookで削除してはいけないVLANを管理する」そうです…余計に事故りそう…
求人要件と実際に求められるスキルにギャップがあったのは事実だとは思いますが、とはいえ自動化を推進していく上では、幅広くスキルを持っていることはどうしても求められてくると思います。 私もインフラ一辺倒で生きてきたので、開発寄りのことをいろいろと身に着けていかないとな、と改めて感じました。
また、「運用可能なアーキテクチャを考えよう」というのはとても重要ですね。書かれてた通り、サービスイン後に運用仕様を変えるのはとても大変です。「とりあえず一通り作って、運用は後で考える！」では本当に後悔しますので、最初から運用サイクルを考えた設計を心掛けたいですね。
運営に関連したInformation
Ansibleコミュニティの様々な分科会の活動などが広報されていました。詳細は動画でご視聴いただければと思います。
またNW部やりたいですね！
冒頭でのコミュニティ活動の紹介として、昨年のアドカレで名前を出していただいて本当にありがとうございます。
大した活動はできていませんが、あんな形ででも、少しでもコミュニティに貢献できればと思っておりますので、今後ともよろしくお願いいたします。
謝辞とまとめ
今回のように、都度貴重な場をご提供いただいているコミュニティ運営の方々、本当にありがとうございます。
また、登壇され貴重な知見を共有いただいた登壇者の方々にも頭が下がります。本当にありがとうございます。
最近業務の関係から実際に手を動かしたり、ブログに投稿する頻度が減ってしまっているため、素人を卒業するためにも実際に活用してみて、情報を得るだけでなく、自身で得た知見を皆様に還元できるように、また取り組んでいきたいなと思いました。
