Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
モダンなネットワーク構成管理DBを最小労力で開発する
Search
Mabuchin
June 06, 2019
Technology
980
3
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
モダンなネットワーク構成管理DBを最小労力で開発する
Mabuchin
June 06, 2019
More Decks by Mabuchin
See All by Mabuchin
TIPSTARのライブ・プロダクションシステムの裏側
mabuchin
1
1.3k
ホワイトボックス伝送の動向と商用利用について
mabuchin
3
860
WhiteBoxSwitch NOSの変遷
mabuchin
5
2.2k
Cassini + Goldstone DCI use case and challenges
mabuchin
1
320
転びながらもネットワーク処理をソフトウェアで自作していく話
mabuchin
8
4.9k
Gitでネットワークオペレーションを進める話
mabuchin
0
160
TapAggregationを使ったデータプレーン性能測定
mabuchin
0
290
Github PullRequestで作業半自動化
mabuchin
0
130
お手軽! BGP RIBのリアルタイム経路解析+可視化
mabuchin
0
450
Other Decks in Technology
See All in Technology
猫でもわかるKiro Web
kentapapa
1
120
AWS FinOps Agent 結局何が得意なの?
siromi
0
210
Amazon Bedrock Agents ClassicからAmazon Bedrock AgentCoreへ移行した際、ガードレール設定が2箇所に割れた話
matsunobu
0
120
「どのログを見ればいい?」 から始めた サーバーレス障害解析
y_waka1
1
150
20260929_AmazonGuardDutyの検出通知メールにAWS DevOpsAgentの調査結果を追加する
yhana
1
230
AIに会社の文脈を理解させる技術~上流工程・非エンジニアにも広げるハーネスエンジニアリング実践~
ochtum
0
130
音声コミュニティを守るAI監視基盤_ 90%以上の入力削減を支えたServerless設計と運用判断
shuheioka123
0
110
AIに書かせて、プラットフォームで縛る ― EKSプラットフォームで実践した責任境界と権限設計
elmodev09
0
820
人にやさしく、AIにやさしく、書き手を選ばないIaCのガードレール再考 / Rethinking IaC Guardrails for Humans and AI Alike
kohbis
5
1.4k
【技術的負債conf】事業成長に伴う技術的負債の説明責任とAIによるモニタリング、認知的負債について
i35_267
4
2.3k
「ピッケル本」日本語版は4.0(第6版)が出版されるべき / pickaxe4-nagoyark05
kakutani
2
310
Making AI Agents Safe and Fast- Jev, Obsidian, and the Meta-Harness
x5gtrn
PRO
0
150
Featured
See All Featured
Imperfection Machines: The Place of Print at Facebook
scottboms
270
14k
WCS-LA-2024
lcolladotor
0
830
The Curse of the Amulet
leimatthew05
3
15k
The State of eCommerce SEO: How to Win in Today's Products SERPs - #SEOweek
aleyda
2
12k
End of SEO as We Know It (SMX Advanced Version)
ipullrank
3
4.4k
Design of three-dimensional binary manipulators for pick-and-place task avoiding obstacles (IECON2024)
konakalab
0
600
The Limits of Empathy - UXLibs8
cassininazir
1
690
From Legacy to Launchpad: Building Startup-Ready Communities
dugsong
0
340
Making Projects Easy
brettharned
120
6.8k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
133
19k
Scaling GitHub
holman
464
140k
Amusing Abliteration
ianozsvald
1
320
Transcript
2019/06/13
ネットワーク構成の管理 2
どんな場⾯で欲しくなってくるか • ⼈が設定変更する場合 • 機器上で「あるべき状態」を確認 • 実際のConfigがMasterデータでも、ある程度問題ない • Botがやる場合 •
「あるべき状態」と「今の状態」を毎回解析してValidationは結構つらい • 「ネットワークの正の情報」は連携の観点でも機器外に持ちたい • 事前確認 • 設定変更 • 事後確認 Automation • Config Replace Master Network Data
DBをネットワーク構成のマスターにできれば Code baseなOperationが⾮常にやりやすい
何を管理する︖
ネットワーク構成で管理するもの • Device Info • OS • Location/Rack • Interface
• Inventory • VLAN • LAG • IP Address • Prefix • NAT Table • ACL Table (自社の場合) • IGP(OSPF) • Interface • Area • metric • VRF • Route Distinguisher • Interfaces • EGP(BGP) • ASN • Neighbor • Route-policy などなど...
結構多い
これ⾃分で全部実装するの︖ • 様々なソフトウェアと連携させる必要性がある • APIの実装が必須 • 作業する場合に、DBを変更してそれを波及させる • ⼈が弄るWeb UIが必要
• 管理する情報量が結構多い • DB設計も時間がかかる • 性質的に、継続的にメンテナンスする可能性が⾼い • 誰でも素早く追加実装できなければいけない • 実装にそんな時間をかけてられない • これだけやってるわけじゃないので...
1から⾃作は無理︕
NetBox is an IP address management (IPAM) and data center
infrastructure management (DCIM) tool. Initially conceived by the network engineering team at DigitalOcean, NetBox was developed specifically to address the needs of network and infrastructure engineers.
• Django製のIPAM兼DCIM OSSツール • Rest API完備 • ほぼ全ての操作に対してAPIが提供されている • Webhookサポート
• Salt/Napalmとの連携サポート • 使いやすい(?)WebUI • 高頻度なリリース • Rack/Device/Inventory/Interface/IP address/VRF/Curcuit/VM の管理機能提供 Netbox
(再掲)ネットワーク構成で管理するもの • Device Info • OS • Location/Rack • Interface
• Inventory • VLAN • LAG • IP Address • Prefix • NAT Table • ACL Table • IGP(OSPF) • Interface • Area • metric • VRF • Route Distinguisher • Interfaces • EGP(BGP) • ASN • Neighbor • Route-policy などなど...
我々には “少しだけ”⾜りない
None
Forkして⾃社カスタム • NetboxはApplication componentでしっかり分離している • 新規でDjango app追加して、既存に倣って分離して開発可能 • フォークしても分離が綺麗だから追従も楽々 •
実装コストがかなり低く、テストされた基盤を使える • Routing appを追加で開発 • テスト含めても1500⾏くらい • 細かい点抜きなら3⽇くらいで⼤体終わる • Netboxの作り込まれたUtilityが利⽤できる • Model/Template/View/APIは既存を真似すれば⼤体分かる
None
Swaggerも標準搭載
今 : 既存からのマイグレーション Netbox POST DATA Data Collector • まずはDBが「最新の構成を保つ」状態からスタート
• 作業者が⼿で設定を変えても、Collectorが情報を集めて差分を検知 • 「役に⽴たないDB」にならないために常に正常系を維持させる • 周辺ツールが機器情報を参照して使えるようにするとこから始める Operator Diff alert & CRUD Network 設定変更 Other Tool 機器情報参照
WIP : これからのフロー Netbox Bot worker • 「DBこそが真」なオペレーション • DBで変更を加えた場合、適⽤するための機器のConfigを丸々⽣成しPR
• CIでSyntax等のValidation実施、⼈が許可したらDeploy • Delete等の⼿続き的なオペレーションフローを伴わずに⾃動適⽤が可能 Network Config Replace Pull Request CI Tools Deploy Device Template Database change Create PR Approve パラメーター
メリット • DBで構成を集中管理 • 機器のConfig Templateと合わせることで 「その機器のConfig」を丸々⽣成し、それをReplaceする • GithubでConfigをPRにすれば、差分が⾒れる&CIも使える •
既存運⽤フローの活⽤ • 他ツールが情報参照する際に機器にアクセスしなくて良い • コードメンテナンス労⼒の抑制 • OSS部分のバグは本家にIssue&PRすればOK • 全て⾃分で保守するべきところは⾃作のところのみ
意外と⼤変だったこと • 常に最新に保つCollector • Diffを算出するのが結構⼤変 • DBに無いのはまだいいけど、DBにあって機器から 消えてるのを探すのもけっこう⼤変 • NAPALMで機器情報を取得しているが、結構情報が⾜りない
• 各メソッドをそこそこ改造している
ちなみにセイコーさんのSmartCSも管理できます︕
こんな機能があったら良いな︕(Serial LLDP) • ラベルの書き換えを忘れて、名前が古いままとかだったりする • 何がつながっているか分からなくなる ↑ ここのLabelをシリアルポートから 解析して⾃動設定してほしい
Thank you!!