Function Compute (FC) for Serverless Devs

The FC component provides full lifecycle management for Function Compute projects, covering:

• Lifecycle Management: Handles creation, development, debugging, deployment, and O&M.
• Security: Automatically detects changes in functions for secure releases.
• CI/CD Integration: Integrates with common CI/CD tools.
• Observability: Allows querying metrics and logs directly from the client.
• Multi-mode Debugging: Supports both local calls and remote debugging (via invoke).

The FC component is designed for full lifecycle management of Function Compute projects, including:

• Lifecycle Management: Handles creation, development, debugging, deployment, and O&M.
• Security: Automatically detects changes in functions for secure releases.
• CI/CD Integration: Integrates with common continuous integration and deployment tools.
• Observability: Provides client-side querying for metrics and logs.
• Multi-mode Debugging: Supports both local calls and remote debugging (invoke) to suit different development and O&M needs.

The ondemand command is used to manage on-demand resources in Function Compute. It allows you to query resource details, list available resources, and publish or update configurations (such as maximum instance counts).

Available subcommands:

• get: Queries the details of specific on-demand resources.
• list: Queries the lists of on-demand resources.
• put: Publishes or updates configurations of on-demand resources.

To view help information, run ondemand -h or ondemand --help.

The .s directory is an in-process directory generated by the FC component. It serves two main purposes:

1. Caching: It stores cloud resource information and deployment logs. This allows Serverless Devs to detect changes in your cloud resources during redeployment.
2. Build Artifacts: It stores build results in the path ./.s/build/artifacts/<Service name>/<Function name>/.

Note: The build artifact capability is not supported when using custom containers.

Serverless-Devs reserves certain special variables for internal purposes. Developers should avoid using them to prevent conflicts.

One such variable is ${aliyun-cli}, which, when used in the access field, automatically obtains the default profile from the aliyun cli. You can check your currently valid profile by running aliyun configure list.

You can configure the asyncConfiguration within a function to specify where messages should be sent after an asynchronous invocation succeeds or fails.

Supported destination formats:

• Function Call: acs:fc:{region}:{uid}:services/{serviceName}.{qualifier}/functions/{functionName}
• MNS Queues: acs:mns:::/queues/{queuesName}/messages
• MNS Topics: acs:mns:::/topics/{topicsName}/messages

Additional settings include maxAsyncEventAgeInSeconds (survival time of the message) and maxAsyncRetryAttempts (number of retries after failure).

asyncConfiguration:
  destination:
    onSuccess: acs:fc:{region}:{uid}:services/{serviceName}.{qualifier}/functions/{functionName}
    onFailure: acs:fc:{region}:{uid}:services/{serviceName}.{qualifier}/functions/{functionName}
  maxAsyncEventAgeInSeconds: 456
  maxAsyncRetryAttempts: 3

To optimize deployment speed and avoid unnecessary changes, you can specify exactly what you want to update using the --type parameter:

• Update only code: Use --type code. This is ideal for rapid iteration on function logic without touching environment variables or memory settings.
• Update only configuration: Use --type config. This is ideal for changing timeouts, memory sizes, or environment variables without re-uploading the code package.

s deploy --type code
s deploy --type config

When nasConfig is configured in your s.yaml, the local command can emulate the NAS directory structure on your local machine.

How it works: If you have a mount point configured, the local environment will create a directory structure under .s/nas/ to simulate the remote storage. For example, if your nasDir is /hello-world-service, the local files should be placed in .s/nas/auto-default/hello-world-service (relative to your s.yaml).

Example Configuration (s.yaml):

services:
  helloworld:
    component: fc
    props:
      service:
        nasConfig:
          mountPoints:
            - serverAddr: xxx.cn-hangzhou.nas.aliyuncs.com
              nasDir: /hello-world-service
              fcDir: /mnt/auto

When the function runs locally, any file operations performed on /mnt/auto will interact with the files in your local .s/nas/ directory.

When using the s build command, you can control the version of the Docker image used for the build environment by setting the FC_DOCKER_VERSION environment variable.

For example, setting it to latest will use the latest available version. Available versions can be found at fc-docker or on Docker Hub.

export FC_DOCKER_VERSION=latest

The role parameter grants the permissions required by Function Compute to perform actions like sending logs to Logstore or accessing other cloud resources.

You can provide role in two ways:

1. Simple configuration: A single string representing the RAM role ARN (e.g., acs:ram::xxx:role/AliyunFcDefaultRole).
2. Detailed configuration: A structure defining a new role and its associated policies.

When using the detailed structure, you define a name and a list of policies. Policies can be existing system policy names (strings) or custom policy structures containing statement blocks.

role:
  name: roleName
  policies:
    - AliyunOSSFullAccess
    - name: myPolicy
      description: custom policy
      statement: 
      - Effect: Allow
        Action: 
          - log:ListProject
        Resource:
          - acs:log:*:*:project/*