Jaki jest właściwy sposób konfiguracji środowiska programistycznego na OS X z Dockerem?

94

Intro

Nie mogę znaleźć dobrego sposobu na skonfigurowanie środowiska programistycznego na OS X przy użyciu Dockera i Boot2Dockera. Problem, który napotykam, polega na tym, jak zarządzać kodem źródłowym, aby:

  1. Mogę modyfikować kod na OS X używając narzędzi (edytor tekstu, IDE, git itp.), Które już zainstalowałem.
  2. Te modyfikacje są odzwierciedlane w kontenerze Docker, więc jeśli ponownie uruchomię testy lub odświeżę stronę internetową, mogę natychmiast zobaczyć swoje zmiany.

W teorii powinno to być łatwe do zrobienia, montując mój kod źródłowy jako wolumin:

docker run -it -v /path/to/my/source/code:/src some-docker-image

Niestety ma to dwa główne problemy, które sprawiają, że jest całkowicie bezużyteczny w systemie OS X:

Problem nr 1: Zamontowane woluminy w VirtualBox (które używają vboxsf) są bardzo wolne

Na przykład, oto ile czasu zajmuje Jekyll skompilowanie mojej strony głównej, jeśli kod źródłowy jest częścią obrazu Dockera:

> docker run -it brikis98/yevgeniy-brikman-homepage:v1 bash

root@7aaea30d98a1:/src# time bundle exec jekyll build

[...]

real    0m7.879s
user    0m7.360s
sys     0m0.600s

Oto dokładnie ten sam obraz Dockera, z wyjątkiem tego, że montuję kod źródłowy z OS X:

> docker run -it -v $(pwd):/src brikis98/yevgeniy-brikman-homepage:v1 bash

root@1521b0b4ce6a:/src# time bundle exec jekyll build

[...]

real    1m14.701s
user    0m9.450s
sys     0m3.410s

Kwestia # 2: Oglądanie plików jest zepsute

Domyślne mechanizmy nadzoru w SBT, Jekyll i grunt używają technologii, takich jak inotify, które nie działają, jeśli działają w kontenerze Docker, a zmiany są wprowadzane w systemie OS X do zamontowanego folderu.

Rozwiązania, które próbowałem

Szukałem rozwiązań (w tym wszystkich na SO) i wypróbowałem kilka z nich, ale nie znalazłem udanego:

  1. I przełączane Boot2Docker używać NFS , ale to było tak powolny.
  2. Wypróbowałem Vagrant + NFS i było to równie powolne.
  3. Wypróbowałem wierzchowca Samby , ale folder zawsze był pusty w kontenerze Dockera.
  4. Próbowałem użyć systemu plików Unison , który działał przez chwilę, aby zsynchronizować pliki, ale potem wyświetlał błędy połączenia .
  5. Włączyłem odpytywanie w Jekyll , ale to znacznie zwiększyło opóźnienie, zanim moje zmiany zostaną odebrane.
  6. Wypróbowałem Dinghy , „szybszy, bardziej przyjazny Docker na OS X z Vagrantem” i uzyskałem pewną poprawę. Kompilacja Jekyll nie była 10-15x wolniejsza, ale 2-3 razy wolniejsza. Tak jest lepiej, ale nadal nie do końca nadaje się do użytku.

Czy ktoś znalazł rozwiązanie, które faktycznie działa i pozwala produktywnie tworzyć kod za pomocą Dockera i OS X?

Aktualizacja: w końcu rozwiązanie!

W końcu znalazłem rozwiązanie, które wydaje się produktywne przy użyciu Boot2Docker + rsync. Uchwyciłem szczegóły, jak to ustawić, w mojej własnej odpowiedzi, a także w projekcie open source o nazwie docker-osx-dev .

Yevgeniy Brikman
źródło
Próbowałeś oficjalnego instalatora Dockera dla OS X razem z NFS? AFAIK nie jest to problem ograniczony do Dockera na OS X, ale także rozwój oparty na Vagrant w systemie OS X z większą bazą kodów ( mamy podobny problem, ale z Vagrantem ). Uważam, że NFS jest jedynym realnym i akceptowalnym rozwiązaniem.
James Mills
@JamesMills: Postępowałem zgodnie z oficjalnymi instrukcjami, aby zainstalować Docker i Boot2Docker. Czy istnieją oficjalne instrukcje dotyczące konfigurowania NFS? Znalazłem je tylko w streszczeniu GitHub, a po ich użyciu nie wydawało się szybsze. Jak skonfigurowałeś NFS?
Yevgeniy Brikman
Czy widziałeś github.com/boot2docker/boot2docker/issues/64 ?
James Mills
6
Właściwym sposobem pracy z Dockerem jest natywne uruchamianie Linuksa zamiast OS X lub wykonywanie wszystkich prac programistycznych na maszynie wirtualnej z systemem Linux. Integracja „boot2docker” to wielki brzydki hack, który nie robi nic poza siejeniem zamieszania i rozczarowania.
larsks
7
@larsks: To nie jest pomocne.
Yevgeniy Brikman

Odpowiedzi:

46

Postanowiłem dodać własną odpowiedź z najlepszym rozwiązaniem, jakie do tej pory znalazłem. Zaktualizuję to, jeśli znajdę lepsze opcje.

Jak dotąd najlepsze rozwiązanie

Najlepszym rozwiązaniem, jakie znalazłem do skonfigurowania produktywnego środowiska programistycznego z Dockerem na OS X, jest: Boot2Docker + Rsync . Dzięki rsync czasy kompilacji w kontenerze Dockera są takie same, jak uruchamianie kompilacji bezpośrednio w systemie OSX! Co więcej, kod obserwatora plików to robi nie wymaga odpytywania ( inotifydziała, ponieważ rsync używa normalnych folderów), więc ponowne ładowanie na gorąco jest prawie tak samo szybkie.

Istnieją dwa sposoby konfiguracji: instalacja automatyczna i instalacja ręczna.

Instalacja automatyczna

Spakowałem wszystkie kroki konfiguracji Boot2Docker z Rsync do projektu open source o nazwie docker-osx-dev . Kod jest nieco szorstki, ale z powodzeniem używam go przez kilka tygodni, aby łatwo przełączać się między 3 projektami z 3 różnymi stosami technologii. Wypróbuj, zgłoś błędy i prześlij kilka PR! Zobacz także mój wpis na blogu, Produktywne środowisko programistyczne z Dockerem w systemie OS X, aby uzyskać więcej informacji.

Manualna instalacja

  1. Zainstalować Boot2Docker : brew install boot2docker.
  2. Run Boot2Docker, ale z VirtualBox udostępnione foldery wyłączone: boot2docker init && boot2docker start --vbox-share=disable.
  3. Uruchom boot2docker shelliniti skopiuj zmienne środowiskowe, które drukuje, do ~/.bash_profilepliku.
  4. Zainstalować rsync na Boot2Docker VM: boot2docker ssh "tce-load -wi rsync".
  5. Utwórz potrzebne foldery podstawowe na maszynie wirtualnej Boot2Docker i ustaw poprawnie uprawnienia do nich. Na przykład, jeśli będziesz synchronizować /foo/barfolder z OS X, musisz utworzyć/foo/bar na Boot2Docker VM: boot2docker ssh "mkdir -p /foo/bar && chown -R docker /foo/bar".
  6. Uruchomić rsync, aby zsynchronizować pliki do Boot2Docker VM: rsync --archive --rsh="ssh -i $HOME/.ssh/id_boot2docker -o StrictHostKeyChecking=no" /foo/bar docker@dockerhost:/foo. Sprawdź dokumenty rsync pod kątem różnych ustawień, które możesz chcieć włączyć, takich jak użycie --exclude .gitdo wykluczenia.git folderu podczas synchronizacji.
  7. Użyj obserwatora plików, aby zsynchronizować pliki. Na przykład możesz użyć fswatch (brew install fswatch ) przesłanego potokiem do rsync.
  8. W tym momencie powinieneś być w stanie docker runuruchomić kontener Docker i użyć -vflagi, aby zamontować synchronizowany folder:docker run -v /foo/bar:/src some-docker-image .
  9. Zaktualizuj kod w systemie OS X jak zwykle. Zmiany powinny być propagowane bardzo szybko przy użyciu rsync, normalny kod obserwatora plików powinien wychwycić zmiany w zwykły sposób (tj. Przy użyciu inotify), a kompilacja powinna przebiegać szybko, ponieważ wszystkie pliki są „lokalne” w kontenerze.
  10. Jeśli chcesz przetestować działającą witrynę internetową, uruchom boot2docker ippolecenie, aby dowiedzieć się, na jakim adresie IP się ona znajduje.
Yevgeniy Brikman
źródło
Dzięki za udostępnienie! Kiedy mówią, że rsync działa „tylko w jedną stronę”, czy oznacza to, że nie mogę używać systemu plików OS X do udostępniania plików między dwoma kontenerami? Przykład: kontener 1 obserwuje pliki źródłowe i kompiluje plik binarny, kontener 2 jest używany do uruchamiania skompilowanego pliku binarnego (w tym przykładzie przy użyciu Haskella).
Nicolas Hery
1
@NicolasHery: Rozumiem, że rsync skopiuje zmiany z OS X do kontenera Docker, ale nie odwrotnie. Dlatego żadne pliki wygenerowane przez kontener Docker (np. Skompilowany plik binarny) nie będą widoczne w systemie OS X. Jeśli jednak te pliki zostaną wygenerowane w folderze oznaczonym jako a VOLUME, możesz dać innemu kontenerowi dostęp do tego woluminu za pomocą --volumes-fromflaga. Jeszcze tego nie próbowałem, ale podejrzewam, że to zadziała.
Yevgeniy Brikman
1
Świetna odpowiedź. Mógłbyś stworzyć sterownik dla docker -machine ( github.com/docker/machine ), który wykonuje większość standardowych zadań za Ciebie.
dom
1
@dom: Podoba mi się ten pomysł, ale czy wiesz, jak stworzyć sterownik dla docker-machine? Czy żądanie ściągnięcia do repozytorium jest jedynym sposobem, czy też można utworzyć sterownik zewnętrznie?
Yevgeniy Brikman
1
Czy ten samouczek jest nadal ważny dla nowej wersji 1.9.1 w systemie Windows? Czy mogę go użyć, czy może Docker miał już nowe rozwiązanie tego „problemu”?
18

Aktualizacja : Teraz, gdy Docker dla Maca jest w wersji beta z funkcjonalnością niezwiązaną z hackowaniem, pójście tą drogą może być o wiele bardziej rozsądne w przypadku lokalnego rozwoju bez hacków i obejść eseju.

Nie . Wiem, że to nie jest odpowiedź, na którą prawdopodobnie liczysz, ale weź uczciwą ocenę kosztów / korzyści próby uzyskania lokalnego kodu źródłowego + dokeryzowanego wykonywania, a nie tylko lokalnego programowania na OSX.

W pewnym momencie wszystkie problemy, wysiłek związany z konfiguracją i problemy operacyjne MOGĄ zostać rozwiązane wystarczająco dobrze, ale w tej chwili uważam, że to strata netto.

Problem 1: Zamontowane woluminy w Virtual Box (które używają vboxfs) są bardzo wolne

Poczekaj chwilę, a to prawie na pewno się poprawi.

Kwestia # 2: Oglądanie plików jest zepsute

Nie jestem pewien, czy można to naprawić w najbliższej przyszłości. Jeśli tego typu funkcjonalność jest kluczowa dla Twojego przepływu pracy, uznałbym to za przełamanie transakcji. Nie jest to warte większego wysiłku badawczo-rozwojowego w porównaniu do zwykłego używania rbenv / bundler do zarządzania instalacjami jekyll / ruby ​​i uruchamiania ich lokalnie na OSX, tak jak ludzie z powodzeniem robili przez ostatnią dekadę +.

Tak jak „chmura” nie angażuje się w moje lokalne ustawienia programistyczne, w tej chwili docker jest zwycięzcą w zakresie testowania / przemieszczania / wdrażania oraz uruchamiania baz danych i innych komponentów stron trzecich, ale aplikacje, które faktycznie koduję, działają od razu na OSX.

Peter Lyons
źródło
1
Popieram to. Tworzymy na OSX i uruchamiamy aplikacje bezpośrednio w systemie (z przeładowaniem na żywo itp.). Następnie, gdy aplikacja jest gotowa, dokeryzujemy ją do testowania, przemieszczania i produkcji.
PaleAle
4
Hm, to trochę zawiedzione. Zawsze miałem parytet w moich środowiskach przejściowych / produkcyjnych. To programista, który zawsze był odstający, ponieważ koduję na OS X. Dokumentacja Dockera z pewnością sprawiła, że ​​brzmiało to tak, jakby to był rozwiązany problem. Dam kolejny dzień wysiłku i zobaczę, czy coś mi się uda.
Yevgeniy Brikman
Czy nadal uważasz tę odpowiedź za aktualną dzisiaj, Piotrze? Zaledwie kilka miesięcy później, ale biorąc pod uwagę projekt @ Yevgeniy i tylko 2 problemy, które zostały już naprawione, być może koszt / zysk jest już warty! Prawda?
cregox
1
To kwestia osobistych preferencji. Nadal nie zadzierałbym z tym ze względu na ogromną liczbę projektów, między którymi przeskakuję jako konsultant. Gdybym był pełnoetatowym pracownikiem pracującym głównie nad tym samym projektem przez tygodnie / miesiące, warto byłoby ustawić rsync / fswatch.
Peter Lyons
Docker Toolbox jest obecnie właściwym sposobem, aby sobie z tym poradzić, ponieważ jeśli używasz homebrew lub innego menedżera pakietów, wersje narzędzia docker wyjdą z synchronizacji, chyba że będą postępować zgodnie z wersjami jako przybornik docker.
taco
12

Docker dla Mac i Windows będzie ostatecznym sposobem programowania z Dockerem na OS X (i Windows). Oprogramowanie Docker to „zintegrowane, łatwe do wdrożenia środowisko do tworzenia, składania i wysyłania aplikacji z komputerów Mac lub Windows”. Ma rzekomo być w stanie rozwiązać problemy przedstawione przez PO. Od ogłoszenia z 24 marca 2016 r . :

  • Szybszy i bardziej niezawodny: koniec z VirtualBox! Silnik Dockera działa w dystrybucji Alpine Linux na maszynie wirtualnej xhyve w systemie Mac OS X lub na maszynie wirtualnej Hyper-V w systemie Windows, a ta maszyna wirtualna jest zarządzana przez aplikację Docker. Nie potrzebujesz docker-machine, aby uruchomić Docker dla komputerów Mac i Windows.
  • Integracja narzędzi: Docker dla komputerów Mac to aplikacja dla komputerów Mac, a Docker dla systemu Windows to aplikacja systemu Windows, zawierająca natywny interfejs użytkownika i możliwość automatycznej aktualizacji. Zestaw narzędzi Docker jest dostarczany w pakiecie: wiersz poleceń Docker, Docker Compose i wiersz poleceń Docker Notary.
  • Montowanie wolumenu dla twojego kodu i danych: dostęp do danych woluminu działa poprawnie, w tym powiadomienia o zmianie plików (na Macu inotify działa teraz bezproblemowo w kontenerach dla katalogów zamontowanych na woluminach). Umożliwia to cykle edycji / testowania dla rozwoju „w kontenerze”.
  • Łatwy dostęp do działających kontenerów w lokalnej sieci hosta: Docker dla komputerów Mac i Windows zawiera serwer DNS dla kontenerów i są zintegrowane z systemem sieciowym Mac OS X i Windows. Na komputerze Mac Docker może być używany nawet po połączeniu z bardzo restrykcyjną korporacyjną siecią VPN.
  • Docker for Mac został zaprojektowany od podstaw, aby był w stanie dopasować się do modelu bezpieczeństwa piaskownicy OS X i ściśle współpracujemy z Apple, aby to osiągnąć.
Quinn Comendant
źródło
Widziałem to niedawno i wygląda na to, że jest to zdecydowanie najbardziej obiecujące rozwiązanie. Jestem bardzo podekscytowany, że mogę dać mu szansę, gdy wyjdzie z wersji beta, a jeśli będzie dobrze działać, zmienię ją na oficjalnie zaakceptowaną odpowiedź.
Yevgeniy Brikman
4
Niestety obecna wersja beta (1.11.0-beta7) wydaje się być tak samo wolna jak inne metody, więc może minąć trochę czasu, zanim będzie to możliwe, aby użyć forums.docker.com/t/ ...
walterra
3

Zastrzeżenie: Mogę być stronniczy, ponieważ jestem autorem docker-sync.

Prawdopodobnie wypróbowałem wszystkie wymienione tutaj rozwiązania, w tym kilka innych (patrz kompilacja https://github.com/EugenMayer/docker-sync/wiki/Alternatives-to-docker-sync ), ale w zasadzie albo zawiodły po stronie wydajność (większość z nich) lub na maszynie dokującej (lub żadna) używana / wymuszona.

http://docker-sync.io został zbudowany, aby połączyć wszystkie rozwiązania i zapewnić najlepsze strategie (wdrażając kilka, możesz wybrać).

Może być używany z rsync (synchronizacja jednokierunkowa), w tym poprawki uprawnień dla użytkowników, oraz z unison (synchronizacja dwukierunkowa). Nie zmusza cię to do dokowania maszyny lub określonego hiperwizora, ani nie wymaga posiadania dockera dla Maca. Działa z każdym z nich.

Wydajność EugenMayer / docker-sync / wiki / 4.-Performance nie ma wpływu, to tak, jakbyś nie miał żadnych udziałów.

docker-sync i jego obserwatory zmian są zoptymalizowane i bezproblemowo pracują z projektami z plikami 12k.

Spróbuj, jeśli chcesz, z chęcią poznam Twoją opinię!

Eugen Mayer
źródło
2

Czuję Cię! Myślę, że próbowałem prawie wszystkiego, czego próbowałeś i niestety nadal było to powolne. Potem natknąłem się na ten komentarz https://github.com/boot2docker/boot2docker/issues/64#issuecomment-70689254, który sugeruje użycie Vagrant i Parallels zamiast Virtualbox. Pozwoliło mi to na użycie nfs i rzeczywiście zauważyłem duży wzrost wydajności mojego projektu (Drupal).

Oto plik Vagranta. Wszystko, co musisz zrobić, to zainstalować vagrant, skopiować to do pliku o nazwie Vagrantfile i umieścić w jakimś folderze. Przejdź do tego folderu i po prostu zrób vagrant upzamiast normalnego boot2dockera.

Vagrant.configure(2) do |config|
  config.vm.box = "parallels/boot2docker"

  config.vm.network "forwarded_port", guest: 80, host: 80

  config.vm.synced_folder(
    "/Users/dicix/work/www", "/vagrant",
    type: 'nfs',
    nfs_udp: true,
    mount_options: %w[actimeo=2],
    bsd__nfs_options: %w[alldirs maproot=root:wheel]
  )
end
Alex Dicianu
źródło
Zakładam, że wymaga to instalacji równoległej?
Yevgeniy Brikman
2

Używam również Vagrant z paralelami i boot2dockerem ( https://github.com/Parallels/boot2docker-vagrant-box ). Rozwój nigdy nie był dla mnie łatwiejszy. Działa naprawdę dobrze z docker-composedużymi konfiguracjami. Naprawdę nie odczuwam opóźnienia ani ogromnego zużycia zasobów.

Tak Vagrantfilewygląda mój wygląd:

Vagrant.configure(2) do |config|

  config.vm.network "private_network", ip: "192.168.33.10"
  config.vm.box = "parallels/boot2docker"

  config.vm.synced_folder "/Users", "/Users", type: "nfs", mount_options: ["nolock", "vers=3", "udp"], id: "nfs-sync"

end
David Heidrich
źródło
1

Od kilku tygodni pracuję w środowisku OS X (Macbook Air z połowy 2011 r.) + Boot2Docker + Docker-compose. Nie napotkałem poważnych problemów z wydajnością, ale unikam uruchamiania jakiejkolwiek kompilacji podczas programowania (dlaczego nie użyć czegoś takiego jekyll serve --skip-initial-build?). Oto przykładowy docker-compose.ymlplik, którego używam:

docker-compose.yml:

test:
  build: .
  volumes:
    - ./client:/src/client
    - ./server:/src/server
    - ./test:/src/test
  command: nodemon --exec jasmine-node -- test/ --verbose --autotest --captureExceptions --color
  environment:
    - DEBUG=*

Dockerfile:

FROM node:0.12

RUN mkdir -p /src
WORKDIR /src

ENV PATH=/src/node_modules/.bin:$PATH

# We add package.json first so that we the
# image build can use the cache as long as the
# contents of package.json hasn't changed.

COPY package.json /src/
RUN npm install --unsafe-perm

COPY . /src

CMD [ "npm", "start" ]
EXPOSE 3000

Czasami używam NFS ( http://syskall.com/using-boot2docker-using-nfs-instead-of-vboxsf/ ), ale nie zauważyłem dużej różnicy w wydajności.

Dla mnie wygoda prostego docker-compose up test uruchomienia mojego środowiska była warta swojej wydajności (rutynowo pracuję nad wieloma projektami z różnymi stosami).

PS: nodemonjest jednym z niewielu obserwatorów plików, który współpracuje z vboxsf (patrz https://github.com/remy/nodemon/issues/419 ).

Olivier Lalonde
źródło
Nawet jeśli pominę początkową kompilację z Jekyllem, za każdym razem, gdy zmienię plik, będzie on musiał się przebudować, co nadal trwa około 1-3 minut, jeśli kod źródłowy jest zamontowany. To sprawia, że ​​niemożliwe jest dokonywanie zmian i przeładowań.
Yevgeniy Brikman
@YevgeniyBrikman Och, nie byłem tego świadomy :( Myślę, że ostatnią opcją byłoby umieszczenie kodu w maszynie wirtualnej boot2docker i zamontowanie go na maszynie hosta za pomocą sshfs. W przeciwnym razie myślę, że będziesz musiał poczekać lepsza wydajność zamontowanego folderu w celu użycia dockera jako środowiska deweloperskiego.
Olivier Lalonde
-1

Uruchomienie dockera jako narzędzia programistycznego jest możliwe. Ale to będzie bolało. Udokumentowałem ten proces tutaj:

http://harmingcola.blogspot.com/2015/05/how-to-setup-docker-as-development-tool.html

harmingcola
źródło
Dziękujemy za wysłanie, ale jak to rozwiązuje problemy z wydajnością z zamontowanymi woluminami?
Yevgeniy Brikman
Ach, przepraszam, nie musisz już używać vBox do montowania czegokolwiek. Możesz montować foldery za pomocą zwykłego interfejsu
dockera
-4

Ta metoda jest najnowszym (wrzesień 2015 r.) I najłatwiejszym sposobem na uzyskanie konfiguracji Dockera na komputerze Mac: łącze tutaj:

Instalujesz Docker za pomocą linku Docker Toolbox do instrukcji tutaj:

Jest to kompletny pakiet instalacyjny Dockera, platformy Docker który zawiera następujące narzędzia platformy Docker:

Docker Machine do uruchamiania pliku binarnego docker-machine

Docker Engine do uruchamiania pliku binarnego Docker

Docker Compose do uruchamiania pliku binarnego Docker-Compose

Kitematic, graficzny interfejs użytkownika platformy Docker, powłoka wstępnie skonfigurowana dla środowiska wiersza polecenia Dockera

Oracle VM VirtualBox

wprowadź opis obrazu tutaj

Co znajduje się w zestawie narzędzi:

  • Klient platformy Docker
  • Maszyna Docker
  • Docker Compose (tylko Mac)
  • Docker Kitematic
  • VirtualBox
rootcript
źródło
3
Tak, ale niestety nie rozwiązało to pierwotnie przedstawionego problemu.
Nick