アップグレードとマイグレーション

アップグレードは、特に本番環境で行う場合は大変な作業となりますが、そのような場合でもスムーズにご利用いただけるようにしています。

アップグレードやマイグレーションのシナリオは、複数の要因によって手順が異なります。

このページでは、サポートしているアップグレードおよびマイグレーションパスについて説明し、アップグレードおよびマイグレーションを成功させるための手順をステップバイステップで説明します。

サポートされているアップグレードパスとマイグレーションパス

まず、デプロイメントには、さまざまな種類があります。

スタンドアロンのRapidMiner Server: コンテナ型ではなく、手動でインストールしたもの（9.7までのすべてのバージョン)
RapidMinerプラットフォーム: コンテナ型（9.4～9.6のいずれかのバージョン）
IDを一元管理しているRapidMinerプラットフォーム: コンテナ型（バージョン9.7）

（旧バージョンのスタンドアロンのRapidMiner Serverおよび旧バージョンのRapidMiner Platformの両方からの）スタンドアロンのRapidMiner Serverの最新バージョンへのアップグレード、およびIDを一元管理しているRapidMinerプラットフォームの最新バージョンへのマイグレーションをサポートしています。

スタンドアロンのRapidMiner Serverのあるバージョンから最新のバージョンにアップグレードするには、Serverアップグレードガイドに従ってください。

IDを一元管理しているRapidMinerプラットフォームの最新バージョンに移行するには、以下のマイグレーションガイドに従ってください。

IDを一元管理しているRapidMinerプラットフォームの最新バージョンへのマイグレーション

移行元のソースのバージョンやデプロイメントの種類によって、手順は少し異なります。ご使用のデプロイ環境に適した章を以下から選んでください。

スタンドアロンのRapidMiner Serverからの移行

最新版のデプロイメントテンプレートをダウンロードします。
RapidMiner Serverのホームフォルダ：RapidMinerプラットフォームのデプロイメントでは、既存のホームフォルダを使用します。そのためには、docker-compose.ymlに記載されているdockerボリュームの定義を、ホストマシンのディスク上の自身のホームフォルダを指すようバインドマウントを変更する必要があります。
ホストマシン上でRapidMiner ServerのホームフォルダがUID1000のユーザーでアクセスできるか確認します。これを行うには、chown -R 1000:1000 ./your-rmserver-home-folderを実行します。このコマンドは、対象のユーザーがシステム上に存在しない場合でも機能します。これは、Dockerコンテナ内でユーザーが、フォルダのコンテンツに適切にアクセスするために必要となります。
RapidMiner Serverデータベース: 下記の3つのオプションから1つを選択できます。
1. 古いSQLデータベースの内容をダンプして、Dockerコンテナとして動作する新しいデータベースにロードします。これは、PostgreSQLデータベースを使用している場合にのみ機能します。
2. ディスク上のデータベースのストレージを指すバインドマウントを作成します。これは、PostgreSQLデータベースを使用している場合にのみ機能します。
3. 既存のデータベースバックエンドを残すことを計画している場合（プラットフォームとは別に管理したい場合や、PostgreSQLデータベースではない場合など）は、.envファイルを編集して、このデータベースのアドレスと認証情報を記述します。SERVER_DBHOST、SERVER_DBSCHEMA、SERVER_DBUSER、SERVER_DBPASS、の変数を変更する必要があります。
ホストマシン上でdocker-compose up -d rm-init-svcを実行して、デプロイメントスタックを初期化します。
docker-compose logs rm-init-svcを実行すると、初期化手順がいつ終了するか確認できます。初期化に成功したというメッセージが表示されたら、Ctrl-Cを押してターミナルに戻ります。
docker-compose up -dを実行してスタックを起動します。
すべてが起動したら、ステップ5で指定したアドレスでログインできるようになります。最初はデフォルトのadminユーザーしか認証されず、ユーザーの移行は別途行う必要があります。

移行を完了させるには、さらに2つの手順が必要です。

必要に応じて、RapidMiner Server内でデータベーススキーマの移行を行います。プラットフォームにログインし、初めてRapidMiner Serverにアクセスする際、この操作を行うように求められます。
旧バージョンに存在していたユーザーを再作成します。これを自動化するための移行スクリプトは現在作成中ですが、今のところは手動で行う必要があります。また可能であれば、IDフェデレーションを設定することをお勧めします。

旧バージョンのRapidMinerプラットフォームからの移行

Platform AdminツールからPythonの環境をバックアップします。
古いdocker-compose.ymlと.envファイルをバックアップします（.envはバージョン9.6で導入されました）。
最新版のデプロイメントテンプレートをダウンロードします。
古い定義ファイルをもとに、お好みのテキストエディタでテンプレートを修正します。移行すべきものは以下です。
1. 環境変数の値（注意：バージョン9.6以前はdocker-compose.ymlファイルに格納されていましたが、.envファイルに移されました）。
2. 追加のコンテナ定義とその構成（追加のジョブエージェントコンテナなど）

アップグレード後にログインできなくなるので、古い.envファイルから以前に生成・保存したシークレットやパスワード（名前にSECRET、USER、PASSWORDを含むすべての変数）を移行できているか確認してください。

.envファイルのPUBLIC_URLおよびSSO_PUBLIC_URL変数に、デプロイメントのパブリックDNS名（DNSエントリが設定されていない場合はIPアドレス）を追加します。
まだ行っていない場合は、古いデプロイメントを実行しているホストマシン上のdocker-compose.ymlと.envを上書きします。
ホストマシン上でdocker-compose up -d rm-init-svcを実行して、デプロイメントスタックを初期化します。
docker-compose logs rm-init-svcを実行すると、初期化手順がいつ終了するか確認できます。初期化に成功したというメッセージが表示されたら、Ctrl-Cを押してターミナルに戻ります。
docker-compose up -dを実行してスタックを起動します。
すべてが起動したら、ステップ5で指定したアドレスでログインできるようになります。最初はデフォルトのadminユーザーしか認証されず、ユーザーの移行は別途行う必要があります。

移行を完了させるには、さらに2つの手順が必要です。

バックアップしたPython環境をPlatform Adminで再構築します。
必要に応じて、RapidMiner Server内でデータベーススキーマの移行を行います。プラットフォームにログインし、初めてRapidMiner Serverにアクセスする際、この操作を行うように求められます。
旧バージョンに存在していたユーザーを再作成します。これを自動化するための移行スクリプトは現在作成中ですが、今のところは手動で行う必要があります。また可能であれば、IDフェデレーションを設定することをお勧めします。

Server RESTエンドポイントでレガシーHTTPベーシック認証を有効にする

KeyCloakコンポーネントを導入してRapidMinerプラットフォームにIdentity and Securityを実装することで、RESTエンドポイントで利用できるセキュリティレベルが向上しました。

既存バージョンのRapidMinerプラットフォームやスタンドアロンのRapidMiner Serverから移行する場合は、既存のWebサービスがすでにクライアントアプリケーションに組み込まれていて、変更できない、または変更したくない場合があります。

このような場合には、これらのRESTエンドポイントで以前使用されていたHTTP Basic認証を再度有効にすることが可能です。

有効にするには、プラットフォームのデプロイメントで環境変数LEGACY_REST_BASIC_AUTH_ENABLEDをtrueに設定する必要があります。この変数は、.envファイルに格納されています。これには、Docker Deployment Managerを使用する方法と、手動でファイルを編集してからdocker-compose up -dコマンドを実行して変更を適用する方法があります。