„Docker“ saugyklos perkėlimo problemos istorija (dokerio šaknis)

Ne daugiau kaip prieš porą dienų viename iš serverių buvo nuspręsta perkelti docker saugyklą (katalogas, kuriame docker saugo visus konteinerio ir vaizdo failus) į atskirą skyrių, kuris
turėjo didesnį pajėgumą. Užduotis atrodė nereikšminga ir nenumatė bėdų...

Tęskime:

1. Sustabdykite ir užmuškite visus mūsų programos konteinerius:

docker-compose down

Jei konteinerių yra daug ir jie yra skirtingos sudėties, galite tai padaryti:

docker rm -f $(docker ps -q)

2. Sustabdykite dokerio demoną:

systemctl stop docker

3. Perkelkite katalogą į norimą vietą:

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

4. Mes liepiame dokerių demonui ieškoti naujojo katalogo. Yra kelios parinktys: arba naudokite vėliavėlę -g, norėdami nukreipti demoną į naują kelią, arba systemd konfigūracijas, kurias naudojome. Arba simbolinė nuoroda. Per daug nesileisiu apie tai, tai yra internete. pilnas vadovai, kaip perkelti dokerio šaknį į naują vietą.

5. Paleiskite dokerio demoną ir įsitikinkite, kad jis atrodo tinkamoje vietoje:

systemctl status docker

Vienoje iš išvesties eilučių turėtume matyti:

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

Įsitikinome, kad parinktis buvo perduota demonui, dabar patikrinkime, ar jis ją pritaikė (ačiū inkvizitor68sl)!

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

6. Pradėkime savo programą:

docker-compose up -d

7. Tikrinimas

Ir čia prasideda linksmybės, DBVS, MQ, viskas gerai! Duomenų bazė nepažeista, viskas veikia... išskyrus nginx. Mes turime savo „nginx“ kūrimą su „Kerberos“ ir kurtizanėmis. Ir peržiūrint konteinerio žurnalus buvo parodyta, kad jis negali rašyti į /var/tmp - Leidimas atmestas. Pirštais minku smilkinius ir bandau analizuoti situaciją... Kaip tai įmanoma? Docker vaizdas nepasikeitė. Mes ką tik perkėlėme katalogą. Visada veikė, o štai tau... Eksperimento sumetimais įėjau į konteinerį rankomis ir pakeičiau teises į šį katalogą, ten buvo šaknis, šaknis 755, davė šaknis, šaknis 777. Ir viskas prasidėjo... Galvoje pradėjo suktis mintis - kažkokia nesąmonė... Galvojau, na, gal aš į kažką neatsižvelgiau...

Nusprendžiau, kad perkėlimo metu susižavėjome prieigos prie failų teisėmis. Sustabdėme programą, docker demoną, ištrynėme naują katalogą ir nukopijavome /var/lib/docker katalogą naudodami rsync -a.

Manau, kad dabar viskas gerai, pakelkime „Docker“ programą.

Aaand... problema liko... Mano akys trūkčiojo. Nuskubėjau į savo virtualios mašinos konsolę, kur atlieku įvairius testus, turėjau šį nginx vaizdą ir įlipau į konteinerį, o čia teisės į /var/tmp katalogą yra root, root 777. Tai yra, tą patį, ką turėjau nustatyti rankiniu būdu. Bet vaizdai identiški!

Xfs failų sistema buvo naudojama visur.

Palyginau naudodamas komandą

docker inspect my-nginx:12345

Visos maišos yra vienodos, visi vienas prieš vieną. Tiek serveryje, tiek mano virtualioje mašinoje. Ištryniau vietinį nginx vaizdą ir vėl ištraukiau jį iš registro, kuris dėl daugelio priežasčių yra tame pačiame kompiuteryje. O problema ta pati... Dabar antroji akis trūkčioja.

Jau nebepamenu, kokios mintys sukosi mano galvoje, be to, šaukė „AAAAAAAAA“ ir kiti dalykai. Buvo 4 valanda ryto, o „Docker“ šaltinio kodas buvo naudojamas norint suprasti vaizdo sluoksnių maišos principą. Atidarė trečią skardinę energetinio gėrimo. Ir galų gale man pasirodė, kad maiša atsižvelgia tik į failą, jo turinį, bet NĖRA PRIEIGOS TEISĖS! Tai yra, kažkokiu paslaptingu būdu buvo prarastos mūsų teisės, selinux išjungtas, acl nenaudojamas ir nėra lipnios bitės.

Aš ištryniau vietinį vaizdą, taip pat ištryniau vaizdą iš docker registro ir vėl jį nustūmiau. Ir viskas veikė. Pasirodo, kad perdavimo metu buvo prarastos teisės tiek vietinio vaizdo viduje, tiek registre gulinčio vaizdo viduje. Kaip jau sakiau, dėl daugelio priežasčių jis buvo tame pačiame automobilyje. Ir dėl to viename kataloge /var/lib/docker.

Ir numatę klausimą, ar jie bandė grąžinti dokininko žvilgsnį į senąjį katalogą - ne, jie nebandė, deja, aplinkybės to neleido. Taip, ir aš tikrai norėjau tai išsiaiškinti.

Parašius šį straipsnį problemos sprendimas man atrodo akivaizdus, ​​tačiau analizės metu taip neatrodė. Sąžiningai, aš ieškojau „Google“ ir neradau panašių situacijų.

Rezultatas: išsprendžiau problemą, vis dar nesuprantu priežasties =(

Jei kas nors žino, spėja, turėjo viziją apie galimas šios problemos priežastis, man bus labai malonu išgirsti iš jūsų komentaruose!

Šaltinis: www.habr.com