Aller au contenu principal

Construire et pousser des images

Bêta

Fonctionnalité en cours de déploiement. L'interface décrite ici est celle de la prochaine livraison : elle peut encore évoluer, et n'est pas forcément activée sur votre tenant.

Votre pipeline construit une image, la pousse dans le registre du tenant et met à jour l'App qui l'utilise. Le job s'authentifie auprès du registre avec sa session OIDC : aucun secret à stocker.

Prérequis​

Un dépôt déclaré dans le tenant :

sng registry create api

ou, en manifeste :

infra/RegistryRepository/api.yml
apiVersion: registry.stackngo.io/v1alpha1
kind: RegistryRepository
metadata:
  name: api
spec:
  retention:
    keepLastCount: 20
    keepTagsRegex: ["^v\\d+\\.\\d+\\.\\d+$"]

Le dépôt s'appelle <registre>/acme/api. Le nom d'hôte du registre est indiqué par sng registry login ; voir Pousser et tirer.

La session OIDC du job​

Le trust utilisé par le job doit avoir registry:push sur le dépôt. La policy readwrite l'inclut ; sinon, ajoutez une policy :

{
  "Version": "1",
  "Statement": [
    {"Effect": "Allow", "Actions": ["registry:push", "registry:pull"], "Resources": ["repository/api"]},
    {"Effect": "Allow", "Actions": ["deploy:read", "deploy:write", "deploy:list"], "Resources": ["*"]}
  ]
}
sng tenant policy create ci-api -f ci-api.json
sng tenant policy attach ci-api --oidc-trust gitlab-deploy

Dans le job, sng registry utilise la session courante :

build-and-push:
  extends: .sng
  stage: deploy
  image: docker:27
  services: [docker:27-dind]
  script:
    - sng registry login                      # docker login avec la session du job
    - docker build -t api:$CI_COMMIT_SHORT_SHA .
    - sng registry build --from-image api:$CI_COMMIT_SHORT_SHA

Ou sng registry build construit, pousse, puis analyse l'image avec trivy si l'image du job le fournit (sinon un avertissement s'affiche et le job continue). --fail-on fait échouer le job sur une vulnérabilité grave, ou si trivy manque :

    - sng registry build . -t api:$CI_COMMIT_SHORT_SHA --fail-on CRITICAL

Et les clés d'accès au registre ?​

Une clé d'accès au registre (RegistryAccessKey) sert avant tout à vos App pour tirer vos images privées (imagePullSecrets). Pour pousser depuis une CI externe, préférez la session OIDC ci-dessus : aucun secret à stocker ni à renouveler.

Une clé reste utile quand le job ne peut pas ouvrir de session :

  • job exécuté par une App de votre tenant : déclarez la clé avec ci: true, et l'App lit ses identifiants dans ses variables d'environnement. Sans ci: true, une App qui les cite dans env ou envFrom est refusée ;
  • outil externe sans OIDC : un administrateur du tenant lit les identifiants avec sng registry access-key credentials NAME --show-password et les recopie dans les variables de la CI ; à refaire après chaque renouvellement.

Détail dans Clés d'accès au registre.

Mettre à jour l'App​

L'image poussée doit se retrouver dans le manifeste. Deux approches :

Tag mouvant et redémarrage. L'App référence acme/api:main ; le job pousse ce tag puis force un redémarrage :

sng app restart api

Simple, mais l'état désiré ne dit pas quelle version tourne.

Tag immuable dans le manifeste. Le job réécrit l'image dans le fichier et applique :

sed -i "s#\(image: .*/acme/api:\).*#\1$CI_COMMIT_SHORT_SHA#" infra/App/api.yml
sng apply infra/App/api.yml
git commit -am "deploy api $CI_COMMIT_SHORT_SHA" && git push   # si vous voulez la trace dans git

Plus de rigueur : sng pull et votre dépôt disent exactement ce qui tourne, et sng env restore ramène à une version précise.

Tirer l'image depuis le tenant​

Une App ne reçoit pas d'accès au registre automatiquement, même dans le même tenant. Déclarez une clé d'accès en lecture (actions: [pull]) : la plateforme prépare l'identifiant <clé>-registry, que vous référencez dans spec.imagePullSecrets (Clés d'accès au registre). Un dépôt public: true se tire sans authentification. Pour un registre externe privé, voir (Variables et secrets).

Voir aussi​