NW⾃動化 開発エンジニアがやってみた話 Ansiblejp ネットワーク部 Jun tomo @tomomo 1 

あらかじめご了承ください • 本資料で説明している製品のバージョンは以下の前提です（古い） • Ansible Core ： . . • Ansible Tower ： . . • 古いバージョンですので、最新のバージョンでは仕様、及び機能名が異なる可能性がありま す。 2 

今⽇も⾮常に ゆるーーーーい話しかしません 3 

Agenda • なぜNWを⾃動化したいのか • 実案件的な話 • NW⾃動化を開発エンジニアとやるとき 4 

—- - name : tomo assert: msg: - DBA in SIer twitter: - @tomomo with_itemes: - あかずきん＆グラレコの⼈ - Ansible何も分からない - NW何も分からない - コンテナ何も分からない - DB何も分からない  Who are you? 

Thank you!! ネットワーク部のロゴを作らせていただきました！ ご意⾒頂いたみなさま、ありがとうございます！！ #ものすごく作るのが遅くなってごめんなさい( ；∀；)  

なぜNWを⾃動化したいのか 7 

なぜNWを⾃動化したいのか NWエンジニア サーバエンジニア 開発エンジニア DBエンジニア どれになりたい？ AI/機械学習系エンジニア Cloudエンジニア セキュリティエンジニア Webエンジニア NWエンジニア サーバエンジニア 開発エンジニア DBエンジニア どれになりたい？ 10年以上前 最近 エンジニアの種類が増えた （⺟数が増えてる/フルスタックエンジニアってなんやねん） 8 

なぜNWを⾃動化したいのか ⼈材不⾜は未来の話ではない 「今」起きていること （出典）総務省「IoT時代におけるICT経済の諸課題に関する調査研究」（平成29年） ICT⼈材不⾜の⾒通し（情報通信業） 9 

なぜNWを⾃動化したいのか • ⼈材不⾜の状態で、今の開発〜運⽤の維持することは不可能 • クラウドやコンテナ等の技術の多様化に伴い、インフラレイヤに求められる要件も複 雑になっている • NWの技術⾃体もの進化を遂げ続けている（SDN、NFV、etc .） • 全てが新しくなっているのではなく、物理レイヤや既存システムの対応など、所謂 「泥臭いこと」もまだまだ必要 NWエンジニアに求められる技術は、さらに多様/複雑化へ 10 

なぜNWを⾃動化したいのか 設計 新技術/システム 構築/保守等 設計 新 構築/保守等 • 業務時間の割合（例） • 構築/保守等の業務に対する軽減化をすることで、設計検討の時間や新技術/システムの学習時間に当て られる • NW設計の考慮漏れはシステムに多⼤な影響を与える為、 少なくとも設計＞構築/保守の時間割合にした い ˣཧ૝ ˣݱ࣮ 11 

なぜNWを⾃動化したいのか • なぜ「NW」にフォーカスしたのか？ • 作業対象台数が基本的に多く、構築/保守業務を⾃動化することによる効果が得やすい • 設定変更作業が⼀般的には多いレイヤ • 同じ作業を複数台に繰り返し実施していることが多い • 障害時、復旧に同じ作業を繰り返していることが多い • コマンドと結果が⽐較的⼀意で、エラー判断がしやすい • 設定ファイルが複数ある、等のサーバやアプリケーションと⽐較するとまだ判断しやすい • 正し全てのエラーは判断できないので、そこは肝に命じておく（NW⽢くみちゃダメ） 12 

だから⾃動化したいです！！ 13 ホスト名、ヨシ！ とか⾔ってる場合じゃ ねぇ！！！ 

実案件的な話 14 

実案件的な話 • 実際NW⾃動化をやってつまづいた点 • 物理レイヤの環境差分の違い • Ansible Towerの単語の説明 15 

実案件的な話 • 物理レイヤの環境差分の違い • Playbookの開発環境（Ciscoの場合） 社内検証環境 ‧仮想iOS ‧AnsibleTower ‧GitLab on VMware 顧客検証環境 ‧実機NW機器 ‧AnsibleTower ‧GitLab 顧客商⽤環境 ‧実機NW機器 ‧AnsibleTower ‧GitLab 16 

実案件的な話 • 物理レイヤの環境差分の違いによる⼿戻り • 仮想iOSと実機で差が出るのが「物理層」 • カードの種別によって出⼒結果の微妙な差が出るので、assertに対するチェックで、顧客検証環境 と商⽤環境で差が出る • 案件途中でカードが変わり、該当箇所の Playbookの修正が発⽣ 17 

show runの結果確認 18 - name: 設定内容を取得する iosxr_command: commands: show running-config interface {{ this_router.port }} register: result_show_run_config - name: 取得結果をデバッグ debug: var=result_show_run_config.stdout_lines[ ] - name: 設定内容確認 assert: msg: “ERROR- : {{ inventory_hostname }} に対する設定値が正しく設定できていません {{ check_string }}" that: - check_string | search(item) vars: check_string: "{{ result_show_run_config.stdout[ ] }}" with_items: - "description {{ this_router.description }}" - "shutdown" - "mtu {{ this_router.mtu }}" - "service-policy output XXXXXXX" - "ipv address {{ this_router.ip }} {{ this_router.mask }}" - "ipv nd suppress-ra" - "ipv enable" - "carrier-delay up {{ this_router.carrier_dly_up }} down {{ this_router.carrier_dly_down }}" - "flow ipv monitor XXXXXXXXXXXXX " - "flow ipv monitor XXXXXXXXXXXXX " - "flow mpls monitor XXXXXXXXXXXXX “ - "dampening {{ this_router.damp_harf_life }} {{ this_router.damp_reuse }} {{ this_router.damp_suppress }} {{ this_router.damp_max_suppress_time }} {{ this_router.damp_restart_penalty }}" カードの違いで ここの設定が増減… 

余談：CiscoのNW機器に対する切り戻し⽅法 19 - name: 設定を切戻し！！ iosxr_config: parents: "interface {{ this_router.port }}" lines: - no description - shutdown - no mtu - no service-policy output Core-Qos - no ipv address - no ipv nd suppress-ra - no ipv enable - no carrier-delay - no flow ipv monitor XXXXXXXXXXXXX - no flow ipv monitor XXXXXXXXXXXXX - no flow mpls monitor XXXXXXXXXXXXX - no dampening 設定変更箇所を全部クリアにする 設定途中でエラーが出ても 切り戻しで全部クリアされるので 「どこまで設定⼊ってる？」の 確認不要 

実案件的な話 • Ansible Towerの単語の説明 • 「ジョブ」「ワークフロー」「サーベイ」の説明 20 ワークフロー ジョブ ジョブ 

実案件的な話 • Ansible Towerの単語の説明 • 「ジョブ」「ワークフロー」「サーベイ」の説明 21 Inventory グループ名 ホスト名 付属情報 ワークフロー情報 サーベイ 付属情報は ホスト毎に変えたい 変数を設定 ワークフロー内で 共通化したい値 

実案件的な話 • Ansible Towerの単語の説明 • 「ジョブ」「ワークフロー」「サーベイ」の説明 22 Inventory testNW interface=TenGigE port= / / / mtu= ip_add= . . . ワークフロー情報 testNW ‧Inventory ‧以下の情報を格納するDBみたいなもの ‧グループ（ホストの集合体） ‧ホスト名 ‧ホスト毎のパラメータ（変数） ‧サーベイ ‧ワークフロー内で共通化したい変数 ‧例えば「ホスト名」にした場合、サーベイ       からホスト名をキーにして、Inventoryから       付属情報（interface,port,mtu,ip_add)を       検索し、ワークフロー内の Playbook に対し       変数を割り当てる Select 

実案件的な話 • とある作業に対する⾃動化コスト • 体制：PM 名、開発2名(初Ansible開発)、NW 名、RHコンサルさん • 作成Playbook数：約50ファイル • 作成期間：検証期間込みで、約2ヶ⽉（PoCでベースの Playbookがある前提） • 導⼊製品：AnsibleTower, GitLab • その他：機能を補填する為のPythonプログラム数個 • 導⼊効果（社内） • 開発2名が、何をするにもAnsibleで⾃動化するようになっていた（頼んだ覚えはない） • ⼀緒のチームメンバーが数名上記に巻き込まれ、気づけば Playbook書いていた • 他部署から⾃動化相談が来るようになった 23 

NW⾃動化を開発エンジニアと やるとき 24 

NW⾃動化を開発エンジニアとやるとき • 「⾃動化しましょう」となったとき • ⾃動化は⼤抵開発が伴う。ちょっとしたプログラム開発が必要な場合も。コードに対しアレル ギー反応するインフラサイドエンジニアがいることも、現実としてある • Ansibleは基本的に「実⾏したいことを羅列して書く」だけなので、NWを知らない⼈でも、実⾏ コマンドをモジュールに実⾏させるという⽅法で、⾃動化を実現させることが可能です 25 開発エンジニアに 頼るのもありですよ！ 

NW⾃動化を開発エンジニアとやるとき • ⾃動化する範囲を明確化する • ⾃動化する際は、⼿順書を渡し「この作業を⾃動化しましょう」と伝えてください。⼿順書があ れば、それが「⾃動化する範囲」になります • 実装していくと、「ついでにこれも…」と⾔いたくなるのが⼈間ですが、まずは最初から最後ま で動くところを、GOALとすることがお勧めしています 26 

NW⾃動化を開発エンジニアとやるとき • 単語の意味に気をつける • 同じ単語を⾔っているのに、意図している内容が異なる可能性があります • 例えば、「冗⻑」という単語を聞いて、頭の中に何を浮かべますか。ブリッジ、VRRP等のNW機 能を思い起こす⽅もいるかもしれません • 開発のエンジニアが思う「冗⻑」がこれと同じとは限りません。OSバックアップのこと、 Lifekeeper等のミドルウェアによるファイルの冗⻑、DBやストレージのデータ冗⻑のことかもし れません • 同じ単語でいずれも誤りではないのですが、単語が持つ意味の差分によって、お互い話が平⾏線 になることがあるかもしれません。その場合は、ホワイトボードや紙に図⽰してみてください。 おそらく、Slackで何⼗分もかけて認識合わせをするより、ずっと簡単に認識差異を埋めることが できます 27 

NW⾃動化を開発エンジニアとやるとき • 開発エンジニアがNW⾃動化ができるということは？ • AnsibleはNWが分からない⼈でも、NWの⾃動化を実現することができました • つまり、NWエンジニアがサーバ/開発作業の⾃動化が出来る、ということでもありますね！ 28 

さて、⾃動化…いつやります？ 29 今でしょ！はちょっと古いので… 

Just do it !!!!! 30