ローカル環境 vs AWS ECS：Docker Compose を活用した構成の違いを整理し、自分なりに記事としてまとめてみた

## はじめに
AWS ECS は、アプリケーションを簡単にスケーラブルかつ高可用性で動作させるためのサービスです。

:::note info
***本記事では、Go 言語を用いたアプリ開発を例に、ローカル環境との違いや ECR を使ったイメージ管理について解説します。***
:::

なお、本記事の内容は個人的な備忘録としてまとめたものですので、その点をご了承いただければ幸いです。**少しでも参考になれば幸いです。**

## 書こうと思ったきっかけ
受講している IT スクールのハッカソンに参加した際、チームで作成したリポジトリを使用し、AWS 上で ECR と ECS を使ったデプロイに挑戦しました。

:::note warn
**その中で、アプリケーションが正しく立ち上がらないというエラーに直面し、原因調査を進める中でいくつかの気づきを得ました。**
:::

***結論としては、ローカル環境用と AWS の ECS 用では、構成に若干の修正が必要だったことが原因でした。***

## ローカル環境用 vs ECS 用の構成の違い

今回発生した事象について、冷静に分析し、自分なりにローカル環境と ECS 上の構成の違いを表形式でまとめました。***必要に応じて参考にしてみてください。***

| 項目                   | ローカル環境                          | ECS 上                                |
|------------------------|---------------------------------------|---------------------------------------|
| **Docker Compose**     | `docker-compose.yml` を使用           | 使用しない                            |
| **ホットリロード（Air）** | 使用（ローカル開発用）                | 使用しない                            |
| **イメージのビルド**    | ローカルでビルド                      | ECR にプッシュしたイメージを使用      |
| **ネットワーク設定**    | `ports: "1323:1323"` でホストと接続  | ECS の `awsvpc` ネットワークモード    |
| **デプロイ**           | ローカルで起動                        | ECS サービスを作成                    |

### Docker Composeの違い

**ローカル環境:**

- `docker-compose.yml` を使用して、複数のコンテナ（アプリケーション、データベースなど）を簡単に管理できます。  

- 以下はローカルで Air を使った開発用の `docker-compose.yml` の例です。

```yaml
version: '3.9'
services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    volumes:
      - .:/usr/src/app
    ports:
      - "1323:1323"
    tty: true
```

**ECS 上:**

- AWS ECS は `docker-compose.yml` を使用しません。  
- 必要な設定は ECS のタスク定義とサービス作成で指定します。

### ホットリロード（Air）の違い

**ローカル環境:**

- Air を使用することで、コードを保存するたびに自動的にアプリケーションを再起動し、開発速度を向上させます。  
- Air の設定ファイル（`.air.toml`）を用意して開発時に利用します。

**ECS 上:**

- ホットリロードは不要です。ビルドされた安定版のイメージを ECS にデプロイします。  
- ホットリロード用のコード（Air 関連）や設定ファイルは含めず、シンプルな構成にします。

### イメージのビルドの違い

**ローカル環境:**

- ローカルで Docker イメージをビルドし、そのままローカルで実行します。  
- 開発中に何度もビルドと実行を繰り返します。

```bash
docker build -t my-app .
docker run -p 1323:1323 my-app
```

**ECS 上:**

- Docker イメージをビルドした後、AWS ECR（Elastic Container Registry）にプッシュして、ECS から利用可能にします。

```bash
docker build -t my-app .
docker tag my-app:latest <account-id>.dkr.ecr.<region>.amazonaws.com/my-app:latest
docker push <account-id>.dkr.ecr.<region>.amazonaws.com/my-app:latest
```

### ネットワーク設定の違い

**ローカル環境:**

- `ports: "1323:1323"` を使用して、ホストマシン（ローカル）のポート 1323 をコンテナ内のポート 1323 にバインドします。  
- ローカルで `http://localhost:1323` にアクセスして動作確認を行います。

**ECS 上:**

- ECS ではネットワークモードとして `awsvpc` を使用します。これにより、タスクが独自の ENI（Elastic Network Interface）を持つようになります。  
- パブリックサブネット内で起動し、外部アクセス用にセキュリティグループを設定します。

### デプロイ

**ローカル環境:**

- `docker-compose` を使い、ローカルで簡単に起動します。

```bash
docker-compose up --build
```


**ECS 上:**

- ECS タスク定義を作成し、ECS サービスを起動します。  

- **必要な手順**
  - ECR にイメージをプッシュ  
  - ECS タスク定義の作成  
  - ECS サービスの作成  
  - セキュリティグループの設定

## まとめ

ここまで読んでいただき、ありがとうございました。***今回の問題について、私自身も多くの学びを得ることができました。***

:::note warn
**※簡単な知識整理**
- **ローカル環境**: 開発とテストに特化（`docker-compose.yml`、ホットリロード）。  
- **ECS 上**: 本番環境用（ECR イメージ、Fargate、`awsvpc` ネットワークモード）。
:::

これらの違いを正しく理解し、適切な手順で構成を切り替えることで、AWS ECS 上でアプリケーションをスムーズに動作させることが可能になります。

***この記事がどなたかの技術的な参考になれば幸いです！***