はじめに
2024/08/07 に、Red Hat 社主催で、Ansible に関する年次イベント「Ansible Automates 2024 Japan」がオンラインで開催されました
今回のテーマは「実践から学ぶインフラ自動化、国内事例大集合！」
ほぼハッシュタグ #ansibleautomates でポストした内容ですが、個人的なメモとしてまとめておきます
なお、後日セッション動画、講演資料は以下のページ経由で公開されるとのことなので、正確で詳細は情報はそちらをご参照ください
そういえば、今回は「自動化2.0」という言葉は使われませんでした。
インフラ自動化の今、そして未来の自動化
- Policy as Code
- AI が生成したPlyabookを自信をもって利用できるように、ガードレールを敷く
- ポリシーをコード化するメリット。透明性、再現性、変更管理、自動化、コンプライアンス対応
- 「ポリシー」の例。作業時間帯の制限、セキュリティのチェックが通ってないと実行させな、署名の有無など
ansible-policy としてはまだバージョニングもされない状態で発展途上だと思うので、これからも様子をウォッチしていきたいと思います
Ansible Lightspeedを活用したPlayboook開発
- Ansible Playbook を AI で生成する Ansible Lightspeed
- 自部門ではAnsibleの心理的ハードルが高いなどの課題があった。そこで Ansible Lightspeed と出会った
- 自然言語によるコード化、作業のタスク分解してくるところがポイントと感じた
- Ansible Lightspeed、まずは3か月の検証。Ansible上級者、初心者、Red Hat コンサルタントによる
- 頑張らなくても自動化できるような理想の姿を描いていた。しかし、生成の制約が多く、自分で書いたほうが早い場面も。適切なプロンプトも分からず。正直がっかり
- Playbook生成機能などの追加が転機になった
- Playbookを生成し、Task Generation を利用してタスクレベルで修正、Playbook Explanation でPlaybookを説明してもらう。という使い方で自動化を加速できた
- Ansible 初心者の視点。自動化対象にあったモジュールが分からない。1からコーディングできない。初歩的な文法エラーが多発。難しくて挫折しがち
- これらの課題を Ansible Lightspeed を用いて解決。モジュールが分からなくてもよくなって、ブログを調べる手間がなくなった。また、生成されたPlaybookを修正するだけなので1からか書かなくてよく、ケアレスミスによるエラーも少ない
- Ansible Lightspeed を使ったデモ。Playbookを生成し、解説してもらう
- デモ中のおはなし。一番いいと思ったのは、1からコーディングすることのハードルが下がり、手直し感覚でできたこと。Ansibleは一ヶ月だけの勉強だけだったが 初心者が Ansible Ligthspeed を利用するのがよいのではないか。プロンプトの書き方を正しくできれば有用
- デモの流れ
- プロンプトを英語で入力（日本語はサポート対象外のため）するとPlaybookが生成される
- アドレスの指定が正しくなかったので修正
- Playbook実行、確認
- Multi Task Generation でタスクを2つ追加、少し修正
- 再実行、確認
- Task Explanationで説明書を生成
- 成果。エラーが約80%現状、コード開発時間が約65%減少。Litghtspeed を使った初心者の方が上級者よりも開発時間が短いことも
- 発展途上なので、今後の機能拡張に期待
- 今後の展望。Ansible Ligthspeed を活用して社内に自動化を広げていく
初期のリリースからと比べると、実用レベルに達してきているみたいですね。ドキュメントを生成してくれるのはよさそうです
Ansible活用によるシステム運用高度化の取り組み
- Ansible採用理由、エージェントレス、シンプル、パワフル
- 最初はサーバー構築の自動化からはじめ、開発・配布環境の整備、運用業務への適用、というAnsible活用の歴史
- サーバー自動構築システム（内部はAnsible）。申請を受けて設定パラメーターをAnsibleように加工して実行。結果を申請DBに返す
- サーバー自動構築システムを入れる前後の比較、効果。従来は各基盤ごとに担当がいたが、現在はサーバー基盤担当のみ。また、ゲストサーバー構築にかかる時間も短く。PJごとの予算取りが不要になり、コストの運用枠でおさまる程度に
- 申請が複数部署にまたがって大変だったがが、簡単になった
- ヒューマンエラーがなくなって、ストレスからも解放。従業員の仕事への満足度が向上
業員の仕事への満足度が向上というレベルまでいっているのが驚きでした
自律化へ向けて
- 自動化のポイント。量子化、標準化、一元化。自分たちの仕事、経験を言語化することが重要
- やっていることを置き換え。システム状態の確認は監視システムへ。など。置き換えた部分を省くとシンプルになる
- 再利用できるところ、仕様の差が少ないところをさがしてロールへ寄せる
事前確認と設定と事後確認の手順を、自動化をしやすくするために切り口を変えて見る話が興味深かったです
オリックス銀行におけるIaC内製化の挑戦と成果・将来
- システムの安定稼働のために、まずはシステム自動復旧。
- 自動化前の課題感
- 手作業による品質のブレやヒューマンエラーがあった（名前付けなど）
- 変更管理が申請とドキュメントベースで、差分が即座に判断できない
- 手作業の業務が多い
- ベンダー任せ（詳しく知らない）
- 実装機能を検討
- 自動化効果が高いもの頻度が多く、時間がかかっていて、手順が複雑なもの
- 拡張性があるもの
- 実現可能性があるもの。限られた時間で実装できるか
- 結果、IAM権限移譲、IAMユーザー作成業務を自動化対象に選定
- 成功したところ
- 内製で実装
- 未経験からの実装
- リリースできた
- 失敗したところ
- コード品質（ロール間の密結合など）
- 標準化（環境が個人裁量）
- マネジメント（スケジュール見積りの甘さ、フォローが後手に）
- 得られたもの
- やってみることの大事さ（PoCや机上評価では得られない生々しさなど）
- 0から1へ（やったことがある、へ）
- 悔しさ
- モチベーション
- これから
- 再利用可能な機能の拡充（よく使う機能）
- 開発環境の標準化
- Ansible開発者の拡大（ガイドライン、コンテンツ）
モブプロがすごく効果的だったそうです
Ansibleが日常になるまで
- 現在のプライベートはクラウドは第3世代。徐々に内製化へ。Ansibleの活用も定着してきた
- 導入期: 盛り上がってるのは個人レベル
- 成長期: ベンダーが作ったPlaybookを読んだり修正
- 定着期: 共通言語化されている。だれでお教えられる。いまここ
- 導入期
- DevOpsの始まり。Gitea 導入。カスタムモジュールのプロトタイプの開発までやった
- 成長期
- ベンダー開発のPlaybookを読み解いて書き換えるのが大変だったので、可読性の重要さを知るきっかけに
- 変数の利用は少なくするという方針に
- 定着期
- ここまできたらAnsibleが日常。現在はテナントにAAPを提供
- うまくいったこと
- DevOps、運用課題の改善のモチベージョンをもとに取り組めた
- 内製化
- 小さい再組織で、対象を絞って始められた
- うまくいかなかったこと
- 日常になるまで時間がかかった
- インベントリの共通化（標準化はできた）
「もし組織の広い範囲でいきなり自動化をはじめたら、どこか他人事になってしまったかもしれない」というお話があ印象に残りました。
おわりに
各事例ではストーリーが伺えて大変興味深かったです。覚えておきたいヒントがたくさんありました 登壇者のみなさまありがとうございました！
