ECSコンテナ起動中にECRイメージを削除した時の挙動
概要
実は以前ECSのコンテナ起動中に、イメージをECRから削除してしまうということをやってしまいました。
この場合にコンテナがどのような挙動になるのか調査したので記事にします。
同じことをやってしまった方にどうか参考になると嬉しいです。
実際の挙動
実際はECRイメージの削除後、コンテナが正常に動き続けていました。
しかしなぜ正常に動き続けるのか、ECSがイメージをどう扱っているのか、こけるとしたらいつなのか、全く不明でそこら辺を調べる必要がありました。
調査
- コンテナ起動時、ECRからイメージをどのように取得してくるのか
- 起動中はどのようにイメージを保持するのか
という観点で調査をします。
内部的なロジックになりますのでまずは公式を見るに限ります
いい感じの記事がありました↓
FargateタイプとEC2タイプのタスクに分かれて記載がありますね。
タスクとかコンテナとかごちゃ混ぜになってきたという方はとりあえず、
- タスクとは設定した定義によってコンテナを立ち上げてくれるもの
- コンテナとはアプリを実行する環境を持つもの
と覚えておけばOKです
(Fargate、EC2それぞれがどう違うのかはまた調査して別記事にします)
Fargateタイプのタスク
Fargate はイメージをキャッシュしないため、タスクの実行時にイメージ全体がレジストリから取得されます。
Fargateの場合は、タスク実行時にECRイメージを取得するみたいですね。
コンテナ起動中は取得してきたイメージを使うので、ECRを常に参照している訳ではないんですね。
EC2タイプのタスク
Amazon ECS エージェントはタスクを開始すると、リモート レジストリから Docker イメージをプルし、ローカル コピーをキャッシュします。
Amazon ECS エージェントは既存のダウンロードされたイメージを使用する
コンテナ起動時にECRイメージを取得し、コピーを作成してコンテナ内にキャッシュするようです。
次回以降はそのキャッシュを使用して起動するんですね。
結論
コンテナ起動中にECRイメージを削除した場合でも正常に動き続ける理由は、
Fargate、EC2どちらであっても、コンテナ起動時にECRイメージを取得しており、起動中はECRを参照しないから
です。
逆に言えば、コンテナが再起動するタイミングでイメージを参照するのでエラーになるということですね。
運用面でのベストプラクティスを考える
現在コンテナで利用しているイメージはローカルにプルしておくことが良いかなと思います。
バックアップがあるのは安心ですよね！
プルしてきたイメージは起動中のイメージURIと同一になるので、それをもう一度ECRへプッシュしておけば、誤って削除してしまった場合に再起動がいつ入っても問題ないということになります。
ローカルにプルする方法はまた別記事にします。
まだまだ情報探しの道中です。
Discussion