Docker

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

http://www.docker.io/

>>473
説明したりPR出したりするのが面倒なのと、俺の周りにそこらで意識高い人がいないんだな、、すまん

もはやDocker関係なくなってんじゃん

ハイパーバイザー借りて
あれっネスト出来ない…quemやvirtualbox糞遅せー！って時助かるよね

WebシステムをCDに焼いて持ち歩ける時代か

>>471
> 自分としては"本番で使うなら" docker の差分ファイルシステムは必要ないし、

それはどういう意味？

1. あってもなくてもかまわないが、必要と思ってないだけ。
2. あったら困る。

>>471
> オンプレだとクラウドのように動的にサーバを追加したリしないので Mesos のようなスケジューラに
> 依存せず自分たちで割当固定したほうが扱いやすいしね。
> （docker が 1 から 10 までできるようになってもこの辺のツールを作ってる会社は変わらないと思う）

いや、dockerを使う理由は、アプリの開発速度にインフラやがついていけないからでしょ？

いまやアプリが使ってる各種ライブラリっていうのは、毎日のように
どれか一つはバージョンアップするんだよ。
そのたびに、インフラ屋は、環境を作り直すのかい？

>>478

1 と 2 の間かな。

Storage Driver （overlay、aufs、devicemapper あたり)はどれも今のところ一長一短で
パフォーマンスや細かな不具合がある。
これらの問題がなければ運用面でのメリットがあるのでできれば使いたい。
ただ、これらの問題があるかぎりはトラブルシュートが面倒なので「あったら困る」。

Storage Driver のトラブルについてはまとめてくれてる方がいるのでそちらが参考になる。
https://github.com/AkihiroSuda/docker-issues

問題だと思ってるものの中では、仕様として残り続ける物もあるとは思うのでどこかで妥協して
overlay あたりを利用するようになるかもしれない。

>>479

以下、質問の意図を私がちゃんと理解できてないのでおかしいことを言っているかもしれない。

> dockerを使う理由は、アプリの開発速度にインフラやがついていけないからでしょ？
たしかに、アプリ側がトライ＆エラーなどをする場合にインフラ屋が足かせになりってるのは事実。
ただ、それらの多くは技術レベルの問題ではなく、システムの環境的な問題や手順的な問題なので
そこをすっ飛ばして docker イメージをアプリ屋さんが作ってもらうスタイルだと思っている。
docker なら構築手順書としての役割と動作確認環境としての役割をある程度満たしてくれるしね。

> いまやアプリが使ってる各種ライブラリっていうのは、毎日のように
> どれか一つはバージョンアップするんだよ。
> そのたびに、インフラ屋は、環境を作り直すのかい？
これはアプリ屋さんの仕事だと考えている。
デプロイ環境の構築やセキュリティチェック、パフォーマンス対応がインフラ屋さんじゃないかな。
（当然、上記以外のホストOSの管理やNetwork、ロードバランサ、バックアップの設計なども）
バージョンアップするかどうかを最終的に決めるのはアプリ屋さんの仕事だと思ってるし、
バージョンアップ後の動作確認もアプリ屋さんやプロデューサーが実施しないと意味ないしね。

アプリ屋さんが docker で環境を作って動作確認なり出来たイメージを用意する。
それをチェックして配布、deploy して動かす環境をインフラ屋さんが用意する（drootなど）。

つまり、インフラ屋はアプリの動作環境を Dockerfile などで理解はするけど構築はしない。

> つまり、インフラ屋はアプリの動作環境を Dockerfile などで理解はするけど構築はしない。

当たり前じゃね？

っていいいうかDockerfileを見るのは、Dockerfileの中身が信用出来ないからで、
信用できるならば、中身無くていいんだよ。

社員なら信用できるでしょ？ｗ
社員が信用出来ないっていうのなら、その社員が作ったアプリも
信用出来ないわけで。

>>482
> アプリ屋さんが docker で環境を作って動作確認なり出来たイメージを用意する。
イメージをメールで送りまーすとかバカなやり方なわけでｗ
流石にそんなことはしないだろうが、もちろんファイル共有で渡すなんてこともしない。

デプロイの自動化を考えると、イメージをどこからか取ってくるかそれともどこかの誰かがイメージを送り込むか
そのイメージをどうやって効率よく受け渡すか？が必要になる。それがDockerレジストリなわけだよ。

そのDockerレジストリはその仕組み上イメージを差分で送受信するからデプロイも速くなる。
ここで一レイヤーのイメージにまとめてしまったら差分で取ってくることができなくなる。


そしてもう一つ。OSやミドルウェアのバージョンアップ。セキュリティパッチのほうがわかりやすいか？
これはアプリは関係ない。この場合セキュリティパッチをあててからデプロイするわけだが、
これはアプリ屋がやることじゃない。

だからアプリ屋はDockerfileを作るところまでで（もちろん開発中にテストビルドは行う）
インフラ屋はソースコードのリポジトリに含まれたDockerfileを使ってビルドする所を担当することになる。

>>482じゃなくて>>481へのレス

うーん
結局何を言いたいのかな
自分でわけ分かんなくなってないかい

>>485
まずは君、DockerfileとDockerイメージの区別はついているかい？

頭の悪い奴は、説明がヘタで文章が長くなるよな

>>487がせつめいしてくれるそーです

インフラ屋とアプリ屋ってそもそもそんなキレイに分かれてるもんなの？

>>489
うちの会社は俺一人。

プログラマーは、何か1つのプログラミング言語がわかればよいけど、
サーバー構築は、LPIC資格がいる

資格を持っていない人が、サーバーをいじくると、
データが消えたり、大変なことが起こるから、
プログラマーよりも給料が高いし、難しい仕事

俺はプログラマーだが、どっちが難しいかはともかく、
出来る事ならrootは使いたくないわな
サーバー屋さんに丸投げしたいわ

>>491
釣り針が大きすぎるんだよ
でもLPIC限定で言い切る不条理さは捨てがたいし悩ましいな

釣り針ってことは、現実は逆なのか・・・

×LPIC持ってないと大変なことが起こる
×LPIC持ってると大変なことは起こらない

んなこたーない。

俺はいつもお守りと折りたたみ傘を持ってるから、
大変なことは何も起こらないよ。

>>497
適切な例え
TOEICが高いから英語の業務を任せろというぐらい横暴だよね
多少はできるかも程度

自動車運転免許しか資格持ってないや。

わしも

危険物取扱免許を持っているが自分が何を取り扱っていいのか忘れた

俺も持ってたな。内容完全に忘れてる
あれ5年くらいで失効だっけ

Windows 10の最新プレビュー「Build 14361」、Dockerコンテナをサポート
http://itpro.nikkeibp.co.jp/atcl/idg/14/481542/061000239/

　今回のビルドで同社は、Windows上でDockerコンテナを
ネイティブに実行できる機能を搭載したほか、

ん？どういう？。
XPのコンテナとか、NTのコンテナとかそういうのに使うって事？

dockerが何かわかってないだろ

ﾜﾛﾀ

わかってないかも。。
dockerってOS部分はホストを使うんだよね？
windows上でネイティブで動くって事は、Win上にLinuxシステムコールが実装されるって事？。
それとも、Dockerコンテナって仕組みだけで、OS部分はホストであるWindowsなので、
コンテナもWindows用ってこと？

>>503
おや？parrallelsとの関係は如何に？

>>507
これはWindows版のDocker Engine（Docker clientによって管理されるdocker containerの管理サービス）が
組み込まれましたよという話みたい。　使えるコンテナはHyper-Vのもので、コンテナの中身は
Windows Server 2016 Technical Preview 5 Nano Server。　

Docker for Windowsやらあるから混乱するけど、それはLinux VMをVirtualBox内で走らせてそこで
Linux コンテナを走らせてたもの。　これはネイティブにWindowsコンテナをWindowsで走らせ、
それをdockerで管理できますよという話。　

https://blogs.windows.com/windowsexperience/2016/06/08/announcing-windows-10-insider-preview-build-14361/

WindowsServer2016TP3で既にネイティブなDockerは実装されてた
Dockerイメージダウンロードで失敗したから（多分ディレクトリの権限の問題で）
速攻でTP3削除したけどなんでWindows10にまで必要なのかわからん
そんな暇あるなら初めて同時リリースできなかったWindowsServerのほうを何とかしろよ
Docker実装してる間にUbuntuなんかLXDリリースしてんじゃん

>>507
一応Dockerって書いてあるけど根本はWSC（WindowsServerContainer）の実装
LXCのWindows版
知ってるとは思うけどDockerも自身の機能だけでContainerを提供しているわけではないから

なんかこの界隈技術者の流動多いのかな？
またはvmwareへの対抗なんかな？

>>512
対抗というかLXDは既存のハイパーバイザを置き換えることを目標にしてるみたい
LXDが普及したら爆発的にVDIが普及すると思う
もともと今のVMwareとかCitrixとかってエコシステムとかイミュータブルみたいなポリシーに
反してるからさっさと滅亡してほしい
LXDが普及したらDockerはどうするんだろうね

LXDは仮想環境として使う用途
Dockerは単一サービスを提供するためのプロセス実行環境を包むためのもの

dockerってデバイスファイルはどう扱われるの？ 見れない感じ？

>>514
dockerが何かわかってないだろ

またお前か

どっかーいけー
ってか。

>>514の説明だとわかってないだろって言われてもしょうがない
インフラ屋でもなければわかってる必要なんてないけど

こうやって、曖昧なことを言って俺のほうが詳しいんだぜ風を
演出するの得意だよなぁｗ

>>514の内容が正しいか間違っているかさえ言わないんだぜ？
本当は知らないか自信がないから言い切れないんだよ。
どっちでも取れるようなことを言って、あとでつじつまを
合わせようと考えてるわけだね。


なお俺の意見言っておくわ。
>>514の内容は正しい。

514 だが、どこが「わかってない」か書かずに
わかってないと罵倒するだけなら小学生でも出来るw

自分は、dockerなんぞ出る前からchrootやcgroup使ってアプリの実行環境の分離を色々独自に検討してたものだけど
ぜひ、わかってる方に正確な所を語って欲しい所ですなw

自信あるならスルーしてればいいのに。
自信が無いから、自分を肯定したくなるんだよな。

ごめんよw
516 は、いつもの奴だから一言だけ言って放置しようと思ったが、
他にも調子にのる、実装もロクにしたことないくせに
自称俺は分かってるモンが居そうだから、つい、ね。大人気なかったw

そっか？あまりに周りが馬鹿だと発狂する天才もいるから、時によりけりだと思う。総じてどうでも良い
ちなみに、うちの上は >>514 のDockerの使い方をしてなくて運用丸投げなので死ぬ思いをする

>>522
> 自信あるならスルーしてればいいのに。
つけあがるからそれはやったらだめ。
完全にぶちのめしてから、次に行くべき。

Docker使うのに困らないぐらいのマシンのスペックを教えてくれないか？
メモリ4GBストレージ128GBでかなり辛いんだが

>>526
まじて物理マシン使っているくらいのヌルヌルさ感じるけどな〜
物理マシン普通に使っている時はどうなのよ

wineをDockerで使いたいけどまったくうまくいかん

>>528
Dockerは単一サービスを提供するためのプロセス実行環境を包むためのもの

>>528
やったことはないが動くっぽい
ttp://qiita.com/syui/items/b43ba220d9cd1e2fb74f

アホやこいつ>>529

>>530
ストック数13ｗｗｗｗ

>>531
ストックって何？イイネの数と思えば良い？

高ストックがいい記事とは限らないんだよなぁ

本格的な内容だと理解できずにスルーされる程度のユーザー層のサイト

>>532
いいねよりもシビアｗ
いいねは付き合いで押すやつがいるが、

ストック数は、その記事が価値があると
思われてるかどうかはっきり分かるからなｗ

価値があると思われてるかどうかをはかるならストック/ページビューとかでないと
単純にストック数だけ比較するのはナンセンス

ページビューが多い・・・よく検索されているが、価値は少ない
ページビューが少ない・・・検索すらされてない情報

>>536
どっちがいい？ｗ

ストック数は単にバズったかどうかの記録で情報の価値じゃねーぞ

バズるだけならストックしないってｗｗｗ

むしろページビューがバズったかどうかの記録だろｗｗｗ

ストック数ぐらいでしか突っ込みどころが入れられない奴なんだよ
内容がまずいなら普通は内容にケチをつけるからなぁ。

内容がまずいことは一番最初に指摘されてるよね？ｗ

> Dockerは単一サービスを提供するためのプロセス実行環境を包むためのもの

>>542
記事だとlineインストール済みの専用イメージを作ってるぞ
> Dockerは単一サービスを提供するためのプロセス実行環境を包むためのもの
という点ではまったく正しい使い方だろ

> Dockerは単一サービスを提供するためのプロセス実行環境を包むためのもの
探しても見つからないんだけど、そもそもこれはDockerが公式に言ってる文言なの？

>>544
一般的な話だからDockerが公式に言うべきことではない。

アプリケーションコンテナ と システムコンテナ の
違いについて調べましょう

使い方の前提と、どう使うかは別。
Docker便利だけど、/bin/initを叩くとか面倒だよね的な。
じゃぁ、そっち用途のを作るか的な。

いや、そのただの｢一般的な話｣ををまるでそれが絶対的に正しいかのように使ってるから婉曲に指摘したつもりなんだが
通じなかったようだね、申し訳ない

> Docker便利だけど、/bin/initを叩くとか面倒だよね的な。
当たり前だろ
Dockerは単一サービスを提供するためのプロセス実行環境を包むためのもの
なんだから

正しくない使い方をして面倒とか、わかってないとしか言えない。


>>547

ドッキングウィンドウを使用すると、ソフトウェア開発のための標準化されたユニットに
その依存関係のすべてを使用してアプリケーションをパッケージ化することができます。

英語読めなくてもこれならわかるでしょｗｗｗ

ドッキングウィンドウ糞ワロタ
dockerのサイトの英文をgoogleで翻訳してそのままコピペでドヤ顔とかさすが頭の出来が違いますなぁwwwww

>>547
頭の固いおっさんだろうから、放置しとけ

「ハサミは紙を切るためのもの。それ以外は間違っているし、面倒になるのは当たり前ﾄﾞﾔｧ」
と同レベル。間違いでは無いんだけどねぇｗ

あれあれ？ 間違いじゃないんですよね？
間違じゃないなら何が問題ですか？

VPSにプロキシ立てまくって自作自演しまくりたいんだけどおすすめのイメージない？

意味なくね？

これ使って見た人いる？
試したけど起動成功しないしなんで失敗するのかも分からない
https://arukas.io/

去年のサービス開始時から触ってるので
どのイメージをどういう設定で出来ないのかなど提示してもらえれば
アドバイスできるかも

>>552
Dockerなんかいらなくね
VPSよりAWSにインスタンス作ってEIP変えまくればいい

docker 使っても src IP 変わらないですしね。
低コストにやるなら lambda と API Gateway を組み合われば
proxy 設定ができてアクセス毎にほぼ別インスタンスという環境は
構築できそうです。
または GAE でもいいかも。
# 試していないのでプラットフォーム側で対策されてるかもしれないですが

こんなレスにまともな答えが返ってくるとはサンクス

1.12のおーけすとれーしょん

Dockerを使うことでサーバ構築のコード化が図れるのかな
と思って使えるか検討してるのですが
apache2とかあえてforegroundで動かしているみたいですね。
この理由ってどなたかご存じないですか？

既存のインフラ構築と随分違うんだなーとびっくりしてます。

あえてっつーか、裏に回す意味がないだろ。apache専用なんだし

>>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はサーバー｣と言うことか…!!!