Skip to Content
Building OsOpstartsscripts

Opstartsscripts

os.startup_scripts opretter afgrænset systemd one-shot-arbejde for det resulterende image. Hver post angiver en shell-kommando, påkrævede pakker, udførelsesbruger og rækkefølge-enhed.

Opstartsscripts er root-kapabel kode, medmindre run_as siger andet. De skal have samme gennemgang som ethvert installationsscript.

Kanonisk form

{
  "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"
      }
    ]
  }
}

Felterne er description og command, ikke det legacy-felt script. run_as og after bruger også snake_case. after er én systemd-enhedsstreng, ikke et array.

Skemaet accepterer højst 32 poster og en afgrænset kommandostørrelse. Validering afviser tomme kommandoer og NUL-bytes, men gør shell-indhold hverken sikkert eller idempotent.

Design til retries og delvise fejl

En boot kan afbrydes efter at nogle sideeffekter allerede er sket. Skriv scripts så et nyt kald enten afslutter sikkert eller stopper med en klar, inspicerbar tilstand.

Gode mønstre omfatter:

  • skriv til en midlertidig fil, verificer, omdøb derefter atomisk;
  • tjek om brugere, mapper eller konfigurationsposter allerede findes;
  • brug install for eksplicit ejer og mode;
  • anvend set -Eeuo pipefail og håndter forventede nonzero-resultater bevidst;
  • afgrænsede netværkstimeouts og et endeligt antal retries; og
  • skriv en readiness marker først når alle påkrævede trin lykkes.

Stol ikke på sleep som readiness-check. Undersøg den faktiske afhængighed.

Eksterne downloads

Undgå curl ... | sh. Hvis first boot skal hente et artifact:

  1. brug HTTPS med certifikatverifikation;
  2. pin det forventede artifact eller kildeversion;
  3. verificer et kryptografisk digest eller godkendt signatur før udførelse;
  4. sæt connect- og total-timeouts;
  5. fail closed hvis verifikation fejler; og
  6. undgå at logge credentials eller signerede URL’er.

For ægte offline eller reproducerbar adfærd, læg gennemgået indhold i image eller et godkendt package repository i stedet for at downloade ved first boot.

Hemmeligheder

Indlejr aldrig plaintext credentials i opskrift, kommando, URL eller genereret marker. Opskrift-JSON og buildlogs gemmes som evidence og kan være synlige for operatører. Brug godkendt enrollment eller secret-delivery ved deployment og afgræns det resulterende credential til målet.

Udførelsesidentitet

Foretræk en unprivileged service account. Kræves root, reducer kommandoen til det mindste privilegerede trin og sæt eksplicit file ownership. Bekræft at run_as navngiver en konto oprettet før enheden starter.

Verifikation

Test resultater, ikke kun enhedens exit-status:

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

Test også anden boot, utilgængelig afhængighed og genopretning efter afbrudt første kørsel. Inspicer systemctl status og enhedens journal ved fejl.

TjenesterImage-lokale brugere