はじめに

Redmine3.2からのバージョンアップ（Redmica1.2へ）の時の対応内容です
この記事は非常に長いです

概要と調査・検討 / 構築 / 移行 / 番外編のうちの、概要と調査・検討です

記事の全体構成

バージョンアップ対象の環境

利用しているRedmineのバージョンは古く、Redmine3.2.0
その昔、Redmineは2008年から運用しており、何回かバージョンアップしてきている
バージョンアップ前のミドルウェア構成（Apache2.4 + Redmine + MySQL5.7）
ハードウェア
- オンプレ、VMWare上で稼働
Redmineは必須システムに近い存在になりつつある
- みんな見るwiki、作業時間から請求情報、バグ管理票の自動生成、プロジェクト数300超え

利用してきたバージョン等の変移

時期	Redmine	OS他
2008	Redmine1.1.3	CentOS
--	Redmine2.2.1	CentOS6.2(Final) / Apahce2.0 ,MysQL5.X
2016	Redmine3.2.0	CentOS 7.2.1511, Apache2.4, MySQL 5.7.12
2021	Redmica1.2	*1) CentOS 7.9.2009, Apache2.4, MySQL 5.7.33

*1) バージョンアップ後の最終的な構成

バージョンアップに合わせてクラウド利用の検討

クラウドを使うならばAWS一択（他はノウハウもなければ経験にもならない）
クラウド移行は敷居が高い（外部からアクセス不可で閉ざされた社内GitLab, SVNとの連携, 社内端末からのDBへのデータアクセスがある）
publicサブネットでssh公開させないため、データアクセスのために踏み台相当を用意し、踏み台を経由してアクセスする場合に、Excel等 ODBCからID、パスワード認証使ってアクセスできず、SSH経由に変更などの対応をしなければならない。
踏み台サーバー（EC2,Workspaces）相当にWindows + Microsoft Officeを使い、社内端末から直接のデータアクセスを不可にすることも考えられる

バージョンアップ2ステップ

ハードウェア変わらず
Redmine4.1にアップし、それからRedmica1.2.1 にバージョンアップ
移行少し前にRedmine4.2がリリースされたが、Redmine4.2は見送りました。
Redmica1.2ではRedmine4.1に対するアップデートが先に取り込まれている（Redmine4.2に入る不具合修正や機能が早めに取り込まれている）。

進め方

現状調査
- 使ってるプラグイン、構成（RedmineとデータベースとRailsを実行するApache）
環境構築
- 同一環境をバージョンアップするにも事前の検証やリハーサル
- Redmine4.1を動かせる環境構築
バージョンアップ・移行方法
- マイグレーション（Redmine本体のマイグレーション）、プラグインでのマイグレーション
テスト
- 運用上支障のないように確認しておく
バージョンアップリハーサル
- 手順の確認、停止や切り替え時間の確認
移行
- 実際のバージョンアップ

現状調査

インストールしているプラグイン、Redmineの画面とpluginsディレクトリで確認する
cronなどの実行有無と実行内容
バックアップ方法
ディスクスペースの空きと今後の増加傾向の予測

バージョンアップ前

ミドルウェア等	バージョン	他
apache	2.4.6-40.el7.centos.1	nginxは未使用
mysql	5.7.12
git	git.x86_64 0:1.8.3.1-5.el7
Ruby	2.2.3
Phusion	Passenger 5.0.28

バージョンアップ後

yum update実施でバージョンアップ含む

ミドルウェア等	バージョン	他
apache	2.4.6-97.el7.centos	nginxは未使用
mysql	5.7.33
ruby	2.6.6
Phusion Passenger	6.0.7

環境構築

OSから新規構築、既存OS利用（既存のVMWareでクローンする）が考えられる（後述参照）
移行後のバージョンでのRedmineが動く環境を作成
- バージョンアップ検討作業時の最新はRedmine4.1のため、それが動く環境を用意する

移行先の環境をつくる

環境移行は、以下から考えた

a）現行環境を停止して、バージョンアップを行う
b）現行環境をコピーしてバージョンアップ環境を別に構築しておき移行する
c）新環境をOSからインストールして新環境に移行する
d）新環境をOSからインストールしてRedmine関係は dockerを使いコンテナ化（Redmine本体とApache、MySQL）する

検討

a）は停止時間が長くなる、OS停止してスナップショット作成後に作業し、切り戻しするならばVMWareのスナップショットを使う。テストしきれない。
c）CentOSを利用しているが、EOLはCentOS8は2021年末、CentOS7は2024年6月、Stream8 は2024年5月、7とStreamは同じじくらいの時期にくる。現状の調査がけっこうある（後から判明するssh鍵認証、外部との連携　等、DNSやNTP等の対応もある、バージョン以外の作業ボリュームが多い）
d）のdocker利用は、見送りました。
- Windows10のWSL2でRedmine4.1は試しに動かして動作した
- cron（リマインダーメール、Gitリポジトリ連携、svnリポジトリ連携）、サーバー証明書、外部ディレクトリ、外部からのhttp/https以外の接続、サーバの使用メモリ、バックアップからの復旧、ログ出力とローテーション、ssh鍵認証などの対応を検討して代替をしなければならないため作業量が多くなる
- コンテナを使う場合は２つ（ApacheとRedmineのコンテナ、MySQLのコンテナ）の想定
- そもそも dockerコンテナ内にsshで入る作業自体論外
今回では、b）を使用。環境自体は、VMware上で稼働しているため、クローンが用意であること、スナップショットを使って検証や構築がしやすい。移行停止中ならば切戻しがしやすい

バージョンアップ時の考慮事項

バージョンアップは良い機会なので見直しできる点は合わせて行う。

本体 Redmineの動作確認
データベースやRubyやRuby On Rails としての動作確認はしない
利用しているプラグインの対応
- 動くか
- 代替あるか
- 利用していないプラグインがあればプラグインを導入しない
Redmine側から外部にアクセスする
- Redmineでチケットが作成や更新された場合に Slackやmattermostに通知するような場合はローカルのIPv4アドレスで動作確認が可能
rakeコマンドを実行して何らか行う場合の確認、メール送信は検証用環境では実運用データ使う場合はメールアドレスは影響のないメールアドレスに更新しておく
bundle exec rake redmine:send_reminders days=3 RAILS_ENV=production のようにリマインダーメール送信している場合
```
mysql コマンドでユーザredmine、データベースredmineに接続して
> mysql -u xxx -p redmine
パスワード入力

メールアドレス変更を実行
> update email_addresses set address ='your-acount@yourdomain';
```
Redmineに対して外部からアクセスがくる
- 他のサービスとの連携でRedmineに対し何らか処理が来る、APIが呼ばれる　そういった場合は検証用のドメイン等を利用してテストを実施する。例えば、testrail があり、それはRedmineのチケットを自動で作成されるものがあり、RedmineのAPIをたたきにくる。

バージョンアップ・移行の試し

VMWareでクローンした後の環境では、同じくVMWare上にあるため検証が自由にできる
スナップショットを利用することで環境のリセットが容易（yum updateでの失敗、Passenger等のライブラリの入れ直しがしやすい、DBマイグレーションを手軽に戻せる、バージョンアップ作業のリハーサルができる）
docker使っている場合も同様に環境の再構築が容易
おそらく、AWSだとEC2インスタンスならばAMIの利用、RDSの場合はバックアップを消さない・S3に保持しておく

プラグインの移行

プラグインは再選定する機会なので見直しも進める
プラグインは新環境でgit clone または release tagsからダウンロードする
redmine_slack プラグイン
- Redmine Messenger を使うように変更可
- 既にRedmine Messengerは使っているが、redmine_slack プラグイン利用の設定が残ったまま
Redmine Code Review plugin は最新を利用
- 当該プラグインは過去に使っていた、現在進行中ではないため、導入しないことでも対応可
- Gitは社内のGitLab 使っていることが多いため Merge request 等が良いと考える
Redmine Default Custom Queryは最新を利用
- チケット一覧表示のクエリをカスタマイズして、それをデフォルトにするケースはどれくらいあるのかは不明
- 自身で作成したカスタムクエリを他の人が使えるので、個人ごとに必要なチケット一覧は異なるように思う

テーマの移行

独自のfaviconを利用
UI・使いやすさが増す、farend_fancy を使っているため、最新を利用する。
farend_fancyをさらにチケット一覧で独自の取消線にしている（ステータスが完了は文字色が薄くなるが、さらに完了を取消線にしている）ため、

Redmine、pluginのバージョンアップ（移行）とは別に作業したこと

yum update
データベースとテーブルの文字コード変更
- Redmine3.2より前から MySQLでutf8を使用してきた、絵文字等が使えないためutf8mb4に変える。svn連携でファイル名に絵文字があるため連携がエラーになるための対応も含む。
css書き換えをしていたものを pluginで対応するように変更
- 本体のcssをoverrideして対応している、これまでと変えないようにするためにcss変更しているが、昨今あまり意味がなさそう、見た目ではテーマ適用で十分ではと思われる。
ディスク容量が切迫してくるためVMWareでディスク追加し、filesの場所を変更
- 何年も運用しているため、添付ファイルが多い。1ファイルあたりの容量制限はあるが、年間5GB程度は増えており、バージョンアップすることで画面キャプチャ（スクリーンショット）が貼付けが容易になるため添付ファイル利用は増えると予想される。
ログローテーション
- syslog / MySQL / Redmine / Apache（Httpd）
- 先述のディスク容量切迫もありログの保存期間を長期にできていないため、長期保存できるようにする

Redmineのバージョンアップ（Redmine3.2 -> 4.1とRedmica1.2への切り替え）その１（概要と調査・検討）

はじめに

記事の全体構成

バージョンアップ対象の環境

バージョンアップに合わせてクラウド利用の検討

バージョンアップ2ステップ

進め方

現状調査

バージョンアップ前

バージョンアップ後

環境構築

移行先の環境をつくる

環境移行は、以下から考えた

検討

バージョンアップ時の考慮事項

バージョンアップ・移行の試し

プラグインの移行

テーマの移行

Redmine、pluginのバージョンアップ（移行）とは別に作業したこと