Types

​

Serverless

Serverless workloads should be used for web applications that serve traffic on a single port, but may not need to run 100% of the time.

Serverless workloads may:

• Scale to zero.

Serverless workloads may not:

• Serve traffic on multiple ports.

Serverless workloads must:

• Expose a network endpoint.

​

Standard

Standard workloads have greater flexibility in network exposure, but may not scale to zero.

Standard workloads may:

• Expose no network endpoint.
• Serve traffic on multiple ports.

Standard workloads may not:

• Scale to zero.

​

Cron

Cron workloads should be used when you need to perform a background task on a regular schedule.

Cron workloads may not:

• Serve traffic.
• Scale to zero.
• Include a container that runs indefinitely.

Cron workloads must:

• Exit upon completion of the task at hand. Control Plane will start a new replica of your workload at the next scheduled execution time.

​

Cron Configuration

• job.schedule
  • A string, which determines how often the cron workload should execute. This field uses the Kubernetes cron schedule syntax
• job.concurrencyPolicy
  • Either Forbid or Replace. This determines what Control Plane will do when a prior execution of your workload is still running when the next scheduled execution time arrives.
    • Forbid: subsequent executions will be forgone until the running execution completes.
    • Replace: the running execution will be stopped so that a new execution can begin.
• job.historyLimit
  • An integer between 1 and 10 representing the number of prior executions to be retained for reference.
• job.restartPolicy
  • Either Never or OnFailure. This determines whether your workload will be restarted when it fails on execution.
• job.activeDeadlineSeconds
  • Optional: By default there is no deadline. Job executions are allowed to run indefinitely.
  • If this property is set, this is the maximum number of a seconds a job execution can run. If the job does not exit in the allotted time, Control Plane will remove it.

​

Run Now

Cron workloads can be run on-demand by submitting a runCronWorkload command via POST https://api.cpln.io/org/my-org/gvc/my-gvc/workload/my-cron-workload/-command

type: runCronWorkload
spec:
  location: aws-us-west-2
  containerOverrides:
    - name: my-container
      command: '/bin/sh'
      args:
        - '-c'
        - sleep 10
      env:
        - name: MY_ENV_VAR
          value: some-new-value

​

runCronWorkload Spec

• location
  • The name of the location as shown in your GVC configuration.
• containerOverrides
  • Optional: A list of objects which override parts of a container’s configuration
• containerOverrides[].name
  • The name of the container in the workload spec to override
• containerOverrides[].command
  • A new command for the container during this execution only. This field works just like workload.containers[].command in the workload spec.
• containerOverrides[].args
  • A new list of arguments for the container during this execution only. This field works just like workload.containers[].args in the workload spec.
• containerOverrides[].env
  • A new list of environment variables for the container during this execution only. This field works just like workload.containers[].env in the workload spec.

​

Run via the CLI

Run a cron workload using the cpln CLI via cpln workload cron start. e.g.

echo '[{"name":"my-container","command":"/bin/bash","args":["-c","sleep 10"],"env":[{"name":"MY_ENV_VAR","value":"some-new-value"}]}]' | cpln workload cron start cron --gvc my-gvc --org my-org --file -

​

Job History

A cron workload retains up to job.historyLimit job executions in its history. Each job execution will be in one of the following statuses:

• Invalid
• Active
• Success
• Failure
• Removed

​

The Removed Status

The Removed status indicates that a job execution was deleted before it could finish execution. There are several reasons this can happen, but the most common are:

• The job.concurrencyPolicy is Replace and while the job was still executing, job.Schedule dictated that the job should begin again.
• The job.activeDeadlineSeconds limit was exceeded.

​

Stateful

​

Overview

Stateful workloads are similar to standard and serverless workloads in many ways. Much of the base functionality including Universal Cloud Identity, autoscaling, metrics, logs, audit trail, etc. remains the same.

​

Key Features

​

Stable Replica Identities

Each replica has a permanent identity. If a replica is rescheduled, restarted, or recreated for any reason, its identity will remain constant. Identities are of the form - e.g. for a workload called my-workload, the replica identities would be:

• my-workload-0
• my-workload-1
• etc.

​

Stable Hostnames

Each replica has a hostname corresponding to its identity. Hostnames are of the form {replicaIdentity}.{\workloadName} e.g. for a workload called my-workload, the replica hostnames would be:

• my-workload-0.my-workload
• my-workload-1.my-workload
• etc.

So to make an HTTP request to a specific replica, one might execute:

curl http://my-workload.my-workload-1:8080 from another workload running on Control Plane

​

Persistent Storage

Stateful workloads can mount a volume set as a volume in one or more of its containers. To do this, simply add a volume to a container’s list of volumes of the form:

uri: cpln://volumeset/my-volume-set
path: /some/mount/directory

​

Considerations When Using Persistent Storage

• Volume sets are GVC scoped.
• A workload can only use volume sets in the same GVC.
• A volume set can be used by at most one workload.
• A workload may use any number of volume sets.
• The volume set uri must begin with cpln://volumeset/.

​

Examples

​

PostgreSQL

This example demonstrates how to run a simple postgresql instance on Control Plane.

​

NATS

This example demonstrates how to run NATS on Control Plane

​

Planned Features

• Access to a specific replica via the external endpoint. Currently, the external endpoint load-balances connections across all available replicas.