Cronologia del problema di migrazione dello spazio di archiviazione docker (docker root)

Non più di un paio di giorni fa, è stato deciso su uno dei server di spostare lo spazio di archiviazione del docker (la directory in cui docker memorizza tutti i file container e di immagine) in una sezione separata, che
aveva una maggiore capacità. Il compito sembrava banale e non lasciava presagire guai...

Per iniziare:

1. Arresta e uccidi tutti i contenitori della nostra applicazione:

docker-compose down

se i contenitori sono molti e sono in composizioni diverse, puoi fare questo:

docker rm -f $(docker ps -q)

2. Arresta il demone docker:

systemctl stop docker

3. Spostare la directory nella posizione desiderata:

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

4. Diciamo al demone docker di cercare nella nuova directory. Ci sono diverse opzioni: utilizzare il flag -g per indirizzare il demone a un nuovo percorso o le configurazioni di systemd, che abbiamo utilizzato. O un collegamento simbolico. Non entrerò troppo nei dettagli su questo, è su Internet. pieno di manuali sullo spostamento della radice docker in una nuova posizione.

5. Avvia il demone docker e assicurati che sia nel posto giusto:

systemctl status docker

In una delle righe di output dovremmo vedere:

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

Ci siamo assicurati che l'opzione fosse passata al demone, ora controlliamo se l'ha applicata (grazie inkvizitor68sl)!

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

6. Iniziamo la nostra applicazione:

docker-compose up -d

7. Controlla

E qui inizia il divertimento, DBMS, MQ, va tutto bene! Il database è intatto, tutto funziona... tranne nginx. Abbiamo la nostra build nginx con Kerberos e cortigiane. E la visualizzazione dei log del contenitore ha indicato che non è possibile scrivere su /var/tmp - Autorizzazione negata. Mi strofino le tempie con le dita e cerco di analizzare la situazione... Com'è possibile? L'immagine Docker non è cambiata. Abbiamo appena spostato la directory. Ha sempre funzionato, ed eccolo qui per te... Per motivi di esperimento, sono entrato con le mani nel contenitore e ho cambiato i diritti su questa directory, c'erano radice, radice 755, ha dato radice, radice 777. E tutto cominciò... Un pensiero cominciò a risuonare nella mia testa - una specie di sciocchezza... Ho pensato, beh, forse non ho tenuto conto di qualcosa...

Ho deciso che ci siamo innamorati dei diritti di accesso ai file durante il trasferimento. Abbiamo arrestato l'applicazione, il demone docker, cancellato la nuova directory e copiato la directory /var/lib/docker utilizzando rsync -a.

Penso che ora vada tutto bene, avviamo l'applicazione Docker.

Eeeee... il problema rimaneva... I miei occhi si contrassero. Sono corso alla console della mia macchina virtuale, dove ho eseguito vari test, avevo questa immagine nginx, e sono salito all'interno del container, e qui i diritti sulla directory /var/tmp sono root, root 777. Cioè il lo stesso che ho dovuto impostare manualmente. Ma le immagini sono identiche!

Il file system xfs è stato utilizzato ovunque.

Ho confrontato utilizzando il comando

docker inspect my-nginx:12345

Tutti gli hash sono identici, tutti uno a uno. Sia sul server che sulla mia macchina virtuale. Ho eliminato l'immagine nginx locale e l'ho recuperata dal registro, che per una serie di motivi si trova sulla stessa macchina. E il problema è lo stesso... Ora il mio secondo occhio si contrae.

Non ricordo più quali pensieri avevo in testa, a parte gridare “AAAAAAAAA” e altre cose. Sono le 4 del mattino e il codice sorgente Docker è stato utilizzato per comprendere il principio dell'hashing dei livelli di immagine. Ho aperto la terza lattina di bevanda energetica. E alla fine mi è venuto in mente che l'hashing tiene conto solo del file, del suo contenuto, ma NON DIRITTI DI ACCESSO! Cioè, in qualche modo misterioso i nostri diritti sono andati perduti, selinux è disabilitato, acl non viene utilizzato e non c'è alcuna parte fissa.

Ho eliminato l'immagine locale, ho anche eliminato l'immagine dal registro della finestra mobile e l'ho reinserita. E tutto ha funzionato. Si scopre che durante il trasferimento i diritti sono andati persi, sia all'interno dell'immagine locale che all'interno dell'immagine che si trova nel registro. Come ho già detto, per una serie di motivi si trovava sulla stessa vettura. E di conseguenza, in una directory /var/lib/docker.

E anticipando la domanda se hanno tentato di riportare lo sguardo del portuale sulla vecchia directory - no, non ci hanno provato, ahimè, le circostanze non lo hanno consentito. Sì, e volevo davvero capirlo.

Dopo aver scritto questo articolo, la soluzione del problema mi sembra ovvia, ma al momento dell'analisi non mi sembrava così. Onestamente, ho cercato su Google e non ho trovato situazioni simili.

Risultato: ho risolto il problema, ancora non ne capisco il motivo =(

Se qualcuno sa, indovina, ha avuto una visione sulle possibili cause di questo problema, sarò estremamente felice di sentirti nei commenti!

Fonte: habr.com