Rulez un registru privat docker v2.7.0 ca a pod kubernetes cu un serviciu și un volum persistent, datorită tutorialului Varun Kumar G, care a fost singura metodă de succes din configurația mea, pentru ca kubernetes să extragă din registrul meu privat de docker de pe 3 noduri--on-premises--cluster cu ubuntu 20.04 lts kvms.
Problema este cu ștergerea imaginilor din registrul kubernetes pod docker v2.7.0 (a trebuit să folosească versiunea anterioară deoarece ultima v2.7.1 nu funcționează cu htpasswd). În plus, am citit o mulțime de fire similare, cum ar fi acest, acest și acest.
Cu docker registry v2.7.1 rulați ca un container docker, nu am avut probleme la ștergerea imaginilor,
dar cu docker registry v2.7.0 rulează ca o păstăi kubernetes, pașii obișnuiți de ștergere rezultat fiind imposibilitatea de a împinge din nou imaginea ștearsă, chiar după ștergerea cu succes a blob-urilor și ștergerea manuală a folderelor de imagini sub /var/lib/registry/docker/registry/v2/repositories/.
Mai jos este podul de registry yaml
apiVersion: v1
fel: Pod
metadate:
nume: dockreg-pod
etichete:
aplicație: mregistry
specificație:
containere:
- nume: registru
imagine: registry:2.7.0
imagePullPolicy: IfNotPresent
volumMonturi:
- nume: repo-vol
mountPath: „/var/lib/registry”
- denumire: certs-vol
mountPath: „/certs”
readOnly: adevărat
- nume: auth-vol
mountPath: „/auth”
readOnly: adevărat
env:
- nume: REGISTRY_AUTH
valoare: "htpasswd"
- nume: REGISTRY_AUTH_HTPASSWD_REALM
valoare: „Regiunea registrului”
- nume: REGISTRY_AUTH_HTPASSWD_PATH
valoare: "/auth/htpasswd"
- nume: REGISTRY_HTTP_TLS_CERTIFICATE
valoare: „/certs/tls.crt”
- nume: REGISTRY_HTTP_TLS_KEY
valoare: „/certs/tls.key”
- nume: REGISTRY_STORAGE_DELETE_ENABLED
valoare: „adevărat”
volume:
- nume: repo-vol
persistentVolumeClaim:
claimName: repo-pvc
- denumire: certs-vol
secret:
secretName: certs-secret
- nume: auth-vol
secret:
secretName: auth-secret
restartPolicy: Întotdeauna
nodeName: primăvară
iar urmeaza volumul persistent yaml
apiVersion: v1
fel: PersistentVolume
metadate:
nume: repo-pv
etichete:
tip: prstore
specificație:
capacitate:
stocare: 7Gi
volumMod: Sistem de fișiere
Moduri de acces:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Păstrați
storageClassName: stocare locală
local:
fsType: ext4
cale: /root/repo
nodeAffinity:
necesar:
nodeSelectorTerms:
- matchExpressions:
- cheie: kubernetes.io/hostname
operator: In
valori:
- primăvară
---
apiVersion: v1
fel: PersistentVolumeClaim
metadate:
nume: repo-pvc
etichete:
tip: prstore
specificație:
selector:
matchLabels:
tip: prstore
volumMod: Sistem de fișiere
storageClassName: stocare locală
Moduri de acces:
- ReadWriteOnce
resurse:
cereri:
stocare: 7Gi
Să presupunem că introduc o imagine pe un pod de registru nou-nouț, după ce am șters stocarea persistentă în prealabil.
root@sea:scripts# docker push dockreg:5000/mubu4:v4
Pusarea se referă la depozit [dockreg:5000/mubu4]
9f54eef41275: Impins
v4: digest: sha256:7bd0d9a9821815dccb5c53c18cea04591ec633e2e529c5cdd39681169589c17f dimensiune: 529
Ștergerea imaginilor pare să funcționeze conform intenției până când încerc să împing din nou imaginea ștearsă, moment în care primesc temutul Stratul există deja eroare.
După cum ați văzut mai sus, am inclus în mediul pod de registry următoarele,
- nume: REGISTRY_STORAGE_DELETE_ENABLED
valoare: „adevărat”
altfel aş primi un nesuportat eroare de la curl -X DELETE sunați, chiar și după adăugare
șterge:
activat: adevărat
în /etc/docker/registry/config.yml în interiorul păstăii,
versiunea: 0.1
Buturuga:
câmpuri:
serviciu: registru
depozitare:
cache:
blobdescriptor: inmemorie
Sistemul de fișiere:
directorul rădăcină: /var/lib/registry
șterge:
activat: adevărat
http:
adresa: :5000
anteturi:
Opțiuni pentru tipul de conținut X: [nosniff]
sănătate:
driver de stocare:
activat: adevărat
interval: 10s
prag: 3
asta pare să nu facă nicio diferență în cazul meu de utilizare.
Următoarele sunt pașii de ștergere.
curl -u alexander:sofianos \
> -vsk -H "Accept: \
> application/vnd.docker.distribution.manifest.v2+json" \
> -X DELETE \
> https://dockreg:5000/v2/mubu4/manifests/sha256:\
> 7bd0d9a9821815dccb5c53c18cea04591ec633e2e529c5cdd39681169589c17f
Cele de mai sus imprimă, printre altele, următoarele
> ȘTERGE /v2/mubu4/manifests/sha256:7bd0d9a9821815dccb5c53c18cea04591ec633e2e529c5cdd39681169589c17f HTTP/2
> Gazdă: dockreg:5000
> autorizare: Basic YWxleGFuZGVyOnNvZmlhbm9z
> user-agent: curl/7.68.0
> accept: application/vnd.docker.distribution.manifest.v2+json
>
* Starea conexiunii a fost schimbată (MAX_CONCURRENT_STREAMS == 250)!
< HTTP/2 202
< docker-distribution-api-version: registry/2.0
< x-content-type-options: nosniff
< lungimea conținutului: 0
< data: sâmbătă, 30 oct 2021 13:25:53 GMT
<
* Conexiunea #0 la dockreg gazdă a rămas intactă
care pare să fie în ordine.
Mai jos, ștergerea blob-urilor din podul de registry
root@sea:scripts# kubectl exec -it dockreg-pod -- sh
/ # bin/registry garbage-collect /etc/docker/registry/config.yml
mubu4
0 blob-uri marcate, 3 blob-uri și 0 manifeste eligibile pentru ștergere
blob eligibil pentru ștergere: sha256:7b1a6ab2e44dbac178598dabe7cff59bd67233dba0b27e4fbd1f9d4b3c877a54
Info [0000] Ștergere blob:/docker/registry/v2/blobs/sha256/7b/7b1a6ab2e44dbac178598dabe7cff59bd67233dba0b27e4fbd1f9d4b3c877a54 Go.Vers
blob eligibil pentru ștergere: sha256:7bd0d9a9821815dccb5c53c18cea04591ec633e2e529c5cdd39681169589c17f
Info [0000] Ștergere blob:/docker/registry/v2/blobs/sha256/7b/7bd0d9a9821815dccb5c53c18cea04591ec6333e2e529c5cd39681169589c17f GO.VERTY = GO
blob eligibil pentru ștergere: sha256:ecb35fc8715f5ab1d9053ecb2f2d9ebbec4a59c0a0615d98de53bc29f7285085
INFO[0000] Se șterge blob: /docker/registry/v2/blobs/sha256/ec/ecb35fc8715f5ab1d9053ecb2f2d9ebbec4a59c0a0615d98de53bc29f7285085 service=118fc8715f5ab1d9053ecb2f2d9ebbec4a59c0a0615d98de53bc29f7285085 service=118fc8715f5ab1d90547474747474747085
În cele din urmă, ștergerea manuală a imaginii depozitului
/ # rm -rf /var/lib/registry/docker/registry/v2/repositories/mubu4
Pe stocarea mea persistentă, registrul arată acum așa
root@spring:repo# arbore
.
âââ docker
âââ registru
âââ v2
âââ blobs
â  âââ sha256
â  âââ 7b
â  âââ ec
âââ depozite
8 directoare, 0 fișiere
Dar când încerc să împing din nou imaginea ștearsă, obțin
root@sea:scripts# docker push dockreg:5000/mubu4:v4
Pusarea se referă la depozit [dockreg:5000/mubu4]
9f54eef41275: Stratul există deja
v4: digest: sha256:7bd0d9a9821815dccb5c53c18cea04591ec633e2e529c5cdd39681169589c17f dimensiune: 529
și în registrul meu, folderul de imagini mubu4 pe care l-am șters anterior a fost recreat în mod misterios prin comanda push de mai sus.
root@spring:repo# arbore
.
âââ docker
âââ registru
âââ v2
âââ blobs
â  âââ sha256
â  âââ 7b
â  âââ ec
âââ depozite
âââ mubu4
âââ _se manifestă
âââ revizuiri
â  âââ sha256
â  âââ 7bd0d9a9821815dccb5c53c18cea04591ec633e2e529c5cdd39681169589c17f
â  âââ link
âââ etichete
âââ v4
âââ curent
â  âââ link
âââ index
âââ sha256
âââ 7bd0d9a9821815dccb5c53c18cea04591ec633e2e529c5cdd39681169589c17f
âââ link
19 directoare, 3 fișiere
De asemenea, am încercat să șterg stocarea persistentă cu
root@spring:repo# rm -rf *
fără niciun rezultat. Încercarea de a împinge imaginea ștearsă după aceea, scoate în continuare exact același lucru Stratul există deja eroare, iar arborele de registry este din nou recreat automat, arătând exact așa cum arată în ieșirea arborelui de mai sus.
Întrebarea este ce altceva pot încerca să funcționeze și/sau alternativ,
din testarea de mai sus rezultă că în pod-ul kubernetes registry docker, există și alte fișiere care dețin configurație în care imaginile șterse par să nu fie șterse, iar aceste fișiere activează recrearea imaginii șterse printr-un apel push docker. Unde ar trebui să mă uit în afară de copac
/var/lib/registry/docker/registry/v2/
ca să pot șterge toate referințele la imaginile șterse?
