Aller au contenu principal

Versionner dans git

Disponible

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

Vos manifestes sont du texte : mettez-les dans git. Ce guide propose une organisation qui marche bien avec sng apply et une CI, sans outillage supplémentaire.

Organisation du dépôt​

infra/
├── stackngo.yaml            # informatif (écrit par sng pull)
├── App/
│   ├── api.yml
│   └── web.yml
├── SSMSecret/
│   └── db-password.yml
├── RegistryRepository/
│   └── api.yml
└── DNSRecord/
    └── api.yml

C'est la disposition que produit sng pull : un dossier par kind, un fichier par ressource. sng apply infra/ applique tout ; sng apply infra/App/api.yml une seule ressource.

Pour plusieurs tenants ou environnements, un dossier par cible :

infra/
├── acme-dev/      …
├── acme-prod/     …
└── labs-dev/      …

et, dans la CI, sng tenant use acme-prod && sng apply infra/acme-prod.

Ce qui va dans git, ce qui n'y va pas​

Dans gitPas dans git
Manifestes (App, SSMSecret, DNSRecord, …)Valeurs des secrets (sng secret set, jamais dans un fichier)
Vos gabarits maison~/.config/stackngo/config.yaml (jetons)
Le pipeline CILe status : sng pull ne l'exporte pas, et s'il traîne dans un fichier il est ignoré

Un SSMSecret déclare un secret sans sa valeur : c'est exactement ce qu'on veut versionner.

Pipeline minimal​

Sur chaque branche : sng validate. Sur la branche principale : sng apply. L'identité de la CI vient d'un trust OIDC, sans secret stocké.

.gitlab-ci.yml (extrait)
validate:
  script:
    - sng sso login --oidc
    - sng tenant use acme-prod
    - sng validate infra/acme-prod
    - sng plan infra/acme-prod

deploy:
  rules: [{if: $CI_COMMIT_BRANCH == "main"}]
  script:
    - sng sso login --oidc
    - sng tenant use acme-prod
    - sng apply infra/acme-prod

Les pipelines complets, avec l'installation de la CLI, sont dans GitLab CI et GitHub Actions.

Revue de code​

sng plan dans la CI d'une merge request montre aux relecteurs ce qui va changer, avec le même rendu qu'en local. Collez sa sortie dans la description, ou faites-en un artefact.

Détecter une dérive​

Quelqu'un a pu appliquer à la main (sng app scale, sng kind edit). Pour le savoir :

sng pull /tmp/etat && diff -r /tmp/etat infra/acme/default

Un job planifié qui fait ce diff et échoue s'il y a un écart est une bonne alarme. Pour remettre le tenant conforme : sng apply infra/acme/default.

Revenir en arrière​

Votre dépôt garde l'historique de ce que vous vouliez appliquer. La plateforme garde, de son côté, l'historique de ce qui a réellement été appliqué : vous pouvez figer ce qui tourne ou revenir à une version précédente sans passer par votre dépôt, avec sng env (Environnements et restauration).

Si ça ne marche pas​

Ce que vous voyezQue faire
Le job deploy échoue sur sng sso login --oidcLe trust OIDC de la CI n'est pas en place : voir Déployer sans secret
Le diff après sng pull montre un écartQuelqu'un a modifié une ressource à la main : réappliquez votre dépôt, ou reportez le changement dans git
sng apply infra/ refuse un fichierLe message nomme le fichier et le champ : corrigez-le, ou retirez du dossier les fichiers qui ne sont pas des manifestes

Voir aussi​