WARNING WARNING WARNING: This is the Digital Rebar v2 product documentation. The v2 version is EOL as of September 2017. Please refer to the new Digital Rebar Provision v3 documentation: http://provision.readthedocs.io/en/tip/README.html
4. Workload Parameters¶
Note: These parameters are optional!
The following options are common for all workload scripts:
--deploy-admin=[provider]tells the script to create a new DR admin server on the provider specified.
--admin-ip=[ip]allows the script to use an existing DR admin server. Generally, this is used with the
--deployment-name=[name]sets the deployment for the workload. This is needed when testing multiple workloads on the same admin server. It also determines the names of the nodes created.
--wait-on-converge=true|falsetells the script to wait for converge work created by the script. This assumes that the admin is only doing one script at a time and is not recommended for CI/CD testing or parallel testing. Defaults to
--rebar-password=<String>sets the password to access the rebar system. Defaults to
--rebar-user=<String>changes the Username to access the rebar system. Defaults to
For example, to install the Kubernetes Workload, use:
cd ~/digitalrebar/deploy workloads/kubernetes.sh --deploy-admin=google --provider=aws --deployment-name=rebarrocks
The script can be interrupted while it is waiting to converge without impacting the deployment operation.
4.1. Using A Running DR Admin¶
While workloads scripts often include a Digital Rebar admin setup (see General Installation), it saves time if a working Admin Node is already present. Tell the scripts to use the admin node using
4.2. Cleaning Up¶
Workloads respect the
--teardown instruction to remove a workload. Make sure to include the same
--deployment-name! This only works if the
--deploy-admin option was used.
In order to keep the Admin node running for additional deployments, include the
--keep-admin=true flag. Otherwise, it will default to _false_.
Workloads need to Add Providers, so expect to specify a provider.
--device-id=<String>allows users to continue an aborted script against a node that was created by a provider in a previous run. This is very handy when debugging scripts.
--init-id-file=<file>File that defines the initial identity used to log into the node after provider provisioning. The scripts will generally handle this automatically and this setting can be used if the provider limits the number of keys that can be used.
AWS Specific Options:
--provider-aws-admin-instance-typeallows AWS instance types to be used for admin nodes. This is important when running large tests and want extra resources.
--provider-aws-instance-typeallows AWS instance types to be used for nodes to match performance needs.
--provider-aws-regionchooses region to be used for nodes
Google Specific Options:
--provider-google-admin-instance-typeallows Google instance types to be used for admin nodes. This is important when running large tests and want extra resources.
--provider-google-instance-typeallows Google instance types to be used for nodes to match performance needs.
--provider-google-zonechooses zone to be used for nodes
4.4. Advanced Options¶
These options provide extra control for the Digital Rebar installation.
--dns-domainDomain name setting is important if nodes need to be joined to a larger DNS infrastructure. Defaults to
--dr_tag=<TAG>if running stable or special branches, then pick a build tag to use for digitalrebar. default:
--id-file=<file>picks the SSH Identity file to use to log into the node to ensure keys are in place. This is useful if multiple SSH identities are in use.