Aller au contenu principal

sng apply, validate, plan, pull

Disponible

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 .yml et .yaml ; les autres fichiers sont ignorés.
  • Plusieurs documents par fichier, séparés par ---.
  • Chaque document doit avoir kind et metadata.name. Le kind doit être applicable par sng apply.
  • metadata ne contient que name : 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
ActionSens
createLe manifeste n'existe pas encore dans l'état désiré
updateIl existe et son contenu diffère
unchangedIdentique : 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.

Reproductible

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​

MessageCause
tenant session required: run sng tenant use NAMEPas 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
conflictNom ou hôte déjà pris, ou ressource en cours de suppression