仮想環境コンテナ総合スレ Docker、Vagrant等 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
開発に仮想環境やコンテナを使う機会が多くなってきたので、みんなで情報交換しませう
よろしこ 担当者を明確に分けるとこういうことなんだわ
1. [インフラ] 新しく物理・仮想サーバーを用意して、
2. [インフラ] 環境ごとのサーバーの設定を行って、
3. [アプリ開発] アプリ・サービスを動かすのに必要な環境を用意して(必要ライブラリのインストールなど)
4. [インフラ][アプリ開発] アプリ・サービスをインストールして
5. [アプリ開発] アプリ・サービスの設定を行って
6. [インフラ][アプリ開発] 環境構築を完成させる
担当者ごとに分けると以下のようになる
・Ansibleで設定する部分
1. [インフラ] 新しく物理・仮想サーバーを用意して、
2. [インフラ] 環境ごとのサーバーの設定を行って、
4. [インフラ] アプリ・サービスをインストールして
(kubernetesのような運用向けオーケストレーション、または単体でDockerコンテナ起動)
6. [インフラ] 運用環境構築を完成させる
・Dockerでコンテナ化する部分
3. [アプリ開発] アプリ・サービスを動かすのに必要な環境を用意して(必要ライブラリのインストールなど)
4. [アプリ開発] アプリ・サービスをインストールして
(Composeのような開発向けオーケストレーション、または単体でDockerコンテナ起動)
5. [アプリ開発] アプリ・サービスの設定を行って
6. [アプリ開発] 開発環境構築を完成させる
作業は明確に分かれてるんだよ
担当者が違う作業を一緒にしてしまってはいけない >>513
> ドッカーはウェブアプリ専用
違うよ。例えばffmpegのような多くの外部ライブラリに依存し
バージョンの違いの影響も大きくコンパイルオプションも豊富で、
権利関連の問題でどのディストリでも標準パッケージでは満足できず
かと言ってライブラリを自分でビルドすると依存関係が壊れがちになって、
すべての機能をONにしたければ自分でビルドするはめになるようなソフトは
Dockerを使うと、簡単にビルド・実行できるようになる。
自分の好きなディストリを使いつつ、ffmpegは他のディストリベースにすることができる サーバの環境をdocker上に作っておく
リプレースが必要になったら新しいサーバにimageを移す
古いけどファミコンのカセットを新しいサーバに刺しなおすだけ つまり
* Dockerの利点はアプリの依存関係のパッケージングである
JavaランタイムなしでJavaアプリが動かせますといったことがOSレベルの依存関係でも可能
* Dockerによってパッケージングされたアプリだけではシステムとして成立しない
Ansibleやオレオレスクリプトで別途環境構成や設定を管理する必要がある
こういうことですか?
DockerはあくまでAnsibleやオレオレスクリプトで管理される取り扱いが容易な部品に徹すると そもそもAnsibleとDockerって明確にセグメント違うでしょ
優劣がどうこう言うたぐいのものじゃない AnsibleはAnsibleだけでいいけど
DockerはAnsibleやシェルなど別途構成要素が必要
結局はここに落ち着く
>>503から進展してない > AnsibleはAnsibleだけでいいけど
> DockerはAnsibleやシェルなど別途構成要素が必要
え? Ansibleでアプリ開発してんの?
普通別の言語を使うよね?
というかAnsibleでどうやってアプリ開発するのか知らんがw
なぜそんなに、アプリ開発の一環である
Dockerコンテナの作成を、Ansibleでやることにこだわるのか?
どうせアプリ開発は別言語でやるのに
インフラ担当は、アプリ開発をしなくていいんだよ? >>521
Ansibleでアプリ開発?
スマンが言ってること意味不明なので解説して欲しい Docker使わない場合(4step, 2lang)
【Java】 Javaアプリ開発
【Ansible】 Javaランタイムインストール
【Ansible】 Javaアプリデプロイ
【Ansible】 アプリ設定
Docker使う場合(5step, 3lang)
【Java】 Javaアプリ開発
【Docker】 Javaランタイムインストール
【Docker】 Javaアプリデプロイ
【Ansible】 コンテナデプロイ
【Ansible】 アプリ設定
覚えること、仕事増えてるよね? >>522
だってすべてAnsibleだけでできるわけないじゃん。
インフラさんはAnsible使ってるだろうけど、
アプリ開発者は別の言語使ってるよね?
インフラさんにとっては、アプリがなんの言語で作られてようが
Dockerコンテナで実行環境毎まとまってようがどうでもいいことじゃん
重要なのはアプリを開発してないインフラさん
(=どんな実行環境・ライブラリなどで動くかなど知らない)が
アプリに依存したことを意識せず「Dockerコンテナを動かす」という
ただそれだけのことで、サービス運用環境を作れること
専門家に任せましょう。どんな実行環境・ライブラリなどで動くかは
アプリ開発者は知ってます。それで作ってテストしてるんだから
アプリ開発者はAnsibleなんか使いません あとAnsibleを使えばDockerのようなことができると
思ってるようだけど、できないからな
・Dockerを使うと実行環境をアプリに組み込むことができます
・Dockerはアプリが使用するポート番号を自由に変更することができます
・Dockerは複雑なアプリ設定を単純化し、引数や環境変数で指定可能なアプリに作り変えます
所詮Ansibleは作られたアプリに対して設定を行うだけで、
Dockerのようにアプリ自体を改善・強化することはできない
アプリをDockerコンテナ化するだけでいろんなOSで動かすできるのも
アプリ自体の改善・強化の一つだな >>510
コンテナ内でcron動かせなきゃ意味ない
cronを含めたパッケージングがしたかったんだよぉ >>527
だから使い方を完全に間違ってる
Dockerはアプリに実行環境を埋め込んで、完全体のアプリを作ること
exeファイルの中にdllなどを埋め込むのと近い
あんたが言ってるのは、C言語でソースコードをビルドしてバイナリを生成して、
バイナリを実行したらcronが動くんじゃなくて、ファイルが存在するだけで
cronを動かすようにしたいって言ってるようなもの
ビルドしただけで動き出すようなプログラムなんてない
意味不明なことを言ってるってわかるだろ?
もちろんDockerコンテナを実行したら内部でcronが実行されてるっていうのなら
簡単にできるが、cronを使うまでもなく実行時間までsleepするだけで十分だな >>525
>>>522
>だってすべてAnsibleだけでできるわけないじゃん。
>インフラさんはAnsible使ってるだろうけど、
>アプリ開発者は別の言語使ってるよね?
アプリ開発言語は別に決まってんじゃんって常識的に考えてわからんか?
>インフラさんにとっては、アプリがなんの言語で作られてようが
>Dockerコンテナで実行環境毎まとまってようがどうでもいいことじゃん
そのとおり
ドウデモイイんだ
ドウデモイイので使うテクノロジーは減らしたほうがいい
>重要なのはアプリを開発してないインフラさん
>(=どんな実行環境・ライブラリなどで動くかなど知らない)が
>アプリに依存したことを意識せず「Dockerコンテナを動かす」という
>ただそれだけのことで、サービス運用環境を作れること
ロールでいいじゃん
ロールの詳細までは別に知らなくていい(知りたければ見ればいい)
>専門家に任せましょう。どんな実行環境・ライブラリなどで動くかは
>アプリ開発者は知ってます。それで作ってテストしてるんだから
>アプリ開発者はAnsibleなんか使いません
クラウドが一般化してきてプログラマでもインフラに関わらなきゃならない機会は増えてる
当然Ansibleも必須科目 >>526
便利っちゃ便利だけど別に必須でもなんでもないよねそれ
それに逆に設定がめんどくさくなることもある(DBとか色々) >>528
Dockerで作った完全体のアプリ()を誰かがコントロールしてやらなければならないんだどうせなq
exeを作っただけじゃ役に立たないようにイメージを作っただけじゃ役に立たない
サービスとして起動して起動後の設定を行う必要がある
そのための基盤がAnsibleみたいな構成管理ツール
どうせAnsible使うなら最初から全部Ansibleでやりゃいいじゃんってこと
依存関係をDockerfileで解決するかPlaybookで解決するかの違いでしかない
複雑な依存関係がある場合はDockerでカプセル化するメリットがあるかもしれんがそんなのは頻繁に起こることじゃない bashで全部できるならbashでやるのか?
馬鹿じゃねーの?
Dockerが必要な状況ならDocker入れればいいだけで何のためにDocker使うかわかりもしないのに入れて
手順が増えるとか言う馬鹿 問題解決や利便性のためにDockerが必要な局面もあるだろ
そういうときにDockerが使えればいいだけ
Ansibleしか使えないのに俺スゲーしたいんだろ
俺日本語だけで十分だからなんで英語やフランス語使ってるのかわからんみたいな
低レベルな自慢みたいな浅はかな感じがする > ドウデモイイので使うテクノロジーは減らしたほうがいい
それならAnsibleをなくしたいねw
だってシェルスクリプトは普段からCLIで使ってるけど
Ansibleは使わないじゃん。
シェルスクリプトはなくせないが、Ansible
はシェルスクリプトで置き換えれば無くせる
Dockerはシェルスクリプトベースだしね そう必要なときに使えばいいんだよ
bashだけで構成管理する大道芸はキツイ
からなんかツールないとやっていけないぞそう世界中のみんなが考えて発明されたのがAnsibleのようなツール
必要性から生まれたツールなんで必要なものなんだね
Dockerは使うと面白いのはわかるけど必要かって言われると正直別に…ってところだな
依存関係?どんだけごった煮のサーバー作る気だ?
ポート変えれます?おめでとさん
引数や環境変数で設定可能?パラメータはファイルに残そうね >>535
アプリに実行環境を組み込んで可搬性のあるアプリを
作るってところはまだ意味がわかってないのかな?
そこについての言及がないってことはそうなんだろうね
Ansibleで開発したアプリの設定を行うほうが大道芸
だって自社で開発したアプリにAnsibleモジュールは存在しない
自分でモジュール作るか?それともコマンド呼び出しで頑張るか?
自社で開発したアプリを動かすにはあれとこれのインストールが必要です。
バージョンが上がったので今度はそれも追加してください
設定項目が追加されてるので、それを設定するように書き換えてください
冪等性あるように作ってください
アプリのデプロイの前に、Ansibleで環境を更新してください
そうしないとアプリ動きませんから!
絶対にミスしないでくださいよ!!
はい、大道芸w
Dockerを使うとそういう複雑なところが隠蔽されるんだよ
Ansibleで書くのはDockerコンテナを起動する。そのためのモジュールを使うだけ
手元でテストしたDockerコンテナを実環境でも使う。だから実行環境に違いはない。
Ansibleの定義ファイルは単にバージョン番号を変更するだけ まだわからんかねぇ
Dockerで完結しないってとこからは目をそらし続けるんだ
コンテナ起動するたびシェルで必死に起動後の設定とかアホくさ
そもそもそんな手順はいらない
ロール用意したんでそれ使ってくださいで終わり > Dockerで完結しないってとこからは目をそらし続けるんだ
どうせアプリはJava使ってありRuby使ったりするんだ、
Ansibleだけで完結することもないよ
それにお前の定義によればDocker使っても「Ansibleだけで完結」してることになるだろ
なぜって? AnsibleのDockerモジュールを使うからだよ
お前、Ansibleでcronの設定したら「Ansibleだけでは完結しない。cronが必要」って言うか?
言わないよなぁ? Ansibleでcron設定しようがDockerコンテナ化したアプリの設定しようが
Ansibleだけで完結してることになってるだろ
んで話を戻して、JavaやRubyなどでアプリを開発してるが
Dockerを使おうがAnsibleを使おうが、新たに別のテクノロジーを使ってるのは一緒。
ならDockerのほうが可搬性の点でもシェルスクリプトベースという点でも
メリットがあるので、Dockerを使ったほうがいい 訂正&補足
んで話を戻して、普段JavaやRubyなどでアプリを開発してる人が
Dockerを使おうがAnsibleを使おうが、新たにアプリ開発言語とは別のテクノロジーを使ってるのは一緒。 必要な環境はロールでカプセル化されっからドッカーでカプセル化して二度手間にする必要はないってことな
つか
「Ansibleで完結」を拡大解釈してねえか?
アプリ開発にジャヴァやらなんやら使うからほれみろAnsibleで完結してませーんってボケにしてもあんまし面白くないぞ
Docker使っても使わなくてもAnsibleで完結してるってのはそうだな
所詮は1モジュールでしかない
逆にDocker視点で見れば全然完結してなくてDockerより大きな他の仕組みが必要になる kubeと組み合わせるケースはansibleだけではカバー出来んじゃろ Ansibleはwindowsも含めて使ったらPowerShellも覚えないといけない >>528
その通りだとするとcronを使ったwebシステムのパッケージングにはDockerは不向きってことになるが
だとすると俺のイメージと違うな
実行環境を含めたパッケージングの利点はまぁわかるが、ツールレベルのバイナリを使うのにわざわざビルドするのはめんどくさくない?
実行環境をパッケージングできるのはすごいアイデアだと思うよ。でも俺は例えばcatを使うのにわざわざDockerでビルドしたりしないな。そのレベルのバイナリならyumとかapt使うわ >>543
馬鹿か。だから自分で作ったアプリに実行環境をくっつけるんだよ
ほんとなぁ、開発者のためのツールだってわかっちゃいねぇ つかいたくなければ、つかわなければいい
これだけで全部解決できるわけないし >>544
批判的な俺だが仕事ではDocker使ってるんだよね
小規模webサイト程度ならほんと使い勝手いいわDocker
引っ越しもすげー楽 ウェブサービスや一回走らせて終わりのコマンドと相性が良すぎるんだよなドッカー
それ以外は残念だけど面倒が増えるだけ > それ以外は残念だけど面倒が増えるだけ
サービスとコマンド以外に世の中に何があるんや? ウェブアプリテスト環境をmac上のDocker環境で行っているのですが
雨が続くみたいのでリモート作業できるよう自宅のwindowsで同じ環境を構築しようと考えています
Docker上の挙動ってホストOSに依存しますか?
VMならHWレベルでエミュレートしてるので大丈夫そうですけど
Dockerの仮想化ってどのレベルでやってるんでしょうか
動かすのはスクリプト言語なのでバイナリレベルの互換性とかはそれほど影響うけなさそうですけど
通信したときのエンディアンとかはホストに依存したりするんでしょうか
やりとりはjsonのみなのでそのへんもちゃんと吸収されてるとは思うのですが
変なところではまりたくないので事前に確認したいです >>551
もともとDockerはLinuxカーネル上で動くものとして作られた
今はWindowsやIBM Zなどに対応しているようだが、使用例は少なく
意識して使おうと思わない限り、Linux(x64)のイメージを使ってるはずだ
Linux(x64)のイメージを使っているのだから、
そのDockerコンテナはMacやWindows上でネイティブに動かない。
だからMacやWindowsでは仮想マシンが使われておりVM上でLinuxが動いている
(このLinuxはDockerを動かすためだけの軽量なLinuxで直接使うことはないのでディストリは意識しなくていい)
Docker for Mac では xhyve (Mac純正仮想マシン)が使われている
Docker for Windows では Hyper-V(Windows純正仮想マシン)が使われている
Docker for Mac/Windowsのほうが新しく推奨だが、Hyper-VはWindows Pro以上でないと
使えないので、Docker Toolbox(Virtual Box)を使うしかない
仮想マシンを使用しているということを意識しないように、うまく設定されてはいるが、
それでも仮想マシンであるがゆえに、CPUやメモリの使用する量を仮想マシンに割り当てるしかなく
その範囲でしか使うことができない。これらはDockerの常駐アイコンから設定できる
> Dockerの仮想化ってどのレベルでやってるんでしょうか
勘違いしている人が多いが、仮想化 = ハードウェアエミュレーションという意味ではない
仮想化というのは単に物理的なものを切り離して抽象化するという意味なだけだ
仮想マシンは、マシンを仮想化したものだが、Dockerが提供しているものは、
(実行環境の)仮想化であって仮想マシンではない。ハードウェアを抽象化して
見せているのではなく実行環境(カーネル以外のOSやライブラリなど)を抽象化して見せているだけ 訂正
Docker for Mac/Windowsのほうが新しく推奨だが、Hyper-VはWindows Pro以上でないと
使えないので、 "Docker for Windowsが使えない場合は" Docker Toolbox(Virtual Box)を使うしかない 環境構築は人にたよってて
その上でjavaやPHPのコーディングするのがメインなのでちゃんと理解できてない…
今の案件がRailsなんですけど
結論からいうとwindows上のDockerでRailsを動かす同じ環境を構築するのは難しい感じでしょうか >>554
別に?
同じように使える。というか同じように使えるように
Docker社が頑張ってくれてる。
もともとLinuxカーネルでしか動かないのに
よくもまあこんなに頑張って対応したもんだと思うよ
WindowsやMacでも動くことの重要性を強く認識していたんだな
本番環境ではLinuxカーネル上で動かすわけで、Linux上にだけ対応するという道もあったはず。
でもWindowsやMacに対応したのは、多くの開発者の開発マシンはWindowsやMacで
開発者にとってのツールであるDockerはWindowsやMacでも使えることが重要だと考えていたのだろう
上の方にいる、誰かが作ったアプリをパッケージングして配布することだけしか考えてないやつには
わからんだろうね。だから配布するならansibleで十分じゃんという発想になってしまう。
Dockerはアプリ開発者のためのツールですから 何度もすいません
インストールはできてコマンドラインからも動作させることはできたんですけど
ファイルシステムやメモリの設定はどこから行えばいいんでしょうか
mac版はランチャーがあって
Preference > Daemon > Advanced にファイルシステムの設定ファイルがかけたり
Preference > Advanced からメモリの設定ができたりしたんですけど >>554
素直に仮想マシンを立てて、Ansibleなど構成管理ツールを使って、本番と開発環境を可能な限り揃えたほうがいいよ
Dockerはほぼどこでも動くけど、どこでも同じように動作するわけじゃないし、トラブルが発生した時の対処手順がDockerと実機サーバーや仮想マシンとでは大きく異なる
本番も開発環境もDockerで統一するなら許容範囲内だけど、それでも環境差異のリスクはあるね > 素直に仮想マシンを立てて、Ansibleなど構成管理ツールを使って、本番と開発環境を可能な限り揃えたほうがいいよ
それをやると問題になるのが、(Windows or Macで)ファイルを編集して
すぐにそれを反映させるのが大変になる。いちいちアップロードなんてしてられない
開発時はソースコード書いてテスト実行という流れが1分間に数回のレベルで発生する
また開発時はデバッグ用のモジュールが必要になる。
ログの表示とかデバッガの実行とか。
本番環境と揃えるのは、開発面ですごく効率が悪い
アプリ開発してない、単に配布しかしてないやつにはそれがわからない >>557
Windowsもタスクトレイのアイコンから設定できるだろ?
Docker Toolboxはどうなってるのかしらんが。 >>558は(Ansibleで構成した)仮想マシンと実機環境が同じだという前提のようだが、
その理屈だと Windows or Mac 上のDockerは仮想マシンで動いてるので
Dockerが動く仮想マシンと、Dockerが動く実機マシンは同じと言える
実際の所、Dockerイメージの中に実行環境が組み込まれているので、
Dockerイメージは、LinuxカーネルとDockerにしか依存しない
Dockerイメージは同じものを使うという前提であれば、
あとはLinuxカーネルとDockerを揃えてしまえばほとんど同じ
たとえ違っていたとしても、Linuxカーネルに関しては高い互換性が
あることが今での実績から明らかで、DockerはDockerコンテナを動かすために
使っているだけで、開発したアプリがDockerに依存しているわけじゃない
なのでLinuxカーネルもDockerもバージョンが変わったところで問題はほとんど発生しない。
環境差異のリスクがあるのはDockerを使わないからなんだ >>559
大変にならないよ?
もしかしてアプリ開発したことないのかな >>561
Dockerといえど環境バグは結構あるよ
まあ仮にDocker間で100%互換性があると譲歩したところでテスト、本番が非Dockerなら開発にDockerを使うのはリスクしかない >>562
じゃあWindows or Macのテキストエディタで
どうやって編集するというのかな? >>563
本番もDocker使うに決まってるでしょw
っていうか、Kubernetesとか使ったことある?
Docker前提だからね。もう大規模はDocker前提の時代になってる WSLでvagrantを使ってる人いる?
使い心地どうですか? GKEもECS+Fargateも使える、この世の中でdocker使わない意味もないし、さすがにmanagedに対してansible使う機会は減ってきたと言わざるを得ない >>564
ま、それも一理あるね
addじゃなくて、volumeで割り当てれば、host側から編集できる コンテナは上がってるのに
docker exec -it xxxxx /bin/bash
Error: No such container: xxxxx
になったんですけど原因わかりませんか?
ymlファイルはいじってなくて
xxxxx:
image: yyyyyyyyyyyyyy
container_name: xxxxx
docker ps の結果は普通に起動してる
zzzzzzzzzzzz yyyyyyyyyy "/bin/bash" 4 days ago Up 23 minutes 0.0.0.0:nnnn->nnnn/tcp
昨日までは普通に動いてたのに
設定ファイルは色々いじったんですがコンテナに関係する部分は触ってないはずなのに…
dockerは便利だけどブラックボックスすぎて一度問題起きると自分で全く解決できないのが辛い よく分からんなら問題解決なんてしないでコンテナ作りなおしちゃおーぜってのがdockerの基本中の基本
根本原因を調べないと再発するのでは?って思うかもしれんけどそのたびに作りなおせば問題ないよね >>572
だから再発するまでは問題ないんだよ
「昨日までは普通に動いてたのに」ってことはコンテナを立ててからしばらくは正常に動いてるってこと
その間だけサービスを提供してダメになったら(なりそうだったら)予備のコンテナに切り替えるってわけ
コンテナ切り替えたら元のコンテナは破棄して次の予備コンテナをスタンバらせる dockerの構築スクリプトも定期的にメンテしないと動かなくなることあるよ >>570
image-idじゃなくて、container-idをシテイシナイト駄目だよ エラーの原因はコンテナと共にバイナリの海の藻屑となる。。。
積み重なったコンテナはやがて墓場を形成し、次第に人々はこう呼ぶようになった。。。
「どっかー(行っちゃった)の墓場」と。。。 docker for winは登録しないとダウンロードできなくなったみたいだ そういやWindowsコンテナってあんま話題にならないけどどうなんだろ
XP、.NET 2.0、正体不明の自社・他社COMライブラリ、Excel.Applicationなどが仕事してる古いシステム
まるごとコンテナ化して隔離できんかな mysqlのdatabaseごとにマウントポイントを変更したい
どうやんの? 内容読む限りKubernetesクラスタとかDockerサーバのセキュリティ甘いやつ狙ってそいつらにデプロイさせてるんだと思う
まぁ自作と公式以外信頼しないのは重要だと思うけど virtualboxの上で直接に動いてるLinuxと
virtualboxの上にのってるVagrant上で動いてるLinux
この2つのLinuxって挙動とか変わってきたりしますか?
C言語とかシェルスクリプトのテスト環境として全く等価なんでしょうか? >Vagrant上で動いてるLinux
Vagrantは、仮想OS ではないので、Linux は、Vagrant上で動かない
「Vagrant」で検索! >>585
>>586
理解できました
ありがとうございます! >>584
インストールから設定をキッチリ揃えたわけでもなければ当然ながら等価じゃないよ
無視できる差異かどうかってとこが重要
これはDockerでも同じこと
厳密に同じ環境はどうやったって作れない >>588
厳密に同じ環境であるかなんて聞いてないだろ >>588
野良boxでなければ等価だと言ってもよいのでは? 何をもって「挙動が同じ」「等価」とするかだよね
スクリプトでハードウェア情報取得しようとすれば環境によって変わってくるだろうし
外部のWebサイトに対して自分で書いたクローラーを実行するとかなら多分「挙動が同じ」になるだろう コンテナ上で仮想OSは動かないということだけど、例えば「docker pull ubuntu」で取得したubuntu動かすのと仮想マシンでubuntu動かすのとの違いが良くわからない >>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の目的は開発環境の作成ではない ■ このスレッドは過去ログ倉庫に格納されています