Dockeri salvestuse (docker root) probleemide ajalugu

Eelmisel nädalal otsustati ühel serveritel viia dockeri salvestus (kataloog, kus docker hoiab kõiki konteinerite faile ja pilte) eraldi sektsiooni, mis
omab suuremat mahtu. Ülesanne tundus triviaalne ja ei ennustanud probleeme…

Alustame:

1. Peatame ja tapame kõik meie rakenduse konteinerid:

docker-compose down

kui konteinerite arv on suur ja nad on erinevates compose’is, saab teha nii:

docker rm -f $(docker ps -q)

2. Peatame docker daemon’i:

systemctl stop docker

3. Kolime katalooge vajalikku kohta:

cp -r /var/lib/docker /docker/data/storage

4. Teatame docker daemon’ile, et ta vaataks uude katalooge. Siin on mitmeid variante: kas lisada daemon’ile uue tee kaudu -g lipp, või kasutada systemd konfiguratsioone, mida me kasutasime. Või ka sümboolne link. Ma ei hakka seda liiga palju lahti seletama, internetis on rohkelt kasutuse õpetusi docker root’i uude kohta viimise kohta.

5. Käivitame docker daemon’i ja jälgime, et ta vaataks õigesse kohta:

systemctl status docker

Ühes väljundi real peaksime nägema:

├─19493 /usr/bin/dockerd --data-root=/docker/data/storage

Veendusime, et daemonile on valik edastatud, nüüd kontrollime, kas ta rakendas selle (tänud inkvizitor68sl)!

docker info | awk '/Root Dir/ {print $NF}' 

6. Käivitame meie rakenduse:

docker-compose up -d

7. Kontrollime

Ja siin see muutub huvitavaks, DB, MQ, kõik on korras! Andmebaas on tühjaks, kõik töötab... välja arvatud nginx. Meil on oma build nginx Kerberos'e ja kurtisaanidega. Ja konteineri logide vaatamine näitas, et ta ei saa kirjutada /var/tmp — Juhtimine keelatud. Hingan sügavalt sisse ja proovisin olukorda analüüsida… Kuidas nii? Docker'i image ei muutunud. Me lihtsalt liikusime katalooge. On alati töötanud, ja nüüd äkki… Eksperimendi huvides läksin käsitsi konteinerisse ja muutsin antud katalooge õigusi, need olid root, root 755, andsin root, root 777. Ja kõik hakkas tööle… Peas kajas mõte — mis jura see on… Olin mõelnud, et võib-olla olin midagi tähelepanuta jätnud…

Otsustasin, et me kaotasime failide õigused nende üleviimisel. Peatasime rakenduse, docker daemon'i, kustutasime uue katalooge ja tegime /var/lib/docker katalooge kopeerimise, kasutades rsync -a.

Mõtlesin, et nüüd on kindlasti kõik hästi, tõstame Docker'i ja rakenduse.

Ja… probleem püsib… Mu silm tõmbleb. Tormasin oma virtuaalmasina konsooli, kus teen erinevaid teste, mul oli see nginx pilt ja ma sisenesin konteinerisse, ning seal kataloogis /var/tmp olid õigused root, root 777. Seega sellised, nagu pidin käsitsi seadma. Aga pildid on ju identsed!

Kasutati failisüsteemi xfs.

Võrdlesin käsu kaudu

docker inspect my-nginx:12345

Kõik hashid on identsed, kõik üks ühele. Nii serveris kui ka mu virtuaalmasinas. Kustutasin kohaliku nginx pildi ja tõmbasin selle uuesti registry'lt, mis mitmel põhjusel on sellel samal masinal. Ja probleem on sama… Nüüd tõmbleb mul teine silm.

Ma ei mäleta enam, millised mõtted mu peas olid peale hüüde „AAAAAAA“ ja muu. Väljas on kell neli öösel, avasin docker'i lähtekoodid, et mõista pildi kihtide hashimise põhimõtet. Ava kolmas energiajook. Ja lõpuks sain aru, et hashimine arvestab ainult faili, selle sisu, aga EI OLE ÕIGUSTE KÜSIMUS! See tähendab, et mingil salapärasel viisil on meie õigused rikutud, kuigi selinux on välja lülitatud, acl ei ole kasutusel, sticky bit puudub.

Kustutasin kohaliku pildi, kustutasin ka pildi docker registry's ning tõukasin uuesti üles. Ja kõik töötas. Tundub, et õigused said ülekandmisel rikutud, nii kohaliku pildi sees kui ka registris olevas pildis. Nagu ma juba ütlesin, asus see mitmel põhjusel ikka veel samas seadmes. Ja seega ühes kataloogis /var/lib/docker.

Ja ette aimates küsimust, kas oleme proovinud suunata docker tagasi vana katalooge — ei, ei ole proovinud, kahjuks ei lubanud asjaolud. Ja tõesti tahtsin ära lahendada.

Pärast selle artikli kirjutamist tundub mulle, et probleemile lahendamine on ilmne, kuid uurimise hetkel ei tundunud see nii. Ausalt öeldes googeldasin ja ei leidnud sarnaseid olukordi.

Kokkuvõte: probleemi lahendasin, põhjus jäi segaseks =(

Kui keegi teab, aimab või on mingi nägemus võimalike põhjuste kohta — oleksin äärmiselt tänulik kommentaarides!

Allikas: habr.com

Osta usaldusväärne veebihosting DDoS kaitsega, VPS VDS serverid 🔥 Osta usaldusväärne veebihosting DDoS kaitsega, VPS VDS serverid | ProHoster