Skip to Content
Building OsPielāgota programmatūra no avota repozitorijiem

Pielāgota programmatūra no avota repozitorijiem

OpenFactory receptes var norādīt Git repozitoriju kā pielāgotā pakotnes ievadi atbalstītajos attēlu būvētājos. Tas ir piegādes ķēdes jutīgs ceļš: repozitoriju, atrisināto revīziju, iepakošanas instrukcijas, būves atkarības un izveidoto pakotni jāpārskata.

Atbalsts ir atkarīgs no mērķa. Daži būvētāji noraida avota pakotņu būves, tostarp pašreizējos Raspberry Pi un Proxmox ceļus. Pirms solāt, ka pakotne tiks izveidota, apstipriniet pieejamību normalizētajā receptē un būves plānā.

Receptes forma

Pielāgoto pakotņu ieraksti atrodas zem os.custom_packages:

{ "os": { "custom_packages": [ { "name": "my-agent", "git_url": "https://github.com/example/my-agent.git", "branch": "release-1.x" } ] } }

Shēma pieņem zara nosaukumu, nevis nemainīgu commit lauku. Kontrolētai release versijai ierakstiet precīzu commit, ko atrisināja būve, un iekļaujiet to saglabātajā izcelsmē. Tikai mainīgs zars nav atkārtojama ievade.

Sagatavojiet repozitoriju

Pašreizējais pakotnes ceļš sagaida vietējus iepakošanas metadatus, kas piemēroti mērķim. Bieži piemēri ir Debian debian/ direktorijs vai RPM spec. Konkrēta būvētāja uzvedība un atbalstītās mērķa versijas var mainīties, tāpēc minimālu pakotni validējiet izvietotajā vidē, nevis paļaujoties uz statisku saderības tabulu.

Debian iepakošanai pārskatiet vismaz:

  • debian/control avota/dveinārā identitātei un atkarībām;
  • debian/changelog pakotnes versijai;
  • debian/rules un citus izpildāmos maintainer skriptus;
  • instalācijas manifestus un systemd vienības; un
  • licencēšanu un iekļauto trešo pušu materiālu.

RPM iepakošanai pārskatiet spec avotus, būves prasības, scriptlets, failu sarakstu un licences metadatus.

Nedomājiet, ka repozitorija īpašumtiesības padara tā būves skriptus drošus. Pakotņu būves izpilda neuzticamu avota un iepakošanas loģiku būves infrastruktūras izolācijas robežā.

Citi pakotņu vadības līdzekļi

Vietējās pakotnes

Izmantojiet os.packages pakotnēm, ko jau nodrošina izvēlētā distribūcija vai skaidri konfigurēts repozitorijs:

{ "os": { "packages": ["curl", "jq"] } }

Pakotņu pārrakstīšana

os.package_overrides var deklarēt add, remove vai replace:

{ "os": { "package_overrides": [ {"name": "nano", "action": "replace", "replacement": "neovim"}, {"name": "telnet", "action": "remove"} ] } }

Override nav pierādījums, ka atkarību atrisināšana to respektēja. Pārbaudiet galīgo pakotņu inventāru un absence/presence assertions.

Papildu repozitoriji

os.extra_repos ir padziļināta ievade. Nepievienojiet neparakstītu HTTP repozitoriju, kā parādīts vecākos piemēros. Apstiprinātai repozitorija integrācijai vajag HTTPS transportu, piesaistītu parakstīšanas atslēgu, parakstu izpildi, release metadatus, kas piemēroti package manager, un dokumentētu īpašumtiesības un atjaunināšanas politiku. Ja pašreizējais būvētājs nevar attēlot šīs uzticības kontroles, neizmantojiet repozitoriju.

Pieņemšanas pierādījumi

Katram pielāgotajam pakotnei saglabājiet:

  • repozitorija URL un atrisināto commit;
  • avota un deklarētās licences pārskatu;
  • būves vides un atkarību snapshot;
  • būves žurnālus un rezultējošo pakotnes nosaukumu/versiju/arhitektūru;
  • pakotnes digest un repozitorija paraksta pierādījumus, kur piemērojams;
  • galīgo attēla inventāru ar instalēto pakotni;
  • service vai izpildāma faila smoke testus; un
  • noņemšanas un jaunināšanas uzvedību.

Veiksmīga avota pakotnes stadija nepietiek. Attēla būve vēlāk var neizmantot pakotni, un instalēta pakotne joprojām var būt nelietojama.

Problēmu risināšana

  • Iepakošanas metadati noraidīti: validējiet vietējo pakotni lokāli ar to pašu distribūcijas release un arhitektūru.
  • Trūkst būves atkarības: izmantojiet atkarības no apstiprinātiem repozitorijiem šim mērķim; maintainer skriptā klusi nelejupielādējiet nejaušus dveināros failus.
  • Pakotnes nav attēlā: salīdziniet izveidotā dveinārā pakotnes nosaukumu ar normalizēto instalācijas pieprasījumu un galīgo inventāru.
  • Versija nemainījās: atjauniniet vietējos versijas metadatus un apstipriniet, ka tika atrisināts jaunais avota commit.
  • Service neizdevās: pārskatiet tā unit, runtime atkarības, atļaujas un guest žurnālus; pirms rebuild pievienojiet uzvedības līmeņa assertion.