Oké, er zijn een paar punten die hier moeten worden aangepakt.
Laten we beginnen met wat een docker-volume is (probeer op dit moment niet aan uw macbook of de zwervende machine te denken. Houd er rekening mee dat de dockers een ander bestandssysteem gebruiken, waar het zich op dit moment ook bevindt):het is zo, op zichzelf is elk volume in Docker slechts een deel van het interne bestandssysteem dat Docker gebruikt. De containers kunnen deze volumes gebruiken, alsof het "kleine harde schijven" zijn die door hen kunnen worden gemount en ook tussen hen kunnen worden gedeeld ( of aangekoppeld door twee van hen tegelijk, zoals het koppelen van een supersnelle versie van een of andere ftp-server aan twee clients of wat dan ook :P ).
In principe kun je deze volumes declareren (denk nog steeds niet aan je computer/vagrant zelf, alleen de dockers;) ) via de VOLUME-instructie van Dockerfile. Standaardvoorbeeld, voer één webservercontainer uit als volgt:
FROM: nginx
VOLUME /www
Nu kan alles wat in /www gaat in theorie worden aan- en ontkoppeld vanuit een container en ook aan meerdere containers. Nu is Nginx alleen saai, dus we willen php laten uitvoeren over de bestanden die nginx opslaat om wat meer leuke inhoud te produceren. => We moeten dat volume in een php-fpm-container mounten. Ergo in ons opstelbestand zouden we dit doen
web:
image: nginx
php:
image: php-fpm
volumes_from:
- web
=> voila! elke map die is gedeclareerd door een VOLUME-richtlijn in de nginx/web-container zal zichtbaar zijn in de php-container. Belangrijk punt om hier op te merken, wat er ook in /www van nginx staat, zal alles overschrijven wat php in /www heeft. Als je de :ro plaatst, kan php niet eens naar die map schrijven :)
Nu we dichter bij uw probleem komen, is er een tweede manier om volumes te declareren, waarvoor ze niet in de Dockerfile hoeven te worden gedeclareerd. Dit kan gedaan worden door volumes van de host te mounten (in dit geval je zwerver/boo2docker-dingetje). Laten we dit bespreken alsof we eerst op een native Linux draaien.
Als je zoiets zou plaatsen als:
volumes:
- /home/myuser/folder:/folder
in uw docker-compose.yml, dan betekent dit dat /home/myuser/folder nu in de docker wordt gemount. Het zal alles overschrijven wat de docker in /folder heeft en net als de /www ook toegankelijk zijn vanuit het ding dat het heeft gedeclareerd. Nu de Linux-machine waarop de docker-daemon draait.
Tot zover de theorie :), in feite heb je waarschijnlijk gewoon het volgende advies nodig om je spullen op gang te krijgen :):
De manier waarop boot2docker/docker-machine/kitematic en al deze dingen met het probleem omgaan, is eenvoudig, dat ze eerst gewoon een volume in de zwervende machine aan de docker-containers koppelen, en ze dit ding gewoon ook in je Mac-bestandssysteem koppelen , in de hoop dat het allemaal goed komt :P
Nu voor het praktische probleem dat we allemaal gebruiken (of gewoon proberen hun collega's te helpen in de wereld van lieve, lieve Docker:P) op Mac, zijn machtigingen. Ik bedoel, denk er eens over na (root of een andere gebruiker verwerkt bestanden in de container, de zwerver van de gebruiker kan bestanden in de zwerver-host afhandelen en dan behandelt je Mac-gebruiker "skalfyfan" die bestanden op Mac. Ze hebben allemaal verschillende gebruikers-ID's en wat dan ook => daar ontstaan veel problemen mee, en enigszins afhankelijk van wat je daadwerkelijk in Docker draait. Vooral Mysql en Apache zijn pijnlijk, omdat ze niet als root in de container draaien. Dit betekent dat ze vaak moeite hebben met het schrijven naar het Mac-bestand systeem.
Voordat u de tweede benadering hieronder probeert, kunt u proberen uw containervolumes onder uw Mac-thuismap te plaatsen. Dit lost in de meeste gevallen problemen met MySQL op, zoals ik in de loop van de tijd heb ontdekt.Btw:Het is niet nodig om volledige paden naar volumes ./folder te declareren. sterk>
Zet gewoon de compose-yml in je Mac-gebruikersmap, dat is het enige dat telt. Geen chmod 777 -R :P zal je hier helpen, het moet gewoon in je thuismap staan :)
Toch zullen sommige apps (Apache bijvoorbeeld) het je nog steeds moeilijk maken. Het feit dat het gebruikers-ID van wat er ook in de container draait, verschilt van je Mac-gebruikers-ID, zal je leven tot een hel maken. Om dit te omzeilen, moet je zowel de gebruikers-ID als de gebruikersgroep aanpassen op een manier die niet in strijd is met de machtigingen van je Mac. De groep die u op een Mac wilt, is personeel, een UID die werkt, is bijvoorbeeld 1000. Daarom zou u dit aan het einde van uw Docker-bestand kunnen plaatsen:
RUN usermod -u 1000 www-data
RUN usermod -G staff www-data
of
RUN usermod -u 1000 mysql
RUN usermod -G staff mysql
Dus zoals je nu hebt geleerd:
Precies, dat doet het :)
Deze heb je bij het verkeerde eind :) Zoals uitgelegd, als je geen hostmap opgeeft, zal Docker dit pad behouden. Maar alleen voor deze container en alles blijft binnen het docker-bestandssysteem. Er wordt helemaal niets naar de gastheer geschreven! Dit gebeurt altijd alleen als je een hostmap voor de containermap geeft!
Ik hoop dat dit heeft geholpen :)