Skip to main content

Prepare to use the workflows

Contributors dmp-netapp netapp-aoife
PDFs

You should be familiar with the organization and format of the Astra workflows before using them with a live deployment.

Introduction

A workflow is a sequence of one or more steps needed to accomplish a specific administrative task or goal. Each step in an Astra Control workflow is one of the following:

  • REST API call (with details such as curl and JSON examples)

  • Invocation of another Astra workflow

  • Miscellaneous related task (such as making a required design decision)

The workflows include the core steps and parameters needed to accomplish each task. They provide a starting point for customizing your automation environment.

Note A workflow can contain only one step. These single-step workflows are formatted slightly differently than workflows containing multiple steps. For example, the explicit step name is removed. The action or operation should be clear based on the workflow title.

Workflow categories

There are two broad categories of Astra workflows available based on your deployment model. If you are using Astra Control Center, you should start with the infrastructure workflows and then proceed to the management workflows. When using Astra Control Service, you can typically go directly to the management workflows.

Note The curl samples in the workflows use the URL for Astra Control Service. You need to change the URL when using the on-premises Astra Control Center as appropriate for your environment.

Infrastructure workflows

These workflows deal with the Astra infrastructure, including credentials, buckets, and storage backends. They are needed with Astra Control Center but in most cases can also be used with Astra Control Service. The workflows focus on the tasks required to establish and maintain an Astra managed cluster.

Management workflows

You can use these workflows after you have set up a managed cluster. Management workflows focus on application protection and support operations such as backing up, restoring, and cloning an app.

Common input parameters

The input parameters described below are common to all the curl samples used to illustrate a REST API call.

Note Because these input parameters are universally required, they are not described further in the individual workflows. If additional input parameters are used for a specific curl example, they are described in the section Additional input parameters.

Path parameters

The endpoint path used with every REST API call includes the following parameters. Also see URL format for more information.

Account ID

This is the UUIDv4 value identifying the Astra account where the API operation runs. See Get an API token for more information about locating your account ID.

Request headers

There are several request headers that you may need to include depending on the REST API call.

Authorization

All the API calls in the workflows need an API token to identify the user. You must include the token in the Authorization request header. See Get an API token for more information about generating an API token.

Content type

With the HTTP POST and PUT requests where JSON is included in the request body, you should declare the media type based on the Astra resource. For example, you can include the header Content-Type: application/astra-appSnap+json when creating a snapshot for a managed application.

Accept

You can declare the specific media type of the content you expect in the response based on the Astra resource. For example, you can include the header Accept: application/astra-appBackup+json when listing the backups for a managed application. However, for simplicity the curl samples in the workflows accept all media types.

Presentation of tokens and identifiers

The API token and other ID values used with the curl examples are opaque with no discernible meaning. And so to improve the readability of the samples, the actual token and ID values are not used. Rather, smaller reserved keywords are used which has several benefits:

  • The curl and JSON samples are clearer and easier to understand.

  • Because all the keywords use the same format with brackets and capital letters, you can quickly identify the location and content to insert or extract.

  • No value is lost because the original parameters cannot be copied and used with an actual deployment.

The variables are formatted for use in a Bash shell environment. Each variable begins with a dollar sign and is enclosed in double quotes as needed. This makes them recognizable to Bash. Upper case is consistently used for the names.

Here are some of the common reserved keywords used in the curl examples. This list is not exhaustive and additional keywords are used as needed. Their meaning should be obvious based on the context.

Keyword Type Description

$ACCOUNT_ID

Path

The UUIDv4 value identifying the account where the API operation runs.

$API_TOKEN

Header

The bearer token identifying and authorizing the caller.

$APP_ID

Path

The UUIDv4 value identifying the application for the API call.

Using the examples with Bash

If you use the workflow curl examples directly, you must update the variables they contain with values appropriate for your environment. You can manually edit the examples or rely on the Bash shell to do the substitution for you, as described below.

Note One advantage of using Bash is that you can set the variable values one time in a shell session instead of once per curl command.
Steps

  1. Open the Bash shell provided with Linux or similar operating system.

  2. Set the variable values included in the curl example you want to run. For example:

    $API_TOKEN=SGgpXHeco6M8PLxzIlgbztA4k3_eX4UCa842hOXHBFA=

  3. Copy the curl example from the workflow page and paste it into the shell terminal.

  4. Press ENTER to perform the following tasks:

    1. Substitute the variable values you set.

    2. Execute the curl command.