sng apply, validate, plan, pull
Fonctionnalité déployée et prise en charge. Les champs et commandes décrits ici sont stables au sein de la version v1alpha1.
Ces quatre commandes forment le cycle de travail sur l'état désiré du tenant courant. Elles
exigent une session de tenant (sng tenant use).
Fichiers acceptés
PATH est un fichier ou un dossier. Par défaut : le dossier courant.
- Extensions
.ymlet.yaml; les autres fichiers sont ignorés. - Plusieurs documents par fichier, séparés par
---. - Chaque document doit avoir
kindetmetadata.name. Le kind doit être applicable parsng apply. metadatane contient quename: pas de tenant (déduit de votre session), ni label, ni annotation. Sinon :metadata : seul name est permis (<clé> refusé).
sng validate
sng validate [PATH]
Envoie les manifestes à l'API pour validation sans rien écrire : structure, schéma du
kind, règles de cohérence, domaines autorisés, quotas. C'est la même validation que apply.
validate OK — 3 document(s)
En cas de problème, une ligne par défaut puis une erreur :
error: App/web: spec.services.db: volumes require replicas <= 1 and strategy recreate
error: SSMSecret/token: spec.rotateDays requires spec.length > 0
Error: validation failed (2 issue(s))
--json : {"valid":false,"issues":[{"kind":"App","name":"web","message":"…"}]}.
sng plan
sng plan [PATH]
Compare les manifestes locaux à l'état désiré et annonce ce que apply ferait, sans rien
écrire.
ACTION KIND NAME
create App web
update SSMSecret db-password
unchanged App api
| Action | Sens |
|---|---|
create | Le manifeste n'existe pas encore dans l'état désiré |
update | Il existe et son contenu diffère |
unchanged | Identique : apply ne le touchera pas |
plan ne signale pas les manifestes présents dans l'état désiré mais absents de PATH :
apply ne supprime jamais rien. Pour supprimer : sng kind delete.
Sans manifeste : nothing to plan.
sng apply
sng apply [PATH]
Valide puis écrit les manifestes dans l'état désiré, et déclenche leur prise en charge. Un manifeste identique à l'existant est réécrit à l'identique (sans effet).
apply acme — 2 object(s)
App/web (web.yml)
SSMSecret/db-password (secrets/db-password.yml)
Chaque ligne donne la ressource (Kind/nom) et le fichier d'où elle vient. Les changements
sont en général pris en compte en moins d'une minute.
--json : {"uploads":[{"kind":"App","name":"web","source":"web.yml",…}]}.
Une fois appliqué, suivez la convergence avec la commande du kind (sng app describe,
sng secret describe) ou, pour les autres kinds, avec la commande indiquée dans sng kind get.
apply est fait pour être rejoué, en local comme en CI : le même dossier appliqué deux fois
donne le même état. Versionnez vos manifestes dans git et faites de sng apply l'étape de
déploiement de votre pipeline (CI/CD).
Un apply interrompu avant la fin n'a aucun effet : aucun manifeste n'est pris en compte
partiellement.
sng pull
sng pull [DIR]
Télécharge tout l'état désiré du tenant courant dans DIR (par défaut
stackngo), un fichier par manifeste : DIR/<Kind>/<nom>.yml, plus un DIR/stackngo.yaml
qui mémorise le tenant.
pull acme → stackngo (4 object(s))
stackngo/
├── stackngo.yaml
├── App/
│ ├── api.yml
│ └── web.yml
├── SSMSecret/
│ └── db-password.yml
└── RegistryRepository/
└── web.yml
C'est le moyen de mettre sous git un tenant créé à la main, ou de vérifier ce que la
plateforme a réellement enregistré. Les fichiers existants dans DIR sont écrasés ; ceux qui
n'ont plus de manifeste correspondant ne sont pas supprimés.
Erreurs typiques
| Message | Cause |
|---|---|
tenant session required: run sng tenant use NAME | Pas de tenant courant : sng tenant use <tenant> |
forbidden (no policy of this tenant allows it: see sng tenant policy list) | La session n'a pas deploy:write (apply) ou deploy:read (plan, validate, pull) |
unsupported kind … | Le kind n'est pas applicable par apply (kind réservé, ou faute de frappe) |
invalid manifest … | Schéma ou règle de cohérence violée ; le message nomme le champ |
conflict | Nom ou hôte déjà pris, ou ressource en cours de suppression |