a_CI_like_approach_to_netwoek

[July Tech Festa 2020 登壇資料]
昨今のインフラへの自動化が叫ばれる中で、様々のものが世に出てきています。
構成管理ツールのAnsibleが非常に注目されていますが、今回はネットワークのテストにフォーカスし、実際に抱える課題と、処方箋、そしてその効果について、デモを交えてお話ししました。

[当日の動画]
https://www.youtube.com/watch?v=TxrGClTO2jQ

Transcript

1. ネットワークへの CI的アプローチ July Tech Festa 2020 2020/7/25 田中 進 株式会社エーピーコミュニケーションズ
2. 自己紹介 • Name: 田中 進 • Company: 株式会社エーピーコミュニケーションズ • Job: ネットワークテスト自動化アプライアンス NEEDLEWORKを作っています。
3. では始めたいと思います。 と、その前にちょっと補足
4. 継続的インテグレーションとは • ソフトウェア開発の世界で作られた言葉 • 随時、変更を統合（コードをマージ） • 随時、試験をする（例えば結合テストであったり、ビルドを通すであった り。どこまでやるかは様々） ※定義や解釈は様々だが、今回ここではこう定義します。 　（Wikipediaのエクストリーム・プログラミングの説明が一番しっくり来ます）
5. 継続的インテグレーションを ネットワークに適用。 こんな話をしていきます。
6. 本日話す内容 - 1. ファイヤーウォールを運用するにあたっての痛み （気持ち面、金額面、何が悪いのか？） 2. 痛みを解決するためのアプローチ （どこに、どうやってアプローチするのか。デモ動画付き。） 3. どんな価値を提供するのか
7. ファイヤーウォールを運用していて 辛かったこと
8. つらい構図 • 仕事量が釣り合ってない • 承認フロー長くなりがち 作業者 依頼者
9. 起きていたこと（トラブル） - • 承認フローを迂回した闇作業によって、通信断を 起きる • ACL上限に達し即興リファクタしての障害 • 要件漏れによる再作業
10. 疲れる。ツライ。
11. 発生した損失 • 稼働 ◦ システム停止をリカバる手運用作業 ◦ 障害報告 • システム停止の損失 ◦ 機会損失 ※規模によるが年間売上を一時間あたりで割ると、1時間あたり、数百万とか、数千万とかになる。 　ECサイト売上ランキングとか見ると、機会損失って大きいと感じますね。
12. 損失：数百〜数千万
13. 取り組む価値は十分にある ここで何が悪かったか振り返る
14. • 簡単にトライアンドエラーできなかったのがイケないのでは？ ◦ 現実的に考えるとIT業界はスピード感を求められてる。 • テストを脳内試験でやっていた • 何が必要かわからないのにシステムを作ろうとしていた（これは今回対象 外） • 人員に対しての作業量が多い • 承認フローが機能していない[結局、信頼できない] 何が悪かったか振り返る（ざっくり）
15. 何が悪かったか振り返る（整理） 患部はここ ・依頼が多すぎる 作業量 ・作業ミス 作業 理由はこれかな ・人の処理量、与えられた工数を超過してる。 作業量 ・脳内試験 ・貧弱な目grep ・簡単にトライアンドエラーできない 作業 ・チェックが機能してない 承認 ・形骸化 ・脳内試験 承認
16. • リソース[人員]には限界がある • 人がもっとも不正確
17. では、どうすればいいか？
18. 不正確な処理を自動化で カバーするしかない！
19. 【本題】ネットワーク機器をCIする
20. どこへのアプローチ？
21. このへんにアプローチ 運用 依頼者（PJ) レビュー 作業依頼 脳内テスト 手順書作成 作業（複雑） 脳内テスト 承認
22. 何をCIする？ • 正直コンフィグ全体は難しい ◦ すべての機能を確認できるようにしなくてはならない？ ◦ やるなら特定の設定のみにフォーカスしたい。 • ansibleのplaybookなら？ ◦ playbookなら特定の設定のみにフォーカスして定義可能 **AnsibleのplaybookでACLを管理する** "動く検証されたマージ済みコード(バイナリ)がほしい"のと同様に、 "動く検証された設定ファイルがほしい"
23. ACLにフォーカスした AnsibleのplaybookをCI
24. • 手段は様々 ◦ pyATS・・・機器の状態確認のイメージ ◦ batfish・・・コンフィグ解析して独自ロジックで意図した通信が通るか判定する。 （脳内テストの自動化のイメージ） ◦ 実際にパケットを流す • 今回は最も本番環境に近い、実際に機器にデプロイしパケットを流す 何をもって検証するか？ "実際に機器にデプロイ"することで構文チェックを通す "パケットを流す"ことによって、要件の通信、既存の通信のチェックができる
25. 実際にパケットを流す
26. スコープと 実装方式がわかった ところで
27. 試験実装
28. 試験実装（構成） gitlab server gitlab runner + Ansible 2.push 1.playbookを編集 3.マージ 4.CI開始 5.コンフィグ投入 6.テスト パケット 送受信
29. コンポーネント紹介
30. 設定自動化はAnsible Ansibleによる自動設定投入 今回は書いたyamlの通りに、ACLが設定されていることを担保
31. コード管理、CIはgitlab gitlabによるコード管理。CIの実行（自動設定のキック、テストのキック）
32. テスト機能 NEEDLEWORKによるFirewall自動テスト 周辺ネットワークをシミュレートし、試験を行う。 実はRESTをしゃべる。 RESTで命令してパケットを投げさせることが可能。 ※この辺はOSSなりでコードを書けば代替可能 ※実はAPIを叩くのは公式ではサポートしていない。開発者だからできるこ とである。
33. こんな感じで使うアプライアンス
34. 本来はWEBUIからアクセスして、テスト実行
35. 今回は、 NEEDLEWORKのAPIを 直に叩きます
36. デモ
37. インター ネット インター ネット 作業前コンフィグ (WEBアクセス可) 設定変更 （作業ミス） 作業後コンフィグ (WEBアクセス不可) WEB接続不可を 自動検出 内容 本番に反映する 前だからセーフ
38. 後日配信されるJuly tech Festa 2020のyoutubeで 見てください。
39. これが出来たところで 何が変わる？
40. フローで見ると
41. ASIS 運用 依頼者（PJ) レビュー 作業依頼 脳内テスト 手順書作成 作業（複雑） 脳内テスト 承認
42. TOBE 運用 依頼者（PJ) レビュー 作業依頼 コード編集 脳内テスト 自動テスト 作業（単純） 自動チェック 承認 自動で判定するのに そもそも必要？ 手順作成 自 動 化
43. どんな価値を提供するのか？
44. 人力(いい加減) => 自動(正確）
45. 止まる => 止まらない (価値をユーザーに提供し続ける) (機会損失が減る)
46. 精神的負荷ダウン （離職リスク低下）
47. ん゛〜百万円規模の効果
48. 自動化って すごい価値がありますね！
49. まとめ
50. 自動化は社会（個人・社員・会社）に対し価値を提供する。 ネットワークのCIは価値提供のアプローチとして十分に可能性あり。
51. 良い自動化ライフを！
52. Appendix
53. Appendix: 今日話したプロダクトのリンク集 • pyATS ◦ URL：https://developer.cisco.com/pyats/ • batfish ◦ URL：https://www.batfish.org/ • NEEDLEWORK ◦ URL: https://www.ap-com.co.jp/ja/needlework/ • gitlab ◦ URL: https://www.gitlab.jp/ • Ansible ◦ URL: https://www.ansible.com/