Problēmas vēsture ar docker krātuves pārvietošanu (docker root)

Pirms dažām dienām tika nolemts kādā no serveriem iznest docker uzglabāšanu (katalogs, kur docker uzglabā visus konteineru un attēlu failus) atsevišķā nodalījumā, kam
bija lielāka ietilpība. Uzdevums, šķiet, ir vienkāršs un nenozīmē briesmas...

Sākam:

1. Apturam un iznīcinām visus mūsu lietojumprogrammas konteinerus:

docker-compose down

ja konteineru ir daudz un tie ir dažādās kompozīcijās, var darīt tā:

docker rm -f $(docker ps -q)

2. Apturam docker demon:

systemctl stop docker

3. Pārvietojam katalogu vajadzīgajā vietā:

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

4. Paziņojam docker demonam, lai tas skatītos jaunajā direktorijā. Šeit ir vairāki varianti: vai nu caur atslēgu -g norādīt demonam jauno ceļu, vai arī izmantot systemd konfigurācijas, kuras mēs izmantojām. Vai arī simbolisko saiti. Negribu to ļoti izklāstīt, internetā ir pilns rokasgrāmatu par docker saknes pārvietošanu uz jaunu vietu.

5. Sākam docker demon, un novērojam, lai tas skatītos tur, kur vajag:

systemctl status docker

Vienā no izsnieguma rindām mums jāredz:

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

Pārliecinājāmies, ka demonam nodota opcija, tagad pārbaudīsim, vai tā tika piemērota (paldies inkvizitor68sl)!

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

6. Sākam mūsu lietojumprogrammu:

docker-compose up -d

7. Pārbaudām

Un te sākas visinteresantākā daļa, DB, MQ, viss kārtībā! Datu bāze ir vesela, viss strādā… izņemot nginx. Mums ir sava nginx versija ar Kerberos un kurtizānēm. Un konteineru žurnāla apskate norādīja, ka tas nevar rakstīt /var/tmp — Atļauja atteikta. Izstaipās pirksti un mēģinu analizēt situāciju… Kā tā var būt? Docker attēls taču nemainījās. Mēs vienkārši pārvietojām direktoriju. Vienmēr strādāja, un te pēkšņi… Eksperimenta pēc iegāju konteinerā un mainīju šo katalogu tiesības, bija root, root 755, devu root, root 777. Un viss sākās… Prātā izskanēja doma — dīvaini… Domāju, nu varbūt kaut ko neesmu ņēmis vērā...

Izlemu, ka mēs esam zaudējuši piekļuves tiesības faili pārvietošanas laikā. Apturējām lietojumprogrammu, docker demon, izdzēsām jaunizveidoto direktoriju un veicām kopēšanu no direktorijas /var/lib/docker jau izmantojot rsync -a.

Domāju, tagad noteikti viss ir kārtībā, pacelam docker, lietojumprogrammu.

Un... problēma palika... Man acs sākusi raustīties. Es steidzos uz savas virtuālās mašīnas konsoli, kur veicu dažādus testus, man bija šis nginx attēls, un es iekļuvu konteinera iekšienē, un tad /var/tmp katalogam ir tiesības root, root 777. Tās ir pašas, kādas man nācās uzstādīt manuāli. Bet attēli taču ir identiski!

Visur tika izmantota xfs failu sistēma.

Es salīdzināju ar komandu

docker inspect my-nginx:12345

Visas hash vērtības ir identiskas, viss ir viens uz vienu. Gan uz servera, gan manā virtuālajā mašīnā. Es izdzēsu vietējo nginx attēlu un atkārtoti to ielaidu no reģistra, kurš dažādu iemeslu dēļ atrodas uz tās pašas mašīnas. Un problēma ir tāda pati... Tagad man sāka raustīties otra acs.

Es jau neatceros, kādas domas bija manā galvā, izņemot saucienus «AAAAAA» un visu pārējo. Ieliku trešo enerģijas dzēriena bundžu. Un beidzot sapratu, ka hashēšana ņem vērā tikai failu, tā saturu, bet NE TIESĪBAS! Tātad, kaut kādā noslēpumainā veidā mūsu tiesības tika salauztas, turklāt selinux ir izslēgts, acl nav izmantots, sticky bit nav.

Es izdzēsu vietējo attēlu, arī izdzēsu attēlu no docker reģistra un nospiedu to atkārtoti. Un viss sāka strādāt. Izrādās, ka pārvietošanas laikā tiesības tika salauztas, gan vietējā attēlā, gan attēlā, kas atrodas reģistrā. Kā jau teicu, dažādu iemeslu dēļ tas atradās uz tās pašas mašīnas. Un kā sekas vienā katalogā /var/lib/docker.

Un, gaidot jautājumu, vai esmu mēģinājis atgriezt docker uz veco katalogu — nē, neesmu mēģinājis, diemžēl apstākļi to neļāva. Un arī ļoti gribējās izprast situāciju.

Pēc šī raksta uzrakstīšanas man risinājums šķiet acīmredzams, bet brīdī, kad to risināju, tas tāds nešķita. Godīgi meklēju internetā un neatradu līdzīgas situācijas.

Rezultāts: problēmu atrisināju, bet iemeslu tā arī nesapratu =(

Ja kāds zina, nojauš, bija idejas par iespējamajiem šīs problēmas cēloņiem — es būšu ļoti priecīgs par komentāriem!

Avots: habr.com