You are viewing the RapidMiner Hub documentation for version 10.3 - Check here for latest version

Upgrade

To migrate to RapidMiner AI Hub 10, please see the detailed migrate from 9.x instructions. Make sure that you’re at least on version 9.10.4. Direct upgrade paths to version 10 from lower versions than the mentioned one are not supported.

Upgrades can be daunting, especially in production deployments, and we are committed to providing a smooth experience even in these scenarios.

That being said, there are multiple distinct upgrade and migration scenarios depending on multiple factors.

On this page, we will explain the upgrade and migration paths that we support, and we will provide step-by-step instructions to carry out a successful upgrade or migration.

Supported upgrade and migration paths for RapidMiner AI Hub 9.x

First, let's establish the different flavors of deployments that exist:

RapidMiner Platform: containerized (any version between 9.4 and 9.6)
RapidMiner Platform with centralized identity: containerized (version 9.7)

We support upgrading to the latest version of Standalone RapidMiner Server, and migrating to the latest version of the RapidMiner Platform with centralized identity (both from an older version of Standalone RapidMiner Server and from an older version of RapidMiner Platform).

To upgrade from one version of Standalone RapidMiner Server to the latest version, follow the Server upgrade guide.

To migrate to the latest version of RapidMiner Platform with centralized identity, follow our migration guide below.

Migrating to the latest version of RapidMiner Platform with centralized identity

Depending on the source version and deployment flavor you are migrating from, you will need to follow slightly different steps. Choose the right chapter for your deployment below.

Migrating from Standalone RapidMiner Server

Download a deployment template for the latest version
The RapidMiner Server home folder: you will use your existing home folder in the RapidMiner Platform deployment. To do this, you'll need to change the docker volume definition in your docker-compose.yml to a bind mount pointing to your home folder on the host machine's disk.
Make sure that the RapidMiner Server home folder is accessible on the host machine by the user with the UID 1000. To do this, run chown -R 1000:1000 ./your-rmserver-home-folder. This command will work even if no such user exists on your system. This is needed so the user inside our docker containers can access the folder contents properly.
The RapidMiner Server database: you can choose one of three options:
1. Dump the contents of the old SQL database and load it into the new one which will run as a docker container. This will only work if you are using a PostgreSQL database.
2. Create a bind mount pointing to your database's storage on disk. This will only work if you are using a PostgreSQL database.
3. If you plan to keep your existing database backend (either because you want to administer it separately from the Platform, or it's not a PostgreSQL database), edit your .env file to contain the address and credentials of this database. You need to modify these variables: SERVER_DBHOST, SERVER_DBSCHEMA, SERVER_DBUSER, SERVER_DBPASS.
On the host machine, initialize the deployment stack by running docker-compose up -d rm-init-svc
You can check when the initialization procedure finishes by running docker-compose logs rm-init-svc. When you see a message stating that initialization completed successfully, hit Ctrl-C to get back to your terminal.
Start the stack by running docker-compose up -d
After everything has booted up, you will be able to log in on the address specified in step 5. At first only the default admin user can be authenticated, user migration needs to be done separately.

To complete the migration, two more manual steps are needed.

If needed, perform a database schema migration in RapidMiner Server. You will get prompted to do this when logging in to the Platform and navigating to RapidMiner Server for the first time.
Recreate users which existed in the old installation. We are working on a migration script to automate this, but for now it has to be done manually. If available, we also encourage configuring identity federation.

Migrating from an older version of RapidMiner Platform

Back up your Python environments from the Platform Admin tool.
Back up your old docker-compose.yml and .env files (.env was only introduced in version 9.6).
Download a deployment template for the latest version
Modify the template with your favorite text editor based on your old definition files. These are the things you should migrate:
1. environment variable values (note: before version 9.6, the variable values were stored in the docker-compose.yml file, and have since been moved to the .env file)
2. any extra container definitions and their configuration (such as additional Job Agent containers)
  Make sure you migrate all the previously generated and stored secrets and passwords (all variables with SECRET, USER or PASSWORD in their names) from your old .env file, otherwise you won’t be able to log in after upgrade.
Add the public DNS name (or IP address if you don't have a DNS entry configured) for the deployment to the PUBLIC_URL and SSO_PUBLIC_URL variables in your .env file.
If the old deployment is still running, stop all jobs, and then stop the deployment with docker-compose down.
Overwrite docker-compose.yml and .env on the host machine where the old deployment was running.
On the host machine, initialize the new deployment stack by running docker-compose up -d rm-init-svc
You can check when the initialization procedure finishes by running docker-compose logs rm-init-svc. When you see a message stating that initialization completed successfully, hit Ctrl-C to get back to your terminal.
Start the stack by running docker-compose up -d
After everything has booted up, you will be able to log in on the address specified in step 5. At first only the default admin user can be authenticated, user migration needs to be done separately.