Et præ-fabrikeret image er – i modsætning til en rigtig installation – bitidentisk på alle maskiner. Det er dets styrke, men også dets svaghed: efter deploy skal hver maskine individualiseres, for ellers deler alle kloner samme identitet.
Et klonet image deler typisk følgende med “originalen”, og det skal rettes pr. maskine:
| Post | Fil/mekanisme | Hvorfor det er et problem |
|---|---|---|
| Hostname | /etc/hostname | Alle maskiner hedder det samme |
| Machine-ID | /etc/machine-id | DHCP, journald og andre tjenester kan ikke skelne maskinerne |
| SSH host-nøgler | /etc/ssh/ssh_host_* | Klonede nøgler = sikkerhedsproblem og host-key-advarsler |
| Netværkskonfig | /etc/sysconfig/network/, NetworkManager | Statiske IP'er/MAC-bindinger fra originalen følger med |
| Brugere & nøgler | /etc/passwd, authorized_keys | Samme adgangsdata overalt |
Den manuelle metode efter deploy er simpel:
sudo hostnamectl set-hostname pc-aarhus-01
Men den rigtige løsning er at lade en first-boot-mekanisme gøre det automatisk. SUSE's images understøtter tre veje, jf. SLES Minimal VM-dokumentationen:
combustion.iso eller fw_cfg) køres ved første boot og kan sætte hostname, brugere, SSH-nøgler osv. uden menneskelig indgriben.user-data-fil leverer hostname, brugere, SSH-nøgler og kommandoer, fx:#cloud-config hostname: pc-aarhus-01 fqdn: pc-aarhus-01.firma.dk users: - name: soeren sudo: ALL=(ALL) NOPASSWD:ALL ssh_authorized_keys: - ssh-ed25519 AAAA... soeren@laptop
Vigtigt ved klonede images: cloud-init/Combustion rydder selv machine-ID og SSH host-nøgler. Gør du det manuelt, skal du selv slette /etc/machine-id (og lade systemd generere en ny) og regenerere host-nøgler med rm /etc/ssh/ssh_host_* && ssh-keygen -A – ellers svarer alle kloner på samme identitet.
user-data, Combustion-scriptet eller AutoYaST/Agama-profilen, så de findes fra første boot – inkl. sudo-rettigheder og SSH-nøgler.useradd/usermod (eller useraddctl i SLES 16) – fint til enkeltmaskiner, men det bryder med idéen om reproducerbarhed: maskinen afviger nu fra imaget, og det skal dokumenteres.Et image er et statisk øjebliksbillede: pakker, certifikater, GPG-nøgler og repos fryses på byggetidspunktet. Der er tre strategier:
a) Opdatere i stedet for at gen-bygge (nødløsning)
Boot imaget, kør zypper dup (eller zypper up på SLES / transactional-update på MicroOS), og deployér derefter. Ulemper: tager tid pr. maskine, afviger fra “golden master”, og meget gamle images kan have udløbne repo-nøgler eller OS-versioner, der kræver springvis migration.
b) Regelmæssig genopbygning (anbefalet) Byg et nyt image med KIWI efter en fast cadence (fx hver 1.–3. måned, eller ved hver servicepack), gerne automatiseret via OBS eller CI. Så er patch-niveauet altid frisk, og deployment forbliver hurtig. Det er samme filosofi som container-images: et image bør betragtes som forbrugsgods, ikke som en permanent installation.
c) Reducér selve problemet Brug et transactionelt/read-only system (openSUSE MicroOS, SLE Micro), hvor imaget i sagens natur er statisk og opdateringer sker atomisk med rollback – her er “gammelt image” mindre kritisk, fordi opdateringen alligevel sker pr. maskine efter deploy.
Glem ikke ved SLES: et klonet image skal også registreres pr. maskine (SUSEConnect), ellers deler alle kloner én registrering – ligesom med hostname og machine-ID.
Individualisering (hostname, machine-ID, SSH-nøgler, brugere) hører hjemme i first-boot-mekanismen (cloud-init/Combustion/JeOS Firstboot), ikke i selve imaget. Og imagets “alder” håndteres bedst ved regelmæssig genopbygning snarere end ved at lappe et gammelt image i drift – undtagen helt nye images, hvor cloud-init/Combustion fint kan trække nyeste opdateringer ved første boot.