Fluentd/bitの立ち位置

まとめ

• 分散
• ストリーム
• 処理
• 配送

のめんどくさいところを担ってくれるライブラリ

ストリーム処理

ストリーム処理の概念はとてもシンプル。
流れ込むデータを分岐させ変形し出力する。

処理リソースの関係でback pressure とかバッファがでてくる.
さらに分散システム全体でのストリーム処理がでてくる.
ネットワークまたぎ、冗長性、負荷分散etcetc...

Fluentd/bitは、後者の実務的に重要で複雑な、だけど処理そのものとは違う部分を担当してくれる。
差別化要素ではないけど重要かつheavy load、的な部分。

だから深く考えないで使うこともできて、それでいて安定感があると評判.
踏み込むと分散ストリームそのものの難しさが出てくるので、理解するのにも一手間かかる。抽象化してくれていてありがとう。

#

• output

  • aggregation (event => chunk)
  • buffer (queue of chunks)
  • retry

• I/O

  • networking
    • load balancing

2020年におけるIPに依存したセキュリティ

問題点

仮想環境前提 => IPがコロコロ変わる.
クラウド全般、コンテナ全盛期、並列サーバーのDNSによる集約 (リバースプロキシならプロキシIPは比較的安定)

解決方法

古典的なネットワーク制御ではなくAuthZ
role-baseとかパスワードは本質的にbearer token
Security Groupみたいなタグ付けも結局はタグbearer tokenみたいなもん（bearer tokenじゃなくてグループへのIP登録でも実装できるけど）

“事後に「ああすべきだった」と揶揄する”表現リスト

• あとから孔明の先見の明
• 後知恵
• インターネット後出し軍師様
• 床屋総理
• 居酒屋監督
• monday morning quarterbacking

振り返らないと成長がないのも事実。
現実と理想の比較は大概比較にならないのも事実.

後知恵バイアス - Wikipedia

コンテナと安全なクレデンシャル（パスワード）

シチュエーションごとに違う

ビルドそのものにクレデンシャルが必要な場合

ビルド時に、パスワードが必要な外部サービスから何かを取ってくる場合.
取ってきた何かは公開していいんだけど、取ってくるためのパスワードは残るとまずい、という場合.

docker build --secretが使える.
docs.docker.com

設定したcredentialsファイルを読んで利用してくれるけどlayerにはファイルが残らないという優れもの.
これでCOPY credentials.txt | RUN use_something | RUN rm -f crednetials.txtしたのにlayerに残っているという危険から逃れられる.

RUNしている間にクレデンシャルが必要な場合

クレデンシャルをログへダンプしたら一巻の終わりだが、何かを実行する以上それを100%避けるのはとても難しい.
最悪ダンプしてもいいように平文でクレデンシャルを持たないのがfail safeにするうえで重要.

ファイルマウントが安全な扱い方の1つ.
マウントはimageに入らないため、取り出したクレデンシャルをどこかに書き込まない限り安全。
クレデンシャルを読んだコンテナをcommitした場合でも新imageには残っておらず、ゆえにpushしても問題ない。imageに残らないので docker history も心配ない.

素朴な方法は環境変数に入れること.

AWS ECSは暗号化して管理されてる変数を環境変数に挿入できる

Refs

• amazon web services - Which is the best way to pass AWS credentials to Docker container? - Stack Overflow

Node.jsプロセスの終了とそのハンドル

'exit'

process.exit()による明示的なプロセス終了、あるいはイベントループの処理終了によって発生するイベント.
'exit'発生後はイベントループを止められないので非同期処理は不可能.

• 'rejectionHandled'
• 'uncaughtException'
• 'uncaughtExceptionMonitor'
• 'unhandledRejection'

トップレベル例外

catchされない例外がトップレベルにくると、デフォルトでは stderrへstack traceをプリント + exit(1) になる.

By default, Node.js handles such exceptions by printing the stack trace to stderr and exiting with code 1, overriding any previously set process.exitCode. ref

'uncaughtException'を掴んだ場合はハンドラで上記のデフォルト動作が上書きされる.

Adding a handler for the 'uncaughtException' event overrides this default behavior. ref

'uncaughtExceptionMonitor'はexit動作は必ず行われるけどその前にhookできる.

Installing an 'uncaughtExceptionMonitor' listener does not change the behavior once an 'uncaughtException' event is emitted. ref

'unhandledRejection'はexitしないけどstderrにログを吐いてくれる。ハンドラでhookできる

process.exit()は未処理のasyncも全部吹っ飛ばしてexitするので、'uncaughtExceptionMonitor'内で非同期処理を仕込んでもhook後のexit()がすぐに動いて仕込んだasyncが処理されない (動作チェック済み）

exit()の動作:

Calling process.exit() will force the process to exit as quickly as possible even if there are still asynchronous operations pending that have not yet completed fully, including I/O operations to process.stdout and process.stderr. ref

異常終了の比較的ましな終わらせ方

想定外のエラー（トップレベル例外）が出た場合、プロセスは無言で死ぬ.
プロセス外からプロセス監視をかけるのが1番のやり方.
もっと楽にする場合、'uncaughtException'に独自ハンドラを仕込み、ハンドラ内で非同期込みのエラーレポートをした後に手動.exit()
こうすればエラーが残る.

docker-compose

Use Compose in production  

This first rebuilds the image for web and then stop, destroy, and recreate just the web service. The --no-deps flag prevents Compose from also recreating any services which web depends on.

Overview of Docker Compose
  
Only recreate containers that have changed🔗
Compose caches the configuration used to create a container. When you restart a service that has not changed, Compose re-uses the existing containers. Re-using containers means that you can make changes to your environment very quickly.

k8sだとPodまるまるの破棄による更新な感じ.
appはmulti-Podで作るのかな？

Graceful shutdown

Node.js

nodeはプロセスとして振る舞う。なのでPOSIX standard signalsに応答する.
nodeのprocessはEventEmitterを継承するglobalオブジェクトなので、ここからsignalハンドラを設定する.

// Ctl+Cをハンドラが捕まえるせいで強制終了不可（Winで検証済み）
process.on("SIGINT", () => {
  console.log("SIGINT come!");
  // process.exit(0);
});

node.js signal events