Skip to Content
AWS（Amazon Web Services）中級AWS 中級カリキュラム（EC2からECS on Fargateへのコンテナ移行）ステップ1：Dockerによるアプリケーションのコンテナ化

ステップ1：Dockerによるアプリケーションのコンテナ化

今回のステップの概要とECサイトとの関連について

このステップでは、従来のEC2上で直接実行していたRailsアプリケーションをDockerコンテナ化し、最終的にAWS Fargateでのサーバーレス実行に向けた準備を行います。具体的には、Dockerfileを作成してコンテナイメージをビルドし、ローカル環境でコンテナとして実行する方法を学習します。

ECサイトにとって、コンテナ化は「将来のサーバーレス運営に向けた商品の標準化パッケージング」のような役割を果たします。どんな環境でも同じように動作するよう、アプリケーションとその実行環境を一つのパッケージにまとめることで、後のFargateでのサーバーレス実行において一貫した動作を保証できます。

このステップで学ぶこと

リソースの関わりと構成説明

ステップ1で作成するリソースは、ECサイトのアプリケーション実行環境の標準化を構築するものです。それぞれのリソースがECサイトにどのように関わるのかを説明します。

Dockerfileとアプリケーションの関わり

Dockerfile「コンテナイメージ設計書」は、ECサイトの「商品パッケージの仕様書」のような役割を果たします。Ruby環境、必要なライブラリ、アプリケーションコードを一つのパッケージにまとめる手順を定義します。これにより、どの環境でも同じように動作するECサイトアプリケーションを作成できます。

コンテナイメージとポータビリティの関わり

コンテナイメージ「実行可能パッケージ」は、ECサイトの「完成品の商品」のような役割を果たします。開発環境で作成したイメージをそのまま本番環境で実行できるため、環境差異による問題を解消します。これにより、ECサイトの安定した運用が可能になります。

ポートマッピングとアクセス制御の関わり

ポートマッピング「通信経路の設定」は、ECサイトの「店舗への入口設定」のような役割を果たします。コンテナ内で動作するアプリケーションに外部からアクセスできるよう、適切なポート設定を行います。これにより、ユーザーがECサイトにアクセスできるようになります。

実際の手順

実際の手順では、たくさんの設定値を入力することになります。 本文中に設定値が指定されていない場合は、デフォルト値のまま作業を進めてください。

1. ローカル環境からAWS環境への接続設定

まず、ローカルのVS CodeからAWS環境にアクセスするための認証設定を行います。

1-1. AWS認証情報の設定

  1. 「AWS access portal」の画面で「アクセスキー」をクリックします。 AWS access portal

  2. ご自身の環境に合わせて「macOS and Linux」、「Windows」、「PowerShell」のタブを選択してください。
    Authentication information

  3. 「オプション 1: AWSの環境変数を設定する」に表示されたAWS環境変数をローカルターミナルで実行します。
    以下は「macOS and Linux」を選択した場合の例です。

export AWS_ACCESS_KEY_ID="ABCDEFGHIJ....."
export AWS_SECRET_ACCESS_KEY="1234ABCDEFG+......"
export AWS_SESSION_TOKEN="ABCDEFGHIJKLMNO+abcdefghijklmnop....."
Tip

【解説】AWS環境変数による認証

AWS環境変数を設定することで、ローカル環境からAWSリソースにアクセスできるようになります。この方法は一時的な認証情報を使用するため、セキュリティ面で優れています。

環境変数は現在のターミナルセッションでのみ有効なため、新しいターミナルを開く際は再度設定が必要です。また、セッションには有効期限があるため、長時間の作業では再取得が必要になる場合があります。

本番環境では、IAMロールやAWS CLIの設定ファイルを使用した永続的な認証設定を行うのが一般的です。

  1. 認証情報が正しく設定されているかを確認します。
aws sts get-caller-identity

以下のような出力が表示されれば、認証設定は成功です。

{
    "UserId": "ABCDEFGHIJ.....",
    "Account": "01234567890",
    "Arn": "arn:aws:iam::01234567890:user/myisb_lsbUsersPS"
}
  1. 次のステップで使用するECRへのログインも試してみましょう。
# アカウントIDを取得
AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query "Account" --output text)
 
# ECRにログイン
aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin ${AWS_ACCOUNT_ID}.dkr.ecr.us-east-1.amazonaws.com

以下のような出力が表示されれば、ECRログインも成功です。

Login Succeeded

以下のようなWARNING無視してかまいません。

WARNING! Your password will be stored unencrypted in 〜
Tip

【解説】ECR事前ログインの意味

ECR（Elastic Container Registry）へのログインを事前に確認することで、後のステップでコンテナイメージをプッシュする際のトラブルを防げます。

ECRログインには一定の有効期限があるため、長時間作業する場合は再度ログインが必要になることがあります。エラーが発生した場合は、AWS認証情報の再設定とECRへの再ログインを行ってください。

このログイン情報はDockerの認証情報として保存され、docker pushコマンド実行時に自動的に使用されます。

2. Docker環境の確認とコンテナ概念の理解

まず、コンテナの開発においてよく使われる概念を再確認します。

Note

【コンテナ技術での役割】

Dockerは、アプリケーションとその実行環境をパッケージ化するコンテナプラットフォームです。

特徴:

  • アプリケーションと依存関係を一つのパッケージにまとめる
  • 軽量で高速な起動が可能
  • 環境間でのポータビリティを提供
  • インフラストラクチャの抽象化を実現

【オンプレミスでの対応】

オンプレミス環境では「仮想マシン」や「物理サーバー」が対応します。

  • 各環境での個別セットアップが必要
  • 重いリソース消費と長い起動時間
  • 環境差異による動作の違いが発生しやすい
項目説明
コンテナイメージOSやアプリケーションのファイルを含むファイルシステムのようなもので、コンテナのテンプレートとなる
コンテナコンテナイメージを元に起動されるアプリケーションプロセス
イメージレジストリコンテナイメージを保管および提供するサービスで、リポジトリにコンテナイメージを格納する
Dockerfileコンテナイメージの作成手順をコードとして記述したファイル

2-1. Docker コマンドを確認する

ローカル環境でDockerのコマンドを確認します。ローカルのターミナルで作業します。

事前にローカル環境にDockerがインストールされている必要があります。インストールされていない場合は、Docker公式サイト からDocker Desktopをダウンロードしてインストールしてください。

  1. 以下のコマンドをターミナルで実行し、Docker のバージョンを確認しましょう。
docker --version
docker info
  1. 以下のような結果が表示され、Docker がインストール・実行されていることを確認できます。
    1. バージョンやBuildバージョン、コンテナ起動数などが異なっていても問題ありません。これらはローカル環境によって異なります。
# docker --versionの表示例
Docker version 24.0.7, build afdd53b
# docker infoの表示例
Server:
 Containers: 2
 Running: 0
 Paused: 0
 Stopped: 2
 Images: 3
Tip

【解説】Docker環境の確認重要性

Docker環境の確認は、コンテナ化作業の前提条件となります。バージョン情報とサービス状態を確認することで、適切な機能が利用可能か判断できます。

特に本番環境では、Dockerデーモンの状態監視が重要で、サービスが停止するとすべてのコンテナが影響を受けます。

開発段階でも、Dockerのバージョンによって利用可能な機能が異なるため、事前確認は必須です。

3. Dockerfileの作成

コンテナの元となるコンテナイメージの作成手順を記述したものが Dockerfile です。

3-1. 作業ディレクトリの作成

  1. ローカル環境に作業用ディレクトリを作成し、移動します。
mkdir docker-rails-workshop
cd docker-rails-workshop

3-2. 空のDockerfileを作成する

  1. 作業ディレクトリ内に空のDockerfile を作成します。
touch Dockerfile

拡張子無しの Dockerfile という名前のファイルを用意することで、コンテナイメージのビルド時に Dockerfile のファイル名の引数 “-f ${FILENAME}” を省略できます。

  1. VS Codeで作業ディレクトリを開き、Dockerfileを編集して次の内容を記述します。
# ruby:3.2.1 というベースイメージを取得する
FROM public.ecr.aws/docker/library/ruby:3.2.1
 
# 必要なパッケージ群を取得する
RUN apt-get update -qq && \
    apt-get install -y nodejs postgresql-client npm && \
    rm -rf /var/lib/apt/lists/*
 
# ローカルにあるファイルをコンテナイメージ内にコピーする
WORKDIR /myapp
COPY Gemfile /myapp/Gemfile
 
# Rails アプリケーションを作成する
RUN bundle install && \
    rails new . -O && \
    sed -i -e "52a\  config.hosts.clear\n  config.web_console.allowed_ips = '0.0.0.0/0'\n  config.action_dispatch.default_headers.delete('X-Frame-Options')" config/environments/development.rb
 
# Rails を 3000 番ポートで起動する
EXPOSE 3000
CMD ["rails", "server", "-b", "0.0.0.0", "-p", "3000"]
Tip

【解説】ECR Publicを使用する理由

Ruby の Docker 公式イメージを ECR Public からダウンロードするように指定しています。ECR Public を使用することで、Docker Hub の API 制限を気にする必要がなくなります。

また、ECR Public に格納されたコンテナイメージは各リージョンに複製され、かつ Amazon CloudFront によってキャッシュされるため、ダウンロード時間の短縮と可用性の向上を実現できます。

実際のアプリケーション開発では、あらかじめ作成しておいたアプリケーションファイルをコンテナイメージ内にコピーしていくことになります。

  1. 編集が終わったら、ファイルを保存します（Ctrl+S / Cmd+S）。

3-3. Gemfileの作成

  1. Dockerfile内でコピーする元となる Gemfile を作成しましょう。
touch Gemfile
  1. VS CodeでGemfileを編集し、次の内容を記述します。
source 'https://rubygems.org'
gem 'rails', '7.2.2'

4. コンテナイメージのビルド

Dockerfile やアプリケーションファイルを作成し、コンテナイメージをビルドする準備ができました。

4-1. コンテナイメージをビルドする

  1. 作業ディレクトリにいることを確認し、以下のコマンドを実行することで、コンテナイメージをビルドできます。
# 現在のディレクトリを確認
pwd
# docker-rails-workshopディレクトリにいることを確認
 
# コンテナイメージをビルド
docker build -t rails-app .

-t のあとの引数では、ビルドするコンテナイメージの “名前” を指定しています。最後のピリオド (.) は、ビルド時の “コンテクスト” としてカレントディレクトリを指定しています。

  1. しばらく待つと、ビルドが完了します (数分かかります)。以下のような出力が表示されれば、ビルドは成功です。
Successfully built d1b29875400d
Successfully tagged rails-app:latest
  1. 完成したコンテナイメージは、以下のコマンドで確認できます。
docker image ls
Tip

【解説】コンテナイメージのポータビリティ

コンテナ技術を使用して環境を “コンテナイメージ” にパッケージ化することで、アプリケーションのポータビリティが増します。

Ruby やアプリケーションファイルを準備して、コンテナイメージを作成することで、コンテナ実行環境さえ用意すれば、Ruby などのミドルウェアや依存ライブラリを設定しなくとも Ruby on Rails アプリケーションを実行できるようになりました。

これは、コンテナでアプリケーションを開発するメリットの 1 つです。

5. コンテナの実行と動作確認

この手順では、ローカルでビルドしたコンテナイメージを使用してコンテナを実行し、アプリケーションの動作を確認します。

5-1. コンテナを実行する

  1. コンテナイメージの名前やタグ、ポートマッピングを指定してコンテナを実行します。
docker run -d -p 8081:3000 rails-app:latest

このコマンドでは、ローカルホストの 8081 番ポートを、コンテナの 3000 番ポートにマッピングしています。

  1. コンテナが正常に起動しているかを確認します。
docker ps

5-2. アプリケーションにアクセスする

  1. ブラウザを開き、以下のURLにアクセスします。
http://localhost:8081
  1. Rails アプリケーションのウェルカムページが表示されれば成功です。
Tip

【解説】ローカル環境でのポートマッピング

ローカル環境では、localhost:8081で直接アクセスできます。VS Code Serverと異なり、特別なポートフォワーディング設定は不要です。

コンテナが起動しない場合は、docker logs <コンテナID>でログを確認し、エラーの原因を特定できます。また、ポート8081が既に使用されている場合は、別のポート（例：8082）を使用してください。

作業完了後は、docker stop <コンテナID>でコンテナを停止し、docker rm <コンテナID>で削除することをお勧めします。

このステップで何をしたのか

このステップでは、従来のEC2上で直接実行していたRailsアプリケーションをDockerコンテナ化しました。具体的には、Dockerfileを作成してアプリケーションの実行環境を定義し、コンテナイメージをビルドしてローカル環境で実行しました。また、ポートマッピングを設定してブラウザからアプリケーションにアクセスできるようにしました。

ECサイトでどのような影響があるのか

この構成により、ECサイトは環境に依存しない一貫した実行環境を獲得しました。開発環境で動作するアプリケーションが本番環境でも同じように動作することが保証されます。また、新しいサーバーへの展開時にも、Dockerさえインストールされていれば即座にアプリケーションを起動できます。これは、物理的な店舗を標準化されたパッケージで複製できるようにすることに相当します。

技術比較まとめ表

技術領域AWSオンプレミス
コンテナ実行Docker → Fargate移行
サーバーレス実行への準備		Docker on 物理サーバー
ハードウェアリソースに依存
イメージ管理ECR (次ステップで使用)
Fargateとの統合による高速配信		プライベートレジストリ
自前での可用性確保が必要
ポートマッピングFargateタスクでの動的割り当て
サーバーレス対応のネットワーク		ファイアウォール設定
手動での設定管理

学習において重要な技術的違い

1. 環境の一貫性

  • AWS：ECR Publicからの公式イメージ使用で安定性を確保
  • オンプレミス：Docker Hubや自前レジストリでのイメージ管理

2. ポータビリティ

  • AWS：複数のAWSサービス間での一貫した実行
  • オンプレミス：異なるサーバー間での環境差異の可能性

3. スケーラビリティ

  • AWS：Fargateによる完全サーバーレス自動スケーリング（後のステップで学習）
  • オンプレミス：手動でのコンテナ管理とスケーリング

4. 運用負荷

  • AWS：Fargateによるサーバー管理完全不要
  • オンプレミス：Docker環境とサーバーの継続的な維持管理が必要

実践チェック：画面キャプチャで証明しよう

下記のチェック項目について、実際にローカル環境で設定ができていることを確認し、各項目ごとに該当画面のスクリーンショットを撮影して提出してください。

  • AWS認証情報設定の確認（aws sts get-caller-identityの実行結果）

  • ECRログイン確認（Login Succeededの表示確認）

  • Dockerのバージョン確認コマンドの実行結果

  • 作業ディレクトリとDockerfile、Gemfileの作成確認

  • docker buildコマンドの実行結果

  • docker image lsコマンドでのイメージ確認

  • docker runコマンドでのコンテナ起動確認

  • ブラウザでのRailsアプリケーション表示（localhost:8081）

提出方法： 各項目ごとにスクリーンショットを撮影し、まとめて提出してください。 ファイル名やコメントで「どの項目か」が分かるようにしてください。

構成図による理解度チェック

このステップで作成したDocker環境の構成を図で表現し、コンテナ化の理解を深めましょう。

なぜ構成図を更新するのか？

コンテナ化により従来のサーバー上での直接実行から、コンテナを介した実行に変わりました。この変化を視覚的に理解することで、次ステップでのECS移行時の理解が深まります。アプリケーションの実行方式の変化を明確に把握することが重要です。

  • 実行環境の抽象化: Dockerコンテナによるアプリケーション実行の仕組み
  • ポートマッピング: ホストとコンテナ間の通信経路
  • イメージとコンテナ: 静的なイメージから動的なコンテナへの変換プロセス

構成図の書き方

以下の要素を含む構成図を作成してみましょう。

  1. ローカル環境: 開発環境としてのローカルマシン
  2. AWS認証: 環境変数によるAWSアクセス設定
  3. Dockerコンテナ: rails-appイメージから起動されたコンテナ
  4. ポートマッピング: localhost:8081 → container:3000の通信経路
  5. ブラウザアクセス: localhost:8081へのHTTPアクセス

💡 ヒント: ローカル環境を大きな枠で囲み、その中にDockerコンテナを配置。AWS認証は雲のマークで表現し、ポートマッピングを矢印で表現しましょう。

理解度チェック：なぜ？を考えてみよう

AWSの各リソースや設計には、必ず”理由”や”目的”があります。 下記の「なぜ？」という問いに自分なりの言葉で答えてみましょう。 仕組みや設計意図を自分で説明できることが、真の理解につながります。 ぜひ、単なる暗記ではなく「なぜそうなっているのか？」を意識して考えてみてください。

Q. なぜDockerfileでECR Publicのイメージを使用するのか？

Q. なぜコンテナ化することでアプリケーションのポータビリティが向上するのか？

Q. なぜポートマッピング（8081:3000）が必要なのか？

今回のステップで利用したAWSサービス名一覧

  • Docker：コンテナ化プラットフォーム
  • ECR Public：パブリックコンテナイメージレジストリ（イメージ取得に使用）
Last updated on
学習の進め方ステップ2：VPCネットワーク基盤とECSクラスター構築