↓ 1/5 はじめに

↓ 2/5 Docker, Docker Compose など基盤構築

↓ 3/5 Nginx, Certbot 導入と SSL 証明書の取得・更新

前回記事の続きです。

この先使用する Compose ファイル（docker-compose.yml）については、前々記事の最後あたりを、Nginx 設定ファイル（vhost-www.example.jp.conf）については、前記事の中央あたりをそれぞれ参照してください。

引き続き、面倒な作業が続きます。

MySQL（初期インポートするの準備 ⇒ 起動）
MySQL（通常起動）
Redmine（通常起動）
データベースのアップグレード
Redmine のファイル群を、移行元から移転。

MySQL（初期インポートするの準備 ⇒ 起動）

最初に作っておくべきディレクトリは、以下の通り。

$ mkdir -p ./docker-entrypoint-initdb.d

ここに初期インポートする .sql ファイルをアップロードします。
準備完了後、mysql を Compose ファイルに則って、普通に起動します。

$ docker-compose up -d mysql
$ docker-compose logs mysql

初回起動のみ、データがインポートされます。

ちなみに上記２行目のコマンドにて MySQL のログが確認できますが、その中に、……

YYYY-MM-DD HH:NN:SS+09:00 [Note] [Entrypoint]: /usr/local/bin/docker-entrypoint.sh: running /docker-entrypoint-initdb.d/XXXXXXXXXXXX.sql

…… というログが記載され、さらにそのあとエラーが続いてなければ、データインポートも成功していると思います。

以降元データベースのバックアップについては、以下の公式サイト等をご確認ください

MySQL（通常起動）

データインポートが完了したら、安全のため、Compose ファイル内のバインドマウント記述を削除しておきます。

docker-compose.yml（抜粋）

    : <snip>
  mysql:
      : <snip>
    volumes:
      ↓↓↓↓↓↓ この行を削除 ↓↓↓↓↓↓
      - ./docker-entrypoint-initdb.d:/docker-entrypoint-initdb.d # データ移行する場合のみ必要、移行終了後マウント削除
      ↑↑↑↑↑↑ この行を削除 ↑↑↑↑↑↑
      - etc_mysql:/etc/mysql
      - var_lib_mysql:/var/lib/mysql
          : <snip>

そして、MySQL を再起動します。
（最後に、インポートデータも削除しておきます。）

$ docker-compose stop mysql
$ docker-compose up -d mysql
$ rm -rf docker-entrypoint-initdb.d

Redmine（通常起動）

$ docker-compose up -d redmine

データベースをアップグレード

リプレースかつ、リプレース前の Redmine バージョンが古い場合は、ここでリプレース後のバージョンのデータベースに更新する。

$ docker-compose exec redmine bundle exec rake db:migrate RAILS_ENV=production

ちなみに自分の環境では、このタイミングでシェルが応答しなくなる場合がありました。
急遽 AWS の CloudWatch にて EC2 の状態を確認したところ、CPU が 100% まで跳ね上がり、バーストクレジットを大きく消費した記録を残したのち、少し待っても、その後のログの取得が取れず。
またシェル応答も引き続き戻ってこなかったのと、再接続もできなかったので、ここでインスタンス再起動しました。
再起動後は、特に不具合ありません。

Redmine のファイル群を、移行元から移転。

リプレースの場合は、ここで Redmine データベース以外のファイルを移転します。
主に移転が必要になるファイルは、redmine ディレクトリ（概ね /usr/src/redmine か /var/lib/redmine など）配下の、以下のディレクトリです。

plugins ディレクトリ

なにかプラグインを導入している場合のみ移行が発生します¹。
プラグイン未導入の場合は、README ファイルあるだけで、ほぼ空っぽの状態。

files ディレクトリ

チケットや Wiki などに貼り付けた画像や添付ファイルが格納されています。
大抵の場合は何かしら入っているはずなので、必ず忘れずに移転しましょう。

public/themes ディレクトリ

サイト自体に個別のテーマ（デザインのカスタマイズ）を設定している場合、こちらのディレクトリにテーマが格納されています²。

移行例

以下は、files ディレクトリの移行コマンド例です³。

$ docker cp redmine.files.tgz redmine:/usr/src/redmine/files  # コンテナ（ボリューム）内に移行データ（圧縮ファイル）格納
$ docker-compose exec redmine bash  # Redmine コンテナのシェルに入る
# cd /usr/src/redmine/files  # Redmine のファイルディレクトリに移動
# tar xvf 20210709.redmine.files.tgz # 移行データを解凍・展開
# chown -R redmine:redmine ./*  # データのオーナー・グループをコンテナのユーザ・グループに変更
# mv var/lib/redmine/files/* .  # 移行元の絶対パスで格納されていたものを展開したので、適切なパスにデータをすべて移動
# rm -rf var  # 移行元の絶対パス（残骸）を削除
# rm 20210709.redmine.files.tgz  # 移行元データ（圧縮ファイル）を削除
# exit  # コンテナから抜ける

Nginx 設定ファイル差替（nginx と Redmine の繋ぎ込み）

Compose ファイルの通り、Redmine は 3000 ポートを開く状態で構築しました。
これを Nginx のリバースプロキシを使って、https（443ポート）に繋ぎ込みます。

"ブラウザ" <== Port 443 (https) ==> "nginx" <== Port 3000 (http) ==> "Redmine"

具体的には Nginx 設定ファイルにの https（SSL）サーバ接続の記述内に、リバースプロキシによるRedmine 繋ぎ込みの内容を反映し、再アップロードします。
（SSL 側 location / の中身を以下の通り、すべて差し替えます。）

vhost-www.example.jp.conf（抜粋）

  : <snip>
server {
    listen        443 ssl;
      : <snip>
    location / {
        proxy_set_header     X-Forward-For $remote_addr;
        proxy_pass           http://redmine:3000/;
        client_max_body_size 500M;
    }
}

設定ファイルを Nginx の設定ボリュームへ格納し、再起動・ログを確認します。

$ docker cp vhost-www.example.jp.conf nginx:/etc/nginx/conf.d/vhost-www.example.jp.conf
$ docker-compose stop nginx
$ docker-compose up -d nginx
$ docker-compose logs nginx

最後にブラウザアクセスにて動作確認します。

http://www.example.jp
https://www.example.jp

特に Redmine の以下の箇所を確認し、問題なければ作業完了となります。

画面表示の確認。
テーマ（デザイン）などをカスタマイズしている場合、適切に反映されているか。
ログインおよび、各画面遷移。チケット発行や Wiki など、Redmine 機能の動作確認。
添付されている画像ファイルなどが、正しく反映されているか。
プラグインの動作確認（導入している場合のみ）
メール送信などの各種連携⁴。

最後の記事（参考・謝辞）に続きます。

↓ 5/5 引用・謝辞

参考・引用

プラグインについては、バージョンアップの伴うリプレースの場合、正しく動作しなくなる可能性がある。その場合はリプレース作業の過程で、プラグインのバージョンアップなど、個別の対応が必要になる。 ↩
テーマについてもプラグインと同様、バージョンアップの伴うリプレースの場合、正しく動作しなくなる可能性がある。その場合はリプレース作業の過程で、個別の対応が必要。 ↩
移行データの取得状態などによって、ファイル名・ディレクトリ名・オーナー・グループが異なる。そのため実際は、適宜コマンド内容などを変更する必要あり。 ↩
当方利用 Redmine システムではメール送信や Git の連携など、一部追加の修正が必要なありました。しかしながら、これらについては Docker 云々とは離れた内容であるため、手順等については記事省略しています。 ↩