/var/log/study

つまり雑記

EdgeRouter X を Prometheus の node_exporter でメトリクス収集をしてみる

世の中にzabbixとMackerelは実際の知見があったけど、Prometheusを利用してEdgeRouterのメトリクス収集の知見は多く無さそうだったし、今後Prometheusを活用できないのは困るので、練習として。

ただし、EdgeRouter(≒VyOS≒Vyatta) にサービスを追加するのをきちんと取り組もうとする (=vyosのインターフェースで色々と設定できるようにしてあげる) と死ぬほど大変そうなので、一旦はnode_exporterが問題無さそうに動くまで。

自分の記事で扱う範囲は、EdgeRouterにnode_exporterを設置するところまでなので、Prometheusサーバーの構築等は他の記事を参考にしてください。

方針

  1. EdgeRouterをMackerelで監視する方法が世の中に知見として転がっているので、それを真似する。
    • Mackerel-agent も node_exporter も golang で書かれていて、知見の転用がし易いから
  2. EdgeRouter上で追加のサービスをきちんと動かすための知見が少ないのでそこもお手軽にやる。 
  3. メトリクスに関しては後日整備する

やったこと

Prometheusの入門を眺める

knowledge.sakura.ad.jp

node_exporterをコンパイルする。

papix.hatenablog.com

上記を参考にしつつ、以下の様なコンパイル方法に落ち着いた

自分はmacの上でコンパイルして、EdgeRouterに持っていった。

go get github.com/prometheus/node_exporter
cd ${path}/${to}/node_exporter
env GOOS=linux env GOARCH=mipsle go build node_exporter.go

EdgeRouterのCPUは普段使うPCとアーキテクチャが違うけど、こういうときにgolangのクロスコンパイルの便利さが効いてくるなぁと思った。

EdgeRouterにコンパイル後のバイナリを置く

後述するinitスクリプトの兼ね合いで /opt/promehteus/node_exporter にした。

node_exporeter用のinit scriptを設置する

EdgeRouterはinit.d でサービスを取り扱っているので、以下のスクリプトをパクらせてもらって /etc/init.d/node_exporter とした。

Init.d script for prometheus node exporter · GitHub

自分でいじったのは、USERを prometheus から root にしたくらい。

実際の起動

sudo /etc/init.d/node_exporter start

Rebootしても大丈夫にする

EdgeRouterのOSの元になっているDebianとかでは chkconfig はなく、 update-rc.d などを使うことになっているが、 EdgeRouter内には無い雰囲気。

ので、今回はお手軽に /etc/rc.local/etc/init.d/node_exporter start を追記しておくことにする。

確実にもっといい方法があるのだけど、EdgeRouterのお作法がよくわからなかったので一旦はこれで。

実際の雰囲気

自分のルーター172.0.0.1 で動いているので以下のようになった。途切れているのはrebootした所で、監視のダウンタイムは大体3分くらい。

f:id:yaaamaaaguuu:20180128215101p:plain

laptopにnixosをインストールする前後の話

nixosというlinuxディストリビューションがある。

大体の話は以下にまとまっている。

github.com

インストール方法も上記wikiインストール のページに書いてある。

インストール自体で自分が若干詰まったのは、MBRなのか?GTPなのか?くらいで特に言及することがないのだが、その前後で書き残しておくとnixosに入門したい人の役に立てるのかなぁと思うので、書き残しておく。

インストール前

Installation of NixOS with encrypted root · GitHub

上記を参考にBIOSの画面で、Disable Secure Boot ControlDisable USB legacy boot というのをした。

インストール後

自分が実施したのは以下

  • ネットワークの設定
  • bluetoothの設定
  • フォントの設定
  • non free なソフトウェアを参照するための設定
  • dockerの設定
  • laptopのJISと外付けのHHKBの英字を共存させるための設定

ネットワークの設定

インストールのページで wpa_supplicant 云々と書いてあるが、OSをインストール後, NetworkManagerを入れると良い。

GUI付きのインストーラーだと、ネットワークを設定するウィジェットがあるが、OSインストール後にはないように見える。が、実はNetworkManagerをインストールすることでインストール前見えていたウィジェットが見えるようになる。あとはNetworkManagerが良しなにやってくれる。

nix-env -i NetworkManager

bluetoothの設定

/etc/nixos/configuration.nix に以下を書き込んだ。

  hardware.bluetooth.enable = true;
  hardware.pulseaudio = {
    enable = true;
    package = pkgs.pulseaudioFull;
  };

bluetoothをenableにするだけだと、bluetoothスピーカーとかが良い感じに動かなかった。

フォント

以下のような感じ。

fonts = {
    enableFontDir = true;
    enableGhostscriptFonts = true;
    fonts = with pkgs; [
      ipafont
    ];
  };

non free なソフトウェアを参照するための設定

この設定に気づくのに謎に時間がかかった。

nixpkgs.config.allowUnfree = true;

上記を有効にしておくと、slackとかdropboxとかのクライアントが使えるようになって便利。インストールは上記を有効にしたあとnoxで適当に探すと良い。

nix-env -iA nixos.pkgs.slack
nix-env -iA dropbox

dockerの設定

インストールは nix-env -iA docker

設定は以下

  virtualisation.docker.enable = true;
  virtualisation.docker.enableOnBoot = true;

あとユーザーをdockerグループに属させる

laptopのJISと外付けのHHKBの英字を共存させるための設定

  • 面倒なので割愛
    • 需要があれば書きます。

2017年の振り返りと2018年の抱負

2017年度の振り返り

  • 自分の主戦場がwebからインフラに少しづつシフトしている
  • 出来ること、やってみて理解が出来ることが増えた
    • たぶんネットワークは初学者くらいの力がついたはず
    • フルスクラッチで実装できるものが増えた
    • 馴染みのあるプロトコルならrfcを読んで実装に落とせる様になった
  • 理系卒インフラエンジニアだらけの職場になった
    • 周りの人たちは自分の知らないことを知っていることが自覚できた
    • とくにコンピューターサイエンスの基礎教養的な箇所

「周りの人たちは極々普通のこととして、自分の知らないことを喋る」というのが2017年だったと思う。

  • ネットワークの話し
  • Linuxカーネルの話し
  • FPGAの話し
  • コンピューターの各種インターフェースの話し
  • etc

2018年度の抱負

特に自分はプログラミングやコンピュータとの関わりが短いので、周りの人との知識量の差を埋めていくか?を考えると、2018年は「できないこと、知らないことを減らす」というのが抱負になる。

EdgeRouter X がファクトリーリセットも効かなくなったのを直した話し

タイトルどおり。 現状は解決に至っていないので、問題の解決方法を知りたいだけならココを見るのは無駄である。

解決した。

yaaamaaaguuu.hatenablog.com

上記を書いてはや数ヶ月。EdgeRouterは息をしなくなった。当然自宅リージョンは全断の状態で非常に困っている。

いまネットを問題なく使えているのはwifiのアクセスポイントとして使っていたやつを急遽ルーターとして再活躍してもらっているからだ。

死んだルーターは以下のやつ。

Ubiquiti Networks Edgerouter ER-X(日本国内)

Ubiquiti Networks Edgerouter ER-X(日本国内)

先に諸々で現状困っていることを書き残す

  • ルーターがDiskfullで死んでいる
  • コンソール接続ができている
    • 一応ファクトリーリセットが効いている様
      • 既存のユーザーのパスワード等は効かない
    • ただし、リセットの一部の工程は上手くいっていない模様
      • 初期ユーザーのパスワードセットとか user: ubnt, password: ubnt とかが設定されてない
  • シングルモードユーザーでのログインを試みているが上手くいっていない
    • が、EdgeRouterの U-Boot でどうしたらLinuxのbootargsにsingleを渡せるのかが分からない
    • bootargsは一応書き換えられるが、書き換えた状態からU-BootのCLIからbootさせる方法がわかっていない
      • 分かった

作業ログてきなモノ

現状の整理

  • 最近なんか調子が悪かった
    • web UIがすぐ落ちたり
  • EdgeRouterにssh出来ない
    • そもそもpingが到達しない
    • 自宅のルーターだからと言って、気軽になんどかrebootした
  • 筐体のLEDは光っている
  • ファクトリーリセットを何度か実行しても状況が変わらない

思い返す

大丈夫だと思ってさらっと見逃したが、ディスクフルだったのでは?という気がしてきた。

対応策

  1. 2年間の保証があるとのことで対応してもらいたい
    • 代理店?が休業中っぽい 😇
  2. USBでコンソールに繋いでなんとかする
    • 仕方がないので今回はこっち

ER-XにUSBでコンソールにつなぐ

元ネタは以下。

community.ubnt.com

なるほど。USB-TTLで変換するのがあれば、ルーターにはシリアルポートが無いバージョンのやつだけどコンソール接続できそう。

amazonで似たようなやつを調達した。

現状の作業環境はOSX high sierraなので、ドライバの配布ページ からドライバをダウンロード, インストールして使えるようにして、結線は以下のようにした。

左から、接続なし, 緑, 白, 黒

このMacについて -> システムレポート -> USB でUSB-TTL が接続できているか?が確認でき、

f:id:yaaamaaaguuu:20171218013355p:plain

ターミナル上で、 /dev/tty.usbserial の有無でドライバが正しくインストールできているか?が確認できる。

でもって、minicomというやつを使えば、コンソール接続できるらしいのでおもむろに brew install minocom した。

接続は以下のコマンド

minicom -b 57600 -o -D /dev/tty.usbserial

f:id:yaaamaaaguuu:20171218013706p:plain

色々出ているが、 no space left というワードが決定的

でもって、bootの途中に、boot方法どうする?と聞かれるので 4 を押す。

そのあとに以下を叩いて現状確認

printenv
~~~
bootargs=console=ttyS1,57600n8 ubi.mtd=7 root=ubi0_0 rootfstype=ubifs rootsqimg=squashfs.img rootsqwdir=w rw
~~~

あとはbootargsにsingleを加えてシングルユーザーモードで起動するようにする

setenv bootargs=console=ttyS1,57600n8 ubi.mtd=7 root=ubi0_0 rootfstype=ubifs rootsqimg=squashfs.img rootsqwdir=w rw single
saveenv
boot bfd40000

bootコマンドの引数の理由は、特に何も指定しなかった時のbootのログから Booting image at bfd4000... とあったのでそれに従った。

Please choose the operation:
   1: Load system code to SDRAM via TFTP.
   2: Load system code then write to Flash via TFTP.
   3: Boot system code via Flash (default).
   4: Entr boot command line interface.
   7: Load Boot Loader code then write to Flash via Serial.
   9: Load Boot Loader code then write to Flash via TFTP.
default: 3
 0

3: System Boot system code via Flash.
## Booting image at bfd40000 ...
   Image Name:   Linux Kernel Image
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:    1708328 Bytes =  1.6 MB
   Load Address: 80001000
   Entry Point:  803799d0
...........................   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

残作業として、 /root.dev が100%になっていることを確認したらフォーラムに以下の事が記載されていたので、それにしたがって古いファームウェアを消した。

community.ubnt.com

その後rebootしたらいつも通りのEdgeRouterが戻ってきたので、あとは頑張って設定を復旧するのみ 😇

ISC DHCP から置き換わるであろう Kea の話し 後編

ISC DHCP から置き換わるであろう Kea の話し 後編

Kea DHCPに纏わる話を 、後編という感じで書きます。

本記事は後編です。以下の記事は2017/12/17にwebにある情報を元に記述しています。

前編, 中編の振り返り

  • ISC DHCPの開発が終わってサポートも終わろうとしているよ
  • 今後は Kea というDHCPを開発していくよ
  • Keaは色々便利機能とかがあるけど、特にWebAPIサーバーが生えていて便利!!!
  • 色々APIが生えているよ
  • ドキュメントの類いが充実しているよ

今回書くこと

  • 中編で取り扱わなかったAPIについての言及
  • 有料のhookの存在
  • 最近の開発動向

中編で取り扱わなかったAPIについての言及

中編では主に3つのAPIが生えていると言及しました。また主に設定変更等を含むサーバー操作系のAPIについて言及もしたので、本記事ではそれ以外のリース情報操作系と統計情報閲覧系について言及しようと思います。

  • 設定変更等を含むサーバー操作系
  • リース情報の操作系
  • サーバーが受け取ったパケットの統計情報の閲覧系

リース情報の操作系

http://kea.isc.org/docs/kea-guide.html#lease-cmds に記載があります。利用方法は、 設定ファイルで libdhcp_lease_cmds.so を読み込むだけなのですが、一点注意があり、 Control-Agent の設定には対象のhookを 記載してはいけない という事があります(Dhcp4やDhcp6にだけ記載するということ)。もし両方を読み込むと、リース操作系として使えるAPIは常に、no current lease manager is available というエラーのレスポンスを受け取ることとなります。一応、Control-AgentとDhcp4の両方でhookを読み込んだとしても、標準のAPIには影響が無いことを確認しています。

APIを上手く叩けず、試行錯誤していたらたまたま気づきました。コードを読んでもなぜそうなっているのか?は追えなかったのですが 内部のコンポーネントの一つの LeaseMgr を生成するためのここらへん の処理が不可解な状態になっているのではないかなぁ?と推測しています。

さて注意点を先に記載したのですが、上記APIで出来ることとしては、リースデータベースを操作することです。ここで思い出していただきたいのが、Kea のバックエンドには複数種類の方法を選ぶことが出来る点です。つまりこのAPIで本当に提供したいことはMySQLPostgreSQL, Cassandraを抽象化し、バックエンドにかかわらずリースの情報を操作するインターフェースを提供することとなります。

Note: not all backends support this command.

なんてこっそりと書いてありますが、どのバックエンドでも利用できそうな雰囲気をしています。コードは以下にリンクするので困ったら読めば良いと思います。

出来ることは以下となっています。

  • lease4-add
    • adds new IPv4 lease;
  • lease4-get
    • checks if an IPv4 lease with the specified parameters exists and returns it if it does;
  • lease4-del
    • attempts to delete an IPv4 lease with the specified parameters;
  • lease4-update
    • updates an IPv4 lease;
  • lease4-wipe
    • removes all leases from a specific IPv4 subnet;

個人的には、払い出したIPとmacaddressのリストが欲しいと思うので、lease4-get-all とかのコマンドが欲しいよね?と思ってます。

サーバーが受け取ったパケットの統計情報の閲覧系

http://kea.isc.org/docs/kea-guide.html#stats に記載がありますが、DHCPが受け取ったパケットの統計情報を見ることが出来るAPIが生えています。

利用の仕方は標準APIと同様、設定のjsonでhookは指定せず利用可能ですが、APIを叩く際はサービスを指定することだけ忘れないようにしてください。(Control-Agentに対して(サービスを指定しない状態)でlist-commandsとかをしても統計APIは見えない気がします。)

叩いてみた程度なので、使いみちについてはよくわかってませんが、運用する際は頭の片隅においておくのが良いと思います。

statistic-get-all を叩くと以下の様なレスポンスが返って来ます。たとえば、declined-addresses とかがやたら増えていたら、DHCPとして嬉しくないことが管理配下のサブネットで発生している!とかが分かるんですかね。

[
  {
    "arguments": {
      "declined-addresses": [
        [
          0,
          "2017-12-17 15:24:55.003177"
        ]
      ],
      "reclaimed-declined-addresses": [
        [
          0,
          "2017-12-17 15:24:55.003183"
        ]
      ],
      "reclaimed-leases": [
        [
          0,
          "2017-12-17 15:24:55.003188"
        ]
      ],
      "subnet[1].assigned-addresses": [
        [
          0,
          "2017-12-17 15:24:55.003195"
        ]
      ],
      "subnet[1].declined-addresses": [
        [
          0,
          "2017-12-17 15:24:55.003201"
        ]
      ],
      "subnet[1].reclaimed-declined-addresses": [
        [
          0,
          "2017-12-17 15:24:55.003208"
        ]
      ],
      "subnet[1].reclaimed-leases": [
        [
          0,
          "2017-12-17 15:24:55.003214"
        ]
      ],
      "subnet[1].total-addresses": [
        [
          224,
          "2017-12-17 15:24:55.003159"
        ]
      ]
    },
    "result": 0
  }
]

有料のhookについて

管理者向けのリファレンス に記載がありますが、いくつか有料のhook(plugin)が販売されています。エンタープライズな感じで使いたい会社に向けたライブラリを提供している印象です。

https://www.isc.org/product/kea-premium-hook-library-kea-1-3-package/ で購入することが可能で、$499だそうです。

  • legal_log: Forensic Logging Hooks
    • たぶん監査とか用のログを出力するライブラリ
  • host_cmds: Host Commands
    • staticにipを割り振るためのライブラリ
    • 標準のAPIでも出来ることは出来るのですが、効率よく処理を行うためのライブラリとなります。
  • flex_id: Flexible Identifiers for Host Reservations
    • こちらもstaticにipを割り振るためのライブラリ
    • 何を持ってipを割り振るか?を柔軟にするヤツっぽい

また Currently this library is only available to ISC customers with a support contract. という形で以下のライブラリも扱っているようです。

  • subnet_cmds: Subnet Commands
    • サブネットを操作するためのライブラリ
    • 標準のAPIでもサブネットを操作することは可能なのですが複数のサブネットを効率よく操作するものだと思います。

最後に開発最近の動向

では最後に少しだけ最近のKeaの開発動向についてを触れて終わりにしたいと思います。

半年ほど前に1.2.0, 先月くらいに1.3.0, 半年くらい先に1.4.0が予定されている状態です。

http://kea.isc.org/wiki/KeaReleaseNotes120 とか https://www.isc.org/blogs/kea-1-3-released-take-it-for-a-spin/ とか http://kea.isc.org/milestone/Kea1.4 が元ネタです。

  • 1.2.0
    • いくつかの DHCPオプションに対応した
    • Control-Agentが追加されてhttpなAPIが叩けるようになった
  • 1.3.0
    • lease_cmd.so が付属するようになった
      • 上記のhookを読み込むとhttpなAPIでリースを操作可能となった
    • Control-Agentをhttpsで叩ける様になったとのこと
  • 1.4.0
    • High Availability と呼ばれる機能が開発中
    • Radius と呼ばれる認証認可のプロトコルに対応しようと考えている
    • 実はCassandraの対応が実験的機能なので、改善しようと考えている
    • Migration Assistantを作ろと考えている
      • ただし、Keaの機能ではなくWebサービスで実装しようと思っている

前後のバージョンの状態を見るに、KeaのDHCPとしての改善は若干落ち着いてきており、より運用を楽にするための改善、ISCとのコンパチビリティとマイグレーションをどの様にしていくか?に主眼が置かれつつあるのかな?という気がします。

まとめ

Kea DHCPに纏わる話を 、後編という感じで書きました。

クラウドの台頭により、需要が減っているプロトコルミドルウェアなのかもしれませんが、今後DHCPを新規で立てる際は、残り何年もないISC DHCPより、Keaを選択する人がこの記事によって増えたらと思います。

また前中後に分割しても書ききれなかった知見や、Keaをプロダクションに持っていくためのスクリプトを書いていたりするのがあるので、それはそれで、また機会があれば纏めて書き残したり公開したりしたいと思っていますので、今後共よろしくお願いいたします。

Caskがmelpaにつながらないと言っている時のワークアラウンド

普段emacsのパッケージ管理には cask ってやつを使っている。macbrewの caskでは無く、emacsのcaskだ。

で、久々にemacsのパッケージをインストールしようと思ったら以下のエラーが出た。

cask install
Contacting host: melpa.org:443
Failed to download ‘melpa’ archive.
Contacting host: elpa.gnu.org:443
Package refresh done
Failed to download ‘gnu’ archive.
Setting ‘package-selected-packages’ temporarily since "emacs -q" would overwrite customizations
Setting ‘package-selected-packages’ temporarily since "emacs -q" would overwrite customizations
Package ‘s-’ is unavailable

原因

今回、自分で起きた問題の原因はmelpaにつなぎに行くときのSSL証明書がいつぞやから変わった模様

解決方法

emacs -q で起動する -> M-x package-refresh-contents 的なやつを実行すると無事解決が出来た。

惜しい解決方法

以下のcommitを真似してhttpsにしても、うまくいかない。(どこかのcommit番号では意味があったのかもしれないが、今は有効的な手段では無さそう。)

github.com

ISC DHCP から置き換わるであろう Kea の話し 中編

ISC DHCP から置き換わるであろう Kea の話し 中編

Kea DHCPにまつわる話を 、中、編という感じで書きます。

本記事は中編です。以下の記事は2017/12/10にwebにある情報を元に記述しています。

またこの記事は 富士通クラウドテクノロジーズ Advent Calendar 2017 の11日目です。

昨日は @alice02 さんの 「サーバ脆弱性スキャンの定期実行・結果通知を自動化してみた」 でした。

この世に存在しているサーバは常に悪意のある攻撃者からの攻撃対象になっています。

と言う一文が、脆弱性対策の重要性をよく表していると思いますので、まだチェックしていない方は是非チェックしてみてください。

前置き

新卒入社2年目の @yaaamaaaguuu です。PHP, Python, Golang を NGINX Unit で動かしてみた - /var/log/study とかを書いた人です。

2017年12月11日現在、富士通クラウドテクノロジーズ(FJCT) で、二フクラのためのソフトウェアエンジニアをやっています。去年のAdventCalenderでは 「レガシーなPHPを改善する為に(新入社員が勝手に)取り組んだ3つの事」という記事を書くくらいはWeb寄りのエンジニアでしたが、部署配属によりインフラに近いエンジニアとなりました。大まかな担務としては物理を含まないネットワークを中心に取り扱っています。

そんな自分が去年 ~ 今年にかけて任された仕事のうちの1つに Keaの検証 というのがあり、日本語で公開されている知見は少ないため書き残しておこうと思います。

と言う意図の記事を書いていたらめちゃくちゃ長くなったので 前後編 3分割しました。DHCP としてKeaが革新的なのはAPIがあることなので、AdventCalender的にはこの記事で登録しています。

前篇のあらすじ

  • ISC DHCPの開発もサポートも終わろうとしている
  • 今後ISCは Kea というDHCPを開発していく
  • Keaは色々便利機能とかがあるけど、特にWebAPIサーバーが生えていて便利!!!

今回書く話し

  • Kea DHCPを動かしてみる
  • Kea DHCPについているAPIの動かし方と注意点
  • ログのフォーマット
  • Keaの検証してみて良いと思った話しとまとめ

対象

DHCPとDockerを動かしていきますので、DHCPプロトコルを知っているかた かつ Dockerの動かし方を知っている方向けに書いています。

最新版の動作を試すには?

前篇でKeaの特徴などを述べてきましたが、ではKeaを動作させるにはどうしたら良いか?を書いておきます。

2017/12/10、現在 インストールのページを眺めても、最新版であるv1.3.0のパッケージは提供されていません。v1.2.0を提供しているのもBSD系とArchLinuxだけですね。せめてv1.2.0以上でないとAPIサーバーの機能が使えず嬉しさ半減です。

なので、最新版をDockerのイメージとして用意いたしました。 (ただし、野良ビルドですので、プロダクション等で利用されても特に責任は取れせんので注意してください。)

https://hub.docker.com/r/shouhei/kea-dhcp/

dockerをインストール済みの方は、以下のコマンドでイメージをダウンロード可能です。

docker pull shouhei/kea-dhcp:v1_3_0

自分ではLinux上で動くことしか検証していません。DHCPがリクエストを受けられるようにhost networking機能を使っているためMacでは動作しないのがわかっています。(もしAPIだけ動けば良いんだ!という気持ちならば、host networkingの設定を外したり、コメントアウトしたりしたら良いと思います。 )

設定ファイルのサンプルは以下においてあるので、それを利用します。ホストについている全てのネットワークインターフェスから、192.168.10.0/24 でIPを配布する設定となっています。検証の環境に合わせて適宜変更してください。変更する際は管理者リファレンスの8.2を参照すると良いです。

kea-docker/config.json.example at master · shouhei/kea-docker · GitHub

肝心の動作方法は以下のような感じで。

docker run --net=host -v ${PWD}/config.json.example:/etc/kea-config.json -it kea-dhcp:latest kea-dhcp4 -c /etc/kea-config.json

すると、設定ファイルで指定したインターフェースがつながっているネットワークでIPの配布が可能になるはずです。

ここまでは極々普通のDHCPサーバーです。

Kea の API サーバーを動かす

まず、KeaのAPIサーバーをDockerで試すには、以下の理由から少し工夫が必要です。

  1. Dockerの1プロセス1コンテナのモデルを守りたい
  2. APIサーバーであるControl-Agentは、Dhcp4サーバー等に処理をディスパッチするためのwebの受け口である
    • ディスパッチの経路がソケットファイル

図にすると以下のように動いて欲しいのです。

f:id:yaaamaaaguuu:20171211025058p:plain

なので、上記を満たすためのdocker-composeファイルと設定ファイルも作成しておきました。

gist.github.com

上記をローカルにコピーして docker-compose up を実施すると動くはずです。

サンプルの設定は簡易版です。後述する config-write というAPIでKeaの持つ設定を別名で書き出すことも、同名で書き出すこともできますが、同名で書き出すとControl-Agent用の設定か、DHCP4の設定が上書きされて消されるのできちんとやる場合は設定ファイルを分割して読み込ませてください。

APIの叩き方は以下のコマンドの様に、curlを使って、Headerに Content-Type: application/json をつけ、POSTメソッドでJSONを投げつけます。

curl -H "Content-Type: application/json" -d '{"command": "list-commands", "service": ["dhcp4"]}' localhost:8080

基本的には以下の3つのkeyとvlaueを指定することでAPIを動作させます。

  • command
    • コマンド
    • apiのlist-commandsで一覧が見れる
    • 後述するサービスとの組み合わせで利用できるコマンドが異なるのに注意
  • service
    • dhcp4なのか、dhcp6なのかとか
    • 配列形式での指定
    • 癖があるので後述する
  • arguments
    • apiによって異なるのでリファレンス参照

APIリファレンス自体は http://kea.isc.org/docs/kea-guide.html#ctrl-channel にあります。

現状標準で使えるAPIとしては大きく分けて3つあります。

  1. 設定変更等を含むサーバー操作系
  2. リース情報の操作系
  3. サーバーが受け取ったパケットの統計情報の閲覧系

サーバー操作系のAPIではconfig全体を書き換える、読み取るくらいしかできないのですが、それでもプログラムから設定の自動生成、投入するには事足りると思います。

また(有料のAPI群にまぎれて)リース情報の操作系を取り扱うhookとAPIはv1.3.0からは同梱されるようになりました。hookを読み込むことで使えるようになります。リース情報のデータベースを初期化したりするapiが生えています。 http://kea.isc.org/docs/kea-guide.html#lease-cmds に詳しい情報が書いてあります。が検証しきれていないので特に言及はしないことにします。

Kea の APIの挙動

APIの種類やコマンドKeaのAPIは挙動に癖があると感じています。これらはおそらくバージョンが上がっていくごとに改善されていくと思うのですが、現状の挙動と癖を書いておこうと思います。

設定変更等を含むサーバー操作系のAPIの注意点

リファレンスには書いてあるのですが、自分が最初に触ったときに若干引っかかったことを記載しておきます。

  • config-write
    • 現在DHCPがメモリ上に持っている設定をファイルに書き出す
  • config-set
    • リクエストとして送ったデータをDHCPの設定としてメモリ上に持つようにする
    • ファイルには書き出さない
      • 書き出したい場合は上記config-write を呼び出す。
    • config-setの後、特にサーバーの再起動等は不要
    • argumentsとして渡すのは、全設定となる
      • 渡さなかった設定値は、サーバーで設定されているデフォルト値となるはず
    • config-setの際はソケットファイルの設定だけは書き換えないように注意する必要がある
      • ソケットファイルを書き換えたが最後、DHCP的にはソケットファイルが見つからず、APIのリクエストが通らなくなる気がします

引数について

serviceにはリスト形式でdhcp4やdhcp6が指定できますが、何も指定しないと、control-agentを指定する事になります。

また、v1.3.0 では control-agentを文字列で指定できません。(ソースを読む限りそうなっていますし、文字列で指定するように修正するのは大変そうだなぁと思っています。)

つまり、dhcp4とcontrol-agentを同時に指定することは不可能です。なので、config-write で設定を上書きしたい際は設定ファイルを分割させる必要があります。

APIレスポンスについて

後述しますが、ログが充実している代わりに、APIレスポンスのメッセージが凄く貧弱です。

HTTPのレスポンス的には200と400しか返さなかったと記憶しています。もしかしたら201と404くらいは追加であったかも。

でもそれくらい貧弱で、たまーにエラーでもhttp的には200を返したりします。なので、APIのレスポンスは result というkeyを信じる事にしましょう。

result indicates the outcome of the command. A value of 0 means success while any non-zero value designates an error or at least a failure to complete the requested action. Currently 1 is used as a generic error, 2 means that a command is not supported and 3 means that the requested operation was completed, but the requested object was not found.

とドキュメントにも記載があるので。

ログの話

APIレスポンスの話の際に、ログが充実していると記載しました。ログのメッセージ自体はリファレンス にありますがKeaのログのフォーマットと、ISC DHCPのログのフォーマットを比較しておきます。

ISC

ISC DHCPDHCPプロトコルのメッセージに沿ったログの出力をしています。ぱっと見たときはわかりやすいのですが、Keaと見比べると異常系のログはなぜ?という情報が少なく思えます。

#具体例
Dec 11 10:35:31 isc-dhcp-server dhcpd: DHCPACK on 192.168.0.55 to xx:xx:xx:xx:xx:xx via eth0
# 説明
日付 ホスト名 dhpcd: DHCPメッセージ on ipアドレス to macaddress via インターフェース

Kea

keaの内部の動作に沿ったログの出力をしています。以下のパターンの場合は、メッセージマニュアル ページで DHCP4_BUFFER_RECEIVED を調べるとログの出力の理由がわかるようになっています。また内部のコンポーネントのどこからメッセージが出力されたか?は kea-dhcp4.packets管理者リファレンス・マニュアル で調べるとわかるようになっています。

#具体例
2017-12-10 22:12:15.972 DEBUG [kea-dhcp4.packets/1] DHCP4_BUFFER_RECEIVED received buffer from 0.0.0.0:68 to 255.255.255.255:67 over interface ens224
#説明
日付 ログレベル [ログの出力元] メッセージ(大文字の箇所) 詳細(大文字以降)

Keaを検証して、良いサーバーだと思えた箇所とまとめ

まとめに入っていこうと思います。Keaを検証してよいと思えた点は、以下だと思いってます。

ここまでで、APIサーバーとしてこまった箇所をいくつもあげてしまいましたが、web apiが生えて利便性は確実に高まったと思っています。設定変更のためにサーバーにログインして設定ファイルを書き換えて... と言った仕事を減らすことがより簡単に可能になると思います。また将来的には、そのAPIを活用してIPAM等との連携も視野に入れているようです。(そこらへんは後編で書くつもりです。)

運用の自動化、効率化とは別の側面を考えると (前篇で問題としてあげていた) ISC DHCPから Kea DHCPへの乗り換えというのがあると思っています。その際に効果を発揮してくるのが、ドキュメント類の充実具合です。どのようなサーバーよりKeaのドキュメントは充実していると思うので、開発する際はお手本にしたいと思えるくらい充実しています。

そのメッセージリファレンスが活躍するのはログ出力を眺めているときで、Keaではサーバーの内部挙動に合わせたログ出力になっています。設計段階からログ出力とメッセージリファレンスを突き合わせることで内部がどの様に動いたかを提示しやすくする様に考えているはずで、困ったときは大体メッセージリファレンスと再現するか?の検証で事が足ります。ISCとKEAで開発会社が同じだけ合って、困りどころがよくわかっているなぁと感心してしまいます。

ということで、将来的にはDHCPを置き換えるであろう、Keaの話しの中編を投稿させていただきました。

プログラムは3度作り直されるというのを過去に何処かで読んだ事があります。そこには 荒削りなプログラム -> 機能満載で使いづらいプログラム -> 洗練されたプログラム という流れをたどると書いてあったと記憶しています。 ISC DHCP -> BIND10 -> Kea という形を経て、確実に良いサーバーになっていると思うので、DHCPを構築運用している方はKeaを試してみるべきだと思います。

明日の話し

まず個人的な話をするとこの記事の後では、個人的には統計情報APIや有料hook, 開発のマイルストーンなど、 前編、中編で拾えなかった話を後編として落穂拾いをしていきます。

アドベントカレンダー的な話しをすると、明日は @Ken-Moriizumi さんの 「KONGでニフクラスクリプトもチームもマネジメントする話」 という記事です。

たぶん https://github.com/Kong/kong のことだと思いますが、マイクロサービス向けのAPIゲートウェイとのことで、APIゲートウェイの話しがどのようにしてチームマネージメントにまで繋がるか?が個人的には気になるところです。

KONGのアイコンがめっちゃかっこいい。どうでも良いですが、動物続き(keaはニュージーランドの高山に住むオウムの名前って書いてありました。)な事に気が付きました。

引き続き、 富士通クラウドテクノロジーズ Advent Calendar 2017 をチェックしていただければと思います。

よろしくお願いいたします。