[過去ﾛｸﾞ] Docker Part2©2ch.net (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
215: 2018/07/19(木)17:07 ID:4Cjfx+r5(1) AAS
「OpenNebula 5.6」公開、Dockerサポートの強化などが加わる 2018年7月18日15:00 末岡洋子
外部ﾘﾝｸ:mag.osdn.jp
クラウドインフラストラクチャ構築・管理プラットフォーム「OpenNebula」の開発チームは7月16日、
最新安定版となる「OpenNebula 5.6」（Blue Flash）を公開した。
Docker管理機能を新たに統合、任意のOpenNebulaクラウドで、Dockerアプリケーション実装の
土台となるDockerエンジンの仮想マシンをMarketplaceよりインポートできるようになった。また、
OpenNebula APIやインターフェイスを経由することなくDockerエンジンをシームレスに管理する
Docker Machineも統合した。
216: 2018/07/27(金)03:51 ID:6DSLURTJ(1) AAS
訳あってソースコードからビルドしないといけない物があるんだけど、
ビルドに必要なパッケージをインストールしたくない。
だからDockerでビルドして、インストール先はDockerの外って
やりたいんだけど、そういう使い方のノウハウって
どこかにまとまってないかなぁ？
ソースコードのディレクトリをボリュームにして
make installだけDockerの外でやるのが一番かなぁ？
217(1): 2018/07/27(金)04:48 ID:1joj4I21(1) AAS
そういうときはmake install先のディレクトリだけ -v でマウントしとくパターンが簡単で良いね
例えば ./configure --prefix=/usr/local で入れるやつはインスコ先になる/usr/localを
docker runのときに -v "/usr/local:/usr/local" って指定する
コンテナでmake installまでやれるしホストもソースやビルドツールで汚れないから安心
docker公式マニュアルのどっかに書いてあった気がしたが見当たらなくなってた
218: 2018/07/27(金)07:25 ID:7fogAuN8(1) AAS
詳しい解説サンクス
219(1): 2018/07/28(土)15:41 ID:0ikx9NUA(1) AAS
>>217
もう少しアイデアを発展させてみた。
このアイデアをどうするかは任せる
make install、前々からの問題。何処に何がインストールされるかわからない。
基本的には--prefixで指定した所だろうけれど、確実にそうとは言い切れない
make uninstall、これも前々からの問題。uninstallをサポートしているものが少ない
インストールした後消すのが大変
docker、make installでインストールされるファイルは多分レイヤーの差分を見ればわかる
インストールされるファイルがわかるのだから、それを消せばアンインストールになる
インストールするファイルも残っているのだから、ファイル内容を比較することで
アンインストール時に想定外のファイルを削除しなくてすむかもしれない
220(1): 2018/07/28(土)16:06 ID:PwMG08J6(1) AAS
今はMulti-stage buildが公式実装されて>>219のアイデアを綺麗に実現できるようになったね！
ビルドコンテナのmake install結果をホスト経由せずに実行用コンテナに簡単に乗せられる
ビルドコンテナも実行用コンテナも使い終わればコンテナごとすべて消せるから
--prefix完全無視の無作法野良ツールにホストのファイルが上書きされることもないし
make uninstall非対応でもコンテナ消せば良いだけだからゴミが残ったりもしない
221: 2018/07/28(土)19:21 ID:fgC/Ah69(1) AAS
>>220
> make uninstall非対応でもコンテナ消せば良いだけだからゴミが残ったりもしない
なんかちょっと違うｗ
インストール先はコンテナの外よ。だからコンテナ消せば良いだけってことにはならない。
どんなものでもコンテナ化して使えるかっていうと、例えば（独自ビルドの）gitコマンドを
コンテナに入れて使うのは大変だと思う。カレントディレクトリを見るし、
サブコマンド次第ではカレント以外のディレクトリも見るしね
インストールするファイルを知ることができるから、コンテナでビルドして生成したものを
コンテナの外にインストールしてアンインストールもしやすくなるだろうと言う話
222(1): 2018/07/29(日)00:30 ID:wo8fIaJv(1) AAS
最初のうちはエディタとかgitとかはどうしても大変に思えてホストに直接置きたくなるんだよな
俺もコンテナ上のgitからホストのカレントディレクトリを見る方法がわからんというごく最初の段階でつまずいた
絶対パス指定ならツールで使う主要ディレクトリを-vに指定しとけば大半普通に開けるけど
カレントを含めた相対パスも単に-v $(pwd):$(pwd) -w $(pwd)を書いておけばいいという基本をDocker Hubのgitイメージページ読んで知った
223: 2018/07/29(日)01:53 ID:vXZjVBrz(1/5) AAS
>>222
だから大変だからホストに直接おいたほうが良いって話なんだが
例えばgit diff --no-indexでカレント（gitディレクトリ）以外を
比較したくなったら-v $(pwd):$(pwd)じゃ対応できない。
他にもgit applyとかさ
-v $HOME:$HOMEにしたら動くかもしれないけど、
それでもhomeの外では使えないコマンドになってしまう。
（例えば/opt以下にgitリポジトリをcloneするツールとかさ）
コマンド実行した時、特定のファイルはコンテナの外を見ますが、
それ以外はコンテナの中を見てますとかややこしいだけだから
俺は頑張ったんだって自己満足してたいだけでしょ？
そんなのは意味がないから辞めたほうが良い
224: 2018/07/29(日)01:54 ID:vXZjVBrz(2/5) AAS
あ、そうだ。gitのglobal configがあるから、
絶対HOMEをボリュームにしないとだめなんだ。
225: 2018/07/29(日)01:57 ID:vXZjVBrz(3/5) AAS
ssh鍵の話もあったな
-v $(pwd):$(pwd) -w $(pwd)を書いておけばって
実際には使ってないだろ。
コンテナ化に適してないアプリをコンテナ化しても使いにくいだけ
226: 2018/07/29(日)02:32 ID:vXZjVBrz(4/5) AAS
面白い例を思いついた
> 最初のうちはエディタとかgitとかはどうしても大変に思えてホストに直接置きたくなるんだよな
エディタとgitをコンテナにするとどうなるか
環境変数GIT_EDITOR、コミットメッセージなどを編集する時に使用されるエディタをしている。
まあGITが使う多数の環境変数をコンテナの中に渡す。これだけでも面倒くさくてやりたくないが、
gitをコンテナの中で動かしたりすると、エディタがコンテナの中で起動される
つまり、gitコンテナの中にエディタまで入れないといけない。
さてそのエディタ、当然（？）のごとくgit連携機能がついている。
エディタからgitを呼び出されるならば、エディタのコンテナの中に、gitを入れないといけない
環境変数？ おっと、gitコンテナの中でエディタを起動するならば、
エディタで使う環境変数も、gitコンテナに渡さないといけないな。
おっと、エディタからgitを呼び出すこともあるから、エディタのコンテナを実行する時も
gitの環境変数を渡さないといけないな
はは、乾いた嘲笑の笑いしか出てこない。こんなムダでややこしいことやって
なんの意味があるんだ。
227: 2018/07/29(日)18:09 ID:PCsU6lV8(1/8) AAS
長くて全部読んでないけど、ホスト側のgitなりエディタ設定なりに依存するようなコンテナって筋悪くない？
k8sとかでコンテナを別ホストに移動したら使えなくなるような気がする。
228: 2018/07/29(日)18:12 ID:PCsU6lV8(2/8) AAS
エディタが何かによるけど、vim程度ならコンテナ毎に入っててもいいのでは。有償のIDEでgit連携して使ってる人にとってはちょっとしんどいとかかな。
229: 2018/07/29(日)20:28 ID:vXZjVBrz(5/5) AAS
そりゃ単に、
普通は使わないけど入っていても良い。イメージのサイズがでかくなるだけ。
程度のことだな
普通はコンテナのイメージはDockerfileで作るし、コンテナの中のファイルを
直接修正することはない。Dockerfileの開発中とかデバッグのために
便利かもーぐらいで入れておいてもいいが、最終的には使わんので消す
コンテナ内のvimは使わない。の意味がわからんやつは
勉強し直したほうが良い
230: 2018/07/29(日)21:46 ID:PCsU6lV8(3/8) AAS
え、普通にvim使ってるけど。何でなの？
231: 2018/07/29(日)21:48 ID:PCsU6lV8(4/8) AAS
本番環境って前提ならそもそも本番で稼働している設定ファイルはみだりに編集しないってのは分かるけど。
単にコンテナ内でvim使うかどうかって話だとしたら本気で意味分からん。
232: 2018/07/29(日)21:51 ID:PCsU6lV8(5/8) AAS
コンテナの中のファイルは絶対編集しないってどういうことなんだろう。良くあるベストプラクティスに書いてあるから盲目的にそうするって事だとしたら、はぁ、そうですかで話終わりにするけど。
233(1): 2018/07/29(日)22:27 ID:Hv8rsH9m(1/2) AAS
>>238
Dockerはアプリケーションコンテナと言って、
アプリケーションをコンテナ化するもの
システムコンテナと違って、コンテナの中で作業するためのものじゃない。
だから、vimという手動で作業するツールをコンテナに入れる意味はないし、
vim自体をコンテナ化しても使いづらいことは説明済み
> 良くあるベストプラクティスに書いてあるから
ベストプラクティスレベルの話じゃない。Dockerの使い方の基本の話。
とりあえずアプリケーションコンテナとシステムコンテナの
違いぐらい学習してから出直せ
234: 2018/07/29(日)22:32 ID:/XpMabXH(1) AAS
ドヤ顔で未来にエスパーしてて草
235: 2018/07/29(日)22:49 ID:Hv8rsH9m(2/2) AAS
内容は間違えてないだろ？ﾆﾔﾘ
236(1): 2018/07/29(日)23:31 ID:PCsU6lV8(6/8) AAS
>>233
アプリケーションコンテナとシステムコンテナの違い、ですか。そうですか。
教科書にはきっとそう書いてるんでしょうね。その辺はよく知らないけど、たぶん間違ってないんだと思います。
でも、私はDockerで開発するファイルも編集します。はい。
237(1): 2018/07/29(日)23:37 ID:PCsU6lV8(7/8) AAS
コンテナでsshd起動してsshでアクセスするなとかいうのも基本としてあるってのは聞いたことある。
けどそんなの関係ねぇ。
実際エンジニアに開発環境としてコンテナ提供するのにsshでアクセスできないって不便でしかない。
238(1): 2018/07/29(日)23:54 ID:PCsU6lV8(8/8) AAS
ちなみにシステムコンテナってSolarisのzoneみたいなものかな。Linuxだと何かあるのだろうか。
239(1): 2018/07/30(月)01:20 ID:QZl1Bega(1/13) AAS
>>236
コンテナの中にあるファイルはコンテナ削除すると消えるでしょ？永続化しない。
残っていてほしいファイルはボリュームでコンテナの外にだすわけだから
そのファイルの編集はコンテナの外でやれば良いわけ
中にvimを入れておくのは開発中とかの一時的にしかやらんよ
っていうか使いづらいでしょ？ あんたvimの設定とかしてないの？
デフォルト設定で使いづらいからカスタマイズするのが常識だけど
コンテナの中にあるのはなんの設定もされてないvimじゃん
240(1): 2018/07/30(月)01:23 ID:QZl1Bega(2/13) AAS
>>237
関係ないとか言ってないで、自分の解釈が大きくずれているって考えたほうが良いよ
ちょっと間違いレベルじゃなくて、方向性が大きくずれている
変な使い方をしているから、使いづらく感じるんだよ
241(1): 2018/07/30(月)06:34 ID:jEBEwRTJ(1/6) AAS
>>239
残ってほしい開発後のプログラムがあるならgitでpushしとけば良くない？
設定あんまりシナイ派だけど、仮にするとしても、それこそvimrcとかgitでpushしてるものをcloneで持ってくれば設定なんて一撃で終わらない？それじゃあダメな理由とかある？
242(2): 2018/07/30(月)06:40 ID:jEBEwRTJ(2/6) AAS
>>240
解釈がどうじゃなくて、実際便利に使えるかどうかが問題なんだけど。
どんなに正しくても実際に使い難ければ正しくてもやらない。
もちろんセキュリティーや影響は考慮するけど、その辺問題なければ基本がどうとか関係ない。
PMBOKとかAgileとか、基本に忠実にそのままやったら余計効率が悪くなって使えたもんじゃないでしょ。教科書守れば良いって思考は実用的な効率を犠牲にする。
243(1): 2018/07/30(月)06:42 ID:QZl1Bega(3/13) AAS
>>241
gitは作業中断時に一時保存するための道具じゃないし、
設定しないなんて使いづらいだけだし、
いちいちcloneするとか面倒くさいことこの上ないし、
ホストでやれば普通にできることを、いちいちやらないといけないのか？
間違ってる方向に進むとこれから、あれやこれが使いにくいって愚痴るだけだぞ
すでに愚痴ってそうだがｗ その原因はすべて間違った使い方にある
変な癖が付く前に矯正したほうがいい
244(1): 2018/07/30(月)06:43 ID:QZl1Bega(4/13) AAS
>>242
> 解釈がどうじゃなくて、実際便利に使えるかどうかが問題なんだけど。
便利に使うための手段を、お前がみんな捨ててるから、
（俺は不便な中で生活してるから）不便に思わないんだって言ってるだけじゃん
245: 2018/07/30(月)06:44 ID:QZl1Bega(5/13) AAS
>>242
> PMBOKとかAgileとか、基本に忠実にそのままやったら余計効率が悪くなって使えたもんじゃないでしょ。教科書守れば良いって思考は実用的な効率を犠牲にする。
お前のその考え方だと、間違った解釈をして間違ったやり方をやって
余計効率が悪くなった。PMBOKとかAgileはクソって言ってるようにしか見えないね
まず教科書守ってやろう。いまお前は教科書通りのことを守らずに使いづらいと言ってる
246(1): 2018/07/30(月)06:48 ID:jEBEwRTJ(3/6) AAS
>>243
一時保存なんて利用用途で言った覚えはないけど、仮にそうだとしても何で一時保存でgit使ったらダメなの？
あなたって基本に従うってことに束縛されて思考が限定されてる気がする。自分だけでそういう方針で進めるのは勝手だけど、人にやり方強制しだすと嫌われるから考え改めた方が良いよ。
新卒ならまだ良いけど。
247(2): 2018/07/30(月)06:51 ID:jEBEwRTJ(4/6) AAS
>>244
よくわからんけど、君の言ってるようにアプリケーションコンテナの中のファイルは編集するなって事を守ると何が便利なの？物凄く不便じゃない？
ローカルなホストにファイルを永続化させるよりgitにpushする方が安心感あると思わない？
248: 2018/07/30(月)06:52 ID:QZl1Bega(6/13) AAS
>>246
gitはバージョン管理するための道具であって、
バージョン管理しないならタダの保存に過ぎないから
それにgit使うなら、コミットする時に、メールアドレスと名前の設定がいるだろ？
gitでpushするならssh鍵が必要だろ？
rootでやるわけないから、自分のhomeディレクトリがいるだろ
お前本当にコンテナの中でgitでpushとかしてるんか？
してねーだろ。使いづらいもんな
お前はまだ初心者で、どうせgitもオープンソースものをcloneするぐらいのことしか
したこと無いんだろ。基礎ができてないんだからまず教科書通りにやれと
249(1): 2018/07/30(月)06:54 ID:jEBEwRTJ(5/6) AAS
PMに教科書通りのやり方を強制されて疲弊してる現場を見てきたから経験談として話してるだけ。
教科書通りやって現場がうまくまわってるならそうすればいいよ。
というか、むしろ教科書なぞってうまくいってる現場があるならそれ勉強会とかで話してほしい。見に行くので。
250: 2018/07/30(月)06:55 ID:QZl1Bega(7/13) AAS
>>247
> よくわからんけど、君の言ってるようにアプリケーションコンテナの中のファイルは編集するなって事を守ると何が便利なの？物凄く不便じゃない？
ホストに置いたファイルを編集すればいいだけだろ。
それがコンテナの中にボリュームを通して見えてるんだから
コンテナの中に入って編集する必要がない。
コンテナの中の環境を整える必要もない
もっと便利なものが俺には見えてるんだが、
お前のやり方は何が便利なの？
できるといってるだけで便利なんてお前は一言も言ってないよね？
お前のやり方が俺は不便だと言ってる。反論は？
できる、やったらだめなの？は不便であることの反論にはならない
251(1): 2018/07/30(月)06:55 ID:jEBEwRTJ(6/6) AAS
ということで、あなたのやり方を変えさせるつもりもないし、自分のやり方を変えるつもりもありません。
以上終わり。
252: 2018/07/30(月)06:57 ID:QZl1Bega(8/13) AAS
>>247
> ローカルなホストにファイルを永続化させるよりgitにpushする方が安心感あると思わない？
ホストにあればgitにpushしたいと思ったタイミングでpushできるんだが
コンテナ消すと中で編集したファイルが消える。不便だからgit入れて忘れずにpushしなきゃって
コンテナのファイルを直接編集すると不便だと言ってなかったか？ｗ
253: 2018/07/30(月)06:58 ID:QZl1Bega(9/13) AAS
>>251
俺はやり方をお前に押し付けてるんじゃなくて、
正しいやり方にしないとお前が困るという事実を言ってるだけ
お前はその事実に反論してない。困るのは自分だけだから
良いじゃないかって逃げてるだけだ。
254: 2018/07/30(月)07:00 ID:QZl1Bega(10/13) AAS
>>249
そのPMが教科書通りにやってないだけだよｗ
教科書通りにやることが簡単だと思ってはいけない
教科書に反論するときは、教科書の場合と何が違っているかまで
理解してからじゃないといけない。
教科書になってるぐらいだから基本的には正しいんだよ。
それが当てはまらない理由を見つけない限り、教科書に反論してはいけない。
当てはまらない理由がわからないのは、理解してないってことになるんだから。
255: 2018/07/30(月)07:08 ID:QZl1Bega(11/13) AAS
ほんとね。反論の一つでもできればまだいいんだが、
回避策はあるというだけじゃ、その方が良いってことにはならないんだよ。
全部回避策を入れないとやっていけないってことになってるんだから、
優れた方法っていうのは、回避策を使わずとも自然な形で実現できる
いちいち回避策を考えなきゃやってられないってのは、
やり方が間違ってる証拠でしか無いんだよ
余談だが、アメリカではツールをただ導入するのではなく、そのツールが
想定している使い方を学習して、やり方をツールにあわせるから効率的になるらしい。
日本だとツールを導入して、自分のやり方にカスタマイズさせる。
やり方を変えようとしないから生産性も変わらないし、
ツールのカスタマイズにコストも掛かるとのこと。それと同じだ
256: 2018/07/30(月)09:12 ID:2DtBR6Mw(1/2) AAS
アプリケーションコンテナはyum, aptのパッケージ相当だと思ってるなぁ
基本的に使い捨てて常にクリーンなコンテナに出来るのがいいし, だからこそkubernetesとかで高い自己修復性を持てる
257(1): 2018/07/30(月)09:22 ID:IG0rWwn1(1) AAS
すると、Vimのような手動カスタマイズほぼ必須のアプリは
コンテナ化には適さないのか
docker searchしてもVimが出てこないのが不思議だったがそういうことか
258: 2018/07/30(月)09:55 ID:2DtBR6Mw(2/2) AAS
そのカスタマイズ部分を, プラグインならホストからマップするか別コンテナで, 設定ファイルはホストからマウントする必要があるだろう
259: 2018/07/30(月)16:34 ID:QZl1Bega(12/13) AAS
>>257
手動カスタマイズの有無じゃないな。
プログラム本体がコンテナに隔離されているので、
コンテナの外に自由にアクセスするものは適さない
もちろんプログラム本体がコンテナに隔離されているおかげで
コンテナの外がどうなっていようがいろんな環境に持っていける
コンテナと外部との通信は基本的にネットワーク通信で行うか
ボリュームとしてマウントしたディレクトリ経由で行う
ボリュームとしてマウントするから、コンテナの外がどのような
OSやディレクトリ構造であっても、コンテナの中からは同じよう見える
コンテナの外がどうなっていても中からは同じように見える。
Dockerの "仮想化" というのはこういう意味
（ハードウェアをソフトウェアで仮想的に作り出すという意味じゃない）
もちろん不可能ではないが面倒なだけ
260: 2018/07/30(月)19:40 ID:vC8FJAc3(1) AAS
これいわゆるイキリstaticおじさんが駄々こねて屁理屈連投してるいつもの案件じゃなくて
もしかして今回に限っては、Docker業界的にも、回避策やカスタマイズの工夫するくらいなら
コンテナはそぐわないからツールの使い方としてもやめてねって方向性にいつの間にか大勢が傾いてるのか
261: 2018/07/30(月)19:45 ID:QZl1Bega(13/13) AAS
エクセルで小説書くなってだけの話
262(1): 2018/07/31(火)19:28 ID:9kOFb8Cb(1) AAS
docker-tramp.el 便利だー。この機能使うためだけにemacs使いになっても良いと
思うくらい。コンテナにvimやsshdインストールする必要がありません。
263: 2018/07/31(火)20:23 ID:GXqvrTdQ(1/2) AAS
いまWSL使ってDockerを使っているんですが、atomでホストに置いたファイルを修正して
それをイメージに反映させたいのですが、修正するたびにビルドするのが面倒です。
なのでボリュームを使ってホストのディレクトリをコンテナ内に共有しようと思っています。
Linuxではうまく動いているのですが、WSLだとうまく動かないのですが、
何が問題だと考えられますか？
264: 2018/07/31(火)20:24 ID:GXqvrTdQ(2/2) AAS
と、書き込んでからひらめきました。
WSLで使ってるのはWindows上のDockerなので
パスの指定をC:\〜でやらないといけないきがします。
265: 2018/07/31(火)20:28 ID:C0KTXAUF(1/2) AAS
ビンゴでした！
こんな感じでホストのディレクトリがコンテナから見えました。
これでWindowsのatomを使って簡単に編集できそうです。
スレ汚し申し訳ありません
266: 2018/07/31(火)20:30 ID:C0KTXAUF(2/2) AAS
↑なぜかコマンドを書き込んだらエラーになったので怪しそうな所を大文字で書きます。
docker run -p80:80 -v"$(wslpath -wa www):/var/ｗｗｗ" -d ｈｔｔｐｄ
267(2): 2018/07/31(火)20:33 ID:PupCkl8+(1/2) AAS
>>262
もとからvimもsshdも入れたりなんかしてないよ。
入れるもんでもないしね。
docker-tramp.elも別にいらないかな。
ファイルを修正したいならボリュームにすればいいだけだし、
sshdはdocker execを使えばいいので、
268(1): 2018/07/31(火)20:50 ID:PXAb2zrY(1) AAS
>>267
定位置にあるconfファイル等を色々いじってテストしたい時はどうしているの？
269(1): 2018/07/31(火)20:52 ID:WDZkbP+f(1/2) AAS
>>267
コンテナ提供するアプリエンジニアにdocker exec使えって言うの？
270(1): 2018/07/31(火)20:54 ID:WDZkbP+f(2/2) AAS
大した負荷のかからないコンテナをサーバーって言ってアプリエンジニアに提供するときある。ポート番号ちょっと変わってるサーバだと思って使ってくれてるよ。
本人はdockerだのコンテナだのを使ってる事に気づいてない。
271: 2018/07/31(火)21:27 ID:PupCkl8+(2/2) AAS
>>268
だからボリューム使えばいいじゃない？
$ docker run -it debian cat /ｅｔｃ/debian_version
9.5
# ホスト上のファイルにすげかえ
$ docker run -it -v/ｅｔｃ/hosts:/ｅｔｃ/debian_version debian cat /ｅｔｃ/debian_version
127.0.0.1 localhost
略
>>269
普通に使ってるからなぁ。
アプリエンジニアがDockerfileを書かないで誰が書くというの？
アプリを動かすのに何が必要かを知ってるのはアプリエンジニアだけなんだが。
build, run, exec などを使って正しく動くコンテナのイメージを作るまでがアプリエンジニアの仕事で
コンテナを動かす環境を作って指定されたイメージを起動するのがインフラエンジニアの仕事
>>270
アプリエンジニアがDockerイメージを作ってないのはおかしい。
アプリを作ってる人でないと、アプリを動かすのに必要なものは知らないんだから
「手元のマシンだと動きました」「ライブラリのバージョンが違ってるんですねー」
これをなくすためにDockerがあるというのに。仕事の分担が間違ってる。
272(1): 2018/08/01(水)05:48 ID:rxe3lfEn(1/10) AAS
動くコンテナのイメージ作るのがアプリエンジニアの仕事なら、結局必要なミドルをアプリエンジニアが入れる事になってそれこそインフラエンジニアの作った本番環境と差異が出てしまうと思うのですが。
まあ新規や中小規模のサービスならそれでも問題無いと思うけど。
273: 2018/08/01(水)05:52 ID:rxe3lfEn(2/10) AAS
大きい会社だとIDEしか使ったことがない、CUI触ったこと無いアプリエンジニアとか普通に居りましてですね
まあその程度のアプリエンジニアはいずれ淘汰されると切り捨てるなら問題無いんですけどね。
274(1): 2018/08/01(水)06:00 ID:rxe3lfEn(3/10) AAS
アプリ動かすのに必要なミドルウェアをバージョンも含めて熟知してるアプリエンジニアって相当優秀だと思う。
取りあえずアプリ動く程度に適当にミドル入れまくるアプリエンジニアいるけど、それができるアプリエンジニアすらそこそこ出来る評価なんだけど。
275: 2018/08/01(水)06:12 ID:eV7ibk3+(1/4) AAS
>>272
やっぱお前使い方間違ってるわ
答えだけ言っておくね。本番環境と全く同じ環境になる
276: 2018/08/01(水)06:13 ID:eV7ibk3+(2/4) AAS
>>274
> アプリ動かすのに必要なミドルウェアをバージョンも含めて熟知してるアプリエンジニアって相当優秀だと思う。
お前の会社の人間が馬鹿だってことかな？
そうなんだろうな。
ミドルウェアのバージョンを把握してないで
どうやってアプリが正しく動くことを保証するのか？
言ってみ
277: 2018/08/01(水)06:15 ID:eV7ibk3+(3/4) AAS
コンテナの中にミドルウェアが入ってしまってるのに
どうやってインフラエンジニアがミドルウェアを入れ替えるんだ？
コンテナに手を入れてミドルウェアを差し替えるんか？ｗ
278: 2018/08/01(水)06:18 ID:eV7ibk3+(4/4) AAS
というかミドルウェアがなにかもわかってなさそうｗ
279: 2018/08/01(水)06:57 ID:rxe3lfEn(4/10) AAS
え、もしかして自分でミドル入れずにDockerhubに落ちてるミドル入りコンテナ使ってるクチだったりするの？
280(1): 2018/08/01(水)06:59 ID:rxe3lfEn(5/10) AAS
コンテナの中庭ミドルが入ってしまっているのにって、じゃあそのミドルは誰が入れるの？
アプリエンジニアが適当に入れたミドルをそのまま本番に使ってたりするんですか？
281(1): 2018/08/01(水)07:01 ID:rxe3lfEn(6/10) AAS
インフラエンジニアの居ない規模の企業でアプリエンジニアが勉強して開発から本番運用までやってるって言うなら分かるけど。
インフラエンジニアいるのにミドル部分までアプリエンジニアが制御するって問題無いの？
部署をまたいだアプリエンジニア同士で宗教論争はじまってまとまらないと思うんだけど。。
282: 2018/08/01(水)07:06 ID:rxe3lfEn(7/10) AAS
最終的にはインフラ分からないアプリはフェードアウトするって意見に異論はないけど、まだその時ではないと思ってる。中小規模やベンチャーは知らない。
283: 2018/08/01(水)07:40 ID:vZ5iA/aw(1/7) AAS
>>280
> アプリエンジニアが適当に入れたミドルをそのまま本番に使ってたりするんですか？
なんで適当に入れるんですか？
お前じゃあるまいしｗ
284: 2018/08/01(水)07:52 ID:vZ5iA/aw(2/7) AAS
>>281
お前さ、アプリケーションが動くサーバー作ったことないだろ？
どうせデータベースサーバーのセットアップぐらいしかしてねーだろ？
データベースサーバーのセットアップなんて簡単だもんな
設定ファイルをいじるだけ。そんな簡単な仕事はお前にやらせるよ
で、アプリ開発してないやつが、どうやってアプリケーションが
動くサーバーを作れるっていうの？
あぁ、どうせお前、オープンソースのアプリ動かしてるだけだっけ？ｗ
俺が作ったアプリ、そのアプリが動くのになんのライブラリが必要か言ってみ？
アプリを開発してる俺は当然わかるが、教えないからなｗ
アプリのコード読んで必要なものを調査するとかやんなくていいよ
俺がコンテナのイメージつくってやっからさ、
お前はそれ動かすだけ。おまえにできないことはやらなくていい
お前はDockerr動くLinuxマシンだけ用意してればいい
285: 2018/08/01(水)08:09 ID:rxe3lfEn(8/10) AAS
何をそんなに怒っているの？
286(1): 2018/08/01(水)08:12 ID:rxe3lfEn(9/10) AAS
あなたがよくても他のアプリエンジニアから不満でたりしないの？
あなたのレスみる限り大きな声で周りねじ伏せて自分凄いって思ってるタイプの人に見えますが。
周りは従ってるんじゃなくて腫れ物には触らないようにしてるだけっていうオチじゃないですか？
287: 2018/08/01(水)09:24 ID:rSD2s4kw(1) AAS
マウント合戦はお腹いっぱい
288(3): 2018/08/01(水)10:07 ID:oUHlYMq4(1) AAS
それだけDockerの理解・運用は難しいということだな
俺本読んでもさっぱりわからんかったもん
コンテナがIPアドレスを持つって聞いて、ファッ?ってなったわ
コンテナ=アプリとその動作環境をパックにしたものと
ここで教わったが、アプリがIPアドレスを持つわけないだろう
289: 2018/08/01(水)10:18 ID:V8uA/puM(1/2) AAS
containerizedされたアプリケーションならdocker-composeなりkubernetesなりでミドルウェアごと構成管理するのが普通
この場合はインフラ屋の役割は主としてdockerなりkubernetesクラスタの管理になると思うのだけれど
単に共通テスト環境としてコンテナを使っていて, アプリケーションをcontainerizedせずにリリースするとか単体のコンテナとして配布して使う側で上手に組み合わせてねってものならインフラ屋が実動環境に合わせてコンテナ構成をすることもある
Travis CIとかGitLab CIでビルド環境として使うコンテナはこっちの場合が多そう
テスト/開発環境でもdocker-composeかVagrantした方がいいと思うけども
290: 2018/08/01(水)10:32 ID:V8uA/puM(2/2) AAS
>>288
UNIXソケットを使わない場合にアプリケーション間のデータのやり取りはTCPやUDPで行われることが多いと思うのだけれど, そうするとIPアドレスがないと困るだろう
特にロードバランシングしていると同一ホスト上でないことが普通なので, ソケットが使えないことが多い
291(1): 2018/08/01(水)18:16 ID:vZ5iA/aw(3/7) AAS
>>286
人間の問題と技術の問題は切り離して考えましょう
俺の周りがどうこうとか聞く必要ないだろ？
お前には関係ない話なんだから。俺の周りが凄くて
全員がDockerを使いこなしていて、誰も文句言わなくても、
「お前の」周りではそうじゃないんだろ？
なら、それはお前の周りでの問題であって。
その問題の原因は人間だって素直に認めればいいじゃないか？
下には下なんていくらでもいるんだから、素人集団には
使えませんと言われても、それ技術となんの関係もないやん
292: 2018/08/01(水)18:21 ID:vZ5iA/aw(4/7) AAS
>>288
> コンテナがIPアドレスを持つって聞いて、ファッ?ってなったわ
> コンテナ=アプリとその動作環境をパックにしたものと
> ここで教わったが、アプリがIPアドレスを持つわけないだろう
そう。認識としてはIPアドレスを持ってないと考えていい。
内部の仕組みの話だから。
コンテナ = アプリで、環境の仮想化を行っているため、
そのコンテナ（＝アプリ）は自由にサービスを提供するポートを変更できる。
仮にコンテナの中で80番ポートでアクセスを受け付けているからって、
コンテナ（＝アプリ）は80番ポートでアクセスを受け付ける必要はない。
コンテナが受け付けるポートは自由に変更できる。
それが「仮想化」で実現している機能の一つ
それを実装するために、内部的にルーティングしているというわけ
Dockerの仕組みに詳しい人はネットワークについても勉強するだろうけど
Dockerを使っている段階では、コンテナがどのIPアドレスを
持ってるかなんて意識していない
293: 2018/08/01(水)18:23 ID:vZ5iA/aw(5/7) AAS
>>288
> それだけDockerの理解・運用は難しいということだな
技術職っていうのはそういうもんだよ。
ソフトウェアにおいて技術=知識
知識を得て楽をするか、知識ない人は力ずくで頑張れと
294(1): 2018/08/01(水)21:17 ID:rxe3lfEn(10/10) AAS
>>291
いや、関係あるでしょ。
元々ある程度のリテラシーのエンジニアに使ってもらうこと前提の話をしてるのに、あなたは俺が俺がばっかりで使い手に対する配慮がほとんど感じられない。
さっきもいったようにあなたは腫れ物か、もしくは本当に周りがDockerくらい使いこなせるみたいな優秀なエンジニアばかりの職場で働いてるからそういう考えになるんでしょうね。
せいぜいその職場から振り落とされないようにしてくださいね。
普通の職場で働くと、たぶんあなたは腫れ物扱いされます。
295: 2018/08/01(水)21:18 ID:/ajt4qwz(1) AAS
なんで喧嘩腰なの？
296: 2018/08/01(水)21:22 ID:vZ5iA/aw(6/7) AAS
>>294
> 元々ある程度のリテラシーのエンジニアに使ってもらうこと前提の話をしてるのに、
だから、それ、人間の話ですよね？
技術の話をしてください
297: 2018/08/01(水)21:27 ID:vZ5iA/aw(7/7) AAS
ほんとDockerの話しろっていってるのに、
俺の周りの人間は〜馬鹿ばかりだから〜
人間の話ばっかりｗ
298: 2018/08/01(水)22:48 ID:gpg7eCuF(1) AAS
なんでこのスレこんなに荒れてるの
299: 2018/08/02(木)01:28 ID:NqqEoGeq(1) AAS
AA省
300(2): 2018/08/02(木)06:34 ID:rhKXtEAo(1) AAS
そこで働く人間無視して仕事できる訳ないし、やってるつもりなら大した仕事してない。
勝手なことやるなら本当にインフラも含めて別予算で独自にやってほしい。
えらそうな事言って勝手な事やって、結局尻拭いはインフラ側に押し付ける勝手なアプリエンジニア見ると文句の一つも言いたくなる気持ち分かるでしょ。
インフラエンジニア要らないってのは理想。ただ、その理想を妨げる事が多いのが声がでかいアプリエンジニア。
大概やりたいようにやって自分では運用回らなくなって、別の誰かに運用を押し付けて自分はフェードアウトするってのがお決まりのパターン。
301: 2018/08/02(木)07:40 ID:a1K3N0Xu(1/2) AAS
>>300
そういう話じゃねーよ
人を持ち出してきたら、どんな結論でも覆せるんだからここで話す意味ないだろってこと
例えばウェブサーバー運用するのにLinuxが適しているとなっても
うちではLinux使える人がいないので、Linuxはだめなんですってなるだろ
Javaが適していてもうちではJava使える人がいないでJavaだめなんです。
COBOL使ってください。ってなるだろーが。
もはや適しているかどうかの話じゃなくなるんだよ。
「Dockerの適している使い方は○○です」って結論した後
心の中で「でもうちでは技術者のスキルが低くて使えるやついないんだよ。」って泣けばいいだろ
他の人には関係ない話だ
302: 2018/08/02(木)08:13 ID:a1K3N0Xu(2/2) AAS
>>300
> インフラエンジニア要らないってのは理想。
そんなこと言ってない。アプリエンジニアがやるべきことはアプリエンジニアがやって
インフラエンジニアがやるべきことはインフラエンジニアがやれってだけ
アプリがなんの言語で使ってるかなんて、アプリエンジニアが知っていればいい情報だろ
言語もそうだしアプリ動かすのにインストールしなきゃいけないライブラリやパッケージを、
アプリエンジニアに聞かないでわかると思うか？
インフラエンジニアにはコンテナのイメージ渡すから、それを動かす環境を作ってくれればいい
中が何で動いているかなんか、知ったこっちゃねーだろ？
それとも勝手にディストリやパッケージを適当に入れた挙げ句、ライブラリのバージョンの違いで
動かなかくて、その責任をとってくれんのか？
どうせこういうことすら思いつかなかったんだろ？
だからお前がアプリケーションが動くサーバー作ったことねーだろってわかるんだよ。
303: 2018/08/03(金)23:40 ID:1yCRuO5i(1) AAS
数日かけてDocker使って個人用のミニアプリ書いたぜ
内容はサーバーのとある情報を、別のマシンからブラウザで
グラフで見れるようにする一種の監視ツール
zabbix や nagios みたいに本格的な物はいらない。むしろおもすぎて邪魔
先に結論から言うと、このアプリを新しいサーバーで動かすには
docker run -d -p80:80 -vなどのオプション --restart=always コンテナ名
とdockerサーバーが動くマシンで、たった一行実行するだけでデプロイは完了する
（docker hubにイメージ置けるのであれば、本当にこの一行で終わり。
置けないならばプライベートレジストリから取ってくるように少し準備がいるだろう）
これは個人用のアプリで１人でやっているが、もしインフラエンジニアに伝えるとすれば、
このコマンドとどんなオプション（環境変数）があるかを伝えるだけで終わり
あとは必要なサーバーにデプロイしてくれるだろう
もしDockerを使わずにインフラエンジニアがデプロイをしようとしたら大変なことになるだろう。
なぜかって？だってこれだけの情報じゃ、どんなサーバーを構築すればいいか
インフラエンジニアにはわからないでしょ？何をインストールする必要があるのか？
なんの言語が必要でどのパッケージを入れておかないといけないのか？
スクリプトのパスは？どんなコマンドが必要なのか？などなど
docker使えば、さっき書いたdocker run〜のコマンドだけで構築できるというのに。
304(1): 2018/08/05(日)08:47 ID:t1pjwXO7(1/2) AAS
すごいドヤ顔w
305: 2018/08/05(日)13:08 ID:FlnPtVfq(1) AAS
>>304
めちゃくちゃ便利やでw
今（個人的に）作ってるのはアプリじゃないんだけど
とあるサービスを特定の用途向けにカスタマイズしたもの
起動時に自作スクリプトで独自フォーマットの簡易な設定ァイルを解析して
サービス本来の設定ファイルを生成してから起動する仕組みで、通常なら/etc/以下にある
設定ファイルをいじらなきゃならないのが、簡易な設定ファイルを書くだけでよくなる
中身は既存のプログラムの組み合わせだけど、同じサービスを提供する
別のプログラムを作ったかのように使える
306: 2018/08/05(日)16:28 ID:t1pjwXO7(2/2) AAS
そうですね
307: 2018/08/05(日)21:35 ID:t4Ako3RB(1) AAS
Docker使いこなせる人ってすごいな（皮肉ではなく）
308(1): 2018/08/05(日)21:53 ID:9sU0s1Rh(1) AAS
わざわざdocker使わんでもchrootでいいことにdocker使ってる人が結構いる
309(1): 2018/08/05(日)22:01 ID:yAw8KkqM(1/2) AAS
chrootの親戚のGUIなし仮想アプライアンスに情熱を燃やせる謎
別スレではviの話で盛り上がるし日本人はビルジョイが好きなんだな
310: 2018/08/05(日)22:05 ID:yAw8KkqM(2/2) AAS
あーGUIまでいってるのか、なるほど
311: 2018/08/05(日)23:04 ID:NroY7Fy3(1/2) AAS
>>308
chroot使うぐらいならDocker使うなー
chroot用のディレクトリを準備するのでさえめんどくさい
debootstrapだっけ、懐かしいな。
/procや/devのマウントとかも必要だし。
同じdebianでもDockerだと最小構成で用意されてるから
ダウンロードの時間からして差があるし
誰かがDockerfileのようなものを公開してくれてるわけでもないし
懐かしくてちょっとググってみたけど、
あんな面倒なことやってたのかって思った
312: 2018/08/05(日)23:08 ID:NroY7Fy3(2/2) AAS
>>309
自分だけの仮想アプライアンスを簡単に自作できるからねー
同じものを何度もセットアップしてるなら
それが簡単になるので楽だよ
せっかく頑張って構築したサーバーも
HDDが壊れたとかOSのアップデートでおかしくなったとか
古くなってリプレイスで再インストールとかで
やり直しになってしまうのはダルい
一度Dockerでイメージ作ってると
同じことを何度もやらなくてすむようになるからね
313: 2018/08/07(火)07:54 ID:shK4WVTS(1) AAS
それだけのことならVMや自作rpmでもあんま変わらん…
314: 2018/08/07(火)08:50 ID:FmqfeUYE(1/4) AAS
あんまり変わらないから、何倍も簡単なDockerの方が良いよね
315: 2018/08/07(火)09:01 ID:FmqfeUYE(2/4) AAS
まあ一応VMや自作PRMが何故Dockerに太刀打ち出来ないかと言うと、
まずVMは仮想マシンなんだ。だから既存のマシンに導入することが難しい
既存のマシン上で動いても、仮想マシン故にネットワークに新たなマシンが登場するのと一緒だし、
NATで動かすならDockerに近い形状になるがメモリリソースを無駄に消費するし起動が遅い。
Dockerみたいにコマンド実行の速度で起動できない
自作RPMはDockerと真逆の考え方だな。実行環境を含めて依存しないようにしてるのに
頑張って他のパッケージとの依存関係を解決しないといけない
適切な依存関係になるように自作PRMを作る大変な作業が待ってる。
316: 2018/08/07(火)09:01 ID:FmqfeUYE(3/4) AAS
自作PRMは可搬性がないからWindowsで動かせないってのもあるな
317: 2018/08/07(火)09:03 ID:FmqfeUYE(4/4) AAS
ようするに、
1. 既存の○○と同じことができる
2. かつ既存の○○の問題を解決できる
これがセットになってるのがDockerなわけで
1.の既存の○○でもあんま変わらんと言われても
既存の○○は2.の問題があるでしょって話
318: 2018/08/07(火)09:43 ID:svderS3e(1) AAS
ドヤ顔w
319: 2018/08/07(火)11:13 ID:KYfMTuuE(1/4) AAS
AA省
320: 2018/08/07(火)14:30 ID:kww6lavE(1) AAS
一生懸命に覚えたことをレポートにまとめてるんだよ。
見守ってやろうぜ。
321: 2018/08/07(火)19:30 ID:/C7ROP+b(1) AAS
なんかワロタ
322(1): 2018/08/07(火)20:10 ID:QJmmm+eF(1/2) AAS
自分で書かなくてもMuninとかあるで。
323: 2018/08/07(火)20:28 ID:KYfMTuuE(2/4) AAS
>>322
知ってる。昔会社で使ってた。
だけどあれじゃ俺がやりたいことを満たせないんだよ
機能は高機能だけど、あそこまでいらない
324(1): 2018/08/07(火)20:39 ID:QJmmm+eF(2/2) AAS
Qiitaにでも書いとけ
325: 2018/08/07(火)20:42 ID:KYfMTuuE(3/4) AAS
いわゆるインフラ屋はDockerを使って
ディストリによってパッケージが用意されてるようなものを
Dockerイメージ化するという発想になりがちに思える
つまりDocker使わなくても、普通にパッケージ入れたり
VM使えばいいだろという発想
違うんだよね。Dockerは独自に開発したアプリのために使う
独自に開発したアプリは、誰かが依存関係を
解決したりしてくれないからね
だからアプリが動く環境も含めてDockerイメージにする
そうすりゃDockerさえ動いていれば、簡単にどこでも動くものが作れる
326: 2018/08/07(火)20:42 ID:KYfMTuuE(4/4) AAS
AA省
327(2): 2018/08/08(水)01:40 ID:H2RB231p(1/2) AAS
VMはカーネルやデバイスノードがゲストに独立して用意されているからサンドボックスとして安心できる
これらをホストゲストで共有してるDockerは、ライフラインを共有しているゲストハウスみたいなもの
カーネルぶんのメモリ(敷金礼金)は浮くがinit以降のメモリ(賃料)は当然払わなければならない
起動も10秒以下の差
つまりデスクトップならVM常道
328: 2018/08/08(水)03:48 ID:tyC3gFls(1/10) AAS
あぁ、またこれな
> 1. 既存の○○と同じことができる
> 2. かつ既存の○○の問題を解決できる
> これがセットになってるのがDockerなわけで
VMでもDockerでもサンドボックスとして安心できる
その上で、VMよりも軽いのがメリットなわけで
329: 2018/08/08(水)04:00 ID:tyC3gFls(2/10) AAS
起動も10秒以下の差とかそれで勝負になると思ってるのか？
Dockerは1秒以下
$ time docker run -it alpine echo ok
ok
real 0m0.924s
user 0m0.046s
sys 0m0.031s
メモリ使用量はこんなもん
$ docker stats
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
d68483bb9e21 vibrant_raman 0.00% 868KiB / 30.38GiB 0.00% 5.89kB / 0B 0B / 0B 1
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d68483bb9e21 alpine "sleep 1000" About a minute ago Up About a minute vibrant_raman
ディスク使用量も少ない
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
alpine latest 11cd0b38bc3c 4 weeks ago 4.41MB
マシンリソースを無駄にすること無く、サンドボックスを動かせる
330: 2018/08/08(水)04:18 ID:tyC3gFls(3/10) AAS
> CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
> d68483bb9e21 vibrant_raman 0.00% 868KiB / 30.38GiB 0.00% 5.89kB / 0B 0B / 0B 1
ちなみにこれ、メモリリミットが30.38GiBとなってる
GPUメモリに1GB使ってて、つまり32GBのメモリを搭載したマシンなんだ
なんで（個人PCなのに）こんなにあるのかと言うと、
6年ぐらい前にOpenStack使ってプライベートクラウドを作るために
たくさんの仮想マシンを起動できるようにとMAXまで積んだんだ
（ちなみにDockerの登場は5年前の2013年）
仮想マシンだと、最低でも1台で数GBは欲しいでしょ？
VM1台で平均2〜4GB割り当てるとして、約10台分。
プライベートといってもクラウドならこれぐらいほしいよね。
でもDockerが登場してプライベートクラウドの熱も冷めた
（本物のクラウドを使うようにしたのでもはやプライベートで作る気はない）
DockerならVM単位での起動じゃなくて、アプリ単位での起動になるので、
メモリは実際に使用した分しか使わず必要なメモリ量もぐんと減った
用途に対してかなりオーバースペックなPCになってしまったよｗ
331: 2018/08/08(水)04:26 ID:tyC3gFls(4/10) AAS
> カーネルぶんのメモリ(敷金礼金)は浮くがinit以降のメモリ(賃料)は当然払わなければならない
あ、ちなみにこれ間違い
仮想メモリ間でのメモリ共有は一部のVMに搭載されているが（セキュリティのためにデフォルトは無効のようだね）
外部ﾘﾝｸ[html]:docs.vmware.com
基本的に仮想メモリ間でメモリは共有されないし、
当然空きメモリも共有されない
2GBのメモリを割り当てたVMは、その中でどんなに小さいプログラムを
実行しようがメモリは2GB使用する
VM（カーネルメモリ + プロセスメモリ ＋ 空きメモリ） VS Docker（プロセスメモリ）
という比較になる。
Dockerだってカーネルメモリ使用するじゃん、なんで右側に書いてないのか？と
思うかもしれないが、ホストのカーネルを共有してるんだからこれで良い。
VMだって同じようにホストのカーネルメモリ書いてないだろ？
332: 2018/08/08(水)04:28 ID:tyC3gFls(5/10) AAS
AA省
333: 2018/08/08(水)04:40 ID:tyC3gFls(6/10) AAS
ま、そもそもVMとDockerは違うもので、両方を組み合わせて使うものなんだけどね
クラウドを使っていればわかるはず。
VMを増やすと金はかかるが、新しいスペックのマシンを
手に入れることで、クラスタの合計性能が増える
Dockerコンテナを増やすだけじゃ、クラスタの合計性能は増えない
Dockerコンテナは一つの（仮想）マシンの中でCPUやメモリを
無駄にすることなく（サンドボックス化された）プロセスを複数起動したり
アプリのデプロイを用意（手元で動いたイメージをそのまま使うとか）にするために使う
目的が違うものなんで、Dockerの代わりにVMを使うとか
VMの代わりにDockerを使うとかいう発想がそもそもズレてる
334(1): 327 2018/08/08(水)05:36 ID:H2RB231p(2/2) AAS
＞目的が違うものなんで、Dockerの代わりにVMを使うとか
＞VMの代わりにDockerを使うとかいう発想がそもそもズレてる
そこだけは同意だな
そこまで理解できたなら賢いじゃないか
335: 2018/08/08(水)07:17 ID:25daI1mK(1) AAS
序論、本論、結論まで到達？
336: 2018/08/08(水)10:38 ID:tyC3gFls(7/10) AAS
>>334
何年も前から理解してるぞw
VMとコンテナをごっちゃにするなって書いたのは、違うスレだったか？
例えば>>76とか書いたの俺だが
> なぜならkubernetesの場合コンテナのオートスケールになるわけだけど
> 起動しているVMの中でコンテナをオートスケールするだけなので
> VMの数もオートスケールしないとコストは下げられないから
VMとコンテナは使い方が明確に違う（ことを理解してなきゃこんなこと書けない）
337: 2018/08/08(水)10:57 ID:tyC3gFls(8/10) AAS
物理マシンもVM（仮想マシン）も、俺にとっては同じマシン扱いなんだわ
形あるハードウェアで形作られてるかそうでないかの違い。
そのマシンにアプリをデプロイする時にDockerを使えば、
そのアプリは同じマシンの他の環境の影響を受けないので
簡単にデプロイできる。
Dockerのメリットはアプリの配布と実行環境なんだよ
「アプリ＋実行環境」でコンテナ化されるから、
LinuxやMacやWindowsに持っていっても動く。
簡単にまとめるなら、
マシン（物理 or 仮想）の中 に
アプリ（パッケージ or Dockerイメージ）をインストール
ってこと。
アプリをサンドボックス化するためにマシンを作るとか重すぎでしょｗ
まさに牛刀割鶏、鶏をさばくのに大きな牛刀を使うようなもの
338: 2018/08/08(水)11:01 ID:tyC3gFls(9/10) AAS
それから「デスクトップ環境」の話
これはアプリか？って問われれば、アプリだと思う人はいないよね
複数のアプリを連携して作られた環境
仮にデスクトップ環境を作るならば、Dockerコンテナはアプリに相当するのだから、
複数のDockerコンテナを連携させるという話になる。
デスクトップ環境を構成する複数のアプリを一つ一つDockerコンテナ化していって
連携させるとか、大変なだけの環境の再発明でしか無い
ここからもわかるように、デスクトップ環境（＝複数のアプリ＋連携）なので
Dockerコンテナ（＝アプリ）と比べるものでないのは言うまでもない話。
デスクトップ環境は誰かが大変な思いをして構成したものを使っていればいい。
物理マシン or 仮想マシン で動いてるデスクトップ環境やらCLIやらsystemdやら。
そこから起動する一つのアプリ、それがDockerコンテナ相当なんだよ
339(1): 2018/08/08(水)17:56 ID:8+YiPWG6(1) AAS
GitLab運用してるんだが, CIで使うビルド環境とかは明らかにDockerないしはKubernetesが優秀
一時Docker-Compose on VMでやってたけど使い捨てVMを構築する処理が重くてしょうがなかった(しかも遅い)
スタンバイ状態のビルド環境VMを2つも作るともう限界だが, Kubernetesなら5個くらいPodをスタンバイさせてても余裕だし新規Pod作成も早い(Docker単体なら10コンテナ並走でもいける)
340(1): 2018/08/08(水)18:46 ID:Gp7Qfh6x(1) AAS
夏休みだな
お前らが当たり前過ぎて書かないこともこうやって書いてあれば誰かの役に立つのだろう
341: 2018/08/08(水)23:00 ID:tyC3gFls(10/10) AAS
>>339
Kubernetesって使用メモリ多くない？1GBぐらい使ってた気がするんだが
だから使わないってわけじゃなく、もうデファクトスタンダードに
なりつつあるから避けようがないと思ってるけど
Docker-Composeは開発者用だと思ってるよ。
ローカルマシンで複数コンテナを組み合わせる時の面倒さを解決するもの
>>340
お前のその書き込みは誰の役にも立たんけどなｗ
上下前次1-新書関写板覧索設栞歴
あと 661 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.048s