Visual Studio Code / VSCode Part8
■ このスレッドは過去ログ倉庫に格納されています
>>429
ホストとコンテナのボリュームをマウントするときに、ホストがWindowsだといろいろめんどいのでWSL2も使うのがオススメ
Windowsで使う場合、WSL2で立てたlinuxマシンにRemote WSLで繋いで、そこからRemote Containersを使うのが良い >>429
そのDockerはWSL2上で動いてるんだぞ? WSL2のDockerはメモリ消費しすぎで使い物にならない WSL2とかじゃなくて時代はDockerなんですよ! コンテナにせよエミュレーションにせよ仮想化テクノロジが最重要であることは言うまでもない
ということは開発機は仮想化に強いMacかLinuxということになる
Linuxはデバイスサポート保障があるマシンのラインナップが魅力的とは言い難い
なので開発者はMacを買うべきという正解が導かれる デファクトスタンダードが決まったらまた連絡してくれ >>436
> ということは開発機は仮想化に強いMacかLinuxということになる
Macが仮想化に強いって何のこと?
MacはLinuxじゃないからDockerはそのまま動かないのに >>440
結論ありきで途中の過程がやる気無さすぎなんだろう Dockerの重要な点として手元で作ったDockerイメージを
そのまま本番環境でつかえるというのがある
しかしMacのCPUがARMになるからこれが難しくなった
本場環境の多くはIntelなのでCPUが違う
そうなると実機はIntel版LinuxのDockerイメージを使って
手元ではARM版LinuxのDockerイメージを使うか
パフォーマンスの低下を諦めて手元でIntel版LinuxのDockerイメージを
エミュレータを使って動かすしかなくなる
Macは開発に向かなくなってきている >>440
Macが強いというよりWindowsが弱いので相対的に良いってだけ Macの仮想化機能は限定的で、
Hypervisorフレームワークは用意しているが
それを使うためのインターフェースも持っていない
つまりサードパーティのソフトに頼らざるを得ないわけだ
HyperVとそれを扱うHyperVマネージャーを
OS標準で用意しているWindowsとは対照的 >>443
現時点で軽量VM使ってるから大きな変化はないのでは? >>444
Windowsの仮想化機能はMacを超えてるぞ
仮想マシン機能は当然備えているし
Macにはない仮想マシン管理アプリも付属
さらにWindows独自のコンテナ機能もある
Windows ServerコンテナというLinuxコンテナに近い機能と
Hyper-Vコンテナの二種類が用意されてる。
そしてDockerもWindowsコンテナに対応している >>446
軽量VMが何の関係があるのか知らんが、
MacのCPUがARMに変わったら
Linuxと同じDockerイメージが使えなくなるか
CPUエミュレーションで遅くなるという話をしてる
同じCPU上での仮想マシンとは違って
CPUが異なると大きなパフォーマンス低下が発生する。 >>448
> HyperVの完成度がお粗末
どこがおそまつなの?
それを言えないんじゃ説得力ゼロなんですよ。 HyperVの完成度の高さはDockerが実用的に動いていることからも明らか
WSL2だけではなくWSL1もHyperVを使っている >>447
標準の管理アプリは別に要らないと思う
実用性を考えるとDockerやVagrantのようなサードパーティツールと合わせて使うから
Windowsコンテナは使ったことないからわからないけどLinuxコンテナと比べると需要少なそう
バックエンドがなにか気にせずコンテナを管理できるから便利なのであって
バックエンドの種類が豊富でもあまり嬉しくないような?
2種類あるとなにが便利なの?
あなたが列挙した機能はもっともらしいメリットには思えないな
それよりもVirtualBoxとの共存で不具合が出やすいなどのデメリットのほうがより目立つ > 標準の管理アプリは別に要らないと思う
いるだろ。Macはユーザーインターフェースが不便なOSだって言いたいのか? VirtualBoxはいらんよ
なんで複数の仮想マシンが必要なんだw > バックエンドの種類が豊富でもあまり嬉しくないような?
> 2種類あるとなにが便利なの?
だからVirtualBoxはいらんよねw >>452
俺が話をしているのはWindowsの方が仮想化機能が充実しているという話
MacはHypervisorフレームワークしかない macOSはOS標準のコンテナ機能も搭載してないからな >>449
動かなくなることはないと思う
ただパフォーマンスのペナルティはあるかもしれない
でもインテルがアップルを追従せざるを得なくなるという話もあるしどちらが良いかは時間をかけて評価しないとならないだろうね
>>450
VirtualBoxとの共存で不具合が出やすい
ネットワーク関連のバグが出やすい
VagrantでHyperVプロバイダを使うと顕著 >>460
> VirtualBoxとの共存で不具合が出やすい
Windows標準の仮想マシン機能を使えばいいじゃんw >>451
Dockerが動くだけで完成度が高いと言えるならどんな仮想化プラットフォームでも高品質になってしまう
WSL2でDockerを使うとすぐにわかるけどvmmemがメモリを食いつぶして使い物にならない
これがバグ扱いじゃなくデフォルトの挙動というのがすごい >>462
一方macOSは仮想マシンに常に一定量のメモリを取られるんだが?
最大値を指定しなければ、Linuxの挙動との兼ね合いでそうなると言うだけの話
それはもう修正パッチができていたはず
そして最大値を指定した場合は、macOSの挙動と同じ
重要なことを忘れてないか?
Windowsの場合、使用しなくなったメモリを開放するようになった。
つまりmacOSのように常に一定量のメモリを取られるんじゃなくて
使用しなくなったメモリが開放されるようになった。
Build 19013」の「WSL 2」ではメモリーの使用効率が改善され、「WSL 2」の使い勝手が向上しています。
https://kledgeb.blogspot.com/2019/11/wsl-191.html >>453
いや必須ではないでしょう
サードパーティの仮想化プラットフォームを入れればUIはついてくるから標準に頼らなくてもいい
>>454
Virtualboxをメインに使うなら複数は必要ないけどDockerがHyperVを選ぶという愚行を犯してしまったから仕方なく複数つかうしかない状況
HyperVだけではVagrantのようなエコシステムを活かしきれない
HyperV(docker)とVirtualBoxを共存させると不具合が出やすい
このあたりがWindowsの仮想化は弱いという所以 >>465
UIもOSの機能の一つだから、それがないのは劣ってると言わざるを得ない
MacでVirtualBoxが必須なのは↓こういう話ですか?w
Virtualboxをメインに使うなら複数は必要ないけどDockerがHypervisorフレームワークを選ぶ
という愚行を犯してしまったから仕方なく複数つかうしかない状況 >>456
ハイパーバイザーフレームワークだけで十分だった
Windowsはむしろ余計なものを追加しやがってといった印象 とことんブーメランになってるよなw
HypervisorフレームワークだけではVagrantというエコシステムを活かしきれない(笑) >>468
「なんでMacにはOSの基本機能が搭載されてないの?」
「Macはサーバーじゃないんだからそんな機能は不要!」 >>467
Hypervisorフレームワークだけで仮想マシンにLinuxをインストールする方法を教えて下さい
あ、Macはフリーソフトを使えば出来る!が自慢でしたっけ?w >>461
HyperVだけじゃVagrantなど蓄積された仮想化エコシステムを活かせないんだよ
HyperVだけでは物足りない
なのにVirtualBoxを共存させると不具合が出やすい
かと言ってHyperVをオミットしたらDockerエコシステムが弱体化する
Windowsでは仮想化を活かしきれないんだ
完全にDockerだけを使う分にはWindowsでも許容範囲内なんだけどね macOSはCLI環境が弱いですからね。
ターミナルもみんなiTerm2とか入れるし
パッケージ管理は、サードパーティのHomebrewをインストール
そしてろくに動作検証もされてない
ただ収録しただけのパッケージを使うしか無い
CLI環境っていうか開発全般が弱いのかw >>463
メモリは32G詰んでる
でもどんなにハイスペでも簡単にメモリを食いつぶすように作られてるから意味ないよ
設定を変更すれば食いつぶすメモリ上限を設けることができるけど設定値まで食いつぶすのは相変わらず
リソース効率がいいのがコンテナのメリットなのにこれじゃあ意味が無い >>472
はぁ?VagrantはOSの機能じゃないし、もはや必要とされてない。
重い仮想マシン上のLinuxにログインして開発する時代は終わってるんだよ
OS標準のCLI環境とDockerを使った実行環境を使って開発する時代に変わった
いつまで旧式のエコシステムを使ってるの?
Dockerを使ったエコシステムに乗り換えろよ >>464
キャッシュに大量のメモリを食われるのは相変わらずと読めるね
キャッシュクリアのためにWSLログインしてコマンドうつの面倒でしょ >>466
いやいやUIなんてオプションですよ
なんならコンソールで済む
MacでもWindowsでもVirtualBoxが必須とは言っていない
DockerをやりたいだけならDocker for Desktopでどちらも問題ない
しかしDocker以外の目的で仮想マシンを使いたくなった場合Macは非常にうまく動作するがWindowsはそうではない
そう言ってるんで早く理解してください >>474
とはいえWindowsよりは幾分マシでしょうな
コマンドプロンプトでしたっけ?
あとはやけに動作が遅いPowerShell >>476
それはあなたがアプリ開発者だからでしょうね
確かにアプリ開発という狭い世界ではDockerがあれば十分かもしれない
でも世の中はアプリだけでは回らないので仮想マシンも必要になってくる
インフラのお勉強もしてみると視野が広がるのでオススメ >>482
あとはWSL用のターミナル(コマンドプロンプトと同じだがbashが動いてる)
そしてWindows Terminalもリリースされたね
もう完全に逆転されてるよw >>483
Macってインフラ弱いよね
Linuxのコマンドがことごとく使えないw >>484
逆に衰退してるように思える
どっちつかずの半端なシェルしかないからアレコレ併用せざるを得なくなって
しょうがないからWindows Terminalでタブ管理できるようにしました
これって完全に根本解決を諦めた人達の答えだよね >>486
> どっちつかずの半端なシェルしかないからアレコレ併用せざるを得なくなって
どっちつかずの半端なシェルとは?
その理由を言えないから説得力ゼロなんですよ あぁ、半端なシェルってタブがないだけという意味だったか。程度が低いな そういえばMac板にこんなスレがあった
macOSは同一Macの仮想マシン上のLinuxよりも遅い
https://egg.5ch.net/test/read.cgi/mac/1582504945/
>macOS上のDocker(OS標準仮想マシン)上のLinuxでbash(5.0.16)を動かした場合
>$ docker run -it bash /usr/bin/time -p bash -c 'for i in $(seq 10000); do (:); done'
>real 5.20
>user 2.47
>sys 2.46
>
>macOS上ネイティブでbash(Homebrewの5.0.16)を動かした場合
>$ /usr/bin/time -p bash -c 'for i in $(seq 10000); do (:); done'
>real 8.26
>user 3.07
>sys 5.08
>
>
>「仮想マシン上のLinux」よりも「macOS上ネイティブ」の方が遅い >>490
Macは半端なUnixだからそういうこともあるでしょうね >>488
レガシーなコマンドプロンプト
重いPowerShell
HyperVに依存した仰々しいWSL
等々
これが正解だってシェルが無い >>493
2の話をしてるからね
つうかWSL1なんて更に中途半端でしょ Windowsはbashもつかえるよ
bashだけじゃなくて全てのLinux用シェルがつかえる
macOSにとって正解だってシェルはzshのようだが
Windowsには選択肢がある(ドンッ!) >>496
ろくなbash処理系なかったと思うが何を使ってんの >>495
Macのターミナルなんてフリーソフトを使わないと
中途半端過ぎでパッケージないじゃんw
標準のパッケージ管理ソフトもないんだっけな >>497
> ろくなbash処理系
bash処理系なんていい方初めて聞いたわw
bash処理系がいくつかあるとか思ってんの?
間抜けやなぁ >>498
zshだけでもWindowsよりマシよ
パッケージ管理もbrewとかいろいろ選択肢あるし
そもそも標準である必要が全くないんだが >>499
幾つもあるよ
まさか全てのbashが同じバイナリで動いてるわけでもあるまい ああ、処理系ってバイナリの違いを言ってたのか。間抜けやなぁw >>500
Windowsはzshをつかえるようになりました。
パッケージ管理はmacOSよりも多くの選択肢を持っています。
さらにOS標準で持っていることが何より強いです Cygwinのbash,
MinGWのbash,
MSYSのbash,
WSLのbash
少なくとも4つあるよ。 >>504
MinGWにはbashなかったか。ごめん。 >>504
その理屈で、Ubuntu用のbash、Debian用のbash、CentOS用のbashとか言い出しそうだよねw >>133や>>437の背景になってる方法論の説明や両者のインスパイア先のサービス、それぞれの使用感など詳しいレビュー・解説が欲しい。
興味はあるんだがツールだけ紹介されても実用できねんだわ… >>441
別もんだっつーの。
WSL2未対応Windows10でもDockerは動作する。 JSの次はVMですか
Visual Studio Codeユーザーは民度が低いですね >>512
何が違うって言ってんの?
WSL2は正式リリースされたし、最新のDockerはWSL2上で動作する WSL2上で動作するというのはちょっと違うと思うけど >>516
WSL2はMSがカスタマイズしたLinuxカーネルを複数のディストリで共有して使っています。
そのHyperV上のLinuxカーネル=WSL2を使ってDockerが動いています。 >>515
>>517
あくまでオプションでな。
あたりまえのようにDockerとWSL2をまとめるなよ。 >>518
お前が何を否定したいのかわからん
DockerがWSL2上で動いてるのは事実だろ
HyperV上でも動くってだけ
まとめてるのはお前。Dockerを作った会社はMSではないことぐらい常識だろ DockerはMSの金がジャブジャブ投入されてズブズブ
もう実質MS傘下みたいなもんだぞ WSL2はリソース効率悪すぎてだめだ
素直にLinuxを使いなさい WSL2は自動的に使用メモリを減らすことが出来るから
リソース効率は良いよ 元々Docker Desktopはhypervが使えるpro以上でしか使えなかった
WSL2が使えるようになったのでhomeでも使えるこちらが主流になる >>428の話をしているところに文脈無視して>>435が割り込んできたのが原因だろうな >>519
じゃあWSL2未対応Windowsでも動作するのはなぜ?
>>524
いずれはそれだけになるんやろねえ。
>>525
謝りは正すのみ。 >>428のRemote Containersに対応しているのは
Hyper-Vで動くDocker DesktopとWSL2で動くDocker Desktop
>>431は後者しか知らなかったのかも知れないが
>>435は前者しか知らないから「別物」とかズレたレスをしている >>527
ついでにスレ誤りも正してくれませんかね? ■ このスレッドは過去ログ倉庫に格納されています