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的にはこの記事で登録しています。
前篇のあらすじ
今回書く話し
対象
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で試すには、以下の理由から少し工夫が必要です。
- Dockerの1プロセス1コンテナのモデルを守りたい
- APIサーバーであるControl-Agentは、Dhcp4サーバー等に処理をディスパッチするためのwebの受け口である
- ディスパッチの経路がソケットファイル
図にすると以下のように動いて欲しいのです。
なので、上記を満たすためのdocker-composeファイルと設定ファイルも作成しておきました。
上記をローカルにコピーして 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つあります。
- 設定変更等を含むサーバー操作系
- リース情報の操作系
- サーバーが受け取ったパケットの統計情報の閲覧系
サーバー操作系の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
引数について
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 DHCPはDHCPプロトコルのメッセージに沿ったログの出力をしています。ぱっと見たときはわかりやすいのですが、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
- リファレンスとログメッセージの充実具合
ここまでで、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 をチェックしていただければと思います。
よろしくお願いいたします。
せっかくseccon2017の予選に出たからメモ書きを残しておく
writeupでは無く後に自分が見直すためのメモ
問題リスト
https://score-quals.seccon.jp/question/
自分が取り組んだやつ
- Qubic Rube
- SqlSRF
- Log search
- automatic_door
回答できたやつ
- Log search
- NoSQL Injection って文字列が最終的に出てきたけど、何がInjectされたのかよくわかってない
*.txtで200のリクエストを返しているヤツを見つければ良いだけだと感じた- なので、問題が公開されてから結構経った時点で問題を解くのは不利なのでは？と思った
- ログが増えた状態になって見つけるのが大変になりそう
- たぶん自分が解けたのは見つけるタイミングが良かったから
- なので、問題が公開されてから結構経った時点で問題を解くのは不利なのでは？と思った
回答できなかったやつ
- Qubic Rube
- 正6面体からQRコードを引っ張ってきてゴニョるやつ
- 3つめのURLぐらいまでやって面倒で諦めた
- 振り返ってみると ImageMagic とかで画像を切り貼りしたら良かったのかなぁ？と思うが、面倒だなって思うのでどっちにしろやらなかったと思う。
- SqlSRF
- automatic_door
感想
webの問題を中心に解いてみた。というかそれ以外の問題は手をつける気にならなかった。
webの問題だけを練習しまくったりしたら、チーム戦とかで貢献できるようになるかもなぁって思った。
ISC DHCP から置き換わるであろう Kea の話し 前編
ISC DHCP から置き換わるであろう Kea の話し 前編
Kea DHCPにまつわる話を 前、中、後編という感じで書きます。
前編です。以下の記事は2017/12/10にwebにある情報を元に記述しています。
今回書く話し
ISC DHCPとKea, その問題点
wikipedia をさっくりと眺めると、Internet Systems Consortiumが開発している DHCP プロトコルのリファレンス実装とのことです。
で、そのISC DHCPに何の不満があるか？と言うと、主に開発面でISCの方々が厳しい思いをしているようで、以下のスライドの6ページ目にその厳しさが詰まっています。
www.slideshare.net
遅いとか、設定が複雑とかは、dhcpを利用する規模によって受け取り方が違うと思うので一概には言えないと個人的には思いますが、中の人たちがそのように言うのだから、そうなのでしょう。
そのような中でBIND10の中にDHCPを混ぜ込んで開発をスタートさせ、BIND10から離れてKeaというのがリリースされたのが2015年だそうです。(上記のスライドの7ページ目にそのように記載指定あります。)
現状のKeaにどのような機能があるのか？は後述しますが、このKeaがリリースされてすでにまる2年が経とうとしています。
そこで問題点として上げられるのが、ISC DHCP は何時までサポートが続くのか？ということです。参考となる一文は ISC の Software Support Policyに以下のように記述してあります。
The exact timeframe for EOL will depend on the maturity of Kea and other available options. We intend to create one more major branch, DHCP 4.4, and that will be the last major branch for ISC DHCP.
要はkeaの開発具合によってISC DHCPは終了したいと書いてあります。
つまり端的な問題点として上げられるのは近いうちに開発やサポートが終了する事が問題だと考えています。
この手のミドルウェアは、脆弱性がたまーに見つかって、パッチが出るのでバージョンアップする必要があると思うのですが、そんなときにISC DHCPは開発が終了していてパッチが当たったバージョンが無く困る状況を回避する必要があるはずです。
一応補足しておくと、似たような問題にpython2.7があると思うので、現実的にはISC DHCPがバンドルされたOSのEOLが訪れるまでは大丈夫ではないか？と思っていますが。
Kea の 情報源について
Keaは大体半年に1度のメジャーリリースをロードマップにしいています。なので、本ブログを2018年に見ても参考にならない可能性があるので、最初に一次の情報源をまとめておきます。
- コード
- https://github.com/isc-projects/kea
masterブランチよりもv1_x_xとバージョニングされたブランチを見るほうが良いと思います。
- wiki
- http://kea.isc.org/wiki
- 管理者向けのリファレンス
- ログメッセージ一覧
- 開発のロードマップ
- Issue
- ISCのブログ
- メーリングリストのアーカイブ等
Keaについて
ISC DHCPとBIND10の苦難から生まれたKeaがどのようなDHCPなのか？という特徴は以下の4点が挙げられます。
- 複数のコンポーネントから構成されている
- JSON形式の設定ファイル
- バックエンドが選択可能
- プラグイン機構により、DHCPとしての動作の拡張が可能
- 設定を変更するためのWebAPIサーバーが付属している
複数のコンポーネントから構成されている
- Dhcp4
- Dhcp6
- DDNS
- Control-Agent
上記で補足が必要なのは、Control-Agentくらいだと思いますが、それは後述するWebAPIのところで詳しく述べます。
JSON形式の設定ファイル
ISC DHCPの頃は、多分独自の設定ファイル記法でした。KeaではJSON記法を利用することが可能です。
各コンポーネント用の記述 + ロギングのための設定と言う形になっています。
バックエンドが選択可能
バックエンドは以下から選択が可能です。
- MySQL
- PostgreSQL
- Cassandra
- ファイル
RDBMSやNoSQLをバックエンドで使うつもりがなかったので特に検証等をしていないためどの様に動作するかは知りません。
プラグイン機構により、DHCPとしての動作の拡張が可能
C++もしくはC言語、もしくはそれらから呼び出せる言語ならプラグインが作成可能です。 (作る必要になったときに備えて、自分はgolangを使って上手いことC++を回避できないか検討していました。)
Kea内ではhookと呼ばれており、DHCPとしての挙動の様々なタイミングで処理を呼び出せる様になっています。
Hook用のデベロッパーズガイドがあるので詳しいことはそちらに任せます。
乱数を用いてIPを払い出すようなプラグインは、C++を勉強してビルドできるようになるまでを含めて大体半日もあれば出来るくらいなので、プラグインは偉大だなと思えます。
設定を変更するためのWebAPIサーバーが付属している
たぶんKeaの目玉の機能となると思います。 Kea v1.2.0からの機能で、Mozillaからのサポートを受けて開発された機能となります。 前述したControl-Agentがwebのapiの受け口を持っており、JSONを送信することで様々な操作が可能です。次の記事で動かし方等をフォローアップしていきます。
前編まとめ
ということで、前編はKeaの特徴を日本語で振り返る記事になりました。
中編ではKeaを実際に動かしてみます。
Dockerとiptablesの共存
タイトル通り
Docker自体がiptablesをゴリゴリと書き換えてくるので、どの様にiptablesを設定するか？という話。
で、iptablesを使いたいのはセキュリティのためだったりすると思うが、本記事を参考にしたからと言っても、何も責任は取れないことだけ明記しておく。
ネットでよく見る話し
ネット上ではDocker チェインを書き換えろ！
iptables -L -v の結果
- DOCKER チェイン
- DOCKER-ISOLATION チェイン
- DOCKER-USER チェイン
上記の3つがある
冷静に考えて
自動的に書き換わるDOCKERチェインよりも、使ってくださいと言わんばかりの名前をしている DOCKER-USER チェインを書き換えてみたい。
ソースを追う
DOCKER-USER so the user is able to filter packet first.
と書いてある。
多少使ってみた結果。
たとえば、systemctl restart docker とか docker-compose up とか docker-compose down では、自分が追記したルールは削除されないことを確認している
dockerのロギングドライバでfluentdに設定を投げつける時にstdoutとstderrを分ける
タイトル通り。
3回設定して、3回悩んだから書いておく。
TODO
fluent-gem install fluent-plugin-rewrite-tag-filter
上記の意図
- dockerからロギングドライバで送られてくるログをfluentdで受けられる
- tagにdockerが付いているログのsourceを見て、stdoutに出力されたものか、stderrに出力されたものなのか？で分類する
- stdoutならstdoutをtagのprefixとして追加
- stderrならstderrをtagのprefixとして追加
- stdoutがtagに着いてたら...
- stderrがtagについていたら...
stdoutとstderrを分けてたい思うんだけど、fluentd初心者な自分だと実現方法を探り当てるまでに時間が掛かった。
実現するための技術は以下のページだけだから凄くしょうもない話しだけど、逆引き的な意味合いで。
『千葉県南房総金谷のワークプレイス「まるも」』というところで開発合宿的なことをしてきた話(の開発以外の話し)
極々プライベートな話しなので、特に技術的な知見は無いです。
2017年10月28日~29日にかけて、千葉県南房総の金谷にあるワークプレイス「まるも」というところで開発合宿的なことをしてきました。
結論から書くと、結構良かったのでブログに書き残しておこうと思いました。
前提
万が一、google等の検索から流入してくる場合は前提がよくわからない可能性があるので、前提というか背景的なことを少し書きます。
自分自身は、Twitter上で やま(´･_･`)ぐち (@yaaamaaaguuu) | Twitter と言うアカウントで生きていて、いわゆるwebっぽいIT系の会社でお仕事をしてます。
そんな会社の同期や後輩、先輩方等々、縁のある方々と勉強会っぽいことをしていて、半年に1度くらいの頻度で集中してプログラムを書く合宿的なことをしています。
今回の「まるも」は、そんな方々とプログラムを書いたりする為に利用させていただきました。
諸々のデータ
| 見出し | 値 |
|---|---|
| 出発地 | 新宿 |
| 参加人数 | 11人 |
| 実施したこと | プログラミングとか |
| 利用開始 | 2017/10/28 (土) 10:00~ くらい |
| 利用終了 | 2017/10/29 (日) ~16:00 くらい |
| 天候 | 雨 (というか台風) |
まるもの立地
最寄りの駅は浜金谷という駅です。新宿駅から特急で2時間くらい、鈍行で3時間くらいっぽいです。
たしか朝の7:50くらいの特急電車にのって、最寄駅についたのが、9:40チョット前だったと記憶してます。
最寄駅からは歩いて5分くらいと近かったのが好印象。
まるもの内観とか
事前にブログを書くことは知っていたので、パノラマ画像をせっかく取ったのに、はてなブログにはアップロードできないことを今知りました (´･_･`)
なので普通の画像を掲載しますが、こんな感じです。
4つの円卓といくつかのテーブルあったので、11人での作業スペースを利用すると、テーブルが1台、荷物置きとして使えるくらいの余裕がある感じでした。
また写真にもちらっと写っていますが、ホワイトボードと黒板がいい感じに作業の補助をしてくれました。
細かい話
IT系の開発合宿をするにあたって、最低限必要になるのが、wifiと電源タップですが、電源タップは持参していく必要が無いくらい充実していて、wifiも全く問題が無かったです。
当日は台風で、特に土曜の夜から日曜の朝にかけての雨量, 風量が凄く、「まるも」内も雨漏りをしていたのですが、特に作業に影響が出るほどではなく快適に作業できてました。
プロジェクターや、ディスプレイも2枚ほどあったのですが、今回は特に利用せず。
またきちんとリサーチしていけばよかったなぁということが、実は「まるも」にキッチンがついている！ということです。有料で利用できるとのことで、調べていたらみんなで料理して晩御飯が食べれたのになぁという気持ちでした。
周辺の話
周辺に野良猫が住み着いている模様。とても人懐こい。(とまるもの方もおっしゃっていた。)
と、いう話はさておき、「まるも」の周辺にはいくつもごはん屋さんがあり、昼食には困りませんでした。ただ、閉店は結構早いらしく、22:00前後にご飯を食べようとした自分たちは若干困った挙句ガストに行きました。
11人で合宿をしていたとは書きましたが、実質は2~3人のチームに分けての作業をしていたため、お昼も別々。ということで自分たちが食べに行ったごはん屋さんだけ紹介します。どっちも一番最初のリンクに張ってあるごはん屋さんなんですけどね😇
https://tabelog.com/chiba/A1206/A120603/12026715/tabelog.com
初日の昼はピザのゴンゾーというお店。お店に釜があって、焼き立てでピザを出してくださる店でした。5~6ページに渡るピザのメニューでどれも美味しそうでした。
2日目の昼はさすけ食堂というところで、さすけ定食をいただきました。アジフライ+鯵の刺し身の定食でボリューミー。写真は撮り忘れ。
宿について
今回は 自転車のイベント が同時期に開催されていたため、LPには掲載されていない金谷ステーションという所を案内していただきました。
金谷ステーション公式WEBサイト | This is a 最高すぎる時間
素泊まりなので非常に安く利用でき、開発合宿の夜間に寝るだけなら必要十分という感じの宿でした。
風呂は男性の方しか事情がわからないのですが、1度に3人くらいずつ入れます。
まとめ
様々なことをざっくりとしか書いていませんが、集中して開発するための空間 + 新宿から離れた場所でご飯を食べると言う意味では非常に良いところだったと思っています。
開発合宿の参考になれば。
flaskのデフォルトのログを出力されないようにする
やりたいことはタイトルどおり。
注意
本記事ではデフォルトで出力されるログを握りつぶすことを主眼においている。
アプリケーションレイヤーできちんとログを出力すること。
動機
flaskのアプリケーションのロギングを自分で細かく設定したい手前、デフォルトで出力されるアクセスログをどの様に消したら良いかがイマイチ分かりづらかったから。
調査した結果としてわかったこと
flaskのデフォのログと書いているがタイトル詐欺で、flaskにデフォで設定されているログの設定はwerkzeug 側で設定されているもの。
つまり本記事を正確に言い表すならば、「werkzeugのデフォルトのログを出力させ無いようにする。」となる。
またwerkzeugが出力するデフォルトの形式を手軽に、程よく改造するのは面倒くさそうだった。
デフォだとApacheのログ形式で、アクセスログが設定されているのだけども、アプリケーション側のログをLTSVとかにし始めると、デフォルトで出力されるログも同じように...というのがお行儀が良いのだろうが、リクエスト自体はリバースプロキシサーバー側でもロギング出来るので一旦握りつぶす方針にした。
デフォルトのログ
深いことは考えずに、アプリケーションを書いて
from flask import Flask app = Flask(__name__) @app.route("/", methods=["GET"]) def root(): return "hello world" if __name__ == "__main__": app.run(debug=True, host="0.0.0.0", port=5000)
サクッと動かして
python app.py
別ターミナルで
curl loclahost:5000
とかすると出力される
172.17.0.1 - - [03/Nov/2017 14:55:23] "GET / HTTP/1.1" 200 -
このアクセスログを握りつぶしたい。
ドキュメントを読む
Logging — Flask Documentation (0.13-dev)
なるほど。
pythonのloggingの設定のrootに何も設定していないと、StreamHandlerが設定されるとのこと。
じゃあStreamHandlerをみると?
16.8. logging.handlers — ロギングハンドラ — Python 3.6.3 ドキュメント
なるほど。stdoutに設定されているとのことらしい。
順番はめちゃくちゃだけど、werkzeugのコードを探すと
以下がloggerを設定している箇所
以下でログを出力するためのヘルパーメソッドとなる。
なるほど。
WSGIRequestHandler 内にある, log_request などが、 logメソッドを呼び、それは最終的に werkzeug/_internal.py にある、_log メソッドを経由してgetattrでloggingの持つメソッドを文字列で指定しながら呼び出している形となる模様。
つまり
きちんと取り組むなら、以下のファイル内にある WSGIRquesutHandler の logメソッドなどなどを継承したオブジェクトを作って... とかが考えられる。
が、前述したとおり一旦握りつぶせるだけで良いので、 /dev/null を向き先にしたFileHandlerで全てのログを握りつぶす。
import logging from flask import Flask l = logging.getLogger() l.addHandler(logging.FileHandler("/dev/null")) app = Flask(__name__) @app.route("/", methods=["GET"]) def root(): return "hello world" if __name__ == "__main__": app.run(debug=True, host="0.0.0.0", port=5000)
上記を起動すると分かるが、flaskが出力する全てのデフォルトのログを握りつぶした状態となったはず。
