Skip to Content
Building OsBuild funkcijas

Build funkcijas

Feature ir nosaukts build modulis. Tā reģistra ieraksts var deklarēt pakotnes vienai vai vairākām distribūciju ģimenēm un var ietvert arī build hooks, aliasus, capability metadata un guest assertions.

Feature pievienošana izsaka nolūku. Tā pati par sevi ne pierāda, ka katra pakotne bija pieejama, katrs hook darbojās vai rezultāta uzvedība strādā mērķa attēlā. Receptes validācija, build pabeigšana un guest verifikācija ir atsevišķi vārti.

Atrast pašreizējo feature kopu

Izmantojiet feature selector vai feature-catalog API izvietotajā OpenFactory versijā. Šī izvade ir autoritatīva darbojošajai versijai. Statiskie saraksti ātri noveco, un daži reģistra ieraksti ir paslēpti, jo tie atbalsta iekšējus fixtures vai nepabeigtas integrācijas.

Pirms feature izvēles pārbaudiet:

  • vai tas ir redzams un iespējots jūsu kontam;
  • vai tas deklarē pakotnes receptes distribūcijas ģimenei;
  • vai tā ārējie avoti ir piesprausti un iegūstami;
  • vai tam ir assertions, kas pierāda jums vajadzīgo uzvedību; un
  • vai tas konfliktē ar citu pieprasīto moduli.

Reprezentatīvās kategorijas

Reģistrs pašlaik ietver moduļus kategorijās, piemēram:

KategorijaPiemēriPieprasāmie pierādījumi
Desktopdesktop-kde, desktop-gnome-minimal, krita, kdenlivesesijas tips, instalētās pakotnes, palaišanas uzvedība un īsts darbvirsmas smoke test
Komandrinda un izstrādegit, curl, python, nodejs, rustpakotņu un versiju inventārs un izpildāmo smoke testi
Infrastruktūranginx, postgresql, redis, docker, ansiblepakalpojuma konfigurācija, enabled/running stāvoklis, porti un application-level veselība
Drošībafirewall, audit-logging, security-hardening, apparmorģenerēta policy, aktīvs runtime stāvoklis, negatīvi testi un dokumentēti izņēmumi
Atbilstības orientēticis-benchmarks, gxp, disa-stig, nist-800-53precīzs benchmark vai control avots, piemērojamība, rezultāti pa control un cilvēka lēmums
AI rīkiollama, alpaca, aider, codex-clipiesprausta source vai package izcelsme, modeļu lejupielādes robeža, palaišanas tests un resursu prasības

Piemēri nav saderības matrica. Feature nosaukums var pastāvēt, kamēr konkrēta distribūcijas implementācija paliek daļēja.

Feature, pakotne un pakalpojums atšķiras

  • os.features izvēlas reģistrētos build moduļus.
  • os.packages lūdz vietējo package manager konkrētās pakotnes.
  • os.services nodrošina nosauktu enablement un konfigurācijas nolūku.

Piemēram:

{ "os": { "features": ["ssh", "firewall"], "packages": ["curl", "jq"], "services": [ { "name": "ssh", "enabled": true, "config": { "port": 22, "disable_password_auth": true } } ] } }

Derīga service config joprojām var saturēt atslēgu, ko ģenerators neizlieto. Pārbaudiet normalizēto recepti un testējiet ģenerēto guest.

Drošības un atbilstības etiķetes

security-hardening instalē un konfigurē vispārīgu hardening baseline. Tas nav sinonīms CIS profilam. Receptes hardening_level ir konfigurācijas etiķete, ko interpretē mērķim specifiski ģeneratori; tā nav sertifikācija vai universāla atbilstība CIS Level 1 vai Level 2.

Feature cis-benchmarks ir specifiskāks Ubuntu 24.04 Level 1 remediation ceļš. Citas bāzes nesaņem to pašu lomu. Precīzu robežu skatiet CIS benchmark pierādījumi.

Tāpat GxP, HIPAA, SOC 2, PCI DSS, NIST vai DISA nosaukta feature ieslēgšana neizveido organizatorisku atbilstību. Tā var pievienot pakotnes, konfigurāciju un testus, kas veido pierādījumus atsevišķi pārvaldītai novērtēšanai.

Feature droša kombinēšana

  1. Sāciet ar mazāko kopu, kas izsaka pieprasīto uzvedību.
  2. Validējiet recepti un pārbaudiet normalizēto izvadi atmestajiem vai secinātajiem laukiem.
  3. Pārskatiet paplašināto pakotņu un hook plānu.
  4. Veiciet build vienu reizi un sekojiet tā ilgtermiņa build ID.
  5. Palaidiet feature specifiskos assertions ielādētā guest.
  6. Skaidri fiksējiet kļūdas un apzinātus izņēmumus.
  7. Pievienojiet nākamo feature tikai pēc tam, kad saprotat pašreizējo baseline.

Kanoniskajai JSON formai skatiet Receptes shēma.