Function Compute:Custom task templates

How it works

During the task execution phase in Serverless Application Center, the system deploys task workers for users and passes the execution context as one part of payload into the task workers. After the task workers receive the payload, the system executes tasks based on the procedure that is defined in steps.

You can configure custom logic for task workers by configuring runnerConfig and steps in the context.

Example of a custom task template

The following sample code provides an example of a custom task template. You can specify the preset serverless-runner in spec.worker.presetWorker, and the execution engine schedules a task worker and performs the steps that you customized on the task worker.

kind: TaskTemplate
name: serverless-runner-task
description: ''
createdTime: '2023-04-11T08:43:58Z'
deletionTime:
generation: 0
labels:
  source: system
resourceVersion: 0
spec:
  description: |-
    Run customized scripts on a serverless runner.
     
  worker:
    # Set the runner type to the preset serverless-runner of Serverless Application Center. 
    # The execution engine of serverless-runner recognizes the configurations of runnerConfig and steps. 
    presetWorker: serverless-runner
  executeCondition:
    # The execution is performed only if the enable == true expression is specified. 
    expression: enable == true
  contextSchema: {}

Example of using a custom task template in a pipeline template

Custom task templates can be used in pipeline templates. Sample code:

kind: PipelineTemplate
name: demo-template
spec:
  context:
    data:
      deployFile: s.yaml
      #  Specify the deployment settings of task workers. If you do not specify the deployment settings, the execution is performed in a sandbox of Serverless Application Center. 
      #  The runnerConfig settings that you specify here affect all tasks that are defined in the template. 
      #  runnerConfig:
      #  Specify the Singapore region. 
      #  regionId: ap-southeast-1
      #  Specify the logging settings. The generated logs are delivered to the specified Logstore of Simple Log Service (SLS). 
      #  logConfig:
      #    logstore: function-log
      #    project: my-project
      #  Specify the network settings. Specify the information about the virtual private cloud (VPC). 
      #  vpcConfig:
      #    securityGroupId: xxx
      #    vSwitchIds: ["xxx"]
      #    vpcId: xxx
      #  Specify the instance specifications. Use compute instances with 1 vCPU and 2 GB of memory. 
      #  cpu: 1
      #  memory: 2048
      #  Specify the timeout period of the server. In this example, the timeout period is set to 15 minutes. 
      #  timeout: 900
      #  Specify whether to enable the debug mode. The Function Compute function that corresponds to the runner is not reclaimed in a short period of time. We recommend that you do not enable the debug mode. 
      #  debugMode: true
      #  Specify environment variables for task workers. 
      #  environmentVariables:
      #  DEBUG: '*'
  tasks:
  # Build and deploy. 
  - name: build-and-deploy
    context:
      data:
        # Enable task execution. By default, task execution is disabled. 
        enable: true
        # You can declare or modify runnerConfig here. 
        # runnerConfig:
        # Specify the execution procedure. The engine provided by serverless-cd is used in the example in the following steps. 
        steps:
          # Check out the code. 
          # The plugin mechanism is used to run the plug-ins of serverless-cd. 
          # @serverless-cd/checkout is an open source plug-in that is used to check out code to the default path. 
          # Function Compute continues to contribute more plug-ins for the community. 
          - plugin: '@serverless-cd/checkout'
          - run: |
              echo "Setup Serverless Devs ing..."
              # Enable the debug mode and print command outputs. 
              set -x
              ls -al
              # aliyun cloud authentication infos.
              access_key_id=${{ sts.accessKeyId || "dummy-ak" }}
              access_key_secret=${{ sts.accessKeySecret || "dummy-sk" }}
              security_token=${{ sts.securityToken || "dummy-token" }}
              uid=${{ uid || "dummy-uid" }}
              # account info alias
              alias=my-account
              s --version
              if [[ $?  -ne 0 ]]; then
              echo "Serverless Devs is not installed."
              exit 1
              fi
              s config add --AccessKeyID "${access_key_id}" --AccessKeySecret "${access_key_secret}" \
              --AccountID "${uid}" --SecurityToken "${security_token}" --access "${alias}" -f
              if [[ $?  -ne 0 ]]; then
              echo "Failed to setup Serverless Devs."
              exit 1
              fi
              echo "Setup Serverless Devs success."
          # Run s-deploy. 
          - run: |
              echo "Deploy by Serverless Devs ing..."
              set -x
              alias=my-account
              deploy_file=${{ ctx.data.deployFile || "" }}
              if [[ -z "${deploy_file}" ]]; then
                if [[ -f "s.yaml" ]]; then
                  deploy_file="s.yaml"
                elif [[ -f "s.yml" ]]; then
                  deploy_file="s.yml"
                fi
              fi
              if [[ !  -f "${deploy_file}" ]]; then
                echo "Failed to find s.yaml file."
                exit 1
              fi
              echo "s.yaml file location: ${deploy_file}"
              s deploy --access "${alias}" -t "${deploy_file}" --use-local --assume-yes --skip-push
              echo "Deploy by Serverless Devs success."
    # Specify the built-in serverless-runner-task template as the task template. 
    taskTemplate: serverless-runner-task
    # Specify the execution sequence. In this example, the execution is immediately triggered without relying on tasks. 
    runAfters: []
---

Use runnerConfig to describe task workers

If you configure runnerConfig, the task workers are deployed under the current account based on the settings. If you do not configure runnerConfig, the task worker is deployed in an Alibaba Cloud sandbox.

{
    "DEBUG":"*"
}

Use steps to describe the execution of task workers

You must configure the procedure in the steps section to specify how to execute task workers. The steps section contains multiple steps, and the execution engine performs each step in sequence. Each step is an independent sub-process of the execution engine.

Steps of the command type

A step of the command type allows you to describe the build behavior by using shell commands. Shell commands support template syntax. You can use the delimiters ['${{', '}}'] to obtain the variables in the context. For example, you can run the echo ${{ ctx.data.appName }} command to print the names of applications in the current context.

Take note that the delimiters ['${{', '}}'] are independent of the $ syntax in shell commands. In run commands, it is different between running the ${{ key }} and ${key} commands. The former command allows you to obtain variables from the current context based on template syntax, whereas the latter command allows you to obtain variables, including environment variables, from the current process based on shell syntax.

{
"appName": "my-application"
}

{
"accessKeyId": "Lk89k****",
"accessKeySecret": "SEC******",
"securityToken":"KJHLS****"
}

{
    "debug":"*"
}

${{ steps['my-cache'].outputs['cache-hit'] != 'true' }}

Steps of the plug-in type

Plug-ins are maintained by Serverless Application Center. After you abstract duplicated and complex build behaviors into plug-ins, you need to only declare the names of the plug-ins, without writing code lines. For example, if you want to check out the code, you need to only declare the name of a plug-in to complete the checkout. In this example, @serverless-cd/checkout is used.

{
    "debug":"*"
}

{
  "key1": "value1",
  "key2": "value2"
}

${{ steps['my-cache'].outputs['cache-hit'] != 'true' }}

Supported plug-ins

• @serverless-cd/checkout