↓ 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
初回起動のみ、データがインポートされます。
ちなみに上記2行目のコマンドにて 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 ファイル内のバインドマウント記述を削除しておきます。
: <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 ディレクトリ
なにかプラグインを導入している場合のみ移行が発生します1。
プラグイン未導入の場合は、README ファイルあるだけで、ほぼ空っぽの状態。
files ディレクトリ
チケットや Wiki などに貼り付けた画像や添付ファイルが格納されています。
大抵の場合は何かしら入っているはずなので、必ず忘れずに移転しましょう。
public/themes ディレクトリ
サイト自体に個別のテーマ(デザインのカスタマイズ)を設定している場合、こちらのディレクトリにテーマが格納されています2。
移行例
以下は、files ディレクトリの移行コマンド例です3。
$ 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 / の中身を以下の通り、すべて差し替えます。)
: <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 機能の動作確認。
- 添付されている画像ファイルなどが、正しく反映されているか。
- プラグインの動作確認(導入している場合のみ)
- メール送信などの各種連携4。
最後の記事(参考・謝辞)に続きます。
↓ 5/5 引用・謝辞
参考・引用
-
プラグインについては、バージョンアップの伴うリプレースの場合、正しく動作しなくなる可能性がある。その場合はリプレース作業の過程で、プラグインのバージョンアップなど、個別の対応が必要になる。 ↩
-
テーマについてもプラグインと同様、バージョンアップの伴うリプレースの場合、正しく動作しなくなる可能性がある。その場合はリプレース作業の過程で、個別の対応が必要。 ↩
-
移行データの取得状態などによって、ファイル名・ディレクトリ名・オーナー・グループが異なる。そのため実際は、適宜コマンド内容などを変更する必要あり。 ↩
-
当方利用 Redmine システムではメール送信や Git の連携など、一部追加の修正が必要なありました。しかしながら、これらについては Docker 云々とは離れた内容であるため、手順等については記事省略しています。 ↩