web-dev-qa-db-ja.com

OS XでDockerを使用して開発環境をセットアップする正しい方法は何ですか？

イントロ

DockerとBoot2Dockerを使用してOS Xで開発環境をセットアップする良い方法がわかりません。私が当たっている問題は、ソースコードをどのように管理するかです：

  1. OS Xのコードは、既にインストールしたツール（テキストエディター、IDE、gitなど）を使用して変更できます。
  2. これらの変更はDockerコンテナに反映されるため、テストを再実行するかWebページを更新すると、変更をすぐに確認できます。

理論的には、これはソースコードをボリュームとしてマウントすることで簡単に実行できるはずです。

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

残念ながら、これにはOS Xで完全に使用できなくなる2つの大きな問題があります。

問題＃1：VirtualBox（vboxsfを使用）にマウントされたボリュームが非常に遅い

たとえば、ソースコードがDockerイメージの一部である場合、Jekyllが homepage をコンパイルするのにかかる時間は次のとおりです。

> 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

これはまったく同じDockerイメージですが、今回は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

問題＃2：ファイルの監視が壊れている

SBT、Jekyll、およびgruntのデフォルトの監視メカニズムは、inotifyなどのテクノロジーを使用します。これらは、Dockerコンテナーで実行され、OS Xでマウントされたフォルダーに変更が加えられると機能しません。

私が試した回避策

ソリューション（SO上のすべてを含む）を検索し、それらのいくつかを試してみましたが、成功したものは見つかりませんでした。

  1. I NFSを使用するようにBoot2Dockerを切り替えました ですが、それは同じくらい遅かったです。
  2. Vagrant + NFS を試しましたが、それも同じくらい遅かったです。
  3. Sambaマウント を試しましたが、Dockerコンテナー内のフォルダーは常に空で表示されました。
  4. nisonファイルシステム を使用しようとしましたが、これはファイルを同期するために簡単に機能しましたが、 接続エラーを表示 を維持しました。
  5. Jekyllでのポーリング を有効にしましたが、変更が反映されるまで遅延が大幅に増加しました。
  6. Dinghy 、「Vagrantを使用したOS Xでのより高速で友好的なDocker」を試し、someの改善を得ました。 Jekyllのコンパイルが10〜15倍遅くなる代わりに、2〜3倍遅くなりました。それは良いですが、それでもまだ使い物になりません。

DockerとOS Xでコードを生産的に開発し、実際に機能するソリューションを見つけた人はいますか？

更新：ついに解決策！

最終的に、Boot2Docker + rsyncを使用することで生産性が高いと思われるソリューションを見つけました。 my own answer と docker-osx-dev と呼ばれるオープンソースプロジェクトでこれを設定する方法の詳細をキャプチャしました。

macosdockerdevelopment-environmentboot2docker
93
Yevgeniy Brikman

私はこれまでに見つけた最良の解決策に自分の答えを追加することにしました。より良いオプションが見つかったら、これを更新します。

これまでのベストソリューション

OS XでDockerを使用して生産的な開発環境をセットアップするために見つけた最良のソリューションは、Boot2Docker + Rsyncです。 rsyncを使用すると、Dockerコンテナでのビルド時間は、OSXで直接ビルドを実行した場合と同等です。さらに、File Watcherコードはnotポーリングを必要としません（inotifyはrsyncが通常のフォルダーを使用するため機能します）。したがって、ホットリロードはalmost速い。

セットアップには、自動インストールと手動インストールの2つの方法があります。

自動インストール

R2でBoot2Dockerをセットアップするためのすべてのステップを、 docker-osx-dev と呼ばれるオープンソースプロジェクトにパッケージ化しました。コードは少し荒いですが、3種類の異なる技術スタックを持つ3つのプロジェクト間を簡単に切り替えるために、数週間にわたって正常に使用しています。それを試して、バグを報告し、いくつかのPRを提出してください！また、私のブログ投稿 OS XでのDockerを使用した生産的な開発環境 を参照してください。

手動設定

  1. インストール Boot2Docker ：brew install boot2docker。
  2. Boot2Dockerを実行しますが、VirtualBox共有フォルダーが無効になっています：boot2docker init && boot2docker start --vbox-share=disable。
  3. boot2docker shellinitを実行し、印刷される環境変数を~/.bash_profileファイルにコピーします。
  4. Boot2Docker VMにrsyncをインストールします：boot2docker ssh "tce-load -wi rsync"。
  5. Boot2Dockerに必要なベースフォルダーを作成しますVM=そして、それらのアクセス許可を正しく設定します。たとえば、OS Xから/foo/barフォルダーを同期する場合、作成する必要があります/foo/bar Boot2Docker VMの場合：boot2docker ssh "mkdir -p /foo/bar && chown -R docker /foo/bar"。
  6. Rsyncを実行して、ファイルをBoot2Docker VMに同期します：rsync --archive --rsh="ssh -i $HOME/.ssh/id_boot2docker -o StrictHostKeyChecking=no" /foo/bar docker@dockerhost:/foo。同期時に--exclude .gitフォルダーを除外するために.gitを使用するなど、有効にすることができるさまざまな設定については、rsyncのドキュメントを確認してください。
  7. ファイルウォッチャーを使用して、ファイルの同期を維持します。たとえば、rsyncにパイプされる fswatch （brew install fswatch）を使用できます。
  8. この時点で、docker runを使用してDockerコンテナーを起動し、-vフラグを使用して、同期しているフォルダーをマウントできます：docker run -v /foo/bar:/src some-docker-image。
  9. 通常どおり、OS Xでコードを更新します。変更はrsyncを使用して非常に迅速に伝播し、通常のFile Watcherコードは通常どおり（つまり、inotifyを使用して）変更を取得し、すべてのファイルがコンテナに対して「ローカル」であるためビルドを高速に実行する必要があります。
  10. 実行中のWebサイトをテストする必要がある場合は、boot2docker ipコマンドを実行して、どのIP上にあるかを確認してください。
46
Yevgeniy Brikman

Update：現在、 mac用のdocker は非ハック機能を備えたベータ版であるため、そのルートを使用する方がはるかに合理的ですエッセイのようなハッキングや回避策のないローカル開発向け。

しないでください。私はそれがあなたがおそらく望んでいる答えではないことを知っていますが、OSXでローカル開発を行うのではなく、ローカルソースコード+ Docker化された実行を取得することのコスト/メリットを正直に評価してください。

ある時点で、すべての問題、セットアップの労力、および運用上の問題点が十分に解決される可能性がありますが、現時点での私の考えでは、これは純損失です。

問題＃1：Virtual Box（vboxfsを使用）にマウントされたボリュームが非常に遅い

しばらく待つと、ほぼ確実に改善されます。

問題＃2：ファイルの監視が壊れている

これに対する修正が近い将来にあるかどうかはわかりません。このタイプの機能が開発ワークフローの鍵である場合、私はこれを取り壊しと見なします。 rbenv/bundlerを使用してjekyll/Rubyのインストールを管理し、OSXでローカルに実行するのに比べて、過去10年以上にわたって成功しているのと比較すると、大きなR＆D努力の価値はありません。

「クラウド」が私のローカル開発のセットアップに関与していないように、現時点では、Dockerはテスト/ステージング/展開、およびデータベースや他のサードパーティコンポーネントの実行に適していますが、実際にコーディングしているアプリケーションはまっすぐに実行されますOSXで。

18
Peter Lyons

MacおよびWindows用のDockerは、OS X（およびWindows）でDockerを使用して開発する決定的な方法です）。 Docker製品であるこのソフトウェアは、「MacまたはWindowsからアプリケーションを構築、アセンブル、および出荷するための統合された展開しやすい環境」です。OPが提示する問題を解決できるとされています。 2016年3月24日発表 ：

  • より高速で信頼性の高い：VirtualBoxはもう必要ありません！ Dockerエンジンは、Mac OS X上のxhyve仮想マシン上またはWindows上のHyper-V VM上のAlpine Linuxディストリビューションで実行され、そのVMはDockerアプリケーションによって管理されます。 MacおよびWindows用のDockerを実行するのにdocker-machineは必要ありません。
  • ツールの統合：Docker for MacはMacアプリケーションであり、Docker for Windowsはネイティブユーザーインターフェイスと自動更新機能を含むWindowsアプリケーションです。 Dockerツールセットには、Dockerコマンドライン、Docker Compose、およびDocker Notaryコマンドラインがバンドルされています。
  • コードとデータのボリュームマウント：ファイル変更通知を含むボリュームデータアクセスが正しく機能します（Macでは、マウントされたディレクトリのコンテナー内でinotifyがシームレスに機能するようになりました）。これにより、「コンテナ内」開発の編集/テストサイクルが可能になります。
  • ローカルホストネットワークで実行中のコンテナーに簡単にアクセス：Docker for MacおよびWindowsにはコンテナー用のDNSサーバーが含まれており、Mac OS XおよびWindowsネットワークシステムと統合されています。 Macでは、非常に制限の厳しい企業VPNに接続されている場合でも、Dockerを使用できます。
  • Mac用Dockerは、OS Xサンドボックスセキュリティモデルに適合するようにゼロから設計されており、これを実現するためにAppleと緊密に協力しています。
12
Quinn Comendant

免責事項：私はdocker-syncの作者なので、偏見があるかもしれません。

私はおそらくここを含むすべてのソリューションを試してみましたが、さらにいくつかを比較します（比較を参照してください https://github.com/EugenMayer/docker-sync/wiki/Alternatives-to-docker-sync ）基本的には、パフォーマンスの側面（ほとんどの場合）またはドッカーマシン（またはなし）で使用/強制が失敗しました。

http://docker-sync.io は、すべてのソリューションをマージし、最良の戦略を提供するために構築されています（いくつか実装し、選択できます）。

ユーザーのアクセス許可の修正を含むrsync（1方向同期）およびunison（2方向同期）で使用できます。強制的にdocker-machineや特定のハイパーバイザーを使用したり、Mac用のdockerを用意する必要はありません。それらのすべてで動作します。

EugenMayer/docker-sync/wiki/4のパフォーマンスは影響を受けません。まったく共有されていないようです。

docker-syncとそのchange-watcherは最適化されており、問題なく12kファイルのプロジェクトで動作します。

あなたが好きなら、それを試してみてください、私はフィードバックを聞きたいです！

3
Eugen Mayer

VagrantとParallelsおよびboot2dockerも使用しています（ https://github.com/Parallels/boot2docker-vagrant-box ）。私にとって開発は決して簡単ではありませんでした。 docker-composeおよび大規模なセットアップ。遅延や大量のリソース消費はあまり感じません。

これは私のVagrantfileのようです：

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
2
David Heidrich

君の気持ち、分かるよ！私はあなたが試したことのほとんどすべてを試しましたが、残念ながらまだ遅いと思います。次に、このコメントに出会いました https://github.com/boot2docker/boot2docker/issues/64#issuecomment-70689254 これは、Virtualboxの代わりにVagrantとParallelsを使用することを示唆しています。これにより、nfsを使用できるようになり、実際に私のプロジェクト（Drupal）のパフォーマンスが大幅に向上しました。

Vagrantファイルは次のとおりです。必要なのは、vagrantをインストールし、これをVagrantfileというファイルにコピーして、いくつかのフォルダーに入れることだけです。そのフォルダーに移動して、vagrant up通常のboot2dockerの代わりに。

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
2
Alex Dicianu

OS X（2011年中期Macbook Air）+ Boot2Docker + Docker-compose環境で数週間開発を続けてきました。重大なパフォーマンスの問題に遭遇したことはありませんが、開発中にビルドを実行することは避けます（なぜjekyll serve --skip-initial-build？）。次に例を示しますdocker-compose.yml使用しているファイル：

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

私は時々NFSを使用します（ http://syskall.com/using-boot2docker-using-nfs-instead-of-vboxsf/ ）が、そうするときの大きなパフォーマンスの違いに気付いていません。

私にとっては、シンプルなdocker-compose up test環境を稼働させるには、パフォーマンスのコストに見合うだけの価値があります（スタックが異なる複数のプロジェクトで日常的に作業しています）。

PS：nodemonは、vboxsfで動作する数少ないファイル監視ツールの1つです（ https://github.com/remy/nodemon/issues/419 を参照）。

1
Olivier Lalonde

Docker Unisonは魅力のように機能します！ https://github.com/leighmcculloch/docker-unison

非常に優れたパフォーマンスの双方向同期！

0
smith64fx