仮想環境コンテナ総合スレ Docker、Vagrant等 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
開発に仮想環境やコンテナを使う機会が多くなってきたので、みんなで情報交換しませう よろしこ >>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の目的は開発環境の作成ではない >>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 >「これこれこういう」の中身が目的やろうが? 「これこれこういう」は利用者の状況や課題によって様々 だから比較検討して答えをだすって何度もレスしとるだろうが いい加減少しは理解してくれ 話しにならないとはまさにこのこと ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる