Automation assets deployment

You must meet the following dependencies before you create an Automation assets instance. A Integration Specialist should carry out these tasks.

• Install the oc OpenShift CLI tool. This is required for tasks such as creating custom keys and credentials. For more information, see Getting started with the CLI in the Red Hat OpenShift documentation.

• Install the operator for Automation assets. See Installation.

• A project must exist for this instance. You can install the Automation assets in a namespace also used by the Platform Navigator.

• If you are using the IBM Entitled Registry, a pull secret must exist in the namespace containing an entitlement key. See Applying your entitlement key.

• You must provide two different types of storage class for use by the Automation assets:

  • Asset data storage - This requires a File RWX volume. For IBM Cloud File the ibmc-file-gold-gid storage class must be used (specifically the gid variant).

  • Asset metadata storage - This requires a Block RWO volume that meets POSIX requirements and has other characteristics as required by CouchDB persistence storage. For IBM Cloud Block, the ibmc-block-gold storage class must be used.

  • For more information on storage classes in OpenShift, see Understanding persistent storage or Cluster storage.

1. Load the Platform Navigator.

2. Click View Capabilities.

3. Click Create Capability.

4. Click Automation assets.

5. Configure the Automation assets using the form.

   Available options:

   Field name	Description	Advanced
   Name	The name you want your instance of Automation assets to have	False
   Namespace	The namespace where your Automation assets should be installed	False
   License acceptance	Read through and accept the license agreement before installing Automation assets	False
   License LI	The code for the license that you have purchased	False
   Asset data storage	An RWX file storage class to be used for asset data. For full details of storage requirements, see Prerequisites.	False
   Asset metadata storage	An RWO block storage class to be used for the asset metadata. For full details of the required storage characteristics, see Prerequisites.	False
   Version	The version of Automation assets that is used to create an instance. This can be a specific version, such as 2020.3.1-0, or a channel, such as 2020.3.1. Selecting a channel enables auto-upgrade for all fix versions. The channel 2020.3.1, for example, auto-upgrades to 2020.3.1-1. When an operator that supports a new fix version is installed, it automatically upgrades any existing Automation assets operands (deployed versions of the operator) to the new version.Important: latest is no longer a supported channel. Any existing Asset Repositories using latest will update to version 2020.3.1-1.Deprecation alert: Automation assets versions 2020.2.1.1 and 2020.2.1-0 are both deprecated, and may no longer be reconciled by future versions of the operator. See the version matrix page for more information on operator and resource version compatibility.	False
   Automation assets API image	The docker registry location for pulling the Automation assets API image	True
   Automation assets UI image	The docker registry location for pulling the Automation assets UI image	True
   Image pull policy	Configure whether you want images to be pulled every time, only if they're not present, or never	True
   Image pull secrets	Configure the secret used for pulling images. If you're using the Entitled Registry and have created a secret for that, you should use that secret here.	True
   Replicas	Number of replicas that each service has. The default is 3. Note: Couch replicas are fixed during the first installation of your Automation assets. Changes to replicas after installation will only affect the UI and API services.	True
   Annotations	Additional annotations to be added to Automation assets pods.	True
   Node Selector	If you wish to assign the pods to a subset of the nodes of your cluster, you can use multiple Node Selectors. See here for more information. Note: This setting only applies to Automation assets UI and API pods. CouchDB pods aren't affected.	True
   Resources	Use the Resources section to override the default resource request and limit values. You can set limit and request values for the Automation assets API and UI pods, and for the containers in the CouchDB pods. Any values you don't configure here will default to the values listed below. For more information about request and limit values, see the Kubernetes documentation. Important: For a given resource, if you wish to set the request, you must also set the limit, and if you wish to set the limit, you must also set the request. Default values: The values below are the defaults for each resource. The request and limit values are the same for each resource. Note: You cannot create an Automation assets with values smaller than these:Automation assets API CPU: 200mAutomation assets API Memory: 150MiAutomation assets UI CPU: 200mAutomation assets UI Memory: 150Mi CouchDB Search CPU: 50mCouchDB Search Memory: 300MiCouchDB DB CPU: 200mCouchDB DB Memory: 300MiCouchDB Mgmt CPU: 50mCouchDB Mgmt Memory: 100Mi	True

   You can also use the YAML editor to configure Automation assets.

   

   To disable runtime checks, add the annotation com.ibm.cp4i/disable-webhook-runtime-checks: true to the Automation assets YAML:

   metadata:
     annotations:
       com.ibm.cp4i/disable-webhook-runtime-checks: true

6. Automation assets starts installing and is initially in the Pending state. Wait for it to enter the Ready state.

   

7. You are asked to initialize the Automation assets with your teams (if applicable) on the next screen.

8. Your Automation assets is now ready to be used.

Built into the Automation assets is support for viewers corresponding to different file types. Files are automatically opened in their associated viewer when selected from either the scroll view or the assets table.

All nonbinary text files have an option to view the associated text underlying the file. If the asset type does not have additional viewer support, the default text viewer is presented. However, if there is additional viewer support, the text view can be triggered by selecting the Code button.

Below are asset types that have additional support:

• Open API - Explore the details of an Open API specification asset stored in the repository. Click any particular call to see further details. Click Code to see the actual code.

• JSON Schema - Explore the details of a JSON schema by selecting a particular field. Click Code to see the actual code.

• Designer API Implementation and Designer Event Driven Flow - The viewer lets you review the contents of the given asset and it also presents cards presenting either the API or the event connections between different triggers.

• PDF - The visualizer lets you to review the contents of a PDF file.

• Image - The image viewer lets you to view image files, provided they are of one of the supported types listed above.

• Avro Schema - The visualizer validatingwebhookconfigurations you to see JSON records for Avro schemas.

• Robotic Process Automation Bot - The visualizer lets you to see the associated contents of the Robotic Process Automation Bot.

When creating a remote you can select the interval at which remotes are synchronised. This can be done by selecting the dropdown menu under the Automatic sync options tab, and select from one of the possible intervals.

After adding the remote URL, you can select a remote branch by selecting the branch from the drop down menu under the Branch label.

When creating a remote you can select which type of assets are imported from that given remote. This can be done by selecting from one of the supported asset types, below the Asset Types label.

You can use an SSH key to access the remote repository. To use SSH, follow these steps.

1. Select Use SSH authentication.

2. Copy the key presented in the dialog.

3. Configure your Git repository to use the copied key. For Github, see Github help.

4. Set the Git URL to the correct address. For a Github repository, this address begins with git@github.com.

Click Create Remote. Once the synchronization completes, you see the remote listed.

The Automation assets automatically resynchronizes with the remote repository at the interval you set, at the point of adding the remote. Click the Edit icon to set the synchronization interval.

You can employ user-supplied SSH keys rather than the default. Take the following steps to use your own keys.

1. Locate or generate the SSH keys you want to use. This must be an RSA key, with no newline or whitespace characters.

2. Make sure the remote repository is configured to use this keypair.

3. Log in to the cluster using the oc login command.

4. Change to the namespace used for the Automation assets.

5. Edit the secret containing the Automation assets keypair.

   oc edit secret <operand name>-ibm-integration-asset-repository-ssh-keypair

   Set data:id_rsa to the base 64 encoded private key and data:id_rsa.pub to the base 64 encoded public key

6. Enable the secret changes to take effect with the following command.

   oc scale deployment/<operand name>-ibm-integration-asset-repository-api --replicas=0
   oc scale deployment/<operand name>-ibm-integration-asset-repository-api --replicas=3

If you configured Automation assets to automatically synchronize with the remote repository, take these additional steps:

1. Click Remotes to see the list of available remote repositories.

2. Click the  Edit icon for the remote you want to edit.

3. Select Never in the Automatic sync options field.

   

4. Click Edit Remote. The screen will return to the list of available remotes.

5. Click the  Edit icon for the remote you want to edit.

6. Select the previously set value in the Automatic sync options field.

7. Click Edit Remote. The screen will return to the list of available remotes.

The new keys are used. Repeat this process for each remote you want to use new keypairs.