Käynnistysskriptit

os.startup_scripts luo rajattua systemd one-shot -työtä valmiille imagelle. Jokainen merkintä määrittelee shell-komennon, tarvittavat paketit, suoritus-käyttäjän ja järjestysyksikön.

Käynnistysskriptit ovat root-oikeuksilla ajettavaa koodia, ellei run_as sano muuta. Ne tarvitsevat saman läpikäynnin kuin mikä tahansa asennusskripti.

Kanoninen muoto

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

Kentät ovat description ja command, ei legacy-kenttä script. run_as ja after käyttävät myös snake_casea. after on yksi systemd-yksikkömerkkijono, ei taulukko.

Skeema hyväksyy enintään 32 merkintää ja rajatun komennon koon. Validointi hylkää tyhjät komennot ja NUL-tavut, mutta se ei tee shell-sisällöstä turvallista tai idempotenttia.

Suunnittelu uudelleenyrityksille ja osittaisille virheille

Käynnistys voi katketa sen jälkeen, kun joitain sivuvaikutuksia on tapahtunut. Kirjoita skriptit niin, että uusi suoritus joko päättyy turvallisesti tai poistuu selkeässä, tarkasteltavassa tilassa.

Hyviä malleja ovat muun muassa:

• kirjoita väliaikaistiedostoon, tarkista, nimeä sitten atomisesti uudelleen;
• tarkista, ovatko käyttäjät, hakemistot tai konfiguraatiomerkit jo olemassa;
• käytä install-komentoa eksplisiittiseen omistajaan ja modeen;
• käytä set -Eeuo pipefail ja käsittele odotetut nollasta poikkeavat tulokset tarkoituksella;
• rajatut verkon timeouts ja äärellinen uudelleenyritysten määrä; ja
• kirjoita readiness marker vasta kun kaikki vaaditut vaiheet onnistuvat.

Älä luota sleep-komentoon readiness-tarkistuksena. Testaa varsinainen riippuvuus.

Ulkoiset lataukset

Vältä curl ... | sh. Jos first bootin täytyy hakea artifact:

1. käytä HTTPS:ää sertifikaatin varmennuksella;
2. kiinnitä odotettu artifact tai lähdeversio;
3. varmista kryptografinen digest tai hyväksytty allekirjoitus ennen suoritusta;
4. aseta connect- ja total-timeouts;
5. fail closed, jos varmennus epäonnistuu; ja
6. älä kirjaa credentials-tietoja tai allekirjoitettuja URL-osoitteita.

Todella offline- tai toistettavaan käyttäytymiseen sisällytä läpikäyty sisältö imageen tai hyväksyttyyn package repositoryyn sen sijaan, että lataat first bootissa.

Salaisuudet

Älä upota plaintext credentials -tietoja reseptiin, komentoon, URL-osoitteeseen tai luotuun markeriin. Reseptin JSON ja build-lokit säilytetään evidence-materiaalina ja voivat näkyä operaattoreille. Käytä hyväksyttyä enrollment- tai secret-delivery-mekanismia deployment-aikana ja rajaa syntynyt credential kohteeseen.

Suoritusidentiteetti

Suosi unprivileged service account -tiliä. Jos root vaaditaan, rajaa komento pienimpään privilegioituun vaiheeseen ja aseta eksplisiittinen file ownership. Varmista, että run_as nimeää tilin, joka on luotu ennen yksikön käynnistymistä.

Varmennus

Testaa tuloksia, älä pelkästään yksikön exit-statusta:

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

Testaa myös toinen boot, poissa oleva riippuvuus ja palautuminen keskeytyneestä ensimmäisestä ajosta. Tarkista virhetilanteessa systemctl status ja yksikön journal.