FAQ

Cesium Automation helps you solve 2 key problems:

1. Running recurring workflows which are supposed to run at specific time intervals.

2. Running workflows for IT Service Request and ITSM Incident response automation with Jira.

Examples for recurring workflows include data extraction, data movement (using FTP or S3 etc), data processing, periodic restacking, security scans etc.

Examples of IT request automation include scripts for handling things like resetting user LDAP credentials, user VPN access, granting ssh access to machines and reverting them after a set period etc. These scripts can be triggered programmatically from the cloud through integrations with cloud based on service management tools like Jira.

Workspace: The workspace is a way of organizing task executors and workflows

Task Executor: A piece of software that needs to be downloaded and run wherever the workflows need to be executed.

Workflow: An entity which contains a directed acyclic graph of tasks where each task presents a specific step that needs to be run as an independent process and some metadata around alerting and environment varialbes.

Jira App: The Jira marketplace app that needs to be installed and configured to hook up with your Cesium account. After its configured, you can setup automation rules to execute specific scripts in response to Jira tickets.

The workspace is a way of organizing task executor and workflow into logical groups for easier management. If you have multiple teams within your company using Cesium , then you can try to create a workspace per team. Or if you are running workflows for different purposes, you can group them by purpose.

The task executor (sometimes also refered to as Tex in the documentation) is a software that must be downloaded and run on your infrastructure. The task executor:

• runs as a daemon process within the customer's infrastructure

• is configured through a properties file to authenticate itself to the Cesium Ops cloud component.

• is responsible for executing the worfkflow and communicating the state of execution

Every task executor must be associated with a workspace. The task executor requires internet access to work correctly. The task executor initiates outbound network connections from the machine it is running on to the Cesium core orchestrator in the cloud. Tex never accepts incoming requests from the internet and does not require you to open any ports in your network.

The current supported task types are:

Shell Task

This is used to run:

• sh or bash scripts on linux or mac

• any native executable available on the system

• bat script or powershell script on Windows

Attributes:

• command: the command that needs to be run like cat, /usr/bin/backup_mysql.sh (which is the command or the bash script that needs to be run). This can be an absolute path to a file already on the machine where tex runs or a relative path to the python script inside the code artifact zip file.

• args: an array of strings that are passed to the executable as parameters. After each parameter, hit "enter" to add the stirng to the argument.

PythonTask

This task type is used to run python scripts. Tex currently only supports running python3 scripts. If your task requires specific python libraries, you can define a requirements.txt in the code artifact zip file which lists all dependencies in the standard format. Tex will create a virtual env for this workflow which live inside the workflow folder. The virtual env will be activated each time this task needs to be executed.

The attributes of a python task are:

• script (Required): The script to the python script that needs to be executed. This can be an absolute path to a file already on the machine where tex runs or a relative path to the python script inside the code artifact zip file.

• args (optional): an array of strings that are passed to the bash script as parameters.

Requirements:

The system where tex is running must have python3 installed and available as python on Windows and python3 on *nix.

If you are using a requirements.txt to manage dependencies, pip3 and venv must be available.

Run Docker

Docker is a containerization technology. Using this task type you can run any docker image. The attributes required to configure a docker run are:

• Docker Image (required): The image that needs to be run. This can be an image from docker-hub or from any private container registry. If its from a private container registry like ECR, please add the fully qualified image name. The machine should already have credentials to pull the required images from the repository.

• Commands (optional): If you want to override the process that the docker container to run. If this is kept empty, then the default RUN command is executed.

• Arguments (optional): If you need to pass any optional arguments or parameters to the docker image.

Requirements:

Docker daemon must be running on the same machine where the tex is running. On linux, tex will communicate to the docker daemon using the standard socket and on Windows using the docker REST API available on the standard port locally. Running docker containers on remote machines is not supported.

Authentication to container registry: There is no explicit authentication and authorization configured to talk to the a private container registry if one is being used. Refer to Docker login on how to provide login credentials. Most private container registries like AWS ECR, Google Container Registry/Artifact registry also provide instructions on how to use their respective IAM mechanisms to allow your instance to pull images from the registry. Please refer to your vendor provided instructions for authenticating the docker daemon to your container registry.

A workflow refers to a single run of the workflow. A workflow run is created whenever it is time to execute it (based on the configured cron) or it is executed on demand. Each workflow run will have the following attributes:

• Requested time: The time at which the workflow run was initiated (whether automatic or manual)

• Start time: The time at which the workflow execution was started by tex

• End time: The time at which the last task in the workflow finished execution

• Status: The current status of the task.

• Execution Type: An enumeration of whether it was scheduled or an on-demand execution.

You can view the workflow run of a specific workflow by choosing the View History action in the workflows list or by clicking on the View History button on the details of a specific workflow.

Workflow Run Details

In workflow history, you can click on any row to see the details of a specific workflow run. The workflow run should show you the following details:

• Run Description

• Inputs

• Workflow Run Timeline: A timeline of individual tasks lifecycle

• Details of the user or the process that started the workflow. If the workflow was started due to a dependency on another workflow, it will show the id or the name of the other workflow.