Services, jobs et cronjobs

Disponible

Fonctionnalité déployée et prise en charge. Les champs et commandes décrits ici sont stables au sein de la version v1alpha1.

Chaque service d'une App a un kind : deployment (un conteneur qui tourne en continu, le défaut), job (une tâche qui tourne une fois jusqu'au bout) ou cronjob (une tâche planifiée). dependsOn ordonne leur démarrage : un service attend que ses dépendances soient prêtes (deployment) ou terminées (job).

Prérequis

• Une session et un tenant : voir Depuis docker compose, prérequis.
• Des images non root, ou l'uid à utiliser (user).

Étapes

1. Écrire les trois 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     # kind: deployment implicite
      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. Suivre l'ordre de démarrage

sng app describe stack

Juste après l'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 * * * *

Quand migrate est terminé et cache prêt, api est créé à son tour.

Vérification

sng app describe stack affiche Statut : prête et 4 services Ready ou Scheduled (SERVICES 4/4 dans sng app list). sng app logs stack --service migrate montre migrate ok.

Les trois kinds en détail

	deployment (défaut)	job	cronjob
Tourne	en continu, redémarré s'il s'arrête	une fois, jusqu'au code de sortie 0	selon schedule (syntaxe cron à 5 champs)
Nombre d'exemplaires	replicas (défaut 1), ou autoscale	1	1 par exécution, jamais deux en même temps
En cas d'échec	exemplaires relancés indéfiniment	3 tentatives, puis Failed (JobFailed)	l'exécution est marquée en échec, la suivante a lieu à l'heure prévue
Relancé quand	l'image, l'env ou la commande change (mise à jour progressive), ou sng app restart	sa spec change : un nouveau job est créé, l'ancien supprimé	— (la planification est mise à jour)
Champs permis	tous	pas de ports, ingress, replicas, strategy, autoscale, allowFrom, restartedAt	idem, plus schedule obligatoire
Phase quand tout va bien	Ready	Ready (terminé)	Scheduled
Peut être une dépendance	oui (doit être prêt)	oui (doit être terminé)	non (pas d'état « terminé »)

Un job n'est pas relancé par un simple sng apply qui ne change pas sa spec. Pour le rejouer, changez quelque chose dans sa définition (par exemple une variable RUN: "2"), ou supprimez-le du manifeste et remettez-le.

Un cronjob qui ne peut pas démarrer à l'heure prévue dispose de 5 minutes de tolérance ; au-delà, l'exécution est sautée. Un seul historique d'exécution réussie et un seul d'exécution échouée sont conservés : sng app logs stack --service tick ne montre que la dernière.

dependsOn

• Les dépendances sont des noms de services de la même App.
• Un service qui attend est en phase Waiting, raison WaitingForDependency ; il n'est pas créé avant. Si une dépendance est en échec, il passe DependencyFailed.
• Pas de cycle, pas de dépendance vers soi-même, pas de dépendance vers un cronjob.
• dependsOn ordonne la création et les mises à jour. Si une dépendance repasse en cours de déploiement, le dépendant est marqué Waiting et ses changements attendent, mais ses exemplaires existants continuent de tourner : rien n'est arrêté.

init : une commande avant chaque démarrage

init lance une commande avec la même image, le même environnement et la même taille que le service, avant le démarrage de chaque exemplaire. Elle convient à une attente ou une préparation légère ; une migration de schéma se fait plutôt dans un job avec dependsOn.

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

Si ça ne marche pas

Ce que vous voyez	Que faire
Un service reste en Waiting, WaitingForDependency	Regardez l'état du service attendu : il n'est pas encore prêt ou terminé
DependencyFailed	Une dépendance a échoué : corrigez-la (sng app logs stack --service <nom>), puis sng apply
Un job passe Failed, JobFailed	Les 3 tentatives ont échoué : lisez ses journaux, corrigez, et changez sa définition pour le rejouer
Le manifeste est refusé à cause d'un cycle ou d'un cronjob dans dependsOn	Retirez la dépendance en cause

Pour aller plus loin

• command remplace le CMD de l'image, entrypoint remplace l'ENTRYPOINT : même sens qu'en compose. Les deux sont des listes (64 éléments au plus).
• Les conteneurs tournent avec un profil durci (pas d'administrateur, pas d'élévation de privilège, aucun accès à la plateforme). Rien à configurer, rien à désactiver.
• pullPolicy: always | missing | never suit les valeurs compose ; sans valeur, la plateforme applique son défaut (une image avec tag latest est toujours re-téléchargée).

Voir aussi

• Healthchecks et scaling
• Opérations (sng app restart, sng app logs)
• Référence des manifestes (page App)