Aller au contenu principal

Opérations

Disponible

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

Une fois l'App appliquée, sng app sert à la suivre et à la piloter sans rouvrir le manifeste : état de chaque service, changement d'image, nombre de réplicas, redémarrage, logs, suppression. Chaque commande qui modifie quelque chose met à jour le manifeste côté plateforme, puis le déploiement suit : la commande rend la main avant la fin du déploiement.

Prérequis​

  • Une App déployée (Depuis docker compose).
  • Les droits deploy:* sur votre tenant (deploy:read suffit pour list/describe, deploy:logs pour logs, deploy:write pour les modifications, deploy:delete pour supprimer).

Étapes​

1. Voir les Apps du tenant​

sng app list
NAME   STATUS      SERVICES  URL
shop   prête       4/4       https://api-shop.<tenant>.dev.stackngo.app/
web    en attente  -         -

STATUS vaut en attente (pas encore déployée), prête, en cours, ou la raison du blocage (QuotaExceeded, SecretNotFound…). URL est celle du premier service exposé.

2. Détailler une App​

sng app describe shop
App      : shop
Statut   : prête
SERVICE  KIND        IMAGE                                        PHASE      URL                                          DETAIL
api      deployment  registry.gitlab.com/stackngo/shop-api:1.4.2  Ready      https://api-shop.<tenant>.dev.stackngo.app/  Reconciled 2/2 prêts
cleanup  cronjob     registry.gitlab.com/stackngo/shop-api:1.4.2  Scheduled  -                                            Reconciled planifié : 0 3 * * *
db       deployment  postgres:17                                  Ready      -                                            Reconciled 1/1 prêts
migrate  job         registry.gitlab.com/stackngo/shop-api:1.4.2  Ready      -                                            Reconciled terminé

--manifest ajoute le manifeste courant à la suite ; --json rend tout en JSON.

3. Changer l'image, la taille, une variable​

sng app patch shop --service api --image registry.gitlab.com/stackngo/shop-api:1.4.3
sng app patch shop --service api --size s --env LOG_LEVEL=debug
App "shop" modifiée ; déploiement en cours

Seuls les champs donnés changent. Pour une App à un seul service, --service est inutile.

4. Ajuster le nombre de réplicas​

sng app scale shop 3 --service api
App "shop" : 3 réplica(s) demandé(s)

Refusé si le service a un autoscale (changez autoscale.max dans le manifeste), s'il a un volume et que le nombre dépasse 1, ou s'il n'est pas un deployment.

5. Redémarrer​

sng app restart shop                 # tous les deployments
sng app restart shop --service api   # un seul
App "shop" : redémarrage demandé

Les exemplaires sont remplacés selon la strategy du service, sans autre changement. Les jobs et cronjobs ne se redémarrent pas ainsi (Services, jobs et cronjobs).

6. Lire les logs​

sng app logs shop --service api --since 10m
sng app logs shop -f
[shop-api-7c9d4b8f6-x2k9q] 2026-10-07T09:12:03Z INFO listening on :8080
[shop-api-7c9d4b8f6-m4r1z] 2026-10-07T09:12:04Z INFO listening on :8080
[shop-db-5f8b7c6d9-q7w2e] 2026-10-07 09:11:58.102 UTC [1] LOG:  database system is ready to accept connections

Chaque ligne est préfixée du nom de l'exemplaire qui l'a écrite (suivi de /init pour la commande d'initialisation). Par défaut, les 200 dernières lignes de chaque conteneur ; --tail jusqu'à 5000, --since jusqu'à 24h, -f suit le flux pendant 10 minutes au plus.

7. Supprimer​

sng app delete shop
Supprimer l'App "shop" ?
Tapez « oui » pour confirmer : oui
App "shop" supprimée (les volumes restent)

--yes saute la confirmation (obligatoire hors terminal). sng kind delete App shop fait la même chose. Les volumes et leurs données sont conservés (Stockage).

Vérification​

Après chaque commande, sng app describe shop passe par en cours puis revient à prête. Si un service reste en Progressing plusieurs minutes, sng app logs shop --service <nom> donne la cause.

Lire status.services​

Chaque service a une phase, une raison et un message :

PhaseSensRaisons habituelles
Readyprêt (deployment disponible et à jour, job terminé)Reconciled
Scheduledcronjob planifié ; compte comme prêtReconciled
Progressingdéploiement ou job en cours ; les anciens exemplaires servent encoreRollingOut, JobRunning, SecretNotFound, QuotaExceeded (montée en charge bloquée)
Waitingrien n'est créé : dépendance ou Secret de registre manquantWaitingForDependency, DependencyFailed, ImagePullSecretNotFound
Failedrefusé ou en échecInvalid, DomainNotAllowed, HostConflict, NameConflict, QuotaExceeded, ApplyFailed, RolloutFailed, JobFailed

Au niveau de l'App, Statut reprend la raison du service le plus en difficulté (un échec avant une attente, une attente avant un déploiement en cours), et Message cite ce service. La liste complète des raisons et des corrections : Conditions et raisons.

Manifeste ou commandes ?​

Les deux écrivent le même manifeste. sng app patch, scale et restart sont pratiques pour un geste rapide ; sng apply d'un fichier versionné reste la référence pour tout changement de structure (ajouter un service, un volume, un autoscale). Après un patch, récupérez le manifeste à jour avec sng app describe shop --manifest ou sng kind get App shop, pour ne pas réappliquer une version périmée.

Deux modifications en même temps

Si deux commandes modifient la même App au même instant, la seconde est refusée plutôt que d'écraser la première. Relancez-la.

Pour aller plus loin​

  • sng app list et describe montrent le manifeste et l'état déployé ; en attente signifie que le déploiement vient d'être demandé et que son état n'est pas encore connu. Comptez généralement moins de deux minutes.
  • sng kind get App shop montre le manifeste brut ; sng kind list App les Apps du tenant sans leur état.
  • sng app describe shop --json donne le status complet.

Voir aussi​