Containerregister

Containerregisteret gir tenanten din et privat OCI-register for containerbildene dine, driftet i EU. Bildene lagres utelukkende i EU/EØS og er aldri offentlige. Alle OCI-klienter virker — docker, podman, en CI-kjører, eller en Kubernetes-klynge som henter bilder med en image pull secret.

Registerets adresse er registry.sweden.frostmoln.cloud.

Push og pull går rett til den adressen med en legitimasjon du oppretter her. De går ikke gjennom Frostmolns API, så ingenting i byggpipelinen din trenger å vite noe om plattformens API.

Aktiver registeret ditt

Registeret krever et uttrykkelig samtykke. Aktiveringen oppretter navnerommet ditt og den fakturerbare lagringen som følger med — det å ha rett til å bruke tjenesten oppretter ikke et register i seg selv.

I portalen går du til Containerregister og velger Aktiver containerregister.

bash

fm registry enable
fm registry status      # hvor du pusher, og om registeret er aktivert

Ingenting kan konfigureres ved opprettelsen: navnerommet ditt utledes fra tenant-ID-en din, så det finnes ingenting en forespørsel kunne si som ville endre det. Å kjøre aktiveringen på nytt via CLI-et eller Terraform for en allerede aktivert tenant er ikke en feil — den rapporterer gjeldende tilstand og avslutter med 0, så den er trygg i et provisjoneringsskript. (API-et selv svarer 409 der; CLI-et og Terraform-leverandøren håndterer det.)

Aktiveringen kan ikke angres, og å avslutte tenanten ødelegger bildene dine

Det finnes ingen deaktiveringshandling, verken i portalen, CLI-et eller API-et. Den eneste måten et register fjernes på, er ved å avslutte tenanten, og det ødelegger permanent hvert eneste bilde i det. Behandle aktiveringen som engangsopprettelse, og kontakt support hvis et register må fjernes.

Se Hva som skjer når du avslutter tenanten nedenfor før du avslutter en — det er et 30-dagersvindu å eksportere i, og det er den eneste sjansen.

Navnerommet ditt og bildereferanser

Navnerommet ditt er t- etterfulgt av tenant-ID-en din uten bindestreker — for eksempel t-3f2a9c1e4b7d4a2f8e1c5d6b7a8f9e0d. Enhver bildereferanse har formen:

registry.sweden.frostmoln.cloud/<navnerommet-ditt>/<bilde>:<tagg>

Navnerommet utledes fra den uforanderlige tenant-ID-en din, ikke fra navnet på tenanten. Å gi tenanten et nytt navn endrer det ikke, så bildereferanser du allerede har låst i en Dockerfile, et Helm-chart eller et deployment-manifest fortsetter å gjelde.

Portalen viser det nøyaktige navnerommet ditt under Hvor du pusher, og CLI-et skriver det ut:

bash

fm registry status

Legitimasjon

En legitimasjon er brukernavnet og passordet du logger inn med via docker login. Opprett en i portalen under Legitimasjon → Opprett legitimasjon, eller fra CLI-et:

bash

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>                        # tilbakekaller (spør først)
fm registry credential delete <id> --force                # samme, uten spørsmål

Navn er din egen etikett — det inngår ikke i brukernavnet. Gi hver legitimasjon navn etter den ene forbrukeren som har den. Uten mulighet til å avgrense til ett enkelt repositorium er etiketten det eneste som senere forteller hvilken legitimasjon som lekket og hva som slutter å virke når du tilbakekaller den.
Tilgang er pull (standard) eller push. Push inkluderer pull. Opprett pull med mindre forbrukeren faktisk publiserer bilder — en push-legitimasjon kan overskrive enhver eksisterende tagg i navnerommet ditt, også en som produksjonsmanifestene dine allerede refererer til.
Brukernavnet har prefikset robot$, for eksempel robot$t-3f2a9c1e4b7d4a2f8e1c5d6b7a8f9e0d-a1b2c3d4.
Én legitimasjon virker for alle navnerom tenanten din eier, fordi docker login skjer per vert. Det går ikke an å avgrense en legitimasjon til ett repositorium, så skadeomfanget til enhver legitimasjon er hele navnerommet ditt.
Legitimasjoner utløper ikke og kan ikke roteres på stedet — tilbakekall og opprett nye bevisst: når noen slutter, når et CI-system byttes ut, eller etter en plan du selv setter.
Du kan ha inntil 20 samtidig; flere enn det avvises, og løsningen er å tilbakekalle en du ikke lenger bruker.
Tilbakekalling får virkning umiddelbart for alt som logger inn på nytt: legitimasjonen kan ikke lenger autentisere, uten frist, så en pipeline eller en klynge som bruker den begynner å feile med én gang. En økt som allerede har et registertoken kan bruke opp den korte levetiden til det tokenet, så tilbakekalling er starten på inneslutningen, ikke hele den.

Passordet vises kun én gang

Passordet vises bare ved opprettelsen. Verken Frostmoln eller registeret beholder en hentbar kopi, og det finnes ingen rotasjonsfunksjon. Ta det vare på med én gang og legg det i Hemmeligheter eller din egen hemmelighetsforvalter.

Hold det unna kildekode, CI-jobblogger, ARG/ENV i Dockerfiler og --build-arg-verdier (som alle blir liggende i bildelag og bildehistorikk), vanlige Kubernetes-manifester, supportsaker eller chat, og utklippshistorikken din.

Mister du det, er eneste utvei å tilbakekalle legitimasjonen og opprette en ny. Slipper det derimot ut, se Hvis en legitimasjon lekker.

Innlogging

Ved et terminalvindu lar du docker spørre etter passordet — det holder det unna skallhistorikken og prosesslisten:

bash

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

Bruk anførselstegn rundt brukernavnet i skallet

Brukernavnet inneholder en $. I bash eller zsh blir et robot$t-... uten anførselstegn ekspandert bort og innloggingen avvist, slik at en fullt fungerende legitimasjon ser ødelagt ut. Bruk alltid enkle anførselstegn.

I CI, der det ikke finnes noen ledetekst, sender du passordet på stdin — aldri med -p/--password, som legger det blant prosessargumentene på en delt kjører:

bash

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

Bruk printf '%s' heller enn echo — echo tolker bakoverskråstrek-sekvenser i zsh og spiser en innledende -n/-e i bash, og begge deler forvansker stille et passord du ikke kan lese tilbake.

Hent $REGISTRY_PASSWORD fra kjørerens maskerte hemmelighetsmekanisme, og sørg for at steget ikke kjører under set -x: kommandosporing ekspanderer variabelen og skriver passordet til byggloggen, dit maskeringen kanskje ikke rekker.

docker login lagrer legitimasjonen på disk

Den skrives til ~/.docker/config.json, base64-kodet, ikke kryptert, med mindre du har konfigurert en credential helper (docker-credential-osxkeychain, pass, secretservice). Den filen er lett å kopiere inn i en byggkontekst, en sikkerhetskopi eller et synkronisert dotfile-repo. Konfigurer en helper på en arbeidsstasjon, og kjør docker logout registry.sweden.frostmoln.cloud når du er ferdig. podman skriver i stedet til $XDG_RUNTIME_DIR/containers/auth.json — podman logout tømmer den.

På en selvdriftet eller på annen måte langlivet CI-kjører finnes sjelden noen credential helper, og filen ville overleve jobben din, der neste jobb kan lese den. Gi hver jobb sin egen konfigurasjonskatalog og fjern den til slutt:

bash

export DOCKER_CONFIG="$(mktemp -d)"
# ... logg inn, bygg, push ...
docker logout registry.sweden.frostmoln.cloud; rm -rf "$DOCKER_CONFIG"

Få et nytt passord inn i en hemmelighetsforvalter

Standard tabellutskrift skriver allerede passordet til terminalen din, og med -o json gir CLI-et det umaskert — som er nettopp det som lar deg sende det videre uten at det noen gang vises på en kommandolinje:

bash

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

Bruk jq -j, ikke jq -r: -r legger til et avsluttende linjeskift, og en forvalter som beholder det gir deg et passord som feiler ved hver innlogging — uten noen andre kopi å sammenligne med.

Ingen fm secrets-kommando leser en verdi fra stdin (fm secrets create tar bare --value, som ville lagt passordet tilbake på en kommandolinje), så send det til portalens skjema Hemmeligheter → Opprett, eller til en forvalter hvis CLI leser stdin:

bash

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

set -o pipefail betyr noe her: uten det avsluttes kjeden med 0 selv om noe tidligere feiler, og du lukker terminalen i troen på at et engangspassord ble lagret. Les verdien tilbake og sammenlign før du lukker den terminalen — dette er det eneste øyeblikket du fortsatt kan. Merk at vault kv put erstatter alle nøkler på stien, så bruk vault kv patch (eller en egen sti) hvis du også lagrer brukernavnet der.

Uansett mottaker: ikke omdiriger det til en fil, ikke kjør det under set -x, og ikke kjør det i en CI-jobb som ekko-er kommandoer. Passordet er umaskert, og det ligger dessuten i terminalens rullebuffer og øktlogg — tøm dem når du er ferdig.

Hvis en legitimasjon lekker

Tilbakekall den — fm registry credential delete <id>, eller Tilbakekall i portalen. Ingen flere innlogginger med den lykkes.
Opprett en erstatning og oppdater hver forbruker som hadde den gamle. Hvis en klynge henter med den via External Secrets Operator, tving fram en oppfriskning eller slett den synkroniserte Secreten — ellers bruker den den døde legitimasjonen fram til neste oppfriskningsintervall.
Finn ut hva annet som lå samme sted. Lekket den via ~/.docker/config.json, Terraform-state, en byggelogg eller et synkronisert dotfile-repo, lekket enhver annen legitimasjon i den artefakten med den.
Vurder skaden ut fra tilgangen.
- En push-legitimasjon kan ha overskrevet enhver tagg i navnerommet ditt. Sammenlign digestene manifestene dine låser mot docker manifest inspect <ref>; et avvik er en overskriving. Du kan slette de resulterende bildene selv — se Frigjøre plass — men merk at sletting av en overskrevet tagg fjerner det NÅVÆRENDE innholdet, så push på nytt digesten du stoler på i stedet for å slette deg tilbake til den.
- En pull-legitimasjon betyr at alt i navnerommet ditt var lesbart, og en tilbakekalling gjør ikke en lesning ugjort. Gå ut fra at alt som noen gang er pushet dit, er hentet ut — også hemmeligheter bakt inn i bildelag.

Frostmoln kan ikke fortelle deg om en lekket legitimasjon faktisk ble brukt — det finnes ingen kundesynlig tilgangslogg for registeret — så digestene du noterte på forhånd er ditt eneste bevis. Det er den praktiske grunnen til å låse til digest.

Et suspendert register kan ikke inneslutes

Mens registeret ditt er suspendert, avvises både tilbakekalling og oppretting. En lekket legitimasjon forblir aktiv, og du kan ikke erstatte den. Kontakt support umiddelbart i stedet for å gå gjennom stegene over.

Fordi ingenting utløper og ingenting kan roteres på stedet, er dette også rutinen du kjører etter en plan, ikke bare etter en hendelse.

Push og hent et bilde

bash

# 1. Logg inn (bruk anførselstegn rundt brukernavnet — det inneholder en $)
docker login registry.sweden.frostmoln.cloud -u 'robot$t-...-a1b2c3d4'

# 2. Tagg bildet for navnerommet ditt
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. Hent det tilbake overalt der det finnes en legitimasjon
docker pull \
  registry.sweden.frostmoln.cloud/t-3f2a9c1e4b7d4a2f8e1c5d6b7a8f9e0d/my-app:1.0.0

podman tar de samme kommandoene. En pull-legitimasjon holder for steg 4; steg 3 krever push.

Hent bilder fra en administrert Kubernetes-klynge

Kubernetes autentiserer mot et privat register med en image pull secret — en Secret av typen kubernetes.io/dockerconfigjson. Opprett en legitimasjon med --capability pull og gi klyngen sin egen i stedet for å dele CI-legitimasjonen din, slik at en tilbakekalling av den ene ikke slår ut den andre.

Arbeidslasten som henter, trenger dessuten utgående internettilgang for å nå registerets adresse, noe som betyr at VPC-en dens trenger en gateway. En VPC opprettes uten gateway med mindre du ber om en, og uten gateway finnes verken internettilgang eller DNS-oppslag — så hentingen feiler før den begynner.

Anbefalt: synkroniser den fra Hemmeligheter

På Frostmoln administrert Kubernetes velger du klyngetillegget External Secrets Operator når du oppretter klyngen, eller legger det først til i klyngen mens den kjører (se veiledningen); på en klynge du kjører andre steder, installerer du ESO selv. Lagre deretter legitimasjonens brukernavn og passord i Hemmeligheter, med navnene registry-username og registry-password slik at de matcher remoteRef.key-verdiene under — bruk portalens skjema Hemmeligheter → Opprett, eller oppskriften med rør over, i stedet for fm secrets create --value, som ville lagt passordet på en kommandolinje.

La deretter External Secrets Operator bygge pull-hemmeligheten i klyngen, slik at passordet aldri havner i et manifest:

En SecretStore er navneromsbundet

SecretStore slås opp i ExternalSecret-objektets eget navnerom, så både frostmoln-lageret og den merkede API-nøkkelhemmeligheten bak det må finnes i my-app — gjenta steg 1 og 2 fra veiledningen for External Secrets Operator der. Vær bevisst på hva det innebærer: det plasserer en API-nøkkel som kan lese alle hemmeligheter i tenanten din i navnerommet, i bytte mot å holde ett registerpassord utenfor det. Begrens den nøkkelen til lesing av hemmeligheter, og hold navnerommets RBAC stram.

yaml

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:
      # Uten denne typen + nøkkelen lager ESO en Opaque Secret, og kubelet
      # bruker den da ikke som pull-hemmelighet.
      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 siterer og escaper verdiene, så et passord som inneholder " eller \ gir likevel et gyldig dokument. Merk refreshInterval: etter at du har erstattet en legitimasjon, bruker klyngen den gamle fram til neste oppfriskning, så senk intervallet eller slett den synkroniserte Secreten for å tvinge fram en.

Engangsvis: opprett Secreten direkte

Dette er veien på Frostmoln administrert Kubernetes.

Dette legger passordet i skallhistorikken din

Passordet havner i ~/.bash_history / ~/.zsh_history og blant prosessargumentene (/proc/<pid>/cmdline) så lenge kallet varer. Bruk dette til å komme i gang for hånd, aldri i et skript eller en CI-jobb — i en CI-jobb med kommandosporing havner det i byggloggen. På en klynge som kjører ESO, foretrekk ESO-oppskriften over.

bash

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

Uansett refererer du den fra pod-spesifikasjonen:

yaml

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

Å låse til digest i stedet for tagg er verdt de ekstra tegnene her. Tagger i navnerommet ditt er foranderlige, og alle som har en push-legitimasjon kan flytte en, så en digest er den eneste referansen som ikke kan endres under en kjørende deployment.

Terraform

Både aktiveringen og legitimasjonen er Terraform-ressurser:

hcl

resource "frostmoln_container_registry" "this" {}

resource "frostmoln_container_registry_credential" "ci" {
  name       = "ci-pipeline"
  capability = "pull" # standard; bruk "push" bare for en publisist

  depends_on = [frostmoln_container_registry.this]
}

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

Legitimasjonens passord skrives til Terraforms state

Det returneres bare én gang, så leverandøren lagrer det. Uten en konfigurert backend skriver Terraform terraform.tfstate som JSON i klartekst i arbeidskatalogen din — vanligvis inne i et git-repositorium, noe som motsier enhver annen regel på denne siden.

Bruk en kryptert fjernbackend (Frostmolns objektlagring via S3-backenden virker), og legg terraform.tfstate* i .gitignore — terraform.tfstate.backup er en andre kopi i klartekst som overlever overgangen til en fjernbackend.

Passordet når også terraform show, JSON-planfiler, enhver CI-artefakt eller cache som beholder state mellom kjøringer, og utdata fra TF_LOG=DEBUG/TRACE, som fanger leverandørens HTTP-svar — inkludert det som bærer passordet. Å merke en output sensitive = true skjuler den bare fra konsollutdata — ikke fra state, og ikke fra terraform output -json.

terraform destroy sletter ikke registeret. Det finnes ingen nedbyggingsfunksjon — ressursen fjernes fra state med en advarsel, mens navnerommet, bildene og den fakturerbare tilstanden alle består. Legitimasjonen er uforanderlig: å endre name eller capability erstatter den og gir et nytt passord, så oppdater forbrukerne dine når du gjør det.

Lagring og grensen

Navnerommet ditt har en hard lagringsgrense: tenantens lagringskvote for containerregisteret — 10 GB med mindre du har fått en økning godkjent, og i så fall det godkjente beløpet. Hvert navnerom for en pull-through-cache har sin egen grense på opptil 10 GiB (10737418240 byte). En push som ville krysse den, avvises med 403, og avslaget oppgir alle tre tallene — størrelsen som ikke fikk plass, hva du allerede bruker, og grensen din:

http

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 registerets eget svar, hentet fra et navnerom med en bevisst liten grense; ditt oppgir din egen. Hva docker push eller en annen klient skriver ut av det, bestemmer klienten. Tallene er løpende tekst inne i message, i den enheten registeret velger — les dem, ikke parse dem. Grensen som faktisk gjelder for navnerommet ditt, er den som vises i portalen under Lagring i bruk og av fm registry status; les den der i stedet for å anta et tall.

Det forbrukstallet er det registeret teller mot grensen din: deduplikerte byte lagret i navnerommet ditt. Det er ikke summen av bildestørrelsene du ser i docker image ls, og de to er reelt forskjellige — lag som deles mellom tagger i samme navnerom telles én gang. Tellingen skjer per navnerom, og grensen gjelder per navnerom: det samme laget som ligger i et annet navnerom, telles på nytt. Les det som «lagring i bruk mot grensen din», og bruk det ikke til å avstemme en faktura. Det gjenspeiler allerede pushen din når den er ferdig — men å pushe lag du allerede har på nytt kan knapt flytte tallet i det hele tatt.

Frigjøre plass

Slett et bilde, så kommer plassen tilbake. I portalen: åpne et repository under Bilder og trykk Fjern på raden. Fra CLI-et:

bash

fm registry image list web/api                       # finn det som skal bort
fm registry image list web/api -o json               # digester i sin helhet
fm registry image delete web/api sha256:1b0c8dd1...  # spør først
fm registry image delete web/api sha256:1b0c8dd1... --force

Den tar en digest, ikke en tagg, og en tagg avvises i stedet for å gjettes. En tagg flytter seg. Hvis pipelinen din pushet v1 på nytt mellom at du leste listen og trykket enter, ville en sletting av "den som er tagget v1" ødelagt bildet du ville beholde — og ingenting ville sagt fra. Kopier digesten fra listen.

Bildet forsvinner, ikke bare taggen. Hver tagg som peker på det følger med, og det gjør manifestet også — etterpå kan det verken hentes med navn eller med digest. Det finnes ingen avtagging: å fjerne en etikett og la innholdet være hentbart via digest frigjør ingenting og ser bare ut som en sletting.

Lagringstallet ditt går ned med én gang — men med mindre enn størrelsen som vises

Tallet under Lagring i bruk, og i fm registry status, gjenspeiler allerede slettingen når den er ferdig. Du venter ikke på noe oppryddingsvindu.

Det det ikke går ned med, er størrelsen bildelisten viste. Den kolonnen er bildets egen størrelse og teller hvert lag i sin helhet; innenfor et navnerom teller grensen din hvert lagrede lag én gang. Å slette et bilde hvis baselag de andre taggene dine fortsatt bruker, frigjør bare lagene ingenting annet refererer til — ofte en liten del av tallet du klikket på.

Altså: slett, og les så av det nye tallet. Ikke regn det ut fra størrelseskolonnen, og ikke fortsett å slette for å jage et tall som aldri kom til å komme.

Begynn med de utaggede. En rad merket <untagged> er et manifest en senere push gjorde foreldreløst: ingenting kan hente det med navn, og det teller fortsatt mot grensen din. Det er som regel mesteparten av det et fullt navnerom holder på.

bash

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

Vil du at dette skal skje automatisk, sett en oppbevaringsregel. Den sletter hver natt utaggede bilder og de taggede bildene som ligger utover de nyeste du velger å beholde.

Et flerarkitekturbilde slettes via indeksen sin. Plattformdelene kan ikke fjernes hver for seg og svarer med en konflikt — slett indeksen, så følger de med.

Et suspendert register kan ikke slette. Skrivinger avvises mens henting og listene fortsetter å virke, så du kan alltid se hva du har.

docker rmi frigjør ingenting. Det sletter et lokalt bilde fra din egen maskin og sender ingen forespørsel til registeret i det hele tatt, så lagringen som telles mot grensen din er uendret.

Vises ingen lagringsverdi i det hele tatt, les det som «ikke rapportert», aldri som «ubegrenset» — pusher kan avvises i den tilstanden. Kontakt support hvis du ser det.

Portalen og fm viser størrelser i SI-enheter (1 GB = 10⁹ byte), samme enhet som lagringskvoten din bes om i. En pull-through-caches grense på 10737418240 byte (10 GiB) vises derfor som omtrent 10,7 GB; begge beskriver samme grense.

Oppbevaringsregler

En oppbevaringsregel sletter gamle bilder for deg, så CI-pusher ikke hoper seg opp mot grensen din. Tenanten din har én oppbevaringsregel. Den gjelder hvert repository i navnerommet ditt, og hvert repository vurderes for seg.

Oppbevaringsregelen har to deler. Begge er valgfrie, men du setter minst én:

Del	Hva den gjør	Område
Behold de siste N taggede bildene	Beholder de N sist pushede taggede bildene i hvert repository og sletter de eldre.	1-1000
Slett utaggede bilder etter X dager	Sletter utaggede bilder der siste push er mer enn X dager gammel.	1-365

En del du ikke setter, beholder alt i sin klasse. Med bare den første delen slettes utaggede bilder aldri; med bare den andre slettes taggede bilder aldri.

N teller bilder, ikke tagger. Et bilde med tre tagger telles én gang. Bilder som er pushet i samme øyeblikk, beholdes i ingen garantert rekkefølge, så hvis to av dem havner akkurat på grensen N, ikke regn med hvilket som blir igjen. Å pushe et bilde på nytt, eller gi et eksisterende bilde en ny tagg, regnes som en ny push: bildet flyttes til den nyeste enden for regelen om å beholde de siste.

Et flerarkitekturbilde beholdes eller slettes som en helhet. Plattformdelene, og signaturer som hører til bildet, følger bildet. En oppbevaringsregel etterlater deg aldri med et halvt bilde og fjerner aldri signaturen fra et bilde den beholder.

Oppbevaringsregelen kjøres hver natt, mellom kl. 00:00 og 06:00 UTC. Det finnes ingen egen tidsplan og ingen måte å kjøre den på forespørsel. En regel du lagrer i dag, gjelder fra neste kjøring.

Slettede bilder kan ikke gjenopprettes

En oppbevaringskjøring sletter bildet, alle taggene og manifestet, akkurat som en manuell sletting. Før du lagrer en regel, sjekk at ingenting du deployer peker på et bilde regelen ville slettet — for eksempel en release du bare henter via digest.

Pull-through-cacher berøres ikke. En oppbevaringsregel gjelder bare ditt eget navnerom. Hver cache har sin egen regel — et bilde ingen henter på 7 dager, fjernes — og den kan du ikke endre; se Pull-through-cacher.

Plassen vises i forbruket ditt etter nattens kjøring. Lagringstallet ditt, og dermed det du faktureres for, gjenspeiler den frigjorte plassen neste morgen. Les av tallet da i stedet for å regne med et nøyaktig tidspunkt.

Når du lagrer en oppbevaringsregel, erstattes hele regelen. En del du utelater når du lagrer, nullstilles — den beholdes ikke fra før.

Å sette en oppbevaringsregel krever tillatelse til å slette bilder. Fordi en oppbevaringsregel sletter bilder, krever lagring både registry:artifacts:delete og registry:settings:update (se Operasjoner). Å fjerne regelen krever bare registry:settings:update.

Sett en oppbevaringsregel

I portalen: åpne Containerregister og bruk kortet for oppbevaring. Fra CLI-et:

bash

fm registry retention set --keep-last-tagged 10 --delete-untagged-after-days 14
fm registry retention get      # hva som gjelder nå
fm registry retention delete   # fjern regelen; ingenting mer slettes

Lagring spør først når den nye regelen sletter mer. Hvis den ville slettet mer enn den nåværende (ingen regel fra før, en del som slås på, eller et lavere tall), viser portalen og fm begge og ber deg bekrefte. I skript bruker du fm registry retention set --force; uten terminal nekter set med mindre --force er gitt.

Med Terraform:

hcl

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

  depends_on = [frostmoln_container_registry.this]
}

depends_on peker på registerressursen fra Terraform ovenfor, så en konfigurasjon som også aktiverer registeret, oppretter det først.

Å fjerne ressursen, eller kjøre terraform destroy, fjerner oppbevaringsregelen. Det henter ikke tilbake bilder en tidligere kjøring har slettet.

Hvis registeret ditt er suspendert

Et suspendert register betjener fortsatt pull. Å pushe nye bilder er blokkert, og push-legitimasjonene dine vises som deaktiverte — pull-legitimasjonene dine fortsetter å virke, bevisst, fordi det er slik du henter ut bildene dine mens registeret er suspendert.

Mens registeret er suspendert kan du verken opprette eller tilbakekalle en legitimasjon. Har du bare push-legitimasjoner, kan du altså ikke opprette pull-legitimasjonen du ville trengt for å eksportere. Å ha én stående pull-legitimasjon unngår det.

Kontakt support for å gjenopprette et suspendert register.

Hva som skjer når du avslutter tenanten

Å avslutte en tenant er den eneste måten registeret fjernes på, og det ødelegger permanent hvert eneste bilde i det. Det finnes ingen gjenoppretting etterpå, og Frostmoln har ingen sikkerhetskopi å hente fra.

Forløpet er fast:

Når	Hva som skjer
Dag 0, du avslutter tenanten	Registeret blir skrivebeskyttet. Push blokkeres og push-legitimasjonen din deaktiveres. Pull-legitimasjonen du allerede har, fortsetter å virke.
Dag 0-30	Eksportvinduet ditt. Hent det du vil beholde.
Dag 30	Hvert bilde, hver legitimasjon og selve navnerommet slettes permanent.

Pull-legitimasjonen må finnes før du avslutter. Mens en tenant avsluttes, kan du verken opprette eller trekke tilbake legitimasjon, så en tenant som bare har push-legitimasjon kan ikke eksportere i det hele tatt — legitimasjonen du ville trengt, kan ikke lenger opprettes. Ha én stående pull-legitimasjon hvis du noen gang kan trenge å eksportere.

Eksport er en vanlig pull. List opp hva du har, og hent så hver referanse:

bash

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

Vil du bare frigjøre plass og ikke forlate tjenesten, se Frigjøre plass — å slette artefakter avslutter ingenting.

Databehandling / Instanser

DNS

Databaser

Kubernetes

IAM-tilgangspolicyer