Upgrade
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
First, let's establish the different flavors of deployments that exist:
- Standalone RapidMiner Server: installed manually, not containerized (any version up to 9.7)
- 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 ofStandalone RapidMiner Server, and migrating to the latest version of theRapidMiner Platform with centralized identity(both from an older version ofStandalone RapidMiner Serverand from an older version ofRapidMiner Platform).
To upgrade from one version ofStandalone RapidMiner Serverto the latest version, follow theServer upgrade guide.
To migrate to the latest version ofRapidMiner Platform with centralized identity, follow ourmigration guidebelow.
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 adeployment templatefor 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.ymlto 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
.envfile 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-Cto 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
adminuser 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 userswhich 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 encourageconfiguring identity federation.
Migrating from an older version of RapidMiner Platform
- Back up your Python environmentsfrom the Platform Admin tool.
- Back up your old
docker-compose.ymland.envfiles (.envwas only introduced in version9.6). - Download adeployment templatefor 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 version9.6, the variable values were stored in the
docker-compose.ymlfile, and have since been moved to the.envfile) - 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,USERorPASSWORDin their names) from your old.envfile, otherwise you won’t be able to log in after upgrade.
- environment variable values (note: before version9.6, the variable values were stored in the
- 添加公共DNS名称或IP地址,如果你不t have a DNS entry configured) for the deployment to the
PUBLIC_URLandSSO_PUBLIC_URLvariables in your.envfile. - If you haven't done so already, overwrite
docker-compose.ymland.envon the host machine where the old deployment is running. - 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-Cto 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
adminuser 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 environmentsusing 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 userswhich 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 encourageconfiguring identity federation.
Enabling legacy HTTP basic authentication on Server REST endpoints
By introducing the KeyCloak component to implement Identity and Security in the RapidMiner Platform, we increased oursecurity level available on our REST endpoints.
When migrating from an existing version of the RapidMiner Platform, or a Standalone RapidMiner Server, existing web services might already be embedded in client applications where a change is not possible, or not desired.
In these cases it's possible to re-enable the HTTP Basic authentication that was previously available on these REST endpoints.
To enable it, you have to set the environment variableLEGACY_REST_BASIC_AUTH_ENABLEDtotruein your platform deployment. This variable is stored in the.envfile. You can do this either usingDocker Deployment Manager, or by manually editing the file and then issuingdocker-compose up -dto apply the changes.
