Kort fortalt

Automatiske Docker-opdateringer kan bygges uden en særskilt opdateringscontainer. Den foreslåede model kombinerer en timer på værten, fastlåsning af images med digest, vedvarende status for hver opdatering og rollback til et lokalt gemt image.

Det er dog vigtigt at skelne mellem en plan og en afprøvet løsning. Forslaget er endnu ikke installeret eller testet på de to VPS’er. Og med én gatewayinstans kan man ikke love nul nedetid eller, at alle igangværende forespørgsler overlever et skift.

Hvad kildekoden fortæller

• Udgivelsesarbejdsgangen tager versionsnumre på formen v plus hoved- og underversion, eksempelvis v3.12. Den udgiver taggene latest, 3.12, v3.12 og en kort commit-SHA, men opretter ikke automatisk et versionsalias som v3.x. Arbejdsgangen er sat op til fire arkitekturer; det beviser ikke i sig selv, at en bestemt udgivelse er bygget til dem alle. Udgivelsesarbejdsgang
• Gatewayen bygges i den nuværende Compose-konfiguration, lytter på port 8080 på værten og bruger en skrivebeskyttet konfigurationsmappe. Mailen ligger i hukommelsen, så det er vigtigt ikke at genstarte mailcontaineren under en gatewayopdatering. Deploy-konfiguration
• Det udgivne image starter projektets rodindgang. Opstarten afhænger af lokal konfiguration til modelleregistret, men den mappe er ikke kopieret ind i imaget. En ekstern installation skal derfor stadig have konfigurationsfilen; et image alene er ikke nok. Dockerfile, opstartsindgang
• Den aktuelle modeloversigt læser et øjebliksbillede af registret og sender ikke en rigtig chatforespørgsel. Sundhedsendpointet melder statisk, at tjenesten lever. Ingen af delene beviser, at en upstream-konto er varmet op, eller at en chat virker. Modeloversigt, sundhedsrute
• Ved et stop-signal annullerer programmet sin servicekontekst og giver HTTP-serveren fem sekunder til at lukke. En længere frist for at stoppe containeren er derfor ikke i sig selv garanti for, at lange streamingforespørgsler afsluttes. Nedlukningslogik

Forslaget ændrer ikke mailen, synkroniserer ikke kontotilstand, opgraderer ikke afhængigheder og indfører ikke fjernkildekode. Det lover heller ikke et præcist samtidigt skift på begge servere. En egentlig tabsfri overgang ville kræve særskilt design med to instanser, skift af indgangspunkt og dræning af forbindelser.

Sådan skal opdateringen fungere

Den planlagte indgang er scripts/auto-update.sh, men scriptet er endnu ikke oprettet. Værten skal som minimum have Bash, Docker Engine, Compose-plugin, curl, jq, flock og Skopeo til at læse image-manifester uden først at hente image-lagene. De konkrete versioner og Linux-distributioner skal kontrolleres under implementeringen.

Scriptet skal køre på værten under en beskyttet konto og tale direkte med den lokale Docker-installation. Docker-socketen og registeradgangskoder skal ikke monteres i en container. Kontoen har stadig Docker-administratorrettigheder; fraværet af et socket-mount fjerner ikke den risiko.

Brug digest, ikke et flytbart tag

Et tag som latest kan pege på forskellige images over tid. Derfor bruges det kun til at finde ud af, om der er kommet en ny udgave. Selve deploymenten skal altid referere til image-adressen med en fast digest. Compose understøtter image-referencer med digest. 1

Hold styr på tre forskellige identifikatorer hver for sig: digest for det flerarkitekturelle indeks, digest for platformens manifest og Docker-image-ID’et lokalt. De er ikke direkte sammenlignelige.

Før et skift skal scriptet gemme det kørende containers image-ID under et særligt lokalt tag og kontrollere, at den gamle tjeneste er sund. Så afhænger rollback ikke af, at netværket stadig virker, eller at det gamle image kan hentes igen.

Opdateringsstatus skal gemmes som data, der parses strengt — aldrig som tekst, der eksekveres. Skriv først til en midlertidig fil i samme mappe, byt derefter filen atomisk, og sørg for, at både fil og mappe bliver synkroniseret til disk, når status er kritisk. Et atomisk filskift alene er ikke garanti for, at data overlever strømsvigt.

Opdatering trin for trin

1. Tag en ikke-blokerende fillås. Hvis en anden opdatering allerede kører, afsluttes forsøget uden støj. Opdatering, rollback, initialisering og oprydning skal bruge samme lås.
2. Afslut først en eventuel ufuldstændig transaktion. Kontrollér derefter Compose-projektnavn, at der kun er én gatewaycontainer, konfigurationsfingeraftryk og mailcontainerens identitet. Ved uventede manuelle ændringer skal scriptet stoppe frem for at overtage.
3. Hent kun manifestet og beregn en digest af samme type som den gemte. Netværks-, adgangs- eller parsefejl må ikke behandles som et nyt image, og den nuværende tjeneste skal blive stående.
4. Hvis digesten ikke har ændret sig, skal scriptet hverken hente image-lag, genskabe containere eller skrive en opdateringshændelse. En digest, der allerede er sat i karantæne efter en fejl, skal også springes over, indtil der kommer en ny digest, eller en administrator fjerner karantænen.
5. Hent det fastlåste image, og kontrollér, at det passer til værtens platform, og at der er diskplads. Den gamle gateway skal fortsætte imens. En mislykket download må ikke påvirke den kørende container.
6. Gem rollback-imaget og kompatibel konfiguration, og skriv status som en klargjort transaktion, før gatewayen genskabes.
7. Kontrollér, at den nye container kører det forventede image og består sundhedstjekket. Først da må den nye version markeres som godkendt.
8. Hvis genskabelsen fejler, eller sundhedsvinduet udløber, genskabes gatewayen med det lokale gamle image og den oprindelige konfiguration. Kør de samme sundhedstjek igen.
9. Hvis rollback lykkes, genskabes den gemte deploymentreference, den fejlslagne digest sættes i karantæne, og hændelsen logges. Hvis rollback også fejler, skal scriptet bevare gendannelsesmaterialet, melde fejl og advare — ikke genstarte i en endeløs løkke.

Skitse til centrale kommandoer:

# Værdierne skal komme fra en valideret konfiguration, som almindelige brugere ikke kan ændre.
exec 9>"$LOCK_FILE"
flock -n 9 || exit 0

# Læs kun manifestet. Verificér først Skopeos autentificering og håndtering af rå manifester.
timeout --kill-after=2s 15s \
  skopeo inspect --authfile "$DOCKER_CONFIG/config.json" \
  --raw "docker://$TRACK_IMAGE" \
  </dev/null >"$MANIFEST_TMP"
# Kontrollér afslutningsstatus før digesten beregnes.
# Brug aldrig delvist output fra et mislykket kald.

# NEW_REF skal være en valideret adresse af formen ghcr.io/repo@sha256:...
timeout --kill-after=5s 600s \
  docker pull "$NEW_REF" </dev/null

# Transaktionen skal være gemt, og det lokale rollback-image kontrolleret på forhånd.
APP_IMAGE="$NEW_REF" timeout --kill-after=5s 60s \
  docker compose --project-name "$PROJECT" \
  --project-directory "$DEPLOY_DIR" -f "$COMPOSE_FILE" \
  up -d --no-deps --no-build --pull never app </dev/null

# Ved fejl: OLD_LOCAL_REF er et gemt og kontrolleret lokalt tag for det gamle image.
APP_IMAGE="$OLD_LOCAL_REF" timeout --kill-after=5s 60s \
  docker compose --project-name "$PROJECT" \
  --project-directory "$DEPLOY_DIR" -f "$COMPOSE_FILE" \
  up -d --no-deps --no-build --pull never app </dev/null

Kommandoen retter sig kun mod gatewaytjenesten. --no-build, --no-deps og --pull never begrænser henholdsvis bygning, opstart af afhængige tjenester og ekstra image-hentning under genskabelsen. 2 Der skal ikke køres en genstart af hele Compose-projektet, slettes forældreløse tjenester eller stoppes tjenester uden for gatewayen.

En timeout betyder ikke nødvendigvis, at Docker er færdig med en baggrundsoperation. Efter timeout skal scriptet først undersøge den faktiske containertilstand og koordinere en eventuel gendannelse. Det må ikke starte et konkurrerende skift med det samme. Tvungen afslutning eller strømsvigt kan heller ikke håndteres alene med en exit-trap; næste opstart skal prioritere den gemte transaktion.

Sundhedstjek: hvad tæller som bestået?

Et muligt startpunkt er et sundhedsvindue på 60 sekunder, højst ét sekunds forbindelsestid, højst tre sekunder pr. forespørgsel, to sekunder mellem kontrolforsøg og tre succeser i træk. Det er forslag til konfiguration, ikke målte resultater.

• Hent den lokale modeloversigt, og kræv HTTP 200 uden at følge omdirigeringer. Kontrollér JSON-strukturen, så en login-side eller en proxyfejl ikke tæller som succes.
• Kontrollér, at gatewaycontaineren faktisk kører det nye image, og at genstartstælleren ikke bliver ved med at stige. Ellers kan svar fra den gamle proces give et falsk positivt resultat.
• Om modeloversigten skal indeholde mindst én model, skal afgøres af det aktuelle registerkontrakt — ikke ved at fastkode et historisk antal på 18.
• Et sundhedsendpoint kan supplere kontrollen, men scriptet bør ikke automatisk sende en rigtig chatforespørgsel, der kan bruge kvote. Reel funktion i produktion kræver en særskilt godkendelse.

Tilpasning til de to VPS’er og håndtering af adgang

Kun image-kilden skal ændres i den eksterne deploymentkopi. Bevar porte, hukommelsesgrænser, logning, miljøvariabler, skrivebeskyttede konfigurationsmounts og mailkonfiguration. Den lokale udviklingsfil docker-compose.yml skal ikke overskrives. Den relevante del er gatewayens build-felt.

services:
  app:
    image: "${APP_IMAGE:?Der skal angives en fastlåst image-reference}"
    pull_policy: never

Det er kun et udsnit, ikke en komplet Compose-fil. Den eksterne deploymentmappe skal indeholde resten af tjenestedefinitionen, og gatewayens build-felt skal fjernes. Den gemte reference skal være en godkendt digest eller et lokalt rollback-tag — ikke latest, som kan ændre sig ved en manuel genstart.

Kontrollér også Compose-projektnavnet på hver VPS. Hvis navnet er forkert, kan Compose oprette et nyt netværk og ændre forbindelsen til mailtjenesten. Antag ikke, at det lokale projektnavn er det samme på begge servere.

Gennemgå de faktiske miljøværdier på serverne. Compose-interpolation og miljøet inde i containeren er ikke det samme; en variabel, der findes i en miljøfil, er ikke automatisk tilgængelig for programmet. Den nuværende konfiguration aktiverer to eksperimentelle funktioner, mens projektets faktuelle afgrænsning angiver, at de som udgangspunkt er slået fra. Opgaven ændrer ikke disse valg; værdierne på serverne skal kontrolleres frem for at blive udledt af den lokale fil. Eksperimentelle flag, projektets faktuelle afgrænsning

Fjernserverne skal kun modtage deployment- og kørselskonfiguration samt de færdigbyggede images. De behøver hverken en kildekodecheckout eller skriveadgang til kodearkivet. Hvis en opdatering kræver en inkompatibel konfigurationsændring, må den ikke rulles ud automatisk, før der findes en løsning, der kan rulles tilbage.

Til et privat GitHub Container Registry (GHCR) anbefales et personligt adgangstoken af den klassiske type med læserettigheden read:packages. Kontrollér, at kontoen faktisk har adgang til pakken, og gennemfør eventuel SSO-godkendelse, hvis organisationen kræver det. Giv ikke VPS’erne CI-tokenet til at skrive pakker, og giv dem ikke adgang til at ændre eller slette pakker eller kildekode. 9

Brug et separat, tilbagekaldeligt læsetoken til hver VPS, og log ind via standard input, så tokenet ikke ender i kommandolinjeargumenter eller auditlog. Gem Docker-loginoplysninger i en mappe, som kun administratoren kan læse, og sørg for, at opdateringsscriptet og manifestværktøjet bruger den samme, kontrollerede autentificering. Tokenet skal aldrig gives videre til gatewayen eller mailcontaineren. Ved en autentificeringsfejl stopper opdateringen; den nuværende tjeneste skal fortsætte.

Planlagt kørsel med systemd

Systemd er den foreslåede scheduler. En mulig serviceenhed og timerenhed ser sådan ud; stier og brugerkonto er eksempler og er ikke installeret:

[Unit]
Description=Aurora – oprindelig image-opdatering og gendannelse
After=docker.service network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=root
WorkingDirectory=/opt/aurora
Environment=DOCKER_CONFIG=/etc/aurora-updater/docker
ExecStart=/opt/aurora/scripts/auto-update.sh
TimeoutStartSec=20min
UMask=0077
Nice=10
IOSchedulingClass=idle
NoNewPrivileges=yes
StandardOutput=journal
StandardError=journal

[Unit]
Description=Aurora – planlagt kontrol af image-opdateringer

[Timer]
OnBootSec=1min
OnUnitInactiveSec=5min
RandomizedDelaySec=30s
AccuracySec=1s
Unit=aurora-update.service

[Install]
WantedBy=timers.target

Installer først afhængigheder, kontrollér konfigurationen, opret et sundt rollback-anker og gennemfør en øvelse. Timeren skal først aktiveres, når det er godkendt. Kør de to servere forskudt, så de ikke henter images eller møder en fejl på samme tid.

Timeren giver gradvis synkronisering, ikke et atomisk skift. Hvis én server ruller tilbage, bør den blive på den gamle version, indtil en ny, godkendt digest findes. Forsøg ikke at tvinge versionslighed ved gentagne gange at udrulle et image, der allerede har fejlet. Lavere prioritet for opdateringsscriptet garanterer heller ikke, at Docker-daemonens CPU-belastning under udpakning begrænses; det skal testes på serverne.

Her betyder “stille”, at scriptet ikke skriver forretningsoutput eller opdateringshistorik, når intet ændrer sig. Systemd kan stadig logge, at tjenesten er startet og afsluttet.

Logning og sikker oprydning

Log UTC-tidspunkt, serveridentitet, transaktions-ID, gamle og nye digests, trin, varighed, sundhedsresultat og rollback-resultat. Log aldrig adgangskoder, hele miljøer, mailkonti eller svarindhold.

Et muligt forslag til logrotation er ugentlig rotation, ekstra rotation ved 1 MB og komprimeret opbevaring af 26 arkiver. Det er en politik, der skal godkendes — ikke en ændring af værtens generelle logindstillinger.

Oprydning må kun slette historiske images, som opdateringsværktøjet selv har registreret som sine. Den skal bruge samme transaktionslås og må ikke foretage en global oprydning af images eller volumes. Beskyt altid den aktuelle version, den senest fungerende version og images, der indgår i en uafsluttet transaktion. Før sletning skal værktøjet desuden kontrollere, at ingen eksisterende container eller andre tags bruger imaget.

Et muligt forslag er at fjerne værktøjets eget retention-tag på historiske images, der er ældre end 14 dage, og derefter forsøge en almindelig, ikke-tvangsmæssig sletning. Hvis Docker afviser sletningen, skal imaget bevares og hændelsen logges. Et dangling-image er ikke automatisk overflødigt — det kan være manuelt bevaret til rollback. Er der for lidt diskplads før en hentning, skal opdateringen opgives frem for at slette det eneste rollback-anker.

Sådan bør løsningen godkendes

1. Kontrollér deploymenten: Undersøg begge VPS’ers platforme, værktøjsversioner, Compose-projektnavne, mounts, adgangsforhold og nuværende sunde images. Opret et gendanneligt udgangspunkt.
2. Implementér opdateringsværktøjet: Byg digestkontrol, vedvarende transaktioner, skift af kun én tjeneste, sundhedstjek, rollback og karantæne for fejlede digests. Øv det i et godkendt isoleret miljø; ikke på produktion.
3. Tilføj drift: Tilslut timer, logrotation og afgrænset oprydning. Test samtidige kørsler, timeouts, tvungen afslutning og genopretning efter genstart.
4. Udrul trinvist: Gennemfør og godkend en reel opdatering og rollback på den første server, før timeren aktiveres på den anden.

Vigtige godkendelsestests er, at en uændret digest ikke udløser laghentning, genskabelse eller opdateringslog; at mailcontainerens ID, starttid og eksisterende mails er uændrede; og at et dårligt image, et ikke-200-svar, en sundhedstimeout eller en genskabelsesfejl fører til rollback. Test også rollback uden adgang til GHCR, afbryd værktøjet på hvert kritisk transaktionstrin, og kontrollér, at næste kørsel genoptager sikkert uden at prøve en karantænesat digest igen. Endelig skal tests bekræfte, at der ikke bygges images, monteres Docker-sockets eller lækkes tokens, at kun én opdatering kan køre ad gangen, og at oprydning ikke fjerner beskyttede images.

Konklusion: En værtbaseret timer med digest-fastlåsning, vedvarende transaktionsstatus og lokal rollback er en fornuftig retning, hvis en kort afbrydelse af gatewayen accepteres. Behandl kontrol af nye versioner som et performance-mål, ikke et løfte om svar under ét sekund. Uden kvitteringer fra de to VPS’er er kompatibilitet, hastighed og rollback endnu ikke dokumenteret. Indtil videre er der kun leveret et forslag — ingen filer er ændret, ingen tests er kørt, og ingen eksisterende plan er blevet overskrevet.

Kort fortalt

Automatiske Docker-opdateringer kan bygges uden en særskilt opdateringscontainer. Den foreslåede model kombinerer en timer på værten, fastlåsning af images med digest, vedvarende status for hver opdatering og rollback til et lokalt gemt image.

Det er dog vigtigt at skelne mellem en plan og en afprøvet løsning. Forslaget er endnu ikke installeret eller testet på de to VPS’er. Og med én gatewayinstans kan man ikke love nul nedetid eller, at alle igangværende forespørgsler overlever et skift.

Hvad kildekoden fortæller

• Udgivelsesarbejdsgangen tager versionsnumre på formen v plus hoved- og underversion, eksempelvis v3.12. Den udgiver taggene latest, 3.12, v3.12 og en kort commit-SHA, men opretter ikke automatisk et versionsalias som v3.x. Arbejdsgangen er sat op til fire arkitekturer; det beviser ikke i sig selv, at en bestemt udgivelse er bygget til dem alle. Udgivelsesarbejdsgang
• Gatewayen bygges i den nuværende Compose-konfiguration, lytter på port 8080 på værten og bruger en skrivebeskyttet konfigurationsmappe. Mailen ligger i hukommelsen, så det er vigtigt ikke at genstarte mailcontaineren under en gatewayopdatering. Deploy-konfiguration
• Det udgivne image starter projektets rodindgang. Opstarten afhænger af lokal konfiguration til modelleregistret, men den mappe er ikke kopieret ind i imaget. En ekstern installation skal derfor stadig have konfigurationsfilen; et image alene er ikke nok. Dockerfile, opstartsindgang
• Den aktuelle modeloversigt læser et øjebliksbillede af registret og sender ikke en rigtig chatforespørgsel. Sundhedsendpointet melder statisk, at tjenesten lever. Ingen af delene beviser, at en upstream-konto er varmet op, eller at en chat virker. Modeloversigt, sundhedsrute
• Ved et stop-signal annullerer programmet sin servicekontekst og giver HTTP-serveren fem sekunder til at lukke. En længere frist for at stoppe containeren er derfor ikke i sig selv garanti for, at lange streamingforespørgsler afsluttes. Nedlukningslogik

Forslaget ændrer ikke mailen, synkroniserer ikke kontotilstand, opgraderer ikke afhængigheder og indfører ikke fjernkildekode. Det lover heller ikke et præcist samtidigt skift på begge servere. En egentlig tabsfri overgang ville kræve særskilt design med to instanser, skift af indgangspunkt og dræning af forbindelser.

Sådan skal opdateringen fungere

Den planlagte indgang er scripts/auto-update.sh, men scriptet er endnu ikke oprettet. Værten skal som minimum have Bash, Docker Engine, Compose-plugin, curl, jq, flock og Skopeo til at læse image-manifester uden først at hente image-lagene. De konkrete versioner og Linux-distributioner skal kontrolleres under implementeringen.

Scriptet skal køre på værten under en beskyttet konto og tale direkte med den lokale Docker-installation. Docker-socketen og registeradgangskoder skal ikke monteres i en container. Kontoen har stadig Docker-administratorrettigheder; fraværet af et socket-mount fjerner ikke den risiko.

Brug digest, ikke et flytbart tag

Et tag som latest kan pege på forskellige images over tid. Derfor bruges det kun til at finde ud af, om der er kommet en ny udgave. Selve deploymenten skal altid referere til image-adressen med en fast digest. Compose understøtter image-referencer med digest. 1

Hold styr på tre forskellige identifikatorer hver for sig: digest for det flerarkitekturelle indeks, digest for platformens manifest og Docker-image-ID’et lokalt. De er ikke direkte sammenlignelige.

Før et skift skal scriptet gemme det kørende containers image-ID under et særligt lokalt tag og kontrollere, at den gamle tjeneste er sund. Så afhænger rollback ikke af, at netværket stadig virker, eller at det gamle image kan hentes igen.

Opdateringsstatus skal gemmes som data, der parses strengt — aldrig som tekst, der eksekveres. Skriv først til en midlertidig fil i samme mappe, byt derefter filen atomisk, og sørg for, at både fil og mappe bliver synkroniseret til disk, når status er kritisk. Et atomisk filskift alene er ikke garanti for, at data overlever strømsvigt.

Opdatering trin for trin

1. Tag en ikke-blokerende fillås. Hvis en anden opdatering allerede kører, afsluttes forsøget uden støj. Opdatering, rollback, initialisering og oprydning skal bruge samme lås.
2. Afslut først en eventuel ufuldstændig transaktion. Kontrollér derefter Compose-projektnavn, at der kun er én gatewaycontainer, konfigurationsfingeraftryk og mailcontainerens identitet. Ved uventede manuelle ændringer skal scriptet stoppe frem for at overtage.
3. Hent kun manifestet og beregn en digest af samme type som den gemte. Netværks-, adgangs- eller parsefejl må ikke behandles som et nyt image, og den nuværende tjeneste skal blive stående.
4. Hvis digesten ikke har ændret sig, skal scriptet hverken hente image-lag, genskabe containere eller skrive en opdateringshændelse. En digest, der allerede er sat i karantæne efter en fejl, skal også springes over, indtil der kommer en ny digest, eller en administrator fjerner karantænen.
5. Hent det fastlåste image, og kontrollér, at det passer til værtens platform, og at der er diskplads. Den gamle gateway skal fortsætte imens. En mislykket download må ikke påvirke den kørende container.
6. Gem rollback-imaget og kompatibel konfiguration, og skriv status som en klargjort transaktion, før gatewayen genskabes.
7. Kontrollér, at den nye container kører det forventede image og består sundhedstjekket. Først da må den nye version markeres som godkendt.
8. Hvis genskabelsen fejler, eller sundhedsvinduet udløber, genskabes gatewayen med det lokale gamle image og den oprindelige konfiguration. Kør de samme sundhedstjek igen.
9. Hvis rollback lykkes, genskabes den gemte deploymentreference, den fejlslagne digest sættes i karantæne, og hændelsen logges. Hvis rollback også fejler, skal scriptet bevare gendannelsesmaterialet, melde fejl og advare — ikke genstarte i en endeløs løkke.

Skitse til centrale kommandoer:

# Værdierne skal komme fra en valideret konfiguration, som almindelige brugere ikke kan ændre.
exec 9>"$LOCK_FILE"
flock -n 9 || exit 0

# Læs kun manifestet. Verificér først Skopeos autentificering og håndtering af rå manifester.
timeout --kill-after=2s 15s \
  skopeo inspect --authfile "$DOCKER_CONFIG/config.json" \
  --raw "docker://$TRACK_IMAGE" \
  </dev/null >"$MANIFEST_TMP"
# Kontrollér afslutningsstatus før digesten beregnes.
# Brug aldrig delvist output fra et mislykket kald.

# NEW_REF skal være en valideret adresse af formen ghcr.io/repo@sha256:...
timeout --kill-after=5s 600s \
  docker pull "$NEW_REF" </dev/null

# Transaktionen skal være gemt, og det lokale rollback-image kontrolleret på forhånd.
APP_IMAGE="$NEW_REF" timeout --kill-after=5s 60s \
  docker compose --project-name "$PROJECT" \
  --project-directory "$DEPLOY_DIR" -f "$COMPOSE_FILE" \
  up -d --no-deps --no-build --pull never app </dev/null

# Ved fejl: OLD_LOCAL_REF er et gemt og kontrolleret lokalt tag for det gamle image.
APP_IMAGE="$OLD_LOCAL_REF" timeout --kill-after=5s 60s \
  docker compose --project-name "$PROJECT" \
  --project-directory "$DEPLOY_DIR" -f "$COMPOSE_FILE" \
  up -d --no-deps --no-build --pull never app </dev/null

Kommandoen retter sig kun mod gatewaytjenesten. --no-build, --no-deps og --pull never begrænser henholdsvis bygning, opstart af afhængige tjenester og ekstra image-hentning under genskabelsen. 2 Der skal ikke køres en genstart af hele Compose-projektet, slettes forældreløse tjenester eller stoppes tjenester uden for gatewayen.

En timeout betyder ikke nødvendigvis, at Docker er færdig med en baggrundsoperation. Efter timeout skal scriptet først undersøge den faktiske containertilstand og koordinere en eventuel gendannelse. Det må ikke starte et konkurrerende skift med det samme. Tvungen afslutning eller strømsvigt kan heller ikke håndteres alene med en exit-trap; næste opstart skal prioritere den gemte transaktion.

Sundhedstjek: hvad tæller som bestået?

Et muligt startpunkt er et sundhedsvindue på 60 sekunder, højst ét sekunds forbindelsestid, højst tre sekunder pr. forespørgsel, to sekunder mellem kontrolforsøg og tre succeser i træk. Det er forslag til konfiguration, ikke målte resultater.

• Hent den lokale modeloversigt, og kræv HTTP 200 uden at følge omdirigeringer. Kontrollér JSON-strukturen, så en login-side eller en proxyfejl ikke tæller som succes.
• Kontrollér, at gatewaycontaineren faktisk kører det nye image, og at genstartstælleren ikke bliver ved med at stige. Ellers kan svar fra den gamle proces give et falsk positivt resultat.
• Om modeloversigten skal indeholde mindst én model, skal afgøres af det aktuelle registerkontrakt — ikke ved at fastkode et historisk antal på 18.
• Et sundhedsendpoint kan supplere kontrollen, men scriptet bør ikke automatisk sende en rigtig chatforespørgsel, der kan bruge kvote. Reel funktion i produktion kræver en særskilt godkendelse.

Tilpasning til de to VPS’er og håndtering af adgang

Kun image-kilden skal ændres i den eksterne deploymentkopi. Bevar porte, hukommelsesgrænser, logning, miljøvariabler, skrivebeskyttede konfigurationsmounts og mailkonfiguration. Den lokale udviklingsfil docker-compose.yml skal ikke overskrives. Den relevante del er gatewayens build-felt.

services:
  app:
    image: "${APP_IMAGE:?Der skal angives en fastlåst image-reference}"
    pull_policy: never

Det er kun et udsnit, ikke en komplet Compose-fil. Den eksterne deploymentmappe skal indeholde resten af tjenestedefinitionen, og gatewayens build-felt skal fjernes. Den gemte reference skal være en godkendt digest eller et lokalt rollback-tag — ikke latest, som kan ændre sig ved en manuel genstart.

Kontrollér også Compose-projektnavnet på hver VPS. Hvis navnet er forkert, kan Compose oprette et nyt netværk og ændre forbindelsen til mailtjenesten. Antag ikke, at det lokale projektnavn er det samme på begge servere.

Gennemgå de faktiske miljøværdier på serverne. Compose-interpolation og miljøet inde i containeren er ikke det samme; en variabel, der findes i en miljøfil, er ikke automatisk tilgængelig for programmet. Den nuværende konfiguration aktiverer to eksperimentelle funktioner, mens projektets faktuelle afgrænsning angiver, at de som udgangspunkt er slået fra. Opgaven ændrer ikke disse valg; værdierne på serverne skal kontrolleres frem for at blive udledt af den lokale fil. Eksperimentelle flag, projektets faktuelle afgrænsning

Fjernserverne skal kun modtage deployment- og kørselskonfiguration samt de færdigbyggede images. De behøver hverken en kildekodecheckout eller skriveadgang til kodearkivet. Hvis en opdatering kræver en inkompatibel konfigurationsændring, må den ikke rulles ud automatisk, før der findes en løsning, der kan rulles tilbage.

Til et privat GitHub Container Registry (GHCR) anbefales et personligt adgangstoken af den klassiske type med læserettigheden read:packages. Kontrollér, at kontoen faktisk har adgang til pakken, og gennemfør eventuel SSO-godkendelse, hvis organisationen kræver det. Giv ikke VPS’erne CI-tokenet til at skrive pakker, og giv dem ikke adgang til at ændre eller slette pakker eller kildekode. 9

Brug et separat, tilbagekaldeligt læsetoken til hver VPS, og log ind via standard input, så tokenet ikke ender i kommandolinjeargumenter eller auditlog. Gem Docker-loginoplysninger i en mappe, som kun administratoren kan læse, og sørg for, at opdateringsscriptet og manifestværktøjet bruger den samme, kontrollerede autentificering. Tokenet skal aldrig gives videre til gatewayen eller mailcontaineren. Ved en autentificeringsfejl stopper opdateringen; den nuværende tjeneste skal fortsætte.

Planlagt kørsel med systemd

Systemd er den foreslåede scheduler. En mulig serviceenhed og timerenhed ser sådan ud; stier og brugerkonto er eksempler og er ikke installeret:

[Unit]
Description=Aurora – oprindelig image-opdatering og gendannelse
After=docker.service network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=root
WorkingDirectory=/opt/aurora
Environment=DOCKER_CONFIG=/etc/aurora-updater/docker
ExecStart=/opt/aurora/scripts/auto-update.sh
TimeoutStartSec=20min
UMask=0077
Nice=10
IOSchedulingClass=idle
NoNewPrivileges=yes
StandardOutput=journal
StandardError=journal

[Unit]
Description=Aurora – planlagt kontrol af image-opdateringer

[Timer]
OnBootSec=1min
OnUnitInactiveSec=5min
RandomizedDelaySec=30s
AccuracySec=1s
Unit=aurora-update.service

[Install]
WantedBy=timers.target

Installer først afhængigheder, kontrollér konfigurationen, opret et sundt rollback-anker og gennemfør en øvelse. Timeren skal først aktiveres, når det er godkendt. Kør de to servere forskudt, så de ikke henter images eller møder en fejl på samme tid.

Timeren giver gradvis synkronisering, ikke et atomisk skift. Hvis én server ruller tilbage, bør den blive på den gamle version, indtil en ny, godkendt digest findes. Forsøg ikke at tvinge versionslighed ved gentagne gange at udrulle et image, der allerede har fejlet. Lavere prioritet for opdateringsscriptet garanterer heller ikke, at Docker-daemonens CPU-belastning under udpakning begrænses; det skal testes på serverne.

Her betyder “stille”, at scriptet ikke skriver forretningsoutput eller opdateringshistorik, når intet ændrer sig. Systemd kan stadig logge, at tjenesten er startet og afsluttet.

Logning og sikker oprydning

Log UTC-tidspunkt, serveridentitet, transaktions-ID, gamle og nye digests, trin, varighed, sundhedsresultat og rollback-resultat. Log aldrig adgangskoder, hele miljøer, mailkonti eller svarindhold.

Et muligt forslag til logrotation er ugentlig rotation, ekstra rotation ved 1 MB og komprimeret opbevaring af 26 arkiver. Det er en politik, der skal godkendes — ikke en ændring af værtens generelle logindstillinger.

Oprydning må kun slette historiske images, som opdateringsværktøjet selv har registreret som sine. Den skal bruge samme transaktionslås og må ikke foretage en global oprydning af images eller volumes. Beskyt altid den aktuelle version, den senest fungerende version og images, der indgår i en uafsluttet transaktion. Før sletning skal værktøjet desuden kontrollere, at ingen eksisterende container eller andre tags bruger imaget.

Et muligt forslag er at fjerne værktøjets eget retention-tag på historiske images, der er ældre end 14 dage, og derefter forsøge en almindelig, ikke-tvangsmæssig sletning. Hvis Docker afviser sletningen, skal imaget bevares og hændelsen logges. Et dangling-image er ikke automatisk overflødigt — det kan være manuelt bevaret til rollback. Er der for lidt diskplads før en hentning, skal opdateringen opgives frem for at slette det eneste rollback-anker.

Sådan bør løsningen godkendes

1. Kontrollér deploymenten: Undersøg begge VPS’ers platforme, værktøjsversioner, Compose-projektnavne, mounts, adgangsforhold og nuværende sunde images. Opret et gendanneligt udgangspunkt.
2. Implementér opdateringsværktøjet: Byg digestkontrol, vedvarende transaktioner, skift af kun én tjeneste, sundhedstjek, rollback og karantæne for fejlede digests. Øv det i et godkendt isoleret miljø; ikke på produktion.
3. Tilføj drift: Tilslut timer, logrotation og afgrænset oprydning. Test samtidige kørsler, timeouts, tvungen afslutning og genopretning efter genstart.
4. Udrul trinvist: Gennemfør og godkend en reel opdatering og rollback på den første server, før timeren aktiveres på den anden.

Vigtige godkendelsestests er, at en uændret digest ikke udløser laghentning, genskabelse eller opdateringslog; at mailcontainerens ID, starttid og eksisterende mails er uændrede; og at et dårligt image, et ikke-200-svar, en sundhedstimeout eller en genskabelsesfejl fører til rollback. Test også rollback uden adgang til GHCR, afbryd værktøjet på hvert kritisk transaktionstrin, og kontrollér, at næste kørsel genoptager sikkert uden at prøve en karantænesat digest igen. Endelig skal tests bekræfte, at der ikke bygges images, monteres Docker-sockets eller lækkes tokens, at kun én opdatering kan køre ad gangen, og at oprydning ikke fjerner beskyttede images.

Konklusion: En værtbaseret timer med digest-fastlåsning, vedvarende transaktionsstatus og lokal rollback er en fornuftig retning, hvis en kort afbrydelse af gatewayen accepteres. Behandl kontrol af nye versioner som et performance-mål, ikke et løfte om svar under ét sekund. Uden kvitteringer fra de to VPS’er er kompatibilitet, hastighed og rollback endnu ikke dokumenteret. Indtil videre er der kun leveret et forslag — ingen filer er ændret, ingen tests er kørt, og ingen eksisterende plan er blevet overskrevet.