Le cycle validate, plan, apply
Fonctionnalité déployée et prise en charge. Les champs et commandes décrits ici sont stables au sein de la version v1alpha1.
Tout ce que vous déployez passe par l'état désiré : l'ensemble des manifestes appliqués à votre tenant. Ce guide montre le cycle de travail quotidien et les réflexes qui évitent les mauvaises surprises.
Prérequis
- Une session sur le tenant (
sng tenant use) ;sng config showaffiche le cluster et le tenant courants. - Vos manifestes dans un dossier, un fichier par ressource de préférence.
1. Écrire
Partez d'un gabarit plutôt que d'une page blanche :
sng template gen App api
sng template gen SSMSecret db-password
Ou récupérez l'existant : sng pull exporte tout l'état désiré courant en fichiers.
Un fichier peut contenir plusieurs manifestes séparés par ---. Les kinds acceptés sont
listés dans la référence des manifestes. Ne précisez jamais
de tenant : il est déduit de votre session.
2. Valider
sng validate .
validate OK — 4 document(s)
validate envoie les manifestes à l'API, qui applique exactement les contrôles de
apply : schéma du kind, règles croisées, domaines autorisés, noms réservés. Rien n'est
écrit. Mettez-la dans un hook de pré-commit ou dans la CI sur chaque branche.
3. Prévisualiser
sng plan .
ACTION KIND NAME KEY
create SSMSecret db-password …
update App api …
unchanged App web …
plan compare au contenu actuel de l'état désiré. Un update inattendu signale souvent
qu'un collègue a modifié la ressource depuis votre dernier pull.
Un manifeste présent dans l'état désiré mais absent de votre dossier n'apparaît pas :
apply n'efface jamais rien de lui-même. Pour supprimer, c'est sng kind delete.
4. Appliquer
sng apply .
apply acme — 4 object(s)
La plateforme applique vos changements en moins d'une minute. Suivez l'avancement avec la commande du kind :
sng app describe api
sng secret describe db-password
Pour les autres kinds, la commande qui lit l'état est listée dans sng kind get. sng kind get KIND NAME montre le manifeste enregistré, pas son état.
5. Supprimer
sng kind delete App api
La suppression retire le manifeste de l'état désiré ; la plateforme retire ensuite ce qu'il
décrivait, en moins d'une minute, selon la
politique de suppression du
kind. En script : -y.
6. Relire l'état réel
sng kind list App # ce qui est déclaré
sng kind get App api # un manifeste enregistré
sng app describe api # son état réel
sng pull ./etat-actuel # tout, en fichiers
Comparer sng pull à votre dépôt git est le moyen le plus sûr de détecter une dérive entre ce
que vous croyez avoir appliqué et ce qui l'est.
Réflexes
- Un
planavant chaqueapplyen dehors de la CI. - Des petits fichiers : un manifeste par fichier, nommé
<kind>-<nom>.ymlou rangé commesng pullle fait (<Kind>/<nom>.yml).sng kind editne sait modifier qu'un document. - Pas de valeur secrète dans un manifeste : déclarez un
SSMSecretet référencez-le (Secrets). - Lire le
statusavant de réappliquer en boucle : la raison y est presque toujours.
Si ça ne marche pas
| Ce que vous voyez | Que faire |
|---|---|
validation failed (N issue(s)) | Corrigez chaque ligne error: affichée au-dessus |
invalid manifest … | Le message nomme le champ ; voir la page du kind dans la référence des manifestes |
conflict | Un nom ou un hôte est déjà pris, ou la ressource est en cours de suppression : renommez ou attendez |
La ressource reste en Progressing | Lisez sa raison (sng app describe) et l'index des conditions |
Les autres messages : Erreurs de la CLI.
Pour aller plus loin
- Un
applyest tout ou rien : s'il est interrompu (coupure réseau,Ctrl-C), aucun de vos manifestes n'est pris en compte. Relancez-le. - La plateforme garde l'historique de ce que vous appliquez : vous pouvez figer ce qui tourne ou revenir à une version précédente (Environnements et restauration).
- L'API expose en plus un mécanisme de déploiements et de releases versionnées
(
/v1/deployments,/v1/releases), sans commande CLI pour l'instant. Il est décrit dans la référence de l'API.