Sejarah masalah pemindahan storan buruh pelabuhan (akar buruh pelabuhan)

Tidak lebih daripada beberapa hari yang lalu, salah satu pelayan telah memutuskan untuk memindahkan storan docker (direktori tempat docker menyimpan semua fail bekas dan imej) ke bahagian berasingan, yang
mempunyai kapasiti yang lebih besar. Tugas itu kelihatan remeh dan tidak meramalkan masalah...

Bermula:

1. Hentikan dan bunuh semua bekas aplikasi kami:

docker-compose down

jika terdapat banyak bekas dan ia dalam komposisi yang berbeza, anda boleh melakukan ini:

docker rm -f $(docker ps -q)

2. Hentikan daemon docker:

systemctl stop docker

3. Alihkan direktori ke lokasi yang dikehendaki:

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

4. Kami memberitahu daemon docker untuk melihat dalam direktori baharu. Terdapat beberapa pilihan: sama ada gunakan bendera -g untuk menghalakan daemon ke laluan baharu, atau konfigurasi systemd, yang kami gunakan. Atau symlink. Saya tidak akan pergi ke terlalu terperinci tentang ini, ia ada di Internet. penuh manual untuk memindahkan root docker ke lokasi baharu.

5. Mulakan daemon docker dan pastikan ia kelihatan di tempat yang betul:

systemctl status docker

Dalam salah satu baris keluaran kita harus melihat:

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

Kami memastikan bahawa pilihan itu diserahkan kepada daemon, sekarang mari kita semak sama ada ia menggunakannya (terima kasih inkvizitor68sl)!

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

6. Mari mulakan permohonan kami:

docker-compose up -d

7. Semak

Dan di sini keseronokan bermula, DBMS, MQ, semuanya baik-baik saja! Pangkalan data adalah utuh, semuanya berfungsi... kecuali nginx. Kami mempunyai binaan nginx kami sendiri dengan Kerberos dan courtesans. Dan melihat log kontena menunjukkan bahawa ia tidak boleh menulis ke /var/tmp - Kebenaran ditolak. Saya menguli pelipis saya dengan jari saya dan cuba menganalisis keadaan... Bagaimanakah ini boleh berlaku? Imej Docker tidak berubah. Kami baru sahaja memindahkan direktori. Ia sentiasa berkesan, dan ini untuk anda... Demi percubaan, saya pergi ke dalam bekas dengan tangan saya dan menukar hak untuk direktori ini, terdapat akar, akar 755, memberi akar, akar 777. Dan semuanya bermula... Fikiran mula kedengaran di kepala saya - semacam karut... Saya fikir, mungkin saya tidak mengambil kira sesuatu...

Saya memutuskan bahawa kami jatuh cinta dengan hak akses kepada fail semasa pemindahan. Kami menghentikan aplikasi, daemon docker, memadam direktori baharu dan menyalin direktori /var/lib/docker menggunakan rsync -a.

Saya rasa semuanya baik-baik saja sekarang, mari tingkatkan aplikasi Docker.

Aaand... masalahnya kekal... Mata saya terkebil-kebil. Saya bergegas ke konsol mesin maya saya, di mana saya menjalankan pelbagai ujian, saya mempunyai imej nginx ini, dan saya naik ke dalam bekas, dan di sini hak untuk direktori /var/tmp adalah root, root 777. Iaitu, sama seperti yang saya perlu tetapkan secara manual. Tetapi imej adalah sama!

Sistem fail xfs digunakan di mana-mana sahaja.

Saya membandingkan menggunakan arahan

docker inspect my-nginx:12345

Semua cincang adalah sama, semuanya satu dengan satu. Kedua-dua pada pelayan dan pada mesin maya saya. Saya memadamkan imej nginx tempatan dan menariknya semula dari pendaftaran, yang atas beberapa sebab berada pada mesin yang sama. Dan masalahnya sama... Sekarang mata kedua saya berkedut.

Saya tidak ingat lagi apa yang ada dalam kepala saya, selain menjerit "AAAAAAAAA" dan lain-lain. Ia adalah pukul 4 pagi, dan kod sumber Docker digunakan untuk memahami prinsip pencincangan lapisan imej. Dibuka tin ketiga minuman tenaga. Dan akhirnya saya sedar bahawa pencincangan hanya mengambil kira fail, kandungannya, tetapi BUKAN HAK AKSES! Iaitu, dalam beberapa cara yang misteri, hak kami telah hilang, selinux dilumpuhkan, acl tidak digunakan, dan tidak ada sedikit yang melekit.

Saya memadamkan imej tempatan, juga memadamkan imej dari pendaftaran docker dan menolaknya semula. Dan semuanya berjaya. Ternyata semasa pemindahan hak telah hilang, baik di dalam imej tempatan dan di dalam imej yang terletak di dalam pendaftaran. Seperti yang telah saya katakan, atas beberapa sebab ia terletak pada kereta yang sama. Dan sebagai hasilnya, dalam satu direktori /var/lib/docker.

Dan menjangkakan soalan sama ada mereka cuba mengembalikan pandangan pekerja pelabuhan ke direktori lama - tidak, mereka tidak mencuba, malangnya, keadaan tidak mengizinkannya. Ya, dan saya benar-benar mahu memikirkannya.

Selepas menulis artikel ini, penyelesaian kepada masalah itu kelihatan jelas kepada saya, tetapi pada masa analisis nampaknya tidak begitu. Secara jujur, saya Google dan tidak menemui situasi yang serupa.

Keputusan: Saya menyelesaikan masalah, saya masih tidak faham sebabnya =(

Sekiranya sesiapa tahu, meneka, mempunyai visi tentang kemungkinan punca masalah ini, saya akan sangat gembira mendengar daripada anda dalam komen!

Sumber: www.habr.com