Constructions

La construction transforme un commit en image prête à servir. Cette page décrit comment elle est isolée, ce que le cache fait gagner, ce qu'elle consomme de votre palier, et la chaîne d'approvisionnement qui analyse, inventorie et signe chaque image avant qu'elle n'atteigne la production. Elle dit aussi quoi faire quand une image est refusée pour une vulnérabilité.

Ce qui se passe pendant une construction

1. Récupération du commit, avec un jeton limité au dépôt et à la lecture pour un dépôt raccordé (voir Git).
2. Détection du cadriciel et choix de l'étage : votre Dockerfile, l'image composée ou le repli (voir Cadriciels).
3. Contrôle des variables requises : les noms déclarés par .env.example doivent exister sur l'environnement.
4. Installation des dépendances puis construction de l'image.
5. Porte d'approvisionnement : analyse, inventaire, signature, puis passage à built.

Chaque étape est horodatée dans le journal de construction, que l'écran Déploiement montre en direct et que deployment_log_read rend page par page. Le journal est conservé jusqu'à 64 Mio sans troncature.

Isolation

• La détection lit des fichiers et n'exécute aucun script du dépôt.
• L'image composée par la plateforme n'interpole aucune valeur venue du dépôt dans ses instructions : les commandes viennent d'un catalogue fermé.
• La construction s'exécute sans privilège ; un Dockerfile qui en demande est refusé.
• Le cache n'est jamais partagé entre deux locataires, même à dépendances identiques : un voisin ne peut pas glisser un artefact dans votre image.
• Une construction est arrêtée au-delà de 30 minutes. Les ouvriers de construction la bornent aussi à 4 vCPU, 8 Go de mémoire et 20 Go de disque ; le message d'arrêt nomme la limite atteinte et la valeur observée.

Le cache de construction

Le cache des couches

Les couches d'image d'un projet sont gardées d'une construction à l'autre : une construction dont les dépendances n'ont pas changé repart de là. Ce cache est plafonné à 2 Go par projet et conservé 30 jours.

Pour construire sans aucun cache : ignoreCache: true dans deployment_create, ou Reconstruire quand même sur l'écran Déploiement d'un échec survenu après la construction.

Le cache distant Turborepo

Un monorepo Turborepo peut déposer et relire ses artefacts dans le cache distant du projet. Dans votre intégration continue ou vos scripts, posez :

• TURBO_API à l'adresse de l'API, https://api.bastide.app ;
• TURBO_TEAM à l'identifiant du projet (prj_…) ;
• TURBO_TOKEN à un jeton du projet.

Un artefact qui contient un secret est refusé, et le refus nomme le fichier.

Dans la console, ouvrez Réglages du projet, section « Crochets et cache », carte « Cache distant Turborepo » : vous y réglez la rétention (de 1 à 30 jours, 7 par défaut) et purgez tout le cache. Un agent fait de même avec build_cache_manage, et peut aussi purger des empreintes précises :

{
  "projectId": "prj_01JQ8ZK4M7NP2RSTVWXYZ34567",
  "purge": ["a1b2c3d4e5f60718"],
  "retentionDays": 14
}

Sans purge, seule la rétention change ; une liste purge vide purge tout le cache. Un artefact purgé n'est plus servi dès l'appel. La nouvelle rétention vaut pour les dépôts suivants.

Note. Le panneau « Cache de l'edge et images » de l'écran Domaines concerne le cache qui sert votre site et la transformation d'images, pas la construction : voir Cache.

Ce que la construction consomme

• Minutes : le quota est un plafond dur, sans facturation de dépassement. Une construction annulée ou sautée ne compte rien ; un échec compte ses secondes. Le mois est celui de la fin de la construction, en UTC. Atteint, il refuse les constructions suivantes jusqu'au premier jour du mois suivant ; les sites en ligne continuent d'être servis. Une construction en cours compte à sa fin.
• Constructions simultanées : au-delà du plafond du palier, une construction attend son tour, sans rien perdre. La plateforme a aussi un plafond global.
• Registre : chaque construction le dit au-delà de 80 % du quota ; à 100 %, la construction est refusée. Les releases anciennes sont purgées chaque jour (les dix dernières de chaque environnement et celles qui ont servi la production depuis 30 jours sont gardées).
• Taille d'image : au-delà de 5 Go, la construction est refusée ; au-delà de 1 Go, le fait est rapporté.

La consommation du dernier mois clos se lit dans Réglages du projet, section « Consommation », ou par usage_read. Voir Limites et Facturation.

La chaîne d'approvisionnement

Entre la construction de l'image et son passage à built, la plateforme :

1. analyse l'image avec Trivy ;
2. juge ses vulnérabilités contre le catalogue des vulnérabilités activement exploitées (recopié de celui de la CISA) et le registre des dérogations ;
3. attache à l'image, dans le registre, l'inventaire logiciel (SBOM) au format CycloneDX et le rapport d'analyse ;
4. inscrit l'analyse au journal d'audit ;
5. refuse la production si le verdict l'exige ;
6. signe l'image et celles de ses services. Les nœuds n'exécutent que des images signées.

Le résumé de l'analyse accompagne le passage du déploiement à « Construit » : le nombre de vulnérabilités élevées et moyennes, et ce que la production refuserait.

Ce qui bloque la production

La criticité se lit au plus haut score CVSS v3 rapporté ; la sévérité du fournisseur ne sert que faute de score. En prévisualisation, l'analyse informe et ne bloque pas : c'est là que vous découvrez ce que la production refuserait. Une image que la plateforme n'a pas pu analyser, juger ou signer n'est pas promue en production (chaine_d_approvisionnement_indisponible) : relancez le déploiement, la cause est de son côté.

Corriger une image refusée

Le refus (image_vulnerabilite_critique ou image_vulnerabilite_exploitee) nomme jusqu'à cinq vulnérabilités, avec le paquet, sa version et la version qui corrige. La carte « Pourquoi il a échoué » de l'écran Déploiement le montre.

1. Mettez à jour le paquet nommé à la version qui corrige, dans votre fichier de verrou, puis redéployez. Si le paquet vient de l'image de base, reconstruisez sur une image de base plus récente.
2. Retirez de l'image finale ce qui n'y sert pas. Une faille portée par un outil de construction (npm et ses dépendances, un compilateur) disparaît si l'image finale ne le contient pas. Avec votre Dockerfile, construisez en plusieurs étages et terminez sur une image d'exécution sans gestionnaire de paquets.
3. Demandez une dérogation si aucun correctif n'existe encore, ou s'il ne peut pas être appliqué tout de suite. Une dérogation ne couvre qu'une vulnérabilité critique, jamais une vulnérabilité exploitée. Elle est datée, motivée, signée par le responsable technique de la plateforme chez Glowsoft, et dure sept jours au plus ; elle ne se prolonge pas. Adressez la demande au support, avec l'identifiant de la vulnérabilité, le projet et votre mesure de contournement.

À l'échéance d'une dérogation, la construction suivante est de nouveau bloquée, et le refus nomme la dérogation échue et sa date.

Licences contaminantes et secrets

• L'option « Bloquer les licences AGPL, SSPL et BUSL » (Réglages du projet, « Source et construction ») fait échouer la construction, dans tout environnement, quand un paquet sous l'une de ces licences est dans l'image. Sans elle, le paquet est seulement signalé.
• Une variable d'image dont la valeur a la forme d'un secret connu refuse la production (image_variable_de_secret). Révoquez d'abord la valeur chez son émetteur : elle est dans une couche d'image, donc publiée.

Erreurs fréquentes

Voir aussi : Cadriciels, Déployer, Sécurité, Limites, Facturation.

Signaler une erreur sur cette page