Deploy a project

What is a deployment?

We broadly define deployment as embedding content created within a project and embedding it into an existing (or new) business process. Here are some examples for these:

• generating a weekly report and emailing it to stakeholders
• periodic data ingestion and cleaning
• publishing a predictive model on a REST endpoint and integrating it with another application which implements certain business objectives
• creating a dashboard to visualize periodically refreshed KPIs and displaying them on a large screen on a factory floor

Once such content (workflows, models, notebooks, etc.) has been created, deployment should be a logical next step to ensure that the project generates continuous business value to the enterprise.

What types of deployments are there?

To present data, models or other results as a convenient dashboard, you should useour apps.

To expose a workflow as a REST endpoint that is always ready to serve requests with low latency, you should useREST API deployments.

In case you have workflows which are longer running, and you need a convenient way to trigger an execution (either manually, or by any third party orchestration tool), you should useshortcuts.

REST API deployments

Features

Exactly one workflow can be served in each deployment, so if you need multiple workflows deployed, you should create a deployment for each one.

When a REST API deployment is created, a dedicated, isolated container will be provisioned and will be ready to serve requests exclusively for the deployed workflow.

When creating (or editing) a deployment, its resource allocation constraints must be specified. The deployment will consist of a single container instance and will not be horizontally scaled. Resource allocation consists of the maximum number of virtual CPUs and maximum amount of memory (in GiB) the deployment is allowed to consume.

The deployment will have its own, unique address accessible on the public internet. This address will be automatically generated when the deployment is created. This unique external address can be reused from other deployments which can be useful in certain scenarios. For more details, seeexternal address management.

Workflow variables can be provided as query parameters if needed, and they can be mapped to shorter, simpler names when creating the deployment. Similarly, the workflow itself can be mapped to a simpler, shorter naming scheme in the deployment URL.

Inputs and outputs

Aside from the previously mentioned workflow variable inputs, REST API deployments can take data as input, and also return data as output. Input data is always passed to the workflow via itsfirst Input operator(as defined by the execution order).

The Input operator must have itsExternal Overwriteenabled so that it can process the input properly.

The data on the workflow'sfirst output portwill be returned in the response (as defined by the execution order).

Inputs and outputs are passed as JSON representation of theRapidMiner data format.

Creating a REST API deployment

Once the workflow is ready to be deployed, go to the Deployments tab in your project and click onNew Deployment.

Next, name your deployment and select the workflow to be deployed.

ForExternal Address, if it's a new deployment, you should chooseGenerate New. More complex cases will beexplained below.

TheURL mappingcan be used to shorten and simplify the deployed URL, and to hide complexities of your project towards the outside world. In our example, we will simplify by exposing the workflow namedtransform-data-and-score-decision-tree.rmpasscore.

If your workflow needs further inputs as workflow variables that you wish to expose, provide them in theParameter mappingsection. You can use shorter/simpler names in your mapping to reduce complexity.

UnderResource allocation, select the resource quota the deployment is allowed to consume.

Finally, you can add a layer ofsecurityfor your endpoints (this is enabled by default, can be disabled if simpler access is preferred).

After checking that everything looks good on the right inSummary, clickDeployto start the deployment.

On the last feedback screen you will see the address of your newly created deployment which you can integrate your other business applications to. The deployment will be created and started in the background and will be ready to serve requests in a matter of seconds.

External address management

External addresses generated for REST API deployments can be reused for a different REST API deployment. This comes in handy when the deployment is already integrated into another business application and the deployment needs to be updated (good examples for this are model retraining scenarios, or simply finding a better performing model for that particular use-case). In this case, the way the deployment is accessed (location and authorization) should remain unchanged while the workflow being served is replaced.

To do this, create a new deployment by following the steps above to deploy your new workflow (or redeploy the same workflow using a newer model).

This time, under External address, selectUse existingand pick the name of your existing deployment.

UnderSummary, the address of your previously existing deployment will be shown.

On the deployments tab, both deployments will be visible. The old one, with no assigned external address, will be marked with a warning status, as seen below:

Security

REST API部署在公共访问Internet, which means that any actor who knows the deployment's address can interact with it. The deployment address is random generated and not easy to guess (also, not possible to compute based on the account ID or user ID), which already provides security by obscurity. In some cases, especially when simplicity is key, this might prove enough. However, it is possible to protect the deployments with a pre-shared secret.

Whenever Security is enabled (which is the case by default), we generate a secret for the deployment. This secret must be provided in theAuthorizationHTTP header in the formatDW-Secret secret_valuewith each request that is sent to the REST API deployment. The secret is shown during deployment creation time on the feedback screen along with the deployment address, and can also be viewed on the deployment details page.

If the correct secret is not provided with the request, the deployment will respond with HTTP 403 Forbidden.

安全可以启用新管理loyments, but you can also edit existing deployments and add security later.

Usage

这里有一个例子使用旋度如何to use a REST API deployment with security enabled:

curl --location --request POST 'https://cloud.www.turtlecreekpls.com/api/ext/0e6ca5e1-ad56-4ea6-b4bd-2cd82f14d6fd/score' \
--header 'Authorization: DW-Secret b3b7169b-4439-4442-94dc-200a1b5f8af1' \
--header 'Content-Type: application/json' \
--data-raw '{
"table": {
"height": 1,
"width": 4,
"columns": [
{
"name": "Mobile Plan",
"index": 0,
"type": "Nominal",
"data": ["Yes"]
},
{
"name": "Partner Plan",
"index": 1,
"type": "Nominal",
“数据”(“不”):
},
{
"name": "Internet Plan",
"index": 2,
"type": "Nominal",
“数据”(“不”):
},
{
"name": "Monthly Payment",
"index": 3,
"type": "Real",
"data": [24.95]
}
]
}
}'

Shortcuts

Shortcuts provide a secure, repeatable API for executing a specific RapidMiner workflow with preset resource constraints.

UnlikeREST API deployments, shortcuts only consume resources when its API triggers an execution.

Shortcuts come in handy when you have created workflows that typically have a long execution time and only need to be executed periodically, either on a schedule or triggered by some external system. This could be either a third party orchestration or workflow management platform or simply your own scheduling system.

Some use-case examples:

• a workflow that generates a fresh report based on latest data
• a workflow that trains (retrains) a predictive model, incorporating the newest observations and accounting for drift
• on-demand data dump and ETL workloads

Features

When a shortcut is created, we generate an API endpoint that, when called, will trigger an execution of that workflow with the resource allocation configured during shortcut creation.

Endpoint security is implemented similarly asfor REST API deployments.

Inputs and outputs are not yet supported when calling the API endpoint, workflows should take inputs and outputs from other sources.

Creating shortcuts

You can either start by clicking theNew Deploymentbutton on theDeploymentstab of your project, or clicking theDeploybutton next to your workflow in the projectContentstab.

Next, selectShortcutas your deployment type.

Name your deployment and choose your workflow. Set resource allocation constraints andsecurity.

Review the summary on the right, and clickDeploy.

Your shortcut will be usable momentarily. Access details are shown on the next screen.

Using shortcuts

这里有一个例子使用旋度如何to use a REST API deployment with security enabled:

curl --location --request POST 'https://cloud.www.turtlecreekpls.com/api/shortcut/c833502d-ff62-4314-9ee7-b53a0e780df2' \
--header 'Authorization: DW-Secret 7213570f-540a-4f9d-ba0c-0e75add87af6' \

Editing and deleting shortcuts

You can edit shortcuts in your project by clicking theEditicon next to your shortcut on the project'sDeploymentstab.

You can delete shortcuts by clicking the删除icon next to your shortcut on the project'sDeploymentstab.

Executions currently running will NOT be affected in either case.

Monitoring executions

Clicking on a shortcut on theDeploymentstab of your project will take you to its details page. You can observe executions that have happened recently or are currently in progress in theRecent runs面板。

Clicking on a recent run will take you to the workload monitor where you can observe more details such as current resource consumption and detailed workload logs for troubleshooting.