Construire des images de système d’exploitation
OpenFactory transforme une recette normalisée en artefact image et, lorsque demandé et disponible, démarre cet artefact pour vérification. Les builders et étapes exacts varient selon la famille d’image de base et le déploiement.
Ce qu’une recette contrôle
| Domaine | Emplacement canonique | Question de relecture |
|---|---|---|
| Base et intention matérielle | base_image, hardware | S’agit-il de la bonne distribution, version, architecture et profil minimum ? |
| Fonctionnalités et paquets | os.features, os.packages | Les capacités demandées sont-elles présentes et supportées sur cette base ? |
| Services et comptes | os.services, os.users | La configuration et l’accès au moindre privilège sont-ils explicites ? |
| Bureau et image de marque | os.desktop_settings, os.branding | Le bureau sélectionné possède-t-il ces paramètres et actifs ? |
| Installateur et persistance | os.installer, os.persistence | Les exigences install-on-disk et persistance sont-elles réellement testées ? |
| Automatisation personnalisée | os.startup_scripts, pièces jointes, paquets source | Les entrées sont-elles épinglées, bornées et sûres à exécuter sous l’utilisateur déclaré ? |
| Vérification | scenarios | Les tests observent-ils chaque résultat matériel plutôt que le seul boot ? |
Voir Schéma de recette pour la forme complète.
Cycle de vie du build
Le flux de statut public peut inclure planification, configuration, travail sur paquets source, génération d’image, finalisation et tests. Ces étapes ne sont pas garanties d’apparaître avec les mêmes noms pour chaque cible. Suivez l’ID de build renvoyé par la requête de démarrage et traitez le statut courant du backend comme faisant autorité.
Gardez ces résultats séparés :
validatedsignifie que la forme de recette reconnue a été acceptée ;- un build terminal réussi signifie qu’un artefact a été finalisé ;
- un succès de test signifie que les assertions sélectionnées ont réussi dans leur environnement ; et
- la certification ou publication, lorsqu’activée, est une décision de politique ultérieure.
Une progression silencieuse n’est pas une raison de créer un build en double. Reconnectez-vous à la console ou au point de statut du build avec le même ID. Si le build devient terminalement en échec, conservez l’étape, l’erreur et les journaux avant de réessayer.
Workflow recommandé
- Rédigez des critères d’acceptation observables.
- Générez ou modifiez la recette.
- Validez-la et comparez le résultat normalisé avec la conversation complète.
- Inspectez fonctionnalités inférées, sources externes, paramètres d’installateur et scénarios.
- Lancez un build et suivez son ID durable.
- Relisez digest de l’artefact, inventaire des paquets, avertissements et preuves de test.
- Démarrez ou installez dans un environnement jetable adapté à la demande.
- Promouvez ou publiez uniquement via la porte d’approbation applicable.
Guides par thème
| Thème | Usage |
|---|---|
| Images de base | Choisir une famille de build supportée |
| Fonctionnalités | Comprendre les modules de capacité enregistrés |
| Services | Déclarer la configuration des services |
| Logiciel personnalisé | Relire les entrées de paquets depuis dépôts |
| Utilisateurs | Créer des comptes locaux à l’image en toute sécurité |
| Bureau | Choisir et vérifier les paramètres de bureau |
| Scripts de démarrage | Rédiger des unités first-boot bornées |
Commencez par la plus petite image utile. Ajoutez des fonctionnalités seulement après avoir compris le comportement et les preuves de l’artefact précédent.