You are viewing the RapidMiner Hub documentation for version 10.1 - 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:
- 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.
- Create a bind mount pointing to your database's storage on disk. This will only work if you are using a PostgreSQL database.
- 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, hitCtrl-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:
- 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) - 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
orPASSWORD
in their names) from your old.env
file, otherwise you won’t be able to log in after upgrade.
- environment variable values (note: before version 9.6, the variable values were stored in the
- Add the public DNS name (or IP address if you don't have a DNS entry configured) for the deployment to the
PUBLIC_URL
andSSO_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, hitCtrl-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.
- Recreate the backed up Python environments using Platform Admin.
- 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.