Docker

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

http://www.docker.io/

>>560
サーバー構築のコード化というとだいぶ違うな
Dockerの目的はアプリにOSを丸ごとスタティックリンクすることだ
それによってアプリに合わせてサーバーのコンポーネントを管理しなくてよくなる
Apacheの例で言えば、OSが立ち上がってその上でApacheがデーモンとして起動するんじゃなくて、
あくまでOSのコンポーネントが全部丸ごとリンクされた状態のApacheを起動すると考えるといい

>>560
アプリ構築のコード化が図れるんだよ。
そもそもあなたの言ってるサーバー構築っていうのは本当に
サーバーの構築ですか？アプリの構築ではありませんか？って話。

本来サーバーの構築っていうのは、スタンドアローンであれば
OSのインストール部分までだよ。複数台で連携するならば、ネットワーク構成まで。

わかりやすく言うならば、Aというアプリをまったく違うBというアプリに
入れ替えたとしても変わらない部分がサーバー。特定のアプリ専用に
パッケージを入れたりするのはアプリ構築

おそらくあんたがサーバー構築だと思っているもの大部分はアプリ構築になるだろう。
サーバー構築としてやることは大きく減少する。

アプリ構築部分がDockerイメージになることで、そのアプリはいろんなサーバー上で
簡単に動かすことが可能になる。Dockerが動く程度のサーバーさえ用意すれば
そこですぐにいろんなDockerで作られたアプリを動かせるからスケールしやすくなる。

>>562-563
回答頂きありがとうございます。
仰るとおりできるだけインフラにコストを掛けずアプリ側に集中したいという思いから
Dockerを使ってインフラ構築しようと見込んでいました。

ですがコンテナ = linux環境　とういうわけではなく
initプロセスがコンテナには存在しないという差異はあるわけですね。

一つお聞きしたいのですがDocker公式イメージとしてApache+phpなどが公開されています。
これらを使用して本番環境を構築した実績を探したのですが見当りませんでした。
実際のところDockerを使って本番環境を使ってる形っていらっしゃいますか
CIとか駆使して自動でDeployするとかそういう重そうなのはネットで拝見するのですが、VPSでApche+phpのような規模の小さい案件をDockerで楽するというのは可能なんでしょうか？

>>563
「サーバー」の意味も知らん奴が長々と語っても後々自分が恥ずかしくなるだけやで

サービスを提供するのがサーバーなんだが？

>>564
Dockerで何をどう楽にしたいのかを明確にしよう。
サーバー構築をコード化したいだけならAnsibleなどの構成管理ツールを使えばいい。
アプリをサーバーごとパッケージ化してデプロイや構成管理を容易にしたいならクラウドでVMのイメージを使えばいい。
それでもあえてDockerを使う理由があるとすれば、
・手元のPCで開発してAWSの本番環境へそのまま移すなど、異なるプラットフォーム間でもイメージを共通化したい。
・アプリをちょっと更新するだけでもいちいちVMを作り直すのは時間がかかるから避けたい。でもサーバーの中身をデプロイ後に弄るのは嫌。
くらいだろうな。
そもそも小さいアプリならサーバーを弄らないことに拘っても大してメリットないしね。
パッチ当てるだけでもイメージをリビルドしなきゃいけないしホストとコンテナを別々に管理しなきゃいけないしかえって面倒臭いだけ。

>>565
どこが間違ってるか言えてないよね？ｗ

これ読むといいよｗ
http://simplearchitect.hatenablog.com/entry/2016/02/18/165917

>>567
>
>そもそも小さいアプリならサーバーを弄らないことに拘っても大してメリットないしね。
>パッチ当てるだけでもイメージをリビルドしなきゃいけないしホストとコンテナを別々に管理しなきゃいけないしかえって面倒臭いだけ。
まさに仰るとおりです。
テスト環境と本番環境を同じにしたかったわけです。
でも本番環境にDockerを導入するのはデメリットだらけでした。
rsyncで同期したほうが何倍も手軽ですし。

Ansible試してみます。

他の構築手順に関しての意見は別として
「サーバ構築をOSインストールまで、アプリ構築は含まない」という意見は
世の中すべてがそうではないと思いますね。

サーバと言うのは、client-server model で言えば、サービス提供をするプログラムのことなので
mail-server や http-server なども含めてサーバ構築という人もそれなりにいると思います。
というか、本来の定義ではこちらが正しいはずです。

サーバーより>>563のアプリ構築の方が、使い方がおかしいと思うのだが…

つまり｢OSはサーバー｣と言うことか…!!!

そして｢OS以外はサーバーではなくアプリである｣ということだな…ッ

だがまてよ、そもそもOSとは何なのだろうか…!?

正直苦労の割に便利でもないよな

アプリっていうのも本来は応用って意味しかない言葉だからなあ

アプリがポート開いててサーバーとして機能するなんてこともあるし

サーバーが何か別のサービスのAPIを利用して動作していれば
それはつまりある種のアプリケーションと言える

(´・ω・｀)Docker滅びる？

幻滅期に入った感じかな
Dockerが世に出て数年で急速にクラウドが進化・普及してインフラ自体がずっと柔軟になったから、
そもそもDockerで解決すべき問題があんまり無くなっちゃった

そ、そんなあ・・(´・ω・｀)

>>576
自分で構築するならそこまで利便性ないかも

エンタープライズでは流行らんけど
個人でお手軽にDockerHubからpullするのはいいかなって感じ

>>579
Dockerで解決すべき問題を
他の方法でどうやって解決するの？

例えばクライアントで動かしているアプリと
全く同じもの（当然OSやライブラリも同じ）を
サーバーで動かすのはどうやるの？

本題と関係ないけど、クライアントでというのは
「手元の開発環境」でってこと？

>>583
今回は手元の開発環境という意味で書いたけど別にどこでもかまわないんだよ。
手元の開発環境の場合もあるし、CIサーバーの場合もある。
（プログラミングできない）テスターが触るテスト環境の場合もあるし
新しく入社した人の新品のマシンの可能性もある。

リモートのサーバーであったとしてもさくらVPSの場合もあるし
Amazon EC2の場合もあるし、Google Compute Engineの場合もある
いろんなしがらみでクラウド使えず自社サーバーの場合もある

むしろ今はDocker全盛期だけどね。AmazonもGoogleもDockerに対応しているから
Dockerインストール済みのインスタンスを使えばあとはそこにアプリ（Dockerイメージ）をデプロイできる

Dockerイメージ一つに（DBなどを分ける場合もあるけど）各種ミドルウェア、ライブラリなどが
入っているから、バージョンアップするときもインフラはなにを使っているか気にする必要がなくなる。
アプリとサーバーが分離されているのが重要で、OSのバージョンが上がったときもアプリが動かなくなるか気にせずに
行うことができるようになる。アプリはアプリで自分の都合がいいときにバージョンアップできる。

Dockerで解決することができる問題の一つとして
（ホスト）OSをアップグレードと
アプリのアップグレードを別にできるってことだな。

OSが提供しているライブラリや実行環境を使うと、
OSのアップグレードでアプリの動きが変わってしまう可能性がある。
だからアプリのテストが必要になるが時間がかかる。

OSをアップグレードしたいが、アプリを修正しないといけない。
アプリを修正したいが、OSをアップグレードできない。
Dockerがなければこういう悪循環に陥るｗ

Dockerを使えば（Dockerコンテナ内の）OSはアプリの一部として考えるから
さくっとアップグレードしてアプリのテストが行える。
そしてホストOSはアプリのアップグレードとは無関係に自分の好きなタイミングでアップグレードできる。
例えば重要な脆弱性が見つかったときとかね。

こうやって考えてみると
Dockerなくても良いって言ってるのは、
リリースするまででその後のメンテナンスまで考えてないよな。
古いバージョンをいつまでも使い続けるはめになるよ

Dockerってよく知らんのだけどカーネルはホストのカーネルそのまんまなのよね？
ホストのカーネルがサポートしてない機能をDockerのイメージが必要としてたらそのイメージは動かせないってこと？

>>587
それDocker関係あるのか？
アプリがカネールサポートしてない機能を
使おうとしたらどうなると思う？

>>585
それコンテナでなくてもアプリごとに仮想マシン作れば目的は達成できるよね。
むしろDockerを使うことでホストを管理するコストが余計に増えてるだろう。
問題はその方法だと仮想マシンのビルドや起動に時間がかかることで、Dockerを使うことで解決できるのはそこだよ。

>>589
> それコンテナでなくてもアプリごとに仮想マシン作れば目的は達成できるよね。

それを言ったら、アプリごとにマシン作っても目的は達成できるから
仮想マシンすらいらなくなるだろｗ

>>588
関係あるよ？

> アプリがカネールサポートしてない機能を
> 使おうとしたらどうなると思う
当然使えないね
そして君のその反応から見るとDocker使った所でそれは変わらないってことだよね？
じゃあホストのカーネルが理由があってそのある機能のサポートを外したらそのDocker上のアプリも動かなくなるね
じゃあ全然アプリのアップグレードとは無関係に自分の好きなタイミングでアップグレードできないね

場所の話をしたかったわけじゃないのです。

>例えばクライアントで動かしているアプリと
>全く同じもの（当然OSやライブラリも同じ）を
>サーバーで動かすのはどうやるの？

この書き方の場合 iOS などのアプリを開発してる人などからすると
「クライアントで動かしているアプリ」=「iOS アプリ」になるので
なんでそれをサーバ上で動かす必要があるのかになると思ったのです。

ここで「クライアント」という言葉は何を表しているかわかりにくいなと。
上にある、クラサバ的に考えるとおかしいですしね。

仮想マシンでは解決しないのは、
例えば仮想マシンで同じコンテナを2つを同じホスト名動かそうとしたら
ポートがかぶってしまって動かないってこと。
開発環境であればポート80で動くものを複数動かしたくなる。

仮想マシンはマシンであるがゆえに、
マシンの制約から逃れることはできない。
マシンにはホスト名が存在するから、そのホスト名に紐付いてしまう。

だから仮想マシン上で動かすアプリのために、仮想マシンそのものの設定変更が必要になる。

Dockerの場合はそれがいらないからこそ、いろんな場所に移動可能になる。

つかこの人Docker関係なく基本的なことが全く分かってないよね？
上の方で"サーバー"と"アプリケーション"をまるで直行する概念のように語ってたり"OS"がまるで万人の間で定義された1つの何かであるかのように語ってたり

>>591
> そして君のその反応から見るとDocker使った所でそれは変わらないってことだよね？

なにが言いたいのわからない。

どんなものでも変わらないところと変わるところがあって、
変わらないところを提示されたところで、
変わるところは変わるんですが？ｗ

>>591
> じゃあホストのカーネルが理由があってそのある機能のサポートを外したらそのDocker上のアプリも動かなくなるね

カーネルとユーザーランドの違いがわかってないなｗ
Linuxのカーネルは互換性がきわめて高い。

ユーザーランドは変わりまくるから、OSのアップグレードを好きなタイミングで行うことはできない。
しかしカーネルは互換性があるから、アップグレードを好きなタイミングで行って構わないし

アプリはアプリでカーネルの機能は使わない。ユーザーランドの機能を使う。

>>595
わからないんじゃなくて自分がおかしいこと言ってることに気づいたんでしょ？

> さくっとアップグレードしてアプリのテストが行える。
> そしてホストOSはアプリのアップグレードとは無関係に自分の好きなタイミングでアップグレードできる。
> 例えば重要な脆弱性が見つかったときとかね。

変わるところは変わるから、その変わるところに該当するケースではさくっとアップグレード出来ないよね？

>>597
変わる所に該当するケースを言いなさい

ユーザーランドしか使わない普通のアプリばっかりなのに
極論を言うばかりで現実問題ってのをわかってないのかな。

>>596
そんなこと分かってるよ？
カーネル内部のインターフェースは結構変わる、ただしカーネルとカーネル外のインターフェースは変わらない

俺が言ってるのはカーネルコンフィグで変わる部分の話だから

>>598
ずれるからレスは1つにまとめてくれないかな

カーネルの機能に依存したものでコンテナで動かすようなものは
殆ど無いので気にしなくて良いのではと思います。

リスクとしてあるのは当然だが、それが問題となるような人はわかってる人か
アプリケーションコンテナでやるようなことではないことをやろうとしている
まったく分かってない人なので無視したほうが良い気がします。

たまにこれを Docker の問題とする人がいますが、具体的に何をする場合に
問題に成るのか正直わかりません。kernel の version や config が違うから
問題と成るアプリケーションは殆ど無いです。

例として、nvidia-docker などはホストの kernel（というかdriver）に依存するような気がしますが
これはそれなりにわかってる人が触るものですし、提供側も driver と docker command までを
セットで提供しているようなのでかなり特殊です。

>>593
今時のクラウドのVMなら使い勝手は起動時間以外はコンテナとそれほど遜色ないよ。
設定も外部から投入できるし。
開発環境とのイメージ共有だって、Dockerfile使ってるんなら、その代わりにシェルスクリプトや構成管理ツールで
ローカルのVMとクラウドのVMで同じVMを作ることは可能だろう。
問題は起動時間、それがDockerを使う意義だよ。

>>601
俺に対してかな、いやいやDockerの問題だなんて思ってないよ
俺の少ないDockerの知識で考えても、それを問題だと言う人はDockerが何を目的としたツールか理解してないってだけだと思う
"問題"ではなく"特性"だよね

ただそういう特性を無視してDockerマンセーしてるのは逆に特性を問題だって言い張ってるのと方向が違うだけで中身が同じだから気になっただけ

>>603

たかがツールのことで、1% のことを問題だと叫ぶのとそれを無視して残り 99% で
素晴らしいと喜ぶことが一緒とは私は思いませんね。

これが保証されるべきものや人の生死に関わるものならば同意できますがたかがツールです。

そのような人は、1% の粗を探して dis ることを目的にしているようにしか見えないですね。

>>604
意味がわからない、>>576の流れから私の最初のレスが>>587だからDockerをディスることが目的のように見られてるってことですか？
もしそうならそういう意図ではないしあなたがどう思うかだけの主観をレスされても困るんですが、まあご自由にどうぞ

(´・ω・｀)本番環境で使うもんでもないし、
ワイはDockerが滅びようがどうでもいいけど

>>605

あなたが dis っているとか問題だと言ってるとは思ってませんが、
docker を讃えてる人と問題だと言ってる人が中身が同じだと仰ったので反論しました。
# twitter などでは、この点に関して dis ってる人がたまにいますね。

ちなみに、kernel の違いに関してですが、docker のホストでの kernel の違いによる影響は
技術をそこそこわかってる人は突っ込みたく成るかもしれません。
ただ、docker を使ってる上でこの特性は実用上無視して問題ないです。
漠然と気持ち悪さや不安感があるのはわかりますが、一般的なアプリケーションコンテナにおいて
具体的に何が問題と成るか考えれば特にないというのは当たり前のことです。

>>607
> docker を讃えてる人と問題だと言ってる人が中身が同じだと仰ったので反論しました。
なるほど、私の中でその部分は完全に私の主観を述べただけスルーされるもの(どう感じるかは正誤の2択ではないのでそもそも反論には意味がない)だと思っていました
主観同士をぶつけた所で意味はないのでそこはどうでも良いですね

> ちなみに、kernel の違いに関して
> docker を使ってる上でこの特性は実用上無視して問題ないです
それを決めるのはあなたではなくユーザーです

そしてあなたも認めているようにhostのkernelに依存しているのは動かしようのない事実です
(Unikernelとかいろいろ方向転換しようとしているようではありますが)

少なくとも私は、今の所Dockerはhostのkernelを使っている以上、hostのkernelをバージョンアップした結果namespace周りにバグや理由があってそもそもnamespace周りを無効にするような変更があればまともに動かなくなる可能性があるなど、
> ホストOSはアプリのアップグレードとは無関係に自分の好きなタイミングでアップグレードできる
> この特性は実用上無視して問題ない
とまで言ってしまっていいものでは無いと思います

>>607
端から見てて思ったんだけど、（ここで）dockerを讃えてる人って
仮想マシンでいいじゃん？という問いにとんちんかんな答えしか出さないんだよね。

すべてにおいてdockerは素晴らしいんだ！って頑張っちゃうの。
だから、そうじゃないケースもあるだろう？って言う話をすると、
何でディスるんだとか技術的なこととはほど遠い話をし始める。

そういうの見てるとdockerがどんどん怪しげに見えてくるんだ。
まあおれがどう思うかだけの主観だがｗ

メリットが分からんからと言って怪しげは言いすぎだろw

>>608
「アプリがカネールサポートしてない機能を使おうとしたら」という話がきっかけなので
そうではなくコンテナエンジンが必要とする機能が無い場合の話ならばそのとおりですね。
どちらもアプリケーションを動かす上で必要という話ならばそのとおりだと思います。

>>610
いや、メリットはあると思ってるよ。ただ万能じゃないよねというだけ。
仮想マシンの例を出したけど、それだって別に万能じゃない。

ただ、過度なdocker推しを見てると、うさんくさく見えるってだけ。

あーこれがトレンドでなんか新しいものできたから使わなきゃ！みたいなのってあるよね。

>>609
docker 自体が、単なるコンテナ/VMと比較して技術的な面ですごいことは
それほどないので docker の話をする場合にその話をしても無意味ですね。
それこそ「昔から jail が合ったのに」と言われて技術的にはそうですねとしか言い様が無いです。
# hyperkit/vpnkit あたりは技術的にすごいなと思います。

docker の良い点はそれらの技術を組み合わせて使いやすくしたこと、
その使いやすさを享受するためにはあるワークフロー（というか縛り）に乗らないとダメなことですね。
つまり、技術の話ではないです。

その縛りによる世界の中では素晴らしいと感じるのでそのように怪しげに見えるんだと思います。
ちなみにこの縛りが個人的には一番大きなメリットです。

このワークフローと何かを比較すべきであってコンテナとVMの技術の比較なんてほとんど意味ないんです。
608 でも書かれてますが docker も別にコンテナにこだわってるわけではありませんし。
# unikernel の開発者は hyperkit に流れたので、当分はコンテナを使うでしょう

上の dis に関しては twitter で「vm と比較して kernel 共有してるからdocker は使っちゃダメなんだ」
とたまに流してる人がいるので書いてますが、docker の本質はワークフローなので
なんで問題にならないそんなことで dis ってんの？という感想にしかならないです。

>>582
rsync

使う理由を探しているよね(´・ω・｀)

もっと気軽に使いなよ。こんな使い方をしてるよ。

・仮想環境より起動が早いので気軽に使える
・ちょっと試したい時にdockerhubから引っ張ってきて試してみる
・自分のメインディストリビューションで提供されてないバージョンの何か
　が必要な時に、別のディストリをdockerで作って利用する。
・クロス環境がいくつかいる時にツールチェーンがよくわからなくなるので
　dockerコンテナに閉じ込めておく。
・webサイトをそのままデプロイするため

dockerの前は仮想環境でやってたよ。vagrantも使ってたけど。

馬鹿田大学とか民進の討論ですか

仮想OSは、様々な問題が出てくるけど、

Dockerなら、動くそのOS内での話だから、問題がない

さすがに意味不明すぎる
仮想マシンは一つの独立したマシン以上でも以下でもない
もちろんそれ故の使いづらさはあるが、その理由も対策もシンプルだ
一方dockerはコンテナがホストや他のコンテナに容易に影響を与え、下手すりゃホストが乗っ取られる場合もある
別にdockerをdisるつもりはないが、さすがに>>619のような人任せの意識で
dockerのようなプラクティスの未熟な道具に手を出すのはどうかと思うわ

>>619は頭を使わない信者臭がして気持ち悪いが

>>620
>一方dockerはコンテナがホストや他のコンテナに容易に影響を与え、下手すりゃホストが乗っ取られる場合もある

仮想マシンも同じだろう？

dockerむちゃくちゃ使いにくいな
仕事だからしゃあなく使うけどプライベートでは絶対に使わない

Docker、良さある

そこでCoreOSですよ

一番あったらありがたいのはDockerfileを読み込んで
VPS上にサーバ構築できたらありがたいわけです。
いちいちAnsible勉強するのめんどくさい。

>>625
本質を見ようぜ
シェルスクリプトと同じだろ?それ

Dockerfileで構築するとめっさ時間かかるよな
ならもうそのままimageで放り込めよと思う

Dockerfileはあくまでもソースコードで使うのはimage（バイナリコード）でしょ

>>627
ベースイメージを多段にすれば、最終の構築はすぐ終わるぞ

わしはこの方法でイメージファイルが3G超えた

docker-machineでdigital-oceanに構築すると楽なんですけど
これって本番運用可能なものなんでしょうか？

本番って基盤のイメージ

WinでVBox不要になるのか

v1.12.0で実装されたSwarmについて誰か説明してくれ
Amazon ECSに変わるものって認識でいいの？

>>630
俺も本番とかいう言い方嫌い

>>620
> 仮想マシンは一つの独立したマシン以上でも以下でもない
> 一方dockerはコンテナがホストや他のコンテナに容易に影響を与え、下手すりゃホストが乗っ取られる場合もある

アホすぎる・・・。

仮想マシンは独立したマシンだというのなら、
ホストどうのこうのじゃなくて
（ゲスト）マシンが乗っ取られる＝（ホスト）マシンが乗っ取られる
ってことだろ。

仮想マシンが独立したマシンと言うのなら、
危険性はホストマシンが乗っ取られるのと同じだ。

そもそも犯罪者の目的はホストマシンを乗っ取ることじゃなくて
マシンリソースやそこにあるデータを奪うことなんだわ。

ホストマシンを掌握すればより多くのことができるようになるかもしれないが、
別にそれは必須じゃない。一般ユーザー権限であっても
そのユーザーの情報は奪えるわけだからね。

ましてやゲストマシンを奪えたならば、そのゲストマシンの
全データを奪えるのと同じ。ゲストマシンで何かを動かすんだろう？

そりゃ
「被害の大小にかかわらずID:7bogyaJyが死んでお詫びします!」
というならID:7bogyaJyにとっては一緒だろうさ
君が言ってるのはそういうこと
何かあったとき切腹じゃなくて焼き土下座で済ませられるように対策しようというのはセキュリティの重要な考え方の一つだよ

>>636
ならあんたはシステムを作らないほうが良いよｗ
物理マシンを使ったら被害は甚大だからね。

安全にシステムを保つことが出来る力がない人は
何もしない方がいい。

なぜ物理マシンを使ったら被害は甚大だと思うの?
物理マシンは複数のサービスが同居してるから乗っ取られたときの被害が大きく、Dockerだとサービス一つで済むってことか？
別に俺はそこを否定してるわけじゃないが、だとしたら君はDockerでホストが乗っ取られたときのリスクの大きさを認めてることになるね
Dockerでホストが乗っ取られたらその上で動作する全コンテナへの完全なアクセスを奪取されるんだから被害は甚大だ

× 君はDockerでホストが乗っ取られたときのリスクの大きさを
○ 君は（コンテナ・仮想マシン・物理マシン・アプリ）でホストが乗っ取られたときのリスクの大きさを認めてることになるね

全部一緒だ。アホめ

× Dockerでホストが乗っ取られたらその上で動作する
○ 仮想マシンが乗っ取られたらその上で動作する
○ 物理マシンが乗っ取られたらその上で動作する

なーんもかわらんｗ

勉強しろアホ目

http://paiza.hatenablog.com/entry/2016/06/07/Docker%E3%81%AF%E5%8D%B1%E9%99%BA%E3%81%A8%E3%81%84%E3%81%86%E8%AA%A4%E8%A7%A3%E3%81%A8%E3%80%81%E6%9C%AC%E5%BD%93%E3%81%AB%E6%B3%A8%E6%84%8F%E3%81%99%E3%81%B9%E3%81%8D%E7%82%B9

コンテナを単に実行するだけで、ホストや他のコンテナがのっとられる
コンテナは隔離環境で実行されますので、単純に(オプションを明示せずに)
一般的なコンテナを実行するだけで、ホストや他のコンテナがのっとられることは現状はありません(知られてはいません)。

ホストのディレクトリ・ファイルを共有すれば、ホストのファイルにアクセスできますが、
明示的に指定しない限り共有されません(-v オプションなど)。
ホストのファイルを共有すればホストにアクセスできますが、
これは仮想マシン(VMware, VirtualBox)でも同じです。

マイクロサービスとかをみると
サービスは独立しているしエラーも他のサービスに影響は与えない
ということはサービスの一つを乗っ取られたとしても
他のサービスには影響を与えないから
影響は限定的ということになる。

Dockerを開発に導入したくて上司に相談したんだけど、コストメリットを示せと言われた。
実際どのくらいでるもんなの？

コストメリットがあるからDockerを導入したいんじゃないのか？

作ったあと開発の手を離れてしまうようなシステムならメリットは全く無い
開発チームにとっても運用チームにとっても面倒臭いだけ

開発スピード上げて差額出せ

2chで聞いたら名無しがこう答えた、で上司は納得するのか?

>>645
まさにこれなんだよな
メリットなんてない
新しいおもちゃ触ってみたいだけ
でもそれは秘密

>>643
そもそも何でDockerを導入しようと思ったの？
その質問だと目的と手段がごっちゃになってるように見えるんだけど

CI回せないならメリットは無いね
開発効率を直接向上できるのはCIであってdockerはそれを実装するためのツールにすぎない
>>649も言ってるけど目的と手段をごっちゃにしてはいけない

>>649
正直いうとごっちゃになってる。
Docker使ってみたいだけ。
だって世間で流行ってるものを使いたいって技術者なら誰しも思う事だろ？
でも費用対効果とか経営者目線で見られると説得しづらいんだよ
技術者と経営者の違いだな

実際コストメリット出す能力もない人間が使っても博打にしかならないと思うぞ

>>651
よくわからないんだけど、ライセンス料がかかるわけでもないのに費用対効果出せないと新しいツールを使うことも許されないの？
そんなこと言い出すと一生新しいツールは使えないってことになるけど

Dockerに興味がある人数人でちょっと使ってみて、メリット・デメリットを洗い出してチーム全体で使うかどうか相談するもんじゃないの？

うちの会社(典型的な請負SIer)でもサーバー系のインフラチームがDocker試してるらしいけど、
コード一行弄るのに客に見積回す会社でしかもアプリのコードを見たことすらないインストール屋が
Docker触ったところでどうするのか甚だ疑問

>>653
実際にやってもらうのは下請けなんだよね
下請けにDocker使ったら効率化できるでしょってやってもらいたいの
その検証費用とか予算取りしないといけない

>>655
下請けに投げるような開発でDocker? 正気か?
煽りでも何でもなく、Dockerで一体何をどう効率化することを期待してるの?

CIじゃなくて
環境をコンテナ化して運用することにメリットないの？

VMを立てるまでもないような、たまにしか走らないバッチ処理にはいいんじゃない
最近はそういう目的のためにAWS Lambdaみたいなのもあるからメリットはオンプレ限定だけど

>>655
酷すぎる
バズワードで現場を振り回す無能上司の見本

理由は「俺のモチベーションが上がるから。」
で通っちゃったりする。
もしくは「とりあえず使ってみないとメリットもわからないでしょ？。」
とかｗ

下請けは効率化する提案持ってこないのよ
理由は人月で見積もってるから稼働がかかる程儲かる仕組み。
だからこっちから効率化案を出さないとやってくれないので。
Dockerを導入してもらって効率化をはかりシステム費用を削減できるかなって思ったけど無理そうだね。
本当に日本のシステム産業って糞だわ