仮想環境コンテナ総合スレ Docker、Vagrant等 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/02/16(木) 18:01:04.48

開発に仮想環境やコンテナを使う機会が多くなってきたので、みんなで情報交換しませう

よろしこ

**デフォルトの名無しさん** · 2019/08/03(土) 21:14:05.18

>>857
オートコンプリートなら別にAnsibleとは無関係に使える。
例えばDockerfileのオートコンプリートだって存在する。

まああれも第三者が作ってるから、公式のバージョンアップに
ついていけないところがあったりで不完全なところがあるんだが、
オートコンプリートなら補完されないってだけで別に大きな問題にはならんな

**デフォルトの名無しさん** · 2019/08/03(土) 21:17:17.90

>>855
極論マンw
一切ないとか言ったら何も使えんわ
お前本当にエンジニア？
世界中で実践運用耐えうるぐらいには問題なく使えるよ

>>856
お前は全てのバグを踏み抜く奇跡の体現者かよw
実際に遭遇して問題が表面化して解決もできないなんてバグは滅多にない
ラッパーなら迂回路はいくらでもあるからな
お前が大好きな本家の設定がバグってたらほとんど打つ手ないけどな

**デフォルトの名無しさん** · 2019/08/03(土) 21:22:16.09

> 一切ないとか言ったら何も使えんわ

だからそういう間に入って変換するだけのものは
使わないほうが良いって言ってんだろ

公式が提供している、標準のやり方を使えばいいだけ

> お前が大好きな本家の設定がバグってたらほとんど打つ手ないけどな
本家がバグってるのをラッパーで回避できるわけ無いだろｗ
もし回避する方法があるなら、その方法をラッパーを使わずにやればいいだけだし

俺が言ってるのは公式が提供している標準のやり方をしろというだけ
間に変な変換ツールを入れて、その制限にぶち当たって悩まなくて良くなる

**デフォルトの名無しさん** · 2019/08/03(土) 21:26:30.12

そのうちプログラミングもYAMLで書きたいとか言い出しそうなんだよなｗ

**デフォルトの名無しさん** · 2019/08/03(土) 21:31:23.14

>>858
buildargsを使う
修正してモジュールにコミットする
シェル系モジュールを使う

回避する方法がいくらでもあるから安心だなぁ

**デフォルトの名無しさん** · 2019/08/03(土) 21:32:02.04

>>859
他のツールは？
カバー範囲狭すぎだろw

**デフォルトの名無しさん** · 2019/08/03(土) 21:37:49.05

>>861
飛行機落ちるかも怖いから乗らないって駄々こねる子供と同じだなこりゃ
大人はメリットもリスクも比べて飛行機に乗る

なんかあったら打つ手なしの飛行機じゃねえんだからリスクはさらに安く見積もって良い
ちょっとでもリスクあったら全否定ってw
本当にアセンブラマンなのかこいつ
今はまだある程度正気のようだがそのうちコンパイラも信じないとか言い出しそうだ

**デフォルトの名無しさん** · 2019/08/03(土) 22:09:24.60

>>863
お前の仕事は、回避することかｗ

>>865
間に挟めてトラブルを引き起こすツールに
メリットなんか無いじゃんｗ

**デフォルトの名無しさん** · 2019/08/03(土) 22:10:17.26

なんども言うが、公式のやり方をすれば
間に挟めるツールのトラブルがまるまるなくなる

非公式のやり方じゃなくて、公式のやり方をしろと言ってるだけ

**デフォルトの名無しさん** · 2019/08/03(土) 22:10:46.33

あとアセンブラとコンパイラは全然意味が違うので話にならない

**デフォルトの名無しさん** · 2019/08/03(土) 22:26:01.09

>>866
仕事は別だ
ごく稀に回避が必要な時にわずかな労力で回避するというだけのことだ
たったそれだけの事を過剰に恐れて便利なツールが中でやってることを全部自前でやるなんてよっぽど暇なのかな
まあ車輪の再発明も仕事といえば仕事か

**デフォルトの名無しさん** · 2019/08/03(土) 22:27:55.21

>>867
省力化やメンテナンス性の向上もまるまるなくなるな

>>868
たとえとしては十分だ

**デフォルトの名無しさん** · 2019/08/03(土) 22:56:40.59

> たとえとしては十分だ

的外れだからな。
所詮「第三者が作った設定ファイル形式のコンバーター」は
トラブルが起きたら変換後のオリジナルの設定ファイルを見なければ話にならん

**デフォルトの名無しさん** · 2019/08/03(土) 22:57:33.53

> たったそれだけの事を過剰に恐れて便利なツールが中でやってることを

ん？それってシェル系モジュール＝シェルスクリプトでできる程度のことでしょ？ｗ

**デフォルトの名無しさん** · 2019/08/03(土) 23:06:48.06

>>871
外れてないぞ
お前の意見は「データを抽象化、容易化するのは無駄(実際には無駄じゃなくメリットはある)で変換器の変換バグがあるかもだからアトミックなまま使え」だからな
機械語コードとコンパイラにもピタリと当てはまるな

**デフォルトの名無しさん** · 2019/08/03(土) 23:10:57.32

>>872
それってアセンブラでもできることでしょう？

ただ出来ると簡単に出来る、うまく出来るは違うことなんだな
だから高級言語が発達した

設定も同じことだ

**デフォルトの名無しさん** · 2019/08/04(日) 01:24:31.62

>>873
俺の意見を間違えてるｗ

「不要な第三者が作った質の悪く機能不足な変換ツールを使わずに
アプリの開発者の想定通りの使い方をしろ」が俺の意見だ

**デフォルトの名無しさん** · 2019/08/04(日) 01:25:43.22

>>874
設定ファイルは同じじゃない。

YAMLで設定を書いたら、できることが減ってバグが増えてる。
それに対してメリットがない。

**デフォルトの名無しさん** · 2019/08/07(水) 02:02:44.08

長いので2つに分割します。(1/2)

toolboxからコンテナを作れたまでは良いのですが、共通ファイルを作った上で、
コンテナ内のディレクトリにcreate-react-appでunk20というReactディレクトリを生成しようとしても、エラーが表示されで作れなくなりました。
途中まではWindowsの方の共通フォルダdocker-common内にunk20というフォルダが生成されているのですが、
以下のコードのnpm ERR!が出るとunk20フォルダごと削除され消えてしまいます。
ちなみに、共通フォルダを設定していない状態ですと、create-react-appでReactディレクトリはちゃんと作られ、localhostで接続すると問題なくブラウザにも表示されます。
node.jsとnpmは最新版にしております。

**デフォルトの名無しさん** · 2019/08/07(水) 02:03:07.70

PS D:\programming\docker> docker run -it --name my-first-docker-app-20 -p 3000:3000 -v //d/programming/docker-common:/docker-common react-env-2/docker-common
(コンテナ作成 & コンテナ内に入る）

create-react-app unk20(create-react-app コマンドでunk20というReactディレクトリを作る）

Creating a new React app in /docker-common/unk20.
(ここで、Windows側のdocker-commonファイル内にもunk20というファイルが生成される）

(Reactを生成中）
Installing packages. This might take a couple of minutes.
Installing react, react-dom, and react-scripts...

(ここら辺りまで順調に進んでいたのですが、以下でエラーメッセージが表示される）
npm ERR! path /docker-common/unk20/node_modules/@hapi/topo/node_modules/@hapi/hoek/package.json.769352676
npm ERR! code ENOENT
npm ERR! errno -2
npm ERR! syscall open
npm ERR! enoent ENOENT: no such file or directory, open '/docker-common/unk20/node_modules/@hapi/topo/node_modules/@hapi/hoek/package.json.769352676'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent

npm ERR! A complete log of this run can be found in:
npm ERR! /root/.npm/_logs/2019-08-06T16_31_06_826Z-debug.log

Aborting installation.
npm install --save --save-exact --loglevel error react react-dom react-scripts has failed.

Deleting generated file... node_modules
Deleting generated file... package.json
Deleting unk20/ from /docker-common
Done.
(unk20ディレクトリが削除される）

**デフォルトの名無しさん** · 2019/08/07(水) 02:03:56.17

最後までお読みいただきありがとうございました。
どなたかわかるかたいらしたら宜しくお願い致します・・・。

**デフォルトの名無しさん** · 2019/08/22(木) 22:54:02.06

すごいなWindowsでdocker使う人が居るんか

**デフォルトの名無しさん** · 2019/08/22(木) 23:05:23.65

むしろwindowsだからこそありがたい

**デフォルトの名無しさん** · 2019/08/22(木) 23:06:47.55

>>880
普通に使ってるけど？

**デフォルトの名無しさん** · 2019/08/23(金) 06:33:41.15

MacのDockerって仮想マシンで動いてるんだなー

**デフォルトの名無しさん** · 2019/08/23(金) 12:03:35.29

Docker for windowsは便利だけどwindowsコンテナは全く使ってない

**デフォルトの名無しさん** · 2019/08/24(土) 11:10:34.44

helmのテンプレートってすごく汚くて読みにくい
うまくYAMLにするためにインデント数を`Indent 12`みたいにしてテンプレートで指定とか正気かよ
なんか良い代わりのやつ無いの？

**デフォルトの名無しさん** · 2019/08/25(日) 00:00:48.85

helmはなんかなじめなくてkustomize使ってる

**デフォルトの名無しさん** · 2019/08/25(日) 00:10:10.89

クソトメライズ？

**デフォルトの名無しさん** · 2019/08/25(日) 00:58:14.70

臨時雇い要員にもdockerを使わせたいのだけどよけいな権限は与えたくない時はどうすればいい？
ホストもコンテナ内も一般ユーザーのみ許可できればいいのだけどそんなことできんのかね

**デフォルトの名無しさん** · 2019/08/25(日) 03:53:54.44

>>888
その臨時雇い要員に専用のパソコンを与えれて
そのパソコンは自由に使っていいけど、本番環境へのアクセスは禁止すればいい

**デフォルトの名無しさん** · 2019/08/25(日) 07:11:30.55

>>889
仮想端末を含めて専用のPCを用意することが出来ません
複数名でログインする端末です
機密情報を扱う別のユーザーと共有してます

**デフォルトの名無しさん** · 2019/08/25(日) 07:27:40.02

> 仮想端末を含めて専用のPCを用意することが出来ません

言い換えると、あなたの会社でまともな開発はできません。ということ
自分で、まともな開発はできないと結論を出してるんだから、そこで終わりだろう。

**デフォルトの名無しさん** · 2019/08/25(日) 07:29:21.71

だいたい、専用のPCを用意できないって
単に金が無いって言ってるだけじゃないか

金がないです。どうしたらいいですかと言われても
借金でもすれば？で終わる話

**デフォルトの名無しさん** · 2019/08/25(日) 07:38:33.38

給料を出だないほど金がないなら話は別だが
パソコンなんて数万円程度で買えるのにのに「できない」
なんてことはありえない。ようするにやる気がないだけ。

言葉は正しく使え。専用のPCを用意することができないんじゃなくて
専用のPCを用意したくない。が正しい言葉だ。

機密情報も、適当でいいって思ってるだろ。
機密情報に関してきっちりしているなら専用のパソコンに物理的に分ける。
パソコンがとても高価だった時代ならまだしも、今の時代に複数で共有なんて危険なことはしない。
個人専用のパソコンを与えてない時点で、セキュリティはザルでしかない。

自己を認識してないようだからはっきり言ってやる。
お前のところは機密情報を扱う資格がないし、守ることすら出来ない。
大切なものを守る意識も欠けてるし、やるべき正しいこともわかっていない。
今何も問題が起きてないのは運がいいだけだ。

**デフォルトの名無しさん** · 2019/08/25(日) 07:42:07.89

あなたの知る限り技術的には不可能ということでしょうか？

**デフォルトの名無しさん** · 2019/08/25(日) 07:45:18.41

>>894
例えば10階建てビルを作る技術はある。
みんなそれを作るための技術と道具を持ってる。

お前は、クレーンがないんです。
技術的に不可能ということでしょうか？と聞いてる。

技術的に不可能じゃなくて、クレーンを買うことができないことが
出来ない理由だっていってんの。ちゃんと認識しろって

**デフォルトの名無しさん** · 2019/08/25(日) 07:46:47.45

目的を達成する方法はいくつもあるが
「金が無い」なら、無理じゃねと言うしか無い

**デフォルトの名無しさん** · 2019/08/25(日) 08:00:05.20

つまりわからないということですね？

**デフォルトの名無しさん** · 2019/08/25(日) 12:49:41.65

何だこいつ

**デフォルトの名無しさん** · 2019/08/25(日) 12:59:09.23

イキってるくせに質問には答えられないクズってたまに居るよねぇ

**デフォルトの名無しさん** · 2019/08/25(日) 13:30:52.18

お前のこと云ってんだよ

**デフォルトの名無しさん** · 2019/08/25(日) 13:35:48.58

言われてるぞお前くん

**デフォルトの名無しさん** · 2019/08/26(月) 00:04:01.79

個人でDockerを入れてそこで自己完結させればいいだけだろ。サーバーからコンテナのコピーで済む話。

buildをユーザ権限でやるならk8sの使えば行けるが、会社と担当者のITリテラシーレベル低そうだし諦めればw

**デフォルトの名無しさん** · 2019/08/26(月) 00:50:09.55

>>902
セキュリティやってる気になってる会社には無理だろ
機密情報を扱う別のユーザーと共用してるパソコンなんて
正気の沙汰じゃない。どうせアップデートもしてないだろうし。
セキュリティ意識ゼロ

**デフォルトの名無しさん** · 2019/08/26(月) 01:31:32.75

コンテナ内というのが意味不明だな。
ビルドでユーザー作れば当然管理者権限なしでも入れるが、dockerでやる事なのだろうか。

中に入る→出来る
ビルド→出来る
docker コマンド→別グループ作れば可能だが実質su

dockerはアプリ動かすツールであって、管理者以外が共有PCで立ち上げ必須な用途には向かない。巻き添えで常駐コンテナに影響するからだ。

PCに入ったあと、Dockerコマンドで機密情報を操作するコンテナを動かすルールなのだろうか。

企業によくいる、自分は詳しいと思いたい素人が管理してる感溢れていて良い。

**デフォルトの名無しさん** · 2019/08/26(月) 02:35:23.25

>>904
かんたんなこと。
なんちゃってセキュリティだから決まってるのは
「root権限は禁止」

これだけ

**デフォルトの名無しさん** · 2019/08/26(月) 02:35:28.97

>>904
かんたんなこと。
なんちゃってセキュリティだから決まってるのは
「root権限は禁止」

これだけ

**デフォルトの名無しさん** · 2019/08/26(月) 06:29:32.37

お前らってわからない時の言い訳はいつも饒舌だよねぇ
質問には答えられないくせにさw

**デフォルトの名無しさん** · 2019/08/26(月) 06:47:45.57

言い訳というのはちょっと違ったか
わからないことを誤魔化すためのマウンティングになると饒舌
これが正確だな

**デフォルトの名無しさん** · 2019/08/26(月) 08:28:14.69

>>907
>>904に答え書いたでしょ。
buildの方はk8sやローカルリポジトリがいるのでかなり難易度高め。k8sが管理者権限だと無理だな。

ユーザー作る方は難しくない。

rootが嫌ならユーザーをdockerに入れると良い。実質suだが。他は不可能。

上2つはdockerfile書けるのが前提で、ここに書いて済むレベルの話ではない。

頑張れw

**デフォルトの名無しさん** · 2019/08/26(月) 08:43:07.72

権限ちゃんと分けたかったら
Dockerじゃなくて普通にVM使うべき。
メモリーの必要量は増えちゃうけど。

**デフォルトの名無しさん** · 2019/08/26(月) 12:49:17.98

「VM使ってもroot使ったダメなんですー」
「個人にパソコンを与えたとしてもrootは禁止なんですー」
「うちってセキュリティしっかりしてるでしょ？」

**デフォルトの名無しさん** · 2019/08/26(月) 15:55:14.47

>>909
呆れる
k8sの話はしてないしローカルDockerの話してんの
ユーザーDockerに入れても意味ないだろ

>>910
業務上の都合で使えません

>>911
答えられないなら無理してレスしないでいいぞ？
見ててちょっと気の毒だ

**デフォルトの名無しさん** · 2019/08/26(月) 15:58:57.84

× 業務上の都合で使えません
○ 業務改革したくないです。やる気ないです。

**デフォルトの名無しさん** · 2019/08/26(月) 16:03:12.47

新しい道具を入れたら、それだけで改善されるって思ってるバカが多いからな
新しい道具に最適になるように「やり方」を変えないと、何もかも無駄になる。

**デフォルトの名無しさん** · 2019/08/26(月) 22:09:26.41

>>912
dockerでは無理。k8sはコンテナも書き方も同じでdockerの上位互換。しかし、複雑で難易度の高め。

**デフォルトの名無しさん** · 2019/08/26(月) 22:11:49.21

普通、業務で使うならk8sだと思うが。分散や冗長化がdockerではできないからね。インストールがユーザー権限で出来るしdockerfileも使える。

完全な上位互換なんだが、代わりに手軽さは一切無いw

**デフォルトの名無しさん** · 2019/08/26(月) 23:35:27.55

そもそも無理な要件を期待してるんだから、要件の方を変えるべきだな。
Dockerでできることのほとんどは、Docker使わなくても手間が違うだけでできるわけだし。
無理だと分かってる要件を押し通そうとするのは無能。

押し通そうとしてるのが自分じゃなく上なら、そんな理不尽な職場は放棄して転職すべき。

**デフォルトの名無しさん** · 2019/08/28(水) 08:51:22.17

macOS版のDockerで、docker buildがたまにフリーズするバグの回避方法ない？
このバグのせいでテストがまともに出来なくて困ってる。
WindowsやLinuxでは発生しない。
タイムアウト仕込んでリトライさせるしか無いかな

**デフォルトの名無しさん** · 2019/08/28(水) 20:14:43.89

>>918
これでどや？

docker run --rm -d --name build-reg -p 55555:5000 registry:latest

docker run --rm -d --name build-dind --link build-reg --privileged \
docker:dind dockerd --host tcp://0.0.0.0:2375 --insecure-registry build-reg:5000

docker run -it --rm --name build-docker --link build-dind \
-v $PWD:/build \
-w /build \
-e DOCKER_HOST=tcp://build-dind:2375 \
docker:latest sh -c 'docker build -t build-reg:5000/test:latest . && docker push build-reg:5000/test:latest'

docker pull localhost:55555/test:latest

docker stop build-dind
docker stop build-reg

docker run --rm localhost:55555/test:latest

**デフォルトの名無しさん** · 2019/08/28(水) 20:16:24.43

いちお捕捉
working directory直下にDockerfile置いてな

**デフォルトの名無しさん** · 2019/08/28(水) 20:26:59.23

つうか本当にmac限定バグなのか
単に速度が遅いだけなのではと思った
for Macはディスクアクセスがやけに遅い気がする

**デフォルトの名無しさん** · 2019/08/28(水) 20:32:44.71

>>919
やってないけど、関係ないわ
docker clientのバグだから

**デフォルトの名無しさん** · 2019/08/28(水) 20:33:17.71

あとdocker buildのバグな

**デフォルトの名無しさん** · 2019/08/28(水) 20:35:18.65

>>921
mac限定のバグ。WindowsとLinuxでは
今まで1セット100ビルドを何十回もやっていて出てなかった

**デフォルトの名無しさん** · 2019/08/28(水) 21:15:43.36

>>922
だとするとclientだけコンテナにすりゃいんじゃね？

docker run --rm -v $PWD:/build -w /build \
-v /var/run/docker.sock:/var/run/docker.sock \
docker:latest build -tag test .

これ100回ぐらい流してみてくれ

**デフォルトの名無しさん** · 2019/08/28(水) 21:57:22.78

>>925
それはLinux版バイナリだからうまくいくよ。
ただね、100回ビルドするだけで3分もかかるんだよ。普通なら30秒。
「1セット100ビルドを何十回もやる」ような場合はちょっと苦痛
更に言うと「Windows」でもやるのでボリュームは使いづらい
それにしてもなんでmac版だけ壊れてるかな？

**デフォルトの名無しさん** · 2019/08/28(水) 22:01:15.18

ビルド100回を何度もするってのがなんか間違いを感じるのだが。

**デフォルトの名無しさん** · 2019/08/28(水) 22:02:48.52

各ディストリ、言語やライブラリのバージョンの違いの
組み合わせでテストしてるから

**デフォルトの名無しさん** · 2019/08/28(水) 22:27:45.82

>>928
dockerってそれをしないで済ますための仕組みなんじゃ。。

**デフォルトの名無しさん** · 2019/08/28(水) 22:29:52.82

>>929
いつかhomebrewとかaptとか無くなって
全部docker上で動くようになる時代がくるといいですね^^;

**デフォルトの名無しさん** · 2019/08/28(水) 22:32:16.66

kibanaで処理したら？

**デフォルトの名無しさん** · 2019/08/28(水) 22:32:55.74

kanikoの間違い

**デフォルトの名無しさん** · 2019/08/28(水) 22:37:10.79

なんか話がおかしい。
確かにホストの方はどうにもならんことはあるだろうが、
ゲストの中身をいろいろなディストリビューションで実装する意味が分からん。

**デフォルトの名無しさん** · 2019/08/28(水) 22:42:10.97

ゲストの中身をいろいろなディストリビューションで実装するなんて言ってないぞ
いろんなディストリビューションで（Dockerを使わずに）動かすんだよ。

例えばいろんなディストリで動くバイナリを生成するコンパイラの開発

**デフォルトの名無しさん** · 2019/08/28(水) 22:43:42.14

「いろんなディストリでビルドできて正常に動くことの確認」の方がわかりやすいか？

**デフォルトの名無しさん** · 2019/08/28(水) 22:59:13.43

だったらホストは無理にmac使う必要ないんでは？

**デフォルトの名無しさん** · 2019/08/28(水) 23:01:14.04

>>936
そうだよ？だからWindowsでもLinuxでも問題なくビルドできたので
今まで気づかなかった。だけど出かける時もありノートでも作業できるようにしたいわけ

それにしてもMac版だけdocker buildがフリーズすることに誰も気づいてないのかな？

**デフォルトの名無しさん** · 2019/08/28(水) 23:03:54.16

いやクラウド環境でも社内サーバーでも勝手に使ってやりゃいいじゃん。。
macにそこまでなんでこだわるかね。。

**デフォルトの名無しさん** · 2019/08/28(水) 23:24:16.17

>>937
githubのissueで調べるか出した方が良いのでは。

windowsとmacだとk8sの不具合が認識されていて、ネットワーク割当が原因と分かっているが、2年経っても治ってない。

dockerやk8sは基本的にLinux用。
後のOSは有志中心の開発だから不具合多い、と思った方が良い。

**デフォルトの名無しさん** · 2019/08/28(水) 23:32:48.79

ただ、ビルドを何周も回して動作確認する用途は明らかに本来の用途外だからどうかな。dockerではなく、メモリなどOSのオーバーヘッドかもしれないし。

**デフォルトの名無しさん** · 2019/08/28(水) 23:41:21.60

> ただ、ビルドを何周も回して動作確認する用途は明らかに本来の用途外だから

CircleCI全否定？（笑）

**デフォルトの名無しさん** · 2019/08/28(水) 23:45:14.48

並列でビルドしているわけじゃないんだからメモリはありえないし、
Mac版のdockerサーバーは仮想マシンのLinux上で動いてるんだから
Mac版のdocker clientの問題だろうね

**デフォルトの名無しさん** · 2019/08/28(水) 23:52:23.20

マルチプラットフォームで動作保証したいならDockerは使わずに実機か仮想マシン使った方がいいと思うけどな
Dockerで動いても生ホストでの動作保証にはぜんぜんならないでしょう(逆も然り)

**デフォルトの名無しさん** · 2019/08/28(水) 23:56:02.47

>>941
自分がやる時は中で操作して、動作をメモしてCIに移植するから、何周もビルドする事は無いな。遅いし。

**デフォルトの名無しさん** · 2019/08/28(水) 23:57:25.96

>>942
繰り返しになるが、Githubで聞いてくれ。
推論を重ねても意味がない

**デフォルトの名無しさん** · 2019/08/28(水) 23:58:06.35

CIは待ち時間が入るから遅いんだよね

**デフォルトの名無しさん** · 2019/08/28(水) 23:59:26.35

Mac版Docker clientが悪いのは推論じゃなくて事実だよ

**デフォルトの名無しさん** · 2019/08/29(木) 00:21:40.39

Open Stack にも、オーケストレーションのHeat、
コンテナ・オーケストレーションのMagnum とかある

Magnumは、Docker Swarm, k8s, Apache Mesos と連携する

**デフォルトの名無しさん** · 2019/08/29(木) 00:50:21.95

>>947
必要なのは悪者探しではなく、対策でしょ。内容的にstackoverflowでも回答無いと思う。

**デフォルトの名無しさん** · 2019/08/29(木) 05:29:15.00

まあ正直ツマラン流れだったな。情報小出しでもう少しマカがファビョって
荒れると面白かったんだが。面倒になったからさっさと終わらせるわ

再現コード、十数回でフリーズすると思うが、極稀に100回通ることもある
for i in $(seq 100); do echo $i; echo FROM alpine | docker build -; done

Mac版docker cilent 19.03系のみでフリーズする。18.09系なら問題なし。
Macで動かしてるdocker server 19.03に外部のLinuxのdocker client 19.03で
やった場合は問題なしだからどうみてもMac版docker clientの問題

**デフォルトの名無しさん** · 2019/08/29(木) 05:32:22.57

対策は19.03専用の機能は使ってないのでクライアントだけ18.09を使うことにした。
バイナリ配布されてるから~/binにでも入れるだけ。
世の中がバグに気づいてなおるのを待つことにする
githubへは面倒なので、だれかやって

**デフォルトの名無しさん** · 2019/08/29(木) 05:34:21.45

volume先のゲストのhtmlファイルをホストのブラウザからlocal host 3000で接続して
htmlの内容がブラウザに表示されたまではいいんだけど
htmlを編集してもブラウザが更新されてくれない(リロードしても編集前と同じ画面）
再度npm startするとちゃんと編集後のコードで更新されているんだけど、
少しの編集でも逐一チェックしたいのでとても不便・・・どうすればブラウザでも随時更新されるようになるのかな？？
手探りで、docker build時に -no--chace=trueを付けてみても駄目だった

**デフォルトの名無しさん** · 2019/08/29(木) 05:37:03.90

ふぅ、せっかく荒らして遊ぼうとしてるのに邪魔しないでくれないかな
docker関係ないだろ

**デフォルトの名無しさん** · 2019/08/29(木) 08:46:05.78

言ってることが糞野郎過ぎて話にならん。

**デフォルトの名無しさん** · 2019/08/29(木) 08:59:52.46

macOSネイティブ版で苦労するより
VMware Fusionでも買って Ubuntu でも入れて
出先のMacノートではそれで開発すれば？って気がするな。
下手するとネイティブより速かったりして。

**デフォルトの名無しさん** · 2019/08/29(木) 09:26:46.62

>>955
それな。MacのCLIってなんであんなに遅いんだろう？
WSLと大差ない。WSLができてMacで開発するメリット無くなったわ

**デフォルトの名無しさん** · 2019/08/29(木) 09:37:55.11

>>952
HTML を更新後に、ウェブサーバーで再読み込みするとか、再起動すれば？

**デフォルトの名無しさん** · 2019/08/29(木) 09:42:53.10

カーネルでのファイルシステムキャッシュとかの性能最適化が遅れてるんじゃない?

Windowsも遅いからクライアントOS志向だとその辺で手を抜くのかね？