Contents
Dockerコンテナデプロイの基礎と目的
Dockerコンテナは、アプリケーションの依存関係や環境設定をパッケージ化し、一貫性のある実行環境を作成する技術です。開発・本番環境共通で導入することで、「環境ごとの不一致による障害」を大幅に減らすことができます。この記事では、Dockerコンテナのデプロイ手順とベストプラクティスをステップバイステップで解説し、EC2やクラウド環境への実践的な導線を提供します。
Dockerfileとdocker-compose.ymlの基本構成
アプリケーションのビルドと運用を安定させるには、Dockerfileとdocker-compose.ymlの適切な記述が不可欠です。両ファイルのベストプラクティスを押さえれば、開発環境から本番環境への移行もスムーズになります。
Dockerfileにおけるベストプラクティス
Dockerfileはイメージを作成するためのレシピと考えてください。以下のようなポイントに注意すると、効率的なビルドが可能になります。
-
ベースイメージの指定:
FROMで安定した公式イメージ（例:nginx:latest）を明記し、バージョン管理を確立ベースイメージは定期的に更新されるため、固定タグ（例:
nginx:1.23）を使用するべきです。 -
多段階ビルドの活用: 環境構築に不要な中間ファイルを排除し、イメージサイズを削減
Dockerfile
# ビルド用ステージ
FROM golang:1.20 as builder
WORKDIR /app
COPY . .
RUN go build -o myapp
# 実行用ステージ（最小限のベースイメージ）
FROM alpine:3.18
COPY --from=builder /app/myapp /usr/local/bin/
CMD ["myapp"]
- ENVで環境変数を定義: テスト環境と本番環境で差異を管理
Dockerfile
ENV NODE_ENV=development
docker-compose.ymlで定義すべき要素
複数コンテナの運用にはdocker-composeが効果的です。サービス・ネットワーク・ボリュームなどの構成を統一することで、開発と本番環境で同じ設定を共有できます。
| 項目 | 必須/任意 | 内容例 |
|---|---|---|
| services | 必須 | 各コンテナの定義（イメージやポート指定など） |
| volumes | 任意 | ボリュームのマウント設定 |
| networks | 任意 | コンテナ間通信のネットワーク構成 |
例:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
version: '3.8' services: webapp: image: my-web-app:latest ports: - "80:80" environment: - DB_HOST=db depends_on: - db db: image: postgres:14 volumes: - db_data:/var/lib/postgresql/data |
ローカルからAWS EC2へのデプロイフロー
ローカル環境で動作確認したコンテナを、本番環境（例: AWS EC2）に移行するには、以下のようなフローを実装します。
EC2インスタンスの準備手順
- EC2インスタンスの起動: Amazon Linux 2やUbuntuなどのOSを選択し、セキュリティグループで必要なポート（例: 80, 443）を開く
- Docker Engineのインストール: AWS CLIやSSH経由でインスタンスにアクセスし、以下のように導入します。
Amazon Linux用コマンド:
|
1 2 3 4 5 |
sudo yum update -y sudo yum install -y docker sudo systemctl start docker sudo systemctl enable docker |
Ubuntu用コマンド:
|
1 2 3 4 5 |
sudo apt-get update sudo apt-get install -y docker.io sudo systemctl start docker sudo systemctl enable docker |
コンテナイメージのビルド・プッシュ
ローカルで以下のようにイメージを構築し、AWS ECR（Elastic Container Registry）などにプッシュします。
|
1 2 3 4 5 6 7 8 9 10 |
# ローカルでのイメージビルド docker build -t my-web-app:latest . # ECRリポジトリへのログイン aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin <account-id>.dkr.ecr.us-east-1.amazonaws.com # イメージのタグ付けとプッシュ docker tag my-web-app:latest <account-id>.dkr.ecr.us-east-1.amazonaws.com/my-web-app:latest docker push <account-id>.dkr.ecr.us-east-1.amazonaws.com/my-web-app:latest |
リモートでのコンテナ起動
EC2インスタンス上で以下のコマンドでイメージを実行します。
|
1 2 3 4 5 6 7 8 |
# イメージのプル docker pull <account-id>.dkr.ecr.us-east-1.amazonaws.com/my-web-app:latest # コンテナの起動（環境変数は外部ファイルから読み込む） docker run -d -p 80:80 \ --env-file ./prod.env \ <account-id>.dkr.ecr.us-east-1.amazonaws.com/my-web-app:latest |
バージョン管理と環境別設定ファイルの分離
CI/CDとの連携を円滑にするには、バージョン管理と環境ごとの設定の分離が重要です。
Dockerイメージタグの命名規則
リリース時や環境違いに応じて一意なタグ名をつけましょう。以下の例は一般的な命名方法です。
| 環境 | タグ名 | 説明 |
|---|---|---|
| 開発 | my-app:dev |
開発用に限定したバージョン |
| 本番 | my-app:latest |
最新ステージの本番リリース |
| テスト | my-app:test-20260718 |
日付つきでバージョン管理 |
注意: 本番環境では固定タグ（例:
v1.0.0）を使用すると、誤って最新の開発版をデプロイしてしまうリスクを防げます。
環境変数ファイルの管理方法
各環境で異なる設定値を持つ場合は、.envファイルまたはDocker Secretsを使用します。
|
1 2 3 4 5 6 7 8 |
# .dev.env（開発用） DB_HOST=localhost APP_DEBUG=true # .prod.env（本番用） DB_HOST=production-db.example.com APP_DEBUG=false |
セキュリティ対策: 本番環境では
.envファイルをリポジトリ外に管理し、Docker SecretsやAWS SSM Parameter Storeで安全に取得しましょう。
CI/CD連携時の注意点とデプロイ自動化
CI/CDにより効率的な自動デプロイが可能ですが、手動操作との境界線を明確にすることが重要です。
GitHub ActionsでのDockerビルド例
以下はGitHub ActionsでDockerイメージをビルドし、AWS ECRへプッシュするワークフローの抜粋です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
name: Build and Push Docker Image on: push: branches: - main jobs: build: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v3 - name: Set up QEMU uses: docker/setup-qemu-action@v1 - name: Build and push Docker image uses: docker/build-push-action@v5.x # バージョン指定を範囲化 with: context: . file: ./Dockerfile push: true tags: | <account-id>.dkr.ecr.us-east-1.amazonaws.com/my-web-app:latest <account-id>.dkr.ecr.us-east-1.amazonaws.com/my-web-app:${{ github.sha }} |
手動デプロイとの境界線
自動化の範囲は慎重に決めましょう。例えば、以下のようなケースでは手動操作を保留するべきです。
- 本番環境へのリリース前：テスト環境で動作確認後、DevOpsが最終的に「Deploy」ボタンを押す
- 重大な設定変更時: データベースの構造変更やセキュリティ設定変更では、リーダー承認が必要
自動化によるエラーは手動で検出・修正が可能になるため、バランスを取りながら導入してください。
セキュリティ設定と運用時のベストプラクティス
本番環境におけるセキュリティリスクを最小限にするには、コンテナの実行権限やポート開放などを厳格に管理する必要があります。
ポート開放の最小限化
「使わないポートは絶対開けない」というルールを定めましょう。以下のようにEXPOSE指令で公開するポートを明示すると、セキュリティポリシーにも合致します。
|
1 2 |
EXPOSE 80 |
注意: セキュリティグループの設定も忘れずに。AWS EC2では最小限のポートだけを開くことを推奨します。
非rootユーザーでのコンテナ実行
root権限で動くコンテナは、脆弱性が発見された際にシステム全体に影響を及ぼすリスクがあります。USER指令で非rootユーザーを作成し、実行許可を与える方法です。
|
1 2 3 |
RUN adduser --disabled-password --gecos '' myuser USER myuser |
実践例: Ubuntuのイメージでは
myuserとしてコンテナを起動し、スクリプトやファイル操作は非rootで行います。さらにEC2上での実行時に以下のように権限設定を行う必要があります。
|
1 2 |
sudo chown -R myuser /path/to/app |
Dockerデプロイチェックリスト
本記事の要点をまとめると以下の通りです：
- Dockerfileとdocker-compose.ymlの最適な記述方法
- EC2などのクラウド環境へのデプロイフロー
- バージョン管理と環境変数ファイルの分離技術
- CI/CDとの連携と自動化の境界線
- セキュリティ設定（ポート制限・非root実行）
Dockerの導入・運用をスムーズに進めるために、以下のチェックリストを作成しました。
→ 「Dockerデプロイチェックリスト」をダウンロードして、実践導入をサポートしてください。