Running Commands Locally
This topic describes how to execute commands locally with Docker.
If you wish to use the underlying om
and p-automator
CLI tools from your local workstation,
we recommend using docker to execute commands.
With p-automator
in particular, using Docker is necessary,
as the IaaS CLIs upon which we depend can be tricky to install.
With om
it's more a matter of convenience -
you can just as easily download the binary if it's available for your system.
Executing Commands
To execute commands in Docker:
-
First import the image:
1
docker import ${PLATFORM_AUTOMATION_IMAGE_TGZ} platform-automation-image
Where
${PLATFORM_AUTOMATION_IMAGE_TGZ}
is the image file downloaded from Tanzu Network. -
Then, you can use
docker run
to pass it arbitrary commands.Here, we're running the
p-automator
CLI to see what commands are available:1 2
docker run -it --rm -v $PWD:/workspace -w /workspace platform-automation-image \ p-automator -h
Note: that this will have access read and write files in your current working directory. If you need to mount other directories as well, you can add additional
-v
arguments.
Useful Commands
Retrieving Product Staged Configuration
1 2 3 |
|
${ENV_FILE}
is the environment file required for all tasks.
${PRODUCT_SLUG}
is the name of the product downloaded from Tanzu Network.
The resulting file can then be parameterized, saved, and committed to a config repo.
Retrieving Director Configuration
1 2 |
|
Ops Manager Targeting
Use environment variables to set what Ops Manager om
is targeting.
For example:
1 2 3 |
|
Note the additional space before the docker
command.
This ensures the command is not kept in bash history.
The environment variable OM_PASSWORD will overwrite the password value in the ENV_FILE
.
See the om
GitHub page for a full list of supported environment variables.
Disable Verifiers
In cases where verifiers are incorrectly failing for known reasons,
those specific verifiers should be disabled in order to apply changes.
om
has commands to disable individual verifiers:
For director verifiers:
1 2 3 4 |
|
Where ${VERIFIER_TYPE}
is the failing verifier.
For product verifiers:
1 2 3 4 |
|
Where ${VERIFIER_TYPE}
is the failing verifier
and ${PRODUCT_NAME}
is the metadata name of the associated product.
A list of failed verifiers is available in the output from the Apply Changes attempt. To retrieve a list of currently failing director and product verifiers without applying changes (from Ops Manager 2.6 forward) run:
1 2 3 |
|
The Ops Manager Documentation has additional details about managing verifiers.