仮想環境コンテナ総合スレ Docker、Vagrant等 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
開発に仮想環境やコンテナを使う機会が多くなってきたので、みんなで情報交換しませう
よろしこ >>592
dockerにとってubuntuは材料に過ぎない
ubuntuという材料をベースにDockerfileを書いてアプリを作る
そういうことが簡単にできるように作られたのがdocker つまりubuntuっぽい(というか見た目は変わらない)動作をするアプリが動いてるだけってことか
ありがとう マイナーなツールでフォアグラウンド起動のしかたがわからない場合どうする? フォアグラウンド起動の方法がないじゃなくて
わからないだけなら、調べろとしか 所詮はDockerって省エネを目指した仮想環境に過ぎないからね
そんなこと気にしなければVagrantがベスト dockerとvagrantという全く違うものを
比較している人に言われましてもw 用途がかぶる部分があるので比較する意味は有る
自転車、自動車、鉄道、飛行機は全く違うものだけど、移動するためのものという用途は同じ
旅行や通勤の際にこれらを比較する価値は大いに有る
vagrantとdockerも同様 基本的にはファイルシステムだけカプセル化してるんだっけか?
でもportなんかもカプセル化してるし、どこまでを閉じ込めてるか結構微妙。 >>601
アプリケーションを動かすのに必要なもののうちOS以外の部分を
アプリケーションに内包させていると考えればいい >>599
なにかアプリを使おうと思った時、わざわざ別マシンを用意して別の環境で動かすのが仮想マシン
今自分が使ってる環境の上でアプリを起動するのがDocker
ぜんぜん違う >>601
そんな抽象的で意味のない答えは求めてない。 >>603
抽象化ができないエンジニアには難しいかも知れないが
ホストと隔離された環境でなんらかのアプリを使うという抽象的な目的は同じなんだよ
基本になってるテクノロジが違うけどそこは同じ
なので比較検討することには意味が有るわけだ
例えばローカル開発環境を構築するという抽象に対してDockerあるいはVagrantという具象が有る
もちろんそういう意味ではホストに必要なパッケージをインストールするだけの素朴な構成も比較検討に値する
完全仮想化とコンテナ仮想化は違う技術だから比較に値しないなんてのは表層しか捉えられないなにもわかってない人の発想なんだね 技術が違うんじゃなくて、目的が違う
ここまで理解能力がないと、本当に話にならない。 Dockerの典型的な利用例の一つは仮想マシン上でDockerコンテナを動かすこと
仮想マシンとDockerをごっちゃにしているやつはなんでそうするかを理解できない
目的が同じものなのになぜ2つのツールを同時に使うんだ?と思ってる
答えははっきりしてる。それこそ目的が違うものである証拠
Dockerを使うとアプリにそれを動かすのに必要なものがOS以外すべてバンドルされる。
それによってDockerさえ動いていれば、どこの環境にも同じDockerイメージを
持っていって使うことができる。この可搬性こそがDockerの目的
単純にVagrantを使うと特定のOS、ディストリ専用にVagrantfileを書かないといけなくなる
各OSでパッケージ名やデフォルト設定やパスなどが違ってるからだ。
そこで可搬性が高いDockerを併用すると、DockerのインストールまではOS、ディストリ依存に
なってしまうが、それ以降は全く同じ手順でDockerコンテナを起動することができる
Vagrantfileでいろいろ書く必要はないし、VagrantをAnsibleやChefと併用する必要もなくなる
もちろんVagrantを使わない環境、例えばAWSやGCPなどのクラウドでもあっても
今は直接Dockerイメージをサポートしてるのもあって、Dockerイメージを指定するだけでいい
Dockerは可搬性を高くするためのもの
仮想マシンはただのマシンでしか無いし、Vagrantは環境構築ツールでしかない
目的が全然違っている。 >>606
目的なんて無数にあるだろ
自分が考える目的以外の目的が存在するということすら想像できないようじゃ話にならない
本当に話しにならない そうやって一般論でごまかすのやめーや
Dockerが考えてる目的を書いただけの話
別の目的に使おうというのなら、使いにくいのは当然だってことだ
少なくとも仮想マシンやVagrantとDockerの目的は違っている
お前の目的の話はしてない。Dockerの目的の話をしてる。 >>607
あらら、まだわからないのか
キミの言うところのDockerの高い可搬性を利用して、例えば開発環境を構築するという目的を達成するんだよ
そして開発環境を構築するという目的を解決する手段はDockerに限らずVagrantでもローカルでも構わない
だから比較検討して目的を達成するのにはどのテクノロジを採用するのがよいかを考えるわけだ
おそらくキミの中ではDockerはこの目的に使うもの、Vagrantはこの目的に使うもの
といったようにただ一つの絶対的な目的があるんだろうな
目的を解決する手段がいくつも有ること、ツールを使う目的はいくつも有ることに気付いていない
最低限そこに気付いてくれないと話しにならないよ >>609
君のレスを引用すると「Dockerは可搬性を高くするもの」
これがDockerが考えている目的なわけだ(というか君の脳内のDocker社の考える目的というべきか)
じゃあ可搬性を高くしてどうするんだ?
その先の目的がまだあるだろ?
その目的は利用者が抱える課題によって様々なんだよ > キミの言うところのDockerの高い可搬性を利用して、例えば開発環境を構築するという目的を達成するんだよ
自分で言ってる通りじゃないかw
Dockerの目的は高い可搬性を作る所まで。
Dockerを利用するってことは、別に作業があるんだろ?
その作業の目的が開発環境を構築することであって
Dockerを使う目的ではない
キミ、物事の本質を捉えられるようにならないとダメだよ >>611
> じゃあ可搬性を高くしてどうするんだ?
> その先の目的がまだあるだろ?
その先の目的? 金を稼ぐってことかいな?
その理屈で言えば、どんな道具も目的は同じになるなw 今置かれてる状況がある
また解決したい何らかの問題がある
そして解決する手段が複数ある
ここまできて比較検討しないって言っちゃなんだけど技術者失格だろう?
非常に幸運で何らかのテクノロジ一択で業務全部をカバーできる
なんて状況でもなければ必ず比較検討が必要になる >>614
お前が物事の本質をわかってないだけ。
Dockerの目的は可搬性を上げるためだし、
テキストエディタの目的はテキストファイルを編集するもの
開発環境を作るために、テキストエディタを使うだろと
いくら吠えたって、テキストエディタの目的が開発環境を作ることにはならないのと
同じようにDockerの目的は開発環境の作成ではない >>612
>Dockerを利用するってことは、別に作業があるんだろ?
>その作業の目的が開発環境を構築することであって
>Dockerを使う目的ではない
開発環境構築は間違いなくDockerを使う目的の1つ
A「なんのためにDockerを採用したの?」
B「開発環境構築のために採用しました」
自然だね
A「なんのためにDockerを採用したの?」
B「開発環境構築のために採用しました」
A「そんなのはDockerの目的じゃない!」
アホかこいつ >>613
極論すればそうだな
どんな道具にも複数の利用目的が存在する
どんな目的にも解決手段は複数有る
だから比較検討するんだよ >>615
道具の目的は作成者や利用者の認識によって様々
テキストエディタの主目的は確かにテキストの編集だろう
だが目的はそれだけではなく人によってことなる
"誰か"の目的を押し付けるべきではない
"おまえ"の目的が全てではない
まずはこの基本的な事実から理解してくれ
話しにならないから > A「なんのためにDockerを採用したの?」
> B「開発環境構築のために採用しました」
採用と目的 は意味が違う
はい論破w
ジョークかよw
なんでこんな簡単な指摘をせにゃならんのだ ほんとさっきからDockerの目的を
違う話にすり替えようとしてるな。
バレバレやで >>619
「なんのために」って読めなかった?外国人? A「なんのためにDockerを採用したの?」
B「開発環境構築のために採用しました」
A「開発環境構築してるのは見ればわかる。それを行うに当たって
なんのためにDockerを採用したのか聞いてるんだが?」
普通は後期着替え得される >>620
すり替えてるのはAn0DfPZDだな
Dockerの利用目的などいくらでもあるのに、開発目的の1つでしかない高い可搬性を唯一絶対の目的のように、こいつはすり替えようとしている 例えて言うなら
A「なんのために○○工法を採用したの?」
B「建造物構築のために採用しました」
こう言ってるようなもん >>622
A「なんのためにDockerを採用したの?」
B「開発環境構築のために採用しました」
A「開発環境構築してるのは見ればわかる。それを行うに当たって
なんのためにDockerを採用したのか聞いてるんだが?」
B「開発環境構築手段としてはVagrantやローカル環境へのバッチ処理適用などが候補に上がりました。
弊社の置かれる状況を踏まえて、それらを比較検討した上で、これこれこういうメリットがあると判断して、採用しました」
普通はこうなる
比較検討なんかしない、などというバカだったら採用理由にも説得力がなかっただろうね
開発環境に限った話ではないが、何かを決めるにあたって、検討した選択肢と採用した理由は関係者に対して必ず説明するものだ
業務で開発したことが有るならアタリマエのことだと思うが
もしかしてキミ仕事で開発したこと無い?あるいは一人で開発してるとか? >>625
> 普通はこうなる
前言撤回かよwwww
俺が間違いを指摘した後に慌てて後付して書くなって
ほんと恥ずかしいやつやなw
だいたい、その「これこれこういう」の中身が目的やろうが?
ちゃんと書けよ。Dockerを使うことで可搬性が高くなるというメリットがあるので
その目的のためにDockerを採用しましたって >>626
>「これこれこういう」の中身が目的やろうが?
「これこれこういう」は利用者の状況や課題によって様々
だから比較検討して答えをだすって何度もレスしとるだろうが
いい加減少しは理解してくれ
話しにならないとはまさにこのこと なんか話が難しくなってきましたね
ひとまず、docker軽いですよ、vagrantに比べて
buildはややかかるけど、終わってしまえば、起動もさくっといきますよ 何に使えるかと、何のための道具かってのをごっちゃにしてるやつのたわごとだからな。
Dockerはアプリケーションを仮想化するために作られた道具
その道具を使って金儲けができるからって、
いろんなものをごっちゃにしたらダメだって話 >>628
> ひとまず、docker軽いですよ、vagrantに比べて
vagrantは開発環境を作る道具にすぎない。
Dockerと比べるものじゃない。
比較するならば、ホストマシンでアプリを動かす vs 仮想マシンでアプリを動かすだろ
ホストマシンでアプリを直接実行するほうが、仮想マシン上でアプリを動かすよりも軽い
といわれても当たり前でしか無い うん、だからdockerの方が軽いんだよね?
当たり前でも何でも実際軽くて便利なんだからいいじゃないか そりゃ仮想マシン使うよりも仮想マシン使わないほうが軽いだろう。
仮想マシン使わないで、普通にパッケージをインストールすれば良い
普通にパッケージをインストールすればいいのに
なぜDockerを使うのか?それこそがDockerを使う目的 課題を解決する手段が複数ある
それぞれ一長一短で状況により正解は異なる
なので比較検討してどれを採用するか決める
これITに限らず一般常識ね んで、今話してるのは手段ではなくて
Dockerは何をする道具かということ
本質をちゃんと見れないと道具は正しく使えない 周回遅れだね
Dockerの特性は正しく理解した上で比較検討しようという段階の話をしてるので付いてきて 話を逸らすな。
Dockerはアプリケーションを仮想化する道具だって話をしてる お気の毒ですがそのような話をしているのはあなただけです
あなたはあなたが話ていることをみんなも話ているように錯覚しているようですが実は違うのです
まずは深呼吸して冷静になってください
会話が成立することを期待して待っています >>637
お前、自分が一人だってわかってないのか?
誰か他に同調してくれるやついるか? >>638
dockerとvagrant(あるいは他の方法論)を比較するという文脈のレスは私のレス以外にも幾つもありますね
比較するのはおかしいという主張はどうやらあなただけのようですが docker vagrant 比較
ぐぐったらたくさん出てきた
ちなみに
docker vagrant 比較するのはおかしい
ぐぐったら”おかしい”が除外されて検索された
こりゃ勝負有ったね >>639
それはお前の意見に同調してるわけじゃないだろw
頭悪いんちゃうか? だいたい、さんざん仮想マシンと比較って言ってくせに
vagrantに言い換えてるし
仮想マシンとvagrantの違いもわかってないようだ 間っていうか、LXCはシステムコンテナだから、Dockerで仮想マシンのような間違った使い方を
使い方をしようとしている人は、LXCを使うべきだよ PythonでJupyter Notebook使ったデータ解析環境をPC変更時に新PC上で手動で再現するのが面倒だからDocker上で動かすようにしてる Jupyter Notebookというアプリにそのアプリを動かすのに
必要なものを全部まとめてるわけだよね。
それが正しい使い方 そもそも再現性気にするくらいならjupyter使うのが間違ってるけどな。 また再現性とか誰も必要だと言ってない話をし始めたw 再現性が必要ない?
それはなかなか斬新ですねw
そコマで頭の悪い意見が出るとは思ってなかった。 Jupyter Notebookって試行錯誤を効率化するのが目的なんだから、再現性なんてDockerイメージで担保すればいいというのも、それはそれでありうる判断だろう。
環境独立な再現性があればあった方がいいって点には誰も異論はないと思うが、
それよりも試行錯誤の効率性の方が優先される用途もあるってだけの話だな。 依存性の封じ込めも再現性もvagrantや別の方法でもできるので比較検討が必要 >>649
依存性の封じ込めも再現性もvagrantや別の方法でもできるので
Dockerを使う理由にはならないってことだよ 複数の方法があるけど一長一短なのでツールの特性と置かれてる状況とを見て比較検討する必要があるんだね ずーっとってる話だが、
比較検討の話と、ツールが作られた目的を
ごっちゃにするなってことですね 発端は>>597-599あたりかな
比較検討の意義についての議論だったのだけど、それが理解できない子も居たようだね 比較検討するにあたって、
どの道具の目的をちゃんと理解してないと
正しい検討ができないって話やろが ここで聞くのが正しいかどうかわからないんですが質問です
やりたいことが2つありまして
1. Vagrantでバーチャルマシン使って開発
2. VPNでリモート環境に接続、そこにあるコンピュータにSSH
この2つは特に関係ない作業です
で、それぞれ単独では出来てるんですが
Vagrantでバーチャルマシンを立ち上げ
192.168.10.10のIPを与えて開発する(LaravelのHomesteadです)
↓
開発終えてvagrant halt(1の作業はここまで)
↓
リモート環境にVPN接続(2の作業開始)
↓
そこにあるコンピュータ192.168.10.14にSSH
としようとすると接続できない、pingも通らない、となっており解決方法を探しております
OSを再起動すると接続出来ます
macOS10.11(El Capitan)です
なにかわかる方いらっしゃいましたら、よろおねです Dockerって言うのを試したいのだが、
少し調べてみた限りでは、コマンドベースで各種の設定などやるようだが、
Linuxの操作に慣れていない人は使うのは難しい? >>658
やめといた方が方がいい。
本格的にLinuxを勉強するつもりなら話が別だが。 GUIしかやってないなら大抵の仮想化ツールは取っ付きにくいだろうな
CUIの勉強しろよ >>658
簡単だけどLinuxの操作などを知っているなら簡単という意味。 ターゲットとなる本番環境じゃなくてポータブル開発環境として使ってる人います?
ローリングリリースのLinux選んでずーっとその仮想育てる感じで
PowershellもMsysもWSLもどうやっても馴染めないよう シェルスクリプト・PowerShell の代わりに、VSCode で、Ruby を使えば?
Windows でも、普通にファイル操作できる。
ただし、irb だけは日本語でバグるから、WSL のirb を使う
日本語では、WSL のirb は、MSYS2 よりも正常に動く うーん正確な用語がわからない・・
そのVSCodeとRubyの方を仮想かしてどこでも同じ使い勝手を味わいたいんだ
そっちの実作業環境を開発環境と呼ぶのは変なのかな サイトの管理を任されたけど、今 vagrant とdockerとかで
環境構築するのが当たり前なの?
もう、MAMP XAMPでローカルに構築する時代じゃないの??? vagrantは開発専用。これでサイト構築はまず無いだろ
> もう、MAMP XAMPでローカルに構築する時代じゃないの???
vagrantかWSLのほうがいいだろ?
実際の動作環境がLinuxなのにWindowsで環境作るほうが面倒 Software Design 12月号の特集は、Python のAnsible
Vagrant, Chef に挑む巨人、Red Hat の猛攻が始まった!
以前は、すべての開発者は、Vagrant の作者で、今世紀最大の創業者、
Mitchell Hashimoto (HashiCorp)を避けて通ることはできないと言われていた
その常識に、赤い巨人が挑む!w >>667
俺の知ってる現場でもみんなvagrantだな
そういう時代なんだと思う VirtualBoxとVagrant を使って開発って
WEBアプリケーション以外にも使われることはあるんですか?
例えば、スマホアプリとか。 WindowsでDocker (Hyper-V)とVirtualBoxが共存可能になったってよ vagrant/terraform
container linux
ansible
docker
kubernetes
Istio
gcp/aws/azure
この辺のキーワード聞くことが多くなってきたが覚えること大杉てしぬ クラウドでコンテナを運用するとしたら規模の小さめなサービスでもk8sが鉄板なんすか? vagrantのguestosをオフライン環境でバージョンアップさせる方法教えてください 本番運用の環境でDockerCE (Docker for Windows) の Linuxコンテナを使ってるんだけど、
たまにポートフォワードがうんとも寸とも言わなくなることがあるんだけど、そういうもん?
具体的にはNGINXのコンテナを作って外からの443をNGINXに向けるようにしてるんだけど、
突然ポートフォワード出来なくなる。TCPパケットダンプしても明らかにコンテナに流れてない。
んでDocker自身を再起動したら復帰する
運用環境としては怖すぎなんだけど・・・ Docker は本家 Linux でも本番環境だとわりとトラブるって話を1年くらい前に聞いたな。
利用は開発環境やステージング環境までにして
本番はネイティブにした方が無難なような。 設定ミスの可能性もあるだろう
マネージドのDocker Hostをレンタルして同じ構成で動かしてみたらどうだ tcpdumpの結果でわりと十分なエビデンスだろう。
突然パケットが流れなくなるような設定間違いってなかなかできない。 >>684
全く「設定ミスがない」ことのエビデンスになってない
それじゃただ単に現象を確認しただけだ >>685
「『全く』設定ミスがない」ことのエビデンスなんて現実的なコストでは提供不能だよ。
特に設定不足系は無理。
ふつうはそんな効率の悪いやり方をしない。
まあ金融・証券系みたいにコスト無視、かつ顧客が無理難題をふっかけるとこだと、顧客が納得するレベルの嘘をついて誤魔化すことはあるけどさ。 「Docker network stopped working 」でググるといっぱい見つかるね。
未解決のも多い。
ttps://github.com/moby/moby/issues/32195
なんかはSolved になってるけど
・(正常なネットワークなら問題ない筈の)先進的なネットワークオプションをとにかくdisableせよ
・Docker のバージョンを上げろ
ってなってて、Docker か、あるいは利用しているネットワーク環境のどちらかに不具合があるっぽい。 >>686
俺がなんで括弧つけたかわかってないな
「全く設定ミスがない」こと証明してないと言いたいのではない
「設定ミスがない」ことを全く証明してないと言ったのだ >>688
ふつうは正しく動作することをもって証明とするんだよ。
数学的な意味での証明には全くならんが、現実的なコストでできる証明ってのはそれくらいしかないんだ。
くだんの人の場合、一応正しくは動作してるのに、しばらくすると止まる、しかもtcpダンプしても止まってるんだから、
症状からしてなにか不具合がある可能性が高い。
そうじゃない、証明する方法があるんだっていうのなら、その方法を具体的に書いてやってくれ。 >>689
もうとっくに書いてんじゃん
マネージドなdockerホスト借りてやってみたらどうだってさ
何も設定項目1つ1つ変更しながらエビデンスとれって言ってるわけじゃないんだよ
適度なサイズのスコープで切り替えながら調査していくの
これって問題調査の基本中の基本だよね?
君が言ってる現実的じゃない方法って
アルゴリズムに例えて言うと線形探索なんだよ
でも俺らは二分探索とか範囲で絞り込むアルゴリズムを知ってるわけだろ?
なんで身につけた知識を応用しないんだ? >>690
マネージドなDockerホストって書いてた人だったのか。
確かにそれはアリだな。
俺の言葉の使い方だとそれを設定ミスがないことのエビデンスになるとは言わないので
マネージド環境でのテストのことを指してるとは思わなかったよ。
すまんかった。
よくよく考えてみるとアホな顧客にエビデンス要求された時に
有料サービスに丸投げした結果を提供してOKもらうことはたびたびあるので
自分でも似た使い方してたなw
自分でそれがエビデンスという強い言葉に値すると思ってないから思いつかないんだなあ。 issueだらけだもんなぁ
本番には到底耐えきれないよ
本番で使わないならってんで開発でもDockerを使わなくなる
だから実務で役に立つのはVagrantとAnsibleになる ■ このスレッドは過去ログ倉庫に格納されています