AWS fargate での signal について

AWS fargate での signal について:

せっかちな人向けの結論

停止命令があった時 SIGTERM が送られ、それから30秒起動し続けたら SIGKILL が送られる。

AWS fargate とは

AWS fargate (以下、fargate) は、AWS のマネージドな docker 実行環境です。

最近、東京リージョンでも使うことができるようになりました。

docker における signal

docker は、そのコンテナ内で自由にプロセスが立ち上がります。

外部からストップを送る場合、基本的には docker コンテナ内の PID 1 のプロセスに SIGTERM が送られます。

その後、起動が続いた場合、 SIGKILL が送られます。

fargate における signal

fargate においてはどうなのかを調べたところ、公式にかのように書いていました。

記事書くためにもう一度探したら、日本語で書いてあった。
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/update-service.html

更新中にサービススケジューラがタスクを置き換えるとき、ロードバランサーがサービスによって使用されている場合、サービスはまずロードバランサーからタスクを削除し、接続のドレインが完了するのを待ちます。その後、タスクで実行されているコンテナに docker stop と同等のコマンドが発行されます。この結果、SIGTERM 信号と 30 秒のタイムアウトが発生し、その後に SIGKILL が送信され、コンテナが強制的に停止されます。コンテナが SIGTERM 信号を正常に処理し、その受信時から 30 秒以内に終了する場合、SIGKILL 信号は送信されません。サービススケジューラは、最小ヘルス率と最大ヘルス率の設定で定義されているとおりに、タスクを開始および停止します。

つまり、「停止命令があった時 SIGTERM が送られ、それから30秒起動し続けたら SIGKILL が送られる。」になります。

最後に

そもそもこれをなぜ調べたかというと、 fargate で 途中で止まる可能性のあるタスクを行う必要があったためです。

調べた結果、猶予時間30秒ではどうしよもないので、他の方法を考えることにします。