Workspace Linking
Cloudomation enables the user to synchronize executions on different workspaces.
Use Cases
Running executions remotely in another workspace. For example:
- in a company Intranet
- on your local machine
- in some other cloud or VPS
This is especially useful for environments with no public IP address or environments that are unreachable from the public network.
Configuration
To configure the workspace linking create a Synch Config in the local and remote workspace each. It is possible to allow for bidirectional control (both workspaces can run flow scripts in the other) or to restrict the control in one way (see the description in the field Remote URL).
Only users with the role organization admin can configure workspace linkings.
| Field | Description |
|---|---|
| Enabled | If unset, the workspace sync is turned off. |
| Remote URL | Contains the URL of the other workspace like: https://<other-workpace-name>.cloudomation.com/api/latest/sync_config/<this-workpace-name>/sync. If you want to restrict the control in one way leave this field empty in the configuration of the workspace that is controlled. |
| CA certificate | The CA certificate of the other workspace. Only needed when using self-signed HTTPS certificates. |
| Verify SSL certificates | A flag to control if SSL certificates should be verified. |
| Own private key | A RSA private key used to sign outgoing messages. |
| Remote public key | The RSA public key of the linked workspace. |
| Send all executions | If unset, executions that are started in the other workspace via the workspace synch, will not show up in the executions list of the controlling workspace. |
| Sync interval | An interval in seconds in which executions are synced. If unset, executions are synced as soon as a change occurs. |
The Own private key and the Remote public key are not shown after saving. For more information on where to find your workspaces' RSA keys please refer to environment variables
Usage
After the link is set up, you can test it with a simple flow script:
import flow_api
def handler(system: flow_api.System, this: flow_api.Execution):
this.flow(
'<your_flow>',
remote_workspace_name='<remote-workspace-name>',
)
return this.success('all done')
In the above example the resource <your_flow> has to exist in the remote workspace. This is generally true for all resources (flow scripts, settings, files etc.) that you want to remotely access.