Σχήμα συνταγής

Οι συνταγές OpenFactory χρησιμοποιούν snake_case JSON. Η κανονική μορφή έχει ένα μικρό φάκελος ανώτατου επιπέδου, ένα αντικείμενο os για τη διαμόρφωση του λειτουργικού συστήματος και ένα Συστοιχία scenarios για επαλήθευση μετά την κατασκευή.

Η επικύρωση αποδεικνύει ότι τα αναγνωρισμένα πεδία έχουν αποδεκτά σχήματα. Δεν το κάνει αποδείξτε ότι υπάρχει κάθε πακέτο, αντιπροσωπεύτηκε κάθε συμπεριφορά που ζητήθηκε ή η εικόνα και οι δοκιμές θα πετύχουν. Τα άγνωστα πεδία ενδέχεται να αγνοηθούν για επιστροφή συμβατότητα, επομένως ελέγχετε πάντα την κανονικοποιημένη συνταγή που επιστρέφεται από το προϊόν.

Κανονικός φάκελος

{
  "name": "debian-web-check",
  "display_name": "Debian Web Check",
  "description": "Small Debian image with explicit smoke tests.",
  "base_image": "debian-trixie",
  "use_case": "Server evaluation",
  "hardware": {},
  "os": {},
  "scenarios": [],
  "publish_to": ["local"]
}

Μην χρησιμοποιείτε πεδία camelCase όπως baseImage ή startupScripts. Το Ο επικυρωτής συμβατότητας δέχεται ορισμένες παλαιότερες επίπεδες συνταγές, αλλά κανονικοποιημένη απόδοση ενσωματώνει τα πεδία OS κάτω από το os. Οι νέες ενσωματώσεις θα πρέπει να στέλνουν την κανονική μορφή.

Πεδία ανώτατου επιπέδου

Υπάρχουν προηγμένα πεδία ειδικά για τον στόχο για επαναμεταχείριση πηγής ISO, επισκέπτης του Proxmox ωφέλιμα φορτία, προέλευση πολιτικής και ενσωματώσεις παράδοσης. Χρησιμοποιήστε το πρόγραμμα επεξεργασίας ή το API συμβόλαιο για την αναπτυγμένη έκδοση αντί να αντιγράψετε ένα παλιό παράδειγμα.

Υλικό

{
  "hardware": {
    "platform": "pc",
    "architecture": "x86_64",
    "gpu": null,
    "min_cpu_cores": 2,
    "min_memory_gb": 4,
    "min_storage_gb": 16,
    "nic_count": 1
  }
}

Το platform είναι pc, phone ή raspberry_pi; οι υποστηριζόμενες τιμές της συσκευής είναι συγκεκριμένου στόχου. Το architecture είναι x86_64 ή aarch64. Όνομα τιμών GPU a υποστηριζόμενος προμηθευτής ή συνδυασμός προμηθευτή. Αυτές είναι δηλωμένες απαιτήσεις, όχι απόδειξη ότι μια εικόνα που προέκυψε δοκιμάστηκε σε αντίστοιχο φυσικό υλικό.

Αντικείμενο λειτουργικού συστήματος

Τα κοινά πεδία os είναι:

Η παρουσία ενός πεδίου ακεραιότητας ή ασφάλειας αποτελεί πρόθεση διαμόρφωσης. Είναι δεν αποδεικνύουν ότι ο μηχανισμός κατασκευάστηκε, επιβλήθηκε κατά το χρόνο εκτέλεσης ή πιστοποιήθηκε για ένα καθεστώς συμμόρφωσης. Απαιτούνται αντίστοιχες αποδείξεις κατασκευής και δοκιμής.

Χρήστες

{
  "os": {
    "users": [
      {
        "username": "deploy",
        "full_name": "Deployment Operator",
        "groups": ["sudo"],
        "shell": "/bin/bash"
      }
    ]
  }
}

Τα ονόματα χρηστών και ομάδων περιορίζονται σε ασφαλείς χαρακτήρες και μήκος λογαριασμού Linux. Αν αφήσετε το password μη καθορισμένο, δημιουργείται ένας λογαριασμός κλειδωμένος με κωδικό πρόσβασης μόνο για κλειδί ή ροές εργασιών διαπιστευτηρίων χρόνου ανάπτυξης. Αποφύγετε τα διαπιστευτήρια απλού κειμένου στα αποθηκευμένα συνταγές.

Υπηρεσίες

{
  "os": {
    "services": [
      {
        "name": "ssh",
        "enabled": true,
        "config": {
          "port": 22,
          "disable_password_auth": true
        }
      }
    ]
  }
}

Το config είναι ειδικό για την υπηρεσία. Ένα συντακτικά έγκυρο κλειδί μπορεί ακόμα να αγνοηθεί από μια γεννήτρια που δεν την υλοποιεί. Επαληθεύστε την κανονικοποιημένη συνταγή που δημιουργήθηκε διαμόρφωση και συμπεριφορά επισκέπτη.

Ασφάλεια και πρόγραμμα εγκατάστασης

{
  "os": {
    "security": {
      "hardening_level": "standard",
      "disk_encryption": false,
      "audit_logging": true,
      "selinux": false,
      "fail2ban": true
    },
    "installer": {
      "enabled": false,
      "type": "calamares",
      "desktop_launcher": true,
      "bootloader": "grub",
      "delivery": [],
      "user_setup": "build_time"
    }
  }
}

Οι τύποι προγράμματος εγκατάστασης εξαρτώνται από τον στόχο (calamares, anaconda ή elster-mobile). Η ενεργοποίηση ενός προγράμματος εγκατάστασης πρέπει να ακολουθείται από έναν δίσκο μιας χρήσης δοκιμή εγκατάστασης? ένα εικονίδιο σε μια ζωντανή επιφάνεια εργασίας δεν αποτελεί απόδειξη ότι η εγκατάσταση λειτουργεί.

Σενάρια εκκίνησης

{
  "os": {
    "startup_scripts": [
      {
        "name": "write-build-marker",
        "description": "Create a local marker after networking is available.",
        "command": "install -m 0644 /dev/null /var/lib/example-ready",
        "packages": [],
        "run_as": "root",
        "after": "network.target"
      }
    ]
  }
}

Γίνονται δεκτά το πολύ 32 σενάρια εκκίνησης. Οι εντολές δεν πρέπει να είναι κενές και δεν μπορούν περιέχει NUL byte. Αντιμετωπίστε τα ως κώδικα κελύφους με δυνατότητα root εκτός εάν λέει το run_as αλλιώς? αναθεωρήστε την ανικανότητα, τις αναφορές, την αποτυχία δικτύου και τη μυστική έκθεση.

Σενάρια και ισχυρισμοί

{
  "scenarios": [
    {
      "id": "primary-smoke",
      "name": "Primary image smoke test",
      "enabled": true,
      "tests": ["boot", "login", "packages"],
      "custom_tests": [
        {
          "description": "Confirm SSH is enabled on the configured port.",
          "assertions": [
            {
              "type": "service_enabled",
              "description": "The SSH service starts at boot.",
              "params": {"service": "ssh"}
            },
            {
              "type": "port_listening",
              "description": "The guest listens on TCP port 22.",
              "params": {"port": 22}
            }
          ]
        }
      ]
    }
  ]
}

Ένα σενάριο μπορεί επίσης να ορίσει ένα topology με VM και δίκτυα, μορφή αναφοράς δοκιμές και ρυθμίσεις CIS. Μια παραλειπόμενη τοπολογία έχει ως προεπιλογή το κανονικό single-VM μονοπάτι. Οι ισχυρισμοί χρειάζονται μια αναγνώσιμη από τον άνθρωπο περιγραφή και συγκεκριμένες παραμέτρους για τον τύπο. Άγνωστοι τύποι ισχυρισμών ενδέχεται να επιβιώσουν από την ανάλυση σχήματος, επομένως επιβεβαιώστε τον δρομέα τους υποστηρίζει πριν τους αντιμετωπίσει ως αποδεικτικά στοιχεία.

Πλήρες Παράδειγμα Minimal

{
  "name": "debian-web-check",
  "display_name": "Debian Web Check",
  "description": "Debian image with SSH, curl, and explicit smoke tests.",
  "base_image": "debian-trixie",
  "use_case": "Server evaluation",
  "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"],
    "users": [
      {
        "username": "deploy",
        "groups": ["sudo"],
        "shell": "/bin/bash"
      }
    ],
    "services": [
      {
        "name": "ssh",
        "enabled": true,
        "config": {"port": 22, "disable_password_auth": true}
      }
    ],
    "security": {
      "hardening_level": "standard",
      "audit_logging": true
    },
    "installer": {"enabled": false}
  },
  "scenarios": [
    {
      "id": "primary-smoke",
      "name": "Primary image smoke test",
      "enabled": true,
      "tests": ["boot", "login", "packages"]
    }
  ],
  "publish_to": ["local"]
}

Ροή εργασιών επικύρωσης

1. Επικυρώστε το JSON μέσω του τρέχοντος προγράμματος επεξεργασίας συνταγών, API ή MCP validate_recipe εργαλείο.
2. Συγκρίνετε την επιστρεφόμενη κανονικοποιημένη συνταγή με την αρχική αίτηση.
3. Αντιμετωπίστε τα άγνωστα πεδία που χάθηκαν ως ελάττωμα στη συνταγή, όχι ως επιτυχημένο διαμόρφωσης.
4. Κατασκευάστε μόνο μετά την παρουσίαση ρητών απαιτήσεων.
5. Επιθεωρήστε τα αποδεικτικά στοιχεία που δημιουργήθηκαν και εκτελέστε ισχυρισμούς εναντίον του επισκέπτη που προέκυψε.

Δείτε το Your First Build για αποτυχία και λήψη καθοδήγηση ανάκτησης.