eccube-docker · v1.0.11 · Apache-2.0

EC-CUBE 4 のセキュリティパッチを、出たその日に当てる。
本体も PHP も、1 コマンドで。

脆弱性の告知が来ても、当てるのが怖くて何か月も放置される。原因は「上げると壊れるかもしれない」 「戻し方が分からない」の 2 つです。ここでは本体をイメージに焼き、あなたのコードだけを git で 持つ。だから上げるのはイメージを引き直すだけで、退避してから確かめ、 ダメなら何も変えずに止まる。インストールもサーバー移転も同じ考え方で 1 コマンドにしました。

始め方 はじめての人のための手引き GitHub お問い合わせ / Issue

パッチはその日のうちに

EC-CUBE 本体のパッチ（4.3.1 → 4.3.2 など）も、PHP や拡張の更新も、やることは同じ 2 つ。プラグインの移植が要るのはメジャー・マイナー（4.3 → 4.4）だけです。

1

環境を新しくする

bin/self-update.sh

PHP・拡張・compose・スクリプトが新しいリリースに揃う。差分は git で見えるので、何が変わるか分かってから進める。

2

本体を上げる

bin/upgrade.sh ~4.3.0 --prod

退避 → 新しい本体でプラグインが読めるかを稼働中に触る前に確認 → メンテナンス表示 → migration → 疎通。途中で失敗したら何も変えずに止まる。

速い理由は 1 つ。あなたが直したものと本体が、別々に更新される

EC-CUBE の中身を直接編集した環境は、上げるたびに「どこを直したか」の調査から始まります。ここでは置き場所が最初から分かれています。

あなたのもの — git で持つ

  • カスタマイズした PHP（app/Customize/）
  • 直したテンプレート・テーマ（app/template/）
  • 独自の CSS / JS（html/user_data/）
  • プラグイン、migration、設定（app/Plugin/ ほか）

パッチを当てても1 ファイルも触られない。上書きされる心配がないので、当てる前に「どこを直したか」を思い出す必要がない。

本体 — イメージで入れ替える

  • EC-CUBE 本体、vendor
  • PHP、拡張、php-fpm、nginx

手で編集しないので、新しいイメージを引き直すだけで新しくなる。だからパッチが出たその日に当てられる。本体を編集した環境ではこれができない。

丸ごと写さない、が守られる テンプレートは「直すファイルだけ」を置く決まり。丸ごと写すと、上げたときに古いほうが勝ち続けて直したはずの不具合が戻ります。bin/theme.sh diff と bin/plugin.sh template diff が、本体側で変わったファイルを上げたあとに挙げます。

バージョンを変えるのは、それぞれ 1 コマンド

PHP・EC-CUBE 本体・この環境自体は、別々に上げ下げできます。どれもデータ（受注・会員・商品・画像）はそのままです。

変えたいものやることかかる時間
PHP
8.2 → 8.3 など		 .env のタグの php8.2 を php8.3 に書き換えて
docker compose pull ec-cube && docker compose up -d		 約 20 秒
戻すのも同じ
EC-CUBE 本体
4.3.1 → 4.3.2 など		 bin/upgrade.sh ~4.3.0 --prod 数分
失敗したら何も変えずに止まる
この環境
bin/ や compose		 bin/self-update.sh 1 分
差分を git で見てから commit
PHP だけ変えても本体は動いたまま PHP はイメージの中に、EC-CUBE 本体と vendor はボリュームの中にあります。だからイメージを差し替えても入れ替わるのは PHP だけで、店のデータにも本体のバージョンにも触りません（作り直されるのはアプリのコンテナ 1 つ、約 20 秒）。合わない組み合わせのタグは存在しないので、壊れる前に pull が失敗します。選べる PHP は下の表のとおりです。

こんなところで止まっていませんか

左は実際によく聞く声、右はこの環境がどう片付けるか。ひとつでも当たれば、続きを読む価値があります。

店の担当者 / 引き継いだ人

「脆弱性の案内が来たけど、上げるのが怖くてそのまま。PHP も古いと言われた」 制作会社に頼むと数十万で数週間。自分でやると壊れそうで、戻し方も分からない。

その日に当てる。上げる前に止まる

バックアップを取り、新しい本体でプラグインが読めるかを稼働中の環境に触る前に確かめ、ダメなら何も変えずに止まります。スキーマの差分に「列の削除」が混じっていれば、それも止まる。

bin/upgrade.sh ~4.3.2 --prod

初めて自分で公開する人

「サーバーは借りた。でもドメインと SSL の設定で止まっている。ポートを開けるのも怖い」 A レコード、証明書の更新、ファイアウォール。どれか 1 つ間違えると、サイトが出ないか、危ない状態で出る。

ドメインは Cloudflare Tunnel で。ポートを 1 つも開けない

Cloudflare の画面でトンネルを作り、公開ホスト名に shop.example.com → http://nginx:80 と書く。あとは発行されたトークンを .env に 1 行。サーバー側はポートを開けず、A レコードも証明書も触らない（HTTPS は Cloudflare が終端し、更新も向こうがやる）。既定の公開方式なので、追加の設定はこれだけです。

COMPOSE_PROFILES=tunnel
TUNNEL_TOKEN=eyJhIjoi...   # Cloudflare Zero Trust で発行

引き継いだ人

「前の会社が作ったサイト。直したのに反映されない。何がどこにあるか分からない」 キャッシュを消しても変わらない。エラーも出ない。触るのが怖い。

困ったら 1 コマンド。日本語で理由が出る

本番モードの EC-CUBE は、コードを直しても例外も 500 も出さずに古いまま動き続けます。doctor が残骸の掃除・無効プラグインの検出・キャッシュの組み立て直し・疎通確認までやり、何が悪いかを出します。

本体とあなたのコードは置き場が分かれています。どこを直せばいいかで迷わない。

bin/plugin.sh doctor

レンタルサーバーから出たい人

「共用サーバーで始めたけど、もう上げられない。VPS に移したい。でも画像と DB とテンプレが散らばっている」 移転の手順を検索すると、人によって言うことが違う。

引っ越しは 3 手順

DB・画像・管理画面が書いたファイル・設定の 4 点セットを 1 コマンドで退避。新しいサーバーでは clone → init → restore。同じ手順がどの VPS でも通ります。

bin/backup.sh
# 新しいサーバーで
bin/init.sh && bin/restore.sh backups/<日時>

制作会社 / フリーランス

「案件ごとにサーバーの手順が違う。前と同じにならない。保守が赤字」 本番の反映で毎回ひやひやする。メンテナンス表示を出し忘れる。

直す場所と動かす場所を分け、反映を 1 コマンドに

退避 → メンテナンス表示 → 取り込み → DB 更新 → キャッシュ → 確認 → 解除。失敗したらメンテナンス表示のまま止まり、壊れた画面をお客さんに出しません。どの案件でも同じ手順。

bin/deploy.sh --remote=shop:/srv/myshop

プラグイン開発者

「本番と同じ環境で試したい。テンプレの上書きと更新で毎回悩む」 写しを置いたら、プラグインを更新しても古いほうが勝ち続けた。

入れる・直す・差分を見る、を揃えてある

private リポジトリから clone して install → enable まで 1 コマンド。テンプレは app/template/plugin/ に写して直し、プラグインを更新したら「自分が変えた／上流が変わった／衝突」を分けて出します。

bin/plugin.sh add git@github.com:you/MyPlugin.git
bin/plugin.sh template add MyPlugin admin/config.twig

毎日はこれだけ

直す場所（手元）と動かす場所（サーバー）を分ける。この環境の全部です。

1

手元で直す

bin/init.sh                # 初回だけ。終わると URL とログイン情報が表示される
2

控えを送る

git add -A && git commit -m "何を直したか" && git push
3

サーバーに反映する

bin/deploy.sh --remote=shop:/srv/myshop

手元から送るので、サーバーに git も GitHub の鍵も要りません（最初の 1 回は bin/bootstrap-server.sh が Docker まで入れる）。数分かかります。終わったらお店を開いて目で確かめる。

本番には main の先頭と同じものしか送れません。出る前に「何が出るか」を見せ、プロジェクト名を打つまで何も変えない。見るだけなら --check。

本番には、レビュー済みの main しか出ない

エンジニアが直し、担当者が承認して、本番へ出す。「エンジニアが勝手に出す」と「担当者がうっかり出す」を、別々の壁で止めます。どれか 1 枚が無くても残りは効く。

①

GitHub — 承認が無いと main に入らない

bin/setup.sh protect

PR 必須、担当者（CODEOWNERS）の承認必須、force push と削除の禁止。管理者も例外なし。非公開リポジトリは GitHub の有料プランが要ります（無ければ②③だけで運用）。

②

手元 — main の先頭と同じものしか送れない

bin/deploy.sh --remote=shop:/srv/myshop
  ✗ いまのブランチは feature です。出せるのは main だけ

別のブランチ、コミットしていない変更、push していないコミット。どれか 1 つでも本番へは送らない。何もしなくて効きます。

③

サーバー — 見せて、打たせて、記録する

  コード: 3f2a1c0 → 9b7e4d2（3 コミット）
  ⚠ migration が含まれます
  続けるなら、プロジェクト名 myshop を入力:

y では通しません。指が覚えて通してしまわないように、プロジェクト名を打つ。誰が・いつ・何を出したかは var/deploy.log に残る。

正直に 本番の SSH を持つ人は②③を素通りできます。壁は「うっかり」を止めるもので「故意」は止められない。だから本番の SSH はエンジニアに渡さない、と決めてください。詳しくは 本番デプロイ。

向いている人・向いていない人

正直に書きます。合わない人が使うと、お互いに時間を失うので。

向いている

  • Docker が動く VPS かクラウドで EC-CUBE 4 を運用する（これから移る人も）
  • ドメインと HTTPS を Cloudflare Tunnel で済ませたい（ポートを開けず、証明書の更新から解放される）
  • メールサーバーや DB の設定を手で書きたくない（bin/setup.sh mail / db が質問に答えるだけで、先に試してから書く）
  • 制作会社・フリーランスで、複数の案件を同じ手順で回したい
  • 複数人で運用する（エンジニアが直して担当者が出す。本番には承認済みの main しか出ない）
  • 前任者のいないサイトを引き継いで、まず状況を把握したい
  • プラグインやテーマを作っていて、本番と同じ環境で試したい
  • ターミナルでコマンドを打つことに抵抗がない（Windows は WSL2 の中で）
  • AI に運用を手伝わせたい（Claude Code / Codex 向けの指示書 AGENTS.md が入っていて、やることと絶対にやらないことが書いてある）
  • DB は MariaDB 派でも PostgreSQL 派でも（.env に 1 行。どちらも同梱、外部のマネージド DB も可）

向いていない

  • 共用レンタルサーバー（Docker が動かない）。移るときに戻ってきてください
  • 管理画面だけで全部済ませたい（テンプレートは git で持つ設計です）
  • Windows でコマンドを触りたくない
ひとこと 初回は Redis も非同期メールも無効で、必要になったら .env に 1 行足す設計です。最初から全部入りではありません。

git clone しない始め方

git clone しません。 リリースの中身をもらって、自分専用の非公開リポジトリとして始めます。

# 配布元の最新リリースの中身をもらう（git の履歴は付いてこない）
curl -fsSL https://github.com/kurozumi/eccube-docker/releases/latest/download/eccube-docker.tar.gz | tar -xz
mv eccube-docker-* myshop && cd myshop

# 自分のリポジトリとして始める（非公開で）
git init -b main && git add -A && git commit -m "eccube-docker から開始"
gh repo create myshop --private --source=. --push

# 動かす（配布イメージを引くので数十秒。PHP はタグで選ぶ）
bin/init.sh --image=ghcr.io/kurozumi/eccube-docker/ec-cube:4.3-php8.3
なぜ clone しないか clone だと origin が配布元のままで、あなたのコードを保存する場所が無い。fork は公開リポジトリだと非公開にできない。中身だけもらって自分のリポジトリにするのが、いちばん素直です。この環境自体の更新は bin/self-update.sh が取り込みます。

対応する EC-CUBE

配布イメージを使うと、手元でビルドせずに数十秒で立ち上がります（bin/init.sh --image=… か .env の ECCUBE_IMAGE）。PHP はタグで選びます: 4.3-php8.3 のように書くとその PHP、-php を省くと系列の既定。

系列イメージ（本番はこれ）選べる PHP備考
4.3ghcr.io/kurozumi/eccube-docker/ec-cube:4.38.1† / 8.2 / 8.3推奨
4.2ghcr.io/kurozumi/eccube-docker/ec-cube:4.28.1† / 8.2
4.4ghcr.io/kurozumi/eccube-docker/ec-cube:4.48.2 / 8.3 / 8.4 / 8.5上流の開発ブランチから焼いている。同じものを立てたいなら日付タグで固定

イメージは毎週月曜に焼き直され、PHP と OS のセキュリティパッチが入ります。 †PHP 8.1 は 2025 年 12 月で終了しています。OS のパッチは入りますが PHP 自体の修正はもう出ないので、8.1 でしか動かないプラグインが無ければ 8.2 以上を。太字は -php 無しの既定。PHP を選ぶなら 4.4-php8.5 のように書く。同じものを何度も立てたい人は日付タグ 4.3-20260907、リリース時点なら 4.3-v1.0.11。

DB は MariaDB / MySQL（既定）か PostgreSQL。版は .env の MARIADB_VERSION / PG_VERSION。.env の DB_ENGINE で選び、バックアップも引っ越しも同じコマンドで通ります。手元の DB でも、クラウドのマネージド DB でも。

文書

理由を書かない手引きと、理由を書いた文書の 2 段構えです。

はじめての人のための手引き

登場するものは 5 つ、毎日やることは 3 つ、困ったときは 1 コマンド。理由は書きません。

導入手順

取得から公開まで。.env の中身、公開方式、プラグインの扱い、デザインを直す場所。

バージョンアップ

運用中の店を上げる手順と切り戻し。マイナーをまたぐときに黙って壊れる 3 つの型。

データを失わないために

down と down -v の違い、消えるコマンド、消したときの復旧。

本番デプロイ

誰が・何を・どうやって本番へ出すか。3 枚の壁、--check、記録、緊急時、誰に何を渡すか。

バックアップ / 復元

5 点セット、送り先、暗号化、引っ越し。bin/setup.sh backup が毎日の cron まで入れる。

困ったこと、こう動いてほしいを聞かせてください

一人で使っている限り、この環境は一人分の経験でしか良くなりません。あなたの店で起きたことが、次の人の「黙って壊れる」を一つ減らします。

GITHUB ISSUE · 募集中

不具合・要望・質問は Issue へ

「エラーが出た」「この手順で止まった」「こういう構成で使いたい」。どれも歓迎です。うまく書けなくても構いません。実行したコマンドと出た文字をそのまま貼ってください。

  • 不具合 … bin/plugin.sh doctor の出力と、EC-CUBE と PHP の版
  • 要望 … 今どう困っていて、どう動けば助かるか
  • 質問 … 文書のどこを読んで分からなかったか
Issue を書く これまでの Issue を見る

CONTACT · 構築・引っ越し・バージョンアップの相談

公開できない話はメールで

本番の URL や DB の中身が絡む相談、受託での構築や引っ越し、B2B サイトの構築、プラグイン開発の依頼はメールで受けています。返信は営業日に順次。

info@a-zumi.net

作った人: Akira Kurozumi（a-zumi.net）。EC-CUBE のプラグインを作りながら、この環境で自分の店も動かしています。

メールで相談する