ネットワークは宣言的になりえるか - LGTM
2020-07-08 追記 はじめに Kubernetes などのコンテナオーケストレーターとの対比によって、ネットワークの世界でも同じように制御できないか注目されています。Cisco、Apstra、VMWare などが言う "Intent Based Networking" や "Closed Loop Automation" も同じものを指していると思われます。宣言的ネットワーキングは「あるべき状態の維持をプロトコルやソフトウェアに任せられるかもしれない」という点で運用上のメリットがあります。 以前所属していた国際Tier1 ISP *1 で、Kubernetes ほど洗練されてはないものの コンセプトとしてはこれを実践していたり、現在もネットワーク自動化の取り組みの中でゴールをここに設定したりしています。 このエントリーでは、 宣言的ネットワーキングとは何なのか 従来のネットワーク運
条件を満たすとチャット通知するリマインダーをつくる - LGTM
NetOpsCoding Advent Calendar 2015 3日目のエントリーです． 最近はネットワーク運用をラクにすることに興味があります． たとえば RESTCONF のようなI-D が標準され，進化すれば ネットワークへの自動デプロイが実現できると思いますが，それはネットワーク運用の一部でしかありません． スコープをネットワーク運用だとすれば オーダーをもらう ネットワークをつくる 監視する トラブル対応する ネットワークを拡張する 廃止する このようなワークフロー全体をラクに回したい．デプロイツールは1つのコンポーネントなのですが，コンポーネントの進化に比べて ワークフローが進化していない(っぽい) ことに少し懸念を持っています． 雑に言えば「このコンポーネントと このコンポーネントを組み合わせれば，ほら，こんなに便利」という知見が足りないと感じています． 前置きが長くなり
JUNOS でCI する話 - LGTM
ネットワーク運用がどんどん便利になって「手軽にメトリック監視できる」「ネットワークリソース管理がほら簡単」みたいな話はけっこう聞く．ところが，本丸であるネットワーク本体への変更については「慎重に人手で」という運用をしているところが多いと思う． それが悪いということではなくて，たぶん「頻度低いから手動がコストバランス良い」のような理由があるんだけど，じゃあ「それに合う形でワークフローを良くしたいよね」と思う． たとえばCI を導入することで，ネットワークデバイスへの変更について議論しやすくなったり，レビューしやすくなるといいなあと． ネットワークでのCI って難しい ネットワークデバイスに変更を加える場合，ソフトウェア開発のように「あらかじめふるまいを確認する」のはけっこうなコストがかかる．しかし，変更はコマンドのリストとして表現できて，コマンド文法が既知だから「シンタックスが正しい」ことく
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
