Docker Part2©2ch.net

LXCを使った軽量仮想環境。
これからの動向が気になるところ。
情報共有しましょう。

http://www.docker.io/

前スレ
Docker
http://mao.2ch.net/test/read.cgi/linux/1374861492/

>>222
だから大変だからホストに直接おいたほうが良いって話なんだが

例えばgit diff --no-indexでカレント（gitディレクトリ）以外を
比較したくなったら-v $(pwd):$(pwd)じゃ対応できない。
他にもgit applyとかさ

-v $HOME:$HOMEにしたら動くかもしれないけど、
それでもhomeの外では使えないコマンドになってしまう。
（例えば/opt以下にgitリポジトリをcloneするツールとかさ）

コマンド実行した時、特定のファイルはコンテナの外を見ますが、
それ以外はコンテナの中を見てますとかややこしいだけだから

俺は頑張ったんだって自己満足してたいだけでしょ？
そんなのは意味がないから辞めたほうが良い

あ、そうだ。gitのglobal configがあるから、
絶対HOMEをボリュームにしないとだめなんだ。

ssh鍵の話もあったな
-v $(pwd):$(pwd) -w $(pwd)を書いておけばって
実際には使ってないだろ。

コンテナ化に適してないアプリをコンテナ化しても使いにくいだけ

面白い例を思いついた

> 最初のうちはエディタとかgitとかはどうしても大変に思えてホストに直接置きたくなるんだよな
エディタとgitをコンテナにするとどうなるか

環境変数GIT_EDITOR、コミットメッセージなどを編集する時に使用されるエディタをしている。
まあGITが使う多数の環境変数をコンテナの中に渡す。これだけでも面倒くさくてやりたくないが、

gitをコンテナの中で動かしたりすると、エディタがコンテナの中で起動される
つまり、gitコンテナの中にエディタまで入れないといけない。
さてそのエディタ、当然（？）のごとくgit連携機能がついている。
エディタからgitを呼び出されるならば、エディタのコンテナの中に、gitを入れないといけない

環境変数？ おっと、gitコンテナの中でエディタを起動するならば、
エディタで使う環境変数も、gitコンテナに渡さないといけないな。
おっと、エディタからgitを呼び出すこともあるから、エディタのコンテナを実行する時も
gitの環境変数を渡さないといけないな

はは、乾いた嘲笑の笑いしか出てこない。こんなムダでややこしいことやって
なんの意味があるんだ。

長くて全部読んでないけど、ホスト側のgitなりエディタ設定なりに依存するようなコンテナって筋悪くない？

k8sとかでコンテナを別ホストに移動したら使えなくなるような気がする。

エディタが何かによるけど、vim程度ならコンテナ毎に入っててもいいのでは。有償のIDEでgit連携して使ってる人にとってはちょっとしんどいとかかな。

そりゃ単に、
　普通は使わないけど入っていても良い。イメージのサイズがでかくなるだけ。
程度のことだな

普通はコンテナのイメージはDockerfileで作るし、コンテナの中のファイルを
直接修正することはない。Dockerfileの開発中とかデバッグのために
便利かもーぐらいで入れておいてもいいが、最終的には使わんので消す

コンテナ内のvimは使わない。の意味がわからんやつは
勉強し直したほうが良い

え、普通にvim使ってるけど。何でなの？

本番環境って前提ならそもそも本番で稼働している設定ファイルはみだりに編集しないってのは分かるけど。
単にコンテナ内でvim使うかどうかって話だとしたら本気で意味分からん。

コンテナの中のファイルは絶対編集しないってどういうことなんだろう。良くあるベストプラクティスに書いてあるから盲目的にそうするって事だとしたら、はぁ、そうですかで話終わりにするけど。

>>238
Dockerはアプリケーションコンテナと言って、
アプリケーションをコンテナ化するもの
システムコンテナと違って、コンテナの中で作業するためのものじゃない。

だから、vimという手動で作業するツールをコンテナに入れる意味はないし、
vim自体をコンテナ化しても使いづらいことは説明済み

> 良くあるベストプラクティスに書いてあるから
ベストプラクティスレベルの話じゃない。Dockerの使い方の基本の話。

とりあえずアプリケーションコンテナとシステムコンテナの
違いぐらい学習してから出直せ

ドヤ顔で未来にエスパーしてて草

内容は間違えてないだろ？ﾆﾔﾘ

>>233
アプリケーションコンテナとシステムコンテナの違い、ですか。そうですか。
教科書にはきっとそう書いてるんでしょうね。その辺はよく知らないけど、たぶん間違ってないんだと思います。

でも、私はDockerで開発するファイルも編集します。はい。

コンテナでsshd起動してsshでアクセスするなとかいうのも基本としてあるってのは聞いたことある。
けどそんなの関係ねぇ。
実際エンジニアに開発環境としてコンテナ提供するのにsshでアクセスできないって不便でしかない。

ちなみにシステムコンテナってSolarisのzoneみたいなものかな。Linuxだと何かあるのだろうか。

>>236
コンテナの中にあるファイルはコンテナ削除すると消えるでしょ？永続化しない。
残っていてほしいファイルはボリュームでコンテナの外にだすわけだから
そのファイルの編集はコンテナの外でやれば良いわけ
中にvimを入れておくのは開発中とかの一時的にしかやらんよ

っていうか使いづらいでしょ？　あんたvimの設定とかしてないの？
デフォルト設定で使いづらいからカスタマイズするのが常識だけど
コンテナの中にあるのはなんの設定もされてないvimじゃん

>>237
関係ないとか言ってないで、自分の解釈が大きくずれているって考えたほうが良いよ
ちょっと間違いレベルじゃなくて、方向性が大きくずれている
変な使い方をしているから、使いづらく感じるんだよ

>>239
残ってほしい開発後のプログラムがあるならgitでpushしとけば良くない？

設定あんまりシナイ派だけど、仮にするとしても、それこそvimrcとかgitでpushしてるものをcloneで持ってくれば設定なんて一撃で終わらない？それじゃあダメな理由とかある？

>>240
解釈がどうじゃなくて、実際便利に使えるかどうかが問題なんだけど。
どんなに正しくても実際に使い難ければ正しくてもやらない。
もちろんセキュリティーや影響は考慮するけど、その辺問題なければ基本がどうとか関係ない。

PMBOKとかAgileとか、基本に忠実にそのままやったら余計効率が悪くなって使えたもんじゃないでしょ。教科書守れば良いって思考は実用的な効率を犠牲にする。

>>241
gitは作業中断時に一時保存するための道具じゃないし、
設定しないなんて使いづらいだけだし、
いちいちcloneするとか面倒くさいことこの上ないし、

ホストでやれば普通にできることを、いちいちやらないといけないのか？
間違ってる方向に進むとこれから、あれやこれが使いにくいって愚痴るだけだぞ
すでに愚痴ってそうだがｗ　その原因はすべて間違った使い方にある
変な癖が付く前に矯正したほうがいい

>>242
> 解釈がどうじゃなくて、実際便利に使えるかどうかが問題なんだけど。

便利に使うための手段を、お前がみんな捨ててるから、
（俺は不便な中で生活してるから）不便に思わないんだって言ってるだけじゃん

>>242
> PMBOKとかAgileとか、基本に忠実にそのままやったら余計効率が悪くなって使えたもんじゃないでしょ。教科書守れば良いって思考は実用的な効率を犠牲にする。

お前のその考え方だと、間違った解釈をして間違ったやり方をやって
余計効率が悪くなった。PMBOKとかAgileはクソって言ってるようにしか見えないね

まず教科書守ってやろう。いまお前は教科書通りのことを守らずに使いづらいと言ってる

>>243
一時保存なんて利用用途で言った覚えはないけど、仮にそうだとしても何で一時保存でgit使ったらダメなの？

あなたって基本に従うってことに束縛されて思考が限定されてる気がする。自分だけでそういう方針で進めるのは勝手だけど、人にやり方強制しだすと嫌われるから考え改めた方が良いよ。
新卒ならまだ良いけど。

>>244
よくわからんけど、君の言ってるようにアプリケーションコンテナの中のファイルは編集するなって事を守ると何が便利なの？物凄く不便じゃない？

ローカルなホストにファイルを永続化させるよりgitにpushする方が安心感あると思わない？

>>246
gitはバージョン管理するための道具であって、
バージョン管理しないならタダの保存に過ぎないから

それにgit使うなら、コミットする時に、メールアドレスと名前の設定がいるだろ？
gitでpushするならssh鍵が必要だろ？
rootでやるわけないから、自分のhomeディレクトリがいるだろ
お前本当にコンテナの中でgitでpushとかしてるんか？
してねーだろ。使いづらいもんな

お前はまだ初心者で、どうせgitもオープンソースものをcloneするぐらいのことしか
したこと無いんだろ。基礎ができてないんだからまず教科書通りにやれと

PMに教科書通りのやり方を強制されて疲弊してる現場を見てきたから経験談として話してるだけ。
教科書通りやって現場がうまくまわってるならそうすればいいよ。
というか、むしろ教科書なぞってうまくいってる現場があるならそれ勉強会とかで話してほしい。見に行くので。

>>247
> よくわからんけど、君の言ってるようにアプリケーションコンテナの中のファイルは編集するなって事を守ると何が便利なの？物凄く不便じゃない？
ホストに置いたファイルを編集すればいいだけだろ。
それがコンテナの中にボリュームを通して見えてるんだから
コンテナの中に入って編集する必要がない。
コンテナの中の環境を整える必要もない

もっと便利なものが俺には見えてるんだが、
お前のやり方は何が便利なの？

できるといってるだけで便利なんてお前は一言も言ってないよね？
お前のやり方が俺は不便だと言ってる。反論は？
できる、やったらだめなの？は不便であることの反論にはならない

ということで、あなたのやり方を変えさせるつもりもないし、自分のやり方を変えるつもりもありません。
以上終わり。

>>247
> ローカルなホストにファイルを永続化させるよりgitにpushする方が安心感あると思わない？

ホストにあればgitにpushしたいと思ったタイミングでpushできるんだが

コンテナ消すと中で編集したファイルが消える。不便だからgit入れて忘れずにpushしなきゃって
コンテナのファイルを直接編集すると不便だと言ってなかったか？ｗ

>>251
俺はやり方をお前に押し付けてるんじゃなくて、

正しいやり方にしないとお前が困るという事実を言ってるだけ
お前はその事実に反論してない。困るのは自分だけだから
良いじゃないかって逃げてるだけだ。

>>249
そのPMが教科書通りにやってないだけだよｗ
教科書通りにやることが簡単だと思ってはいけない

教科書に反論するときは、教科書の場合と何が違っているかまで
理解してからじゃないといけない。

教科書になってるぐらいだから基本的には正しいんだよ。
それが当てはまらない理由を見つけない限り、教科書に反論してはいけない。
当てはまらない理由がわからないのは、理解してないってことになるんだから。

ほんとね。反論の一つでもできればまだいいんだが、
回避策はあるというだけじゃ、その方が良いってことにはならないんだよ。
全部回避策を入れないとやっていけないってことになってるんだから、

優れた方法っていうのは、回避策を使わずとも自然な形で実現できる
いちいち回避策を考えなきゃやってられないってのは、
やり方が間違ってる証拠でしか無いんだよ


余談だが、アメリカではツールをただ導入するのではなく、そのツールが
想定している使い方を学習して、やり方をツールにあわせるから効率的になるらしい。

日本だとツールを導入して、自分のやり方にカスタマイズさせる。
やり方を変えようとしないから生産性も変わらないし、
ツールのカスタマイズにコストも掛かるとのこと。それと同じだ

アプリケーションコンテナはyum, aptのパッケージ相当だと思ってるなぁ
基本的に使い捨てて常にクリーンなコンテナに出来るのがいいし, だからこそkubernetesとかで高い自己修復性を持てる

すると、Vimのような手動カスタマイズほぼ必須のアプリは
コンテナ化には適さないのか
docker searchしてもVimが出てこないのが不思議だったがそういうことか

そのカスタマイズ部分を, プラグインならホストからマップするか別コンテナで, 設定ファイルはホストからマウントする必要があるだろう

>>257
手動カスタマイズの有無じゃないな。
プログラム本体がコンテナに隔離されているので、
コンテナの外に自由にアクセスするものは適さない

もちろんプログラム本体がコンテナに隔離されているおかげで
コンテナの外がどうなっていようがいろんな環境に持っていける

コンテナと外部との通信は基本的にネットワーク通信で行うか
ボリュームとしてマウントしたディレクトリ経由で行う

ボリュームとしてマウントするから、コンテナの外がどのような
OSやディレクトリ構造であっても、コンテナの中からは同じよう見える
コンテナの外がどうなっていても中からは同じように見える。
Dockerの "仮想化" というのはこういう意味
（ハードウェアをソフトウェアで仮想的に作り出すという意味じゃない）

もちろん不可能ではないが面倒なだけ

これいわゆるイキリstaticおじさんが駄々こねて屁理屈連投してるいつもの案件じゃなくて
もしかして今回に限っては、Docker業界的にも、回避策やカスタマイズの工夫するくらいなら
コンテナはそぐわないからツールの使い方としてもやめてねって方向性にいつの間にか大勢が傾いてるのか

エクセルで小説書くなってだけの話

docker-tramp.el 便利だー。この機能使うためだけにemacs使いになっても良いと
思うくらい。コンテナにvimやsshdインストールする必要がありません。

いまWSL使ってDockerを使っているんですが、atomでホストに置いたファイルを修正して
それをイメージに反映させたいのですが、修正するたびにビルドするのが面倒です。

なのでボリュームを使ってホストのディレクトリをコンテナ内に共有しようと思っています。
Linuxではうまく動いているのですが、WSLだとうまく動かないのですが、
何が問題だと考えられますか？

と、書き込んでからひらめきました。
WSLで使ってるのはWindows上のDockerなので
パスの指定をC:\〜でやらないといけないきがします。

ビンゴでした！
　

こんな感じでホストのディレクトリがコンテナから見えました。
これでWindowsのatomを使って簡単に編集できそうです。

スレ汚し申し訳ありません

↑なぜかコマンドを書き込んだらエラーになったので怪しそうな所を大文字で書きます。

docker run -p80:80 -v"$(wslpath -wa www):/var/ｗｗｗ" -d ｈｔｔｐｄ

>>262
もとからvimもsshdも入れたりなんかしてないよ。
入れるもんでもないしね。

docker-tramp.elも別にいらないかな。
ファイルを修正したいならボリュームにすればいいだけだし、
sshdはdocker execを使えばいいので、

>>267
定位置にあるconfファイル等を色々いじってテストしたい時はどうしているの？

>>267
コンテナ提供するアプリエンジニアにdocker exec使えって言うの？

大した負荷のかからないコンテナをサーバーって言ってアプリエンジニアに提供するときある。ポート番号ちょっと変わってるサーバだと思って使ってくれてるよ。
本人はdockerだのコンテナだのを使ってる事に気づいてない。

>>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があるというのに。仕事の分担が間違ってる。

動くコンテナのイメージ作るのがアプリエンジニアの仕事なら、結局必要なミドルをアプリエンジニアが入れる事になってそれこそインフラエンジニアの作った本番環境と差異が出てしまうと思うのですが。

まあ新規や中小規模のサービスならそれでも問題無いと思うけど。

大きい会社だとIDEしか使ったことがない、CUI触ったこと無いアプリエンジニアとか普通に居りましてですね

まあその程度のアプリエンジニアはいずれ淘汰されると切り捨てるなら問題無いんですけどね。

アプリ動かすのに必要なミドルウェアをバージョンも含めて熟知してるアプリエンジニアって相当優秀だと思う。

取りあえずアプリ動く程度に適当にミドル入れまくるアプリエンジニアいるけど、それができるアプリエンジニアすらそこそこ出来る評価なんだけど。

>>272
やっぱお前使い方間違ってるわ

答えだけ言っておくね。本番環境と全く同じ環境になる

>>274
> アプリ動かすのに必要なミドルウェアをバージョンも含めて熟知してるアプリエンジニアって相当優秀だと思う。

お前の会社の人間が馬鹿だってことかな？
そうなんだろうな。

ミドルウェアのバージョンを把握してないで
どうやってアプリが正しく動くことを保証するのか？

言ってみ

コンテナの中にミドルウェアが入ってしまってるのに
どうやってインフラエンジニアがミドルウェアを入れ替えるんだ？
コンテナに手を入れてミドルウェアを差し替えるんか？ｗ

というかミドルウェアがなにかもわかってなさそうｗ

え、もしかして自分でミドル入れずにDockerhubに落ちてるミドル入りコンテナ使ってるクチだったりするの？

コンテナの中庭ミドルが入ってしまっているのにって、じゃあそのミドルは誰が入れるの？

アプリエンジニアが適当に入れたミドルをそのまま本番に使ってたりするんですか？

インフラエンジニアの居ない規模の企業でアプリエンジニアが勉強して開発から本番運用までやってるって言うなら分かるけど。

インフラエンジニアいるのにミドル部分までアプリエンジニアが制御するって問題無いの？

部署をまたいだアプリエンジニア同士で宗教論争はじまってまとまらないと思うんだけど。。

最終的にはインフラ分からないアプリはフェードアウトするって意見に異論はないけど、まだその時ではないと思ってる。中小規模やベンチャーは知らない。

>>280
> アプリエンジニアが適当に入れたミドルをそのまま本番に使ってたりするんですか？

なんで適当に入れるんですか？
お前じゃあるまいしｗ

>>281
お前さ、アプリケーションが動くサーバー作ったことないだろ？
どうせデータベースサーバーのセットアップぐらいしかしてねーだろ？

データベースサーバーのセットアップなんて簡単だもんな
設定ファイルをいじるだけ。そんな簡単な仕事はお前にやらせるよ

で、アプリ開発してないやつが、どうやってアプリケーションが
動くサーバーを作れるっていうの？
あぁ、どうせお前、オープンソースのアプリ動かしてるだけだっけ？ｗ

俺が作ったアプリ、そのアプリが動くのになんのライブラリが必要か言ってみ？
アプリを開発してる俺は当然わかるが、教えないからなｗ

アプリのコード読んで必要なものを調査するとかやんなくていいよ
俺がコンテナのイメージつくってやっからさ、
お前はそれ動かすだけ。おまえにできないことはやらなくていい
お前はDockerr動くLinuxマシンだけ用意してればいい

何をそんなに怒っているの？

あなたがよくても他のアプリエンジニアから不満でたりしないの？
あなたのレスみる限り大きな声で周りねじ伏せて自分凄いって思ってるタイプの人に見えますが。
周りは従ってるんじゃなくて腫れ物には触らないようにしてるだけっていうオチじゃないですか？

マウント合戦はお腹いっぱい

それだけDockerの理解・運用は難しいということだな
俺本読んでもさっぱりわからんかったもん
コンテナがIPアドレスを持つって聞いて、ファッ?ってなったわ
コンテナ=アプリとその動作環境をパックにしたものと
ここで教わったが、アプリがIPアドレスを持つわけないだろう

containerizedされたアプリケーションならdocker-composeなりkubernetesなりでミドルウェアごと構成管理するのが普通
この場合はインフラ屋の役割は主としてdockerなりkubernetesクラスタの管理になると思うのだけれど

単に共通テスト環境としてコンテナを使っていて, アプリケーションをcontainerizedせずにリリースするとか単体のコンテナとして配布して使う側で上手に組み合わせてねってものならインフラ屋が実動環境に合わせてコンテナ構成をすることもある
Travis CIとかGitLab CIでビルド環境として使うコンテナはこっちの場合が多そう
テスト/開発環境でもdocker-composeかVagrantした方がいいと思うけども

>>288
UNIXソケットを使わない場合にアプリケーション間のデータのやり取りはTCPやUDPで行われることが多いと思うのだけれど, そうするとIPアドレスがないと困るだろう
特にロードバランシングしていると同一ホスト上でないことが普通なので, ソケットが使えないことが多い

>>286
人間の問題と技術の問題は切り離して考えましょう

俺の周りがどうこうとか聞く必要ないだろ？
お前には関係ない話なんだから。俺の周りが凄くて
全員がDockerを使いこなしていて、誰も文句言わなくても、

「お前の」周りではそうじゃないんだろ？

なら、それはお前の周りでの問題であって。
その問題の原因は人間だって素直に認めればいいじゃないか？

下には下なんていくらでもいるんだから、素人集団には
使えませんと言われても、それ技術となんの関係もないやん

>>288
> コンテナがIPアドレスを持つって聞いて、ファッ?ってなったわ
> コンテナ=アプリとその動作環境をパックにしたものと
> ここで教わったが、アプリがIPアドレスを持つわけないだろう

そう。認識としてはIPアドレスを持ってないと考えていい。
内部の仕組みの話だから。

コンテナ = アプリで、環境の仮想化を行っているため、
そのコンテナ（＝アプリ）は自由にサービスを提供するポートを変更できる。

仮にコンテナの中で80番ポートでアクセスを受け付けているからって、
コンテナ（＝アプリ）は80番ポートでアクセスを受け付ける必要はない。
コンテナが受け付けるポートは自由に変更できる。
それが「仮想化」で実現している機能の一つ

それを実装するために、内部的にルーティングしているというわけ

Dockerの仕組みに詳しい人はネットワークについても勉強するだろうけど
Dockerを使っている段階では、コンテナがどのIPアドレスを
持ってるかなんて意識していない

>>288
> それだけDockerの理解・運用は難しいということだな

技術職っていうのはそういうもんだよ。
ソフトウェアにおいて技術=知識
知識を得て楽をするか、知識ない人は力ずくで頑張れと

>>291
いや、関係あるでしょ。
元々ある程度のリテラシーのエンジニアに使ってもらうこと前提の話をしてるのに、あなたは俺が俺がばっかりで使い手に対する配慮がほとんど感じられない。

さっきもいったようにあなたは腫れ物か、もしくは本当に周りがDockerくらい使いこなせるみたいな優秀なエンジニアばかりの職場で働いてるからそういう考えになるんでしょうね。

せいぜいその職場から振り落とされないようにしてくださいね。
普通の職場で働くと、たぶんあなたは腫れ物扱いされます。

なんで喧嘩腰なの？

>>294
> 元々ある程度のリテラシーのエンジニアに使ってもらうこと前提の話をしてるのに、

だから、それ、人間の話ですよね？

技術の話をしてください

ほんとDockerの話しろっていってるのに、
俺の周りの人間は〜馬鹿ばかりだから〜
人間の話ばっかりｗ

なんでこのスレこんなに荒れてるの

そこで働く人間無視して仕事できる訳ないし、やってるつもりなら大した仕事してない。

勝手なことやるなら本当にインフラも含めて別予算で独自にやってほしい。
えらそうな事言って勝手な事やって、結局尻拭いはインフラ側に押し付ける勝手なアプリエンジニア見ると文句の一つも言いたくなる気持ち分かるでしょ。

インフラエンジニア要らないってのは理想。ただ、その理想を妨げる事が多いのが声がでかいアプリエンジニア。
大概やりたいようにやって自分では運用回らなくなって、別の誰かに運用を押し付けて自分はフェードアウトするってのがお決まりのパターン。

>>300
そういう話じゃねーよ

人を持ち出してきたら、どんな結論でも覆せるんだからここで話す意味ないだろってこと

例えばウェブサーバー運用するのにLinuxが適しているとなっても
うちではLinux使える人がいないので、Linuxはだめなんですってなるだろ
Javaが適していてもうちではJava使える人がいないでJavaだめなんです。
COBOL使ってください。ってなるだろーが。

もはや適しているかどうかの話じゃなくなるんだよ。

「Dockerの適している使い方は○○です」って結論した後
心の中で「でもうちでは技術者のスキルが低くて使えるやついないんだよ。」って泣けばいいだろ
他の人には関係ない話だ

>>300
> インフラエンジニア要らないってのは理想。

そんなこと言ってない。アプリエンジニアがやるべきことはアプリエンジニアがやって
インフラエンジニアがやるべきことはインフラエンジニアがやれってだけ

アプリがなんの言語で使ってるかなんて、アプリエンジニアが知っていればいい情報だろ
言語もそうだしアプリ動かすのにインストールしなきゃいけないライブラリやパッケージを、
アプリエンジニアに聞かないでわかると思うか？

インフラエンジニアにはコンテナのイメージ渡すから、それを動かす環境を作ってくれればいい
中が何で動いているかなんか、知ったこっちゃねーだろ？
それとも勝手にディストリやパッケージを適当に入れた挙げ句、ライブラリのバージョンの違いで
動かなかくて、その責任をとってくれんのか？

どうせこういうことすら思いつかなかったんだろ？
だからお前がアプリケーションが動くサーバー作ったことねーだろってわかるんだよ。

数日かけてDocker使って個人用のミニアプリ書いたぜ

内容はサーバーのとある情報を、別のマシンからブラウザで
グラフで見れるようにする一種の監視ツール
zabbix や nagios みたいに本格的な物はいらない。むしろおもすぎて邪魔

先に結論から言うと、このアプリを新しいサーバーで動かすには

docker run -d -p80:80 -vなどのオプション --restart=always コンテナ名

とdockerサーバーが動くマシンで、たった一行実行するだけでデプロイは完了する
（docker hubにイメージ置けるのであれば、本当にこの一行で終わり。
置けないならばプライベートレジストリから取ってくるように少し準備がいるだろう）

これは個人用のアプリで１人でやっているが、もしインフラエンジニアに伝えるとすれば、
このコマンドとどんなオプション（環境変数）があるかを伝えるだけで終わり
あとは必要なサーバーにデプロイしてくれるだろう

もしDockerを使わずにインフラエンジニアがデプロイをしようとしたら大変なことになるだろう。

なぜかって？だってこれだけの情報じゃ、どんなサーバーを構築すればいいか
インフラエンジニアにはわからないでしょ？何をインストールする必要があるのか？
なんの言語が必要でどのパッケージを入れておかないといけないのか？
スクリプトのパスは？どんなコマンドが必要なのか？などなど

docker使えば、さっき書いたdocker run〜のコマンドだけで構築できるというのに。

すごいドヤ顔w

>>304
めちゃくちゃ便利やでw

今（個人的に）作ってるのはアプリじゃないんだけど
とあるサービスを特定の用途向けにカスタマイズしたもの

起動時に自作スクリプトで独自フォーマットの簡易な設定ァイルを解析して
サービス本来の設定ファイルを生成してから起動する仕組みで、通常なら/etc/以下にある
設定ファイルをいじらなきゃならないのが、簡易な設定ファイルを書くだけでよくなる

中身は既存のプログラムの組み合わせだけど、同じサービスを提供する
別のプログラムを作ったかのように使える

そうですね

Docker使いこなせる人ってすごいな（皮肉ではなく）

わざわざdocker使わんでもchrootでいいことにdocker使ってる人が結構いる

chrootの親戚のGUIなし仮想アプライアンスに情熱を燃やせる謎
別スレではviの話で盛り上がるし日本人はビルジョイが好きなんだな

あーGUIまでいってるのか、なるほど

>>308
chroot使うぐらいならDocker使うなー

chroot用のディレクトリを準備するのでさえめんどくさい
debootstrapだっけ、懐かしいな。
/procや/devのマウントとかも必要だし。

同じdebianでもDockerだと最小構成で用意されてるから
ダウンロードの時間からして差があるし
誰かがDockerfileのようなものを公開してくれてるわけでもないし

懐かしくてちょっとググってみたけど、
あんな面倒なことやってたのかって思った

>>309
自分だけの仮想アプライアンスを簡単に自作できるからねー
同じものを何度もセットアップしてるなら
それが簡単になるので楽だよ

せっかく頑張って構築したサーバーも
HDDが壊れたとかOSのアップデートでおかしくなったとか
古くなってリプレイスで再インストールとかで
やり直しになってしまうのはダルい

一度Dockerでイメージ作ってると
同じことを何度もやらなくてすむようになるからね

それだけのことならVMや自作rpmでもあんま変わらん…

あんまり変わらないから、何倍も簡単なDockerの方が良いよね

まあ一応VMや自作PRMが何故Dockerに太刀打ち出来ないかと言うと、

まずVMは仮想マシンなんだ。だから既存のマシンに導入することが難しい
既存のマシン上で動いても、仮想マシン故にネットワークに新たなマシンが登場するのと一緒だし、
NATで動かすならDockerに近い形状になるがメモリリソースを無駄に消費するし起動が遅い。
Dockerみたいにコマンド実行の速度で起動できない

自作RPMはDockerと真逆の考え方だな。実行環境を含めて依存しないようにしてるのに
頑張って他のパッケージとの依存関係を解決しないといけない
適切な依存関係になるように自作PRMを作る大変な作業が待ってる。

自作PRMは可搬性がないからWindowsで動かせないってのもあるな

ようするに、
1. 既存の○○と同じことができる
2. かつ既存の○○の問題を解決できる
これがセットになってるのがDockerなわけで

1.の既存の○○でもあんま変わらんと言われても
既存の○○は2.の問題があるでしょって話

ドヤ顔w

一生懸命に覚えたことをレポートにまとめてるんだよ。
見守ってやろうぜ。

なんかワロタ

自分で書かなくてもMuninとかあるで。