Containerregister

Containerregistret ger din tenant ett privat OCI-register för dina containeravbilder, driftat inom EU. Avbilderna lagras uteslutande inom EU/EES och är aldrig publika. Alla OCI-klienter fungerar — docker, podman, en CI-körare eller ett Kubernetes-kluster som hämtar avbilder med en image pull secret.

Registrets adress är registry.sweden.frostmoln.cloud.

Push och pull går direkt till den adressen med en behörighet du skapar här. De passerar inte Frostmolns API, så ingenting i din byggpipeline behöver känna till plattformens API.

Aktivera ditt register

Registret kräver ett uttryckligt aktiveringsval. Aktiveringen skapar din namnrymd och den debiterbara lagringen som följer med — att ha rätt att använda tjänsten skapar inte ett register i sig.

I portalen går du till Containerregister och väljer Aktivera containerregister.

fm registry enable
fm registry status      # var du pushar, och om registret är aktiverat

Ingenting går att konfigurera vid skapandet: din namnrymd härleds ur ditt tenant-id, så det finns inget en förfrågan skulle kunna säga som ändrar den. Att köra aktiveringen igen via CLI:et eller Terraform på en redan aktiverad tenant är inte ett fel — den rapporterar nuvarande läge och avslutas med 0, så den är säker i ett etableringsskript. (API:et självt svarar 409 där; CLI:et och Terraform-leverantören hanterar det.)

Aktiveringen kan inte ångras, och att avsluta tenanten förstör dina avbilder

Det finns ingen åtgärd för att inaktivera, varken i portalen, CLI:et eller API:et. Det enda sättet ett register tas bort på är att avsluta tenanten, och det förstör permanent varje avbild i det. Betrakta aktiveringen som engångsskapande och kontakta supporten om ett register behöver tas bort.

Läs Vad som händer när du avslutar tenanten nedan innan du avslutar en — det finns ett 30-dagarsfönster att exportera i, och det är den enda chansen.

Din namnrymd och referenser till avbilder

Din namnrymd är t- följt av ditt tenant-id utan bindestreck — till exempel t-3f2a9c1e4b7d4a2f8e1c5d6b7a8f9e0d. Varje avbildsreferens har formen:

registry.sweden.frostmoln.cloud/<din-namnrymd>/<avbild>:<tagg>

Namnrymden härleds ur ditt oföränderliga tenant-id, inte ur tenantens namn. Att byta namn på tenanten ändrar den inte, så avbildsreferenser du redan har låst fast i en Dockerfile, ett Helm-chart eller ett deployment-manifest fortsätter att gälla.

Portalen visar din exakta namnrymd under Var du pushar, och CLI:et skriver ut den:

fm registry status

Behörigheter

En behörighet är det användarnamn och lösenord du loggar in med via docker login. Skapa en i portalen under Behörigheter → Skapa behörighet, eller från CLI:et:

fm registry credential create --name ci-pipeline          # endast 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>                        # återkallar (frågar först)
fm registry credential delete <id> --force                # samma, utan fråga

• Namn är din egen etikett — det ingår inte i användarnamnet. Namnge varje behörighet efter den enda konsument som innehar den. Utan möjlighet att begränsa till ett enskilt repositorium är etiketten det enda som senare talar om vilken behörighet som läckt och vad som slutar fungera när du återkallar den.
• Åtkomst är pull (standard) eller push. Push inkluderar pull. Skapa pull om inte konsumenten faktiskt publicerar avbilder — en push-behörighet kan skriva över vilken befintlig tagg som helst i din namnrymd, även en som dina produktionsmanifest redan refererar till.
• Användarnamnet har prefixet robot$, till exempel robot$t-3f2a9c1e4b7d4a2f8e1c5d6b7a8f9e0d-a1b2c3d4.
• En behörighet fungerar för alla namnrymder din tenant äger, eftersom docker login sker per värd. Det går inte att begränsa en behörighet till ett enskilt repositorium, så varje behörighets skadeområde är hela din namnrymd.
• Behörigheter upphör inte att gälla och kan inte roteras på plats — återkalla och skapa nya medvetet: när någon slutar, när ett CI-system byts ut, eller enligt ett eget schema.
• Du kan ha upp till 20 samtidigt; fler än så nekas, och lösningen är att återkalla en du inte längre använder.
• Att återkalla får effekt omedelbart för allt som loggar in på nytt: behörigheten kan inte längre autentisera, utan respit, så en pipeline eller ett kluster som använder den börjar genast misslyckas. En session som redan har en registertoken kan använda den tokenens korta livstid färdigt, så en återkallning är början på inneslutningen, inte hela den.

Lösenordet visas en enda gång

Lösenordet visas bara när det skapas. Varken Frostmoln eller registret behåller någon hämtbar kopia, och det finns ingen funktion för att rotera det. Spara det direkt i Hemligheter eller i din egen hemlighetshanterare.

Håll det borta från källkod, CI-loggar, ARG/ENV i Dockerfiler och --build-arg-värden (som alla lever kvar i avbildslager och avbildshistorik), vanliga Kubernetes-manifest, supportärenden och chatt samt din urklippshistorik.

Om du tappar bort det är den enda lösningen att återkalla behörigheten och skapa en ny. Om det i stället läcker ut, se Om en behörighet läcker.

Logga in

Vid en terminal låter du docker fråga efter lösenordet — det håller det borta från skalhistoriken och från processlistan:

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

Citera användarnamnet i skalet

Användarnamnet innehåller ett $. I bash eller zsh expanderas ett ociterat robot$t-... bort och inloggningen nekas, vilket får en fullt fungerande behörighet att verka trasig. Använd alltid enkla citattecken.

I CI, där ingen fråga kan ställas, skickar du lösenordet på stdin — aldrig med -p/--password, som lägger det bland processargumenten på en delad körare:

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

Använd printf '%s' i stället för echo — echo tolkar bakstrecksekvenser i zsh och äter ett inledande -n/-e i bash, vilket i båda fallen tyst förvanskar ett lösenord du inte kan läsa tillbaka.

Hämta $REGISTRY_PASSWORD från körarens maskerade hemlighetshantering, och se till att steget inte körs under set -x: kommandospårning expanderar variabeln och skriver lösenordet till byggloggen, dit maskeringen kanske inte når.

docker login sparar behörigheten på disk

Den skrivs till ~/.docker/config.json, base64-kodad, inte krypterad, om du inte konfigurerat en credential helper (docker-credential-osxkeychain, pass, secretservice). Filen är lätt att råka kopiera in i en byggkontext, en säkerhetskopia eller ett synkat dotfile-repo. Konfigurera en helper på en arbetsstation, och kör docker logout registry.sweden.frostmoln.cloud när du är klar. podman skriver i stället till $XDG_RUNTIME_DIR/containers/auth.json — podman logout rensar den.

På en självdriftad eller på annat sätt långlivad CI-körare finns sällan någon credential helper, och filen skulle överleva ditt jobb där nästa jobb kan läsa den. Ge varje jobb en egen konfigurationskatalog och ta bort den till sist:

export DOCKER_CONFIG="$(mktemp -d)"
# ... logga in, bygg, pusha ...
docker logout registry.sweden.frostmoln.cloud; rm -rf "$DOCKER_CONFIG"

Få in ett nytt lösenord i en hemlighetshanterare

Standardutskriften i tabellform skriver redan ut lösenordet i din terminal, och med -o json lämnar CLI:et det omaskerat — vilket är just det som låter dig skicka det vidare utan att det någonsin syns på en kommandorad:

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

Använd jq -j, inte jq -r: -r lägger till ett avslutande radslut, och en hanterare som behåller det ger dig ett lösenord som misslyckas vid varje inloggning — utan någon andra kopia att jämföra med.

Inget fm secrets-kommando läser ett värde från stdin (fm secrets create tar bara --value, vilket skulle lägga tillbaka lösenordet på en kommandorad), så skicka det till portalens formulär Hemligheter → Skapa, eller till en hanterare vars 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 spelar roll här: utan det avslutas kedjan med 0 även när något tidigare misslyckas, och du stänger terminalen i tron att ett engångslösenord sparats. Läs tillbaka värdet och jämför innan du stänger den terminalen — det är enda tillfället då du fortfarande kan. Observera att vault kv put ersätter alla nycklar på sökvägen, så använd vault kv patch (eller en separat sökväg) om du också lagrar användarnamnet där.

Oavsett mottagare: omdirigera det inte till en fil, kör det inte under set -x, och kör det inte i ett CI-jobb som ekar kommandon. Lösenordet är omaskerat, och det ligger dessutom i terminalens rullningsbuffert och sessionslogg — rensa dem när du är klar.

Om en behörighet läcker

1. Återkalla den — fm registry credential delete <id>, eller Återkalla i portalen. Inga fler inloggningar med den lyckas.
2. Skapa en ersättare och uppdatera varje konsument som hade den gamla. Om ett kluster hämtar med den via External Secrets Operator, framtvinga en uppdatering eller ta bort den synkade hemligheten — annars fortsätter det använda den döda behörigheten fram till nästa uppdateringsintervall.
3. Ta reda på vad mer som låg på samma ställe. Läckte den via ~/.docker/config.json, Terraforms state, en bygglogg eller ett synkat dotfile-repo, så läckte varje annan uppgift i den artefakten med den.
4. Bedöm skadan utifrån åtkomsten.
   • En push-behörighet kan ha skrivit över vilken tagg som helst i din namnrymd. Jämför de digests dina manifest låser fast mot docker manifest inspect <ref>; en avvikelse är en överskrivning. Du kan ta bort de resulterande avbilderna själv — se Frigöra utrymme — men observera att en borttagning av en överskriven tagg tar bort det NUVARANDE innehållet, så pusha om den digest du litar på i stället för att ta dig tillbaka genom att radera.
   • En pull-behörighet innebär att allt i din namnrymd gick att läsa, och en återkallning ogör inte en läsning. Utgå från att allt som någonsin pushats dit är taget, inklusive hemligheter inbakade i avbildslager.

Frostmoln kan inte tala om för dig huruvida en läckt behörighet faktiskt använts — det finns ingen kundsynlig åtkomstlogg för registret — så de digests du antecknat i förväg är din enda bevisning. Det är det praktiska skälet att låsa till digest.

Ett pausat register går inte att innesluta

Medan ditt register är pausat nekas både återkallning och nyskapande. En läckt behörighet förblir aktiv och du kan inte ersätta den. Kontakta supporten omedelbart i stället för att gå igenom stegen ovan.

Eftersom ingenting upphör att gälla och ingenting kan roteras på plats är detta också rutinen du kör enligt schema, inte bara efter en incident.

Pusha och hämta en avbild

# 1. Logga in (citera användarnamnet — det innehåller ett $)
docker login registry.sweden.frostmoln.cloud -u 'robot$t-...-a1b2c3d4'

# 2. Tagga avbilden för din namnrymd
docker tag my-app:latest \
  registry.sweden.frostmoln.cloud/t-3f2a9c1e4b7d4a2f8e1c5d6b7a8f9e0d/my-app:1.0.0

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

# 4. Hämta tillbaka den varhelst det finns en behörighet
docker pull \
  registry.sweden.frostmoln.cloud/t-3f2a9c1e4b7d4a2f8e1c5d6b7a8f9e0d/my-app:1.0.0

podman tar samma kommandon. En pull-behörighet räcker för steg 4; steg 3 kräver push.

Hämta avbilder från ett hanterat Kubernetes-kluster

Kubernetes autentiserar mot ett privat register med en image pull secret — en Secret av typen kubernetes.io/dockerconfigjson. Skapa en behörighet med --capability pull och ge klustret en egen i stället för att dela din CI-behörighet, så att en återkallning av den ena inte slår ut den andra.

Arbetsbelastningen som hämtar behöver dessutom utgående internetåtkomst för att nå registrets adress, vilket innebär att dess VPC behöver en gateway. Ett VPC skapas utan gateway om du inte ber om en, och utan gateway finns varken internetåtkomst eller DNS-uppslagning — så hämtningen misslyckas innan den börjat.

Rekommenderat: synka den från Hemligheter

På Frostmolns hanterade Kubernetes väljer du klustertillägget External Secrets Operator när du skapar klustret, eller lägger först till det i klustret medan det körs (se guiden); på ett kluster som du kör på annat håll installerar du ESO själv. Lagra därefter behörighetens användarnamn och lösenord i Hemligheter, med namnen registry-username och registry-password så att de matchar värdena i remoteRef.key nedan — använd portalens formulär Hemligheter → Skapa, eller receptet med rör ovan, i stället för fm secrets create --value, som skulle lägga lösenordet på en kommandorad.

Låt sedan External Secrets Operator bygga pull-hemligheten i klustret, så att lösenordet aldrig hamnar i ett manifest:

En SecretStore är namnrymdsbunden

SecretStore slås upp i ExternalSecret-objektets egen namnrymd, så både frostmoln-lagret och den märkta API-nyckelhemligheten bakom det måste finnas i my-app — upprepa steg 1 och 2 i guiden för External Secrets Operator där. Var medveten om vad det innebär: det placerar en API-nyckel som kan läsa alla hemligheter i din tenant i namnrymden, i utbyte mot att hålla ett enda registerlösenord utanför den. Begränsa den nyckeln till läsning av hemligheter och håll namnrymdens 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:
      # Utan denna typ + nyckel skapar ESO en Opaque Secret, och kubelet
      # använder den då inte som pull-hemlighet.
      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 citerar och escapar värdena, så ett lösenord som innehåller " eller \ ger ändå ett giltigt dokument. Observera refreshInterval: efter att du bytt ut en behörighet fortsätter klustret använda den gamla fram till nästa uppdatering, så sänk intervallet eller ta bort den synkade hemligheten för att framtvinga en.

Engångsvis: skapa hemligheten direkt

Det här är vägen på Frostmolns hanterade Kubernetes.

Detta lägger lösenordet i din skalhistorik

Lösenordet hamnar i ~/.bash_history / ~/.zsh_history och bland processargumenten (/proc/<pid>/cmdline) under anropets livstid. Använd detta för att komma igång för hand, aldrig i ett skript eller ett CI-jobb — i ett CI-jobb med kommandospårning hamnar det i byggloggen. På ett kluster som kör ESO, föredra ESO-receptet ovan.

kubectl create secret docker-registry frostmoln-registry \
  --docker-server=registry.sweden.frostmoln.cloud \
  --docker-username='robot$t-...-a1b2c3d4' \
  --docker-password='<lösenordet som visades en gång>' \
  --namespace my-app

Oavsett vilket refererar du den från pod-specifikationen:

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

Att låsa till digest i stället för till tagg är värt de extra tecknen här. Taggar i din namnrymd är föränderliga och den som har en push-behörighet kan flytta en, så en digest är den enda referens som inte kan ändras under en körande deployment.

Terraform

Både aktiveringen och behörigheten är Terraform-resurser:

resource "frostmoln_container_registry" "this" {}

resource "frostmoln_container_registry_credential" "ci" {
  name       = "ci-pipeline"
  capability = "pull" # standard; använd "push" bara för en publicerare

  depends_on = [frostmoln_container_registry.this]
}

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

Behörighetens lösenord skrivs till Terraforms state

Det returneras bara en gång, så leverantören sparar det. Utan konfigurerad backend skriver Terraform terraform.tfstate som JSON i klartext i din arbetskatalog — oftast inuti ett git-repositorium, vilket motsäger varje annan regel på den här sidan.

Använd en krypterad fjärrbackend (Frostmolns objektlagring via S3-backenden fungerar), och lägg till terraform.tfstate* i .gitignore — terraform.tfstate.backup är en andra kopia i klartext som överlever bytet till en fjärrbackend.

Lösenordet når också terraform show, JSON-planfiler, alla CI-artefakter eller cachar som behåller state mellan körningar, och utdata från TF_LOG=DEBUG/TRACE, som spelar in leverantörens HTTP-svar — inklusive det som bär lösenordet. Att markera en output sensitive = true döljer den bara från konsolutdata — inte från state och inte från terraform output -json.

terraform destroy tar inte bort registret. Det finns ingen funktion för nedmontering — resursen tas bort ur state med en varning, medan namnrymden, avbilderna och det debiterbara läget alla finns kvar. Behörigheten är oföränderlig: att ändra name eller capability ersätter den och ger ett nytt lösenord, så uppdatera dina konsumenter när du gör det.

Lagring och gränsen

Din namnrymd har en hård lagringsgräns: din tenants lagringskvot för containerregistret — 10 GB om du inte har fått en höjning godkänd, och i så fall det godkända beloppet. Varje namnrymd för en pull-through-cache har en egen gräns på upp till 10 GiB (10737418240 byte). En push som skulle överskrida den avvisas med 403, och avslaget anger alla tre siffrorna — storleken som inte fick plats, vad du redan använder och din gräns:

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 är registrets eget svar, hämtat från en namnrymd med en medvetet liten gräns; ditt anger din egen. Vad docker push eller en annan klient skriver ut av det bestämmer klienten. Siffrorna är löpande text inuti message, i den enhet registret väljer — läs dem, tolka dem inte maskinellt. Den gräns som faktiskt gäller för din namnrymd är den som visas i portalen under Använt lagringsutrymme och av fm registry status; läs den där i stället för att utgå från en siffra.

Den förbrukningssiffran är vad registret räknar mot din gräns: deduplicerade byte lagrade i din namnrymd. Den är inte summan av de avbildsstorlekar du ser i docker image ls, och de två skiljer sig verkligen åt — lager som delas mellan taggar i samma namnrymd räknas en gång. Räkningen sker per namnrymd, och gränsen tillämpas per namnrymd: samma lager som finns i en annan namnrymd räknas igen. Läs den som "lagring i bruk mot din gräns", och använd den inte för att stämma av en faktura. Den speglar redan din push när pushen är klar — men att pusha om lager du redan har kan knappt flytta siffran alls.

Frigöra utrymme

Ta bort en avbild så kommer utrymmet tillbaka. I portalen: öppna ett repository under Avbilder och tryck Ta bort på raden. Från CLI:et:

fm registry image list web/api                       # hitta det som ska bort
fm registry image list web/api -o json               # digests i sin helhet
fm registry image delete web/api sha256:1b0c8dd1...  # frågar först
fm registry image delete web/api sha256:1b0c8dd1... --force

Den tar en digest, inte en tagg, och en tagg avvisas i stället för att gissas. En tagg flyttar sig. Om din pipeline pushade om v1 mellan att du läste listan och tryckte enter, skulle en borttagning av "den som är taggad v1" förstöra den avbild du ville behålla — och ingenting skulle säga det. Kopiera digesten från listan.

Avbilden försvinner, inte bara taggen. Varje tagg som pekar på den följer med, och det gör manifestet också — efteråt går den varken att hämta med namn eller med digest. Det finns ingen avtaggning: att ta bort en etikett och lämna innehållet hämtbart via digest frigör ingenting och ser bara ut som en borttagning.

Din lagringssiffra sjunker direkt — men med mindre än storleken som visas

Siffran under Lagring som används, och i fm registry status, speglar redan borttagningen när den är klar. Du väntar inte på något städfönster.

Det den inte sjunker med är storleken som avbildslistan visade. Den kolumnen är avbildens egen storlek och räknar varje lager i sin helhet; inom en namnrymd räknar din gräns varje lagrat lager en gång. Att ta bort en avbild vars baslager dina andra taggar fortfarande använder frigör bara de lager ingenting annat refererar till — ofta en liten del av talet du klickade på.

Alltså: ta bort, och läs sedan av den nya siffran. Räkna inte fram den ur storlekskolumnen, och fortsätt inte ta bort för att jaga ett tal som aldrig skulle komma.

Börja med de otaggade. En rad märkt <untagged> är ett manifest som en senare push gjorde föräldralöst: ingenting kan hämta det med namn, och det räknas fortfarande mot din gräns. Det är oftast merparten av vad en full namnrymd håller.

# varje otaggad avbild i ett repository, bara digests
fm registry image list web/api --all -o json | jq -r '.data[] | select(.tags == []) | .digest'

Vill du att det sker automatiskt, ange en gallringspolicy. Den tar varje natt bort otaggade avbilder och de taggade avbilder som ligger utöver de senaste du väljer att behålla.

En avbild för flera arkitekturer tas bort via sitt index. Dess plattformsdelar kan inte tas bort var för sig och svarar med en konflikt — ta bort indexet så följer de med.

Ett avstängt register kan inte ta bort. Skrivningar avvisas medan hämtningar och listningarna fortsätter fungera, så du kan alltid se vad du håller.

docker rmi frigör ingenting. Det tar bort en lokal avbild från din egen maskin och skickar ingen förfrågan alls till registret, så lagringen som räknas mot din gräns är oförändrad.

Om ingen lagringssiffra visas alls, läs det som "inte rapporterad", aldrig som "obegränsad" — pushar kan nekas i det läget. Kontakta supporten om du ser det.

Portalen och fm visar storlekar i SI-enheter (1 GB = 10⁹ byte), samma enhet som din lagringskvot begärs i. En pull-through-caches gräns på 10737418240 byte (10 GiB) visas därför som ungefär 10,7 GB; båda beskriver samma gräns.

Gallringspolicyer

En gallringspolicy tar bort gamla avbilder åt dig, så att CI-pushar inte samlas på hög mot din gräns. Din tenant har en policy. Den gäller varje repository i din namnrymd, och varje repository bedöms för sig.

Policyn har två regler. Båda är valfria, men du anger minst en:

Regel	Vad den gör	Intervall
Behåll de senaste N taggade avbilderna	Behåller de N senast pushade taggade avbilderna i varje repository och tar bort de äldre.	1-1000
Ta bort otaggade avbilder efter X dagar	Tar bort otaggade avbilder vars senaste push ligger mer än X dagar bakåt.	1-365

En regel du inte anger behåller allt i sin klass. Med bara den första regeln tas otaggade avbilder aldrig bort; med bara den andra tas taggade avbilder aldrig bort.

N räknar avbilder, inte taggar. En avbild med tre taggar räknas en gång. Avbilder som pushats i samma ögonblick behålls i ingen garanterad ordning, så om två av dem hamnar precis vid gränsen N ska du inte räkna med vilken som blir kvar. Att pusha en avbild igen, eller ge en befintlig avbild en ny tagg, räknas som en ny push: avbilden flyttas till den nyaste änden för regeln om att behålla de senaste.

En avbild för flera arkitekturer behålls eller tas bort som en helhet. Dess plattformsdelar, och signaturer som hör till den, följer avbilden. En policy lämnar dig aldrig med en halv avbild och tar aldrig bort signaturen från en avbild den behåller.

Policyn körs varje natt, mellan kl. 00:00 och 06:00 UTC. Det finns inget eget schema och inget sätt att köra den på begäran. En policy du sparar i dag gäller från nästa körning.

Borttagna avbilder går inte att återställa

En gallringskörning tar bort avbilden, alla dess taggar och dess manifest, precis som en manuell borttagning. Kontrollera innan du sparar en policy att ingenting du driftsätter pekar på en avbild som policyn skulle ta bort — till exempel en release som du bara hämtar via digest.

Pull-through-cacher påverkas inte. En gallringspolicy omfattar bara din egen namnrymd. Varje cache har sin egen regel — en avbild som ingen hämtar på 7 dagar tas bort — och den kan du inte ändra; se Pull-through-cacher.

Utrymmet syns i din användning efter nattens körning. Din lagringssiffra, och därmed det du faktureras för, speglar det frigjorda utrymmet nästa morgon. Läs av siffran då i stället för att räkna med en exakt tidpunkt.

När du sparar en policy ersätts hela policyn. En regel du utelämnar när du sparar rensas — den behålls inte från tidigare.

Att ange en policy kräver behörighet att ta bort avbilder. Eftersom en gallringspolicy tar bort avbilder kräver det att spara en både registry:artifacts:delete och registry:settings:update (se Operationer). Att ta bort en policy kräver bara registry:settings:update.

Ange en policy

I portalen: öppna Containerregister och använd kortet för gallring. Från CLI:et:

fm registry retention set --keep-last-tagged 10 --delete-untagged-after-days 14
fm registry retention get      # vad som gäller nu
fm registry retention delete   # ta bort policyn; inget mer tas bort

Den frågar först när den nya policyn tar bort mer. Om den skulle ta bort mer än den nuvarande (ingen policy tidigare, en regel som slås på eller ett lägre tal) visar portalen och fm båda och ber dig bekräfta. I skript använder du fm registry retention set --force; utan terminal vägrar set om inte --force anges.

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 pekar på registerresursen från Terraform ovan, så att en konfiguration som också aktiverar registret skapar det först.

Att ta bort resursen, eller köra terraform destroy, tar bort policyn. Det tar inte tillbaka avbilder som en tidigare körning har tagit bort.

Om ditt register är pausat

Ett pausat register betjänar fortfarande pull. Att pusha nya avbilder är blockerat och dina push-behörigheter visas som inaktiverade — dina pull-behörigheter fortsätter att fungera, medvetet, eftersom det är så du hämtar ut dina avbilder medan registret är pausat.

Medan registret är pausat kan du varken skapa eller återkalla en behörighet. Om du bara har push-behörigheter kan du alltså inte skapa den pull-behörighet du skulle behöva för att exportera. Att ha en stående pull-behörighet undviker det.

Kontakta supporten för att återställa ett pausat register.

Vad som händer när du avslutar tenanten

Att avsluta en tenant är det enda sättet registret tas bort på, och det förstör permanent varje avbild i det. Det går inte att återställa efteråt, och Frostmoln har ingen säkerhetskopia att återskapa från.

Förloppet är fast:

När	Vad som händer
Dag 0, du avslutar tenanten	Registret blir skrivskyddat. Push blockeras och dina push-uppgifter inaktiveras. De pull-uppgifter du redan har fortsätter att fungera.
Dag 0-30	Ditt exportfönster. Hämta det du vill behålla.
Dag 30	Varje avbild, varje uppgift och själva namnrymden raderas permanent.

Pull-uppgiften måste finnas innan du avslutar. Medan en tenant avslutas kan du varken skapa eller återkalla uppgifter, så en tenant som bara har push-uppgifter kan inte exportera alls — uppgiften du skulle behöva går inte längre att skapa. Ha en stående pull-uppgift om du någonsin kan behöva exportera.

Export är en vanlig pull. Lista vad du har och hämta sedan varje referens:

fm registry repository list
fm registry image list <repository>
docker pull registry.sweden.frostmoln.cloud/<din-namnrymd>/<repository>:<tagg>

Om du bara vill frigöra utrymme och inte lämna, se Frigöra utrymme — att radera artefakter avslutar ingenting.