Skip to Content
Getting StartedComprendre les recettes

Comprendre les recettes

Un BuildRecipe est la spécification normalisée qu’OpenFactory envoie au pipeline d’image. Le chat peut aider à la rédiger, mais la recette, les instantanés sources, les fichiers générés et les preuves de test définissent un build.

Modèle mental

La recette canonique comporte quatre couches principales :

  1. Identité et cible : nom, description, image de base et intention matérielle.
  2. Système d’exploitation : fonctionnalités, paquets, services, utilisateurs, sécurité, bureau, installateur, pièces jointes et scripts de démarrage sous os.
  3. Vérification : un ou plusieurs scénarios avec tests intégrés et assertions personnalisées.
  4. Intention de livraison : destinations de publication demandées et paramètres de livraison optionnels.
{
  "name": "debian-web-check",
  "display_name": "Debian Web Check",
  "description": "Small Debian image with explicit smoke tests.",
  "base_image": "debian-trixie",
  "hardware": {
    "platform": "pc",
    "architecture": "x86_64",
    "min_cpu_cores": 2,
    "min_memory_gb": 4,
    "min_storage_gb": 16,
    "nic_count": 1
  },
  "os": {
    "features": ["ssh"],
    "packages": ["curl"],
    "services": [
      {
        "name": "ssh",
        "enabled": true,
        "config": {"port": 22, "disable_password_auth": true}
      }
    ],
    "security": {
      "hardening_level": "standard",
      "audit_logging": true
    }
  },
  "scenarios": [
    {
      "id": "primary-smoke",
      "name": "Primary image smoke test",
      "enabled": true,
      "tests": ["boot", "login", "packages"]
    }
  ],
  "publish_to": ["local"]
}

Utilisez snake_case. Les nouvelles intégrations ne doivent pas envoyer d’anciennes formes comme baseImage, features au niveau racine ou startupScripts.

Trois vérifications, trois réponses différentes

Validation de schéma

La validation répond : « Les données reconnues ont-elles une forme acceptable ? » Elle ne prouve pas que les paquets existent ou que le comportement fonctionne. Certains champs inconnus sont ignorés pour compatibilité ; un succès de validation peut donc omettre une demande importante.

Comparez toujours la recette normalisée retournée avec le chat et les exigences d’origine. Un bureau, une application, un installateur, une pièce jointe ou un test manquant est un défaut de recette même si la validation indique valid.

Preuve de build

Un build réussi répond : « Le pipeline a-t-il produit un artefact ? » Il ne prouve pas que chaque fonctionnalité prévue est dans l’image. Inspectez l’inventaire des paquets, la provenance des sources, les avertissements et les preuves d’étapes de build.

Vérification invité

Les tests invité répondent à des questions d’exécution étroites : si la VM a démarré, si un service est actif, si un port écoute, si un fichier a le contenu attendu ou si une application s’est lancée. Une assertion réussie ne supporte que le comportement qu’elle a réellement observé.

Les paramètres de sécurité expriment une intention

Les valeurs hardening_level acceptées sont minimal, standard et strict, mais ces libellés ne sont pas des profils de conformité portables. Les générateurs cibles peuvent les interpréter différemment. Si vous exigez un benchmark, sélectionnez le benchmark applicable exact et conservez les résultats par contrôle ; n’inférez pas la conformité CIS depuis strict.

De même, disk_encryption, audit_logging, SELinux, fail2ban, Secure Boot, dm-verity et les paramètres d’installateur exigent des tests d’artefact et d’exécution correspondants.

Chat et propriété de la recette

Lorsque vous validez ou modifiez une recette issue du chat, la conversation existante reste partie du contexte de rédaction. La validation doit affiner la recette courante, pas la remplacer silencieusement par un défaut générique. La recette normalisée reste néanmoins le point de contrôle final avant build.

Pour chaque exigence matérielle :

  • trouvez le champ normalisé correspondant ;
  • confirmez sa valeur et sa portée cible ;
  • ajoutez une assertion lorsqu’une preuve d’exécution est possible ; et
  • conservez le travail réservé au déploiement comme avertissement explicite plutôt que de prétendre qu’il s’est produit pendant le build d’image.

Liste de relecture

  • L’image de base et l’architecture sont-elles correctes ?
  • Toutes les fonctionnalités bureau et application demandées sont-elles présentes ?
  • Les sources externes sont-elles épinglées et licenciées pour l’usage prévu ?
  • Les secrets sont-ils absents des champs et scripts de recette enregistrés ?
  • L’installateur est-il configuré et testé sur un disque jetable si demandé ?
  • Les scénarios testent-ils les critères d’acceptation réels ?
  • Les exigences non supportées ou au moment du déploiement sont-elles signalées ?

Voir Schéma de recette pour la référence des champs et Votre premier build pour le workflow de build et téléchargement.

Votre premier buildGuides de build