継続的デリバリと旧式ネットワーク機器

はじめに

　NetOpsCoding Advent Calendar 2016 - Qiita の19日目の記事です。

　前に書いたブログの記事で「Bere-metal/White Box Switchとか結構いいよね」みたいな話をした。ただ「じゃあ全部White Box Switch買い換えよう!」とは現実的にはならない。性能的な面もあるし、単純に欲しい要件、機能に合致しないだとか、いざという時のベンダーサポートはやっぱりほしい、そもそもお金がないなんて話も。

na-777.hatenablog.com

では旧式のネットワーク機器はどうするんだ?といった話になると思うはず。これらに対して既存の各種ツールをどう適応するかを継続的デリバリの説明を交えて今回考えてみる。ほんとに考えただけなので細かい部分に関してはいろいろツッコミもあると思うし、あまり丁寧な説明ではないところもあるので注意してほしい。

今まで出てきたツールを整理しよう

na-777.hatenablog.com

今まで話したツールをまとめてみると

といったものがある。ただ「これってソフトウェア開発で使ってたツールだよね」と思うはずだ。しかし、前回「ネットワークの継続的インテグレーション」で出てきた「構成管理ツール」によりサーバ周りの状況が一変する。

www.chef.io

　サーバ構築ではShell Scriptなどを使った構築用のプログラムを使うこともあったが、これには問題があった。

コマンド入力後の出力結果を考慮し、行う作業を変更する必要がある
誤ってプログラムを数回実行した場合、単純な作りだと複数設定が追加されたり、ほかの設定を上書きするなどサーバ設定に問題が出る
プログラムを作りこんでしまうと、作成者にしか扱えなくなる

　こういった背景から、個人があまり作りこまなくても、サーバ構築の手順を記述でき、皆で使用できるものが必要とされた。「構成管理ツール」はそういったサーバ構築に特化したソフトウェアである。ここではChef*1とInSpec*2の例を出して説明する。

file "#{ENV['HOME']}/test.txt" do
  content 'This file was created by Chef!'
end

Quick Start — Chef Docs

　公式から抜粋。上記のコードは、テキストファイルを作成するだけだが、書き方を変えればパッケージをインストールしたり、サービスを起動するなどのコマンド実行をコードで表現できる。これらのコードをテストするにはサーバ用のテスティングフレームワークを使用する。

describe file "#{ENV['HOME']}/test.txt" do
  its('content') { should match 'This file was created by Chef!' }
end

InSpec Tutorial: Day 1 - Hello World

　公式から抜粋したコードを少し変更。上記のコードで「This file was created by Chef!」と書かれたtest.txtがあるかをチェックできる。

　このようにサーバ構築の作業内容を、コード化し、コマンド1つでそれらの手順を素早く実行できる。また確認作業もコード化する。サーバの構築手順がコード化されると、ソフトウェア開発で使われていた技術を適応しやすくなる。Infrastructure as Codeの誕生だ。

simplearchitect.hatenablog.com

　単にツールを使うだけではなく、アジャイルソフトウェア開発で適応されていた経験則(プラクティス)なども適応する。バージョン管理、継続的インテグレーション、コードレビュー、リファクタリングなどが代表的なものだろう。

　継続的インテグレーションでは、常に「完成品のソフトウェア」が開発環境に置かれるが、本番環境への投入まで行かなかった。Infrastructure as Codeの恩恵により、開発環境から検証環境、検証環境から本番環境への移行時間が短縮され、いつでも「完成したサービス」を届けられるようになった。これが継続的デリバリ(Continuous Delivery)だ。

ネットワークに置き換えよう

　下記の図は、Infrastructure as Codeでよくある構成だ*3ネットワークに適応するには何が足りないだろうか？

f:id:na-777:20161217005713j:plain

PC・ビジネス | FLAT ICON DESIGN -フラットアイコンデザイン-

Chef/Git/Oracle VM VirtualBox/GitLab/Jenkins

　すぐに思いつくのは「構成管理ツール」と「テスティングフレームワーク」だ。じゃあこれを作ればよいのかと思うが、ネットワーク機器の設定ファイルを思い出してほしい。これはコードではないだろうか?

interfaces {
    ethernet eth0 {
        address dhcp
        hw-id 00:0c:29:44:3b:0f
    }
    loopback lo {
    }
}

User Guide - VyOS

　ネットワーク機器にはFTPを使って設定ファイルのバックアップしたり、設定ファイルをFTPで取得してネットワーク機器に適応するコマンドが存在する。つまり設定ファイルさえあれば、ネットワーク機器へログイン/設定ファイルを投入する程度の操作で済む*4。この部分の操作をexpectなどで自動化しておけばAPIなどを持たない旧式のネットワーク機器などにも比較的楽に設定投入が可能だ。

qiita.com

設定ファイルの作成を楽にしたい場合はヒアドキュメント使うのが手っ取り早い。ただ、設定項目が多くなった場合はこれでは綺麗ではないのでERBを使うのも良いかもしれない。PythonならJinja2などだろう。

github.com

　テスティングフレームワークに関してはNetOpsCodingなどで取り上げられている物を使用するのもアリだ。また簡単なネットワークの疎通テストをするだけであれば、CIツールのJenkinsが持つslave agent機能を使って[Pingを行うNode] [パケットキャプチャを行うNode]などを立てて置き、それらにJobを実行させるのもいいだろう。これらのログはすべてJenkins上で見ることができるし、Jenkinsfileを使用すれば細かいJobの設定を行うことができる。

あなたの目的は何ですか？

megamouth.hateblo.jp

　とりあえずいろんなツールを出してみたものの現実は非情である。これらのソフトウェアを採用するのが正しいか、正しくないかは「あなた」もしくは「チーム」が、さらには「組織」がどんなことで困っているかにもよる。ツールを採用するのも、チームの運用に口出しできる程度の業務権限が必要だし、チームメンバはソフトウェアの使い方を覚える必要がある。導入したけど「何が便利なのかわかりません」「今までよりも仕事が増えました」というのもざらにある*5。

codeiq.jp

「もう小学生でもプログラミングできる時代になっているので、コードが書けるだけなら小学生以下だよねということは言いたいですね」

　以前一緒に仕事をした熟練のプログラマも似たようなこと言っていた。いやだなー。怖いなー。

www.inagawa-kaidan.com

　この話は、プログラミングができるだけではなく、そのプログラムによって「何をして」「どう便利になり」「いかに稼ぐか(or 費用削減するか)」という目的の部分を指している。ネットワークに対してInfrastructure as Codeを適応する際にも考えられる。果たしてあなたはネットワークの何を、どう便利にして、結果どういった利益を得たいのか？そこを明確にするために、現在の作業手順や、運用を振り返り、そこに今まで出てきたソフトウェアをどう適応するかを考える必要があるだろう。

まとめ

構成管理ツールによりサーバ構築の手順がコード化されるようになった。
ソフトウェアの手法をインフラに取り入れるInfrastructure as Codeというものが出てきた。
不足している部分もあるがネットワークにもこれらを適応できるのではないか。
不足している部分も、既存技術の組み合わせなどで対応はできる。
ただし、自分たちにとって本当に必要なものを選択する必要がある。

*1:Ansibleは楽だが、ちょっと複雑なことをしようとすると面倒だったりする。また、サーバ向けのテスティングフレームワークはRubyのRspecベースがほとんどで、Rubyの知識が必要になる。構成管理ツールもRubyで書けるほうが設定情報の共有などしやすく、書き方も混乱しないので個人的にはChef良さそうだなと思ってる。

*2:Serverspecでも良かったが、Chefの公式見たらInSpecというテスティングフレームワークあったので引用。書き方はServerspecと同じようなところもあるが、一部機能拡張されていたり、方向性の違いが見える。

*3:GitHubやCircleCIでも良かったが、たぶんネットワークの人とかは手元の環境で使用できるソフトウェアのほうがよさそうな感じがしたので。

*4:コンフィグ投入時における、設定反映・各種プロトコルなどに起因するネットワーク断時間だとかはあんまり考えてないが。

*5:ほとんど構成が変わらないネットワークがあったり、設定手順が定型化できない作業も存在する。そういったネットワークの自動化コードを書いても、大きな効果があるようには思えない。