Platform Automation Toolkit Tasks

This document lists each Platform Automation Toolkit task, and provides information about their intentions, inputs, and outputs.

The tasks are presented, in their entirety, as they are found in the product.

Task types

The Docker image can be used to invoke the commands in each task locally. Use --help for more information. To learn more see Running commands locally.

Note The inputs, outputs, params, filename, and filepath of this task file are part of its semantically versioned API. See our documentation for a detailed discussion of our semver API. See www.semver.org for an explanation of semantic versioning.

activate-certificate-authority

Ensures that the newest certificate authority on Tanzu Operations Manager is active.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information

params:
  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to root of the `env` input

run:
  path: platform-automation-tasks/tasks/activate-certificate-authority.sh

Implementation


cat /var/version && echo ""
set -eux

om --env env/"${ENV_FILE}" activate-certificate-authority

Usage

- task: activate-new-ca
  image: platform-automation-image
  file: platform-automation-tasks/tasks/activate-certificate-authority.yml
  input_mapping:
    env: configuration
  params:
    ENV_FILE: foundations/config/env.yml

apply-changes

Triggers an install on the Tanzu Operations Manager described by the auth file.

To optionally provide an errand file to manually control errands for a particular of run of apply-changes. To see an example of this config file, see Inputs and outputs.

Note Tanzu Operations Manager Verifier failures when applying changes will prevent deployment. In cases where these verifiers are incorrectly failing for known reasons, they should be disabled using om. The IGNORE_WARNINGS parameter for the apply-changes, stage-configure-apply, and apply-director-changes tasks allows users to ignore all warnings from ignorable verifiers. In an automation context, disabling only the particular verifiers where failure is well-understood allows other verifiers to continue to provide important feedback. Some verifiers continue to return warnings even when disabled, preventing deployment without the IGNORE_WARNINGS: true param set. If the verifiers that are preventing deployment are known issues based on the environment setup, then it is safe to use the flag.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information
- name: errand-config # contains the errand configuration file
  optional: true

params:
  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to root of the `env` input

  RECREATE: false
  # - Optional
  # - If true, will recreate all product VMs
  # - If true, will also recreate the director VM if there are changes

  ERRAND_CONFIG_FILE:
  # - Optional
  # - Filepath of the errand config file
  # - Relative to root of the task build;
  #   for example, `errand-config/errands.yml`
  #   or `env/errands.yml`

  IGNORE_WARNINGS: false
  # - Optional
  # - If true, will not fail when verifiers have warnings,
  #   it will still fail for any errors.
  # - This is not recommended unless unless the warning failure(s)
  #   are well understood.

  SELECTIVE_DEPLOY_PRODUCTS:
  # - Optional
  # - Comma separated list of products for apply changes.

run:
  path: platform-automation-tasks/tasks/apply-changes.sh

Implementation


cat /var/version && echo ""
set -eux

flags=("--reattach")

if [ "${RECREATE}" == "true" ]; then
  flags+=("--recreate-vms")
fi

if [ "${IGNORE_WARNINGS}" == "true" ]; then
  flags+=("--ignore-warnings")
fi

if [ -n "${ERRAND_CONFIG_FILE}" ]; then
  flags+=("--config" "${ERRAND_CONFIG_FILE}")
fi

if [ -n "${SELECTIVE_DEPLOY_PRODUCTS}" ]; then
  # convert comma-separated variable into bash-native space-separated
  for PRODUCT in ${SELECTIVE_DEPLOY_PRODUCTS//,/ }; do
    flags+=("--product-name" "${PRODUCT}")
  done
fi

# ${flags[@] needs to be globbed to pass through properly
# shellcheck disable=SC2068
om --env env/"${ENV_FILE}" apply-changes \
  ${flags[@]}

Usage

- task: apply-product-changes
  attempts: 3
  image: platform-automation-image
  file: platform-automation-tasks/tasks/apply-changes.yml
  input_mapping:
    env: configuration
  params:
    ENV_FILE: foundations/config/env.yml

apply-director-changes

apply-changes can also be used to trigger an install for just the BOSH Director with the --skip-deploy-products/-sdp flag.

Note Tanzu Operations Manager Verifier failures when applying changes will prevent deployment. In cases where these verifiers are incorrectly failing for known reasons, they should be disabled using om. The IGNORE_WARNINGS parameter for the apply-changes, stage-configure-apply, and apply-director-changes tasks allows users to ignore all warnings from ignorable verifiers. In an automation context, disabling only the particular verifiers where failure is well-understood allows other verifiers to continue to provide important feedback. Some verifiers continue to return warnings even when disabled, preventing deployment without the IGNORE_WARNINGS: true param set. If the verifiers that are preventing deployment are known issues based on the environment setup, then it is safe to use the flag.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information

params:
  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to root of the `env` input

  IGNORE_WARNINGS: false
  # - Optional
  # - If true, will not fail when verifiers have warnings,
  #   it will still fail for any errors.
  # - This is not recommended unless unless the warning failure(s)
  #   are well understood.

run:
  path: platform-automation-tasks/tasks/apply-director-changes.sh

Implementation


cat /var/version && echo ""
set -eux

flags=("--skip-deploy-products" "--reattach")

if [ "${IGNORE_WARNINGS}" == "true" ]; then
  flags+=("--ignore-warnings")
fi

# ${flags[@] needs to be globbed to pass through properly
# shellcheck disable=SC2068
om --env env/"${ENV_FILE}" apply-changes \
  ${flags[@]}

Usage

- task: apply-product-changes
  attempts: 3
  image: platform-automation-image
  file: platform-automation-tasks/tasks/apply-changes.yml
  input_mapping:
    env: configuration
  params:
    ENV_FILE: foundations/config/env.yml

assign-multi-stemcell

assign-multi-stemcell assigns multiple stemcells to a provided product. For more information about how to utilize this workflow, see Stemcell Handling.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information
- name: config # contains the configuration file for assign-multi-stemcell command
  # - Example config:
  # ---
  # product: cf
  # stemcell:
  # - ubuntu-trusty:1234.6
  # - ubuntu-xenial:latest

params:
  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to root of the `env` input

  CONFIG_FILE: config.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to root of the `assign-multi-stemcell-config` input

run:
  path: platform-automation-tasks/tasks/assign-multi-stemcell.sh

Implementation



cat /var/version && echo ""
set -eux
om --env env/"${ENV_FILE}" assign-multi-stemcell \
  --config config/"${CONFIG_FILE}"

Usage

- task: assign-multi-stemcell
  image: platform-automation-image
  file: platform-automation-tasks/tasks/assign-multi-stemcell.yml
  params:
    ENV_FILE: ((foundation))/env/env.yml

assign-stemcell

assign-stemcell assigns a stemcell to a provided product. For more information about how to use this workflow, see Stemcell Handling.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information
- name: config # contains the configuration file for assign-stemcell command
  # - Can consume the output of `download-product` task directly
  # - Example config:
  # ---
  # product: cf
  # stemcell: 3468.86

params:
  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to root of the `env` input

  CONFIG_FILE: config.yml
  # - Required
  # - Filepath of the assign-stemcell config YAML
  # - The path is relative to root of the `config` input

run:
  path: platform-automation-tasks/tasks/assign-stemcell.sh

Implementation


cat /var/version && echo ""
set -eux
om --env env/"${ENV_FILE}" assign-stemcell \
  --config config/"${CONFIG_FILE}"

Usage

- task: assign-stemcell
  image: platform-automation-image
  file: platform-automation-tasks/tasks/assign-stemcell.yml
  params:
    ENV_FILE: ((foundation))/env/env.yml

backup-director

Use BBR to backup a BOSH Director deployed with Tanzu Operations Manager.

Task


---
platform: linux

inputs:
  - name: platform-automation-tasks
  - name: env # contains the env file with target OpsMan Information
outputs:
  - name: backup
    # This will output a *.tgz of the entire backup.
    # The filename includes the timestamp.


params:
  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to the root of the `env` input

  PRODUCT_NAME:
  # - Required
  # - The name of the product config to be exported

  OPSMAN_SSH_PRIVATE_KEY:
  # - Optional
  # - May be required to communicate with the Ops Manager BOSH director
  # - This is the private key for the Ops Manager VM (used during VM creation)

  OPSMAN_SSH_USERNAME: ubuntu
  # - Optional
  # - May be required to communicate with the Ops Manager BOSH director
  # - This is the username used when tunneling through the Ops Manager VM

run:
  path: platform-automation-tasks/tasks/backup-director.sh

Implementation


cat /var/version && echo ""
set -eu

# shellcheck source=./setup-bosh-env.sh
source ./platform-automation-tasks/tasks/setup-bosh-env.sh

bosh_username="bbr"
bosh_private_key="$(om --env env/"${ENV_FILE}" curl -p /api/v0/deployed/director/credentials/bbr_ssh_credentials | om interpolate --path /credential/value/private_key_pem)"

set -x

pushd backup
  bbr director \
    --host "${BOSH_ENVIRONMENT}" \
    --username "${bosh_username}" \
    --private-key-path <(set +x; echo "${bosh_private_key}") \
    backup-cleanup

  bbr director \
    --host "${BOSH_ENVIRONMENT}" \
    --username "${bosh_username}" \
    --private-key-path <(set +x; echo "${bosh_private_key}") \
    backup

  tar -zcvf director_"$( date +"%Y-%m-%d-%H-%M-%S" )".tgz --remove-files -- */*
popd

Usage

- task: backup-director
  image: platform-automation-image
  file: platform-automation-tasks/tasks/backup-director.yml
  params:
    OPSMAN_SSH_PRIVATE_KEY: ((vsphere_private_ssh_key))

backup-product

Use BBR to backup a product deployed with Tanzu Operations Manager.

Task


---
platform: linux

inputs:
  - name: platform-automation-tasks
  - name: env # contains the env file with target OpsMan Information
outputs:
  - name: backup
    # This will output a *.tgz of the entire backup.
    # The filename includes the timestamp.


params:
  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to the root of the `env` input

  PRODUCT_NAME:
  # - Required
  # - The name of the product config to be exported

  OPSMAN_SSH_PRIVATE_KEY:
  # - Optional
  # - May be required to communicate with the Ops Manager BOSH director
  # - This is the private key for the Ops Manager VM (used during VM creation)

  OPSMAN_SSH_USERNAME: ubuntu
  # - Optional
  # - May be required to communicate with the Ops Manager BOSH director
  # - This is the username used when tunneling through the Ops Manager VM

run:
  path: platform-automation-tasks/tasks/backup-product.sh

Implementation


cat /var/version && echo ""
set -eu

if [ -z "${PRODUCT_NAME}" ]; then
  { printf "\nError: 'PRODUCT_NAME' parameter is required"; } 2>/dev/null
  exit 1
fi

# shellcheck source=./setup-bosh-env.sh
source ./platform-automation-tasks/tasks/setup-bosh-env.sh

# exported for use in other tasks
export DEPLOYMENT_NAME
DEPLOYMENT_NAME="$(om --env env/"${ENV_FILE}" curl -p /api/v0/deployed/products | om interpolate --path "/type=${PRODUCT_NAME}/guid")"

set -x

pushd backup
  bbr deployment \
      --deployment "${DEPLOYMENT_NAME}" \
    backup-cleanup

  bbr deployment \
      --deployment "${DEPLOYMENT_NAME}" \
    backup --with-manifest

  tar -zcvf product_"${PRODUCT_NAME}"_"$( date +"%Y-%m-%d-%H-%M-%S" )".tgz --remove-files -- */*
popd

Usage

- task: backup-product
  image: platform-automation-image
  file: platform-automation-tasks/tasks/backup-product.yml
  params:
    PRODUCT_NAME: cf
    ENV_FILE: env.yml
    OPSMAN_SSH_PRIVATE_KEY: ((opsman-ssh-private-key))

backup-tkgi

Use BBR to backup Tanzu Kubernetes Grid Integrated Edition(TKGI) deployed with Tanzu Operations Manager.

Note PKS CLI may be temporarily unavailable: During the backup, the PKS CLI is disabled. Due to the nature of the backup, some commands may not work as expected.

Caution Known issue: When using the task backup-tkgi behind a proxy, the values for no_proxy can affect the SSH (though jumpbox) tunneling. When the task invokes the bbr CLI, an environment variable ( BOSH_ALL_PROXY) has been set, this environment variable tries to honor the no_proxy settings. The task's usage of the SSH tunnel requires the no_proxy to not be set.
If you experience an error, such as an SSH connection refused or connection timeout, try setting the no_proxy: "" as params on the task.
For example,

- task: backup-tkgi
    file: platform-automation-tasks/tasks/backup-tkgi.yml
    params:
    no_proxy: ""

Task


---
platform: linux

inputs:
  - name: platform-automation-tasks
  - name: env # contains the env file with target OpsMan Information
outputs:
  - name: backup
    # This will output two *.tgz of the entire backup.
    # One is the backup of the tkgi tile
    # One is the backup of the tkgi clusters
    # The filename includes the timestamp.

params:
  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to the root of the `env` input

  OPSMAN_SSH_PRIVATE_KEY:
  # - Optional
  # - May be required to communicate with the Ops Manager BOSH director
  # - This is the private key for the Ops Manager VM (used during VM creation)

  OPSMAN_SSH_USERNAME: ubuntu
  # - Optional
  # - May be required to communicate with the Ops Manager BOSH director
  # - This is the username used when tunneling through the Ops Manager VM

run:
  path: platform-automation-tasks/tasks/backup-tkgi.sh

Implementation


cat /var/version && echo ""
set -eu

export PRODUCT_NAME="pivotal-container-service"

# shellcheck source=./setup-bosh-env.sh
source ./platform-automation-tasks/tasks/setup-bosh-env.sh

# shellcheck disable=SC2016
echo 'Backing up TKGI, the `pks` CLI may be unavailable'

# shellcheck source=./backup-product.sh
source ./platform-automation-tasks/tasks/backup-product.sh

bosh_team_creds="$(om --env env/"${ENV_FILE}" curl -p /api/v0/deployed/products/"${DEPLOYMENT_NAME}"/uaa_client_credentials)"
bosh_team_client="$(echo "${bosh_team_creds}" | om interpolate --path /uaa_client_name)"
bosh_team_client_secret="$(echo "${bosh_team_creds}" | om interpolate --path /uaa_client_secret)"

set -x

pushd backup
  bbr deployment \
    --username "${bosh_team_client}" \
    --password "${bosh_team_client_secret}" \
    --all-deployments \
    backup-cleanup
    
  bbr deployment \
    --username "${bosh_team_client}" \
    --password "${bosh_team_client_secret}" \
    --all-deployments \
    backup --with-manifest

  tar -zcvf "${PRODUCT_NAME}"_clusters_"$( date +"%Y-%m-%d-%H-%M-%S" )".tgz \
    --exclude "${PRODUCT_NAME}"_*.tgz \
    --remove-files -- */*
popd

Usage

- task: backup-tkgi
  image: platform-automation-image
  file: platform-automation-tasks/tasks/backup-tkgi.yml
  params:
    ENV_FILE: env.yml
    OPSMAN_SSH_PRIVATE_KEY: ((opsman-ssh-private-key))

check-pending-changes

Returns a table of the current state of your Tanzu Operations Manager and lists whether each product is changed or unchanged and the errands for that product. By default, ALLOW_PENDING_CHANGES: false will force the task to fail. This is useful to keep manual changes from being accidentally applied when automating the configure-product/apply-changes of other products.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information

params:
  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to root of the `env` input

  ALLOW_PENDING_CHANGES: false
  # - Optional
  # - If false, will fail if there are pending changes in OpsMan

run:
  path: platform-automation-tasks/tasks/check-pending-changes.sh

Implementation


cat /var/version && echo ""
set -eux

flags=("")
if [ "${ALLOW_PENDING_CHANGES}" == "false" ]; then
  flags+=("--check")
fi

# ${flags[@] needs to be globbed to pass through properly
# shellcheck disable=SC2068
om --env env/"${ENV_FILE}" pending-changes \
  ${flags[@]}

Usage

- task: check-pending-changes
  image: platform-automation-image
  file: platform-automation-tasks/tasks/check-pending-changes.yml
  input_mapping:
    env: configuration
  params:
    ENV_FILE: foundations/config/env.yml
    ALLOW_PENDING_CHANGES: true

collect-telemetry

Collects foundation information using the Tanzu Telemetry for Tanzu Operations Manager tool.

This task requires the telemetry-collector-binary as an input. The binary is available on the Broadcom Support portal; you must define a resource to supply the binary.

This task requires a config file.

After using this task, the send-telemetry task may be used to send telemetry data to VMware.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: telemetry-collector-binary
- name: env # contains the env file with target OpsMan Information
- name: config # contains the product configuration file
  # - Example config:
  # ---
  # env_type: sandbox | development | qa | pre-production | production
  # with_credhub_info: false
  # cf_api_url: cf.example.com
  # usage_service_url: service.example.com
  # usage_service_client_id: client
  # usage_service_client_secret: secret
  # usage_service_insecure_skip_tls_verify: false

outputs:
- name: collected-telemetry-data

params:
  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to root of the `env` input

  CONFIG_FILE: config.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to root of the `config` input

run:
  path: platform-automation-tasks/tasks/collect-telemetry.sh

Implementation


set -eux

cat config/"${CONFIG_FILE}" env/"${ENV_FILE}" >combined-config.yml
sed 's/---//g' combined-config.yml >clean-config.yml

# Creating a named pipe so that the interpolated config isn't written to disk.
# We would normally use the <() syntax to do this,
# but the the telemetry collector requires a file extension.
mkfifo /tmp/pipe.yml

function finish() {
  rm /tmp/pipe.yml
}
trap finish EXIT

om interpolate -c clean-config.yml --vars-env OM_VAR >/tmp/pipe.yml &

./telemetry-collector-binary/telemetry-collector-linux-amd64 --version

om --env env/"${ENV_FILE}" curl --path /api/v0/info >/dev/null 2>&1

./telemetry-collector-binary/telemetry-collector-linux-amd64 collect \
  --output-dir ./collected-telemetry-data \
  --config /tmp/pipe.yml

Usage

- task: collect-telemetry-data
  image: platform-automation-image
  file: platform-automation-tasks/tasks/collect-telemetry.yml
  input_mapping:
    env: configuration
    config: configuration
  params:
    CONFIG_FILE: foundations/((foundation))/config/telemetry.yml
    ENV_FILE: foundations/config/env.yml

configure-authentication

Configures Tanzu Operations Manager with an internal userstore and admin user account. See configure-saml-authentication to configure an external SAML user store, and configure-ldap-authentication to configure with LDAP.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information
- name: config # contains the auth configuration

params:
  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to root of the `env` input

  AUTH_CONFIG_FILE: auth.yml
  # - Required
  # - Filepath of the authorization config YAML
  # - The path is relative to root of the `config` input

  VARS_FILES:
  # - Optional
  # - Filepath to the Ops Manager vars YAML file
  # - The path is relative to root of the task build
  # - These vars can come from the `env` or `config` inputs

run:
  path: platform-automation-tasks/tasks/configure-authentication.sh

Implementation


cat /var/version && echo ""
set -eux

vars_files_args=("")
for vf in ${VARS_FILES}; do
  vars_files_args+=("--vars-file ${vf}")
done

# ${vars_files_args[@] needs to be globbed to pass through properly
# shellcheck disable=SC2068
om --env env/"${ENV_FILE}" --skip-ssl-validation configure-authentication \
  --config config/"${AUTH_CONFIG_FILE}" \
  ${vars_files_args[@]}

Usage

- task: configure-authentication
  image: platform-automation-image
  file: platform-automation-tasks/tasks/configure-authentication.yml
  attempts: 10
  input_mapping:
    env: configuration
    config: configuration
  params:
    ENV_FILE: foundations/config/env.yml
    AUTH_CONFIG_FILE: foundations/config/auth.yml

For details on the config file expected in the config input, see Generating an Auth file.

configure-director

Configures the BOSH Director with settings from a config file. See staged-director-config, which can extract a config file.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: config # contains the director configuration file
- name: env # contains the env file with target OpsMan Information
- name: vars # variable files to be made available
  optional: true
- name: secrets
  # secret files to be made available
  # separate from vars, so they can be store securely
  optional: true
- name: ops-files # operations files to custom configure the product
  optional: true

params:
  VARS_FILES:
  # - Optional
  # - Filepath to the Ops Manager vars YAML file
  # - The path is relative to root of the task build,
  #   so `vars` and `secrets` can be used.

  OPS_FILES:
  # - Optional
  # - Filepath to the Ops Manager operations YAML files
  # - The path is relative to root of the task build

  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to root of the `env` input

  DIRECTOR_CONFIG_FILE: director.yml
  # - Required
  # - Filepath to the director configuration YAML file
  # - The path is relative to the root of the `config` input

run:
  path: platform-automation-tasks/tasks/configure-director.sh

Implementation


cat /var/version && echo ""
set -eux

vars_files_args=("")
for vf in ${VARS_FILES}; do
  vars_files_args+=("--vars-file ${vf}")
done

ops_files_args=("")
for of in ${OPS_FILES}; do
  ops_files_args+=("--ops-file ${of}")
done

# ${vars_files_args[@] needs to be globbed to pass through properly
# ${ops_files_args[@] needs to be globbed to pass through properly
# shellcheck disable=SC2068
om --env env/"${ENV_FILE}" configure-director \
  --config "config/${DIRECTOR_CONFIG_FILE}" \
  ${vars_files_args[@]} \
  ${ops_files_args[@]}

Usage

- task: configure-director
  image: platform-automation-image
  file: platform-automation-tasks/tasks/configure-director.yml
  input_mapping:
    config: configuration
    env: configuration

Caution GCP with service account: For GCP, if service account is used, the property associated_service_account has to be set explicitly in the iaas_configuration section.

configure-ldap-authentication

Configures Tanzu Operations Manager with an external LDAP user store and admin user account. See configure-authentication to configure an internal user store, and configure-saml-authentication to configure with SAML.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information
- name: config # contains the auth configuration

params:
  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to root of the `env` input

  AUTH_CONFIG_FILE: auth.yml
  # - Required
  # - Filepath of the authorization config YAML
  # - The path is relative to root of the `config` input

  VARS_FILES:
  # - Optional
  # - Filepath to the Ops Manager vars YAML file
  # - The path is relative to root of the task build
  # - These vars can come from the `env` or `config` inputs

run:
  path: platform-automation-tasks/tasks/configure-ldap-authentication.sh

Implementation


cat /var/version && echo ""
set -eux

vars_files_args=("")
for vf in ${VARS_FILES}; do
  vars_files_args+=("--vars-file ${vf}")
done

# ${vars_files_args[@] needs to be globbed to pass through properly
# shellcheck disable=SC2068
om --env env/"${ENV_FILE}" --skip-ssl-validation configure-ldap-authentication \
  --config config/"${AUTH_CONFIG_FILE}" \
  ${vars_files_args[@]}

Usage

- task: configure-ldap-authentication
  image: platform-automation-image
  file: platform-automation-tasks/tasks/configure-ldap-authentication.yml
  params:
    ENV_FILE: ((foundation))/env/env.yml
    AUTH_CONFIG_FILE: ((foundation))/auth/auth.yml

For more details about using LDAP, see Tanzu Operations Manager documentation.

For details about the config file expected in the config input, please see Generating an Auth file.

configure-opsman

This task supports configuring settings on the Tanzu Operations Manager Settings page in the UI. For example, the SSL cert for the Tanzu Operations Manager VM can be configured.

Configuration can be added directly to opsman.yml. An example of all configurable properties can be found in the "Additional Settings" tab.

The upgrade-opsman task will automatically call configure-opsman, so there is no need to use this task then. It is recommended to use this task in the initial setup of the Tanzu Operations Manager VM.

Task


---
platform: linux

inputs:
  - name: platform-automation-tasks
  - name: config # contains the OpsMan configuration file
  - name: env # contains the environment information for OpsMan
  - name: vars # variable files to be made available
    optional: true
  - name: secrets # secret files to be made available
    # separate from vars, so they can be stored securely
    optional: true

params:
  VARS_FILES:
  # - Optional
  # - space-seperated array of filepaths to YAML vars files
  #   to be loaded with the CONFIG_FILE
  # - relative to root of the task build,
  #   so both `vars` and `secrets` can be used.

  ENV_FILE: env.yml
  # - Required
  # - filepath of the env config YAML
  # - relative to root of the `env` input

  OPSMAN_CONFIG_FILE: opsman.yml
  # - Required
  # - filepath of the Ops Manager Application Settings
  #   config file. (such as banner, pivnet token, etc)
  # - relative to root of the `config` input
  # - VMware recommends using one config file to
  #   configure-opsman, upgrade-opsman, create-vm, delete-vm

run:
  path: platform-automation-tasks/tasks/configure-opsman.sh

Implementation


cat /var/version && echo ""
set -eux

vars_files_args=("")
for vf in ${VARS_FILES}; do
  vars_files_args+=("--vars-file ${vf}")
done

# ${vars_files_args[@] needs to be globbed to pass through properly
# shellcheck disable=SC2068
om --env env/"${ENV_FILE}" configure-opsman \
  --config "config/${OPSMAN_CONFIG_FILE}" \
  ${vars_files_args[@]}

Usage

- task: configure-ldap-authentication
  image: platform-automation-image
  file: platform-automation-tasks/tasks/configure-ldap-authentication.yml
  params:
    ENV_FILE: ((foundation))/env/env.yml
    AUTH_CONFIG_FILE: ((foundation))/auth/auth.yml

configure-product

Configures an individual, staged product with settings from a config file.

Not to be confused with Tanzu Operations Manager's built-in import, which reads all deployed products and configurations from a single opaque file, intended for import as part of backup/restore and upgrade lifecycle processes.

See staged-config, which can extract a config file, and upload-and-stage-product, which can stage a product that's been uploaded.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: config # contains the product configuration file
- name: env # contains the env file with target OpsMan Information
- name: vars # variable files to be made available
  optional: true
- name: secrets
  # secret files to be made available
  # separate from vars, so they can be store securely
  optional: true
- name: ops-files # operations files to custom configure the product
  optional: true

params:
  CONFIG_FILE:
  # - Required
  # - Filepath to the product configuration YAML file
  # - The path is relative to the root of the `config` input

  VARS_FILES:
  # - Optional
  # - Filepath to the product configuration vars YAML file
  # - The path is relative to root of the task build,
  #   so `vars` and `secrets` can be used.

  OPS_FILES:
  # - Optional
  # - Filepath to the product configuration operations YAML files
  # - The path is relative to root of the task build

  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to root of the `env` input

run:
  path: platform-automation-tasks/tasks/configure-product.sh

Implementation


cat /var/version && echo ""
set -eux

vars_files_args=("")
for vf in ${VARS_FILES}; do
  vars_files_args+=("--vars-file ${vf}")
done

ops_files_args=("")
for of in ${OPS_FILES}; do
  ops_files_args+=("--ops-file ${of}")
done

# ${vars_files_args[@] needs to be globbed to pass through properly
# ${ops_files_args[@] needs to be globbed to pass through properly
# shellcheck disable=SC2068
om --env env/"${ENV_FILE}" configure-product \
  --config "config/${CONFIG_FILE}" \
  ${vars_files_args[@]} \
  ${ops_files_args[@]}

Usage

- task: configure-pks
  image: platform-automation-image
  file: platform-automation-tasks/tasks/configure-product.yml
  input_mapping:
    config: configuration
    env: configuration
    vars: configuration
  params:
    CONFIG_FILE: foundations/((foundation))/config/pks.yml
    ENV_FILE: foundations/config/env.yml
    VARS_FILES: |
      vars/foundations/((foundation))/vars/director.yml
      vars/foundations/((foundation))/vars/pks.yml

configure-new-certificate-authority

Creates a new certificate authority on Tanzu Operations Manager. This can either create a new CA using CredHub or create a new CA using a provided certificate and private key in PEM format via the certs/ input.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information
- name: certs # contains the cert and private key for the CA
  optional: true
  # certs/certificate.pem and certs/privatekey.pem will be in inside the certs folder

params:
  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML

run:
  path: platform-automation-tasks/tasks/configure-new-certificate-authority.sh

Implementation

cat /var/version && echo ""
set -eux

if [[ -f "certs/certificate.pem" && -f "certs/privatekey.pem" ]]; then
  om --env env/"${ENV_FILE}" create-certificate-authority \
   --format json \
   --certificate-pem "$(<certs/certificate.pem)" \
   --private-key-pem "$(<certs/privatekey.pem)"
else
  om --env env/"${ENV_FILE}" generate-certificate-authority
fi

Usage

- task: create-root-ca
  image: platform-automation-image
  file: platform-automation-tasks/tasks/configure-new-certificate-authority.yml
  input_mapping:
    env: configuration
  params:
    ENV_FILE: foundations/config/env.yml

configure-saml-authentication

Configures Tanzu Operations Manager with an external SAML user store and admin user account. See configure-authentication to configure an internal user store, and configure-ldap-authentication to configure with LDAP.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information
- name: config # contains the auth configuration

params:
  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to root of the `env` input

  AUTH_CONFIG_FILE: auth.yml
  # - Required
  # - Filepath of the authorization config YAML
  # - The path is relative to root of the `config` input

  VARS_FILES:
  # - Optional
  # - Filepath to the Ops Manager vars YAML file
  # - The path is relative to root of the task build
  # - These vars can come from the `env` or `config` inputs

run:
  path: platform-automation-tasks/tasks/configure-saml-authentication.sh

Implementation


cat /var/version && echo ""
set -eux

vars_files_args=("")
for vf in ${VARS_FILES}; do
  vars_files_args+=("--vars-file ${vf}")
done

# ${vars_files_args[@] needs to be globbed to pass through properly
# shellcheck disable=SC2068
om --env env/"${ENV_FILE}" --skip-ssl-validation configure-saml-authentication \
  --config config/"${AUTH_CONFIG_FILE}" \
  ${vars_files_args[@]}

Usage

- task: configure-saml-authentication
  image: platform-automation-image
  file: platform-automation-tasks/tasks/configure-saml-authentication.yml
  params:
    ENV_FILE: ((foundation))/env/env.yml
    AUTH_CONFIG_FILE: ((foundation))/auth/auth.yml
Note BOSH admin client: By default, this task creates a BOSH admin client. This is helpful for some advanced workflows that involve communicating directly with the BOSH Director. It is possible to disable this behavior; see the config file documentation for details.

Configuring SAML has two different auth flows for the UI and the task. The UI will have a browser based login flow. The CLI will require client-id and client-secret as it cannot do a browser login flow.

For more details on using SAML, see Tanzu Operations Manager documentation.

For details on the config file expected in the config input, please see Generating an Auth file.

create-vm

Creates an unconfigured Tanzu Operations Manager VM.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: state # contains the state for the vm
- name: config # contains the product configuration file
- name: image # contains the image file to be installed
- name: vars # variable files to be made available
  optional: true
- name: secrets
  # secret files to be made available
  # separate from vars, so they can be store securely
  optional: true

outputs:
- name: generated-state #contains the updated state file


params:
  VARS_FILES:
  # - Optional
  # - Filepath to the Ops Manager vars YAML file
  # - The path is relative to root of the task build,
  #   so `vars` and `secrets` can be used.

  OPSMAN_CONFIG_FILE: opsman.yml
  # - Required
  # - Filepath of the opsman config YAML
  # - The path is relative to root of the `config` input

  STATE_FILE: state.yml
  # - Required
  # - Filepath of the state YAML file
  # - The path is relative to root of the `state` output
  # - if the filename includes "$timestamp",
  #   for example "state-$timestamp.yml",
  #   the final filename will include the current timestamp.
  #   - this is necessary if using an "S3 compatible" blobstore
  #     that doesn't support versioned blobs
  #   - timestamped filenames will need to be represented
  #     with a glob-style wildcard in tasks that use this state file
  #     (such as state-*.yml)

run:
  path: platform-automation-tasks/tasks/create-vm.sh

Implementation


cat /var/version && echo ""
set -eux

vars_files_args=("")
for vf in ${VARS_FILES}; do
  vars_files_args+=("--vars-file ${vf}")
done

# '$timestamp' must be a literal, because envsubst uses it as a filter
# this allows us to avoid accidentally interpolating anything else.
# shellcheck disable=SC2016
input_state_file="$(echo "${STATE_FILE}" | env timestamp='*' envsubst '$timestamp')"

# '$timestamp' must be a literal, because envsubst uses it as a filter
# this allows us to avoid accidentally interpolating anything else.
# shellcheck disable=SC2016
output_file_name="$(echo "${STATE_FILE}" | env timestamp="$(date '+%Y%m%d.%-H%M.%S+%Z')" envsubst '$timestamp')"
generated_state_file_name="$(basename "${output_file_name}")"

export IMAGE_FILE
IMAGE_FILE="$(find image/*.{yml,ova,raw} 2>/dev/null | head -n1)"

if [ -z "${IMAGE_FILE}" ]; then
  echo "No image file found in image input."
  echo "Contents of image input:"
  ls -al image
  exit 1
fi

# ${vars_files_args[@] needs to be globbed to split properly (SC2068)
# input_state_file need to be globbed (SC2086)
# shellcheck disable=SC2068,SC2086
om vm-lifecycle create-vm \
  --config "config/${OPSMAN_CONFIG_FILE}" \
  --image-file "${IMAGE_FILE}" \
  --state-file state/${input_state_file} \
  ${vars_files_args[@]}

# input_state_file need to be globbed (SC2086)
# shellcheck disable=SC2086
cp state/${input_state_file} "generated-state/${generated_state_file_name}"

Usage

- task: create-vm
  image: platform-automation-image
  file: platform-automation-tasks/tasks/create-vm.yml
  input_mapping:
    image: opsman-image
    config: configuration
    vars: configuration
  params:
    OPSMAN_CONFIG_FILE: foundations/((foundation))/config/opsman.yml
    STATE_FILE: state-((foundation)).yml
    VARS_FILES: vars/foundations/((foundation))/vars/director.yml
  ensure: &put-state
    do:
    - put: state
      params:
        file: generated-state/state-((foundation)).yml

This task requires a config file specific to the IaaS being deployed to. See the configuration page for more specific examples.

The task does specific CLI commands for the creation of the Tanzu Operations Manager VM on each IAAS. See the following for more information:

AWS

  1. Requires the image YAML file from the Broadcom Support portal
  2. Validates the existence of the VM if defined in the statefile, if so do nothing
  3. Chooses the correct AMI to use based on the provided image YAML file from the Broadcom Support portal
  4. Creates the VM configured using the opsman config and the image YAML. This only attaches existing infrastructure to a newly created VM. This does not create any new resources
  5. The public IP address, if provided, is assigned after successful creation

Azure

  1. Requires the image YAML file from the Broadcom Support portal
  2. Validates the existence of the VM if defined in the statefile, if so do nothing
  3. Copies the image (of the OpsMan VM from the specified region) as a blob into the specified storage account
  4. Creates the Tanzu Operations Manager image
  5. Creates a VM from the image. This will use unmanaged disk (if specified), and assign a public and/or private IP. This only attaches existing infrastructure to a newly createdVM. This does not create any new resources.

GCP

  1. Requires the image YAML file from the Broadcom Support portal
  2. Validates the existence of the VM if defined in the statefile, if so do nothing
  3. Creates a compute image based on the region specific Tanzu Operations Manager source URI in the specified Tanzu Operations Manager account
  4. Creates a VM from the image. This will assign a public and/or private IP address, VM sizing, and tags. This does not create any new resources.

OpenStack

  1. Requires the image YAML file from the Broadcom Support portal
  2. Validates the existence of the VM if defined in the statefile; if so do nothing
  3. Recreates the image in OpenStack, if it already exists, to validate that you are using the correct version of the image
  4. Creates a VM from the image. This does not create any new resources
  5. The public IP address, if provided, is assigned after successful creation

vSphere

  1. Requires the OVA image from the Broadcom Support portal
  2. Validates the existence of the VM if defined in the statefile, if so do nothing
  3. Build ipath from the provided datacenter, folder, and VM name (vmname) provided in the config file. The created VM is stored on the generated path. If folder is not provided, the VM will be placed in the datacenter.
  4. Creates a VM from the image provided to the create-vm command. This does not create any new resources

credhub-interpolate

Interpolate credhub entries into configuration files.

Caution Deprecation Notice: The credhub-interpolate task will be deprecated in future major versions of Platform Automation Toolkit.

Note The prepare-tasks-with-secrets task replaces the credhub-interpolate task on Concourse versions 5.x+ and provides additional benefits.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: files
# contains YAML files with extension `.yml`.
# Each one of these files will have their values interpolated from credhub.
# For examples, run: `credhub interpolate --help`
# (minimum version >= 2.1.0 required)

outputs:
- name: interpolated-files
# Contains only YAML files found and interpolated by this task.
# Maintains the filestructure of the `files` input.

# all params are required to be filled out
params:

  CREDHUB_CLIENT:
  CREDHUB_SECRET:
  CREDHUB_SERVER:
  # - Required
  # - Credentials to talk to credhub server

  CREDHUB_CA_CERT:
  # - Optional
  # - This is only necessary if your Concourse worker
  #   is not already configured to trust the CA used for CredHub.
  # - If more than one CA cert is required (ie the UAA),
  #   the CA certs can be concatenated together and separated by a newline.
  #   For example,
  #   CREDHUB_CA_CERT: |
  #     -----BEGIN CERTIFICATE-----
  #     ...credhub cert...
  #     -----END CERTIFICATE-----
  #     -----BEGIN CERTIFICATE-----
  #     ...UAA cert...
  #     -----END CERTIFICATE-----

  PREFIX:
  # - Required
  # - Prefix flag used by credhub interpolate

  INTERPOLATION_PATHS: '.'
  # - Required
  # - Path the contains the files to read from
  # - This is a space separated list of directories
  #   the paths are all evaluated relative to files/

  SKIP_MISSING: true
  # Optional
  # Change to false to have strict interpolation
  # and fail if params are missing from vars

run:
  path: platform-automation-tasks/tasks/credhub-interpolate.sh

Implementation


cat /var/version && echo ""
set -euo pipefail

# NOTE: The credhub cli does not ignore empty/null environment variables.
# https://github.com/cloudfoundry-incubator/credhub-cli/issues/68
if [ -z "${CREDHUB_CA_CERT}" ]; then
  unset CREDHUB_CA_CERT
fi

credhub --version

if [ -z "${PREFIX}" ]; then
  echo "Please specify a PREFIX. It is required."
  exit 1
fi

# $INTERPOLATION_PATHS needs to be globbed to read multiple files
# shellcheck disable=SC2086
files=$(cd files && find ${INTERPOLATION_PATHS} -type f -name '*.yml' -follow)

flags=("")
if [ "${SKIP_MISSING}" == "true" ]; then
  flags+=("--skip-missing")
fi

for file in ${files}; do
  echo "interpolating files/${file}"
  mkdir -p interpolated-files/"$(dirname "${file}")"

  # ${flags[@] needs to be globbed to pass through properly
  # shellcheck disable=SC2068
  credhub interpolate --prefix "${PREFIX}" \
    --file files/"${file}" ${flags[@]} \
    >interpolated-files/"${file}"
done

Usage

- task: interpolate-env-creds
  image: platform-automation-image
  file: platform-automation-tasks/tasks/credhub-interpolate.yml
  params:
    CREDHUB_CLIENT: ((credhub-client))
    CREDHUB_SECRET: ((credhub-secret))
    CREDHUB_SERVER: ((credhub-server))
    PREFIX: '/pipeline/vsphere'
    INTERPOLATION_PATHS: ((foundation))/config
    SKIP_MISSING: true
  input_mapping:
    files: configuration
  output_mapping:
    interpolated-files: interpolated-configs

This task requires a valid credhub with UAA client and secret. For information about how to set this up, see Using a secrets store to store credentials.

delete-certificate-authority

Deletes all inactive certificate authorities from the Tanzu Operations Manager.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information

params:
  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML

run:
  path: platform-automation-tasks/tasks/delete-certificate-authority.sh

Implementation


cat /var/version && echo ""
set -eux

om --env env/"${ENV_FILE}" delete-certificate-authority --all-inactive

Usage

- task: delete-certificate-authority
  image: platform-automation-image
  file: platform-automation-tasks/tasks/delete-certificate-authority.yml
  input_mapping:
    env: configuration
  params:
    ENV_FILE: foundations/config/env.yml

delete-installation

Deletes the Tanzu Operations Manager installation.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information

params:
  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to root of the `env` input

run:
  path: platform-automation-tasks/tasks/delete-installation.sh

Implementation


cat /var/version && echo ""
set -eux
om --env env/"${ENV_FILE}" delete-installation --force

Usage

- task: delete-installation
  image: platform-automation-image
  file: platform-automation-tasks/tasks/delete-installation.yml
  input_mapping:
    env: configuration
  params:
    ENV_FILE: foundations/config/env.yml

delete-vm

Deletes the Tanzu Operations Manager VM instantiated by create-vm.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: state # contains the state for the vm
- name: config # contains the product configuration file
- name: vars # variable files to be made available
  optional: true
- name: secrets
  # secret files to be made available
  # separate from vars, so they can be store securely
  optional: true

outputs:
- name: generated-state #contains the updated state file

params:
  VARS_FILES:
  # - Optional
  # - Filepath to the Ops Manager vars YAML file
  # - The path is relative to root of the task build,
  #   so `vars` and `secrets` can be used.

  OPSMAN_CONFIG_FILE: opsman.yml
  # - Required
  # - Filepath of the opsman config YAML
  # - The path is relative to root of the `config` input

  STATE_FILE: state.yml
  # - Required
  # - Filepath of the state YAML file
  # - The path is relative to root of the `state` output
  # - if the filename includes "$timestamp",
  #   for example "state-$timestamp.yml",
  #   the final filename will include the current timestamp.
  #   - this is necessary if using an "S3 compatible" blobstore
  #     that doesn't support versioned blobs
  #   - timestamped filenames will need to be represented
  #     with a glob-style wildcard in tasks that use this state file
  #     (such as state-*.yml)

run:
  path: platform-automation-tasks/tasks/delete-vm.sh

Implementation


cat /var/version && echo ""
set -eux

vars_files_args=("")
for vf in ${VARS_FILES}; do
  vars_files_args+=("--vars-file ${vf}")
done

# '$timestamp' must be a literal, because envsubst uses it as a filter
# this allows us to avoid accidentally interpolating anything else.
# shellcheck disable=SC2016
input_state_file="$(echo "${STATE_FILE}" | env timestamp='*' envsubst '$timestamp')"

# '$timestamp' must be a literal, because envsubst uses it as a filter
# this allows us to avoid accidentally interpolating anything else.
# shellcheck disable=SC2016
output_file_name="$(echo "${STATE_FILE}" | env timestamp="$(date '+%Y%m%d.%-H%M.%S+%Z')" envsubst '$timestamp')"
generated_state_file_name="$(basename "${output_file_name}")"

# ${vars_files_args[@] needs to be globbed to split properly (SC2068)
# input_state_file need to be globbed (SC2086)
# shellcheck disable=SC2068,SC2086
om vm-lifecycle delete-vm \
  --config "config/${OPSMAN_CONFIG_FILE}" \
  --state-file state/${input_state_file} \
  ${vars_files_args[@]}

# input_state_file need to be globbed (SC2086)
# shellcheck disable=SC2086
cp state/${input_state_file} "generated-state/${generated_state_file_name}"

Usage

- task: delete-vm
  image: platform-automation-image
  file: platform-automation-tasks/tasks/delete-vm.yml
  input_mapping:
    config: configuration
  params:
    OPSMAN_CONFIG_FILE: foundations/((foundation))/config/opsman.yml
    STATE_FILE: state-((foundation)).yml
  ensure:
    do:
    - put: state
      params:
        file: generated-state/state-((foundation)).yml

This task requires the state file generated create-vm.

The task does specific CLI commands for the deletion of the Tanzu Operations Manager VM and resources on each IAAS. See the following for more information:

AWS

  1. Deletes the VM

Azure

  1. Deletes the VM
  2. Attempts to delete the associated disk
  3. Attempts to delete the associated nic
  4. Attempts to delete the associated image

GCP

  1. Deletes the VM
  2. Attempts to delete the associated image

OpenStack

  1. Deletes the VM
  2. Attempts to delete the associated image

vSphere

  1. Deletes the VM

download-and-upload-product

This is an advanced task. If a product (and its associated stemcell) has already been uploaded to Tanzu Operations Manager then it will not re-download and upload. This is helpful when looking for a fast-feedback loop for building pipelines.

This task is similar to download-product, as it takes the same product config. There are no outputs for this task because the products (and stemcell) don't need to be shared downstream.

Caution This currently only works with product source being the Broadcom Support portal.

Task


---
platform: linux

inputs:
  - name: platform-automation-tasks
  - name: config # contains download-file config file
  - name: env # contains the env file with target OpsMan Information
  - name: vars # variable files to be made available
    optional: true
  - name: secrets
    # secret files to be made available
    # separate from vars, so they can be store securely
    optional: true
params:
  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to root of the `env` input

  CONFIG_FILE: download-config.yml
  # - Required
  # - Filepath to the product configuration YAML file
  # - The path is relative to the root of the `config` input

  VARS_FILES:
  # - Optional
  # - Filepath to the product configuration vars YAML file
  # - The path is relative to root of the task build,
  #   so `vars` and `secrets` can be used.

  FLOATING_STEMCELL: true
  # - Optional
  # - Assigns the stemcell to all compatible products
  # - If false, a user is required to run the assign-stemcell task

run:
  path: platform-automation-tasks/tasks/download-and-upload-product.sh

Implementation


cat /var/version && echo ""
set -eux

if [ -z "${ENV_FILE}" ]; then
  echo "No env file was provided."
  echo "Please provide and env file to talk to the Ops Manager."
  exit 1
fi

vars_files_args=("")
for vf in ${VARS_FILES}; do
  vars_files_args+=("--vars-file ${vf}")
done

mkdir -p downloaded-product
mkdir -p downloaded-stemcell

# ${vars_files_args[@] needs to be globbed to pass through properly
# shellcheck disable=SC2068
om --env env/"${ENV_FILE}" download-product \
  --config config/"${CONFIG_FILE}" ${vars_files_args[@]} \
  --output-directory downloaded-product \
  --stemcell-output-directory downloaded-stemcell \
  --check-already-uploaded

downloaded_product="$(find downloaded-product/*.pivotal 2>/dev/null | head -n1)"
if [ "${downloaded_product}" != "" ]; then
  om --env env/"${ENV_FILE}" upload-product \
    --product "${downloaded_product}"
fi

downloaded_product="$(find downloaded-product/*.tgz 2>/dev/null | head -n1)"
if [ "${downloaded_product}" != "" ]; then
  om --env env/"${ENV_FILE}" upload-stemcell \
    --stemcell "${downloaded_product}"
fi

downloaded_stemcell="$(find downloaded-stemcell/*.tgz 2>/dev/null | head -n1)"
if [ "${downloaded_stemcell}" != "" ]; then
  floatingArg=""
  if [ "${FLOATING_STEMCELL}" == "true" ] || [ "${FLOATING_STEMCELL}" == "false" ]; then
    floatingArg="--floating=${FLOATING_STEMCELL}"
  fi

  om --env env/"${ENV_FILE}" upload-stemcell \
    --stemcell "${downloaded_stemcell}" "${floatingArg}"
fi

Usage

- task: download-and-upload-pas
  image: platform-automation-image
  file: platform-automation-tasks/tasks/download-and-upload-product.yml
  input_mapping:
    env: configuration
    config: configuration
  params:
    ENV_FILE: foundations/config/env.yml
    CONFIG_FILE: download-product-pivnet/download-tas.yml

download-product

Downloads a product specified in a config file from the Broadcom Support portal: (pivnet), S3(s3), GCS(gcs), or Azure(azure). Optionally, also downloads the latest stemcell for that product.

Downloads are cached, so files are not re-downloaded each time. When downloading from the Broadcom Support portal, the cached file is verified using the the Broadcom Support portal checksum to validate the integrity of that file. If it does not, the file is re-downloaded. When downloading from a supported blobstore the cached file is not-verified, as there is no checksum from those blobstore APIs to use.

Outputs can be persisted to any supported blobstore using a put to an appropriate resource for later use with download-product using the SOURCE parameter, or used directly as inputs to upload-and-stage-product and upload-stemcell tasks.

This task requires a download-product config file.

If stemcell-iaas is specified in the download-product config file, and the specified product is a .pivotal file, download-product will attempt to download the stemcell for the product. It will retrieve the latest compatible stemcell for the specified IaaS. The valid IaaSs are:

  • aws
  • azure
  • google
  • openstack
  • vsphere

If a configuration for S3, GCS, or Azure is present in the download-product config file, the slug and version of the downloaded product file will be prepended in brackets to the filename.
For example:

  • original-pivnet-filenames:

    ops-manager-aws-2.5.0-build.123.yml
    cf-2.5.0-build.45.pivotal
    
  • download-product-filenames if blobstore configuration is present:

    [ops-manager,2.5.0]ops-manager-aws-2.5.0-build.123.yml
    [elastic-runtime,2.5.0]cf-2.5.0-build.45.pivotal
    

This is to allow the same config parameters that let us select a file from the Broadcom Support portal select it again when pulling from the supported blobstore. Note that the filename will be unchanged if supported blobstore keys are not present in the configuration file. This avoids breaking current pipelines.

Caution When using the s3 resource in Concourse: If you are using a regexp in your s3 resource definition that explicitly requires the the Broadcom Support portal filename to be the start of the regex, (that is, the pattern starts with ^) this won't work when using S3 config. The new file format preserves the original filename, so it is still possible to match on that, but if you need to match from the beginning of the filename, that will have been replaced by the prefix described earlier.

Note When specifying Tanzu Application Service [Windows]: This task will automatically download and inject the winfs for pas-windows.

Caution This task cannot download the stemcell for pas-windows on vSphere. To build this stemcell manually, see Creating a vSphere Windows stemcell using stembuild in the VMware Tanzu Application Service documentation.

Note When the download product config only has the Broadcom Support portal credentials, it will not add the prefix to the downloaded product. For example, example-product.pivotal from the Broadcom Support portal will be displayed in the output as example-product.pivotal.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: config # contains download-file config file
- name: vars # variable files to be made available
  optional: true
- name: secrets
  # secret files to be made available
  # separate from vars, so they can be store securely
  optional: true

outputs:
- name: downloaded-product
- name: downloaded-stemcell
- name: assign-stemcell-config

caches:
- path: downloaded-product
- path: downloaded-stemcell

params:
  CONFIG_FILE: download-config.yml
  # - Required
  # - Filepath to the product configuration YAML file
  # - The path is relative to the root of the `config` input

  VARS_FILES:
  # - Optional
  # - Filepath to the product configuration vars YAML file
  # - The path is relative to root of the task build,
  #   so `vars` and `secrets` can be used.

  SOURCE: pivnet
  # - Required
  # - The source location where products and stemcells are downloaded from.
  # - Values: pivnet, s3, gcs, azure

run:
  path: platform-automation-tasks/tasks/download-product.sh

Implementation


cat /var/version && echo ""
set -eux

if [ -z "${SOURCE}" ]; then
  echo "No source was provided."
  echo "Please provide pivnet, s3, gcs, or azure."
  exit 1
fi

vars_files_args=("")
for vf in ${VARS_FILES}; do
  vars_files_args+=("--vars-file ${vf}")
done

export CACHE_CLEANUP="I acknowledge this will delete files in the output directories"

# ${vars_files_args[@] needs to be globbed to pass through properly
# shellcheck disable=SC2068
om download-product \
  --config config/"${CONFIG_FILE}" ${vars_files_args[@]} \
  --output-directory downloaded-product \
  --stemcell-output-directory downloaded-stemcell \
  --source "${SOURCE}"

{ printf "\nChecking if product needs winfs injected..."; } 2>/dev/null
# shellcheck disable=SC2068
product_slug=$(om interpolate \
  --config config/"${CONFIG_FILE}" ${vars_files_args[@]} \
  --path /pivnet-product-slug)

if [ "${product_slug}" == "pas-windows" ] && [ "${SOURCE}" == "pivnet" ]; then
  product_file=$(om interpolate \
    --config downloaded-product/download-file.json \
    --path /product_path)

  # The winfs-injector determines the necessary windows image,
  # and uses the CF-foundation dockerhub repo
  # to pull the appropriate Microsoft-hosted foreign layer.
  winfs-injector \
    --input-tile "${product_file}" \
    --output-tile "${product_file}"
fi

if [ -e downloaded-product/assign-stemcell.yml ]; then
  mv downloaded-product/assign-stemcell.yml assign-stemcell-config/config.yml
fi

rm -f downloaded-product/download-file.json

Broadcom Support Portal Usage (formerly Tanzu Network)

- name: fetch-pks
  plan:
  - in_parallel:
    - get: daily
      trigger: true
    - get: platform-automation-image
      params:
        unpack: true
    - get: platform-automation-tasks
      params:
        unpack: true
    - get: configuration
  - task: prepare-tasks-with-secrets
    <<: *prepare-tasks-with-secrets
  - task: download-pks-product-and-stemcell
    image: platform-automation-image
    file: platform-automation-tasks/tasks/download-product.yml
    params:
      CONFIG_FILE: download-product-pivnet/download-pks.yml
    input_mapping:
      config: configuration
    output_mapping: {downloaded-stemcell: pks-stemcell}
  - in_parallel:
      - put: pks-product
        params:
          file: downloaded-product/*.pivotal
      - put: pks-stemcell
        params:
          file: pks-stemcell/*.tgz

S3 Usage

- task: download-pks
  image: platform-automation-image
  file: platform-automation-tasks/tasks/download-product.yml
  input_mapping:
    config: configuration
    vars: configuration
  params:
    CONFIG_FILE: foundations/((foundation))/config/download-pks.yml
    VARS_FILES: vars/foundations/((foundation))/vars/versions.yml
    SOURCE: s3
  output_mapping:
    downloaded-product: pks-product
    downloaded-stemcell: pks-stemcell

GCS Usage

- task: download-pas
  image: platform-automation-image
  file: platform-automation-tasks/tasks/download-product.yml
  params:
    CONFIG_FILE: download-product/pas.yml
    SOURCE: gcs
  input_mapping:
    config: configuration
  output_mapping:
    downloaded-product: pas-product
    downloaded-stemcell: pas-stemcell

Azure Usage

- task: download-pas
  image: platform-automation-image
  file: platform-automation-tasks/tasks/download-product.yml
  params:
    CONFIG_FILE: download-product/pas.yml
    SOURCE: azure
  input_mapping:
    config: configuration
  output_mapping:
    downloaded-product: pas-product
    downloaded-stemcell: pas-stemcell

expiring-certificates

Returns a list of certificates that are expiring within a specified time frame. These certificates can be Tanzu Operations Manager or CredHub certificates. This is a purely informational task.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information

params:
  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to root of the `env` input

  EXPIRES_WITHIN:
  # - Required
  # - Example: "3m" is 3 months
  # - Check for certificates expiring within the defined time period
  # - Supports a time period defined with a suffix of:
  #   days(d), weeks(w), months(m) and years(y)

run:
  path: platform-automation-tasks/tasks/expiring-certificates.sh

Implementation


cat /var/version && echo ""
set -eux

if [ -z "${EXPIRES_WITHIN}" ]; then
  echo "The parameter EXPIRES_WITHIN is required"
  exit 1
fi

om --env env/"${ENV_FILE}" expiring-certificates \
  --expires-within "${EXPIRES_WITHIN}"

Usage

- task: expiring-certificates
  image: platform-automation-image
  file: platform-automation-tasks/tasks/expiring-certificates.yml
  input_mapping:
    env: configuration
  params:
    ENV_FILE: foundations/config/env.yml
    EXPIRES_WITHIN: 2m

export-installation

Exports an existing Tanzu Operations Manager to a file.

This is the first part of the backup/restore and upgrade lifecycle processes. This task is used on a fully installed and healthy Tanzu Operations Manager to export settings to an upgraded version of Tanzu Operations Manager.

To use with non-versioned blobstore, you can override INSTALLATION_FILE param to include $timestamp, then the generated installation file will include a sortable timestamp in the filename.

example:

params:
  INSTALLATION_FILE: installation-$timestamp.zip

Note The timestamp is generated using the time on Concourse worker. If the time is different on different workers, the generated timestamp may fail to sort correctly. Changing the time or timezone on workers might interfere with ordering.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information

outputs:
- name: installation # will contain the exported installation

params:
  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to root of the `env` input

  INSTALLATION_FILE: installation-$timestamp.zip
  # - Required
  # - Filepath of the installation ZIP file
  # - The path is relative to root of the `installation` output
  # - if the filename includes "$timestamp",
  #   for example "installation-$timestamp.zip",
  #   the final filename will include the current timestamp.
  #   - this is necessary if using an "S3 compatible" blobstore
  #     that doesn't support versioned blobs
  #   - timestamped filenames will need to be represented
  #     with a glob-style wildcard in the `upgrade-opsman` task configuration
  #     (the default will work with the example provided above).

run:
  path: platform-automation-tasks/tasks/export-installation.sh

Implementation


cat /var/version && echo ""
set -eux

timestamp="$(date '+%Y%m%d.%-H%M.%S+%Z')"
export timestamp

# '$timestamp' must be a literal, because envsubst uses it as a filter
# this allows us to avoid accidentally interpolating anything else.
# shellcheck disable=SC2016
output_file_name="$(echo "${INSTALLATION_FILE}" | envsubst '$timestamp')"

om --env env/"${ENV_FILE}" export-installation \
  --output-file installation/"${output_file_name}"

Usage

- task: export-installation
  image: platform-automation-image
  file: platform-automation-tasks/tasks/export-installation.yml
  input_mapping:
    env: configuration
  params:
    ENV_FILE: foundations/config/env.yml
    INSTALLATION_FILE: ((foundation))-installation-$timestamp.zip

Important VMware recommends persisting the zip file exported from export-installation to an external file store (for example, S3) on a regular basis. The exported installation can restore the Tanzu Operations Manager to a working state if it is not working.

generate-certificate

Generate a certificate, signed by the active Tanzu Operations Manager certificate authority, for the domains specified in the DOMAINS environment variable.

This task outputs certificate, containing certificate.pem and privatekey.pem for the new certificate.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information

outputs:
- name: certificate # contains the newly created Certificate and private key

params:
  DOMAINS:
  # - Required
  # - The domains required to generate the certificates

  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to root of the `env` input

run:
  path: platform-automation-tasks/tasks/generate-certificate.sh

Implementation


cat /var/version && echo ""
set -eux

om --env env/"${ENV_FILE}" generate-certificate -d "${DOMAINS}" > /tmp/certificate.json
om interpolate -c /tmp/certificate.json --path /certificate > certificate/certificate.pem
om interpolate -c /tmp/certificate.json --path /key > certificate/privatekey.pem

import-installation

Imports a previously exported installation to Tanzu Operations Manager.

This is a part of the backup/restore and upgrade lifecycle processes. This task is used after an installation has been exported and a new Tanzu Operations Manager has been deployed, but before the new Tanzu Operations Manager is configured.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: env # contains the environment information about the OpsMan
- name: installation # contains the installation to be imported

params:
  ENV_FILE: env.yml
  # - Required
  # - Filepath of the environment config YAML
  # - The path is relative to root of the `env` input
  # - The env file _must_ contain the `decryption-passphrase`
  #   while it's optional for other tasks, this one requires it.

  INSTALLATION_FILE: installation*.zip
  # - Required
  # - Filepath of the installation ZIP file
  # - The filepath provided can be wildcard expanded.
  # - The path is relative to root of the `installation` input

run:
  path: platform-automation-tasks/tasks/import-installation.sh

Implementation


cat /var/version && echo ""
set -eux

# INSTALLATION_FILE needs to be globbed
# shellcheck disable=SC2086
om --env env/"${ENV_FILE}" --skip-ssl-validation import-installation \
  --installation installation/${INSTALLATION_FILE}

Usage

- task: import-installation
  image: platform-automation-image
  file: platform-automation-tasks/tasks/import-installation.yml
  input_mapping:
    env: configuration
  params:
    ENV_FILE: ((foundation))/env/env.yml
    INSTALLATION_FILE: installation-*.zip

make-git-commit

Copies a single file into a repo and makes a commit. This is useful for persisting the state output of tasks that manage the VM, such as:

It is also useful for persisting the configuration output from:

Note This commits all changes present in the repo used for the repository input, in addition to copying in a single file.

Important This does not perform a git push. You must put the output of this task to a git resource to persist it.

Task


---
platform: linux

inputs:
  - name: platform-automation-tasks
  - name: repository
  # - This must be an initialized git repository.
  # - Note that any changes present in this input
  #   will be committed along with the file copied in
  #   by this task.
  - name: file-source
  # - This is the input folder containing the file to be committed.
  #   Typically, this will from some other task
  #   with an output that needs to be persisted.

outputs:
  - name: repository-commit

params:
  FILE_SOURCE_PATH:
  # - Required
  # - Filepath to be copied into the git repo
  #   before a commit is created
  # - Relative to the root of the `file-source` input

  FILE_DESTINATION_PATH:
  # - Required
  # - Filepath to write the file specified by FILE_SOURCE_PATH
  # - Relative to the root of the `repository` input

  GIT_AUTHOR_NAME:
  # - Required
  # - Used to configure the human-readable
  #   name in the `author` field of the commit

  GIT_AUTHOR_EMAIL:
  # - Required
  # - Used to configure the email address
  #   in the `author` field of the commit

  COMMIT_MESSAGE:
  # - Required
  # - Specify a commit message to be used
  #   for all commits made by this task.

run:
  path: platform-automation-tasks/tasks/make-git-commit.sh

Implementation


cat /var/version && echo ""
set -eu

git clone repository repository-commit

FILE_DESTINATION_PATH="repository-commit/${FILE_DESTINATION_PATH}"
destination_directory=$(dirname "${FILE_DESTINATION_PATH}")

if [ ! -d "${destination_directory}" ]; then
  echo "Directory ${destination_directory} does not exist in repository, creating it..."
  mkdir -p "${destination_directory}"
fi

cp file-source/"${FILE_SOURCE_PATH}" \
  "${FILE_DESTINATION_PATH}"
cd repository-commit
git config user.name "${GIT_AUTHOR_NAME}"
git config user.email "${GIT_AUTHOR_EMAIL}"
if [[ -n $(git status --porcelain) ]]; then
  git add -A
  git commit -m "${COMMIT_MESSAGE}" --allow-empty
fi

Usage

- task: make-commit
  image: platform-automation-image
  file: platform-automation-tasks/tasks/make-git-commit.yml
  input_mapping:
    repository: configuration
    file-source: generated-state
  output_mapping:
    repository-commit: configuration-commit
  params:
    FILE_SOURCE_PATH: state.yml
    FILE_DESTINATION_PATH: state/state.yml
    GIT_AUTHOR_EMAIL: "[email protected]"
    GIT_AUTHOR_NAME: "Platform Automation Bot"
    COMMIT_MESSAGE: 'Update state file'

pre-deploy-check

Checks if the Tanzu Operations Manager director is configured properly and validates the configuration. This feature is only available in Tanzu Operations Manager 2.6+. Additionally, checks each of the staged products and validates they are configured correctly. This task can be run at any time and can be used a a pre-check for apply-changes.

The checks that this task executes are:

  • is configuration complete and valid
  • is the network assigned
  • is the availability zone assigned
  • is the stemcell assigned
  • what stemcell type/version is required
  • are there any unset/invalid properties
  • did any Tanzu Operations Manager verifiers fail

If any of the above checks fail the task will fail. The failed task will provide a list of errors that need to be fixed before an apply-changes operation can start.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information

params:
  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to root of the `env` input

run:
  path: platform-automation-tasks/tasks/pre-deploy-check.sh

Implementation


cat /var/version && echo ""
set -eux

om --env env/"${ENV_FILE}" pre-deploy-check

Usage

- task: pre-deploy-check
  image: platform-automation-image
  file: platform-automation-tasks/tasks/pre-deploy-check.yml
  input_mapping:
    env: configuration
  params:
    ENV_FILE: foundations/config/env.yml

prepare-image

This task modifies the container image with runtime dependencies. CA_CERTS can be added, which can help secure HTTP connections with a proxy server and allows the use of a custom CA on the Tanzu Operations Manager.

Caution Concourse 5+ only: This task uses a Concourse feature that allows inputs and outputs to have the same name. This feature is only available in Concourse v5+. prepare-image does not work with Concourse v4.

Task


---
platform: linux

inputs:
  - name: platform-automation-tasks
  - name: platform-automation-image
  - name: config
    optional: true

outputs:
  - name: platform-automation-image
    # contains the modify image with the ca-certs

params:
  # One or both of the following must be set.
  CA_CERTS:
  # - Optional
  # - Multiple certificates can be concatenated
  #   into a single multi-line string or param
  CA_CERT_FILES:
  # - Optional
  # - Space-separated list of file-paths to valid CA files.
  # - Paths are relative to the `config` input.

run:
  path: platform-automation-tasks/tasks/prepare-image.sh

Implementation


cat /var/version && echo ""
set -eu

if [ -z "${CA_CERTS}" ] && [ -z "${CA_CERT_FILES}" ]; then
  { printf "Either/both CA_CERTS or CA_CERT_FILES is required"; } 2>/dev/null
  exit 1
fi

if [ -n "${CA_CERTS}" ]; then
  echo 'Found certs in CA_CERTS'
  echo "${CA_CERTS}" >/usr/local/share/ca-certificates/custom.crt
fi

if [ -n "${CA_CERT_FILES}" ]; then
  echo 'Found certs in CA_CERT_FILES'
  for cf in ${CA_CERT_FILES}; do
    cat config/"${cf}" >>/usr/local/share/ca-certificates/custom.crt
  done
fi

update-ca-certificates

# copy updated files for certs
rsync -al /etc/ssl/certs/ "${PWD}"/platform-automation-image/rootfs/etc/ssl/certs
rsync -al /usr/local/share/ca-certificates/ "${PWD}"/platform-automation-image/rootfs/usr/local/share/ca-certificates
rsync -al /usr/share/ca-certificates/ "${PWD}"/platform-automation-image/rootfs/usr/share/ca-certificates

Usage

prepare-image: &prepare-image
  image: platform-automation-image
  file: platform-automation-tasks/tasks/prepare-image.yml
  params:
    CA_CERTS: ((opsman-ssl.ca))

prepare-tasks-with-secrets

Modifies task files to include variables needed for config files as environment variables for run-time interpolation from a secret store. See Using a secrets store to store credentials.

Caution Concourse 5+ only: This task uses a Concourse feature that allows inputs and outputs to have the same name. This feature is only available in Concourse v5+. prepare-tasks-with-secrets does not work with Concourse v4.

Task


---
platform: linux

inputs:
  - name: platform-automation-tasks
  - name: tasks
    # Contains the task files that will be modified to contain secrets
    # as environment variables
  - name: config
    # Contains the config files with (()) parameterized variables
  - name: vars
    # Optional input for variables to be made available for use with VARS_PATHS
    # - See the VARS_PATHS param for more information
    optional: true

outputs:
  - name: tasks
    # contains the modified tasks

params:
  CONFIG_PATHS: config
  # - Optional
  # - Paths of the directories containing the config files
  # - The path is relative to root of the task build
  # - Child folders will be recursively searched

  VARS_PATHS:
  # - Optional
  # - Variables found under files in VARS_PATHS
  #   will not be added to tasks for lookup
  #   from Concourse's credential manager.
  #   If VARS_FILES are used in later tasks,
  #   they must be accounted for here to avoid task setup failure.
  # - If VARS_PATH is not set and the vars input is provided,
  #   VARS_PATH will be set to the root of the vars input
  # - The path is relative to root of the task build
  # - Child folders will be recursively searched
  # - Multiple paths can be provided separated by spaces

  TASK_PATH: tasks
  # - Optional
  # - Path of the directory contain the task files.
  # - The path is relative to root of the task build
  # - Child folders will be recursively searched
  # - NOTE: Every *.yml/*.yaml will be considered a task.
  #   It will have issues files that aren't a task.

run:
  path: platform-automation-tasks/tasks/prepare-tasks-with-secrets.sh

Implementation


cat /var/version && echo ""
set -eux

config_file_args=("")
for cp in ${CONFIG_PATHS}; do
  config_file_args+=("--config-dir ${cp}")
done

if [[ -d "vars" && -z "${VARS_PATHS}" ]]; then
  VARS_PATHS=vars
fi

vars_file_args=("")
for vf in ${VARS_PATHS}; do
  vars_file_args+=("--var-dir ${vf}")
done

# ${config_file_args[@] needs to be globbed to pass through properly
# ${vars_paths_args[@] needs to be globbed to pass through properly
# shellcheck disable=SC2068
om vm-lifecycle prepare-tasks-with-secrets \
  --task-dir "$TASK_PATH" \
  ${config_file_args[@]} \
  ${vars_file_args[@]}

Usage

# This task is used in multiple jobs
# The YAML anchor "*prepare-tasks-with-secrets" is used in its place
prepare-tasks-with-secrets: &prepare-tasks-with-secrets
  image: platform-automation-image
  file: platform-automation-tasks/tasks/prepare-tasks-with-secrets.yml
  input_mapping:
    tasks: platform-automation-tasks
    config: configuration
    vars: configuration
  params:
    CONFIG_PATHS: config/foundations/config config/foundations/((foundation))/config
    VARS_PATHS: vars/foundations/((foundation))/vars
  output_mapping:
    tasks: platform-automation-tasks

regenerate-certificates

Regenerates all non-configurable leaf certificates managed by Tanzu Operations Manager using the active certificate authority.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information

params:
  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to root of the `env` input

run:
  path: platform-automation-tasks/tasks/regenerate-certificates.sh

Implementation


cat /var/version && echo ""
set -eux

om --env env/"${ENV_FILE}" regenerate-certificates

Usage

- task: regenerate-certificates
  image: platform-automation-image
  file: platform-automation-tasks/tasks/regenerate-certificates.yml
  input_mapping:
    env: configuration
  params:
    ENV_FILE: foundations/config/env.yml

replicate-product

This replicates the product for use in isolation segments. The task requires a downloaded product prior to replication. The output is a replicated tile with a new name in the metadata and filename.

Note replicate-product does not support storing the replicated product in a non-versioned blobstore, because it cannot generate a unique name. It is recommended to use the replicated tile immediately in the next task rather than storing it and using it in a different job.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: product
# product to be replicated (p-isolation-segment, p-windows-runtime, pas-windows)

outputs:
- name: replicated-product

params:
  REPLICATED_NAME:
  # - Required
  # - The desired name for the replicated product (10 character MAX)
  # - The resulting tile will be "$REPLICATED_NAME.pivotal"

run:
  path: platform-automation-tasks/tasks/replicate-product.sh

Implementation


cat /var/version && echo ""
set -eux

if [[ -z "${REPLICATED_NAME}" ]]; then
  echo "REPLICATED_NAME is a required param"
  exit 1
fi

iso-replicator -name "${REPLICATED_NAME}" \
  -output "replicated-product/${REPLICATED_NAME}.pivotal" \
  -path product/*.pivotal

Usage

- task: replicate-product
  image: platform-automation-image
  file: platform-automation-tasks/tasks/replicate-product.yml
  input_mapping:
    product: pas-windows
  params:
    REPLICATED_NAME: iso-1

revert-staged-changes

Reverts all changes that are currently staged on the Tanzu Operations Manager.

Caution Since revert-staged-changes reverts all changes on a Tanzu Operations Manager, it can conflict with tasks that perform stage or configure operations. Use passed constraints to ensure things run in the order you mean them to.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information

params:
  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to root of the `env` input

run:
  path: platform-automation-tasks/tasks/revert-staged-changes.sh

Implementation


cat /var/version && echo ""
set -eux

om --env env/"${ENV_FILE}" revert-staged-changes

Usage

- task: revert-staged-changes
  image: platform-automation-image
  file: platform-automation-tasks/tasks/revert-staged-changes.yml
  input_mapping:
    env: configuration
  params:
    ENV_FILE: foundations/config/env.yml

run-bosh-errand

Runs a specified BOSH errand directly on the BOSH Director by tunneling through Tanzu Operations Manager.

Caution Tanzu Operations Manager is the main interface for interacting with BOSH, and it has no way of knowing what is happening to the BOSH Director outside of the Tanzu Operations Manager UI context. By using this task, you are accepting the risk that what you are doing cannot be tracked by your Tanzu Operations Manager.

Caution Tanzu Operations Manager, by design, will re-run failed errands for you. As this task interacts with BOSH directly, your errand will not be re-run if it fails. To replicate this retry behavior in your pipeline, use the attempts Concourse feature to run the task more than once.

Task


---
platform: linux

inputs:
- name: env
- name: platform-automation-tasks

params:
  PRODUCT_NAME:
  # - Required
  # - Product containing the errand
  # - Use the product name from the metadata/ops manager api,
  #   not the Broadcom Support portal slug

  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to the root of the `env` input

  ERRAND_NAME:
  # - Required
  # - The name of the errand to be run
  # - The task lists valid errand names as part of execution

  OPSMAN_SSH_PRIVATE_KEY:
  # - Optional
  # - May be required to communicate with the Ops Manager BOSH director
  #   if your Concourse worker doesn't otherwise have a route
  #   to your BOSH Director.
  # - This is the private key for the Ops Manager VM
  #   (used during VM creation)

  OPSMAN_SSH_USERNAME: ubuntu
  # - Will only be used if OPSMAN_SSH_PRIVATE_KEY is set
  # - This is the username used when tunneling via the Ops Manager VM;
  #   the default should work for most cases.

  INSTANCE:
  # - Optional
  # - The instance group the errand will be run on
  # - The errand must already be declared on the instance group
  #   in the deployment manifest.
  # - If INSTANCE is not specified,
  #   the errand will run on all eligible instances in parallel.
  # - Instance group can be further specified with an optional
  #   `/instance-id` - `/first` is valid
  #   if you just want to run on one VM.

run:
  path: platform-automation-tasks/tasks/run-bosh-errand.sh

Implementation


cat /var/version && echo ""
set -eux

# shellcheck source=./setup-bosh-env.sh
source ./platform-automation-tasks/tasks/setup-bosh-env.sh

# ensure desired product is actually deployed, provide list of errands
{ echo "About to try to run your errand." ; } 2> /dev/null
{ echo "If it doesn't work, here is a list of errand names:" ; } 2> /dev/null

om --env "env/${ENV_FILE}" errands --product-name "${PRODUCT_NAME}"
set -x

# determine deployment name, including generated id
staged_products=$(mktemp)
om --env "env/${ENV_FILE}" curl -p /api/v0/staged/products  > "${staged_products}"
installation="$(bosh int "${staged_products}" --path "/type=${PRODUCT_NAME}/installation_name")"


if [ -z "${INSTANCE}" ]; then
  bosh -d "${installation}" run-errand "${ERRAND_NAME}"
else
  bosh -d "${installation}" run-errand "${ERRAND_NAME}" --instance "${INSTANCE}"
fi

Usage

- task: run-bosh-errand
  image: platform-automation-image
  file: platform-automation-tasks/tasks/run-bosh-errand.yml
  input_mapping:
    env: configuration
  params:
    PRODUCT_NAME: cf
    ERRAND_NAME: smoke_tests
    ENV_FILE: foundations/config/env.yml
    OPSMAN_SSH_PRIVATE_KEY: ((ops_manager_ssh_private_key))

send-telemetry

Sends the .tar output from collect-telemetry to VMware.

Note To use the send-telemetry, you must acquire a license key. Contact your VMware representative.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: telemetry-collector-binary
- name: collected-telemetry-data

params:
  API_KEY:
  # required
  # The API key provided by Pivotal after accepting the EULA

  DATA_FILE_PATH:
  # required

run:
  path: platform-automation-tasks/tasks/send-telemetry.sh

Implementation


set -eux

./telemetry-collector-binary/telemetry-collector-linux-amd64 --version

# DATA_FILE_PATH needs to be globbed (SC2086)
# shellcheck disable=SC2086
./telemetry-collector-binary/telemetry-collector-linux-amd64 send \
  --path ${DATA_FILE_PATH}

Usage

- task: send-telemetry-data
  attempts: 3
  image: platform-automation-image
  file: platform-automation-tasks/tasks/send-telemetry.yml
  params:
    API_KEY: no-op-test-key
    DATA_FILE_PATH: collected-telemetry-data/FoundationDetails*.tar

stage-configure-apply

This is an advanced task. Stage a product to Tanzu Operations Manager, configure that product, and apply changes only to that product without applying changes to the rest of the foundation.

Note Tanzu Operations Manager Verifier failures when applying changes will prevent deployment. In cases where these verifiers are incorrectly failing for known reasons, they should be disabled using om. The IGNORE_WARNINGS parameter for the apply-changes, stage-configure-apply, and apply-director-changes tasks allows users to ignore all warnings from ignorable verifiers. In an automation context, disabling only the particular verifiers where failure is well-understood allows other verifiers to continue to provide important feedback. Some verifiers continue to return warnings even when disabled, preventing deployment without the IGNORE_WARNINGS: true param set. If the verifiers that are preventing deployment are known issues based on the environment setup, then it is safe to use the flag.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: config # contains the product configuration file
- name: env # contains the env file with target OpsMan Information
- name: vars # variable files to be made available
  optional: true
- name: secrets
  optional: true
  # secret files to be made available
  # separate from vars, so they can be store securely
- name: ops-files # operations files to custom configure the product
  optional: true
- name: product # contains the product file to be staged
  optional: true
- name: stemcell # contains the stemcell tarball
  optional: true
  # - The stemcell filename is important and must be preserved.
  #   if using the bosh.io Concourse resource,
  #   set `params.preserve_filename: true` on your GET.
- name: assign-stemcell-config # contains the configuration file for assign-stemcell command
  optional: true
  # - Can consume the output of `download-product` task directly
  # - Example config:
  # ---
  # product: cf
  # stemcell: 3468.86

params:
  CONFIG_FILE:
  # - Required
  # - Filepath to the product configuration YAML file
  # - The path is relative to the root of the `config` input

  STAGE_PRODUCT_CONFIG_FILE:
  # - Optional
  # - If not using a product file, this is required
  # - If set, this will be the CONFIG_FILE used
  #   for the stage-product step
  # - The path is relative to root of the `config` input
  # - Required config properties:
  # product-name: cf
  # product-version: 2.9.0

  ASSIGN_STEMCELL_CONFIG_FILE:
  # Optional
  # - Filepath of the assign-stemcell config YAML
  # - The path is relative to root of the `assign-stemcell-config` input
  # - If set, this will assign a stemcell to the specific product
  #   defined in the config

  FLOATING_STEMCELL: true
  # - Optional
  # - Assigns the stemcell to all compatible products
  # - If false, a user is required to run the assign-stemcell task

  UPLOAD_STEMCELL_CONFIG_FILE:
  # - Optional
  # - Path to the config file for upload-stemcell
  # - Relative to the root of the `config` input
  # - If empty, no config will be used; version and sha256 will not be checked
  # - Example config:
  # ---
  # shasum: 6daededd8fb4c341d0cd437a669d732d2fde62cb89716498e6b16f34607a1498

  VARS_FILES:
  # - Optional
  # - Filepath to the product configuration vars YAML file
  # - The path is relative to root of the task build,
  #   so `vars` and `secrets` can be used.

  OPS_FILES:
  # - Optional
  # - Filepath to the product configuration operations YAML files
  # - The path is relative to root of the task build

  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to root of the `env` input

  ALLOW_PENDING_CHANGES: false
  # - Optional
  # - If false, will fail if there are pending changes in OpsMan

  RECREATE: false
  # - Optional
  # - If true, will recreate the VMs for the product
  # - If true, will also recreate the director VM if there are changes

  ERRAND_CONFIG_FILE:
  # - Optional
  # - Filepath of the errand config file
  # - Relative to root of the task build;
  #   for example, `errand-config/errands.yml`
  #   or `env/errands.yml`

  IGNORE_WARNINGS: false
  # - Optional
  # - If true, will not fail when verifiers have warnings,
  #   it will still fail for any errors.
  # - This is not recommended unless unless the warning failure(s)
  #   are well understood.

run:
  path: platform-automation-tasks/tasks/stage-configure-apply.sh

Implementation


cat /var/version && echo ""
set -eux

platform-automation-tasks/tasks/check-pending-changes.sh

if ls stemcell/* 1>/dev/null 2>&1; then
  CONFIG_FILE="${UPLOAD_STEMCELL_CONFIG_FILE}" platform-automation-tasks/tasks/upload-stemcell.sh
fi

CONFIG_FILE="${STAGE_PRODUCT_CONFIG_FILE}" platform-automation-tasks/tasks/stage-product.sh

if [ -n "${ASSIGN_STEMCELL_CONFIG_FILE}" ]; then
  om --env env/"${ENV_FILE}" assign-stemcell \
  --config assign-stemcell-config/"$ASSIGN_STEMCELL_CONFIG_FILE"
fi

platform-automation-tasks/tasks/configure-product.sh

product_file="$(find product/*.pivotal 2>/dev/null | head -n1)"
if [ -f "${product_file}" ]; then
  if [ -n "${STAGE_PRODUCT_CONFIG_FILE}" ]; then
    { printf "\nError: Cannot use both product file and 'STAGE_PRODUCT_CONFIG_FILE'"; } 2>/dev/null
    { printf "\nTo fix: Either remove the product input or unset the 'STAGE_PRODUCT_CONFIG_FILE' param"; } 2>/dev/null
    exit 1
  fi

  product_name="$(om product-metadata \
    --product-path product/*.pivotal \
    --product-name)"
else
  if [ -z "${STAGE_PRODUCT_CONFIG_FILE}" ]; then
    { printf "\nError: Both 'STAGE_PRODUCT_CONFIG_FILE' and the config input OR just the product input must be provided"; } 2>/dev/null
    exit 1
  fi

  vars_files_args=("")
  for vf in ${VARS_FILES}; do
    vars_files_args+=("--vars-file ${vf}")
  done

  ops_files_args=("")
  for of in ${OPS_FILES}; do
    ops_files_args+=("--ops-file ${of}")
  done

  # ${vars_files_args[@] needs to be globbed to pass through properly
  # ${ops_files_args[@] needs to be globbed to pass through properly
  # shellcheck disable=SC2068
  product_name="$(om interpolate \
    -c config/"$STAGE_PRODUCT_CONFIG_FILE" \
    --path /product-name \
    ${vars_files_args[@]} \
    ${ops_files_args[@]}
  )"
fi

flags=()

if [ "${RECREATE}" == "true" ]; then
  flags+=("--recreate-vms")
fi

if [ "${IGNORE_WARNINGS}" == "true" ]; then
  flags+=("--ignore-warnings")
fi

if [ -n "${ERRAND_CONFIG_FILE}" ]; then
  flags+=("--config" "config/${ERRAND_CONFIG_FILE}")
fi

# ${flags[@] needs to be globbed to pass through properly
# shellcheck disable=SC2068
om --env env/"${ENV_FILE}" \
  apply-changes \
  --product-name "${product_name}" \
  ${flags[@]}

Usage

- task: stage-configure-apply
  image: platform-automation-image
  file: platform-automation-tasks/tasks/stage-configure-apply.yml
  attempts: 3
  params:
    CONFIG_FILE: foundations/((foundation))/config/p-telemetry.yml
    STAGE_PRODUCT_CONFIG_FILE: foundations/((foundation))/config/p-telemetry.yml
    ENV_FILE: foundations/config/env.yml
    VARS_FILES: |
      vars/foundations/((foundation))/vars/director.yml
  input_mapping:
    env: configuration
    config: configuration
    vars: configuration

stage-product

Staged a product to the Tanzu Operations Manager specified in the config file.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: product # contains the product file to be staged
  optional: true
- name: config # contains a file with product name and version to be staged
  optional: true
- name: env # contains the env file with target OpsMan Information

params:
  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to root of the `env` input

  CONFIG_FILE:
  # - Optional
  # - Filepath of the stage-product config YAML
  # - This may be used instead of a product file
  # - The path is relative to root of the `config` input
  # - Example config:
  # ---
  # product-name: cf
  # product-version: 2.9.0

run:
  path: platform-automation-tasks/tasks/stage-product.sh

Implementation


cat /var/version && echo ""
set -eux

product_file="$(find product/*.pivotal 2>/dev/null | head -n1)"
if [ -f "${product_file}" ]; then
  if [ -n "${CONFIG_FILE}" ]; then
    { printf "\nError: Cannot use both product file and 'CONFIG_FILE'"; } 2>/dev/null
    { printf "\nTo fix: If using 'stage-product', either remove the product input or unset the 'CONFIG_FILE' param"; } 2>/dev/null
    { printf "\nTo fix: If using 'stage-configure-apply', either remove the product input or unset the 'STAGE_PRODUCT_CONFIG_FILE' param"; } 2>/dev/null
    exit 1
  fi

  product_metadata_name="$(om product-metadata \
    --product-path "${product_file}" \
    --product-name)"

  product_metadata_version="$(om product-metadata \
    --product-path "${product_file}" \
    --product-version)"

  om --env env/"${ENV_FILE}" stage-product \
    --product-name "${product_metadata_name}" \
    --product-version "${product_metadata_version}"
else
  if [ -z "${CONFIG_FILE}" ]; then
    { printf "\nError: If using 'stage-product', both 'CONFIG_FILE' and the config input OR just the product input must be provided"; } 2>/dev/null
    { printf "\nError: If using 'stage-configure-apply', both 'STAGE_PRODUCT_CONFIG_FILE' and the config input OR just the product input must be provided"; } 2>/dev/null
    exit 1
  fi

  om --env env/"${ENV_FILE}" stage-product \
    --config config/"${CONFIG_FILE}"
fi

Usage

- task: upload-and-stage-tas
  image: platform-automation-image
  file: platform-automation-tasks/tasks/stage-product.yml
  input_mapping:
    product: tas-product
    env: configuration
  params:
    ENV_FILE: foundations/config/env.yml

staged-config

Downloads the configuration for a product from Tanzu Operations Manager.

This is not to be confused with Tanzu Operations Manager's built-in export, which puts all deployed products and configurations into a single file, intended for import as part of backup/restore and upgrade lifecycle processes.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information

outputs:
- name: generated-config # will contain the staged product config

params:
  PRODUCT_NAME:
  # - Required
  # - The name of the product config to be exported

  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to root of the `env` input

  SUBSTITUTE_CREDENTIALS_WITH_PLACEHOLDERS: true
  # - Optional
  # - Replace credentials with interpolatable variable names
  # - If set to false, **literal credentials** will be included in the output

run:
  path: platform-automation-tasks/tasks/staged-config.sh
  

Implementation


cat /var/version && echo ""
set -eux

flag=$(
  if "${SUBSTITUTE_CREDENTIALS_WITH_PLACEHOLDERS}"; then
    echo '--include-placeholders'
  else
    echo '--include-credentials'
  fi
)

om --env env/"${ENV_FILE}" staged-config \
  --product-name "${PRODUCT_NAME}" \
  "${flag}" >generated-config/"${PRODUCT_NAME}".yml

Usage

- task: staged-config
  image: platform-automation-image
  file: platform-automation-tasks/tasks/staged-config.yml
  input_mapping:
    env: configuration
  params:
    PRODUCT_NAME: cf
  ensure:
    do:
      - put: state
        params:
          file: generated-state/state.yml

staged-director-config

Downloads configuration for the BOSH director from Tanzu Operations Manager.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information

outputs:
- name: generated-config # will contain the staged product config

params:
  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to root of the `env` input

run:
  path: platform-automation-tasks/tasks/staged-director-config.sh

Implementation


cat /var/version && echo ""
set -eux
om --env env/"${ENV_FILE}" staged-director-config \
  --include-placeholders >generated-config/director.yml

Usage

- task: staged-director-config
  image: platform-automation-image
  file: platform-automation-tasks/tasks/staged-director-config.yml
  input_mapping:
    env: configuration
  ensure:
    do:
      - put: state
        params:
          file: generated-state/state.yml

The configuration is exported to the generated-config output. It does not extract credentials from Tanzu Operations Manager and replaced them all with YAML interpolation (()) placeholders. This is to ensure that credentials are never written to disk. The credentials need to be provided from an external configuration when invoking configure-director.

Note staged-director-config will not be able to grab all sensitive fields in your Tanzu Operations Manager installation (for example: vcenter_username and vcenter_password if using vSphere). To find these missing fields, see the Tanzu Operations Manager API Documentation.

test

An example task to ensure the assets and Docker image are setup correctly in your Concourse pipeline.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks

run:
  path: platform-automation-tasks/tasks/test.sh

Implementation


echo "Platform Automation for PCF version:"
cat /var/version && echo ""

printf "\nom version:"
om -v

set -eux
om vm-lifecycle --help
om --help
{ echo "Successfully validated tasks and image!"; } 2>/dev/null

Usage

- task: test
  file: platform-automation-tasks/tasks/test.yml
  image: platform-automation-image

test-interpolate

An example task to ensure that all required vars are present when interpolating into a base file. For more instruction on this topic, see the variables section.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: config # contains the base configuration file
- name: vars # variable files to be made available
  optional: true

params:
  VARS_FILES:
  # - Optional
  # - Filepath to the vars YAML file
  # - The path is relative to root of the task build
  # - These vars can come from the `vars` or `config` inputs

  CONFIG_FILE: base.yml
  # - Required
  # - Filepath to the base YAML file to interpolate from
  # - The path is relative to root of the task build

  SKIP_MISSING: true
  # - Optional
  # - Change to false to have strict interpolation
  #   and fail if params are missing from vars

run:
  path: platform-automation-tasks/tasks/test-interpolate.sh

Implementation


cat /var/version && echo ""
set -eux

flags=("")
for vf in ${VARS_FILES}; do
  flags+=("--vars-file ${vf}")
done

if [ "${SKIP_MISSING}" == "true" ]; then
  flags+=("--skip-missing")
fi

# ${flags[@] needs to be globbed to pass through properly
# ${vars_files_args[@] needs to be globbed to pass through properly
# shellcheck disable=SC2068
om interpolate --config "config/${CONFIG_FILE}" ${flags[@]}

Usage

- task: test-interpolate
  image: platform-automation-image
  file: platform-automation-tasks/tasks/test-interpolate.yml
  params:
    CONFIG_FILE: foundations/((foundation))/config/download-tas.yml
    SKIP_MISSING: true
  input_mapping:
    config: configuration

update-runtime-config

This is an advanced task. Updates a runtime config on the Tanzu Operations Manager deployed BOSH director. The task will interact with the BOSH director (sometimes via SSH tunnel through the Tanzu Operations Manager), upload BOSH releases, and set a named runtime config. This is useful when installing agents on BOSH deployed VMs that don't have a Tanzu Operations Manager tile.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: config # contains the runtime config file
- name: releases # contains the releases to be uploaded for use with the runtime config
  optional: true
- name: vars # variable files to be made available
  optional: true
- name: env # contains the env file with target OpsMan Information

params:
  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to the root of the `env` input

  CONFIG_FILE: config.yml
  # - Required
  # - Filepath of the runtime config YAML
  # - The path is relative to the root of the `config` input
  # - Information on BOSH runtime configs: https://bosh.io/docs/runtime-config/

  NAME:
  # - Required
  # - The name of the runtime config that will be updated

  RELEASES_GLOB: "*.tgz"
  # - Required
  # - The glob to identify releases with in the releases input.
  # - When using the bosh-io-release resource in Concourse,
  #   it includes release.tgz, sha1, url, and version files.

  OPSMAN_SSH_PRIVATE_KEY:
  # - Optional
  # - May be required to communicate with the Ops Manager BOSH director
  # - This is the private key for the Ops Manager VM (used during VM creation)

  OPSMAN_SSH_USERNAME: ubuntu
  # - Optional
  # - May be required to communicate with the Ops Manager BOSH director
  # - This is the username used when tunneling through the Ops Manager VM

  VARS_FILES:
  # - Optional
  # - Filepaths of the product configuration vars YAML file
  # - The path is relative to the root of the task build,
  #   so `vars` can be used.
run:
  path: platform-automation-tasks/tasks/update-runtime-config.sh

Implementation


cat /var/version && echo ""
set -eu

if [ -z "${NAME}" ]; then
  { printf "\nError: 'NAME' parameter is required"; } 2>/dev/null
  exit 1
fi

# shellcheck source=./setup-bosh-env.sh
source ./platform-automation-tasks/tasks/setup-bosh-env.sh
set -x

if [ -e "releases/" ]; then
  # $RELEASES_GLOB needs to be globbed to pass through properly
  # shellcheck disable=SC2086
  release_files="$(find releases/${RELEASES_GLOB} 2>/dev/null)"
  if [ -n "${release_files}" ]; then
    for rf in ${release_files}; do
      bosh upload-release "${rf}"
    done
  fi
fi

vars_files_args=("")
for vf in ${VARS_FILES}; do
  vars_files_args+=("--vars-file ${vf}")
done

# ${vars_files_args[@] needs to be globbed to pass through properly
# shellcheck disable=SC2068
bosh -n update-config \
  --type runtime \
  --name "${NAME}" \
  config/"${CONFIG_FILE}" \
  ${vars_files_args[@]}

Usage

- task: update-runtime-config
  image: platform-automation-image
  file: platform-automation-tasks/tasks/update-runtime-config.yml
  input_mapping:
    config: configuration
    env: configuration
    releases: bosh-releases
  params:
    CONFIG_FILE: runtime-config.yml
    NAME: my-runtime-config
    OPSMAN_SSH_PRIVATE_KEY: ((opsman-ssh-private-key))

Caution When using runtime configs, Tanzu Operations Manager owns the default runtime config. If you use this task to edit "default" it will be replaced on every Apply Changes. Use the NAME param to provide a non-conflicting runtime config.

upgrade-opsman

Upgrades an existing Tanzu Operations Manager to a new given Tanzu Operations Manager version

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: state # contains the state for the vm
- name: config # contains the OpsMan configuration file
- name: image # contains the image file to be installed
- name: installation # contains the installation to be imported
- name: env # contains the environment information for OpsMan
- name: vars # variable files to be made available
  optional: true
- name: secrets # secret files to be made available
  # separate from vars, so they can be stored securely
  optional: true

outputs:
- name: generated-state #contains the updated state file

params:
  VARS_FILES:
  # - Optional
  # - space-seperated array of filepaths to YAML vars files
  #   to be loaded with the OPSMAN_CONFIG_FILE
  # - relative to root of the task build,
  #   so both `vars` and `secrets` can be used.

  ENV_FILE: env.yml
  # - Required
  # - filepath of the env config YAML
  # - relative to root of the `env` input

  OPSMAN_CONFIG_FILE: opsman.yml
  # - Required
  # - filepath of the opsman config YAML
  # - relative to root of the `config` input
  # - to configure Ops Manager Application Settings
  #   (such as banner, pivnet token, etc)
  #   add this configuration to your opsman.yml

  STATE_FILE: state.yml
  # - Required
  # - Filepath of the state YAML file
  # - The path is relative to root of the `state` output
  # - if the filename includes "$timestamp",
  #   for example "state-$timestamp.yml",
  #   the final filename will include the current timestamp.
  #   - this is necessary if using an "S3 compatible" blobstore
  #     that doesn't support versioned blobs
  #   - timestamped filenames will need to be represented
  #     with a glob-style wildcard in tasks that use this state file
  #     (such as state-*.yml)

  INSTALLATION_FILE: installation*.zip
  # - Required
  # - filepath of the installation ZIP file
  # - can be wildcard expanded
  # - relative to root of the `installation` input

run:
  path: platform-automation-tasks/tasks/upgrade-opsman.sh

Implementation


cat /var/version && echo ""
om -v
set -eux

vars_files_args=("")
for vf in ${VARS_FILES}; do
  vars_files_args+=("--vars-file ${vf}")
done

# '$timestamp' must be a literal, because envsubst uses it as a filter
# this allows us to avoid accidentally interpolating anything else.
# shellcheck disable=SC2016
input_state_file="$(echo "${STATE_FILE}" | env timestamp='*' envsubst '$timestamp')"

# '$timestamp' must be a literal, because envsubst uses it as a filter
# this allows us to avoid accidentally interpolating anything else.
# shellcheck disable=SC2016
output_file_name="$(echo "${STATE_FILE}" | env timestamp="$(date '+%Y%m%d.%-H%M.%S+%Z')" envsubst '$timestamp')"
generated_state_file_name="$(basename "${output_file_name}")"

export IMAGE_FILE
IMAGE_FILE="$(find image/*.{yml,ova,raw} 2>/dev/null | head -n1)"

if [ -z "${IMAGE_FILE}" ]; then
  echo "No image file found in image input."
  echo "Contents of image input:"
  ls -al image
  exit 1
fi

# ${vars_files_args[@] needs to be globbed to split properly (SC2068)
# INSTALLATION_FILE and input_state_file need to be globbed (SC2086)
# shellcheck disable=SC2068,SC2086
om vm-lifecycle upgrade-opsman \
  --config "config/${OPSMAN_CONFIG_FILE}" \
  --image-file "${IMAGE_FILE}" \
  --state-file state/${input_state_file} \
  --installation installation/${INSTALLATION_FILE} \
  --env-file env/"${ENV_FILE}" \
  ${vars_files_args[@]}

# input_state_file could have a "*", and needs to be expanded by the shell
# shellcheck disable=SC2086
cp state/${input_state_file} "generated-state/${generated_state_file_name}"

# ${vars_files_args[@] needs to be globbed to pass through properly
# shellcheck disable=SC2068
om --env env/"${ENV_FILE}" configure-opsman \
  --config "config/${OPSMAN_CONFIG_FILE}" \
  ${vars_files_args[@]}

Usage

- task: upgrade-opsman
  image: platform-automation-image
  file: platform-automation-tasks/tasks/upgrade-opsman.yml
  input_mapping:
    image: opsman-image
    config: configuration
    env: configuration
    vars: configuration
  params:
    ENV_FILE: foundations/config/env.yml
    OPSMAN_CONFIG_FILE: foundations/((foundation))/config/opsman.yml
    STATE_FILE: state-((foundation)).yml
    INSTALLATION_FILE: ((foundation))-installation*.zip
    VARS_FILES: vars/foundations/((foundation))/vars/director.yml
  ensure: *put-state

For more information about this task and how it works, see Recovering and upgrading Tanzu Operations Manager.

upload-and-stage-product

Uploads and stages product to the Tanzu Operations Manager specified in the config file.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: product # contains the product file to be uploaded and staged
- name: env # contains the env file with target OpsMan Information
- name: config # contains the product configuration file
  optional: true

params:
  CONFIG_FILE:
  # - Optional
  # - Path to the config file for the product
  # - Relative to the root of the config input
  # - If empty, no config will be used; version and sha256 will not be checked
  # - Example config:
  # ---
  # product-version: 1.2.3-build.4
  # sha256: 6daededd8fb4c341d0cd437a669d732d2fde62cb89716498e6b16f34607a1498

  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - The path is relative to root of the `env` input

run:
  path: platform-automation-tasks/tasks/upload-and-stage-product.sh

Implementation


cat /var/version && echo ""
set -eux

if [ -z "${CONFIG_FILE}" ]; then
  om --env env/"${ENV_FILE}" upload-product \
    --product product/*.pivotal
else
  om --env env/"${ENV_FILE}" upload-product \
    --product product/*.pivotal --config "config/${CONFIG_FILE}"
fi

product_name="$(om product-metadata \
  --product-path product/*.pivotal \
  --product-name)"
product_version="$(om product-metadata \
  --product-path product/*.pivotal \
  --product-version)"

om --env env/"${ENV_FILE}" stage-product \
  --product-name "${product_name}" \
  --product-version "${product_version}"

Usage

- task: upload-and-stage-pks
  image: platform-automation-image
  file: platform-automation-tasks/tasks/upload-and-stage-product.yml
  input_mapping:
    product: pks-product
    env: configuration
  params:
    ENV_FILE: foundations/config/env.yml

upload-product

Uploads a product to the Tanzu Operations Manager specified in the config file.

If a shasum is provided in the config.yml, the integrity product will be verified with that shasum before uploading.

Task


---
platform: linux

inputs:
- name: platform-automation-tasks
- name: product # contains the product file to be uploaded and staged
- name: env # contains the env file with target OpsMan Information
- name: config # contains the product configuration file
  optional: true

params:
  CONFIG_FILE:
  # - Optional
  # - Path to the config file for the product
  # - Relative to the root of the `config` input
  # - If empty, no config will be used; version and sha256 will not be checked
  # - Example config:
  # ---
  # product-version: 1.2.3-build.4
  # shasum: 6daededd8fb4c341d0cd437a669d732d2fde62cb89716498e6b16f34607a1498
  ENV_FILE: env.yml
  # - Required
  # - Filepath of the env config YAML
  # - Relative to root of the `env` input

run:
  path: platform-automation-tasks/tasks/upload-product.sh

Implementation


cat /var/version && echo ""
set -eux

export OPTIONAL_CONFIG_FLAG=""
if [ -n "${CONFIG_FILE}" ]; then
  export OPTIONAL_CONFIG_FLAG="--config config/${CONFIG_FILE}"
fi
# shellcheck disable=SC2086
om --env env/"${ENV_FILE}" upload-product \
  --product product/*.pivotal \
  ${OPTIONAL_CONFIG_FLAG}

Usage

- task: upload-tas-product
  image: platform-automation-image
  file: platform-automation-tasks/tasks/upload-product.yml
  input_mapping:
    product: tas-product
    env: configuration
  params:
    ENV_FILE: foundations/config/env.yml

upload-stemcell

Uploads a stemcell to Tanzu Operations Manager.

Note that the filename of the stemcell must be exactly as downloaded from the Broadcom Support portal. Tanzu Operations Manager parses this filename to determine the version and OS of the stemcell.

Task


cat /var/version && echo ""
set -eux

export OPTIONAL_CONFIG_FLAG=""
if [ -n "${CONFIG_FILE}" ]; then
  export OPTIONAL_CONFIG_FLAG="--config config/${CONFIG_FILE}"
fi
# shellcheck disable=SC2086
om --env env/"${ENV_FILE}" upload-stemcell \
  --floating="${FLOATING_STEMCELL}" \
  --stemcell "${PWD}"/stemcell/*.tgz \
  ${OPTIONAL_CONFIG_FLAG}

Implementation


cat /var/version && echo ""
set -eux

export OPTIONAL_CONFIG_FLAG=""
if [ -n "${CONFIG_FILE}" ]; then
  export OPTIONAL_CONFIG_FLAG="--config config/${CONFIG_FILE}"
fi
# shellcheck disable=SC2086
om --env env/"${ENV_FILE}" upload-stemcell \
  --floating="${FLOATING_STEMCELL}" \
  --stemcell "${PWD}"/stemcell/*.tgz \
  ${OPTIONAL_CONFIG_FLAG}

Usage

- task: upload-pks-stemcell
  image: platform-automation-image
  file: platform-automation-tasks/tasks/upload-stemcell.yml
  input_mapping:
    env: configuration
    stemcell: pks-stemcell
  params:
    ENV_FILE: foundations/config/env.yml
check-circle-line exclamation-circle-line close-line
Scroll to top icon