docker-composeによる環境構築に対応

[m-pyon23]

概要(Overview・Refs Issue)

docker-composeを用いたスムーズな開発環境構築への対応。
dockerコマンドと比較して、よりポートやボリューム設定等の共有も簡単かつ確実になるため。

方針(Policy)

基本方針

4.0開発者向けドキュメントの「Dockerを使用してインストールする」の内容を基本的に再現する。

• 参照ドキュメントバージョン： EC-CUBE/doc4.ec-cube.net@8740f0c

上記「Dockerを使用してインストールする」との相違点

以下の点に関しては利便性を考慮し、マウントの対象を変更しています。

[従来のマウント対象]

/app, /html, /srcのみを同期

[本対応でのマウント対象]

パフォーマンス影響の大きい/var,/vendor以外の全てを同期

[メリット]

• ローカル上で編集できなかった.env等を編集可能になる
• コンテナを破棄可能な状態にできる
  • ホストとコンテナ間におけるファイルの乖離を極力無くすことで、起動/停止(start-stop)だけでなく、生成/破棄(create-remove, up-down)を行うことが出来るようになる(エフェメラルに保つ)

利用方法

Docker Composeを使用してインストールする

前提として、 Docker Desktop のインストール{:target="_blank"} が必要です。

• 初期状態では SQLite3 を使用します
• ローカルディレクトリをマウントします

cd path/to/ec-cube

# コンテナの起動 (初回のみビルド処理あり)
docker-compose up

# 初回はインストールスクリプトを実行
docker-compose exec ec-cube bin/console eccube:install

2回目以降の起動時も同様のコマンドを使用します。

# コンテナの起動
docker-compose up

# コンテナの停止
docker-compose down

各種サービスの使用

EC-CUBE 4のWebサーバを含め、以下のサービスが簡単に起動できるようにしています。

サービス名	概要
ec-cube	EC-CUBE 向けPHP Webサーバ
mysql	MySQLデータベース
postgres	PostgreSQLデータベース
mailcatcher	MailCatcher デバッグ用SMTPサーバ

コンテナの起動時にサービス名を列挙することで、各種サービスを起動出来ます

# 例：EC-CUBEとMySQLとMailCatcherを起動する
docker-compose up -d ec-cube mysql mailcatcher

# 省略した場合はすべてのサービスが起動します
docker-compose up -d

各種サービスと連携させる場合は、以下の通り設定が必要です

メール送信を使用する場合

.env にて MAILER_URL=smtp://mailcatcher:1025 としておく

localhost上(デフォルトポート:1080)で構築した場合、以下URLにてアクセスします。

http://localhost:1080

PostgreSQL を使用する場合

.env にて DATABASE_URL=pgsql://dbuser:secret@postgres/eccubedb としておく

データベーススキーマを初期化していない場合は、以下を実行する

docker-compose exec ec-cube composer run-script compile

MySQL を使用する場合

.env にて DATABASE_URL=mysql://dbuser:secret@postgres/eccubedb としておく

データベーススキーマを初期化していない場合は、以下を実行する

docker-compose exec ec-cube composer run-script compile

ファイルの同期

docker-composeを用いてインストールした場合、ホストのローカルディレクトリとコンテナ上のファイルは同期します。.env等の設定ファイルについても、ホスト上のファイルを直接編集します。

なお、一部環境において著しいパフォーマンスの劣化が発生する場合があるため、以下のフォルダは同期の対象から除外しています。

• /var
• /vender

これらについてはvolumeを用いてパフォーマンスを損なわない形で永続化しています

実装に関する補足(Appendix)

Dockerfile内での一部インストールのスキップについて

現状Dockerfile内でDBのマイグレーションまで行ってしまっているため、この時点で起動していないMySQLやPostgresアクセスできずビルドが失敗してしまいます。
そのため、環境変数の指定で該当のインストールスクリプトをスキップ可能とすることで対応しています。

https://github.com/m-pyon23/ec-cube/blob/51372d5ca55b4397d41cbe5d88fd1df45bfa0cec/Dockerfile#L84-L90

# Dockerfile

# trueを指定した場合、DBマイグレーションやECCubeのキャッシュ作成をスキップする。
# ビルド時点でDBを起動出来ない場合等に指定が必要となる。
ARG SKIP_INSTALL_SCRIPT_ON_DOCKER_BUILD=false

RUN if [ ! -f ${APACHE_DOCUMENT_ROOT}/var/eccube.db ] && [ ! ${SKIP_INSTALL_SCRIPT_ON_DOCKER_BUILD} = "true" ]; then \
        composer run-script installer-scripts && composer run-script auto-scripts \
        ; fi

https://github.com/m-pyon23/ec-cube/blob/51372d5ca55b4397d41cbe5d88fd1df45bfa0cec/docker-compose.yml#L23-L29

# docker-compose.yml

  ec-cube:
    build: 
      context: .
      args:
        # ビルド時のECCubeインストールスクリプトをスキップする場合にtrueを指定する。
        # ビルド時点でDBサーバの起動や接続が出来ない、という場合等にエラーとなるため。
        SKIP_INSTALL_SCRIPT_ON_DOCKER_BUILD: "true"

この時はキャッシュ作成・DBマイグレーションのため、初回のコンテナ作成後にeccube:install、もしくはそれに準じるコマンドを実行する必要があります
(1度実行した後は/varvolume内にキャッシュが永続化されている状態になるため、再度の実行は不要)

ディレクトリのマウント方法について

ローカルのフォルダを全てマウント対象にした上で、除外したい部分(/var,/vendor)のみvolumeに格納するよう指定することで、高コストなローカルとの同期を切り、低コストなvolume上で永続化するようにしています。

https://github.com/m-pyon23/ec-cube/blob/51372d5ca55b4397d41cbe5d88fd1df45bfa0cec/docker-compose.yml#L33-L37

# docker-compose.yml

    volumes:
      - ".:/var/www/html:cached"
      ### 同期対象からコストの重いフォルダを除外 #####################
      - "var:/var/www/html/var"
      - "vender:/var/www/html/vendor"

テスト（Test)

• 従来記載のDockerコマンドを直接使用する方法でもイメージのビルドとコンテナ起動ができることを確認
• docker-composeで起動した環境をブラウザより目視確認
• mysql,postgresの疎通及びCRUD動作確認（会員登録、商品登録）
• mailcatcherの疎通及び動作確認（会員登録）
• Docker for Windows環境において大きなパフォーマンス低下が起こらないこと
  +（Docker for Mac環境で特に低下しやすい認識のため、お持ちの方に確認をお願いしたいです）

相談（Discussion）

1. 環境変数類の記述場所

一般的にはdocker-compose.ymlで使用する環境変数(各種ポートマッピングや、MySQLコンテナで作成するDB情報等)は.envファイル内に記載するものですが、追加しても良いでしょうか？

現状はとりあえずdocker-compose.ymlに直接記載しています。

2. Dockerfile内のインストールスクリプト回避の是非

前述の通り、Dockerfile内でcomposer run-script installer-scriptを実行する場合、イメージビルドdocker-compose buildの段階でDBに接続出来ないとエラーになるという状態になり、DBコンテナを活かせないため、環境変数による回避手段を設けました。

若干力業感があるため、何か他に良い手段があれば検討したいです。

※本来であれば、そもそもDBマイグレーションやキャッシュ生成等はイメージのビルド時ではなく、コンテナの初回起動時にdocker-entrypoint-initdb.dのようにENTRYPOINTで実施したりするのが適切かと思います。

マイナーバージョン互換性保持のための制限事項チェックリスト

• 既存機能の仕様変更
• フックポイントの呼び出しタイミングの変更
• フックポイントのパラメータの削除・データ型の変更
• twigファイルに渡しているパラメータの削除・データ型の変更
• Serviceクラスの公開関数の、引数の削除・データ型の変更
• 入出力ファイル(CSVなど)のフォーマット変更

レビュワー確認項目

• 動作確認
• コードレビュー
• E2E/Unit テスト確認(テストの追加・変更が必要かどうか)
• 互換性が保持されているか
• セキュリティ上の問題がないか

[m-pyon23]

OSS活動初心者です。ご指摘など何卒よろしくお願いします

[kiy0taka]

@m-pyon23 マージさせていただきました。ありがとうございました！
またのPRお待ちしています。