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が出力する全てのデフォルトのログを握りつぶした状態となったはず。
webサーバー開発週報 第3週目
進捗
- httpサーバーとしての新機能は無し
- httpサーバーとしての機能修正も無し
- 細々とした修正をした
- virtual host を設定できるようにすることを見越して
今週の詰まりどころ
- 進捗が少ないのでなし
- グローバル変数的なものの扱いをどうするのか、未だによくわかってない
- ググったらそれっぽいのは出てくるけど、試せてない
感想
- 今週は新しい進展が無かった
- 仕事の負荷が若干上がってきた
- 仕事で使いたいコードを書いていた
- 来週はもう少し時間を取りたい
webサーバー開発週報 第2週目
前回
まぁ1週間は続くよね。
進捗
- 相変わらずstaticなwebサーバー
- 追加系
- 変更系
- やりたかったけどできなかった
- 設定ファイルをhclにできなかった
- ドキュメントルートも指定できるようにしたかったが未着手
今週の詰まりどころ
- 型が面倒
- StringとかByteStringとか, IntとかInt64とか
- gzipで圧縮することより、内部的な型の方が厄介だった
- どこかの場面でとても大切なのかもしれないけれど、今のところそこら辺はよしなにやってほしい気持ちの方が大きい
- StringとかByteStringとか, IntとかInt64とか
- 設定ファイルをhclにしたかった
感想
http1.0対応の根幹は結構できてきたと思う。がhaskellっぽいコードか？と問われるとかなり微妙。
そもそも、すごいHaskellとかを挫折してこういう取り組みを行っているので、haskellっぽいコードにならないのは仕方が無いと割り切るしか無い。
HSpecはかなり好きだが、webサーバーとしてテストが網羅できてるかはコレまた怪しい。
そろそろhttp1.0のstaticなwebサーバーは脱却して、少しずつcgiとかに対応できたら良いなぁと思う。
webサーバー開発週報
webサーバー開発週報 第1週目
続くかどうかはよくわからないけど、どうせやるなら週報とかつけてみるとモチベーションが上がるのではないかなぁ？と思って書いてみる。
- haskellでwebサーバーの実装を始めた
- 自分が実装したいものを気ままに実装していく方針
リポジトリは以下
進捗
- 現状レスポンスは固定
- 正常のときは200
- 正しくファイルが開けないとき or ファイルが無い時は404を出す
- ヘッダーは以下を付与
- Server
- Accept-Ranges
- Content-Type
- Content-Length
- Date
- 以下のファイルをレスポンス出来るようになった
今週の詰まりどころ
- imageが上手くレスポンスできずに詰まった
- pngとかjpgとかgifとか
- しばらくは
Network.Socketを利用していたが、Network.Socket.ByteStringがあることに気がついた Network.Socketだとテキストはさくっと返せるが、バイナリなデータはいい感じに返せない？- 上記のライブラリのどちらでも、
send関数を一度読んだだけでは送りたいデータを送りきれない事にも気づくのに時間が掛かった。
GitLab CI Runner をProxy環境下で動かす
前提
とあるネットワークのセグメント配下に設置されたVM -> GitLabへの通信はProxyを通す必要があり、かつそのVMがGitLab CI Runnerの役割を果たしている時の話し
準備
上記のページに沿ってci runnerをインストールしたらOK
ハマりどころ
インストール後はci runnerをgitlabに登録することになる。ただしProxyの設定をしておかないと登録はできるがGitLabからCIをキックできずにハマる。
なのでその次のステップの登録はちょっとまって欲しい。
Proxyの設定
上記のissueのコメントの Adding Proxy variables to the runner config, so it get's builds assigned from the gitlab behind the proxy に書いてあるとおり、 /etc/systemd/system/gitlab-runner.service.d/http-proxy.conf などを作って、systemd側からproxyの設定をgitlab ci runnerに渡してあげる必要がある
Proxyの設定を登録したら
上記の通り、gitlab ci runnerを登録したら良い
与太話
自分がgitlab ci runnerをproxy配下で動かそうと試行錯誤している途中で、gitlabのデータがおかしくなって、gitlab ci runnerがweb uiから登録解除というか削除できなくなってしまった。
そのような場面に陥ったら以下のissueを参考にすると良い。CLI側からもci runnerを登録解除できる。登録解除に必要なTokenなどは /etc/gitlab-ci-multi-runner/config.toml を参照したら見つけられるはず。
