SREの林と松野です。先日AnsibleのNetwork界隈では大変著名な"金魚のアイコンの人"こと、エーピーコミュニケーションズの横地さんを弊社にお招きし、熱いAnsible談義を交わしたのでブログします。
オイラ大地におけるAnsible
簡単にオイラ大地のAnsible利用シーンを紹介すると、これまではサーバ運用でのツールとして、100%では無いものの多くの部分で活用しています。 それは構成管理としてのansible-playbookであったり、adhockに複数のサーバに一括コマンドを送信するansibleコマンド(ワンライナー)であったりします。
オイラ大地の特徴として、お野菜を届ける物流自体も自前で持っており、自前の配送拠点を構えています。そして拠点の中には優先・無線それぞれのNW機器があり、それらのNW機器を管理するのもSREの仕事の一つです。
昨年(2018)10月にらでぃっしゅぼーやとの統合を経て、拠点の数も倍増*1したため、比例して管理するNW機器の数も多く増えました。
こうした状況を受け、これまではsshで個別に設定を行っていたNW機器の運用に限界を感じ始めたこともあり、サーバ運用でも大変効果をあげているAnsibleのメリットを、NW運用でも活用していきたいという思いを抱いていました。
金魚アイコンの人との出会い
金魚アイコンの人ことエーピーコミュニケーションズの横地さんについては、もともと個人的にブログやTwitterを通して一方的に存じている関係でしたが、弊社が会場提供をして開催したGitlabCIハンズオン#2に横地さんにご参加頂き、そこでの懇親会でGitLabCIをそっちのけで*2Ansible談義をするという機会を得ました。
もっとAnsibleの話をしたいんだ
実際に横地さんと対面してAnsible談義に花を咲かせたのですが、懇親会の僅かな時間・喧騒・アルコール・週末金曜日の疲労の中では全く時間が足りませんでした。そんな思いが高まってしまい懇親会終了後に林から「今度時間とってもっとAnsibleの話しませんか？！」とお呼びかけしたところ、快諾頂いたのが今回の"Ansible Network Automation Deep Dive in オイラ大地 with 金魚"の開催につながりました。
さて、フリートークから始めよう
そうして迎えた当日、オイラ大地の会議室の一角に落ち着いた私たちは、特にアジェンダ無しで話を始めました。これは今回の会談のざっくばらんなところから来るもので、結果的に良かったと感じています。 お互いの経歴を簡単に話した後、好きなAnsibleモジュール*3について話すことでアイスブレイクし、いよいよ本題に入っていきます。
現状の課題とビジョン
冒頭でも一部述べたAnsibleについてのオイラ大地の現状と今後のビジョンについて説明しました。まとめると以下の通りです。
課題
- 基本的にNW機器については手作業
- 統合もありNW機器が一気に増えた
- 人間はそんなにスケールしない
ビジョン
- NW機器もコードで管理され、バージョン管理が行われ、ソフトウェア開発のメソッドを適用できる(IaC)
- 煩雑な作業がPlaybookに落とし込まれ、簡単に実行でき、再利用が可能となる
- 作業の質が同じであれば、機器の増加に左右されない状態となる
ビジョンへの道筋を話す
では何から始めようか、という話になります。 颯爽と立ち上がった横地さんは以下の言葉を述べ、ホワイトボードに書き始めます。
「作業をいくつかの種類に分けて、どれをAnsibleに落とし込むか考えてみましょう」
どのように分けるかは以下の通り、リスクと頻度の2軸です。 その中でリスクが少なく、実施する頻度の高いもの についてまずAnsibleでの適用を考えてみようとなりました。
| リスク | 頻度 | 手始めにAnsible化する？ |
|---|---|---|
| 大 | 大 | しない |
| 大 | 小 | しない |
| 小 | 小 | しない |
| 小 | 大 | Ansible化するならまずココ！！ |
そうして出てくる具体的な作業としては、VLANの追加であったり、正常性確認（つまりはテスト）であったりしました。
より具体的なステップに落とす
1. Inventoryを整備してAnsibleで全NW機器へ接続可能にする
とはいえ現状はほぼ0の状態ですので、もう少し現実的なステップに落としていきます。サーバ運用では意外と便利なのはワンライナーによる一括確認で、それを行うにはAnsibleのinventoryファイルの整備が必要です。 そのため 第一ステップをInventoryの整備 とし、適切なグルーピングによる運用作業を目指すことにしました。
2. 全NW機器の自動コンフィグバックアップ機能の実装
Inventoryの整備が終われば、全てのNW機器へAnsibleによるアクセスが可能な状態となります。サーバ側の要件でAWXは導入済みであるため、秘密情報の格納先にも迷うことはありません。そういった状況で 第二ステップ を全機器のコンフィグ定期バックアップ です。AWXのスケジュール機能と、GitLabを利用して日次で全機器からコンフィグを取得し、Gitの機能で差分があった場合のみバックアップを実施、さらにGitLabのHook機能で更新があった場合はSlack通知を行う、といった仕組みを構成しようと考えました。*4
3. VLAN設定のような頻繁かつインパクトの少ない作業をAnsibleで実施
自動コンフィグバックアップが回るようになれば、いよいよAnsibleでの設定変更を行う予定です。社内向けのSSID追加作業などでVLANが増えるケースはしばしば発生するため、VLAN追加をAnsibleでのコンフィグ変更の第一弾としようと考えています。
実際にAnsibleによるNW機器の設定変更に関して大きな学びがあったのは、処理の中では手続き型であるというポイントです。
具体例をios_configモジュールのサンプルから抜粋します。
以下はCisco機器のACLを設定するケースですが、 before: no ip access-list extended test でACLを丸ごと削除したあとで、新規でACLを作成することで結果的に冪等性を実現しています。
- name: load new acl into device ios_config: lines: - 10 permit ip host 192.0.2.1 any log - 20 permit ip host 192.0.2.2 any log - 30 permit ip host 192.0.2.3 any log - 40 permit ip host 192.0.2.4 any log - 50 permit ip host 192.0.2.5 any log parents: ip access-list extended test before: no ip access-list extended test match: exact
これは話としては分かるが、一時的に想定しない状態が発生してしまうため、できれば差分だけを反映して欲しいところです。横地さんからはCisco社のブログ: Automating your Network Operations, Part 5を紹介頂き、 Ansible difference filter を使った差分だけを適用するというオシャレな例も紹介頂きました。
その他にもAnsible談義
その他にもAnsible話は尽きず、様々なお話をさせて頂きましたのでいくつかピックアップして紹介すると
最新情報はAnsible projectsで習得！ Ansibleの最新情報はGitHubにあり！！ということで、その中でもGitHubのProject（要するにカンバンです）を参照することで最新情報にリーチできるという話は実におもしろかったです。中でもNetworkingのProjectについては、横地さんは毎日の様に購読しているとのことで流石という感想でした。
Ansible Moduleサイトはdevelを見ろ！ Ansiblerなら数えられないほど参照することになる公式ドキュメントのModule Indexですが、URLをdevelと変えることで、開発中*5の最新ドキュメントを参照することができます。次のアップデートに備えてモジュールの情報を確認するのが捗りますね。*6
まとめ
勢いで開催した横地さんとのAnsible談義でしたが、実に有意義な時間と、今後に向けた具体的な計画と、個人的にはモチベーションの高まりを得られたという点で非常に素晴らしいものでした。 こういった機会は今後も気軽に作っていきたいなと思います。
「「横地さんありがとうございました！！！！」」
(そしてこの縁はAnsibleコミュニティとも繋がり、イベント開催の機運が...!?!?)
