Containerregister

Containerregistret giver din tenant et privat OCI-register til dine container-images, hostet i EU. Images lagres udelukkende i EU/EØS og er aldrig offentlige. Enhver OCI-klient fungerer — docker, podman, en CI-runner eller en Kubernetes-klynge, der puller med en image pull secret.

Registrets endpoint er registry.sweden.frostmoln.cloud.

Push og pull går direkte til det endpoint med et sæt legitimationsoplysninger, du udsteder her. De passerer ikke Frostmolns API, så intet i din byggepipeline behøver overhovedet at kende til platformens API.

Aktivér dit register

Registret kræver et udtrykkeligt tilvalg. Aktiveringen opretter dit navnerum og den betalingspligtige lagring, der følger med — at have lov til at bruge tjenesten opretter ikke i sig selv et register.

Gå til Containerregister i portalen, og vælg Aktivér containerregister.

fm registry enable
fm registry status      # hvor du pusher, og om registret er aktiveret

Intet kan konfigureres ved oprettelsen: dit navnerum udledes af dit tenant-id, så der er intet, en forespørgsel kunne angive, som ville ændre det. At køre tilvalget igen via CLI'et eller Terraform på en allerede aktiveret tenant er ikke en fejl — det rapporterer den aktuelle tilstand og afslutter med 0, så det er sikkert i et provisioneringsscript. (API'et svarer selv 409 der; CLI'et og Terraform-provideren absorberer det.)

Aktiveringen kan ikke fortrydes, og lukker du din tenant, ødelægges dine images

Der findes ingen handling til at deaktivere — hverken i portalen, CLI'et eller API'et. Den eneste måde, et register fjernes på, er ved at lukke tenanten, og det ødelægger permanent hvert eneste image i det. Betragt aktiveringen som engangsoprettelse, og kontakt support, hvis et register skal fjernes.

Læs Hvad der sker, når du lukker din tenant nedenfor, før du lukker en — der er et vindue på 30 dage at eksportere i, og det er den eneste chance.

Dit navnerum og dine image-referencer

Dit navnerum er t- efterfulgt af dit tenant-id uden bindestreger — for eksempel t-3f2a9c1e4b7d4a2f8e1c5d6b7a8f9e0d. Enhver image-reference har formen:

registry.sweden.frostmoln.cloud/<dit-navnerum>/<image>:<tag>

Navnerummet udledes af dit uforanderlige tenant-id, ikke af tenantens navn. At omdøbe din tenant ændrer det ikke, så image-referencer, du allerede har låst fast i en Dockerfile, et Helm-chart eller et deployment-manifest, bliver ved med at være gyldige.

Portalen viser dit præcise navnerum under Hvor du pusher, og CLI'et skriver det ud:

fm registry status

Legitimationsoplysninger

Et sæt legitimationsoplysninger er det brugernavn og den adgangskode, du logger ind med via docker login. Udsted et sæt i portalen under Legitimationsoplysninger → Opret legitimationsoplysninger, eller fra CLI'et:

fm registry credential create --name ci-pipeline          # kun pull (standard)
fm registry credential create --name ci-pipeline --capability push
fm registry credential list
fm registry credential get <id>
fm registry credential delete <id>                        # tilbagekald (spørger først)
fm registry credential delete <id> --force                # samme, uden spørgsmål

• Navn er din egen etiket — det indgår ikke i brugernavnet. Navngiv hvert sæt efter den ene forbruger, der har det. Uden mulighed for at afgrænse et sæt til ét enkelt repository er etiketten det eneste, der senere fortæller dig, hvilket sæt der er lækket, og hvad der holder op med at virke, når du tilbagekalder det.
• Adgang er pull (standard) eller push. Push indebærer pull. Udsted pull, medmindre den pågældende forbruger faktisk udgiver images — et sæt push-legitimationsoplysninger kan overskrive enhver eksisterende tag i dit navnerum, også en, som dine produktionsmanifester allerede refererer til.
• Brugernavnet har præfikset robot$, f.eks. robot$t-3f2a9c1e4b7d4a2f8e1c5d6b7a8f9e0d-a1b2c3d4.
• Ét sæt legitimationsoplysninger rækker til hvert eneste navnerum, din tenant ejer, fordi docker login gælder pr. vært. Der er ingen måde at afgrænse et sæt til ét enkelt repository, så skadesomfanget for ethvert sæt er hele dit navnerum.
• Legitimationsoplysninger udløber ikke og kan ikke roteres på stedet, så tilbagekald dem og udsted nye bevidst — når nogen stopper, når et CI-system udskiftes, eller efter en plan, du selv lægger.
• Du kan have op til 20 sæt ad gangen; udstedelse ud over det afvises, og løsningen er at tilbagekalde et sæt, du ikke længere bruger.
• Tilbagekaldelse får virkning med det samme for alt, der logger ind igen: sættet kan ikke længere autentificere, uden nogen henstandsperiode, så en pipeline eller en klynge, der bruger det, begynder straks at fejle. En session, der allerede har en registertoken, kan nå at bruge den tokens korte levetid færdig, så en tilbagekaldelse er begyndelsen på inddæmningen, ikke det hele.

Adgangskoden vises kun én gang

Adgangskoden vises kun ved oprettelsen. Hverken Frostmoln eller registret opbevarer en kopi, der kan hentes frem, og der findes intet endpoint til rotation. Gem den med det samme i Hemmeligheder eller i din egen hemmelighedshåndtering.

Hold den væk fra versionsstyring, CI-joblogs, ARG/ENV i Dockerfiles og --build-arg-værdier (som alle lever videre i image-lag og image-historik), almindelige Kubernetes-manifester, supportsager og chat samt din udklipshistorik.

Mister du den, er den eneste vej tilbage at tilbagekalde sættet og udstede et nyt. Slipper den ud i stedet for at gå tabt, se Hvis legitimationsoplysninger lækker.

Log ind

I en terminal lader du docker spørge efter adgangskoden — det holder den ude af din shell-historik og ude af proceslisten:

docker login registry.sweden.frostmoln.cloud -u 'robot$t-...-a1b2c3d4'

Sæt brugernavnet i anførselstegn i din shell

Brugernavnet indeholder et $. I bash eller zsh bliver et robot$t-... uden anførselstegn ekspanderet væk, og login afvises, hvilket får et fuldt fungerende sæt legitimationsoplysninger til at se ødelagt ud. Brug altid enkelte anførselstegn.

I CI, hvor der ikke kan spørges om noget, sender du adgangskoden på stdin — aldrig med -p/--password, som lægger den blandt procesargumenterne på en delt runner:

printf '%s' "$REGISTRY_PASSWORD" | docker login registry.sweden.frostmoln.cloud \
  -u 'robot$t-...-a1b2c3d4' --password-stdin

Brug printf '%s' frem for echo — echo fortolker backslash-sekvenser i zsh og æder et indledende -n/-e i bash, og begge dele forvansker i stilhed en adgangskode, du ikke kan læse tilbage.

Hent $REGISTRY_PASSWORD fra din runners mekanisme til maskerede hemmeligheder, og sørg for, at trinnet ikke kører under set -x: kommandosporing ekspanderer variablen og skriver adgangskoden ud i byggeloggen, hvor maskeringen måske ikke når hen.

docker login gemmer legitimationsoplysningerne på disken

Den skriver til ~/.docker/config.json, base64-kodet, ikke krypteret, medmindre du har konfigureret en credential helper (docker-credential-osxkeychain, pass, secretservice). Den fil er let at få kopieret med ind i en byggekontekst, en backup eller et synkroniseret dotfile-repo. Konfigurer en helper på en arbejdsstation, og kør docker logout registry.sweden.frostmoln.cloud, når du er færdig. podman skriver i stedet til $XDG_RUNTIME_DIR/containers/auth.json — podman logout rydder den.

På en selvhostet eller på anden vis langlivet CI-runner er credential helpers sjældent tilgængelige, og filen ville overleve dit job, hvor det næste job kan læse den. Giv hvert job sin egen konfigurationsmappe, og fjern den til sidst:

export DOCKER_CONFIG="$(mktemp -d)"
# ... log ind, byg, push ...
docker logout registry.sweden.frostmoln.cloud; rm -rf "$DOCKER_CONFIG"

Sådan får du en ny hemmelighed ind i en hemmelighedshåndtering

Standardudskriften i tabelform skriver allerede hemmeligheden ud i din terminal, og med -o json sender CLI'et den umaskeret — og det er netop det, der lader dig sende den videre, uden at den nogensinde optræder på en kommandolinje:

fm registry credential create --name ci -o json | jq -j .secret

Brug jq -j, ikke jq -r: -r tilføjer et afsluttende linjeskift, og en håndtering, der beholder det, giver dig en adgangskode, der fejler ved hvert login — uden en anden kopi at sammenligne med.

Ingen fm secrets-kommando læser en værdi fra stdin (fm secrets create tager kun --value, hvilket ville lægge hemmeligheden tilbage på en kommandolinje), så send den til portalens formular Hemmeligheder → Opret, eller til en håndtering, hvis CLI læser stdin:

set -o pipefail
fm registry credential create --name ci -o json | jq -j .secret \
  | vault kv put secret/frostmoln/registry password=-

set -o pipefail betyder noget her: uden det afsluttes kæden med 0, selv når noget tidligere fejler, og du lukker terminalen i troen på, at en engangshemmelighed blev gemt. Læs værdien tilbage, og sammenlign den, før du lukker den terminal — det er det eneste tidspunkt, hvor du stadig kan. Bemærk, at vault kv put erstatter alle nøgler på stien, så brug vault kv patch (eller en separat sti), hvis du også gemmer brugernavnet der.

Uanset hvilken modtager du bruger: omdiriger den ikke til en fil, kør den ikke under set -x, og kør den ikke i et CI-job, der ekkoer kommandoer. Hemmeligheden er umaskeret, og den ligger desuden i din terminals rullebuffer og sessionslog — ryd dem, når du er færdig.

Hvis legitimationsoplysninger lækker

1. Tilbagekald dem — fm registry credential delete <id>, eller Tilbagekald i portalen. Ingen yderligere login med dem lykkes.
2. Udsted et erstatningssæt, og opdater hver forbruger, der havde det gamle. Hvis en klynge puller med det via External Secrets Operator, så fremtving en opdatering, eller slet den synkroniserede Secret — ellers bliver den ved med at bruge det døde sæt indtil sit næste opdateringsinterval.
3. Find ud af, hvad der ellers lå samme sted. Lækkede det via ~/.docker/config.json, Terraform-state, en byggelog eller et synkroniseret dotfile-repo, så lækkede alle andre legitimationsoplysninger i den artefakt med det.
4. Vurdér skaden ud fra adgangen.
   • Et sæt push-legitimationsoplysninger kan have overskrevet enhver tag i dit navnerum. Sammenlign de digests, dine manifester låser fast, med docker manifest inspect <ref>; en uoverensstemmelse er en overskrivning. Du kan selv slette de artefakter, det gav — se Frigør plads — men bemærk, at det at slette en overskrevet tag fjerner det NUVÆRENDE indhold, så push i stedet den digest, du stoler på, frem for at slette dig tilbage til den.
   • Et sæt pull-legitimationsoplysninger betyder, at alt i dit navnerum kunne læses, og en tilbagekaldelse gør ikke en læsning ugjort. Gå ud fra, at alt, der nogensinde er pushet dertil, er taget, inklusive hemmeligheder, der er bagt ind i image-lag.

Frostmoln kan ikke fortælle dig, om et lækket sæt rent faktisk blev brugt — der findes ingen kundesynlig adgangslog for registret — så de digests, du noterede på forhånd, er dit eneste bevis. Det er den praktiske grund til at låse fast på digest.

Et suspenderet register kan ikke inddæmmes

Mens dit register er suspenderet, afvises både tilbagekaldelse og udstedelse. Et lækket sæt forbliver aktivt, og du kan ikke erstatte det. Kontakt support omgående i stedet for at gå igennem trinnene ovenfor.

Fordi intet udløber, og intet kan roteres på stedet, er dette også den rutine, du kører efter en fast plan og ikke kun efter en hændelse.

Push og pull et image

# 1. Log ind (sæt brugernavnet i enkelte anførselstegn — det indeholder et $)
docker login registry.sweden.frostmoln.cloud -u 'robot$t-...-a1b2c3d4'

# 2. Tag dit image til dit navnerum
docker tag my-app:latest \
  registry.sweden.frostmoln.cloud/t-3f2a9c1e4b7d4a2f8e1c5d6b7a8f9e0d/my-app:1.0.0

# 3. Push
docker push \
  registry.sweden.frostmoln.cloud/t-3f2a9c1e4b7d4a2f8e1c5d6b7a8f9e0d/my-app:1.0.0

# 4. Pull det tilbage overalt, hvor der findes et sæt legitimationsoplysninger
docker pull \
  registry.sweden.frostmoln.cloud/t-3f2a9c1e4b7d4a2f8e1c5d6b7a8f9e0d/my-app:1.0.0

podman tager de samme kommandoer. Et sæt pull-legitimationsoplysninger er nok til trin 4; trin 3 kræver push.

Pull fra en administreret Kubernetes-klynge

Kubernetes autentificerer mod et privat register med en image pull secret — en Secret af typen kubernetes.io/dockerconfigjson. Udsted et sæt legitimationsoplysninger med --capability pull, og giv klyngen sit eget frem for at dele dit CI-sæt, så en tilbagekaldelse af det ene ikke ødelægger det andet.

Den arbejdslast, der puller, skal desuden have udgående internetadgang for at nå registrets endpoint, hvilket betyder, at dens VPC skal have en gateway. Et VPC oprettes uden en, medmindre du beder om den, og uden en gateway er der hverken internetadgang eller DNS-opslag — så pullet fejler, før det er begyndt.

Anbefalet: synkronisér den fra Hemmeligheder

På Frostmoln Administreret Kubernetes vælger du klyngetilføjelsen External Secrets Operator, når du opretter klyngen, eller føjer den først til klyngen, mens den kører (se guiden); på en klynge, du kører andre steder, installerer du selv ESO. Gem derefter sættets brugernavn og adgangskode i Hemmeligheder under navnene registry-username og registry-password, så de matcher værdierne i remoteRef.key nedenfor — brug portalens formular Hemmeligheder → Opret, eller opskriften med rør ovenfor, frem for fm secrets create --value, som ville lægge adgangskoden på en kommandolinje.

Lad derefter External Secrets Operator bygge pull-hemmeligheden i klyngen, så adgangskoden aldrig optræder i et manifest:

En SecretStore er bundet til sit namespace

SecretStore slås op i ExternalSecret-objektets eget namespace, så både frostmoln-storet og den mærkede API-nøglehemmelighed bag det skal findes i my-app — gentag trin 1 og 2 i guiden External Secrets Operator der. Vær bevidst om det: det placerer en API-nøgle, der kan læse alle hemmeligheder i din tenant, i det namespace, til gengæld for at holde én registeradgangskode ude af det. Afgræns den nøgle til læseadgang til hemmeligheder, og hold namespacets RBAC stram.

apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: frostmoln-registry
  namespace: my-app
spec:
  refreshInterval: 1h
  secretStoreRef: { name: frostmoln, kind: SecretStore }
  target:
    name: frostmoln-registry
    template:
      # Uden denne type + nøgle producerer ESO en Opaque Secret, og kubelet
      # bruger den ikke som pull secret.
      type: kubernetes.io/dockerconfigjson
      data:
        .dockerconfigjson: |
          {"auths":{"registry.sweden.frostmoln.cloud":{"username":{{ .username | toJson }},"password":{{ .password | toJson }}}}}
  data:
    - secretKey: username
      remoteRef: { key: registry-username }
    - secretKey: password
      remoteRef: { key: registry-password }

toJson sætter værdierne i anførselstegn og escaper dem, så en adgangskode, der indeholder " eller \, stadig giver et gyldigt dokument. Bemærk refreshInterval: når du har erstattet et sæt legitimationsoplysninger, bliver klyngen ved med at bruge det gamle indtil næste opdatering, så sænk intervallet eller slet den synkroniserede Secret for at fremtvinge en.

Engangsvis: opret Secret-objektet direkte

Dette er vejen på Frostmoln Administreret Kubernetes.

Dette lægger adgangskoden i din shell-historik

Adgangskoden havner i ~/.bash_history / ~/.zsh_history og blandt procesargumenterne (/proc/<pid>/cmdline), så længe kaldet varer. Brug det til at komme i gang i hånden, aldrig i et script eller et CI-job — i et CI-job med kommandosporing lander det i byggeloggen. På en klynge, der kører ESO, så foretræk ESO-opskriften ovenfor.

kubectl create secret docker-registry frostmoln-registry \
  --docker-server=registry.sweden.frostmoln.cloud \
  --docker-username='robot$t-...-a1b2c3d4' \
  --docker-password='<adgangskoden, der blev vist én gang>' \
  --namespace my-app

Uanset hvad refererer du den fra pod-specifikationen:

spec:
  imagePullSecrets:
    - name: frostmoln-registry
  containers:
    - name: my-app
      image: registry.sweden.frostmoln.cloud/t-3f2a9c1e4b7d4a2f8e1c5d6b7a8f9e0d/my-app@sha256:<digest>

At låse fast på digest frem for på tag er de ekstra tegn værd her. Tags i dit navnerum kan ændres, og enhver, der har et sæt push-legitimationsoplysninger, kan flytte en, så en digest er den eneste reference, der ikke kan ændre sig under en kørende deployment.

Terraform

Både tilvalget og legitimationsoplysningerne er Terraform-ressourcer:

resource "frostmoln_container_registry" "this" {}

resource "frostmoln_container_registry_credential" "ci" {
  name       = "ci-pipeline"
  capability = "pull" # standard; brug kun "push" til en udgiver

  depends_on = [frostmoln_container_registry.this]
}

output "image_prefix" {
  value = "${frostmoln_container_registry.this.endpoint}/${frostmoln_container_registry.this.namespace}"
}

Sættets hemmelighed skrives til Terraform-state

Den returneres kun én gang, så provideren gemmer den. Uden en konfigureret backend skriver Terraform terraform.tfstate som JSON i klartekst i din arbejdsmappe — som regel inde i et git-repository, hvilket modsiger hver eneste anden regel på denne side.

Brug en krypteret fjernbackend (Frostmolns objektlagring via S3-backenden fungerer), og tilføj terraform.tfstate* til .gitignore — terraform.tfstate.backup er endnu en kopi i klartekst, som overlever flytningen til en fjernbackend.

Hemmeligheden når også terraform show, JSON-planfiler, enhver CI-artefakt eller cache, der bevarer state mellem kørsler, og output fra TF_LOG=DEBUG/TRACE, som optegner providerens HTTP-svar — inklusive det, der bærer hemmeligheden. At markere et output sensitive = true skjuler det kun fra konsoloutput — ikke fra state og ikke fra terraform output -json.

terraform destroy sletter ikke registret. Der findes intet endpoint til nedrivning — ressourcen fjernes fra state med en advarsel, mens navnerummet, dets images og dets betalingspligtige tilstand alle lever videre. At fjerne registret betyder at lukke tenanten, hvilket ødelægger imagene med den; se Hvad der sker, når du lukker din tenant. Legitimationsoplysningerne er uforanderlige: ændrer du name eller capability, erstattes de, og der udstedes en ny hemmelighed, så opdater dine forbrugere, når du gør det.

Lagring og grænsen

Dit navnerum har et hårdt lagringsloft: din tenants lagerkvote til containerregistret — 10 GB, medmindre du har fået en forhøjelse godkendt, og i så fald det godkendte beløb. Hvert navnerum til en pull-through-cache har sit eget loft på op til 10 GiB (10737418240 byte). En push, der ville overskride det, afvises med 403, og afvisningen nævner alle tre tal — den størrelse, der ikke kunne være der, hvad du allerede bruger, og dit loft:

HTTP/1.1 403 Forbidden
Content-Type: application/json; charset=utf-8

{"errors":[{"code":"DENIED","message":"adding 900.0 KiB of storage resource, which when updated to current usage of 300.0 KiB will exceed the configured upper limit of 1.0 MiB."}]}

Det er registrets eget svar, hentet mod et navnerum med et bevidst lille loft; dit eget nævner dine egne tal. Hvad docker push eller en anden klient skriver ud af det, er op til den klient. Tallene er løbende tekst inde i message, i den enhed registret nu vælger — læs dem, tolk dem ikke maskinelt. Det loft, der faktisk gælder for dit navnerum, er det, der vises i portalen under Anvendt lagring og af fm registry status; læs det der frem for at antage et tal.

Det forbrugstal er det, registret tæller mod dit loft: de deduplikerede byte, der er lagret i dit navnerum. Det er ikke summen af de image-størrelser, du ser i docker image ls, og de to er reelt forskellige — lag, der deles mellem tags i samme navnerum, tælles én gang. Optællingen sker pr. navnerum, og loftet håndhæves pr. navnerum: det samme lag, der ligger i et andet navnerum, tælles igen. Læs det som "lagring i brug mod dit loft", og brug det ikke til at afstemme en faktura. Det afspejler allerede din push, når pushet er færdigt — men en push, der ikke tilføjer nye lag, rykker det næsten ikke.

Frigør plads

Slet et image, og pladsen kommer tilbage. I portalen: åbn et repository under Images, og tryk Fjern på rækken. Fra CLI'et:

fm registry image list web/api                       # find det, der skal fjernes
fm registry image list web/api -o json               # digests i fuld længde
fm registry image delete web/api sha256:1b0c8dd1...  # spørger først
fm registry image delete web/api sha256:1b0c8dd1... --force

Den tager en digest, ikke en tag, og en tag afvises frem for at blive gættet. En tag flytter sig. Hvis din pipeline pushede v1 igen, mellem at du læste listen og trykkede enter, ville en sletning af "den, der er tagget v1", ødelægge det image, du ville beholde, og intet ville fortælle dig det. Kopiér digesten fra listen.

Imaget forsvinder, ikke bare tagget. Hver tag, der peger på det, følger med, og det gør manifestet også — bagefter kan det hverken pulles ved navn eller ved digest. Der findes ingen handling til at fjerne en tag: at fjerne en etiket og lade indholdet kunne pulles via digest frigør ingenting og ligner blot en sletning.

Dit lagringstal falder med det samme — med mindre end den viste størrelse

Tallet under Anvendt lagring, og i fm registry status, afspejler allerede sletningen, når den returnerer. Du venter ikke på et oprydningsvindue.

Det, det ikke falder med, er den størrelse, image-listen viste for det image. Den kolonne er imagets egen størrelse og tæller hvert lag fuldt ud; inden for et navnerum tæller dit loft hvert lagret lag én gang. At slette et image, hvis baselag dine andre tags stadig bruger, frigør kun de lag, intet andet refererer til — ofte en lille brøkdel af det tal, du klikkede på.

Altså: slet, og læs derefter det nye tal. Regn det ikke ud på forhånd ud fra størrelseskolonnen, og bliv ikke ved med at slette for at jage et tal, der aldrig ville komme.

Begynd med de utaggede. En række mærket <untagged> er et manifest, som en senere push har gjort forældreløst: intet kan pulle det ved navn, og det tæller stadig mod dit loft. Det er som regel hovedparten af det, et fyldt navnerum indeholder.

# hvert utagget image i et repository, kun digests
fm registry image list web/api --all -o json | jq -r '.data[] | select(.tags == []) | .digest'

Vil du have det til at ske automatisk, så angiv en opbevaringspolitik. Den sletter hver nat utaggede images og de taggede images, der ligger ud over de nyeste, du vælger at beholde.

Et multiarkitektur-image slettes via sit indeks. Dets dele pr. platform kan ikke fjernes hver for sig og svarer med en konflikt; slet indekset, så følger de med.

Et suspenderet register kan ikke slette. Skrivninger afvises, mens pull og listerne bliver ved med at virke, så du kan altid stadig se, hvad du har.

docker rmi frigør ingenting. Den fjerner et lokalt image fra din egen maskin og sender slet ingen forespørgsel til registret, så den lagring, der tælles mod dit loft, er uændret.

Vises der slet intet lagringstal, så læs det som "ikke rapporteret", aldrig som "ubegrænset" — push kan blive afvist i den tilstand. Kontakt support, hvis du ser det.

Portalen og fm viser størrelser i SI-enheder (1 GB = 10⁹ byte), den samme enhed som din lagerkvote anmodes i. En pull-through-caches loft på 10737418240 byte (10 GiB) vises derfor som ca. 10,7 GB; begge beskriver samme grænse.

Opbevaringspolitikker

En opbevaringspolitik sletter gamle images for dig, så CI-push ikke hober sig op mod dit loft. Din tenant har én politik. Den gælder hvert repository i dit navnerum, og hvert repository vurderes for sig.

Politikken har to regler. Begge er valgfrie, men du angiver mindst én:

Regel	Hvad den gør	Interval
Behold de seneste N taggede images	Beholder de N senest pushede taggede images i hvert repository og sletter de ældre.	1-1000
Slet utaggede images efter X dage	Sletter utaggede images, hvis seneste push ligger mere end X dage tilbage.	1-365

En regel, du ikke angiver, beholder alt i sin klasse. Med kun den første regel slettes utaggede images aldrig; med kun den anden slettes taggede images aldrig.

N tæller images, ikke tags. Et image med tre tags tælles én gang. Images, der er pushet i samme øjeblik, beholdes i ingen garanteret rækkefølge, så hvis to af dem ligger lige ved grænsen N, så regn ikke med, hvilket der bliver tilbage. At pushe et image igen, eller give et eksisterende image en ny tag, tæller som et nyt push: imaget flytter til den nyeste ende for reglen om at beholde de seneste.

Et multiarkitektur-image beholdes eller slettes som en helhed. Dets dele pr. platform, og signaturer knyttet til det, følger imaget. En politik efterlader dig aldrig med et halvt image og fjerner aldrig signaturen fra et image, den beholder.

Politikken kører hver nat, mellem kl. 00:00 og 06:00 UTC. Der er ingen egen tidsplan og ingen måde at køre den på efter behov. En politik, du gemmer i dag, gælder fra næste kørsel.

Slettede images kan ikke gendannes

En opbevaringskørsel sletter imaget, alle dets tags og dets manifest, præcis som en manuel sletning. Før du gemmer en politik, så tjek, at intet, du deployer, peger på et image, politikken ville slette — for eksempel en release, du kun puller via digest.

Pull-through-caches påvirkes ikke. En opbevaringspolitik dækker kun dit eget navnerum. Hver cache har sin egen regel — et image, som ingen puller i 7 dage, fjernes — og den kan du ikke ændre; se Pull-through-cacher.

Pladsen ses i dit forbrug efter nattens kørsel. Dit lagringstal, og dermed det, du faktureres for, afspejler den frigjorte plads næste morgen. Læs tallet da i stedet for at regne med et præcist tidspunkt.

Når du gemmer en politik, erstattes hele politikken. En regel, du udelader, når du gemmer, ryddes — den beholdes ikke fra før.

At angive en politik kræver tilladelse til at slette images. Fordi en opbevaringspolitik sletter images, kræver det både registry:artifacts:delete og registry:settings:update at gemme en (se Operationer). At fjerne en politik kræver kun registry:settings:update.

Angiv en politik

I portalen: åbn Containerregister, og brug kortet for opbevaring. Fra CLI'et:

fm registry retention set --keep-last-tagged 10 --delete-untagged-after-days 14
fm registry retention get      # hvad der gælder nu
fm registry retention delete   # fjern politikken; intet mere slettes

Der spørges først, når den nye politik sletter mere. Hvis den ville slette mere end den nuværende (ingen politik før, en regel der slås til, eller et lavere tal), viser portalen og fm begge og beder dig bekræfte. I scripts bruger du fm registry retention set --force; uden en terminal afviser set, medmindre --force er angivet.

Med Terraform:

resource "frostmoln_container_registry_retention" "this" {
  keep_last_tagged           = 10
  delete_untagged_after_days = 14

  depends_on = [frostmoln_container_registry.this]
}

depends_on peger på registerressourcen fra Terraform ovenfor, så en konfiguration, der også aktiverer registret, opretter det først.

At fjerne ressourcen, eller køre terraform destroy, fjerner politikken. Det bringer ikke images tilbage, som en tidligere kørsel har slettet.

Hvis dit register er suspenderet

Et suspenderet register betjener stadig pull. At pushe nye images er blokeret, og dine push-legitimationsoplysninger vises som deaktiverede — dine pull-legitimationsoplysninger bliver ved med at virke, og det er med vilje, for det er sådan, du henter dine images ud, mens registret er suspenderet.

Mens registret er suspenderet, kan du hverken udstede eller tilbagekalde legitimationsoplysninger. Så hvis du kun har push-legitimationsoplysninger, kan du ikke oprette de pull-legitimationsoplysninger, du ville have brug for til at eksportere. Ét stående sæt pull-legitimationsoplysninger undgår det.

Kontakt support for at få et suspenderet register genoprettet.

Hvad der sker, når du lukker din tenant

At lukke en tenant er den eneste måde, dens register fjernes på, og det ødelægger permanent hvert eneste image i det. Der er ingen gendannelse bagefter og ingen backup, Frostmoln kan gendanne fra.

Forløbet ligger fast:

Hvornår	Hvad der sker
Dag 0, du lukker tenanten	Registret bliver skrivebeskyttet. Push er blokeret, og dine push-legitimationsoplysninger deaktiveres. De pull-legitimationsoplysninger, du allerede har, bliver ved med at virke.
Dag 0-30	Dit eksportvindue. Pull det, du vil beholde.
Dag 30	Hvert eneste image, hvert eneste sæt legitimationsoplysninger og selve navnerummet slettes permanent.

Pull-legitimationsoplysningerne skal findes, før du lukker. Mens en tenant lukkes, kan du hverken udstede eller tilbagekalde legitimationsoplysninger, så en tenant, der kun har push-legitimationsoplysninger, har slet ingen mulighed for at eksportere — det sæt, du ville få brug for, kan ikke længere oprettes. Hav ét stående sæt pull-legitimationsoplysninger, hvis du nogensinde kan få brug for at eksportere.

Eksport er et helt almindeligt pull. List, hvad du har, og pull derefter hver reference:

fm registry repository list
fm registry image list <repository>
docker pull registry.sweden.frostmoln.cloud/<dit-navnerum>/<repository>:<tag>

Vil du kun frigøre plads frem for at forlade platformen, se Frigør plads — at slette artefakter lukker ingenting.