![](https://blogimg.goo.ne.jp/user_image/02/27/ce0d02ace7b8f96c247d3421116c2100.png)
いくつかの機能の検証と追加。
1.DBの文字コードの件
前々回のDBデータ移行の作業の際に、設定情報(utf8mb4)と移行情報の書き換え(uft8mb3)に齟齬があるものの、
稼働に支障はない状況の裏付けとして、mariadbの初期データの確認を実施。
ということで、uft8mb3/utf8mb3_general_ci と置換しても良さそうです。
2.データのバックアップスクリプトを作る
以前までの環境(bitnamiのredmineスタック)は、一つのコンテナ内にredmine環境とmariaDB環境を押し込めていたので、
そのコンテナ内でバックアップScriptを作成し、cronで起動していましたが、
今回は、redmineとmariaDBのコンテナが別になるため、同期をとったバックアップを取得するには、
ホスト側で制御するのがよさそうです。
ということで、手順としては
(1) docker-compose でredmineのコンテナを停止し、mariaDBのコンテナでデータをバックアップ
(2) redmineのVolumeにある/filesディレクトリと/public/pluginsディレクトリをバックアップ
(3) 必要に応じてローテーション(過去分の削除)
(4) redmineコンテナの再開
でしょうか。
ホスト側でcronで指定しておけば、自動化できますね。
3.プラグインの稼働確認
以前確認したPlugin以外に、稼働するものを見つけたので記録に残します。
これで何とか移行作業は終了とできそうです。ホッ。。
1.DBの文字コードの件
前々回のDBデータ移行の作業の際に、設定情報(utf8mb4)と移行情報の書き換え(uft8mb3)に齟齬があるものの、
稼働に支障はない状況の裏付けとして、mariadbの初期データの確認を実施。
# docker exec -it (mariaDBコンテナ名) bash -c "/opt/bitnami/mariadb/bin/mysqldump -u bn_redmine bitnami_redmine > /bitnami/mariadb/data/dbbkup/dbdump_202212.sql" # more /var/lib/docker/volumes/datacont_mariadb_data/_data/data/dbbkup/dbdump_202212.sql -- MariaDB dump 10.19 Distrib 10.6.11-MariaDB, for Linux (x86_64) -- -- Host: localhost Database: bitnami_redmine -- ------------------------------------------------------ -- Server version 10.6.11-MariaDB /*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */; /*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */; /*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */; /*!40101 SET NAMES utf8 */; /*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */; /*!40103 SET TIME_ZONE='+00:00' */; /*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */; /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */; /*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */; /*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */; -- -- Table structure for table `ar_internal_metadata` -- DROP TABLE IF EXISTS `ar_internal_metadata`; /*!40101 SET @saved_cs_client = @@character_set_client */; /*!40101 SET character_set_client = utf8 */; CREATE TABLE `ar_internal_metadata` ( `key` varchar(255) NOT NULL, `value` varchar(255) DEFAULT NULL, `created_at` datetime(6) NOT NULL, `updated_at` datetime(6) NOT NULL, PRIMARY KEY (`key`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_general_ci; /*!40101 SET character_set_client = @saved_cs_client */; ・・・ # more /var/lib/docker/volumes/(mariaDBのコンテナ用Volume名)/_data/data/dbbkup/dbdump_202212.sql | grep utf8mb ・・・ ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_general_ci; ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_general_ci; ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_general_ci; ) ENGINE=InnoDB AUTO_INCREMENT=10 DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_general_ci; ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_general_ci; ・・・
ということで、uft8mb3/utf8mb3_general_ci と置換しても良さそうです。
2.データのバックアップスクリプトを作る
以前までの環境(bitnamiのredmineスタック)は、一つのコンテナ内にredmine環境とmariaDB環境を押し込めていたので、
そのコンテナ内でバックアップScriptを作成し、cronで起動していましたが、
今回は、redmineとmariaDBのコンテナが別になるため、同期をとったバックアップを取得するには、
ホスト側で制御するのがよさそうです。
ということで、手順としては
(1) docker-compose でredmineのコンテナを停止し、mariaDBのコンテナでデータをバックアップ
(2) redmineのVolumeにある/filesディレクトリと/public/pluginsディレクトリをバックアップ
(3) 必要に応じてローテーション(過去分の削除)
(4) redmineコンテナの再開
でしょうか。
ホスト側でcronで指定しておけば、自動化できますね。
3.プラグインの稼働確認
以前確認したPlugin以外に、稼働するものを見つけたので記録に残します。
(赤字は、前回稼働確認時からバージョンが変更となっているもの)
導入確認済 plugins:(12/31現在) 4.2.1導入 バージョン 5.0.4導入検証 備考 6 redmine_code_review 1.0.0 1.1.0★ 正常稼働 バージョンアップの必要あり https://github.com/haru/redmine_code_review で最新版を入手 7 redmine_logs 0.1.1 0.3.0★ 正常稼働 バージョンアップの必要あり https://github.com/haru/redmine_logs で最新版を入手 8 redmine_close_button 0.0.8 0.0.8 正常稼働 オリジナルのコードにpatchが必要(適用例) +$LOAD_PATH.unshift "#{File.dirname(__FILE__)}/lib" 9 sidebar_hide 0.0.7 0.0.7 正常稼働 オリジナルのコードにpatchが必要(適用例) -require_dependency 'sidebar_hook_listener' +require File.expand_path('../lib/sidebar_hook_listener', __FILE__)
これで何とか移行作業は終了とできそうです。ホッ。。