Storia del trasferimento dello storage di docker (root di 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 container e delle immagini) su una partizione separata che
aveva una maggiore capacità. L'operazione sembrava banale e non preannunciava problemi...

Iniziamo:

1. Arrestiamo e uccidiamo tutti i container della nostra applicazione:

docker-compose down

se ci sono molti container e sono in vari compose, possiamo fare così:

docker rm -f $(docker ps -q)

2. Arrestiamo il demone docker:

systemctl stop docker

3. Spostiamo la cartella nel luogo desiderato:

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

4. Informiamo il demone di docker di guardare nella nuova directory. Ci sono diverse opzioni: o specificare il nuovo percorso con il flag -g, oppure utilizzare i file di configurazione di systemd, che abbiamo utilizzato. Oppure un symlink. Non entrerò nei dettagli, ci sono molti manuali su come spostare il root di docker in un nuovo posto.

5. Avviamo il demone di docker e controlliamo che stia guardando dove deve:

systemctl status docker

In una delle righe di output dovremmo vedere:

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

Verificato che abbiamo 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

E qui inizia la parte più interessante, DBMS, MQ, tutto ok! Il database è integro, tutto funziona… tranne nginx. Abbiamo una nostra build di nginx con kerberos e cortigiane. E controllando i log del container, ho notato che non può scrivere in /var/tmp — Permission denied. Mi massaggio le tempie e cerco di analizzare la situazione… Come mai? L'immagine Docker non è cambiata. Abbiamo semplicemente spostato la directory. Ha sempre funzionato, e ora… Per esperimento sono entrato manualmente nel container e ho cambiato i permessi su questa cartella, erano root, root 755, ho dato root, root 777. E tutto ha iniziato a funzionare… È sorto un pensiero nella mia mente — è una follia… Ho pensato, forse mi è sfuggito qualche dettaglio…

Ho deciso che abbiamo perso i permessi sui file durante il trasferimento. Abbiamo fermato l'applicazione, il demone Docker, eliminato la nuova directory e copiato la directory /var/lib/docker usando rsync -a.

Penso che ora sia tutto a posto, avviamo Docker, l'applicazione.

Ehi… il problema persiste… Mi è partito un tic. Sono corso alla console della mia macchina virtuale, dove eseguo vari test. Avevo questa immagine di nginx e sono entrato nel contenitore, e qui nella cartella /var/tmp i permessi sono impostati su root, root 777. Cioè, gli stessi che ho dovuto impostare manualmente. Ma le immagini sono identiche!

È stato utilizzato ovunque il file system xfs.

Ho confrontato tramite il comando

docker inspect my-nginx:12345

Tutti gli hash sono identici, tutto è uno a uno. Sia sul server che sulla mia macchina virtuale. Ho rimosso l'immagine locale di nginx e l'ho pullata di nuovo dal registry, che per varie ragioni si trova sulla stessa macchina. E il problema è lo stesso… Adesso mi è partito anche l'altro occhio.

Non ricordo già più quali pensieri avessi in testa, oltre a urlare «AAAAAA» e altro. Sono le 4 del mattino, ho tirato fuori i sorgenti di docker per capire il principio di hashing dei layers dell'immagine. Ho aperto la terza lattina di energy drink. E alla fine mi è chiaro che l'hash tiene conto solo del file, del suo contenuto, ma NON DEI PERMESSI! Quindi, in qualche modo misterioso, i permessi si sono incasinati, eppure selinux è disattivato, acl non sono utilizzati, e non c'è sticky bit.

Ho rimosso l'immagine locale, ho anche eliminato l'immagine dal docker registry e ho fatto un nuovo push. E tutto ha funzionato. Risulta che durante il trasferimento i permessi siano stati danneggiati sia all'interno dell'immagine locale che in quella nel registry. Come ho già detto, per vari motivi era collocata sulla stessa macchina. E di conseguenza, nella stessa directory /var/lib/docker.

E prevedendo la domanda, non abbiamo provato a riportare Docker sul vecchio catalogo — no, non abbiamo provato, purtroppo le circostanze non lo consentivano. E avevo davvero voglia di capirlo.

Dopo aver scritto questo articolo, la soluzione al problema mi sembra ovvia, ma al momento dell'analisi non pareva tale. Ho fatto ricerche oneste, e non ho trovato situazioni simili.

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

Se qualcuno sa o ha qualche idea sui possibili motivi di questo problema — sarei molto felice di ascoltarvi nei commenti!

Fonte: habr.com