仮想環境コンテナ総合スレ Docker、Vagrant等 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
開発に仮想環境やコンテナを使う機会が多くなってきたので、みんなで情報交換しませう
よろしこ >>717
EBSを使ってもいいが、アプリの仮想マシンからブロックデバイスとしてマウントはしないんだよ。
EBSをマウントするのは(広い意味での)データベース・サーバーの一台
アプリからは、そのデータベースサーバーに対してネットワークでデータを読み書きする
複数あるアプリの仮想マシンでファイルシステムをマウント(Dockerのボリューム含む)しようという発想が古い
ストレージをマウントするのは仮想マシン1台だし、そこにネットワーク経由でアクセスする。
↑このストレージをバックアップなど含めて適切に管理するのが面倒だから、クラウドストレージを使う
いずれにしろ、アプリからはネットワーク経由でデータの読み書きをする >>717
例として挙げただけなのでどのストレージサービスでも状況は同じ
>718
ストレージサービスをネイティヴサポートしてない他社製アプリはVolumeマウントするしかないと思うけど違うのかな?
オープンソースならフォークしてファイルアクセスを全てストレージサービスに置き換えることはできなくはないけど労力に到底見合わない
だからどうしてもVolumeマウントに頼らざるをえないケースは多々ある
そういうケースにステートフルコンテナをクラスタに組み込むにはどうするべきか悩ましい >>721
だからな? 新しい仕組みを活かそうと思うなら、
設計から見直さなきゃいけないんだよ。
効率化する新しい仕組みを導入したいのですが
今までの効率の悪いやり方まま変えたくないんです。
↑アホみたいだろ?
やり方を変えないなら、今までのやり方をするしか無いんだよ。
諦めな >>722
設計を見直すと言われても他社製だからな…
従来のようにバックアップとリストアをしっかり整備して多少のリスクを受け入れるぐらいしか思い浮かばん
ダウンタイムはともかく直近のデータロストは怒られそうできつい docker hubがハックされてgitアカウントが19万ぐらい失効されたらしい? dockerのGUIでの監視や起動停止とかでまだまともなのないかね? 5人のチームのローカル開発環境を同じにしたい場合VagrantとDockerどちらが楽だろ?
VagrantfileとDockerfileのどちらが簡単かという話になるのかな? そりゃあVagrantだろ
変なトラブルが少ない
開発デスクトップも仮想化できる
環境の再現性がたかい
Linux+Windows混在も楽々
ただしターゲットがDockerの場合に限りローカル鯖もDockerにした方がいい
それは当然のことだな
その場合でも開発デスクトップはDockerを使わないほうがいい 開発に使えないものを本番環境に投入とか論外なわけで
Dockerの使いどころが...
(それを言っちゃあおしまい) 使えるか使えないかの問題じゃなく楽かどうか
本番でDockerを使わないなら本番環境はDockerへの配慮なんてしてない構成になってるはず
その構成をローカルに再現するときにDockerを使うかVagrant/Ansible使うのどっちが工数少ないかってことだ
少なくとも本番環境の構築手順書があるのだから完全仮想化環境で同等の環境を再現するのはさほど難しくない
しかしDockerだとどうしても構成の整理と手順書の読み替えと動作確認が求められてくるので面倒だ >>731
> 5人のチームのローカル開発環境を同じにしたい場合VagrantとDockerどちらが楽だろ?
何度も言ってるが、仮想マシン(Vagrant)とアプリ仮想化(Docker)は
組み合わせて使うものです!
どちらか一方を使うんじゃない。役目が違うんだから両方使う 大前提としてな。開発環境と本番環境は同一に出来ないんだよ。
可能不可能の話じゃなくて、そんな事やるやつは馬鹿という意味で同一に出来ない
開発環境はVagrantで作るが本番環境はAnsibleなどで作る
開発環境には便利なテキストエディタやIDE、ヘッダファイル、静的解析ツール
その他便利なコマンドなど、いろんなものを入れる必要がある。
それに対して本番環境はそれらは入れない。セキュリティリスクにつながるし
メンテナンス性も考えなるべく小さなイメージにしておく
開発環境と本番環境は同一でないという前提で、
開発環境でどうやってテストするか?という話が出てくる
本番環境に近い環境でないとテストに自信が持てないのは当然
そこでDockerがでてくるんだよ。開発環境で動かすDockerコンテナと
本番環境で動かすDockerコンテナを同一に(もしくは限りなく近く)することで
開発環境と本番環境が違っていても、信頼性のあるテストが実行できる
そうするとDockerコンテナさえ同じであれば、開発環境を統一する意味もなくなる
開発環境がLinuxであってもWindowsであってもMacであっても、
同一のDockerコンテナを使うのだから、信頼性のあるテストが実行できる
だから今はVagrantを使って開発環境を統一するメリットが減ってる。
統一したいならしてもいいが(それは開発者の自由を奪うというデメリットでもある)
統一しなくても良いのが今の開発 >>737
本番環境が全てDockerという幻想の上でしか成立しないな
本番環境がDockerでないなら開発環境でDockerを使うと逆に再現性が低下する 最初の質問に戻るとだな
> 5人のチームのローカル開発環境を同じにしたい場合VagrantとDockerどちらが楽だろ?
「ローカル開発環境を同じにしたいならVagrantを使う」
それと同時にDockerも使う
Dockerを使うなら、ローカル開発環境を同じにする意味はさほどない
同じにしないなら Vagrantを使わなくて良い。Dockerだけ使う
これは「ローカル開発環境を同じにしたい場合にDockerが楽」と言ってるのではなくて
「ローカル開発環境を同じにしないならVagrantはいらない」という意味
だから「ローカル開発環境を同じにしたいならVagrantを使う」ということは否定していない
使う目的が違うのだから、どちらを使うか?っていう話にはならない >>738
もう今は本番環境でDockerを使うのは常識
仮に本番環境でDockerを使わないとしても、
本番環境と同じ環境をDocker以外で作るのは困難
開発環境用VM(Vagrant)と本番環境用VM(Vagrant)の
2つを作るのは重いだけ 訂正
開発環境用VM(Vagrant)と本番環境"再現用"VM(Vagrant)の
2つを作るのは重いだけ
本番環境用VMといってしまうと、これを本番環境で使うように思えてしまうので訂正
実際の本番環境はVagrantでは作らないので、本番環境そのものにはならない
高い再現性を求めるなら、開発環境でも本番環境でもDockerを使うのがベスト 開発環境と本番環境が違っていても
Dockerコンテナは同じですよーっていうのが
Dockerを使うメリットなわけだ vagrantは "開発環境を作るためだけ" のものだが
Dockerはソフトウェ開発全般で使う k8sのdocker依存は解消されたって聞いてたんだけど…? Vagrantはこれから使われなくなっていくよ。俺はもう使ってない。
ローカル開発環境を同じにしたい場合にはたしかに便利だが、
ローカル開発環境を同じにする必要がなくなってきてる。
そういう意味ではVagrantを使わないほうが良いと言える。 >>749
依存してなくても事実上Dockerを使うのが現時点ではベストという話 >>748
Vagrantは本番環境でも使えるしDockerを使わない開発も未だに無数にある
Dockerのメリットは確かに大きいがそれなりのデメリットも同時に抱え込んでしまう
Dockerでやるべき明確な理由がないなら使う必要はない > Vagrantは本番環境でも使えるし
使えるが使わん。 https://www.vagrantup.com/
Development Environments Made Easy
^^^^^^^^^^^^^^^^^^^^^^^^^^^
「開発環境を簡単に」と書いてあるんだから
本番環境で使おうとするな。想定外の使い方だ Dockerの使い方でも変なやつがいるけど
本来想定してない用途なのに、使えそうだから使おうというのは
その技術を正しく理解してない証拠なんだよな VagrantにできてDockerではダメな典型例だとAnsibleなど構成管理ツールの開発・テスト環境を作るときなどがあるね
当たり前だけどOSの様々な機能が制限されるコンテナは仮想マシンの代替にはなりえない だからVagrant(というよりVM)とDockerはどちらかを使うものじゃなくて
両方組み合わせて使うものだという話になる。
AnsibleのテストするならVMを使うのが一番。各クラウドやKVM等ね。
というかAnsibleのテストでVagrantなんて使うか?
Vagrantで作ったらVagrantユーザーがいるわけで、
それは本来のAnsible実行対象マシンとは違うものになる。 × コンテナは仮想マシンの代替にはなりえない
○ (アプリケーション)コンテナはそもそも仮想マシンの代替として作られたものじゃない >>757
組み合わせて使っても良いが
常に組み合わせて使う前提のものではない
>>758
だから君のDocker万能論はちゃんちゃらおかしいということだよ
開発環境は開発対象をよく理解して適切に選ぶこと
全部DockerでOKなんてことはありえない あぁ、なるほど。素晴らしい気付きがあった。
Ansible(Chefなども同様だろう)を使うといった時、
playbookを作る のと playbookを実行する という2つの段階がある
playbookを作る場合は、当然テストが必要なわけだがVagrantが便利。
なぜならVMを特定の状態にして何度もplaybookをやり直すから。
具体的にはsnapshotの機能を使う(最初からvagrant boxを作り直すのもあり)
でもこれって、Ansibleに内蔵されているべき機能ではないだろうか?
Vagrantで作るVMと本番環境のVMは違っている。
本当は本番環境(を複製して)を何度も同じ状態にしてテストを実行したいはずだ
通常、本番環境のVMの構築にVagrantは使わない。Ansibleを使って構築するだろう。
ならば、Ansibleだけで本番環境のVMのスナップショットを取れたほうが良いだろう。
今はそれが出来ないからVagrantを使っている。
なるほど、これは良い発見だ!
(独り言) >>759
> だから君のDocker万能論はちゃんちゃらおかしいということだよ
何度もDockerとVMは組み合わせて使うって言ってるのに、
なんで俺のことをDocker万能論者に仕立て上げようとすんのさ? > 全部DockerでOKなんてことはありえない
そんなこと言ってない。
何度も何度もVMと組み合わせて使うって言ってるのに そうだな万能論は言いすぎた
しかしそれでも君の主張はDockerありきが前提にっているのは確かだろ
しかし実際にはAnsibleの例のようにDockerを使いにくい環境も存在している
だから君の主張がおかしいということには変わりはない >>763
やっぱり素でDockerを理解してないんだな・・・
> しかし実際にはAnsibleの例のようにDockerを使いにくい環境も存在している
Dockerはアプリケーションとユーザーランドを一体化させて
一つのアプリケーションのように仮想化するためのものであって
Ansible(構成管理ツール)とDocker(アプリ仮想化)を組み合わせて使うことがそもそも間違い。
俺はAnsibleとDockerを組み合わせて使うなんて一言も言ってない。
俺の主張?俺が何を主張したっていうんだ? >>764の組み合わせて使うっていうのは、
DockerをVM(Vagrant)のようの代わりに使って
DockerでAnsibleなど構成管理ツールの開発・テスト環境を作るという使い方
Ansibleを使ってVMの構成管理を行い、その一つとして
Dockerコンテナを起動するっていう使い方は問題ない。
俺は、DockerでAnsibleなど構成管理ツールの開発・テスト環境を作るという使い方をしろなんて
一言も主張していない 結局俺じゃなくてお前が
DockerをVM(Vagrant)の代わりに使おうとして
DockerはVM(Vagrant)の代わりとしては使えない!って
独り相撲してるだけじゃんか
俺は最初から組み合わせて使う。両方使う。役割が違うと言ってる。 >>764
君の主張は自分のレスを読み返したら?
開発環境はとにかくDocker
Dockerなしなんてありえない
それが世界の常識
君は昨日散々そう主張していたよね
そんな主張をしたら例えばAnsibleの開発環境みたいなDockerに向かない環境もDockerで組むのかなこいつはと解釈されても仕方がないよ >>767
お前が見返して、どこで言ってるのか指摘してくれ
俺はお前が言ってることを何一つ主張してない 例として一つ出すなら
>>737で
> 開発環境はVagrantで作るが本番環境はAnsibleなどで作る
開発環境はVagrantで作るとはっきり言っている >>769
だからそれをお前がやれって言ってる。
お前嘘つきじゃん。さっきからどれもコレも俺が主張してないことを
俺が言ったことにしようとしてさ >>770
で、そのレスの後半でDockerを使う話に持っていってるよね
とにかくDocker
Dockerありき
それが世界の常識
それが君の主張 > で、そのレスの後半でDockerを使う話に持っていってるよね
ぽかーんw
スレの前半でDockerを使わない話してるよね?
お前、スレの後半しか読んでないの?
スレの後半だけで判断しちゃった?w >>771
やれもクソも君の目の前のブラウザか専ブラかをちょっとスクロールして見るだけだよ
俺がやることなど何もなく君が自分のレスを見るだけだ
それを俺が代行してやることは物理的にできない >>773
後半を主張するための前振りだろ?
だって君の主張はDockerありきが世界の常識だもんな >>776
何度も何度も何度もVMとDockerは組み合わせて使うと言ってる
お前が、VMとDockerはどちらか一つを排他的に使うものだって
心の底で思ってるから、俺がDockerを使うという話をすると
VMを使わないと言ってるんだって勘違いしてるんだよ。 >もう今は本番環境でDockerを使うのは常識
>
>仮に本番環境でDockerを使わないとしても、
>本番環境と同じ環境をDocker以外で作るのは困難
>
>開発環境用VM(Vagrant)と本番環境用VM(Vagrant)の
>2つを作るのは重いだけ
ほーん
Ansibleの本番環境と同じ環境もDockerで作るんだ
なんたってDocker以外で作るのは困難だからなー
それが世界の常識ってやつですかそうですか > Ansibleの本番環境と同じ環境もDockerで作るんだ
また俺が言ってないことを言い出した。 >>777
VMを使わないことではなくDockerを使うことが前提になっている点がおかしいと言ってる >>780
本番環境を同じ環境をローカルに作る場合
Dockerを使った構成にしないと作るのは困難だって言ってる
本番環境(の多くは)ベアメタルもしくは仮想マシンにLinuxを入れる
ローカルの開発環境はベアメタルにLinuxを入れることは少ない
ローカルの開発環境は
1. Linuxを使う
2. macOSを使う
3. Windowsを使う
4. それ以外
この三種類。2と3は確実に本番環境と違う。1はLinuxで同じだが
ローカルの開発環境には開発ツールが必要なので、これも本番環境と同じになることはない
4.のそれ以外として、1〜3の開発環境を使い、それとは別に本番環境"再現用"VMを作る方法
>>742で書いているように、2つを作るのは重いだけ
そして本番環境はVagrantを使って作らないが、本番環境"再現用"VMはVagrantを使って作るという違いがある
本番環境"再現用"VMをVagrantを使って作ると、Vagrantユーザーがいたりして、本番環境とはやっぱり違う
作成した時期によってパッケージのバージョン等が異なる。
本番環境はVagrantじゃないから同じVagrant Boxを使って環境を合わせることも出来ない。
本番環境のベアメタルもしくは仮想マシンにLinuxを入れて作るものに近づけるには
ローカルの開発環境に用意する 本番環境"再現用"VMも(Vagrantを使わずに)
VirtualboxやKVmやHyperVなどの上に直接作る必要がある。
だけどそれをやったとしてもやっぱりパッケージのバージョンを合わせるのは難しい。
その問題をDockerを使った構成にすることで違いをカーネル部分(ここは高い互換性がある)だけに分離することができる。
カーネル以外のアプリケーション+ユーザーランド、つまりパッケージのバージョンは全く一緒になる
このレベルを実現するにはDockerを使わないと困難だと言ってる >>782
何に反論すれば良いのさ?w
お前の書いた嘘? そのゲームのプロセスID か何かを取得して、
OS・ディスプレイマネージャーに対して、
そのゲームを最前面に表示するように、命令できないの? dockerってメモリ4GB だと重いですか?docker使って仮想環境作る勉強したいんですが >>789
Linuxで使えば仮想マシンも不要でネイティブに動く
メモリも数MB程度のオーバーヘッドだけですむだろう Windows環境なんでwslでubuntuはインストールしたんですけどそのままdocker落として仮想マシン構築する事出来ます? Windows 10デスクトップだと4Gは厳しい
仕事で仕方なく使ってるけどメモリ不足で起動失敗が多発する
Windowsコンテナのプロセス分離だけに限定すればいけるかもしれんが…
Winコンテナは興味なくて検証したこともない
WSLでDockerは動かない
次の大型アップデートでWSL 2が実装されるけどそっちではDockerも簡単に動かせる
Docker for WSL 2のサポートも決定事項
こっちの必要スペックはわからん 今のvirtualbox使ったwindows dockerはクソだと思うが
Docker for WSL 2 は期待していいんでないかな。 今のDocker for WindowsはVirtualBoxなんざ使ってねぇぞ Docker for Windowsも、Docker for Macも
どちらも仮想マシンを使っています virtualbox使ってるのはdocker toolboxの方 てか現状、hyper-vない環境のが多い訳でwinでdockerいうたらそれだよね。 wsl2のアーキテクチャ、hyper-v必須に見えるんだけどhome切り捨てか? はぁ、homeも対応するって発表しただろ
hyper-vのサブセットを提供するって。少しは調べろよ >>801
マジかサンキュー!
俺の調査完了だぜw Windows10 Home
HP ENVY Ryzen7 3700U を使用しています。
https://dotup.org/uploda/dotup.org1884129.png
BIOSの方で仮想化設定をONにして、タスクマネージャーで確認しても「仮想化 有効」に
なっているのにかかわらず、Docker Quickstart Terminal を起動すると
「仮想化がenableになっていません。」とエラーが出て終了してしまいます。
どうすれば通常通り起動できるようになるでしょうか。
どなたか心当たりある方いらしたらお教えいただけないでしょうか・・・。 >>803
Docker Toolboxは古い
Docker Desktop for Windowsを使え wsl2まで待つかwin10pro買うかどっちかを勧める。 dockerのimageファイルをブラウザからダウンロードできるサイトないですか?
特殊なインターネット接続なし環境で構築しており,インターネット接続環境はブラウザしか起動できない状況です。 っていうか、業務に必要なことなら、必要って言えばいいだろ
仕事で苦労してる責任が管理者にあるなら管理者に責任を押し付けろや。
コストがあがったのはあんたが認めないからです。責任はあんたにありますって 小さい組織の末端の開発者ならそれでいいかもしれん
大きな組織だと特定の開発者のコストを下げても必ずしも全体のコストが安くなるわけではない 大きな組織だと、その判断を末端の開発者がしてはいけない。
つまり、言いたいことは、"上に投げつける前に個人の判断で諦めるな" ということ
上に投げつけて、上の責任にするんだよ。 >811
理屈はわかるがそんなこと実際にするのはかなり丁寧に組織的根回ししないと無理だろ。
そんなことができるくらいならこんなとこに相談こねーわ。 イミフ。上に言うだけやろ。こういうことで困ってますって。 小さい組織でやってるとこういう苦労はわからないものさ
責任が小さいから自由もある だーかーら、上に相談することも出来ないのか?って言ってるんだが >>813
お前がそれで解決しないという現実を知らんだけ。 解決するかしないかは関係ないんだよ。
上の責任にしろって話。
責任を押し付けないから、上は適当に仕事するんだよ。
おめぇの責任だって言えば上は逃げられなくなるからな。 与えられた裁量の中で成果を出すことが求められている
もっと権限をよこせよこさないならうまくいかないぞそうなったらおまえのせいだかんななどと喚くのは無能だ
組織で働いたことがねえんだろうなあ > 与えられた裁量の中で成果を出すことが求められている
どんな校則でも絶対に守る生徒 VS 校則の内容に疑問を持つ生徒
ほんとなぁ、日本の学校教育の失敗やで。
意味のないルールでも絶対に守れ。疑問を持つことは許さない
という教育をしてるからこうなる。 ■ このスレッドは過去ログ倉庫に格納されています