Storia del problema di trasferimento dello storage docker (root docker)

Non più di qualche giorno fa è stato deciso di spostare lo storage di Docker (la cartella in cui Docker memorizza tutti i file dei contenitori e delle immagini) su una partizione separata, che
aveva una maggiore capacità. Il compito sembrava banale e non preannunciava problemi...

Iniziamo:

1. Fermiamo e chiudiamo tutti i contenitori della nostra applicazione:

docker-compose down

se ci sono molti contenitori e sono in diversi compose, possiamo fare così:

docker rm -f $(docker ps -q)

2. Fermiamo il demone di Docker:

systemctl stop docker

3. Trasferiamo la cartella nel posto desiderato:

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

4. Comunichiamo al demone di Docker di guardare nella nuova directory. Ci sono diverse opzioni: o tramite il flag -g indicare al demone il nuovo percorso, o configurazioni systemd, che abbiamo utilizzato. Oppure un symlink. Non entrerò nei dettagli, su internet ci sono molti manuali sul trasferimento della root di Docker in un nuovo luogo.

5. Avviamo il demone di Docker e controlliamo che guardi nella giusta direzione:

systemctl status docker

In una delle righe di output dovremmo vedere:

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

Assicuriamoci di aver passato l’opzione al demone, ora controlliamo se l’ha applicata (grazie a inkvizitor68sl)!

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

6. Avviamo la nostra applicazione:

docker-compose up -d

7. Controlliamo

Ed è qui che inizia la parte interessante, DBMS, MQ, tutto bene! Il database è intatto, tutto funziona… tranne nginx. Abbiamo una nostra versione di nginx con kerberos e cortigiane. La consultazione dei log del contenitore ha indicato che non può scrivere in /var/tmp — Permission denied. Massaggio le tempie e cerco di analizzare la situazione... Come mai? L’immagine di Docker non è cambiata. Abbiamo solo trasferito la directory. Ha sempre funzionato, e ora... Per sperimentare, sono entrato manualmente nel contenitore e ho cambiato i permessi su questa cartella, eranoroot, root 755 , ho datoroot, root 777

. E tutto ha ripreso a funzionare... Nella mia mente è risuonata l'idea — una follia... Pensavo, forse ho trascurato qualcosa... Ho deciso che avevamo perso i diritti di accesso ai file durante il trasferimento. Abbiamo fermato l’applicazione, il demone di Docker, eliminato la nuova directory e abbiamo effettuato la copia della directory /var/lib/docker utilizzando.

rsync -a

E... il problema è rimasto... Ho avuto un tic all'occhio. Sono saltato alla console della mia virtual machine, dove eseguo vari test; avevo questa immagine di nginx, sono entrato nel container, e qui la directory /var/tmp ha i permessi impostati su root, root 777. Cioè, gli stessi che ho dovuto impostare manualmente. Ma le immagini sono identiche!

Ovunque è stato utilizzato il file system xfs.

Ho confrontato tramite il comando

docker inspect my-nginx:12345

Tutti gli hash sono identici, uno a uno. Sia sul server che sulla mia virtual machine. Ho eliminato l'immagine locale di nginx e l'ho scaricata nuovamente dal registry, che per vari motivi è situato su questa stessa macchina. E il problema è lo stesso... Ora anche il mio secondo occhio ha iniziato a tremare.

Non ricordo più quali pensieri giravano nella mia testa, oltre alle urla di "AAAAAA" e simili. Sono le 4 del mattino, ho preso i sorgenti di Docker per capire il principio di hashing dei layer dell'immagine. Ho aperto la terza lattina di energetico. E alla fine mi è venuto in mente che l'hashing considera solo il file, il suo contenuto, ma NON I PERMESSI! Cioè, in qualche modo misterioso i permessi si sono danneggiati, anche se selinux è disabilitato, acl non sono utilizzati, e non c'è sticky bit.

Ho eliminato l'immagine locale, ho anche eliminato l'immagine dal registry di Docker e ho fatto un nuovo push. E tutto ha funzionato. Risulta che durante il trasferimento i permessi si siano corrotti, sia nell'immagine locale che in quella nel registry. Come ho già detto, per vari motivi si trovava su questa stessa macchina. E come conseguenza in una stessa directory /var/lib/docker.

E anticipando la domanda, se abbiamo provato a riportare Docker alla vecchia directory — no, non abbiamo provato, purtroppo, le circostanze non lo permettevano. E avevo davvero voglia di capire.

Dopo aver scritto questo articolo, per me la soluzione del problema sembra ovvia, ma al momento dell'analisi non lo era affatto. Ho onestamente cercato su Google, e non ho trovato situazioni simili.

Risultato: ho risolto il problema, ma non ho capito la causa =(

Se qualcuno ha un'idea su quali potrebbero essere le cause di questo problema — sarei molto lieto di sentirlo nei commenti!

Fonte: habr.com