Skip to main content

Services, jobs and cronjobs

Available

Deployed and supported. The fields and commands described here are stable within version v1alpha1.

Each service of an App has a kind: deployment (a container that runs continuously, the default), job (a task that runs once to completion) or cronjob (a scheduled task). dependsOn orders their startup: a service waits until its dependencies are ready (deployment) or completed (job).

Prerequisites​

  • A session and a tenant: see From docker compose, prerequisites.
  • Non-root images, or the uid to use (user).

Steps​

1. Write the three kinds​

stack.yml
apiVersion: deploy.stackngo.io/v1alpha1
kind: App
metadata:
  name: stack
spec:
  services:
    migrate:
      kind: job
      image: busybox:1.37
      user: "1000"
      command: ["sh", "-c", "echo migrate ok"]
      size: xxxs
    api:
      image: nginxinc/nginx-unprivileged:1.27     # implicit kind: deployment
      ports: ["8080"]
      size: xxxs
      dependsOn: [migrate, cache]
    cache:
      image: busybox:1.37
      user: "1000"
      command: ["sh", "-c", "mkdir -p /data/x && sleep 3600"]
      size: xxxs
      volumes:
        - { path: /data, size: 1Gi }
    tick:
      kind: cronjob
      schedule: "*/5 * * * *"
      image: busybox:1.37
      user: "1000"
      command: ["date"]
      size: xxxs
sng apply stack.yml
apply acme — 1 object(s)

2. Follow the startup order​

sng app describe stack

Right after the apply:

App      : stack
Statut   : en cours
Message  : api : attend : migrate
SERVICE  KIND        IMAGE                               PHASE        URL  DETAIL
api      deployment  nginxinc/nginx-unprivileged:1.27    Waiting      -    WaitingForDependency attend : migrate
cache    deployment  busybox:1.37                        Progressing  -    RollingOut 0/1 à jour, 0 disponibles
migrate  job         busybox:1.37                        Progressing  -    JobRunning job en cours
tick     cronjob     busybox:1.37                        Scheduled    -    Reconciled planifié : */5 * * * *

When migrate is completed and cache is ready, api is created in turn.

Verification​

sng app describe stack displays Statut : prête and 4 services Ready or Scheduled (SERVICES 4/4 in sng app list). sng app logs stack --service migrate shows migrate ok.

The three kinds in detail​

deployment (default)jobcronjob
Runscontinuously, restarted if it stopsonce, until exit code 0according to schedule (5-field cron syntax)
Number of instancesreplicas (default 1), or autoscale11 per run, never two at the same time
On failureinstances restarted indefinitely3 attempts, then Failed (JobFailed)the run is marked as failed, the next one takes place at the scheduled time
Restarted whenthe image, env or command changes (rolling update), or sng app restartits spec changes: a new job is created, the old one deleted— (the schedule is updated)
Allowed fieldsallno ports, ingress, replicas, strategy, autoscale, allowFrom, restartedAtsame, plus schedule required
Phase when all is wellReadyReady (completed)Scheduled
Can be a dependencyyes (must be ready)yes (must be completed)no (no "completed" state)

A job is not rerun by a simple sng apply that does not change its spec. To replay it, change something in its definition (for example a variable RUN: "2"), or remove it from the manifest and put it back.

A cronjob that cannot start at the scheduled time has a 5-minute tolerance; beyond that, the run is skipped. Only one history of a successful run and one of a failed run are kept: sng app logs stack --service tick shows only the last one.

dependsOn​

  • Dependencies are names of services of the same App.
  • A waiting service is in phase Waiting, reason WaitingForDependency; it is not created before. If a dependency fails, it switches to DependencyFailed.
  • No cycle, no dependency on itself, no dependency on a cronjob.
  • dependsOn orders creation and updates. If a dependency goes back into deployment, the dependent is marked Waiting and its changes wait, but its existing instances keep running: nothing is stopped.

init: a command before each start​

init runs a command with the same image, the same environment and the same size as the service, before each instance starts. It suits a wait or a light preparation; a schema migration is better done in a job with dependsOn.

services:
  api:
    image: registry.example.com/api:1.2
    ports: ["8080"]
    init: ["sh", "-c", "until nc -z db 5432; do sleep 1; done"]

If it doesn't work​

What you seeWhat to do
A service stays in Waiting, WaitingForDependencyLook at the state of the awaited service: it is not ready or completed yet
DependencyFailedA dependency failed: fix it (sng app logs stack --service <name>), then sng apply
A job switches to Failed, JobFailedAll 3 attempts failed: read its logs, fix, and change its definition to replay it
The manifest is rejected because of a cycle or a cronjob in dependsOnRemove the offending dependency

Going further​

  • command replaces the image's CMD, entrypoint replaces the ENTRYPOINT: same meaning as in compose. Both are lists (64 items at most).
  • Containers run with a hardened profile (no administrator, no privilege escalation, no access to the platform). Nothing to configure, nothing to disable.
  • pullPolicy: always | missing | never follows the compose values; without a value, the platform applies its default (an image with the latest tag is always downloaded again).

See also​