Contents
Rails 7アプリケーションのDockerデプロイに必要な準備と環境構築
Rails 7アプリケーションをDockerで効率的にデプロイするには、開発環境と生産環境での整合性が不可欠です。特にRuby 3.x対応とYarn/Webpackerの導入状況を事前に確認することで、後工程のトラブルを防ぎます。以下に具体的なチェックポイントを紹介します。
Ruby 3.x対応確認
Rails 7はRuby 3.0以上が必須であり、プロジェクトのGemfileやrails new時のバージョン指定に注意が必要です。
- 確認手順
ruby -vで現在のRubyバージョンを確認する- Gemfileに
ruby '3.x'と記述されているかチェックする .ruby-versionファイルが存在し、適切なバージョンを指定しているか確認
注意：2023年現在、Rubyの公式サポートは3.1以降に移行しており、3.0以下の使用は推奨されません。
Yarn/Webpackerの導入状況チェック
Rails 7ではWebpackerがデフォルトで導入されており、静的アセットのバンドルにはYarnが必要です。
- 確認手順
yarn --versionでYarnのバージョンを確認するbin/webpack-dev-serverが正しく動作するかテストpackage.jsonに必要な依存関係が含まれているかチェック
| 項目 | 確認方法 | 期待値 |
|---|---|---|
| Yarnバージョン | yarn --version |
v1.22以上（最新はv3.x推奨） |
| Webpackerの状態 | rails webpacker:install実行結果 |
なし（既に導入済み） |
Dockerfileとdocker-compose.ymlの最適な記述例
Dockerイメージの構築では、ベースイメージ選定と多層ビルド構成が効率を左右します。Railsアプリケーション向けにはスリムイメージを使用し、必要最小限のレイヤー分割で軽量化を図ることがベストプラクティスです。
ベースイメージ選定のポイント
Rails 7ではRuby 3.2以上対応のベースイメージが推奨されます。最新の安定版であるruby:3.2-slimや、Node.jsを含むruby:3.2-slim-bookworm-nodeが代表的です。
- 選定ポイント
- パフォーマンスとセキュリティを重視する場合は
slimバージョンを選ぶ - JavaScript処理が必要な場合はNode.js付きイメージを選択
DockerfileでFROM ruby:3.2-slim-bookworm-nodeのように明記
注意：Debian busterは非推奨となるため、
bookworm（Debian 12）やtrixie（Debian unstable）を選択してください。
多層ビルド構成例
多層ビルドでは、依存関係のインストールとアプリケーションのコピーを分離することで、ビルドキャッシュの効率化が可能になります。
|
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 28 29 |
# ビルド用イメージ（依存関係のインストール） FROM ruby:3.2-slim-bookworm-node as builder RUN apt-get update && apt-get install -y \ build-essential \ nodejs WORKDIR /app COPY Gemfile Gemfile.lock ./ RUN bundle install --without production COPY package.json yarn.lock ./ RUN yarn install COPY . . RUN rails assets:precompile # 実行用イメージ（最小限の環境構築） FROM ruby:3.2-slim-bookworm WORKDIR /app COPY --from=builder /app/vendor/bundle /app/vendor/bundle COPY --from=builder /app/public /app/public COPY --from=builder /app/config /app/config COPY --from=builder /app/db /app/db COPY --from=builder /app/lib /app/lib CMD ["rails", "server", "-b", "0.0.0.0"] |
注意：
bundle installやyarn installはビルドステージで一度実行し、実行イメージでは不要なパッケージを排除する。
Rails 7特有の環境設定対応策
Rails 7のアセットパイプラインとWebpackerとの連携には、Dockerのビルドフローに配慮した設定が求められます。特にNode.jsバージョン管理やYarnのキャッシュ処理が重要です。
Webpackerとの連携方法
WebpackerはJavaScriptアセットをバンドルするためのツールですが、Docker内で動作させるには以下のような設定が必要です。
- 手順
package.jsonに"scripts": { "build": "webpack --mode production" }を追加- Dockerfileで
RUN yarn run buildを実行し、生成されたファイルをpublic/packs以下へ配置
Node.jsバージョン管理
YarnとWebpackerの互換性を保つにはNode.jsのバージョンに注意が必要です。
| Yarnバージョン | 推奨Node.jsバージョン |
|---|---|
| v1.22 | v20.x（LTS） |
| v3.x | v20.x |
重要：
nvmではなく、DockerイメージのベースにNode.jsを含むバージョンを選択する方が安定性が高いです。
多層イメージ構築時のベストプラクティス
多層ビルドで効率化と軽量化を実現するには、レイヤー分割とキャッシュ戦略が鍵となります。以下の手順に従うことで、リデュースされるイメージサイズの実測値は35%程度削減可能になります（2023年現在の平均）。
ステージごとのレイヤー分割例
下記のようにビルドステージを分割し、各段階で必要なパッケージのみをインストールします。
- 依存関係インストールステージ
Gemfileとpackage.jsonのコピー-
bundle installとyarn installの実行 -
アプリケーション構築ステージ
- アセットコンパイル（
rails assets:precompile） -
テストコードや開発用ファイルの排除
-
最終イメージ構築ステージ
- 必要なディレクトリのみをコピーし、最小限の環境で起動
キャッシュ効率化の工夫
COPYコマンドでファイルのコピー順を調整（Gemfileなど依存関係は最初にコピー）- ビルドキャッシュが有効になるようにレイヤー名を統一（例：
builder,productionなど）
実測値：2023年調査では、多層構築の導入によりイメージサイズは平均35%減少。
CI/CD連携時の実装サンプルと注意点
GitHub ActionsでDockerイメージをビルド・テストする際には、リポジトリの変更に応じた自動化が推奨されます。また、Artifact管理も重要です。
GitHub ActionsでのDocker Build例
以下は.github/workflows/build.ymlのサンプルです。
|
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 28 |
name: Docker Build on: push: branches: [ main ] pull_request: branches: [ main ] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Set up Docker Buildx uses: docker/setup-buildx-action@v2 - name: Login to Docker Hub uses: docker/login-action@v2 with: username: ${{ secrets.DOCKER_HUB_USERNAME }} password: ${{ secrets.DOCKER_HUB_TOKEN }} - name: Build and push Docker image uses: docker/build-push-action@v5 with: context: . file: ./Dockerfile push: true tags: your-username/rails7-app:latest |
Artifact管理のベストプラクティス
CI/CDパイプラインでは生成されたイメージやログをArtifactとして保存することが推奨されます。
- 手順
- GitHub Actionsで
artifactsステップを追加し、ビルド結果を保存 - テスト失敗時にアーカイブを確認可能に設定
注意：Docker Hubのプライベートレジストリ利用時は、シークレット管理に注意。
セキュリティ強化策と運用最適化
生産環境でのセキュリティ確保には、non-rootユーザーの設定とネットワークポリシーの設計が不可欠です。
non-rootユーザー設定方法
Dockerイメージでroot権限を持つコンテナを起動するとセキュリティリスクがあります。以下の手順でnon-rootユーザーを作成します。
-
Dockerfileに以下を追加：
Dockerfile
RUN useradd -ms /bin/bash railsuser
USER railsuser -
Gemfileやpackage.jsonの読み込み時にユーザー権限が不足しないように注意（例：/appディレクトリに適切なパーミッションを設定）
ネットワークポリシーの設計
Docker Composeでネットワークセキュリティを強化するには、以下のように設定します。
|
1 2 3 4 5 6 7 |
networks: app-network: driver: bridge ipam: config: - subnet: 172.20.0.0/24 |
- 対策
- コンテナ間通信を制限する
--networkオプションの活用 - 外部アクセスが必要なポートのみ公開（例：
ports: "3000:3000"）
注意：生産環境ではDockerデーモンのセキュリティ設定も併せて確認する必要があります。