仮想環境コンテナ総合スレ Docker、Vagrant等 [無断転載禁止]©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
開発に仮想環境やコンテナを使う機会が多くなってきたので、みんなで情報交換しませう
よろしこ 普通、業務で使うならk8sだと思うが。分散や冗長化がdockerではできないからね。インストールがユーザー権限で出来るしdockerfileも使える。
完全な上位互換なんだが、代わりに手軽さは一切無いw そもそも無理な要件を期待してるんだから、要件の方を変えるべきだな。
Dockerでできることのほとんどは、Docker使わなくても手間が違うだけでできるわけだし。
無理だと分かってる要件を押し通そうとするのは無能。
押し通そうとしてるのが自分じゃなく上なら、そんな理不尽な職場は放棄して転職すべき。 macOS版のDockerで、docker buildがたまにフリーズするバグの回避方法ない?
このバグのせいでテストがまともに出来なくて困ってる。
WindowsやLinuxでは発生しない。
タイムアウト仕込んでリトライさせるしか無いかな >>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 いちお捕捉
working directory直下にDockerfile置いてな つうか本当にmac限定バグなのか
単に速度が遅いだけなのではと思った
for Macはディスクアクセスがやけに遅い気がする >>919
やってないけど、関係ないわ
docker clientのバグだから >>921
mac限定のバグ。WindowsとLinuxでは
今まで1セット100ビルドを何十回もやっていて出てなかった >>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回ぐらい流してみてくれ >>925
それはLinux版バイナリだからうまくいくよ。
ただね、100回ビルドするだけで3分もかかるんだよ。普通なら30秒。
「1セット100ビルドを何十回もやる」ような場合はちょっと苦痛
更に言うと「Windows」でもやるのでボリュームは使いづらい
それにしてもなんでmac版だけ壊れてるかな? ビルド100回を何度もするってのがなんか間違いを感じるのだが。 各ディストリ、言語やライブラリのバージョンの違いの
組み合わせでテストしてるから >>928
dockerってそれをしないで済ますための仕組みなんじゃ。。 >>929
いつかhomebrewとかaptとか無くなって
全部docker上で動くようになる時代がくるといいですね^^; なんか話がおかしい。
確かにホストの方はどうにもならんことはあるだろうが、
ゲストの中身をいろいろなディストリビューションで実装する意味が分からん。 ゲストの中身をいろいろなディストリビューションで実装するなんて言ってないぞ
いろんなディストリビューションで(Dockerを使わずに)動かすんだよ。
例えばいろんなディストリで動くバイナリを生成するコンパイラの開発 「いろんなディストリでビルドできて正常に動くことの確認」の方がわかりやすいか? >>936
そうだよ?だからWindowsでもLinuxでも問題なくビルドできたので
今まで気づかなかった。だけど出かける時もありノートでも作業できるようにしたいわけ
それにしてもMac版だけdocker buildがフリーズすることに誰も気づいてないのかな? いやクラウド環境でも社内サーバーでも勝手に使ってやりゃいいじゃん。。
macにそこまでなんでこだわるかね。。 >>937
githubのissueで調べるか出した方が良いのでは。
windowsとmacだとk8sの不具合が認識されていて、ネットワーク割当が原因と分かっているが、2年経っても治ってない。
dockerやk8sは基本的にLinux用。
後のOSは有志中心の開発だから不具合多い、と思った方が良い。 ただ、ビルドを何周も回して動作確認する用途は明らかに本来の用途外だからどうかな。dockerではなく、メモリなどOSのオーバーヘッドかもしれないし。 > ただ、ビルドを何周も回して動作確認する用途は明らかに本来の用途外だから
CircleCI全否定?(笑) 並列でビルドしているわけじゃないんだからメモリはありえないし、
Mac版のdockerサーバーは仮想マシンのLinux上で動いてるんだから
Mac版のdocker clientの問題だろうね マルチプラットフォームで動作保証したいならDockerは使わずに実機か仮想マシン使った方がいいと思うけどな
Dockerで動いても生ホストでの動作保証にはぜんぜんならないでしょう(逆も然り) >>941
自分がやる時は中で操作して、動作をメモしてCIに移植するから、何周もビルドする事は無いな。遅いし。 >>942
繰り返しになるが、Githubで聞いてくれ。
推論を重ねても意味がない Mac版Docker clientが悪いのは推論じゃなくて事実だよ Open Stack にも、オーケストレーションのHeat、
コンテナ・オーケストレーションのMagnum とかある
Magnumは、Docker Swarm, k8s, Apache Mesos と連携する >>947
必要なのは悪者探しではなく、対策でしょ。内容的にstackoverflowでも回答無いと思う。 まあ正直ツマラン流れだったな。情報小出しでもう少しマカがファビョって
荒れると面白かったんだが。面倒になったからさっさと終わらせるわ
再現コード、十数回でフリーズすると思うが、極稀に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の問題 対策は19.03専用の機能は使ってないのでクライアントだけ18.09を使うことにした。
バイナリ配布されてるから~/binにでも入れるだけ。
世の中がバグに気づいてなおるのを待つことにする
githubへは面倒なので、だれかやって volume先のゲストのhtmlファイルをホストのブラウザからlocal host 3000で接続して
htmlの内容がブラウザに表示されたまではいいんだけど
htmlを編集してもブラウザが更新されてくれない(リロードしても編集前と同じ画面)
再度npm startするとちゃんと編集後のコードで更新されているんだけど、
少しの編集でも逐一チェックしたいのでとても不便・・・どうすればブラウザでも随時更新されるようになるのかな??
手探りで、docker build時に -no--chace=trueを付けてみても駄目だった ふぅ、せっかく荒らして遊ぼうとしてるのに邪魔しないでくれないかな
docker関係ないだろ macOSネイティブ版で苦労するより
VMware Fusionでも買って Ubuntu でも入れて
出先のMacノートではそれで開発すれば?って気がするな。
下手するとネイティブより速かったりして。 >>955
それな。MacのCLIってなんであんなに遅いんだろう?
WSLと大差ない。WSLができてMacで開発するメリット無くなったわ >>952
HTML を更新後に、ウェブサーバーで再読み込みするとか、再起動すれば? カーネルでのファイルシステムキャッシュとかの性能最適化が遅れてるんじゃない?
Windowsも遅いからクライアントOS志向だとその辺で手を抜くのかね? >>957
>>958
ありがとう〜
多分npmのキャッシュが原因なのかなぁ
nodemonっての使って更新されるようになったけど
結局はnpm startをリスタートしているだけで待ち時間が少し早くなった程度
dockerはむつかしい^p^ マカーさんの自己顕示欲は異常だわ
Docker以前のおま環のことで荒らすなや
きくちももこ学生です並のウザさは健在 19.03.2がリリースされたけど直ってなかったな
やっぱりMacでdocker buildがフリーズする >>962
再現性あるならgithubにでも書いてきたら?
どういう運用かわからんけどcoreutils周りとか
同じコマンド名で挙動が違うのにひっかかってるだけじゃないかって気が >>963
これで再現するっていってんでしょ
for i in $(seq 100); do echo $i; echo FROM alpine | docker build -; done
運用が何の関係があるのかさっぱりわからん
(バグを)運用でカバーすれば大丈夫だからバグじゃない!とか言うつもり?
バグはバグだよ >>964
こんな便所の落書きでボヤいても直りゃしないからちゃんと報告しろっていう話よ >>966
再現や英語書きで2時間くらいは最低でもいるから
1人月150万円だと2万円は必要な作業なわけだがもしかしてタダで人を使おうってこと?
ホントに仕事として請け負うならやり取りのフォローアップも考慮して10万円コースよ。 >>964
>バグはバグだよ
とはいえユースケースが想像しにくいテストコードでのバグってのは
みんな対応したくないもんで。
もっと重いコンテナでも同じように落ちる?
特定のコンテナだけだったりする? >>967
そういうこと。2万円は必要な作業を俺はやりたくないw >>969
> とはいえユースケースが想像しにくいテストコードでのバグってのは
ユースケース? docker buildのユースケースがわからないの?
docker buildを行うとn%の確率で固まるっていう不具合なんだけど
運が悪ければ、1回目で固まる。 >>969
> もっと重いコンテナでも同じように落ちる?
自分で試せよ。どんなイメージも関係ない
docker buildがまれにフリーズするというバグ お、誰か書き込んでるなw
ただクラッシュじゃないんだよね。
おそらく排他制御とかでデッドロック状態にでもなってるんだろう
18.xまでは問題ないから19.xのBuildKit周り(の並列処理)が怪しそう >>972
docker buildを行うとn%の確率で固まる
特定のコンテナに限らない
reprexは
for i in $(seq 100); do echo $i; echo FROM alpine | docker build -; done
と初めからから書くとみんな幸せだと思う >>918で書いてるぞ
> macOS版のDockerで、docker buildがたまにフリーズするバグの回避方法ない? issue出てるなら一旦待ちだろ。
kubernets関係の起動しないトラブルも2年近く治ってない。
windowsやmac版はそんなもの。 なるほどパイプラインのタイミングの問題とか全く分からず使ってるバカなんだな。 固まったり固まらなかったりすることと
パイプラインの問題(?)と何の関係があるの?
そもそも、お前が知ってるパイプラインの問題って何さ? みんなサーバサイド開発してる人が多いだろうからDockerが人気なんだろうけど、俺的には「macOSコンテナ」が欲しいな
特定のプロジェクトをビルドする環境を構築したり保存したりできたらいいのにな Windowsは「Windowsコンテナ」があって、DockerもWindowsコンテナに対応してるけど、
macOSにはコンテナってないのか?
曲がりなりにもUnixなんだからchrootはあるはずだが、
プロセス分離するとかそれ以外の機能が足りないのか? GUI無しで使うメリットがほぼ無いから
作る人が居ないだけなんじゃないかと 正確にはMacはGUIなしじゃ使い物にならない。
LinuxとWindowsはCUIだけでも使いものになるから
コンテナがある。という話? いや、WindowsよりmacOSの方がCLIなツールは充実してるよ。
単にAppleにコンテナ技術に関するやる気がないってだけの話。 WinもWSLでLinux用CLIツール使えるようになったし、Macとそう変わらんのでは ・WSLは追加で入れる必要があるけどmacOSは最初から一通り入ってる
・WindowsのネイティブGUIアプリと
WSLは別のサブシステムで動いていてやり取りに制限があるのに対し、macOSのネイティブGUIアプリとCLIツールは同じ世界で動いてるのでそういう制限がない
のでmacOSの方がまだちょっとCLI環境的には強い OS本体のコンテナ化に関する話でしょ。Macはブランドに固執してるからOSをコンテナにする事はなさそうだ。同じ理由でOSをPCで動かない設定にしてるわけだし >>986
> ・WSLは追加で入れる必要があるけどmacOSは最初から一通り入ってる
MacのCLIはApple非公式のHomebrewを別途入れないとまったく使い物にならんぞ 今Macで開発してるような技術者はUnixやCUIが好きだからWindowsよりMacを選んでると思うね
となると仮想Linuxベースになろうが抵抗感が無いからMacネイティブへの需要はなかなか少なくんじゃないのかなぁ 重要なのはいまMacで開発してる人じゃなくて
今Linux向けアプリ(クラウド関係はゲームも含めてほぼ全て)を
作ってる人はLinuxを選ぶってことだよ。
MacはBSD系だから今の時代少数派に分類される BSD→Linuxは割と簡単
Linux→BSDはストレスが溜まる
なぜならBSDのコマンドはLinuxのものと比べて低機能だから。
さらにLinuxの情報が使えない上にBSDの情報が少ない
BSDといってもFreeBSDとかとも違うから実質Macだけの情報しか使えない >>988
まったくというわけでもない。
WSLなしのWindowsに比べれば、素のmacOSの方が100倍くらいは便利。 >>991
>BSD→Linuxは割と簡単
>Linux→BSDはストレスが溜まる
>
>なぜならBSDのコマンドはLinuxのものと比べて低機能だから。
一丸には言えない
>さらにLinuxの情報が使えない上にBSDの情報が少ない
manが読めない人にはそうかもね
BSD→Linuxソフトウェアが古すぎて腰を抜かす なんでWSLなしのWindowsと比べるんだろう?
それってエンジンなしの自動車に比べれば
自転車のほうが速いって言ってるようなもんやでw
> 一丸には言えない
いえるいえる。全部低性能
> manが読めない人にはそうかもね
manもLinuxの方が多い。それにBSDだと--helpがめっちゃ少ないしw
> BSD→Linuxソフトウェアが古すぎて腰を抜かす
古いのって例えば何? BSDをまともに使ったことがないのはよーくわかった
ssh,nginx,bash,zsh,tmux,mariadb,python,named,postfix,syslogd,clang,h]gccほぼ全部において古い
manが追いついてないコマンドいくつあると思ってんよ BSDの何が駄目かって、POSIXで規定されてる
基本コマンドが貧弱なんだよ。
最低限しか実装されていない。
よく使う基本コマンドだから困る https://ja.wikipedia.org/wiki/BusyBox
> 1996年、ブルース・ペレンズが書いたのが起源である。Debianディストリビューション用の
> レスキューディスクにもインストーラにもなるフロッピーディスク1枚の完全なブート可能システムとして設計した
1. busyboxはLinuxのためのもの
2. BSDはレスキューディスクと比べるぐらい機能が低い このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 952日 14時間 18分 59秒 レス数が1000を超えています。これ以上書き込みはできません。