こんにちは、エンジニアの片桐です。
エニグモでは、社内サーバインフラの構成管理にAnsibleを採用しています。
Ansibleの前任の構成管理ツールにはChefを使用していました。
Chefと比較して、Ansibleで使用するファイルはYAMLベースの記述が可能で可読性が高いこと、エージェントレスで管理対象サーバに何もインストールする必要が無いこと等、Ansibleを導入することで様々なメリットを享受しています。
(Ansibleの導入話は以下の弊社ブログ記事でも話されている為、合わせて是非ご覧下さい！)
社内でのAnsible活用が進む一方、他社のAnsible活用事例にはどんな物があるのか知りたいなと思っていた所、 Ansible Night 2023.07 現場を支えるPlaybook編というイベントが開催されることを知りました。
折角の機会ということで、聴講側で参加しましたのでレポートを残したいと思います。
Ansible Nightとは
Ansibleのユーザコミュニティである、Ansibleユーザー会様主催の技術イベントです。
技術的な話題は勿論のこと、自動化を実装する為の組織作りの話題まで、Ansibleを使用した幅広いテーマを主体として開催されています。
イベント情報はAnsibleユーザー会のConnpassで公開されていますので、興味があれば覗いてみてください。
1. Ansibleによる、ネットワークOSに依存しないコマンド作成・設定変更 (APコミュニケーションズ 川名さん)
公演資料
公演内容
業務内容と現状業務の問題点
問題点に対する改善
- Ansibleとjinja2テンプレートを使って、IPアドレスの計算と設定ファイルの生成を自動化した。
- 自動化実装の結果、作業者・レビュー者ともに作業負担が非常に軽くなり、作業効率も上がってミスも減った。
Ansible実装時に発生した問題
- 開発ツール(エディタ)を統一していなかった。
- エディタ依存のインデント差分等が生まれ、レビューに時間が掛かった。
- 開発ツールはVisual Studio Codeに統一し、使用する拡張機能もチーム内で共有した。
- Playbookのコーディングルールが無かった。
- 変数名などの表記に揺れが生じ、レビューが困難だった
- Playbookの管理にGit等の構成管理ツールを使用していなかった。
- Playbookの重複編集や、誤爆削除が発生していた。
自動化によって発生した課題
- 「手動での設定ファイル生成作業を経験したことの無い人」が発生するようになった
- 新しく着任した人は、既に自動化された作業をなぞるだけになる為、作業内容のイメージがしづらい。
- 検証環境で手作業での作業も実行させると理解が深まりやすい。
- Ansibleで実行エラーが起きるたびに開発者に連絡が来るようになった。
- 既知のエラーについてのドキュメントの整備とエスカレーションフローを整備して、問い合わせの件数を軽減した。
感想
Ansibleでサーバに対して設定ファイルを展開するのではなく、テンプレートエンジン的な使い方をして設定ファイルの生成のみを行うという、自分の知らないAnsibleの使い方だと感心しました。
ネットワークOSによるサブインターフェースの設定コマンドの差異は以下の様になるとのことで、これだけ異なれば差分を吸収するのは確かに大変そうだな...と思います。
- Junos:
set interfaces fe-0/0/0 unit 11 vlan-id 11
set interfaces fe-0/0/0 unit 11 family inet address 192.168.0.1/28
- IOS:
interface GigabitEthernet1.11
encapsulation dot1Q 11
ip address 192.168.0.1 255.255.255.240
!
各種言語を使用したスクリプトでも同様の設定ファイル生成処理は実現可能とは思いますが、OSによるホストの出し分けやPlaybookの再利用性など、Ansibleならではのメリットが享受できそうな使い方だと思いました。
また、実装時の問題点では「開発環境(エディタ)をVisual Studio Codeに統一する」対応を取られていたとお話されていました。
Vim使用者やサクラエディタ使用者等、幅広いエディタ使用者が居たと言う事だったので、エンジニア間で揉める所があったんじゃないかなと思い、ハラハラしながら聴講しておりました...。
2. NetBoxを利用したIPアドレスの自動払い出し (APコミュニケーションズ 宮下さん)
講演資料
公演内容
業務内容と業務の問題点
改善内容
- IPAM/DCIM機能を持つOSSである、NetBoxを導入した。
- AnsibleとNetBoxを連携することで、以下のフローを実現した。
- VM構築にかかる稼働時間やリードタイム削減、オペミス頻度の低下、棚卸しの容易化などのメリットが生まれた。
自動化で生まれた課題
感想
Ansibleを利用して人の手が必要な部分を上手く自動化し、業務の効率化だけではなく、業務の質も向上出来ているアプローチだなと感じました。
また、NetBoxと言うOSSはこの公演を通して初めて知りました。VMだけでなく、物理サーバの管理やNW機器の管理も可能で、それぞれの管理項目もかなり詳細に設定出来る様です。
NetBoxのデモサイトが公開されている他、Docker版のNetBoxも公開されている為、是非社内でも導入検証してみたいと思いました。
3. チケット運用とAnsible連携による変更管理の自動化(RedHat 小野さん)
講演資料
- 公開なし
公演内容
業務内容と問題
- あるインフラ関連作業について、メールや台帳で作業依頼を受けていた。
- アサインされた作業者が各々で手順書を作成して実行し、作業後に各人が依頼主に返信して対応完了にしていた。
- チケット管理システム等による作業管理がされておらず、ナレッジの蓄積と共有がし辛い状態であった。
業務改善までのフロー
標準化: ServiceNowによるチケット管理の導入
- あるインフラ関連作業について、メールや台帳で作業依頼を受けていた。
- 依頼によって発生したタスクを一元管理する為に、チケット管理システムであるServiceNowを導入した。
- タスクをチケットとして一元管理できるようになり、依頼フローなどが整備された。
自動化: Ansible Playbookを用いた作業手順の統一化
- 作業手順の不均一性を解消するために、AnsibleのPlaybookに作業手順をコーディング。
- 担当者による作業の差異がなくなり、一貫性のある作業が可能になった。
- 人の手による作業からAnsibleが自動で作業を実行する方式に変更することで、作業効率が向上した。
サービス化: AWXによるフルオートメーションの実現
- AWX(Ansible Tower)のAPIを活用して、作業依頼のチケットが承認されると自動で作業が開始されるように設定した。
- 作業フローは完全に自動化され、人の介入が不要になった。これによって作業のスピード、精度、効率が向上した。
仕組みづくりの為の3ステップ
- 標準化
- ルール作成、ガイドライン策定
- 作業ミス低減、トレーサビリティ向上を目指す。
- 自動化
- 標準化された作業を、ソフトウェアやシステムで自動的に行う
- ユーザへの価値向上、プロセスタイムの削減を目指す。
- サービス化
- 自動化されたプロセスを相互連携させて、ユーザに対して価値をもたらす。
- リードタイム削減、価値最大化を目指す。
インフラエンジニアとして伝えたいこと
- インフラエンジニアは、自分に与えられた作業を正確にこなす内向きな作業者視点から、ユーザ視点の価値にフォーカスすべきである。
- 自分の作業効率を上げるための作業者視点の自動化から、ユーザへ価値を届ける仕組みづくりへの視点への転換が重要。
- 効率的な業務を行う為の仕組みづくりを行う、サービスプロバイダになるべき。
感想
完全手動かつ無管理だったワークフローを、チケット管理システムを使用して管理化した後、Ansible Tower(AWX)を使用して完全自動化するまでのステップを紹介していました。
標準化によって作業の品質が保たれ、自動化によって効率が上がり、最終的にはサービス化を通じてエンドユーザーに直接的な価値が提供されると言う一連のフローが、技術だけでなく組織全体での価値創出に繋がるという点は非常に参考になりました。
また、インフラエンジニアが単に内向きな作業にフォーカスするのではなく、ユーザ視点での価値を考える重要性が強調されていたのは、今後の業務においても非常に参考になると感じました。
自分自身の作業効率を上げることも重要ですが、それをどのようにサービスとして外部に提供するか、という視点も持つべきだというメッセージに、大いに共感しました。
最後に
久しぶりに技術イベントに参加して、新たな知見や視点に触れる充実した時間を過ごしました。
今回のイベント参加に使用したConnpassでは、インフラに限らず多様なテーマで日々イベントが開催されています。特にリモート参加が可能なイベントも増えており、時間や場所に縛られることなく学びを広げられて良さを感じました。
気軽に参加出来ることもあり、自己研鑽も兼ねて今後も興味を持ったイベントのレポート出来れば良いな、と思いました。
株式会社エニグモ すべての求人一覧
