DockerイメージをAWSで起動 - AWSのECRの使い方(2)

2024年9月30日 10:04

前回ECRにpushしたdockerイメージであるがこれを起動するにあたってはいろいろな手法が考えられる。一番簡単なのはEC2からdocker pullして起動する方法だろう。いきなりECSってのも敷居が高いので、まずはEC2で起動してみよう。

EC2にdocker.ioをinstallしてpullして起動

とりあえずdebianを選択した。ubuntuとか他でもいいよ。dockerがみつけられるなら

ささっと起動しdocker.ioをinstallした

sudo apt update; sudo apt install docker.io

で、awsコマンドはこの手のインスタンスは最初から入ってるので気にしなくてok

admin@ip-172-31-45-84:~$ aws --version
aws-cli/2.9.19 Python/3.11.2 Linux/6.1.0-23-cloud-arm64 source/aarch64.debian.12 prompt/off

aws configureでECRのために作ったユーザーのキー情報をセットしてもいいんだけど、IAMロールを割り当てれはこのインスタンスに許可できるので、そっちの方がキーが漏れるとかないので通常AWS内リソースの場合はそういう風にするのがベストだろう。

このようにして次の画面で

AmazonEC2ContainerRegistryReadOnly を割り当てる

として適当な名前にした。ここではecr-test-roleとする。すると

このように選択できるようになるので、これを選択する。

沢山roleがあるのになぜセレクトボックスにこれしか出てこないんだって疑問があった場合はroleの「信頼されたエンティティー」ってところを見てみましょ

これでdocker loginできるようになる。

$ aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin ****.dkr.ecr.ap-northeast-1.amazonaws.com

ただし、以下のようになるかもしれない

permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/auth": dial unix /var/run/docker.sock: connect: permission denied

この時はdockerを実行しようとしているユーザーをdockerグループに投入するといい、debian系の場合は。

admin@ip-172-31-45-84:~$ sudo adduser admin docker
Adding user `admin' to group `docker' ...
Done.

とかして
いずれにせよ

WARNING! Your password will be stored unencrypted in /home/admin/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Login Succeeded

とかになったらdocker pullしよう

docker pull <ECRのURI>

で行う。

正しく権限がついていればdocker pullできるはずだ。ってことは、ECSにこの環境を移動してもこのpullする権限が必要になる事が予想できますね。

あとは起動するだけだ

$ docker run --rm ****.dkr.ecr.ap-northeast-1.amazonaws.com/demo-docker-app
Hello from entrypoint.sh!

以上がEC2を用いてdocker imageをECRからpullして起動する例だ。

ECS Fargateを使う

さて、ここまで見てきたので理解できるようにdockerイメージを動かすためにはdockerを起動しないといけない。これは通常EC2のようなOS環境でdocker.ioをインストールして行うのだがECS Fargateはdockerより下のレイヤーを管理してくれる。ただしその為には各種起動テンプレートが必要ってことになるわけ。ここがEC2より敷居を高くしている所であーる。

ECSクラスターの作成

ECSクラスターはECSにおけるキャンバスみたいなもんで、この下に「サービス」や「タスク」が連なっていく。とりあえずこれが無いとはじまらないので作成していく。ダッシュボードからクラスターの作成

ここではDevClusterって名前にした。何でもいい。

作成する

タスク定義の作成

これはどういう条件でタスク、この場合Dockerコンテナを起動するかの設定を行う。左ペインの「タスク定義」より行う。

タスク定義は安定するまでちょいちょい変更がかかったりするのでwebよりもjsonで変更する方が定石なのではあるが、とりあえずwebから実行しよう。ここでは「新しいタスク定義の作成」を押す

タスク定義ファミリーに適当な名前を入れる。ここではdemoTaskとした。むしろ重要なのはその下の欄であーる。

起動タイプはECS Fargateとする。これがいわゆるサーバーレスのコンテナ実行環境である。

アーキテクチャはdockerイメージをビルドした環境にする。筆者の環境ではARM64である。しかしここではあえて異なるアーキテクチャーを選択してエラーにしてみよう。

課金にかかわるところとしてはvcpuとmemoryがあるが組合せによってうまくセットできないものの最小単位は .25 vCPUと .5GB

タスクロールや、タスク実行ロールは重要であるが今はスルーしてok

このコンテナの設定が重要で

こんな感じで設定するんだけど、面倒なことにECRからコピってこないといけない、頑張って(アルアルな苦労)。今回はwebアプリではないのでportうんぬんは全く関係ない。

以上をセットしたら下の方の「作成」を押す

実行してみる

クラスターに入って「タスク」を押す

新しいタスクの実行を押す

キャパシティープロバイダー戦略とかいう面くらう画面が出てくるけどここでは「起動タイプ」を選ぶ、するとちょっとすっきりするだろう。起動タイプはFARGATEになっているはずだから下の方に移動していく。

こんな感じでさくさく設定する

要するにdemoTaskの最新を1つ起動しろってことだ。

これで画面下部の作成を押す。すると

というライフサイクルになる。いずれにせよ消滅する。

これだけでは何が起きてるのかわからないので、ここでCloudWatchにてログを見る

ログをみる

CloudWatchのロググループを見る。そうすると /ecs/demoTask ってのがあると思う。その中に入ると

exec /usr/local/bin/entrypoint.sh: exec format error

このようになっている。これは前段でアーキテクチャーをあえて間違えた事に起因している。慣れているとこのエラーから何が間違っているのかすぐわかるようになるが、あえて間違ってみるというのも手かもしれない。

さて、間違ったまま終わるのもアレだが、長くなっているので次回はタスク定義の修正やプログラムの改修などなど行っていく。