常連

### 実現したいこと

AWSのECSを利用する際に、2つ以上のコンテナを１つのEC2上で稼働させたい。

### 前提

機械学習のpythonプログラムをコンテナ化し、EC2のg3で動かそうとしています。
利用料金が高いので、複数作った別々の内容のコンテナを一つのＥＣ２で動かそうとしていました。普通にＥＣ２を1台借りて、dockerをインストールし、そこに複数コンテナを稼働させようとしていたのですが、コンテナのマネジメントサービスであるＥＣＳがあると知りました。ＥＣＳのほうが、運用が楽かなと思い、複数コンテナを一つのＥＣ２サーバ上で動かそうとしたのですが、ＥＣＳ作成画面で既存のＥＣ２サーバを設定する項目が見つからず、進まなくなってしまいました。
ＧＰＵプログラミングであるＣＵＤＡが使えるサーバでしか利用したい機械学習プログラムが動かないため、
fargateで動かすなども考えてみましたが、ＣＵＤＡを利用できるのかもわかりませんでした。
やりたいことが実現できるなら他の方法（fargateを利用する、やＥＫＳを利用するなど）でも構いませんのでご教授いただきたいです。


### 試したこと

・ECSの設定画面の確認
　→インフラストラクチャのEC2の新規作成しかできず、既存のEC２への追加ができない。
・googleでこの質問内容の検索
　→日本語の記事で回答になりえそうなものがなかったです。

### 補足情報（FW/ツールのバージョンなど）

ここにより詳細な情報を記載してください。


AWSのECSを利用する際に、2つ以上のコンテナを１つのEC2上で稼働させたい。

```terminal
~ % aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin ◯◯◯◯◯◯.dkr.ecr.ap-northeast-1.amazonaws.com/rails 
```
上のコマンドを入力した際に、以下のエラー文が表示されます。
```terminal
An error occurred (UnrecognizedClientException) when calling the GetAuthorizationToken operation: The security token included in the request is invalid.
Error: Cannot perform an interactive login from a non TTY device
```

AWS CLIはインストール＋設定済です。

最終的にはDockerコンテナをECSでデプロイしたいのですが途中で躓いています。

宜しくお願い致します。

AWS ECRにログインできない

### 実現したいこと

RailsアプリケーションをAWS ECSにて運用したいのですが、
サービスを実行すると、実行したタスクが数分で停止してしまいます。
サービスがタスク数を維持しようとしてまた新しくタスクが実行されますが、そのタスクも数分で停止します。
この繰り返しになってしまいます。

以前は問題なくサービスを実行できていたのですが、アプリの開発を行い、タスク定義をアップデートしたところ、
上記のような問題が発生しました。

＊5/19追記
以前は問題なくサービスを実行できたと書きましたが、確認してみると、以前のコードでも上手く動きませんでした。
コード以外になんらかの変更を加えてしまい、それが原因となっている可能性が高そうです。

### 構成・前提

```
ロードバランサー：ALB

データベース：RDS

デプロイ：ECS
  => 起動方法: EC2
  => 実行: クラスター1つ、サービス1つ、タスク1つ
  => タスク定義: Nginxコンテナ, Railsコンテナ (Unicorn)

ALB-EC2間の通信: HTTPS

Rails関連:
  => rails db:create, rails db:migrate 済み
  => RAILS_MASTER_KEY 設定済み

```

### 発生している問題・エラーメッセージ

ECSのサービスにて実行したタスクが3分程で停止してしまいます。
具体的には、Nginxコンテナ, Railsコンテナが両方立ち上がるのですが、3分程でコンテナが停止し、どちらも`STATUS`が`Exited (137)`になってしまいます。

また、同じタスクを、サービスを通さずに単発で実行すると、停止しません。
（`ECSコンソール`=>`クラスター`=>`タスク`=>`新しいタスクの実行`）
タスクは停止せず、コンテナは問題なく起動し、コンテナの`STATUS`は`UP`を維持します。

この違いは何なのでしょうか？

単発のタスク実行は成功することから、タスク定義は問題ないと考えます。

どちらのパターンも同じタスク定義を使用し、タスクの実行に使用しているEC2インスタンスも同じです。
どこに差分が生まれているのでしょうか？

### 試したこと

考えられる差分として、ALBのヘルスチェックが何らかの悪さをしているのではと考え、ヘルスチェックのプロトコルを`HTTPS`から`HTTP`に変更しましたが、結果は変わりませんでした。
(Nginxコンテナは、443ポートで動的ポートマッピングしているため、`HTTP`にすることによりNginxコンテナへのヘルスチェックの通信を切る形になります)


### ログ

Dockerの標準出力、NginxとRailsAppのログファイルにも、ログは一切出力されませんでした。

### 該当のソースコード

```servise
起動タイプ: EC2

新しいデプロイの強制: なし
サービスタイプ: REPLICA

タスクの数: 1
最小ヘルス数: 0
最大ヘルス数: 200

ヘルスチェックの猶予期間: 0

ロードバランシング:
  => ロードバランサー名: ALB
  => コンテナ名: Nginx
  => コンテナポート: 443
  => ターゲットグループ: ALB-TargetGroup

Service Auto Scaling: サービスの必要数を直接調整しない
```

```RailsApp
# Dockerfile

FROM ruby:2.5.1

ENV JAVA_HOME /usr/lib/jvm/java-1.8.0-openjdk-amd64

RUN apt-get update \
  && apt-get install -y \
       build-essential \
       nodejs \
       openjdk-8-jdk

ADD . /rails-app-root
WORKDIR /rails-app-root
RUN mkdir tmp tmp/sockets log \
  && bundle install

CMD unicorn_rails -c /rails-app-root/config/unicorn.rb -E production

```

```nginx
# Dockerfile

FROM nginx:1.15.8

RUN rm -f /etc/nginx/conf.d/*
ADD docker/nginx/nginx.pro.conf /etc/nginx/conf.d/rails_app.conf

RUN apt-get update \
  && apt-get install -y \
       openssl \
  && mkdir /etc/ssl/ca \
  && cd /etc/ssl/ca \
  && openssl req -new -newkey rsa:2048 -keyout server.key -nodes -out server.csr -subj "/C=JP/ST=Prefecture/O=Hoge/CN=www.hoge.com" \
  && openssl x509 -req -days 3650 -signkey server.key -in server.csr -out server.crt

CMD /usr/sbin/nginx -g 'daemon off;' -c /etc/nginx/nginx.conf

# docker/nginx/nginx.pro.conf

upstream unicorn {
  server unix:///rils-app-root/tmp/sockets/unicorn.sock;
}

server {
  listen 443 default ssl;
  server_name www.hoge.com;

  access_log /var/log/nginx/access.log main;
  error_log  /var/log/nginx/error.log warn;

  root /rails-app-root/public;

  client_max_body_size 100m;
  error_page 404             /404.html;
  error_page 505 502 503 504 /500.html;
  try_files  $uri/index.html $uri @rails_app;
  keepalive_timeout 5;

  ssl_certificate     /etc/ssl/ca/server.crt;
  ssl_certificate_key /etc/ssl/ca/server.key;
  ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers         HIGH:!aNULL:!MD5;

  location @rails_app {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Host $http_host;
    proxy_pass http://unicorn;
  }
}
```

### まとめ

なぜ、タスクは数分ですぐに停止してしまうのでしょうか？

サービスを通さずに単発でタスクを実行した状態と、サービスを通してタスクを実行した状態の差分に原因があると考えていますが、その原因をつかめておりません。
ALBが絡むくらいしか差分はないように思うのですが、ALBが原因であるとは考えづらいです、、。
このような問題の想定原因をご教授頂けますと幸いです。

宜しくお願い致します。

### 追記

5/19
調べると以下の公式資料が該当し、停止したタスクには停止理由が表示されるとのことでした。
コンソールから確認すると、以下のようになっていました。

```
停止理由: Scaling activity initiated by deployment ecs-svc/123456789001122
```

タスクの実行数を1にしてデプロイしているのですが、今回の問題だと永遠に新しいタスクが実行されてしまうため、確認したいことが終わるとタスク数を0にすることにより対応しています。
上記は、そのタスク数0の変更に対してサービスが対応した結果だと思われます.



```
停止理由: Task failed ELB health checks in (target-group arn:aws:elasticloadbalancing:ap-northeast-1:...)
```
3分置きに終了してしまうタスクには、この様な停止理由が書かれていました。
タスクは、ターゲーットグループのヘルスチェックが何回か失敗すると、自動的に停止する仕様になっているのでしょうか？
ヘルスチェックがなぜ失敗するのか、原因を調査してみます。

取り急ぎ、共有させて頂きます。


[https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/stopped-task-errors.html](https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/stopped-task-errors.html)

もう一つ追記です。
タスク数を2にしてデプロイしてみましたが、状況は変わりませんでした。
むしろ、実行されているタスク数は1から変わらず、少々おかしいような気がします。
こちらは、当方のECSやオートスケーリング、タスク配置についての理解不足が原因で、タスク数1が正常なのかなとも思っております。
こちらも共有させて頂きます。

AWS ECSにて、サービスで実行したタスクが3分置きに停止してしまう原因がわからない

### 実現したいこと
ECS on EC2で構築したコンテナに対し、インスタンス外からもパブリックIPでアクセスできるようにしたい
（現在は、EC2インスタンス内ではアクセスできている状態）

### 前提
Django REST Frameworkのアプリを作成し、ECRにプッシュしました。
その後、EC2インスタンス内でSSH接続して、以下のコマンドを使ってコンテナを立ち上げました。
```
sudo docker run -p 8000:8000 -d  (コンテナ名):(タグ名)
```
その後、以下のコマンドをEC2インスタンス内で実行すると問題なさそうに見えました
```
sudo docker logs　（コンテナid)
[2023-10-26 04:33:39 +0000] [1] [INFO] Starting gunicorn 21.2.0
[2023-10-26 04:33:39 +0000] [1] [INFO] Listening at: http://0.0.0.0:8000 (1)
[2023-10-26 04:33:39 +0000] [1] [INFO] Using worker: sync
[2023-10-26 04:33:39 +0000] [6] [INFO] Booting worker with pid: 6


```

### 発生している問題・エラーメッセージ

インスタンス外から接続が確認できない
（Failed to connect to (Elastic IP) port 8000 after 75004 ms: Couldn't connect to serverというエラーメッセージが出る）


### 試したこと

・インスタンス内でコマンドを使って接続
```
curl http://(バックエンドのElastic IP):8000/api/register/
>> (レスポンス内容は伏せますが、接続が確認できました)
```
・なお、フロントエンドのコンテナもECRにpushし、別のEC2インスタンスで立ち上げましたが
　こちらは問題なく接続できています。
　フロントエンドのEC2内でも、
```
curl http://(バックエンドのElastic IP):8000/api/register/
```
は問題なく実行できました。

・EC2インスタンスのセキュリティグループには、インバウンドルールで0.0.0.0/0から8000番ポートの接続を許可しています。


### 補足情報（FW/ツールのバージョンなど）
・一度は問題なく接続できましたが、突然接続できなくなってしまいました。
・インスタンスのファイアウォール(UFW)は無効になっていました。
・どちらのインスタンスもパブリックサブネットに配置しています。
・VPCにインターネットゲートウェイがアタッチされてることを確認しました。



ECS on EC2で構築したコンテナに対し、インスタンス外からアクセスできない

### 概要
ポートフォリオ用のwebアプリをruby on railsで製作中です。
railsの実行環境としてawsのecsを利用する想定ですが、
起動タイプをec2かfargateのどちらにするかを料金によって判断したいです。
aws price calculatorで計算しているのですが、各項目が正しく理解できている自信がありません。
条件と設定を記載したので、下記の設定で正しいか教えていただきたいです。

計算に使用したツール
https://calculator.aws/#/createCalculator/EC2
https://calculator.aws/#/createCalculator/Fargate

### 条件
・1日中起動しっぱなし
・ポートフォリオ用のwebアプリなので
　集客や多数のユーザーが利用することなどは考慮しない
・スペックは最低

### ecs fargateを使用する場合
（設定項目：設定値）
タスクまたはポッドの数：1/月
（1つのタスクを起動したままにするので、月当たりのタスク数は1の想定）
平均期間：30/日数
（１ヶ月を30日として入力。起動したままなので30日の想定）
割り当てられたvCPUの量：0.25
割り当てられたメモリ量：0.5GB
Amazon ECSに割り当てられたエフェメラルストレージの量：20GB

・金額
8.89USD

### ec2を使用する場合
（設定項目：設定値）
オペレーティングシステム：Linux
インスタンスタイプ：t2.micro
数量：1
使用率：100%

EBS部分
各EC2インスタンスのストレージ：汎用SSD(gp2)
ストレージ量：30GB

・金額
11.12USD

AWS ECSの料金計算について

### 解決したいこと
ECSサービスを立ち上げると、掲題のエラーが発生してコンテナが立ち上がりません。
エラー内容及び、AWSにて使用しているVPC, ECR, ECSの環境を記述しました。

コンテナが立ち上がらない原因、何か分かりましたらヒントなどでもご教授いただけますと幸いです。

### エラー内容
```
Cannotpullcontainererror: ref pull has been retried 5 time(s): 
failed to copy: httpReadSeeker: failed open: failed to do request: 
Get "https://prod-ap-northeast-1-starport-layer-bucket.s3.ap-northeast-1.amazonaws.com/....
```

### 動作環境
#### VPC
- サブネット
  パブリックサブネットを二つ用意。
  リストパブリック IPv4 アドレスを自動割り当て済

- ネットワークACL
  インバウンド、アウトバウンドルールにて、ポート番号80、443の0.0.0.0/0に対する通信を許可
  それ以外の通信は許否

- セキュリティグループ
  インバウンド、アウトバウンドルールにて、ポート番号80、443の0.0.0.0/0に対する通信を許可

- エンドポイント
  以下をサービス名のエンドポイントを作成して、VPCに紐付けた
  →com.amazonaws.ap-northeast-1.ecr.api
  →com.amazonaws.ap-northeast-1.ecr.dkr
  →com.amazonaws.ap-northeast-1.logs
  →com.amazonaws.ap-northeast-1.ssm
  →com.amazonaws.ap-northeast-1.s3（ゲートウェイ型）

  ※S3のエンドポイントを除いた全てのエンドポイントに対してセキュリティグループ（80番、443番の全通信(0.0.0.0/0)を許可）を付与してます

- ルートテーブル
  0.0.0.0/0の通信をインターネットゲートウェイに設定
  com.amazonaws.ap-northeast-1.s3の通信をS3のエンドポイント（ゲートウェイ）に設定
  それ以外の通信をローカルに設定


#### ECR
- ポリシー
  [リンク](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryReadOnly)に従い、AmazonEC2ContainerRegistryReadOnlyの部分のポリシーを付与した

#### ECS
- タスク定義
  タスク実行ロール：ecsTaskExecutionRoleのみを付与
  アプリケーション環境：FARGATEを使用

- クラスター
  ネットワークは上記に記述したVPCのサブネットを指定
  
- サービス
  FARGATEバージョン：1.4
  コンピューティングオプション：起動タイプ
  ネットワーキングのセキュリティグループ：VPCで作成したセキュリティグループ
  パブリックIP：有効

### 備考
[こちら](https://aws.amazon.com/jp/premiumsupport/knowledge-center/ecs-pull-container-error/)に記述してある対処方法は一通り試しました。
→プライベートネットワークを導入していないため、NATインスタンスに関連する操作は特にしてませんが


[AWS, ECS] Cannotpullcontainererrorの原因を解消したい

### 実現したいこと

ECSのサービス内にあるタスクを一度削除してしまったので、改めて「タスクの実行」をしたところ、「API の失敗 理由: RESOURCE:CPU」というエラーが出てきてしまったので、こちらのエラーを解消させたいです。

### 前提

起動タイプはEC2でECSにデプロイさせています。
・SSL化は完了している（ALBと紐付け完了済み)
・ECRにDockerイメージをpush済み、イメージが正常にリポジトリに登録されているか下記コマンドで確認済みです。

一度デプロイを完成させています。

### 発生している問題・エラーメッセージ

```
タスクを実行させた時
API の失敗 理由: RESOURCE:CPU

サービスのイベント
service onsen-service was unable to place a task because no container instance met all of its requirements. The closest matching container-instance feb※※ has insufficient CPU units available. For more information, see the Troubleshooting section of the Amazon ECS Developer Guide.
```

### 該当のソースコード

```
■ECSタスク作成
タスク定義名：onsen-task
タスクロール：ECS-Exec-role2
タスク実行ロール：ecsTaskExecutionRole
ネットワークモード：bridge
ボリュームの追加
　名前：sockets
　タイプ Docker
　ドライバー：local
　スコープ：task
タスクメモリ (MiB)512
タスク CPU (単位)512

■VPC
VPC：VPC_for_onsen
IPv4 CIDR ブロック：10.0.0.0/24

■サブネット作成
上記VPC作成に伴いサブネットが１つ勝手に作られるが、名前がデフォルトなので修正。
onsen-Subnet-1a
もう一つサブネットを作成。
VPC：VPC_for_onsen
サブネット名：onsen-Subnet-1c
IPv4 CIDR ブロック：10.0.1.0/24

■コンテナの定義
　onsen-nginx-container
　　イメージ：{AWSの12桁ID}.dkr.ecr.ap-northeast-1.amazonaws.com/onsen-nginx
　　ポートマッピング：0:80
　　マウントポイント
　　　コンテナパス：/app/tmp/sockets
　　　ソースボリューム：sockets
　　ログ設定チェックON

　onsen-container
　　イメージ：{AWSの12桁ID}.dkr.ecr.ap-northeast-1.amazonaws.com/onsen
　　コマンド： ["bundle","exec","puma","-C","config/puma.rb"]
　　ポートマッピング：0:3000
　　マウントポイント
　　　コンテナパス：/app/tmp/sockets
　　　ソースボリューム：sockets
　　ログ設定チェックON
　　環境変数
　　　DB_HOSTNAME    {RDSのホストARN}
　　　DB_NAME    {アプリDB名}
　　　DB_PASSWORD    password
　　　DB_USERNAME    root
　　　RAILS_ENV  production
　　　RAILS_MASTER_KEY   {Railsのconfig/master.keyの値}
　　　RAILS_SERVE_STATIC_FILES   true

■ELB作成
・ターゲットグループ作成
名前：onsen-Target-Group
Choose a target type：Instances
他そのまま

・ロードバランサー作成
Application Load BalancerInfoを選択
名前：onsen-ELB
VPC：上記と一緒　サブネットも２つ選択する。
セキュリティグループ選択
リスナーに上記ターゲットグループを選択

■ECSクラスター
EC2 Linux + ネットワーキングを選択
クラスター名：onsen-cluster
プロビジョニングモデル：オンデマンドインスタンス
EC2 インスタンスタイプ：t2micro
インスタンス数：2 
EC2 AMI ID*：そのまま
ルート EBS ボリュームサイズ (GiB)：そのまま
キーペア：上記で作成したキーペア
VPC：上記のもの
サブネット：Publicのサブネットどちらか１つ指定すればOK？
パブリック IP の自動割り当て：サブネット設定を使用
セキュリティグループ：今回作成したものを割り当て
コンテナインスタンスの IAM ロール：ecsInstanceRole

■サービスの
起動タイプ：EC2
タスク定義：上記のもの
クラスター：上記のもの
サービス名：onsen-service
サービスタイプ：REPLICA
タスクの数：2 
最小ヘルス数：50
最大率：100
デプロイサーキットブレイカー：無効
デプロイメントタイプ：ローリングアップデート
ロードバランサーの種類：ALB
サービス用の IAMロールの選択：AWSServiceRoleForECS
ロードバランサー名：onsen-ELB
ロードバランス用のコンテナ:nginxを「ロードバランサーに追加」ボタンクリック
```

### 試したこと
メモリが不足している可能性があったので、EC2 インスタンスタイプを「t2.micro」から「t2.small」に変更しました。

新しくタスク定義を作成するために、タスクサイズを
タスクメモリ (MiB)512
タスク CPU (単位)512

だったものを

タスクメモリ (MiB)1024
タスク CPU (単位)1024
に変更しました。

参考サイト
https://repost.aws/ja/knowledge-center/ecs-change-container-instance-type
https://repost.aws/ja/knowledge-center/allocate-ecs-memory-tasks
### 補足情報

ECS作成時の参考サイト
https://qiita.com/saongtx7/items/f36909587014d746db73

ECSはまだまだ浅学なため、知識もまだまだ不足しています。
なので拙い説明となってしまい申し訳ありません。
AWS公式等色々と読んで試してみても、解決の糸口を見つけられなので、お力添え頂けるよう、よろしくお願い致します。

API の失敗 理由: RESOURCE:CPU　エラーの解決方法

現在、「コンテナ時代のWebサービスの作り方」という書籍を元に、AWS ECSの学習をしております。
Terraformを利用してリソースを作成し、AWS CLIを利用してECSのタスク定義更新、サービス更新をしようとしております。

やりたいことは、「起動しているタスク定義のリビジョンを最新にしたい」です。
ECSのサービスに紐づくタスク定義のリビジョンの更新は新しくなるものの、起動しているタスク定義のタスクのリビジョンが新しくならず困っております。

## 環境
```
$ sw_vers
ProductName:	macOS
ProductVersion:	11.1
BuildVersion:	20C69

$ aws --version
aws-cli/2.1.28 Python/3.9.2 Darwin/20.2.0 source/x86_64 prompt/off
```

## 前提
- タスク定義名: webapp-service
- サービス名: webapp-service
- クラスタ名: sample-ecs-cluster

## 実施したこと

```
# タスク定義のテンプレートを出力 & 保存
$ aws ecs describe-task-definition --task-definition webapp-service | jq '.taskDefinition | { containerDefinitions: .containerDefinitions }' > task_definition.json

# タスク定義のテンプレートに基づきタスク定義を更新
$ aws ecs register-task-definition --family webapp-service --cli-input-json file://task_definition.json

# サービスを更新
$ aws ecs update-service --cluster sample-ecs-cluster --service webapp-service --task-definition webapp-service
```

※コマンドのリファレンス: [update-service — AWS CLI 1.19.17 Command Reference](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html#options)

## 結果
- サービスに紐づくタスク定義のリビジョン: 最新になっている `webapp-service: 8`


![イメージ説明](cb4165c7ed60e860b46d67a4c998f437.png)

- 起動しているタスクのタスク定義のリビジョン: 古いまま `webapp-service: 4`

![イメージ説明](f6038d5502fb9091b99546a5e9b62843.png)

## お願い
起動しているタスク定義のリビジョンを最新にしたいです。

「確認すべき項目」や「次に取るべきアクション」など、アドバイスいただけますと幸いです。