{"id":36736,"date":"2019-10-31T22:13:26","date_gmt":"2019-10-31T19:13:26","guid":{"rendered":"https:\/\/prohoster.info\/blog\/istoriya-problemy-perenosa-docker-storage-docker-root\/"},"modified":"2019-10-31T22:13:26","modified_gmt":"2019-10-31T19:13:26","slug":"istoriya-problemy-perenosa-docker-storage-docker-root","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/istoriya-problemy-perenosa-docker-storage-docker-root","title":{"rendered":"De geschiedenis van het probleem van het verplaatsen van docker storage (docker root)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Enige dagen geleden werd besloten om de Docker-opslag (de map waarin Docker alle containerbestanden en -images opslaat) op een aparte partitie te plaatsen die
\nmeer capaciteit had. De taak leek triviaal en beloofde niets te goeds\u2026
\n<\/a><\/noindex>
\nLaten we beginnen:<\/p>\n

1. Stop en verwijder alle containers van onze applicatie: <\/p>\n

docker-compose down<\/code><\/pre>\n
\nAls er veel containers zijn en ze in verschillende compose-bestanden staan, kan dit ook: <\/p>\n
docker rm -f $(docker ps -q)<\/code><\/pre>\n
\n2. Stop de Docker-daemon: <\/p>\n
systemctl stop docker<\/code><\/pre>\n
\n3. Verplaats de map naar de juiste locatie: <\/p>\n
cp -r \/var\/lib\/docker \/docker\/data\/storage<\/code><\/pre>\n
\n4. Geef de Docker-daemon door dat hij naar de nieuwe directory moet kijken. Er zijn verschillende opties: ofwel de daemon naar het nieuwe pad wijzen met de -g vlag, of met systemd-configuraties, wat wij hebben gebruikt. Of als symbolische link. Ik zal dit niet in detail beschrijven, er zijn genoeg handleidingen op internet<\/a><\/noindex> over het verplaatsen van de Docker-root naar een nieuwe locatie.<\/p>\n
5. Start de Docker-daemon weer, en controleer of hij naar de juiste locatie kijkt: <\/p>\n
systemctl status docker<\/code><\/pre>\n
\nIn een van de regels van de uitvoer zouden we moeten zien:<\/p>\n
\u251c\u250019493 \/usr\/bin\/dockerd --data-root=\/docker\/data\/storage<\/code><\/pre>\n
\nWe hebben gecontroleerd dat we de optie aan de daemon hebben doorgegeven, nu controleren we of hij deze heeft toegepast (dank aan inkvizitor68sl<\/a><\/noindex>)!<\/p>\n
docker info | awk '\/Root Dir\/ {print $NF}' <\/code><\/pre>\n
\n6. Start onze applicatie: <\/p>\n
docker-compose up -d<\/code><\/pre>\n
\n7. Controleer het<\/p>\n
En hier begint het interessante, DB, MQ, alles werkt goed! Database is intact, alles functioneert\u2026 behalve nginx. We hebben onze eigen nginx-build met Kerberos en courtesans. En het bekijken van de logs van de container gaf aan dat hij niet kon schrijven naar \/var\/tmp - Toegang geweigerd. Ik wrijf mijn slapen en probeer de situatie te analyseren\u2026 Hoe kan dit? Het Docker-image is immers niet veranderd. We hebben alleen de directory verplaatst. Het heeft altijd gewerkt, en nu ineens\u2026 Uit nieuwsgierigheid ben ik de container ingegaan en heb ik de rechten op deze map gewijzigd, waren root, root 755<\/u>, gaf root, root 777<\/u>. En alles werkte weer\u2026 In mijn hoofd hoorde ik een gedachte \u2013 dit is onzin\u2026 Ik dacht, misschien heb ik iets over het hoofd gezien\u2026 <\/p>\n
Ik besloot dat we waarschijnlijk de bestandsrechten bij het verplaatsen hadden verloren. We stopten de applicatie, de Docker-daemon, verwijderden de nieuwe directory en voerden een kopie uit van de directory \/var\/lib\/docker met behulp van rsync -a<\/code>. <\/p>\n
Ik dacht dat alles nu zeker goed was, we starten Docker en de applicatie.<\/p>\n
Tja\u2026 het probleem blijft bestaan\u2026 Mijn oog trilt. Ik sprintte naar de console van mijn virtuele machine, waar ik verschillende tests uitvoer. Ik had dit nginx-image en ik ging het container in, en daar had de map \/var\/tmp de rechten root, root 777. Dat zijn dezelfde rechten die ik handmatig moest instellen. Maar de images zijn identiek! <\/p>\n
Overal werd het bestandssysteem xfs gebruikt.<\/u><\/p>\n
Ik vergeleek het met het commando <\/p>\n
docker inspect my-nginx:12345<\/code><\/pre>\n
\nAlle hashes zijn identiek, allemaal precies hetzelfde. Zowel op de server als op mijn virtuele machine. Ik verwijderde het lokale nginx-image en haalde het opnieuw van de registry, die om verschillende redenen op dezelfde machine staat. En het probleem is hetzelfde\u2026 Nu trilt ook mijn andere oog.<\/p>\n
Ik kan me niet herinneren welke gedachten er in mijn hoofd waren, naast schreeuwen 'AAAAAAA' en dergelijke. Het is 4 uur 's nachts, de bronbestanden van Docker zijn in gebruik om het principe van hashing van de layers van het image te begrijpen. Ik heb het derde blik energiedrank geopend. En uiteindelijk realiseerde ik me dat hashing alleen het bestand en de inhoud ervan in overweging neemt, maar GEEN TOEGANGSRIGHTS<\/b>! Dus op een of andere mysterieuze manier zijn onze rechten verstoord, terwijl selinux uitgeschakeld is, acl niet wordt gebruikt, en de sticky bit ontbreekt. <\/p>\n
Ik verwijderde het lokale image, verwijderde ook het image van de docker registry en duwde het opnieuw. En alles werkte. Het blijkt dat de rechten zijn verstoord tijdens de overdracht, zowel binnen het lokale image als binnen het image in de registry. Zoals ik al zei, bevond deze zich om verschillende redenen op dezelfde machine. En als gevolg in dezelfde map \/var\/lib\/docker.<\/p>\n
En in afwachting van de vraag of we geprobeerd hebben om Docker naar de oude map te verwijzen \u2014 nee, we hebben het niet geprobeerd, helaas, de omstandigheden lieten het niet toe. En ik wilde het graag uitzoeken.<\/p>\n
Na het schrijven van dit artikel lijkt de oplossing voor het probleem me vanzelfsprekend, maar op het moment van het analyseren leek het niet zo. Ik heb eerlijk gegoogeld en vond geen vergelijkbare situaties.<\/p>\n
Conclusie: probleem opgelost, maar de oorzaak begreep ik niet =(<\/p>\n
Als iemand idee\u00ebn heeft of een idee heeft over de mogelijke oorzaken van dit probleem \u2014 ik hoor het graag in de reacties!
\n
Bron: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u041d\u0435 \u0434\u0430\u043b\u0435\u0435, \u0447\u0435\u043c \u043f\u0430\u0440\u0443 \u0434\u043d\u0435\u0439 \u043d\u0430\u0437\u0430\u0434 \u0431\u044b\u043b\u043e \u0440\u0435\u0448\u0435\u043d\u043e \u043d\u0430 \u043e\u0434\u043d\u043e\u043c \u0438\u0437 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u0432\u044b\u043d\u0435\u0441\u0442\u0438 docker storage (\u043a\u0430\u0442\u0430\u043b\u043e\u0433, \u0433\u0434\u0435 \u0434\u043e\u043a\u0435\u0440 \u0445\u0440\u0430\u043d\u0438\u0442 \u0432\u0441\u0435 \u0444\u0430\u0439\u043b\u044b \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432, \u043e\u0431\u0440\u0430\u0437\u043e\u0432) \u043d\u0430 \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u044b\u0439 \u0440\u0430\u0437\u0434\u0435\u043b, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u043e\u0431\u043b\u0430\u0434\u0430\u043b \u0431\u043e\u043b\u044c\u0448\u0435\u0439 \u0435\u043c\u043a\u043e\u0441\u0442\u044c\u044e. \u0417\u0430\u0434\u0430\u0447\u0430, \u043a\u0430\u0437\u0430\u043b\u043e\u0441\u044c \u0431\u044b, \u0442\u0440\u0438\u0432\u0438\u0430\u043b\u044c\u043d\u0430\u044f \u0438 \u043d\u0435 \u043f\u0440\u0435\u0434\u0432\u0435\u0449\u0430\u043b\u0430 \u0431\u0435\u0434\u044b\u2026 \u041f\u0440\u0438\u0441\u0442\u0443\u043f\u0430\u0435\u043c: 1. \u041e\u0441\u0442\u0430\u043d\u0430\u0432\u043b\u0438\u0432\u0430\u0435\u043c \u0438 \u0443\u0431\u0438\u0432\u0430\u0435\u043c \u0432\u0441\u0435 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u044b \u043d\u0430\u0448\u0435\u0433\u043e \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f: docker-compose down \u0435\u0441\u043b\u0438 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432 \u043c\u043d\u043e\u0433\u043e, \u0438 \u043e\u043d\u0438 \u0432 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-36736","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Verhaal over het probleem van het verplaatsen van docker storage (docker root) | ProHoster","description":"Niet langer dan een paar dagen geleden werd besloten om op een van de servers de docker storage (map waar Docker alle container- en imagebestanden opslaat) naar een aparte partitie te verplaatsen met een grotere capaciteit.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/istoriya-problemy-perenosa-docker-storage-docker-root","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0418\u0441\u0442\u043e\u0440\u0438\u044f \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u044b \u043f\u0435\u0440\u0435\u043d\u043e\u0441\u0430 docker storage (docker root) | ProHoster","og:description":"\u041d\u0435 \u0434\u0430\u043b\u0435\u0435, \u0447\u0435\u043c \u043f\u0430\u0440\u0443 \u0434\u043d\u0435\u0439 \u043d\u0430\u0437\u0430\u0434 \u0431\u044b\u043b\u043e \u0440\u0435\u0448\u0435\u043d\u043e \u043d\u0430 \u043e\u0434\u043d\u043e\u043c \u0438\u0437 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u0432\u044b\u043d\u0435\u0441\u0442\u0438 docker storage (\u043a\u0430\u0442\u0430\u043b\u043e\u0433, \u0433\u0434\u0435 \u0434\u043e\u043a\u0435\u0440 \u0445\u0440\u0430\u043d\u0438\u0442 \u0432\u0441\u0435 \u0444\u0430\u0439\u043b\u044b \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432, \u043e\u0431\u0440\u0430\u0437\u043e\u0432) \u043d\u0430 \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u044b\u0439 \u0440\u0430\u0437\u0434\u0435\u043b, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u043e\u0431\u043b\u0430\u0434\u0430\u043b \u0431\u043e\u043b\u044c\u0448\u0435\u0439 \u0435\u043c\u043a\u043e\u0441\u0442\u044c\u044e.","og:url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/istoriya-problemy-perenosa-docker-storage-docker-root","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:13:26+00:00","article:modified_time":"2019-10-31T19:13:26+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"36736","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-22 04:38:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:39:24","updated":"2026-01-22 04:38:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/36736","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=36736"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/36736\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=36736"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=36736"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=36736"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}