Docker

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

http://www.docker.io/

docker run -i -p 8888:8888 b.gcr.io/tensorflow/tensorflow

docker toolbox使っているならそのデフォルトIP
http://192.168.99.100:8888/
でなんか出てきたぞ

beforehoge | hoge | afterhoge
みたいな処理のうち、hogeが
32bitアプリで、仕方ないから

Docker便利ですね

便利だけど

利用する
便利じゃん

具体的な用途は何?
今使っている物とは別のバージョンのソフトを入れるとか?

今すぐサーバー上で設定済みのWordPressを動かして！
Dockerならできます。

>>387
Dockerなら、何もしなくて設定済みのWordPressインストールされてて即実行できるの?
今すぐっていうことは、ダウンロードも必要ないんだ?

へー、ノーベル賞とかチューリング賞取れるレベルのソフトなんだね。

サーバーのコンテナの次は何だろう

WordPressっていうかWebサービスだよね
Webサービス丸々一つ持ち運べる

>>388
$ docker run --name some-wordpress --link some-mysql:mysql -p 8080:80 -d wordpress

この程度じゃ取れないと思うよ（マジレス

データの保存をどうするか、悩むところだ。
Dockerこんてなのデータ永続化はどうしてるんだろう。

DB

意外とこれを知らん奴が多いのな
Docker使ってなんかやろうと思うなら読んどけよ

The Twelve-Factor App
http://12factor.net/ja/

dockerを勝手に運用に使ってた奴が辞めて現場は大混乱だ

>>395
それだけ重要な人を失ったということだ。

社長が辞めて大混乱になるのと
同じぐらい大変なことが起きてるな。

今どきDockerを知らないレベルはヤバイ
問題は運営方法をどうするか決めずに設定だけやってる奴ら
うちの会社だとバックアップ方法がバラバラなので、どれかコンテナの運用者がいなくなると一気に危険ゾーンだわ

そいつらどんな了見で自分勝手な本番運用しやがるんだよｗ
いますぐ皆クビにしろマジで

>>395
勝手に言うか全部自分に任されてるから勝手にやってるけど
自分が今急に死んだらやばいかも
まあそうならないようにドキュメント書くようにはしてるけど

俺が死んだら、迷惑かけても、痛む心がなくなってるわけだから、どうでもいいや。

俺は嫌な思いしてないから
それにお前らが嫌な思いをしようが俺の知った事ではないわ
だって全員どうでもいい人間だし
大袈裟に言おうがお前らが死んでもなんとも思わん
それはリアルでの繋がりがないから
つまりお前らに対しての情などない

どうした突然ｗｗｗｗ

勝手に運用してるのも問題だけど、辞めるまで気づきませんでした、技術的にスキルが追いつかず引き継げませんってのもまた問題じゃね?

技術力を売りにしながら現場丸投げはダメな会社あるあるだよね〜

>>403
自分勝手な事するような馬鹿にスキルが追いつかないとかありえんからｗ
何の夢見てんだよお前ｗ

>>405
自分勝手なことをやるのは、単に
その会社のコミュニケーションの問題だろ。
そもそも勝手にできてしまうって状況が駄目だってわかる？

一人で作業をさせているってことだし、ドキュメントを
用意してないってことだし、ミーティングもなにもない
情報の共有がされてない会社だってことだよ。


Dockerがわからないのは単に技術力不足。
これはわからないほうが悪い。

>>406
> Dockerがわからないのは単に技術力不足。
こんなレベルのやつ現実の職場にはいないからｗ
おまえあれだろ？春休みの学生さんってやつだろ？
まともな会社に入れるようにせいぜい努力するこったな

>>407
いや？ｗ　いないと証明するには
すべての職場を調べないといけないんだけど。

お前、知ることが出来るはずがないことを
知っていると言ってることに、自分で気づいているか？

ワイのために喧嘩はやめて(´・ω・｀)

>>409
まあ喧嘩するつもりもないが
そんな眠たい事言ってるから>>408みたいな馬鹿が会社に潜りこんでくるんだぜ

へ？ お前の理屈を説得力がないと潰してやったのに、
何言ってるの？ｗ

Docker使う奴は頭おかしい。このスレ見るとよく分かる。

東証一部だが、この醜い争いの元凶である現場の暴走がまさに起きてるぜ
主な理由が、問題起きたら人柱に辞めてもらうことで手打ちにしてもらう。それまでは丸投げと言う素晴らしい管理方針だから
意外と二次受けのほうがしっかりしてるのよ

GUIの管理ツールどれ使ってる？

いらん

dockerではGUIが使えないから使ってない

使えるけど？
使わないけど

>>417
ウケる

vncか母艦のローカルソケット共有だっけ
ググればすぐ出るレベルだからな…

GUIは基本的にかったるい
CUIで済む用途に無理にGUIの皮被せるのって
何の意味も無い

>>420
それな
いちいちコンソール起動するのほんとウザイ

Docker 勉強用に良い本ないですか？
複数のコンテナを一纏めにVPSにデプロイしたり、必要最小限のコンテナを0から構築したいです。
あと仮想ネットワークを使いたくないです。
その変の知識が日本語で一冊にまとまってる本があれば教えてくだせぇ・・・

＞あと仮想ネットワークを使いたくないです
の意味がよく分からない

>>423
なんと言ったら伝わるのか自分でもよくわからないのですが、ホストもコンテナも同一IPで使用したいんです。
Dockerって確か仮想ブリッジみたいなのが勝手に作られましたよね？
それを使いたくないんです。

>>424
＞ホストもコンテナも同一IPで使用したいんです。
よくわからんけど外から見たらホストもコンテナも同じIPアドレスだけど

すみません、ちょっと私の語彙ではうまく説明できそうにありません。
とりあえずネットワーク周りとか複数コンテナの管理法とかが乗ってる本を探しています。
ここ数年でDocker周りのツールが増えまくって、何が何をするツールなのかわかりづらくとっつきにくいんです。
ツールの名前と効果が頭の中で一致しないというか、例えばKubernetesとか言われても何じゃそりゃ状態でして・・・

まだ本はすぐ古い内容になっちゃうしなぁ。
とりあえず、Dockerで遊ぶ。
つぎ管理系ツールを探す。でいいんじゃないな？。
VPSによるしな。

変なこだわりをやりたいなら人に質問せずに自分で調査できるレベルにならないとなあ
この分野もはや本は出ないから英語のマニュアルやらソースやら全部見るしかないだろ

dockerのマニュアルはかなり親切な方だと思うけど
まずマニュアルだけでも大体理解出来ると思うが

用語使って説明できないんじゃ、掲示版で語り合うこともできまい
libert読んでからとか(オイ

もし仕事でやっていて、こういう陳腐化の早い
ソフトやシステムの使い方の日本語の本やドキュメントが無いと何もできないなら
もうこの業界やめたほうがいいよ

日本語の本を買ってもいいのは陳腐化が遅いアルゴリズムとか計算機アーキテクチャとか数学の教科書とかはいいと思うけど、
特定のソフトの使い方なんてものは、英語だろうが何だろうが基本的にはそのソフトのドキュメントを見て手早く済ませるべき話

もし仕事でやっているなら、こういう陳腐化の早いソフトに手を出さない方がいいよ

>>426
ツールが多いのが問題じゃないと思うよ。
あなたのやりたいことに対して必要な知識(ネットワーク周り(NAT)、Dockerとは何か、コンテナの管理って何をするのか)が全然足りてないから、
ツールの概要を読んでも何も見えてこないだけで。

かと言って、これを読めば一通り網羅できるよってのがあるわけじゃないんだけど。

Dockerについては、RedHatの中井悦司が、本を出している

ていうか日本語のdockerの本て数冊しか出てないじゃん
なんか人に頼り切ろうとする姿勢が見える

わかんないことだらけだからこの際ちゃんと勉強して進めたい、という気持ちは間違ってないと思うけどね
ただ、VirtualBoxとかVMwareとかでVMをNATモードで動作させても似たような感じになるから、まずはその辺の書籍でも読んでみたらどうだろうか

日本語の本、数冊しかないけどそれ買えばいいがな

まー強いて言うならTCP/IPの基礎がきちんと分かってないとそもそも駄目
その上で、Linuxの場合iptablesとbridge辺りのことをある程度調べて把握すれば
kvmだろうがDockerだろうが公式のドキュメントに目を通す程度で苦労せずに対応できる

そういう前提となる基礎知識なしに、場当たり的に
入門書に書いてあったりするオマジナイを覚えようとするのが一番ダメ

include stdio.h 思い出した

(´・ω・｀)手を動かさないやつは何をやっても無駄

確かに手を動かすのが大切だね

フルボッコのように見えるけど、助け舟が出てるなぁ

SL移植されとる

docker run -t co2016/sl

SLが走りよる

# docker run -t co2016/sl

連投ごめん・・ミス

Dockerコンテナ上でのJavaの実行はライセンス違反なのか？
http://www.infoq.com/jp/news/2016/04/docker-java

Arukas無料枠あるのか

Docker使った開発してるが興奮してきた
これ将来性はどうなんだ？インフラになるのか？

>>449
微妙。正直な所、一過性のエンジニアのおもちゃのレベルを脱していない。

>>450
同意
ウチの会社ではCIでしか使ってない
つうかLinuxしか動かないしなぁ

Arukas無料なんで
公開即登録しておいた
要るのは（出来ればプロバの）メールアドレスだけだし

有料のは後で出るはず
これが無料でできるの？というレベル

Windows10で将来的にBASHが動くんじゃなかったっけ？
そうなるとdocker絡みでなにかおもしろい動きとかないかな

Windows は HyperV Container を使ったのがまだ正式版じゃないけど出てるよね。
これは Windows のコンテナで、 docker 使って IIS を動かすようなもの。

bash と同じように LinuxAPI を用意する形で docker が実装されることはないと思う。
bash などの UserSpace でどうにかできるプログラムと違って LinuxKernel べったりだし。

将来、「docker -> HyperV Container(windows os) 」 で windows アプリを制御できるようになるけど
「docker -> vmやremote (Linux + docker daemon)」で Linux アプリの制御は変わらないはず。

(昔からある)Linux の docker に関しては、今日の AWS summit で AbemaTVFresh! で
本番で使ってる例が紹介されてたけど、こういうのや AWS や GCP、RedHat のサポートなどをみてると
エンジニアのおもちゃよりはもうちょっとレベルが上ってるのかなと思う。

２ちゃんっておっさんばっかりだから、時代の流れに付いけてないな。
Dockerスレが過疎るとかｗｗｗ

バズワードにつきあう体力がないのよ、おっさんには

>>450-451
あんまりか
バージョンが若いせいかバグも多いよね
思想としては面白いとは思うんだけどな

>>457
言うまでもなく、BSD JailやSolaris Containerとかあって目新しくないし、仮想化技術も進歩してkernel共有するメリットがあんまし感じられないなぁ

と、docker commitもgit commitに比べてコレジャナイ感あるし、、

Jail や Zone と docker を比較するのって use case わかってるのかなって感じる。

docker の基本はパッケージングでその方法として現在はコンテナ使ってるだけだし。
Jail や Zone では Arukas のようなサービスや k8s や ECS のような仕組みを
作ろうとはなかなかならない。

Jail や Zone はインフラ屋のおもちゃでそれ以上にするのは辛かった。
それに対して、docker はアプリ屋のおもちゃだからインフラ屋でピンと来ない人が多い気もする。

あと、docker は思想が強すぎるからそれが合わないというのもあるな。
インフラ屋としてはキモい面も多い。
だから droot とかが作られてるんだろうけど。

https://codezine.jp/static/images/article/7894/7894_03cs.png

dockerって性能ネイティブ同等で仮想のいいとこ取りできるんだろ

>>459
>Jail や Zone と docker を比較するのって use case わかってるのかなって感じる。

コンピュータ屋のおもちゃであることには変わりないだろう？

>>459
なるほど
インフラとアプリどっちもかじってないと良さが分からないってことは

>>459
話を聞いてdrootは無いなって思った。

あれ思想がどうこういうより、
dockerを使った→ちょっとした問題点があった→普通のコンテナでいいんじゃね？
という単純な発想で作られたものだよ。その他の理由は後づけ。

古いやり方を引きずってるだけで、それでいてイメージのビルドツールとして
dockerを使おうとしているから、結局dockerの知識が必要になって、
さらにdrootを使うことで使えないdockerの知識と
drootそのものの知識が必要になる。

dockerの問題点は、dockerのバージョンアップで解決するし、
drootはdockerに依存しつつ、dockerとは全く違う劣化版を
個人で作ろうとしているから、将来性も感じられない。

現時点では、drootは確かにこの点ではdockerよりもメリット有るね。
だけど、dockerのメリットを随分と失っているよね。という感想で、
そして時が経てば、dockerのバージョンアップで、
drootのメリットってもう無いよね。になっていくと思う。

>>459
インフラ屋のおもちゃってのはよく聞くけど、それを開発するにもネットワーク、マシン、OS、プラットフォームが必要(とそこに至るまでの知識)じゃない？

俺は配線〜アプリまで全部やるけど、正直dockerのimage起動するからよろ！って渡されたら中身がカオスってたりしそうで怖い。glibcってナンデスカ？って人が古いまま使ってるとか容易に想像できる

なんというか、

途中でおくってしまった、、
OSI参照モデルとかだと下位レイヤーの知識は必要ないんだが、現状そう上手くいかないよな。

あと、dockerと関係のツールの分裂と乱立っぷりを見るととても不安になる

>>464
> 正直dockerのimage起動するからよろ！って渡されたら中身がカオスってたりしそうで怖い。glibcってナンデスカ？って人が古いまま使ってるとか容易に想像できる

意味がわからん、Dockerfileみれば中身なんてわかるし、
最新にしたければDockerfileからイメージビルドしなおせばいいだけじゃん。

>>466
人から渡された物をいちいち中身検証して最新にするのかよ。
なんでそんな面倒なことをしなければならんの？

上から下まで知ってるとか書くわりには
dockerについてぜんぜん知らずに
よくそこまで否定するな

>>467
Dockerfile見るのがそんなに手間になると思えんのだが…

インフラ屋としては Dockerfile の中身は当然見るし、
今ならばプルリクきたら「Docker Security Scanning」や「Vuls」あたりで
CIなりで自動でチェックを入れることを検討する。

そういうのが面倒なら docker 使うのやめたほうがいいよ。向いてない。

Docker 社も今以上にインフラ屋に使いやすくするつもりはないはず。
アプリ屋やデザイナー、プロデューサーには Kitematic や Docker for Windows/Mac で
便利にしていくという方向性があるけどね。

使ってて楽しいからエンジニアの自分としては「おもちゃ」という表現でいいけど、
Siri のバックエンドとして使われてたり、クックパッドで使われてるのを見ると
揶揄するつもりで使ってるなら自分のプライドを保つ以外に意味は無いよ。

IT系でないお客さんの人事/経理などを扱うSI系だとデプロイは1月に1回とか、
サーバも数ラック入れてインフラの設定は年に1回変えるかどうかだし変えるときは
レビューなど含めて1月かかるとかざらだから Docker なんて苦労して使う意味ないしね

>>463
docker を手元で使う多くのアプリ屋としては docker は便利なんだけど
本番の運用として使うインフラ屋としては docker は便利すぎて面倒なんだよね。
docker は「1 から10のうち 1から9 までやってくれる」けど、
私達の欲しいのは「8から10」なんですという場合にdocker を使うのかって話。

自分としては"本番で使うなら" docker の差分ファイルシステムは必要ないし、
docker daemon が提供する REST API も必要ない、Network も iptables とか触ってほしくないし
Host と一緒でいいから Network plugin もいらない。
でも、docker で出来たイメージ(というか今なら OCI フォーマット）や Dockerfile を
アプリ屋と共通の言語として使いたい。

これらはdrootを作った"はてな"やペパボあたりの今までオンプレで運用してたところは
同じように不満を持つんじゃないかなと思う。
オンプレだとクラウドのように動的にサーバを追加したリしないので Mesos のようなスケジューラに
依存せず自分たちで割当固定したほうが扱いやすいしね。
（docker が 1 から 10 までできるようになってもこの辺のツールを作ってる会社は変わらないと思う）

その結果 droot やら haconiwa やら apr などオリジナルコンテナエンジンを作ろうかなとなるだけ。
droot は他の会社が使うものじゃない。あれははてなが必要だから作ったものだし。
ただ似たようなものを作る会社は今後出てくると思う。

または、うちの会社みたいに machinectl(systemd-nspawn)つかったり、 CoreOS の rkt や
OCI の runc を直接使う会社も出てくると思う。
どっちの場合でも共通言語は Dockerfile で、細かな仕様は runc の SPEC.md あたりを参考にしてね。

docker とオリジナルツールについて知識が必要なのはそのとおりだけど、結局コアの技術は今のところ
コンテナ（Namespaces/Capabilities/cgroup）+差分FSなのでオリジナルツールは docker を理解する方法として
デメリットには感じないね。

>>468
いやDocker自体は全然否定はしてないんだ。
ただ、これからはDockerっすよ！！
とかいってスマートに纏めてあるDockerfile渡された事一回もないだけなんだ、、

よくわかんねーからとりあえずchmod -R 777とか書いてたり、、

>>472
前提が変わってるし
自分のレスとも矛盾してるやんけ
んなもんそいつに言えよ

>>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 などで理解はするけど構築はしない。