Forge Container services reference: manifest (Preview)

The endpoint module described on this page is also documented in the Endpoint manifest reference.

To customize Forge Container services configuration by environment type and placement, see Manifest overrides.

Forge features a top-level manifest property named services that lets you define a service and its corresponding container. It supports the following properties:

Containers

The containers property lets you configure a container’s resource, scaling, and health check settings:

Resources

The resources property defines what compute resources are allocated to the container.

Valid resource size combinations

The cpu and memory values must be one of the following supported combinations. Deployments with unsupported combinations will fail.

Health

The health property defines how your container is determined as healthy and ready to receive traffic. For more details around timing for configured container health checks during deployment and runtime, see Deploy the Service.

Scaling

The scaling property defines how the service should scale the number of instances.

Scaling profiles

For now, the only supported profile is default. With this profile, scaling behaviors are triggered whenever the average CPU or memory usage reaches the following thresholds:

The following table describes the default profile’s scaling behavior:

Forge Container services checks average resource usage every 15 seconds.

Scale to zero

You can configure a container service to scale down to zero running instances when it is idle. This can help reduce costs for containers used in non-production environments by ensuring that no instances are running when there is no traffic. Scaling a container service to zero is supported in DEVELOPMENT and STAGING environments.

To enable this, set min to 0 in your service's scaling configuration:

1
2
services:
  - key: example-service
    scaling:
      min: 0
      max: 2

With scale to zero enabled, a container service scales down to 0 running instances if it receives no traffic for 15 minutes. When the next request arrives, Forge returns a 503 response and starts scaling the service back up.

The service typically becomes available within a few minutes. Once the container has scaled up, subsequent requests are processed normally.

When enabling scale to zero, consider the following differences in behavior:

• Scheduled triggers have a short retry window of around 2 minutes. If the container service does not come online within that window, Forge may silently drop the scheduled trigger invocation. If scheduled trigger delivery is important, we recommend handling the scheduled trigger with a Forge function that creates an async event.
• Product events and async events have longer retry windows, so Forge processes them after the container service comes online.

Tunnel

The tunnel property lets you configure settings for running the container locally, including which port service invocations should be made to.

See Testing a containerised service locally for more details.

Example

The following snippet shows a service named java-service, which is backed by a container of the same name. The service is accessible via the /webtrigger route on the webtrigger-ep endpoint module.

1
2
modules:
  webtrigger:
    - key: container-webtrigger
      endpoint: webtrigger-ep
  endpoint:
    - key: webtrigger-ep
      service: java-service
      route:
        path: /webtrigger

services:
  - key: java-service
    containers:
      - key: java-service
        tag: latest
        resources:
          cpu: "1"
          memory: "2Gi"
        health:
          type: http
          route:
            path: "/healthcheck"
    scaling: 
      min: 1
      max: 1