Skip to main content

Batch — Workloads

This article refers to Platform v3.4.0. The current Platform version is v3.3.0.

Update in Progress...
This article is obsolete and we're preparing a fully updated version. Thanks for your patience. Please check back soon!

Overview​

The Workloads category of the batch wizard covers everything you do to applications and models across a fleet. Rather than one general-purpose install command, it offers a separate command per operation, so deploying an application for the first time and updating one already running are distinct actions with distinct parameters.

Each command becomes a batch: you pick the command in Action, the nodes in Target Nodes, optionally the hypervariable sets in Hypervariables, the values in Parameters, and confirm in Batch validation. See Batch operations for the wizard itself.

In this article, you will learn what each Workloads command does and which parameters and policies it exposes.

Workload commands​

Deploy​

Installs the selected application on all your target nodes. Use it for a first installation rather than to move an existing one to a new version.

Parameters asks for the application and the version, and exposes the configuration the workload starts with: App Secrets, Compose Config, and the App Config JSON. Each of these accepts hypervariables, so a single Deploy can give every node its own configuration. See Using hypervariables in batches.

Because a target node may already have the application installed, Deploy asks what to do in that case:

  • Install a new instance — leave the existing one alone and add another.
  • Overwrite installed version — replace what is there.
  • Reinstall the same version — reinstall without changing the version.
  • Do not install app — skip those nodes.

Update​

Updates the selected application to its latest available version on your target nodes. It changes the version and nothing else: existing configuration, secrets, and Compose settings are left untouched.

Parameters only needs the application and the target version. For nodes where the update does not apply, choose Do not install update in such nodes.

The Batch validation step is particularly useful here, because a node only qualifies if the application is actually installed on it. Use Remove invalid nodes to drop the rest in one action before launching.

Update App Config​

Replaces the current app configuration with an updated version across your target nodes. The workload keeps running on its installed version: only the configuration changes.

This is the command that pairs most naturally with hypervariables. Combined with a set, one batch delivers a different configuration to every node, which is otherwise a per-node operation.

warning

An App Config that contains hypervariable references cannot be applied to a single node from that node's own configuration view. References only resolve in a batch, where Barbara knows the group and can look up each node's value. To use such a configuration on one node, either remove the references or run this command with a single-node target.

Delete​

Deletes the selected workload on all your target nodes. If several instances of the workload are installed on a target node, all of them are deleted.

Start and Stop​

Start and Stop change the run state of the selected workload across the fleet. As with Delete, if a node has several instances of the workload, the command applies to all of them.

Configuration commands​

Three further commands in the same category set configuration that workloads draw on, rather than acting on a workload directly.

  • Update Global Config — defines global configuration parameters for all workloads on the target nodes.
  • Docker Credentials — adds the specified credentials to all target nodes. A credential that does not exist on a node is created; one that already exists is updated with the new values.
  • Global Secret — adds the specified secrets to the secret list of all target nodes, creating or updating each one the same way.

Policies​

Depending on the command, Parameters exposes a few switches that control how the operation runs:

  • Run automatically after install? — start the workload as soon as it is installed.
  • Activate logs for this application — begin capturing logs immediately.
  • Force docker image download? — pull the image again instead of reusing the one cached on the node.
  • Enable Rollback — return to the previous state if the operation fails.
  • Run using GPU — run the workload on the node's GPU.

Keep the defaults unless you have a reason to change them. Force docker image download? is the one worth knowing about: it makes a batch considerably slower across a large fleet, and it is only necessary when a tag has been republished and the cached image is stale.

Verify

Which policies each command exposes still needs confirming command by command against the shipped interface, and the screenshots for this article are pending.

Summary​

The Workloads category gives each fleet operation its own command: Deploy for a first installation, Update for a version change, Update App Config for configuration alone, and Delete, Start and Stop for lifecycle. Three configuration commands cover Global Config, Docker credentials, and Global Secrets.

Separating them means the parameters you see are only the ones the operation needs, and Batch validation can tell you in advance which nodes qualify. Combined with hypervariables, one batch configures a fleet whose values all differ.