Contents
Dockerfileの作成手順
Actix Webアプリケーションを効率的にビルド・デプロイするには、マルチステージビルドによるDockerfileの作成が推奨されます。この手法は、最終イメージサイズの削減やセキュリティ強化に有効です。以下では具体的な手順とベストプラクティスを解説します。
マルチステージビルドとは、1つのDockerfileで「ビルド用コンテナ」と「実行用コンテナ」の2段階を構成し、必要なファイルのみを最終イメージに含める手法です。これにより、開発ツールなどの不要な依存を排除できます。
マルチステージビルドのベストプラクティス
Actix Webアプリ向けDockerfileテンプレートは以下のように構成されます。Rust 1.73とDocker Engine 24.x以降で動作が確認されています（最新情報ではないため、実際の環境に応じてバージョンを確認してください）。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
# ビルドステージ: Rustでアプリをコンパイル FROM rust:1.73 as builder WORKDIR /app COPY Cargo.toml . COPY Cargo.lock . RUN cargo build --release COPY . . RUN cargo build --release # 実行ステージ: 最小限のLinuxイメージを使用 FROM debian:bookworm-slim WORKDIR /app COPY --from=builder /app/target/release/app /app CMD ["./app"] |
注意点と最適化ポイント
rust:1.73イメージの使用: Rust開発環境に最適化されたイメージを使用し、ビルドの一貫性を確保します。- releaseモードでのコンパイル: 実行ファイルは
--releaseオプションで構築され、パフォーマンスと安全性が向上します。 - 不要なツールの排除: 最終イメージには
cargoやrustcなどの開発用ツールを含めず、セキュリティリスクの軽減につなげます。
マルチステージビルドにより、開発環境と本番環境での差異が最小限に抑えられ、運用コストも削減できます。
docker-compose.ymlの構築例
複数サービスを含むアプリケーションは、docker-compose.ymlを使って一括管理すると効率的です。特にネットワークやポート設定の明確化がデバッグやテストに重要になります。
サービス定義の標準的な書き方
Actix Webアプリ用の基本構成例を以下に示します。ローカルでの開発環境構築に最適です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
version: '3.8' services: actix-web-app: build: . ports: - "8080:8080" networks: - app-network restart: unless-stopped networks: app-network: driver: bridge |
設定項目の説明
| 項目 | 値 | 補足 |
|---|---|---|
| ports | "8080:8080" |
ローカルポートとコンテナ内ポートをマッピング。Actix Webのデフォルトポートは8080です。 |
| networks | app-network |
サービス間通信用ネットワーク名。bridgeドライバで構成されます。 |
| restart | "unless-stopped" |
コンテナが停止した場合でも自動再起動する設定です。 |
docker-compose.ymlの標準記述を守ることで、他メンバーとの協業やCI/CDでの利用がスムーズになります。
デプロイ後の検証方法
Dockerコンテナが正しく起動したとしても、アプリケーション自体の動作確認は必須です。特にdocker logsコマンドとヘルスチェックエンドポイントのテストを重視してください。
コンテナログの確認手順
以下のようにdocker logsコマンドで出力情報を取得し、異常がないかを確認します。
|
1 2 |
docker logs actix-web-app |
- エラーメッセージのチェック: ログに
error:やpanic!などのキーワードがあれば、デプロイ時の問題がある可能性があります。 - 初期処理確認: Actix Webアプリが正しく起動し、リスナーがポートを待機しているかを観察します。
ヘルスチェックエンドポイントのテスト
Actix Webアプリでは、以下のようなヘルスチェックAPIを作成しておくことを推奨します。
|
1 2 3 4 5 |
#[get("/health")] async fn health_check() -> impl Responder { HttpResponse::Ok().body("OK") } |
このエンドポイントをcurlやブラウザでアクセスし、レスポンスが200 OKであることを確認します。
ヘルスチェックは自動リトライや負荷分散に活用可能で、運用の安定性向上に貢献します。
AWS Lightsail連携手順
AWS Lightsailは、クラウド上でのコンテナデプロイに最適なサービスです。DockerイメージをLightsailに接続する手順とセキュリティ設定について解説します。
Dockerイメージのリモートデプロイ設定
-
AWS Lightsailコンソールへアクセス
AWS管理コンソールから「コンテナ」メニューを開き、必要なサービスを選択してください。 -
新しいコンテナの作成
「新規コンテナを作成」をクリックし、以下のように情報を入力します。 -
名前:
actix-web-container（任意） -
イメージ名:
your-registry/actix-web-app:latest（Docker Hubなどに公開済みのイメージを使用） -
セキュリティグループの設定
- 入力規則でポート
8080を許可するルールを追加します。 - ソースIPは、公開アクセスが必要であれば「全世界」を選択し、限定したい場合はCIDR形式で指定してください。
LightsailではDockerイメージを直接アップロードすることはできず、レジストリ経由でのプル操作が必須です。事前にイメージをビルドしてプライベート/パブリックなレジストリに公開しておく必要があります。
Dockerデプロイの実践ガイド
これまでに説明した手順を踏まえ、Actix WebアプリケーションをDockerでデプロイする一連の流れを整理します。以下のステップに従うことで、効率的なリモートデプロイが可能になります。
-
RustとDockerバージョンの確認
rustc --versionとdocker --versionで環境の最新性を確認します（実際には最新情報かは別途検証が必要です）。 -
マルチステージビルドのDockerfile作成
上記テンプレートを参考に、アプリケーション専用のDockerfileを作成してください。 -
docker-compose.ymlでの環境構築
docker-compose up -dコマンドでローカル環境のテストを実施します。 -
AWS Lightsailへのコンテナイメージアップロード
Docker HubやECRなどのレジストリにイメージをプッシュし、Lightsailコンソールからデプロイを行います。 -
アプリケーション動作確認と監視設定
ヘルスチェックエンドポイントテストを行い、セキュリティグループの変更やログ収集など運用準備を行います。
まとめ
DockerによるActix Webアプリケーションのデプロイには、以下のようなキーポイントがあります。
- マルチステージビルドでイメージサイズを最小限に抑える
docker-compose.ymlでローカル環境構築とネットワーク設定を行う- ヘルスチェックAPIでアプリの動作確認を自動化する
- AWS Lightsailなどでリモートデプロイを実現する
この記事で紹介した手順を参考に、Dockerデプロイを試してみてください。