こんにちは。 技術課の山本です。
以下記事では、ECR のパブリックリポジトリにある AWS 公式の Fluent Bit のコンテナイメージを、ECSタスクで直接利用する方法があると分かりました。
利用者側では、Fluent Bit の設定ファイルを、S3 バケット上に配置するのみで良い方法です。
本記事では、上の記事でデプロイした Fluent Bit コンテナを再デプロイせずに、設定ファイルの書き換えを行う方法がないか、確認しました。
結果
設定ファイルの書き換えを行うには、再デプロイ（新しいタスクの起動）が必要です。
FireLens を使えば、ファイルを編集して S3 に再アップロードするだけで、タスクの起動時に自動的に新しい設定を取り込むことができます。
引用元：詳解 FireLens – Amazon ECS タスクで高度なログルーティングを実現する機能を深く知る
また、以下の プルリクエスト にある通り、２０２３年２月１５日時点において、 fluent-bit にホットリロード機能はないようです。
Currently, fluent-bit does not support hot reloading feature. For now, I implemented SIGHUP handler to handle hot reloading. Some of plugins do not handle pause/resume operations correctly. So, I fixed their behavior by implementing pause/resume callbacks.
実際にできないことを確認してみた
ECS Exec で fluent-bit のコンテナにログインし、設定ファイルを書き換えて、SIGHUP や SIGUSR2 といったシグナルを送ってみました。
SIGUSR2 を試したのは、fluent-bit の生みの親である fluentd では、 SIGUSR2 が設定ファイルを再読み込みするシグナルであるためです。
SIGUSR2 Reloads the configuration file by gracefully re-constructing the data pipeline. Fluentd will try to flush the entire memory buffer at once, but will not retry if the flush fails. Fluentd will not flush the file buffer; the logs are persisted on the disk by default. This signal has been supported since v1.9.0.
以下の記事を参考に、ECS Exec を利用できるようにし、検証します。
設定ファイルを書き換えてシグナルを送った結果を確認するため、タスクでは ３分に１回ログを出力し、３０分後に終了するようにしました。（実装方法については割愛します。）
ECS Exec を利用する準備
以下の IAM ポリシーを ECS タスクロールに追加します。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ssmmessages:CreateControlChannel", "ssmmessages:CreateDataChannel", "ssmmessages:OpenControlChannel", "ssmmessages:OpenDataChannel" ], "Resource": "*" } ] }
ECS Exec が有効なタスクの実行
「--enable-execute-command」オプションを付与して、aws ecs run-task コマンドを実行します。
# 変数設定 cluster_name="クラスター名" task_arn="タスク定義のARN" subnet="サブネットID" securitygroup_id="セキュリティグループID" vpc_config="awsvpcConfiguration={subnets=[$subnet],securityGroups=[$securitygroup_id],assignPublicIp=ENABLED}" # タスクの実行 aws ecs run-task --cluster $cluster_name --task-definition $task_arn --network-configuration $vpc_config --launch-type FARGATE --enable-execute-command
標準出力する "taskArn" をメモします。
ECS Exec で fluent-bit のコンテナに接続
起動したタスク内の fluent-bit のコンテナに接続します。
# 変数設定 task_id="タスクの実行時に標準出力した「taskArn」" container_name="fluent-bitコンテナのコンテナ名（コンテナ定義での名前）" # 接続 aws ecs execute-command --cluster $cluster_name --task $task_id --container $container_name --interactive --command "/bin/bash"
fluent-bit のホットリロードに失敗することを確認
まずは fluent-bit のpid を確認します。
# fluent bit の pid を確認 ps -ef
pid は 1 です。
( 1 であることが気になる人のための補足：initProcessEnabled を設定していなく、親プロセスがいないため、1 になっています。)
また、「/init/fluent-bit-init.conf 」を設定ファイルとして読み込んでいます。
（画像が小さくてすみません。ターミナル表示の都合で、これ以上大きくできませんでした。）
「/init/fluent-bit-init.conf 」 の中身です。 INCLUDEを使って、 S3 からダウンロードした設定ファイルをみているようです。
検証のため、S3 に置いた、extra.conf は空ファイルにしています。
コンテナ上で、「/init/fluent-bit-init-s3-files/extra2.conf」を新規に作成します。
[FILTER] name multiline match * multiline.key_content log multiline.parser java #[FILTER] # name rewrite_tag # Match * # Rule $log ^.*$ tag1 false [FILTER] name record_modifier Match * Remove_key container_id Remove_key container_name Remove_key ecs_cluster Remove_key ecs_task_arn Remove_key source
「/init/fluent-bit-init.conf 」 を書き換えます。extra.conf を extra2.conf に書き換えます。
（作成した extra2.conf を読み込むかを、確認します。）
@INCLUDE /fluent-bit/etc/fluent-bit.conf
@INCLUDE /init/fluent-bit-init-s3-files/extra2.conf # extra.conf を extra2.conf に書き換え
変更を反映できるか確認するため、 SIGUSR2 シグナルを送ります。
# fluent-bit の pid に SIGUSER2 を送信 kill -s SIGUSR2 1 # 戻り値が 0 であることを確認 echo $?
extra2.conf に変更できた場合、java のマルチラインパーサーが機能するはずです。
しかし、機能していませんでした。
（複数行のログがある場合に、１行が１レコードになっていました。＝元のままです。）
同様に、SIGUSR2 を SIGHUP に変えても同じ結果でした。
まとめ
２０２３年３月現在、fluent-bit にホットリロード機能はないようです。
fluent-bit の設定ファイルの書き換えを行うには、再デプロイ（新しいタスクの起動）が必要です。
余談
３月１８日（土曜日）あたりにまとまった雪が降り、その後は暖かい気温が続いたため、標高の高い山では雪崩が多く起きたようです。
（幸い、大きな事故はなかったようです。）
雪崩のリスクを避けて、週末は弊社の登山部員と標高の低い里山（御座山）に行って、楽しみました。
