Compose: docker-mac osbetaのdockerで低速で作成する

ping @frenchben ：smile：

+1

同じ問題が発生しました：D

@ smith64fxの問題は、WiFiをオフにすると解消されますか？

@stijnはい、wifiをオフにすると、すべてが魅力のように機能します

Von meinem iPhone gesendet

アム2016年5月5日午前0時26 umのschrieb SebastiaanバンStijn [email protected] ：

@ smith64fxの問題は、WiFiをオフにすると解消されますか？

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください

@ smith64fxあなたの署名から、あなたはドイツ（またはオーストリア/スイス）出身である可能性が高いことがわかります。 あなたのインターネットプロバイダーは何ですか？ 私たちが同じものを持っているかどうか、そしてそれがハードウェア/ソフトウェアの非常に良い部分のように見えず、dockerによって考えられたように機能しない箱から来ているのではないかと思います。

（私はボーダフォンと一緒にいて、イージーボックスを持っています-何でも）

有線ネットワーク（企業ネットワーク）でも同じ問題が発生します。プラグを抜くとすぐにすべてが非常に高速になります。 だから私はそれがあなたの特定のプロバイダーとは関係がないことを確信しています。

詳細な出力を確認しましたが、明らかなエラーはありません（システムログのどこにもありません）。 しかしこれに気づきました：

ネットワークがない場合、これらの回線はグループ化されます。

docker attach <- (u'd90162cbfd7b312c28488a209440641b2d9c9f99e8eb59082f20ddf7d84e7b7e', stderr=True, stream=True, stdout=True)
docker attach -> <generator object _multiplexed_response_stream_helper at 0x1045f20a0>
docker start <- (u'd90162cbfd7b312c28488a209440641b2d9c9f99e8eb59082f20ddf7d84e7b7e')

ネットワークがないと、アタッチ<-とアタッチ->で返される場所の間に「compose.parallel.feed_queue：Pending：set（[]）」が100〜200行表示されます。

この時点より前は、ネットワークでもさらに多くのことが起こっていますが、ほとんどの場合、画像などを検査するための呼び出しが増えているようです。

私はcomposeの出力を添付しました-ボットの状況に合わせて詳細に説明します。 作成ファイルは、ハブから直接2つのコンテナーです。

with-networking.txt
without-networking.txt

@holstvoogdああ、プロバイダーは大丈夫。 情報をありがとう、私は少し心配していました:)

@Erwyn @ smith64fx確認のために、あなたは常に接続されており（有線）、同時にWi-Fiで同じネットワークを使用していますか？

@FrenchBenいいえ、それは私の家のWi-Fiネットワークだけにあります。 私のオフィスでは超高速です。 しかし、問題は、docker-compose ^ _ ^ "を除いて、自宅の他のすべてが高速に実行されることです。

@FrenchBenは@ @holstvoogdは有線接続で同じ問題を抱えているようです。

Docker forMacベータ版でも同じ問題に気づいています。 docker-compose upは、Wi-Fiが有効な場合は低速で、Wi-Fiが無効の場合は高速です。

• Docker Composeバージョン：docker-composeバージョン1.7.1、ビルド0a9ab35
• Dockerバージョン：Dockerバージョン1.11.1、ビルド5604cbe
• OSバージョン：OS X El Capitan 10.11.4

こんにちは、これについて何かニュースはありますか？

同じ問題があります。 Compose / Docker / OSXのバージョンは、 @ eugenesiaと同じです。
私は自宅とオフィスでWiFiを使用していますが、自宅では動作が非常に遅くなっています。 オフィスでは、期待どおりに機能します（高速）。

ISPのDNSサーバーに関連しているのではないかと思い（自宅とオフィスのインターネットプロバイダーが異なります）、Googleのものを含むいくつかのパブリックDNSを使おうとしましたが、役に立ちませんでした。

WiFiをオフにすると、 docker-composeは非常に高速に動作します

@KryDos今週、速度が改善された新しいリリースがリリースされる予定です。

同じ問題があります。Mac1.11.1-beta13用のdockerにアップデートした後も、問題は解決しません。 ネットワークをオフにしてから再度オンにすることによる回避策は機能しなくなり、ネットワークをオフにするとサービスは高速で開始されますが、ネットワークを再びオンにすると、サービスにアクセスできなくなり、Dockerデーモンが応答しなくなります。

docker ps
Error response from daemon: Bad response from Docker engine

• Docker Composeバージョン：docker-composeバージョン1.7.1、ビルド0a9ab35
• Dockerバージョン：Dockerバージョン1.11.1-beta13、ビルド7975
• OSバージョン：OS X El Capitan 10.11.5

同じ問題が発生し、docker-composeがlocalunixsocket.localを解決しようとしていることを示す投稿（申し訳ありませんが、参照を失いました）を見つけました。 sudo tcpdump -A -s0 -nni en0 port 53実行すると、DNSルックアップに関する洞察を得ることができます。

今の私が指摘してきたlocalunixsocket.local私にlocalhostに/etc/hosts 。 今、すべてが再びスピーディーです。

127.0.0.1 localunixsocket.local

ありがとう@jewilmeer 、それは便利に見えます

docker-machineでvirtualboxを使用して切り替えました。 問題は存在せず、Docker MacBetaよりも最大10倍高速です。

@ smith64fxコメントは建設的なものにしてください。 これはベータ版であり、まだ完成品ではないため、バグやパフォーマンスの問題が予想されます。 それらを解決するために報告（およびテスト）が必要なのはまさにこの種の問題です。

超素晴らしいコメント、@ jewilmeer！ 私の場合、 tcpdumpコマンドを使用して発見した/ etc / hostsにさらにいくつかのアドレスを追加する必要がありました。

# (yours)
127.0.0.1 localunixsocket.local
# additional ones -- be sure to replace bracketed thing with the output of `hostname`
127.0.0.1 localunixsocket.home <my hostname>.home

それらの追加の後-スピーディー！ 実際、驚くほど高速で、DockerToolboxを使用する場合よりもかなり高速に見えます。 woop woop：）（それは非常に主観的な観察かもしれませんが！）

それはかなり奇妙ですが、根本的な問題が何であるかを指摘しているようです...

私は現在これと同じ問題に直面しており、問題を解決できません。
/etc/hostsを編集するための以前の提案を試しました。 私たちのオフィスネットワークでは、dockerは非常に遅いです。 ホームネットワークや携帯電話へのテザリングを使用すると、すべての速度低下が解消され、すべてが迅速になります。

4つのサービスコンテナ（postgres、redis、rabbitmq、elasticsearch）にリンクされたWebコンテナでdocker-composeを使用しています。 OSXから直接4つのサービスコンテナのいずれかに接続することは問題ありません。 Webコンテナからいずれかのサービスコンテナに接続しようとすると、速度が低下します。

tcpdump -vvv -s 0 -l -n port 53を実行すると、携帯電話に接続すると次の出力が得られます

tcpdump: data link type PKTAP
tcpdump: listening on pktap, link-type PKTAP (Packet Tap), capture size 262144 bytes
16:54:34.236026 IP (tos 0x0, ttl 64, id 25341, offset 0, flags [none], proto UDP (17), length 69)
    172.20.10.4.56662 > 172.20.10.1.53: [udp sum ok] 5785+ PTR? 1.0.19.172.in-addr.arpa. (41)
16:54:34.239617 IP (tos 0x0, ttl 64, id 29137, offset 0, flags [none], proto UDP (17), length 123)
    172.20.10.1.53 > 172.20.10.4.56662: [udp sum ok] 5785 NXDomain* q: PTR? 1.0.19.172.in-addr.arpa. 0/1/0 ns: 19.172.IN-ADDR.ARPA. [1d] SOA 19.172.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 (95)
16:54:34.303325 IP (tos 0x0, ttl 64, id 46188, offset 0, flags [none], proto UDP (17), length 69)
    172.20.10.4.58590 > 172.20.10.1.53: [udp sum ok] 52066+ PTR? 1.0.19.172.in-addr.arpa. (41)
16:54:34.309241 IP (tos 0x0, ttl 64, id 7329, offset 0, flags [none], proto UDP (17), length 123)
    172.20.10.1.53 > 172.20.10.4.58590: [udp sum ok] 52066 NXDomain* q: PTR? 1.0.19.172.in-addr.arpa. 0/1/0 ns: 19.172.IN-ADDR.ARPA. [1d] SOA 19.172.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 (95)
16:54:39.309028 IP (tos 0x0, ttl 64, id 52570, offset 0, flags [none], proto UDP (17), length 69)
    172.20.10.4.63544 > 172.20.10.1.53: [udp sum ok] 12851+ PTR? 1.0.19.172.in-addr.arpa. (41)
16:54:39.320135 IP (tos 0x0, ttl 64, id 32359, offset 0, flags [none], proto UDP (17), length 123)
    172.20.10.1.53 > 172.20.10.4.63544: [udp sum ok] 12851 NXDomain* q: PTR? 1.0.19.172.in-addr.arpa. 0/1/0 ns: 19.172.IN-ADDR.ARPA. [1d] SOA 19.172.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 (95)
16:54:39.392915 IP (tos 0x0, ttl 64, id 8082, offset 0, flags [none], proto UDP (17), length 69)
    172.20.10.4.59994 > 172.20.10.1.53: [udp sum ok] 22334+ PTR? 1.0.19.172.in-addr.arpa. (41)
16:54:39.416821 IP (tos 0x0, ttl 64, id 51863, offset 0, flags [none], proto UDP (17), length 123)
    172.20.10.1.53 > 172.20.10.4.59994: [udp sum ok] 22334 NXDomain* q: PTR? 1.0.19.172.in-addr.arpa. 0/1/0 ns: 19.172.IN-ADDR.ARPA. [1d] SOA 19.172.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 (95)

これは私たちのオフィスのwifiでの出力です：

16:54:13.870062 IP (tos 0x0, ttl 64, id 17811, offset 0, flags [none], proto UDP (17), length 69)
    192.168.0.32.56316 > 192.168.0.1.53: [udp sum ok] 21469+ PTR? 1.0.19.172.in-addr.arpa. (41)
16:54:13.870723 IP (tos 0x0, ttl 64, id 53920, offset 0, flags [none], proto UDP (17), length 69)
    192.168.0.32.52082 > 192.168.0.1.53: [udp sum ok] 50601+ PTR? 1.0.19.172.in-addr.arpa. (41)
16:54:13.872706 IP (tos 0x0, ttl 64, id 50395, offset 0, flags [none], proto UDP (17), length 69)
    192.168.0.32.56176 > 192.168.0.1.53: [udp sum ok] 45180+ PTR? 1.0.19.172.in-addr.arpa. (41)

そのため、DNS逆引き参照を使用したもののように見えますが、トラブルシューティングの方法がわかりません。 Wi-Fiを無効にすると、この速度の低下も完全に保証されます。 無効にしてから再度有効にしても効果はありません。

もちろん、質問を投稿した直後に独自の解決策を見つけます。 開発環境にインストールされたパッケージがOSXのDNS設定を更新したため、問題が発生したようです。 /etc/resolv.confのデフォルトを使用するようにOSXDNSをリセットすると、すべてが機能します。

これは、Bonjourが.localを所有している問題とIPV6のバグに関連している可能性がありますか？
詳細： https ：

これが役に立ったらDunnoですが、以前はこの問題があり、DNSサーバーを8.8.8.8と8.8.4.4変更して修正しました。

また、この問題は私のホームネットワークでのみ発生しました。 職場ではこの問題はありませんでした。

@jewilmeerの修正を試した後でも、同じ問題に直面しています。
docker-compose upは、私のオフィスネットワークでは正常に機能しますが、ホームネットワークでは約7分かかります。
他のdockerと同じ動作-stop、pull、psなどのcomposeコマンド。

docker --version
Dockerバージョン1.12.0-rc2、ビルド906eacd、実験的

docker-compose --version
docker-composeバージョン1.8.0-rc1、ビルド9bf6bc6

docker-machine --version
docker-machineバージョン0.8.0-rc1、ビルドfffa6c9

理由はわかりませんが、ローカルドメイン要素を削除して機能させる必要がありました。

/ etc / hosts：
127.0.0.1 localunixsocket

非常によく似た問題がありますが、 DNSCryptの使用に関連している可能性があり

@Erwyn VodafoneEasyboxでも同じ問題が発生しました...
Vodafone Easyboxは、 .localドメインの検索をルーターにバインドすることが判明しました（ルーターの動的ホスト名、つまりeasy.boxを評価するため）
そして、私の推測では、このバインディングにより、 docker-composeがルーターの応答を待機していました（これについては完全に間違っている可能性があります）...
しかし、追加
127.0.0.1 localunixsocket.localからetc/hosts問題が解決しました

こんにちは、みんな、
etc / hostsへの127.0.0.1 localunixsocketは私のために問題を解決しました

@davidino Thx Bro、完璧に動作します！ なぜこの回避策が必要なのか興味がありますか？

こんにちはみんな！ ここでも同じ問題があります。 ブラジルでは、オフィスでWi-Fiを使用すると、起動に時間がかかります。 /etc/hostsファイルを変更した後、すべてが正常に機能しました。

ここで同じ問題。 1つのオフィス（WIFI上）での作業問題や遅延はありません。 別のオフィス（WIFIでも）で作業すると、最大10分の遅延が発生します。

127.0.0.1 localunixsocketを/etc/hosts追加しても、問題は解決しませんでした。 再起動と組み合わせて試してみましたが、それでもうまくいきませんでした。

DNSサーバーとして8.8.8.8と8.8.4.4を追加すると、問題が解決しました。

ありがとう@Typositoire！

ねえ、 @ dadarek 、hostsファイルに127.0.0.1 localunixsocket.home <hostname>.homeを追加してみてください。 両方のホスト名を追加したとき、それはちょうど私のために働きました。 したがって、必要に応じて、ローカルDNSを引き続き使用できます...

これは、安定したチャネルとベータチャネルの両方で発生し、インターネットを切断するか、ホストエントリを追加すると修正されます。

エルキャピタン10.11.4
Dockerバージョン1.12.0、ビルド8eab29e、実験的
docker-composeバージョン1.8.0、ビルドf3628c7
docker-machineバージョン0.8.0、ビルドb85aac1

ビルドコマンドでホスト名とインターネットの切断の両方を試しましたが、何も役に立ちません... DNSの変更も試しました... 5〜10分間そのままにしてから、ビルドプロセスを開始します... CPU使用率が上がるのを確認できますdocker-composeプロセスで最大100％

http://i.imgur.com/fmlhjCo.png

とてもイライラする

http://i.imgur.com/C1P6zHi.png

ところで、セットアップはツールボックスで正常に機能し、非常に迅速に実行されました...

詳細なデバッグをオンにすると、ここにぶら下がっているのがわかります

[ホーム/ドッカー]-$ docker-compose --verbose build app

compose.config.config.find：構成ファイルの使用：./ docker-compose.yml
docker.auth.auth.load_config：ファイルが存在しません
compose.cli.command.get_client：docker-composeバージョン1.8.0、ビルドf3628c7
docker-pyバージョン：1.9.0
CPythonバージョン：2.7.9
OpenSSLバージョン：OpenSSL 1.0.2h 2016年5月3日
compose.cli.command.get_client：Docker base_url：http + docker：// localunixsocket
compose.cli.command.get_client：Dockerバージョン：KernelVersion = 4.4.15-moby、Os = linux、BuildTime = 2016-07-28T21：15：28.963402499 + 00：00、ApiVersion = 1.24、Version = 1.12.0、GitCommit = 8eab29e、Arch = amd64、GoVersion = go1.6.3
compose.service.build：アプリの構築
compose.cli.verbose_proxy.proxy_callable：docker build <-（pull = False、stream = True、nocache = False、tag = u'docker_app '、buildargs = None、rm = True、forcerm = False、path =' / Users / bartdabek / Sites / docker '、dockerfile =' Dockerfile-app '）

数分後、

docker.api.build._set_auth_headers：認証構成を探しています
docker.api.build._set_auth_headers：メモリに認証設定がありません-ファイルシステムからロードしています
docker.auth.auth.load_config：ファイルが存在しません
docker.api.build._set_auth_headers：認証構成が見つかりません

その後、再びハングします...

私のインターネット速度は60mb / sでテストしただけで問題ありません

プロキシ設定からExclude simple hostnamesを有効にすること

NO_PROXY=* docker-compose up

@jewilmeerによって投稿された回避策
https://github.com/docker/compose/issues/3419#issuecomment-221793401は私のために働きます。

Docker for MacREADME.mdまたはチュートリアルのどこかに@jibingeoによるヒントがあるとよいでしょう。

こんにちはみんな、@ thaJeztah。

ソースコードを調べたところ、 socket.gethostbyname("localunixsocket")実行に30秒以上かかっていることがわかりました（私の場合）。

そこで、ローカルDNSとGoogleDNSを照会しました

$ time nslookup localunixsocket 10.0.0.1
Server:     10.0.0.1
Address:    10.0.0.1#53

** server can't find localunixsocket: NXDOMAIN

real    0m30.295s
user    0m0.004s
sys     0m0.005s

$ time nslookup localunixsocket 8.8.8.8
Server:     8.8.8.8
Address:    8.8.8.8#53

** server can't find localunixsocket: NXDOMAIN

real    0m0.685s
user    0m0.005s
sys     0m0.013s

ローカルDNSはFQDNホスト名で完全に機能します

time nslookup google.com 10.0.0.1
Server:     10.0.0.1
Address:    10.0.0.1#53

Non-authoritative answer:
Name:   google.com
Address: 216.58.196.110


real    0m0.028s
user    0m0.005s
sys 0m0.006s

これは、実際の問題がルーターDNSにあることを意味します。

それは私だけですか、それともlocalunixsocket DNSルックアップを行うのは直感に反しているように見えますか？ これは、ローカルドメインソケットではなくTCPスタイルのアドレスを期待しているときにプレースホルダーとして使用されるフィラーホスト名のようです。

とにかく、ローカルDNSとGoogleのDNSの時間の違いは興味深いです...私はそれがそれをする原因となっているのか興味があります。 （残念ながら、再帰的にヒットした中間サーバーを保持できるDNSルックアップに相当するtracertがない限り、ルーターが指すDNSサーバーに別のTCPダンプを設定する必要があると思います。クエリ）

これも参考になるかもしれません（Mac OS Xのman nslookupにあります）：

Mac OSXの通知

nslookupコマンドは、ホスト名とアドレスの解決を使用しません
またはで実行されている他のプロセスによって使用されるDNSクエリルーティングメカニズム
MacOSX。 nslookupによって出力された名前または住所のクエリの結果
Mac OSXを使用する他のプロセスで検出されるものとは異なる場合があります
ネイティブの名前とアドレスの解決メカニズム。 DNSの結果
クエリは、Mac OS XDNSルーティングを使用するクエリとも異なる場合があります
図書館。

nslookup使用する特定のメカニズムとMac OS Xが提供するメカニズムについては実際には明確にされていないため、Dockerがnslookup動作を共有することが期待されるかどうかを判断するのは困難です。または他のMacOS Xアプリのそれ...（ nslookupと同じ方法を使用していると思いますが、両方のコードを掘り下げて明確に把握する必要があります）

ねえ@whitelynx

これは、ローカルDNSとGoogleDNSで取得されたTCPダンプです。 ダンプを取るために使用したコマンドは

sudo killall -HUP mDNSResponder && docker-compose ps

ローカルDNSの場合：

15:49:30.025038 IP (tos 0x0, ttl 255, id 18504, offset 0, flags [none], proto UDP (17), length 83)
    10.0.0.3.60707 > 10.0.0.1.53: [udp sum ok] 54235+ PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. (55)
15:49:30.291508 IP (tos 0x0, ttl 255, id 36848, offset 0, flags [none], proto UDP (17), length 61)
    10.0.0.3.52331 > 10.0.0.1.53: [udp sum ok] 10799+ A? localunixsocket. (33)
15:49:31.097658 IP (tos 0x0, ttl 255, id 32568, offset 0, flags [none], proto UDP (17), length 83)
    10.0.0.3.60707 > 10.0.0.1.53: [udp sum ok] 54235+ PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. (55)
15:49:31.368098 IP (tos 0x0, ttl 255, id 54970, offset 0, flags [none], proto UDP (17), length 61)
    10.0.0.3.52331 > 10.0.0.1.53: [udp sum ok] 10799+ A? localunixsocket. (33)
15:49:33.596367 IP (tos 0x0, ttl 30, id 20508, offset 0, flags [none], proto UDP (17), length 133)
    10.0.0.1.53 > 10.0.0.3.60707: [udp sum ok] 54235 NXDomain* q: PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. 0/1/0 ns: 10.IN-ADDR.ARPA. [1d] SOA 10.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 (105)
15:49:33.597103 IP (tos 0x0, ttl 30, id 20510, offset 0, flags [none], proto UDP (17), length 136)
    10.0.0.1.53 > 10.0.0.3.52331: [udp sum ok] 10799 NXDomain q: A? localunixsocket. 0/1/0 ns: . [2h8m4s] SOA a.root-servers.net. nstld.verisign-grs.com. 2016090900 1800 900 604800 86400 (108)

Google DNSの場合：

15:45:25.301293 IP (tos 0x0, ttl 255, id 37492, offset 0, flags [none], proto UDP (17), length 83)
    10.0.0.3.60707 > 8.8.8.8.53: [udp sum ok] 14029+ PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. (55)
15:45:25.371167 IP (tos 0x0, ttl 56, id 10269, offset 0, flags [none], proto UDP (17), length 83)
    8.8.8.8.53 > 10.0.0.3.60707: [udp sum ok] 14029 NXDomain q: PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. 0/0/0 (55)
15:45:25.599570 IP (tos 0x0, ttl 255, id 7256, offset 0, flags [none], proto UDP (17), length 61)
    10.0.0.3.59912 > 8.8.8.8.53: [udp sum ok] 3154+ A? localunixsocket. (33)
15:45:25.702374 IP (tos 0x0, ttl 56, id 39895, offset 0, flags [none], proto UDP (17), length 136)
    8.8.8.8.53 > 10.0.0.3.59912: [udp sum ok] 3154 NXDomain q: A? localunixsocket. 0/1/0 ns: . [29m58s] SOA a.root-servers.net. nstld.verisign-grs.com. 2016090900 1800 900 604800 86400 (108)

ここでは、ローカルDNSで最大3秒の遅延が見られます。

注：ここで使用したルーターは、以前のコメントで使用したルーターとは異なります

こんにちは、みんな、
Mac用のDockerにアップグレードした後Version 1.12.1 (build: 12133)追加する必要がありました
127.0.0.1 localunixsocket再び/etc/hosts

私はdavidinoがしたこともしなければなりませんでした。

この非常に厄介なバグを解決するための見積もりはありませんか？

それを機能させるには、 127.0.0.1 localunixsocket.lanも追加する必要がありました。 私はmacOSSierraを使用しています。

これが同じ問題かどうかはわかりませんが、 @ jibingeoの返信が
_docker-compose_は、Docker Toolbox forWindowsを使用している私の会社の環境でも非常に遅いです。 NO_PROXY=*を設定することも私を助けましたが、これは私の会社のプロキシに干渉します。 だから私は少し試してみましたが、より具体的な解決策を見つけました（デフォルトのdocker VirtualBox ip range 192.168.99.0/24を使用していると仮定します）：

NO_PROXY=192.168.99.0/24すべてを高速化するので、composeは内部IP用に会社のプロキシを試す必要はありません。

関連？ https://github.com/SeleniumHQ/docker-selenium/issues/227

127.0.0.1 localunixsocketを/etc/hostsに入れる@davidinoソリューションは、私にとって問題を解決しました。

今はとても速く

私は同じ問題を抱えています。 Wi-Fiをオフにして、ホストファイルに複数のエントリを追加しようとしましたが成功しませんでした。 Linuxボックスで同じセットアップを試しましたが、結果ははるかに高速です。

ビルドはまともな速度で実行されているようですが、実行中のコンテナーにリクエストを送信すると、結果はひどいものになります。 単純なテキスト応答であっても、要求には約30秒かかります。

RailsスタックでMacOS Sierra（10.12.1）とDocker for Mac（1.12.1）を実行しています。

私は10.11.6（15G31）を使用しています

これは私の/etc/hostsファイルにあるものです：

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
255.255.255.255 broadcasthost
::1             localhost 
127.0.0.1 localhost
127.0.0.1 localunixsocket
127.0.0.1 localunixsocket.lan
127.0.0.1 localunixsocket.local

私はベータチャネルドッカー1.12.3-beta29.2（13499）を使用しています

@gardnerこれをhostsファイルに追加しましたが、ベータ版を試しましたが成功しませんでした。 私は本当にそれがシエラと関係があると思い始めています。 アップグレードする前は、それが機能していたと確信しています。 ベータ版をもう一度試して、機能するかどうかを確認します。 テストした後、また投稿します。

@gardner同じ問題。 Docker 1.12.3-beta29.3（13640）を実行しています。 私のLinuxセットアップは、RAMの1/4で、まだはるかに高速に実行されています。

私が知ることができる最善のことは、それがDockerとホストマシン間のIOの問題であるということです。 リクエストに応じてフレームグラフを実行しましたが、ほとんどの時間をファイルの読み取りに費やしています。
https://www.dropbox.com/s/4702tx7qqpkr4yd/Screenshot%202016-11-02%2014.39.22.png?dl=0

これは同じアプリ、同じリクエストで、ローカルで実行されます。
https://www.dropbox.com/s/xxs5jdug7cllpbu/Screenshot%202016-11-02%2014.44.37.png?dl=0

アプリを本番モードで実行するように構成すると、Docker内で同じように高速に実行されます。

これがすでに知られているかどうかはわかりませんが、うまくいけば、このスレッドに来てそれを理解しようとしている他の人に役立つでしょう。

編集：これは私が直面している本当の問題のようです。 https://forums.docker.com/t/file-access-in-mount-volumes-extremely-slow-cpu-bound/8076/223

また、この問題が発生すると、ホストへの変更によって少し違いが生じますが、それでも少し遅くなります。
127.0.0.1 localunixsocket.local 127.0.0.1 localunixsocket

これは、OSX10.11.6を実行している次の安定したDockerバージョンと次のDockerバージョンで見られます。

Client:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Wed Oct 26 23:26:11 2016
 OS/Arch:      darwin/amd64

Server:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Wed Oct 26 23:26:11 2016
 OS/Arch:      linux/amd64

これは遅いクラウド接続（ロンドンのカフェのクラウド）で見られます。WiFiをオフにすると、作成が非常に速くなります。そうしないと、すべてが非常に遅くなります...

最新のリリース（1.9.0）は、問題が発生している人にとって何か変わったように見えましたか？

@ shin-最新のDockerfor Macを使用したdocker-compose --versionにはまだ1.8.1があります。 いつアップデートを期待できますか？

この問題の解決はいつ期待できますか？

1.9はベータチャネルにあり、いつ安定して出荷されるかはわかりません。おそらく
一週間かそこらで。

2016年11月18日午前8時7分、「DavidRichards」 [email protected]は次のように書いています。

@ shin- https：//github.com/shin-まだdocker-composeに1.8.1があります
--Mac用の最新のDockerを使用したバージョン。 いつアップデートを期待できますか？

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/docker/compose/issues/3419#issuecomment-261472095 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAdcPBV7gMv0kMwil0SEz3etChNY6ej3ks5q_VyugaJpZM4IXnGd
。

私にとって、 McAfee EndpointSecurityがdocker-composeが非常に遅い理由でした。 オンアクセススキャナーは、docker-composeが実行されるたびに発生するように見えるPython環境を解凍するパフォーマンスを実際に殺しているようです。

私にとっては、 .local検索ドメインを削除することですべての違いが生まれました。

@ shin- 1.9.0-rc4でまだ問題があります。 何をしたのかわかりませんが、数日前は問題がなく、 docker-compose年以上
docker-compose --versionは本当に速いです
docker-compose psは非常に遅い
Wifiの無効化- psも高速です

@gsong残念ながら、それは私には役に立ちませんでした

私も突然この問題を抱え始めました。 @timsuchanekと同じように、私はdocker-compose upはほぼ無期限にハングします。 他のみんなと同じように、wifiをオフにすると機能します。

私はdocker-compose version 1.9.0, build 2585387

編集： 127.0.0.1 localunixsocketを/etc/hosts追加すると、今のところ修正されました。 私はmacOS10.11.6を使用しています

ヨセミテで導入された.local変更が原因である可能性はどのくらいありますか？

https://support.apple.com/en-us/HT203136
https://news.ycombinator.com/item?id=9026192

@afxjzsが以前にそれたが、フォローアップは見られませんでした。

xdebugを機能させようとしているときに、自分に合ったものに出くわしました。

sudo ifconfig en0 alias 10.254.254.254 255.255.255.0

ホストマシン上。

JamesCowieに感謝します。

編集：xdebugが私の問題の根本だったようです。 xdebugをオフにすると、/ etc / hostsがデフォルトの状態であっても、Dockerマシンは超高速になります。 オンにして、xdebug.remote_hostを10.254.254.254に設定すると、速度が低下してクロールします。 / etc / hostsに推奨される編集は役に立ちませんが、上記のようにen0にlocalhostエイリアスを設定すると問題が修正されます。

これは、最新の安定したMac用Docker（1.13.1、docker-compose 1.11.1）で私に起こっています。

NO_PROXY=*機能します。

これは、最新のアップデート（1.13.1、docker-compose 1.11.1）でも発生しました。 https://github.com/docker/compose/issues/3419#issuecomment-221793401で問題が解決しました。

同じエラーが発生します。 localunixsocketを/etc/hosts追加します。 動作しませんでした。 [プロキシ]タブでExclude simple hostnamesをマークする一時的な修正。

macOS Sierra 10.12.3 (16D32)
Docker version 1.13.1, build 092cba3
docker-compose version 1.11.1, build 7c5d5e4

レスポンシブ検索ドメインがあると、Dockerの作成が非常に遅くなることに気づきました。 それだけではありません.local私が使っていた.dev 。

今日、docker-composeがヘルプや--versionを表示する場合でも、永久にハングするという同じ問題が発生しました。 tcpdumpの使用に関する@jewilmeerのアドバイスに従いました。私の場合、問題は/ etcホストに127.0.0.1 prod.python.map.fastly.netを追加することで解決されました

かなり変だと思いますか？

ここで同じ問題。 それぞれ約25秒間、2回ハングしているように見えます。 これは、各HANGが挿入された--verbose出力です。

compose.config.config.find: Using configuration files: ./config/docker-compose-dev.yml
docker.auth.find_config_file: Trying paths: ['/Users/dorkusprime/.docker/config.json', '/Users/dorkusprime/.dockercfg']
docker.auth.find_config_file: Found file at path: /Users/dorkusprime/.docker/config.json
docker.auth.load_config: Found 'auths' section
docker.auth.parse_auth: Found entry (registry=u'https://index.docker.io/v1/', username=u'dorkusprime')

[HANGS FOR ~25S]

compose.cli.command.get_client: docker-compose version 1.11.2, build dfed245
docker-py version: 2.1.0
CPython version: 2.7.12
OpenSSL version: OpenSSL 1.0.2j  26 Sep 2016
compose.cli.command.get_client: Docker base_url: http+docker://localunixsocket
compose.cli.command.get_client: Docker version: KernelVersion=4.9.13-moby, Arch=amd64, BuildTime=2017-03-15T20:28:18.193664702+00:00, ApiVersion=1.27, Version=17.03.1-ce-rc1, MinAPIVersion=1.12, GitCommit=3476dbf, Os=linux, Experimental=True, GoVersion=go1.7.5
compose.project.build: mongodb uses an image, skipping
compose.project.build: redis uses an image, skipping
compose.service.build: Building web
compose.cli.verbose_proxy.proxy_callable: docker build <- (pull=False, stream=True, nocache=False, tag='dorkusprime/dashboard-test', buildargs=None, rm=True, forcerm=False, path='/Users/dorkusprime/repository/Dashboard-test', dockerfile=None)
docker.api.build._set_auth_headers: Looking for auth config
docker.api.build._set_auth_headers: Sending auth config (u'https://index.docker.io/v1/')

[HANGS FOR ~25S]

compose.cli.verbose_proxy.proxy_callable: docker build -> <generator object _stream_helper at 0x105cc4910>

/ etc / hostsの回避策を試しましたが、目立った改善はありませんでした。

ここでも同じ問題があり、スレッド全体からの解決策は役に立ちません（ /etc/hostsもNO_PROXY変数もExclude simple hostnamesも、DNSを8.8.8.8変更することもありません）。

注意すべき点の1つは、sudoを使用してdockerを実行すると、速度の問題が解決することです。

最新のDockerバージョン（Dockerバージョン17.03.1-ce-rc1、ビルド3476dbf）。 ベータ版と安定版の両方のリリースを試しました。

私の場合、 docker --versionはバージョンを出力するのに32秒かかります。

この問題はもう1年近く続いています...

@mobileka dockerまたはdocker-composeですか？

@ shin-私の場合、dockerに関連するすべてのcliコマンド（ dockerまたはdocker-compose ）には、実際に結果を出す前、またはジョブを開始する前に30秒ほどの遅延があります。

@mobilekaわかりました-これは、ここで説明する問題とはまったく関係ありません。 代わりに、 Docker forMacリポジトリで問題を作成することを検討してください。

@ shin-申し訳ありませんが、「症状」が非常に似ていたため、間違ったレポにいることに気づきませんでした。インターネット接続がアクティブなときは遅く、インターネット接続がないときは速いです。

ありがとうございます。DockerforMacリポジトリで問題を作成します。

これが他の誰かに打撃を与えるという偶然の機会に、私は領事と遊んでいる（そしてその後の失敗）が/ etc / resolversに設定ファイルを追加したと確信しています。 これにより、 localunixsocketの表示で報告された、 そのようです：

A.D.*.5.>t.d............localunixsocket.foo.bar.example.com.....
14:36:13.357925 IP 10.23.45.67.65066 > 10.98.76.54.53: 25754+ A? localunixsocket.foo.bar.example.com. (54)
E..R.......P
...

/ etc / resolvesからファイルを削除すると、問題はすぐに解決しました。

お役に立てば幸いです。

ここで同じ問題が発生し、スレッド全体からの解決策は役に立ちません（/ etc / hosts、NO_PROXY変数、単純なホスト名の除外、DNSの8.8.8.8への変更のいずれでもありません）。

私はおもちゃのウェブサイトを作成し（ロジックは本当にシンプルで、パフォーマンスの問題はないはずです）、docker-composeを使用してローカルで実行します。 ほぼすべてのページの読み込みに数分かかることがわかりました。 何か指示はありますか？

アプリの@mqliangページの読み込み時間は、この問題とはまったく関係がなく、一般的に作成とは関係がないようです。

MacOS Sierra、10.12.5。
Docker CommunityEdition
バージョン17.06.0-ce-mac18（18433）
チャネル：安定
d9b66511e0

私はすでに8.8.8.8としてDNSを持っていました。 localunixsocket.localとlocalunixsocketの両方を/ etc / hostsに追加する必要があります。 これが追加された瞬間、実行中のdocker-composeが活気づきました。

これが誰かに役立つかどうかはわかりませんが、dnscryptをインストールしましたが、docker betaに切り替えた後、dockercomposeは非常に遅くなりました。 dnscryptを（brew cask経由で）再インストールすると、問題が修正されました。

愛してる@jewilmeer

これをここに残したかっただけです。 私の問題は、ビルドコンテキスト内のセッションファイルでした。 ファイルはapacheユーザーによって所有されており、docker-composeビルドは次の行の後にハングします。

docker.api.build._set_auth_headers: No auth config found 

悲しいことに、私はずっと前にファイルベースのセッションの使用をやめました。 たまに私のワークスペースを掃除する必要があります。

コメントの理由：composeがハングするだけではないのは本当に素晴らしいことです。 Docker Buildを直接使用している原因を見つけただけで、問題がうまく通知されました。

@paali正確に何をしたか、詳しく説明していただけますか？

@ Vad1mo私の完全なセットアップは非常に複雑です（そして厄介で進行中です）が、基本的な部分はSymfony2プロジェクトです。 ./app/sessionsフォルダーにapacheユーザーが所有していた古いセッションファイルがありました（Docker時間より前）。

基本的に私は持っていた
COPY app app/
Dockerfilesとdocker-compose.ymlをオンにして、特定のDockerfileをビルドします。
使用したコマンド：
docker-compose -f docker-compose-ci.yml build --no-cache --force-rm

前述のように、ビルドプロセスは実際には開始されませんでしたが、認証ヘッダーに関する行の後でフリーズしました。 Dockerでビルドを行うと、次のことがわかりました。

> docker build -f thefile --no-cache --force-rm
error checking context: 'no permission to read from '/path/to/my/project/app/sessions/sess_n8turtujft1bipv745khqsqbi1''.

次回はすぐにdockerを試すことを知っていますが、本当の問題が何であるかを示唆するものは何もありませんでした。 Docker for Mac7.06.1-ce-mac24を使用しています。

ホストルールを追加するかプロキシをオフにするように全員に指示する必要がある以外に、これに対する実際の解決策について何か言いたいことはありますか？

+1

+1

+1

私にとってそれを修正したのは、システム環境設定/ネットワーク/詳細/ DNS /検索ドメインに移動し、エントリ「.local」を削除することでした。 私がそこに置いたもの。 これにより、macOSは検索ドメインにデフォルト値の「localdomain」のみを入力しました。 そして、 docker-composeが再び応答するようになりました。

docker自体は常に反応していました。

わかりませんが、おそらくdockerがIPアドレスまたは安定したローカル名を使用してオンシステムリソースを正しく見つけているのに対し、 docker-composeは安全にlocaldomain依存していないと思います

修正の元の投稿にあったDNSを監視するために行を実行します：

sudo tcpdump -A -s0 -nnien0ポート53

これは、hostfileに追加する必要があるのは次のとおりであることを示しています。

127.0.0.1 localunixsocket.localdomain

何かが.localから.localdomainに変更されたようですか？

それ以来、10.12Sierraの新規インストールを行いました。 dockerを再インストールしましたが、問題を再現できませんでした。

私は今日、Macでの最初の日、この問題に遭遇しました。
Dockerの作成は、文字通り/etc/hostsに行を挿入した後、期待どおりに機能し始めたため、停止しました。
私はWiFiを使用していましたが、イーサネットで同じバージョンを使用しているオフィスの全員がこの問題について聞いたことさえありませんでした。
Docker： Version 17.09.0-ce-mac35 (19611)
Mac 10.13.1 (17B48)

ここに同じバグがあります。 この問題を解決するには、/ etc / hostsに3行を追加する必要があります。
127.0.0.1 localunixsocket
127.0.0.1 localunixsocket.lan
127.0.0.1 localunixsocket.local

同じバグ。 これは私のために働いた。

$ sudo tcpdump -vvv -s 0 -l -n port 53
...
13:46:10.203734 IP (tos 0x0, ttl 255, id 7224, offset 0, flags [none], proto UDP (17), length 81, bad cksum 0 (->7b21)!)
    10.64.14.244.54683 > 10.0.0.10.53: [bad udp cksum 0x2491 -> 0xf39b!] 30038+ A? localunixsocket.*.svc.cluster.local. (53)

$ sudo vim /etc/hosts

# hacks for docker
127.0.0.1 localunixsocket.*.svc.cluster.local

私は追加127.0.0.1 localunixsocketで/etc/hosts 、それが私のために働いた、ありがとう！
（しかし、それはまだwtfバグです）

最新バージョンではまだ問題があります。 上記の修正は私には何の役にも立たないようです。ある時点で速度が遅くなり、ハングします。 私にとっての回避策は、Docker forMacを頻繁に再起動することです。

/etc/hosts 127.0.0.1 localunixsocketが劇的にスピードアップすることを確認しました、修正してください！

追加127.0.0.1 localunixsocketで/etc/hostsができます。 docker-compose version 1.18.0, build 8dd22a9

@norbertsienkiewiczが推奨するソリューションは、私にとって完璧に機能しました。 docker-compose up時間が10分以上から1分未満に短縮されました（バージョン1.18.0）。

そもそもなぜこれが起こり始めたのか、私は実際にもっと興味があります。 最近発生した問題の回避策としてhostsファイルを変更し、それを「解決策」として宣言する必要があるのは、私には少しばかげているようです。

偽のDNSルックアップを引き起こすバックトレースは次のとおりです。

  File "/Library/Python/2.7/site-packages/docker-3.1.0-py2.7.egg/docker/api/daemon.py", line 88, in info
    return self._result(self._get(self._url("/info")), True)
  File "/Library/Python/2.7/site-packages/docker-3.1.0-py2.7.egg/docker/utils/decorators.py", line 46, in inner
    return f(self, *args, **kwargs)
  File "/Library/Python/2.7/site-packages/docker-3.1.0-py2.7.egg/docker/api/client.py", line 193, in _get
    return self.get(url, **self._set_request_timeout(kwargs))
  File "/Library/Python/2.7/site-packages/requests-2.18.4-py2.7.egg/requests/sessions.py", line 521, in get
    return self.request('GET', url, **kwargs)
  File "/Library/Python/2.7/site-packages/requests-2.18.4-py2.7.egg/requests/sessions.py", line 499, in request
    prep.url, proxies, stream, verify, cert
  File "/Library/Python/2.7/site-packages/requests-2.18.4-py2.7.egg/requests/sessions.py", line 672, in merge_environment_settings
    env_proxies = get_environ_proxies(url, no_proxy=no_proxy)
  File "/Library/Python/2.7/site-packages/requests-2.18.4-py2.7.egg/requests/utils.py", line 692, in get_environ_proxies
    if should_bypass_proxies(url, no_proxy=no_proxy):
  File "/Library/Python/2.7/site-packages/requests-2.18.4-py2.7.egg/requests/utils.py", line 676, in should_bypass_proxies
    bypass = proxy_bypass(netloc)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib.py", line 1487, in proxy_bypass
    return proxy_bypass_macosx_sysconf(host)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib.py", line 1453, in proxy_bypass_macosx_sysconf
    hostIP = socket.gethostbyname(hostonly)

ワイヤレスから有線に切り替えた後、この問題が発生しました。 ワイヤレスに戻ると、すべてが世界で正しいです。

/ etc / hostへの変更はホストマシンまたはDockerコンテナになりますか？

どのhostsファイルを変更しますか？

1. macOSホストファイル？
2. Dockerホストとして機能するLinuxVM？
3. コンテナ自体？

理由はわかりませんが、ローカルドメイン要素を削除して機能させる必要がありました。

/ etc / hosts：
127.0.0.1 localunixsocket

天才！！！