Scripturi de pornire

os.startup_scripts creează lucru systemd one-shot limitat pentru imaginea rezultată. Fiecare intrare declară o comandă shell, pachetele necesare, utilizatorul de execuție și unitatea de ordonare.

Scripturile de pornire sunt cod cu drepturi root, dacă run_as nu spune altfel. Primesc aceeași revizuire ca orice script de instalare.

Forma canonică

{
  "os": {
    "startup_scripts": [
      {
        "name": "write-build-marker",
        "description": "Create a local readiness marker after networking is available.",
        "command": "set -Eeuo pipefail\ninstall -d -m 0755 /var/lib/example\nprintf '%s\\n' ready > /var/lib/example/build-ready",
        "packages": [],
        "run_as": "root",
        "after": "network-online.target"
      }
    ]
  }
}

Câmpurile sunt description și command, nu câmpul vechi script. run_as și after folosesc și ele snake_case. after este un singur șir de unitate systemd, nu un array.

Schema acceptă cel mult 32 de intrări și o dimensiune limitată a comenzii. Validarea respinge comenzile goale și octeții NUL, dar nu face conținutul shell sigur sau idempotent.

Proiectare pentru reîncercări și eșec parțial

O pornire poate fi întreruptă după ce unele efecte secundare au avut loc. Scrieți scripturile astfel încât o nouă rulare fie finalizeze în siguranță, fie iasă cu o stare clară, inspectabilă.

Modele bune includ:

• scriere într-un fișier temporar, verificare, apoi redenumire atomică;
• verificarea dacă utilizatorii, directoarele sau intrările de configurare există deja;
• folosirea install pentru proprietar și mod explicite;
• aplicarea set -Eeuo pipefail și tratarea deliberată a rezultatelor nenule așteptate;
• timeout-uri de rețea limitate și un număr finit de reîncercări; și
• scrierea unui marker de pregătire doar după succesul tuturor pașilor necesari.

Nu vă bazați pe sleep ca verificare de pregătire. Testați dependența reală.

Descărcări externe

Evitați curl ... | sh. Dacă prima pornire trebuie să preia un artefact:

1. folosiți HTTPS cu verificarea certificatului;
2. fixați artefactul așteptat sau versiunea sursei;
3. verificați un digest criptografic sau o semnătură aprobată înainte de execuție;
4. setați timeout-uri de conectare și total;
5. la eșecul verificării, ieșiți cu eroare; și
6. evitați logarea credențialelor sau a URL-urilor semnate.

Pentru comportament cu adevărat offline sau reproductibil, includeți conținut revizuit în imagine sau într-un depozit de pachete aprobat, în loc de descărcare la prima pornire.

Secrete

Nu încorporați credențiale în clar în rețetă, comandă, URL sau marker generat. JSON-ul rețetei și jurnalele de build sunt dovezi păstrate și pot fi vizibile operatorilor. Folosiți un mecanism aprobat de înrolare sau livrare a secretelor la deploy și limitați credențialul rezultat la țintă.

Identitate de execuție

Preferați un cont de serviciu neprivilegiat. Dacă root este necesar, reduceți comanda la cel mai mic pas privilegiat și setați proprietatea explicită a fișierelor. Confirmați că run_as numește un cont creat înainte ca unitatea să pornească.

Verificare

Testați rezultatele, nu doar codul de ieșire al unității:

{
  "type": "file_contains",
  "description": "The startup unit wrote its readiness marker.",
  "params": {
    "path": "/var/lib/example/build-ready",
    "content": "ready"
  }
}

Testați și a doua pornire, o dependență indisponibilă și recuperarea după o primă rulare întreruptă. La eșec, inspectați systemctl status și jurnalul unității.