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 .

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.

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.

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ąć.

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ę!

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

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

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 ).

Docker Unison działa jak marzenie! https://github.com/leighmcculloch/docker-unison

Dwukierunkowa synchronizacja z bardzo dobrą wydajnością!

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

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

Co znajduje się w zestawie narzędzi:

• Klient platformy Docker
• Maszyna Docker
• Docker Compose (tylko Mac)
• Docker Kitematic
• VirtualBox