こんにちは、タリーです☕️

案件でAWSを触るなかで勉強したサービスを1つずつまとめるシリーズ、前回のECS Fargateに続いて、今回はECRです。
前回の「見えないサーバー」の話がそのまま繋がってくるので、まだの方は先にそちらを読むと分かりやすいと思います。

まず、ECRが何をするサービスかを一言で書いておきます。

ECR … build済みのコンテナイメージを置いておく、AWSの保管庫。

これだけです。作るわけでも動かすわけでもなく、「イメージを置いておくだけ」。ここが今回の一番大事なところでした。

この記事のゴールは、前回と同じく概念を理解することです。手を動かす話（push/pullの実際のコマンド等）は次回以降にして、今回は概念だけに振り切ります。

構成は前回と同じく2つに分けています。

1. 私の前提

勉強を始める前の私の認識を、あとで読み返す用に残しておきます。「こう思っていた」と「実際はこうだった」を並べるとこんな感じでした。

イメージの認識がズレていたのが一番の原因でした。ここを直すのが第一歩だったので、順番に整理していきます。

2. このサービスの概要

私はイメージを「コンテナ内で実行されるもの」だと思っていましたが、正確には**実行される前の、動かないテンプレート（型）**です。

前回やった「タスク定義（型）とタスク（実体）」と同じ関係が、ここにもあります。

	動かない「型」	動いている「実体」
ECSの世界	タスク定義	タスク
Dockerの世界	イメージ	コンテナ

イメージはアプリやライブラリを1つに固めたパッケージで、それ自体は動きません。そのイメージを起動して動かした実体がコンテナ、という関係です。1つのイメージから、コンテナは何個でも起動できます。

自分のPCでDockerをいじっているときはECRなんて意識しませんでした。理由はシンプルで、docker build するとイメージはbuildしたマシンのディスクに保存されるからです。自分のPCで作れば自分のPCにあるので、そのまま動かせる。保管庫は要りませんでした。

問題はクラウドで動かすときです。前回やったとおり、Fargateでコンテナが乗る地面は「自分のPC」ではなく「見えないサーバー」でした。ここでこうなります。

「地面（サーバー）はあるけど、その上で起動する元になるイメージが届いていない」状態です。だから、両方からアクセスできる共通の置き場所にイメージを一旦置いておく必要があります。それがECRです。

やることは、マシンAからECRにイメージをpush（送る）、マシンBがECRからpull（持ってくる）、これだけです。

前提のところで「push/pullは送る/持ってくる」という認識は合っていたので、ここはそのまま繋がりました。

「誰がbuildしてpushするのか」には、いくつかパターンがあります。案件で使うのはCIですが、それはあくまでその1つ、という位置づけです。

パターン	誰がbuild & pushするか	いつ使うか
手動	自分のPC	個人開発、動作確認、学習中
CI（自動）	クラウド上のビルド用マシン	チーム開発・本番運用

本番運用でいちいち自分のPCからpushするのは現実的ではないので、CIで自動化するのが一般的です。案件でもこちらでした。流れは次のとおりです。

① コードをGitHubにpush
② CIが起動して docker build
③ CIができたイメージをECRにpush
④ FargateがECRからpullして起動

コードを上げれば、あとは自動でイメージが作られてECRに入る、という形ですね。

ECRの中は、リポジトリという単位で仕切られています。アプリごとに1つ用意する「棚」だと思うと分かりやすいです。棚の中には、同じアプリの色々な版が入り、それぞれにタグという版のラベルが付きます。

pullするときは、この「どのリポジトリの、どのタグか」を指定して取り出します。

ここが私が一番つまづいたところです。整理する途中で「イメージをbuildするサービスがECR」だと勘違いしていました。実際は違って、ECRはbuildも起動もしません。置くだけです。

役割を分けるとこうなります。

作る・置く・動かすは、それぞれ別の担当です。ECRは真ん中の「置く」だけを担当していて、buildにも起動にも関わっていません。ここを分けて考えられると、頭の中が整理できました。