Docker

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

http://www.docker.io/

>>199
理由書かないと何の説得力もないよ。

仮想環境と書いているが曖昧で、俺が言ってるのは
アプリを仮想化したものだと言ってる。
Dockerで作るのは仮想マシンではない。

この二つをごっちゃにすると、
仮想マシンの中でDockerを作るのは意味が無い。などと勘違いしてしまう。

仮想マシンの中であっても、アプリをインストールして起動する。
Dockerを使うと、このアプリのインストールと起動が簡単になる。

使い方が全く違うんだよ。

アプリを特定の環境 (/usr/lib/libなんちゃらの特定のバージョンがある、など) で動かすための仕組みが仮想環境じゃねーの？

仮想環境をポイっと用意されたらその中で案件毎に複数のアプリをインストールしたりして、
ただ単に分離されたフルのOS環境として使うのが従来の仮想化の一般的な使い方だったけど、
KVMやESX, Hyper-Vなんかよりcgroup/namespace使ったコンテナはとっても軽いので
特定の仮想環境と特定のアプリ(nginx)をワンパッケージとして管理したら良いんじゃない？
ってことで出て来たのがDockerってことと思ってるが

>>201
仮想環境と言われると曖昧だが、
仮想マシンではないということ。

> 仮想環境をポイっと用意されたらその中で案件毎に複数のアプリをインストールしたりして、

「複数のアプリをインストールしたりして」の部分ね。
これがDockerコンテナ化された複数のアプリに変わる。

仮想マシンの中に複数アプリを入れると言っても、
そのアプリには設定が必要。何も設定しないでもいいアプリはあまりない。
つまりアプリのインストールというのは面倒な作業といえる。

それを軽減するためにChefなどのツールを使ったり、
AmazonのAMI（仮想マシンイメージ）を作ったりするが、
それは、アプリとアプリの依存関係を定義しているようなもので、
【「仮想マシンの中に入れる複数のアプリ」で構成されたもの】を作ることになる。
言い換えると、アプリの設定 と アプリ間の連携の設定が結びついてしまう。

Dockerコンテナの場合、単体のアプリを作るものだから、アプリのみの設定を行う。
そのアプリの連携はDockerコンテナの起動オプション（またはdocker-compose等）で行う

だから軽いっていうのもあるけど、新しいアプリのインストール・デプロイの方法なんだよ。
Dockerを導入した場合、仮想マシンというのはマシンスペックを増やすために作るもので、
その中で動かすアプリは柔軟に変更できる。

今のサービスは複数のアプリで構成されるのは普通だけど、その構成を決め打ちで定義してしまうものではなく、
Dockerコンテナで設定済みのアプリを作っておき、そのアプリの配置を好きに変更できる。
1仮想マシン、1アプリでもいいし、ハイスペックな1仮想マシンで全アプリにするのも自由自在

ようはOSすら１アプリって言えるってことでしょ？

>>203
ニュアンスの違い程度な気もするけど、
俺が言ってることを正確に表現するなら、
OSをアプリに内包するってこと。

（カーネル以外の）OSがアプリの一部になる。
Windowsで言えば、C:\Windows以下にある各種DLL全てを
アプリのディレクトリに入れたようなものかな。

メインはアプリであって、OSを使っているわけじゃないので。

オブジェクト指向信者みたいな奴だな
ただの軽量な仮想環境なんだから、使いたいように使えばいいだろ

パフォーマンスチューニング考えると複数のアプリを1つのコンテナにまとめた方が良い、という話もあるしな

パフォーマンス的にも専用OSにDocker載せたほうが軽い

>>205
いや、軽いだけの仮想マシンとして考えると使いづらいところが多いんだよ。
間違ってそう考えたがゆえにDockerは使えないと判断する人もいるしね。
違うものとして考えないと。

>>206
例えばSQLiteというデータベースライブラリ（サーバーではなくて）があるけど
これと同じようにデータベースをアプリに内蔵するという考え方で
MySQLを一つのアプリに内蔵するというやり方はある。

でもパフォーマンスチューニングという点で、一つのコンテナに
まとめたほうが良いという意見は聞かないな。どこで聞いたの？

>>207
さすがに物理マシンでそのまま動かしたほうが速いでしょｗ
もちろん仮想マシンよりかは速いけどさ。

>>208
http://thinkit.co.jp/story/2015/05/26/6037

コンテナ内のチューニングは面倒だな
環境でころころ変わって統一的にコンテナを扱えなくなるのはうまくない

> 環境でころころ変わって統一的にコンテナを扱えなくなるのはうまくない
具体的に言うと、何がダメなの？

一部の環境でのみバグったり劣化したりするリスクが増える

具体的にどの環境でのみバグった？

普通のアプリであれば、アプリ以外の部分、
つまりカーネル、OS、libc等の基本的な
ライブラリ、アプリの言語のバージョン、
その言語用のライブラリと依存するものが多い。

OSのアップグレードなんかしたら、それらが
変わってしまうから、一部の環境のみでバグったりするね？

でもDockerコンテナ化すれば、アプリにアプリが適切に
動く環境そのものを同梱できるから、
アプリ以外の部分は、カーネルのみになる。

だから一部の環境のみでバグるということが少ないはずなんだが？
もう少し、具体的な事例が聞きたいね。

dockerコマンド自体にバージョン違いがあるのだから、
管理側が2つを操作するよりは、1つをまとめておいた方がいい場合もあるやろ
面倒なやっちゃなー…

>>214
ホストOS上で、二つのアプリを操作するのが面倒だってこと？
何を言っているのかよくわからない。

>>212
しばらく待ってみましたが、やはりそんなリスクは
想像だけのもので、具体例は出せないようですね。

>>214
こちらも結局説明なしのようですね。
想像で言ってみたけど外れてたという類

>>217
オプション指定一つとってもバージョン違いあるやろ
外れてるのはお前の頭のネジやで

>>218
そっちじゃない。

> 管理側が2つを操作するよりは、1つをまとめておいた方が
これが意味不明という話

Dockerって、chrootみたいなもの？

>>220
「chrootの機能を継承した技術」を使いやすい形に統合したものかな。

知っているとは思うけど、chrootは単に
プロセスから見えるルートディレクトリを変更しただけ。

それを更に発展させてルートディレクトリだけではなく
プロセスやネットワークも分離させて、プロセスに対して
そのプロセスに独立した環境を作り出すのがコンテナ（LXC等）

ちなみに古いバージョンのDockerはLXCを利用していた。
今はlibcontainerを使ってカーネルのコンテナAPIを直接呼び出している

でDockerはそのカーネル提供しているコンテナAPIを応用して作られたソフトウェア
コンテナのビルド（作成）とその実行を行うための環境を提供している。

コンテナAPI自体は昔からあったわけだが、従来は使うためのツールが不足していて大変だった。
Dockerを使うとDockerfileというテキストファイルを用意することでコンテナイメージを
簡単に作成でき、コンテナが利用するリソース（CPU、メモリ、メットワーク）を
コマンドライン等で指定しつつ簡単に起動や停止が行えるようになる。

chroot+jailの発展形という説明があったな

>>221
昔流行りかけたXenみたいな感じでいいのかね？
コンテナイメージってファイル群じゃなくてでかい単一ファイル？

>>223
Xenはマイクロソフトに魂売ってHyper-Vでしょ？ｗハイパーバイザー部類だしょ？
コンテナは単一じゃなくてホストの１プロセスでは？

>>223
> 昔流行りかけたXenみたいな感じでいいのかね
ぜんぜん違う

chrootを知っていて、なんでそう勘違いするのかよくわからんが、
同じカーネルで動く1プロセスのルートディレクトリと
プロセス空間その他を隔離しただけ。

違いの一例を上げるとXenもKVMも仮想マシンを作るから
仮想的なハードウェアの一つとして仮想ディスクも必要になる。
だけどDockerはchrootと同じようにルートディレクトリを変えるだけだから
カーネルから認識されている同じディスクを使用する。

Dockerのコンテナはカーネルから見れば、単なる1アプリにすぎない。

> コンテナイメージってファイル群じゃなくてでかい単一ファイル？
chrootと同じようにファイル群。

1つのイメージは複数のレイヤーから構成されレイヤーにはファイルシステムの差分が記録される
1つのレイヤー = 1つのディレクトリ、通常イメージの最初のレイヤーにはchrootと同じく
OSのシステムファイルのほぼ全てが、次のレイヤーには差分だけが記録される。
このレイヤーはコンテナイメージの修正時に再利用/共有されるため、時間とディスクの節約になる。

訂正
× レイヤーにはファイルシステムの差分が記録される
○ レイヤーにはファイル単位で差分が記録される

別にディスクイメージが記録されてるわけじゃない。
レイヤー=ディレクトリに普通にファイルがある

こういう仕組みを提供しているのが
Dockerなわけだね。

>>225
ネットワークってどうやって別空間にしてるの？
chrootのときはしかたないからエイリアス使ってたけど
あとchrootのときみたいにやたらマウントポイント汚す？

chrootが謎の技術で/dev,/procを別物にした上で
上にaufsみたいなのが被さってるイメージでいいの？

k8sを使うと同一ホスト上の複数のコンテナに同じポートを割り当てられるんでしょうか？

Dockerで同じイメージを冗長化のために
A,B、2台のプライベートレジストリにpushしたとします。

Dockerfileでベースイメージを指定する時、
Dockerfileを書き換えずに、ベースイメージを取得する
プライベートレジストリのサーバーを変更する方法ありますか？

ただし2台のプライベートレジストリ（サーバー）はホスト名が異なり
DNSの変更は行わないものとします。

ぶっちゃけDockerfileのFROMに
プライベートレジストリのURLを含めることが気持ち悪いです。

いったんローカルに持ってきてからtag付けたら

>>227
ネットワークは、コンテナ接続用の仮想ブリッジがホストに作られてそこに接続される
ホストの外とコンテナとの通信は、ポートフォワードでできる

設定次第ではこれ以外の構成も可能だが、コンテナのメリットがなくなる場合もあり

DockerfileにVolumeを記載したときの動作がわからないです。
これを記載すると、docker run したときに-vのオプションをつけたときと同じ動作をするのでしょうか？

>>233
いいえ。DockerfileのVOLUMEは単にディレクトリを作るだけと考えてください。

例えばmountコマンドで/mnt/hoge/にマウントしようと思ってもできません。
先にマウントポイントとなる/mnt/hoge/ディレクトリを作成しておく必要があります。


VOLUMEは、-vオプションでマウントするためのディレクトリ作成するだけです。

>>234
なるほど。
そういう用途なんですね。
理解しました。

なんかWS2016TP3のイメージダウンロードで失敗して
Docker起動すらできないのだが・・・

docker インスコしたら、なぜかgitがアンインスコされてマジギレなんだが
docker作者いたらぶん殴ってやりてえわ
何考えてるんだ基地害、マジで死ね

ちなWinだが
嫌がらせなのか
gitconfigも消えやがった
マジで損害賠償モンだぞゴミ野郎が
何なんだマジで、インストーラーに選択肢にも出てなかったgitの文字が出てきて嫌な予感がしたが
まさかアンインスコしてわけわからんgitもどきのゴミぶちこまれるとは
スパイウェアかよ、ありえない

1時間無駄にした
俺様の睡眠時間削るとは何様だよゴミの分際で
マジで死ね、勝手に人様の環境のgit削除して入れ直すとかどう考えても頭イカレてんだろ基地害
頭にウンコでもつまってるのかこのゴミみたいなインストら−作ったゴミ屑は
ISISに爆殺されて死ねや

※実際には消えたのではなくて、追加で新しくmsys環境がインストールされ
パスが変わっただけである。

ダメなんだろ。
向いてないね。

Windowsみたいなゴミ使うからそうなる

どっかに行ってしまったんだろうね

それをOSやDockerのせいにするのは無能

コンテナ起動して一個だけコマンド実行して終わったら
コンテナさよならってのはできませんか？

できる

手動でgccのAndroid向けクロスコンパイル環境を作ろうとしてるんだけど、もううまくいかないやー
Dockerにその用途に向いたコンテナないかな？

Dockerは

1. 可能か不可能か・・・可能だ
2. 以前より簡単にできる ・・・ YES
3. 簡単にできる ・・・ NO
4. ハマる・・・YES

だからなｗ

え、Androidビルド環境なんかで悩むところあるか？

>>249
Makefileが手書きのLinux向けフリーウエアをビルドしようとしていて、Makefileをいじっても環境変数をいじってもなかなか通らなくてね
ちゃんと自分でMakefileを修正できていないのが原因なんだろうけど、他も自信がないから環境が整ってるところでやってみたいかな

>>246
よかったらヒント教えていただけると助かります

もし自分で辿りつけたらフィードバックしますね

「docker 起動」
「docker 停止 削除」で検索！

シェルスクリプトにdocker runとdocker rm書けばいいだけだろ

単一のコマンドをコンテナで実行するだけならLXCでいいじゃん

>>254
> 単一のコマンドをコンテナで実行するだけならLXCでいいじゃん
めんどくせーだろｗ

dockerはパッケージでインストールするとして、インストールだけが終わった状態から、
たったこれだけで単一のコマンドをコンテナで実行できるんだぞｗ

docker run debian /bin/bash --version

もちろんdebianの所を変えれば、その他のコンテナで実行できる。
LXCで同じことをやってみてくださいよｗ

docker使おうとしてdocker run コンテナ
ってやってもsyntax errorとか出て何一つ動かない
試したのはfedora,ubuntu,busybox,gccあたり
環境はFedora23 i686
XeleronM410 メモリ512MB

ミスった・・・Celeronね

command not foundではなく、syntax errorとでるのなら、
dockerはインストールされているのだろう？
docker --versionってやってみて。

Docker version 1.8.2-fc23, build 1a57647-dirty
ダウンロードとかは普通にできるんだけどいざ動かそうとするとうんともすんとも言わない
エラーはこんな感じ
exec format error
Error response from daemon: Cannot start container 602972c2cf599bd4702de17c25e64d7608fbc7fbc74c128ca789baad53e0852b: [8] System error: exec format error

32bitだからでは

やっぱり？
32bitダメなのかー

Docker hubでよくわからんのだけど、
公式でないものは、危険な可能性があるってことでいいの？

AUTOMATED BUILDに関しては、リポジトリが表示されているから
おそらく大丈夫なのだろうと思うけど（でも工夫すれば抜け道ありそう・・・）
そうでないものは、どのDockerfileから生成したか？の情報ないよね？

追記、AUTOMATED BUILDの抜け道思いついた。

ソースリポジトリは表示されているけど、
タグを複数つけた時、Dockerfileは何故か一つしか表示されてないみたい。

これを利用すると別のディレクトリで作って、
あたかもこれで作ったみたいな見せ方ができそう。

何する気だよw

>>264
例えばMySQLを高度に最適化したイメージを作った
ふりをして、データを抜くコンテナを作るとか

Dockerの使い方を勉強したいんだけど
どこのサイトを見ても、docker.ioをインストールした後から
の手順が急にぼんやりした説明になっている

xeyesをdocker上で動かすとか
そういう分かりやすいサンプルはないの？

何のためにつかうんだ？

docker上の話は普通にやればいいだけだろ

docker pull ubuntu
docker run -i -t ubuntu /bin/bash
切り替わったらaptでもつかって好きにいじればいい
量産したかったらそのコンテナを登録して増やす

なんかまたDockerを仮想マシンと考えてる奴ができてそうだな。

コンテナをLinux仮想マシン扱いすること自体はいいんでない。意外とそういうところから面白い使い道が発見されるのかもよ

コンテナを仮想マシンとして使うのは、OpenVZが昔からあるから
それを使えばいいんだよ。

DockerはOpenVZではないものとして作られているんだから、
OpenVZ的な使い方をするには合わない。

>>266
docker xeyesでググればxeyesをつかったサンプルがいくつかあるが。
それじゃ不満？

ググるなんて能力あるわけ無いだろやめてやれよ

キーワードまで教えてもらってぐぐれないなんてことないだろ

ここにキーワードがあるじゃろ




・・・・・・

xeyesをdocker上で動かす方法のググり方を教えて下さい
↓
docker xeyes でぐぐる
↓
ありがとうございました。

もしかして: docker lxc

32bit対応してくれねーかなー

無料のLinuxで32bit対応が欲しいという理由は
ハードウェアが対応してないからだと思うが、
新しいパソコンを買ったほうが良いと思うよ。

OSなしでいいんだから3千円台＋送料ぐらいから買える
http://kakaku.com/used/pc/ca=0010/?s2=10

わざわざ32bit限定でdockerが必要なケースがあるのか？

仕事でそれしか支給されてないとかw
流石にそんな会社はないか

>>280
hostapdでWiFiAP使えないと困るからノートになるじゃん
でノートで3000円だと2007年くらいのになってi686しかつかえない
>>281
俺の鯖で動かない
大学受かったら新しい鯖買う予定だけどそれまでは無理
WiFiは〜Piにして鯖と分ければいいんだろうけどね

>>283
家かなんかでサーバー機として常時稼働させていればいい
あんたが今使っているノートからログインして使うんだよ。

>>284
ちがう
自宅の常時稼働鯖がノートじゃないとアクセスポイントにできないって話
で金もない

あとレンタルサーバーでVPSを借りるって手もあるな。

だが大学入試があるなら、遊んでないで勉強しとけ。

>>286
すいませんね勉強に戻ります
カナダに一回払いで買った鯖あるけどローカルでも動かしたい時があるのよ

>>285
だからなんだ？と思うだけだが、
新しくPC買って、そのノートから直結するなり
ハブ経由で接続すればよかろう？

ラズパイでdockerとかアリでしょ？
環境ぶった切ったり
IP毎にサービス割振りしてるよ
OH少なくて助かってる

へー、ラズパイでDocker動いたのか。
ARMだからパッケージ少ないし対応してないと思ってたよ。
基本技術はコンテナだからOSレベルで対応してるのかな。

http://dev.classmethod.jp/hardware/docker-on-raspberry-pi2/
> 結論から言うと動きます。が、実用的ではないです。それは、
> DockerコンテナはDockerホストと同じCPUアーキテクチャでないと動作しないからです

docker はchrootみたいなものなの？
docker動いている最中に ホストからファイル見れたりする？

ググれば全部出てるぞ
日本語訳されてるであろうArchwikiでも読んでこい

OS イメージをベースにして Docker コンテナを作るメリットって、
ホストOS に縛られずにコンテナを配置できるって理解であってる？

ただ、サーバーのメモリやストレージの節約を考えると
ホスト OS は決め打ちにして、コンテナには OS イメージを含めない方がいいと思うけどどうなの？
実際の運用でもサーバーごとに OS やバージョンが異なるなんてことはないはずだしね。

ごめんなさい。すぞい勘違いをしていました。

DockerHub に登録されてる Dockerfile を見ていて気がついたのですが、
Docker イメージは、基本的に何らかの OS イメージをベースにして作るんですね。

FROM scratch となってるものもいくつかありましたが、
FROM を遡っていくとほとんどが何らかの OS イメージをベースにしていました。

OSのイメージはDebianで100MBを切る。
Alpine Linuxならわずか5MBだ

コンテナは仮想マシンじゃない。だからホストOSのカーネルを使用する。
コンテナで起動したアプリ以外の、各種デーモンも起動しない。
だからメモリ使用量もアプリを直接動かすのと大差ない。

つまりサーバーのメモリやストレージの節約は考える必要が無い。

実際の運用ではサーバーごとに OS やバージョンが異なる。
アップデートをすることで日々更新され続けるからだ。
LinuxのLTS（長期サポート）なんて5年しかない

>>293
ホストに縛られないというかコンテナをコピーするだけでそのまま実行環境を別のホストに移せる
あと1つのホストに複数の実行環境を構築できる
これらは従来のVMでも出来ることだけどまるまる1台分を仮想化するのと違ってリソースをより効率よく使うことができる

Dockerを仮想マシンの一種として考えてしまうとインフラよりの発想となってしまう。
これではDockerがもてはやされている理由を理解できない。
Dockerはアプリ開発者の立場で考えるとわかる。

まず（ホスト）OSのアップデートで勝手にライブラリのバージョンが
変わってしまうと困る。例えばRubyのライブラリを勝手に
アップデートされたらアプリが動かなくなる可能性がある。

また、逆にディストリが提供しているパッケージよりも新しいバージョンの
ライブラリを使いたいこともある。1つのホストに複数のアプリを実行する時
アプリごとに使うバージョンを変えたいこともある。
だからアプリ開発者はディストリのパッケージでインストールするライブラリは使わない。
rbenvなどを使ってアプリの一部としてアプリごとにインストールする。
（注 Dockerを使えばrbenvを使う必要はない）

これはRubyライブラリだけの話に限らない。ネイティブライブラリやCLIコマンドなど
アプリから使用するあらゆるものはアプリ独自に入れたい。

アプリはアプリだけで動くのではない。動的リンクライブラリやCLIコマンドまで含めて
1つの動作するアプリとして完全体となる。つまりアプリとアプリを正しく動かすのに
必要なものを含めた完全体がコンテナ。コンテナさえあればアプリは完全に動くので、
ホストOSはDockerさえ動けば良くなる。

これがDockerを使う目的なのだから、その目的を達成できない方法はそもそも代替案にはならない。
ホストOSのリソースの効率化とかそういう話じゃないんだよ。

>>295

ただ、DockerHub で配布されてる centos:6.7 に
yum install git すると image size が 190.6 MB → 323.3 MB
yum groupinstall "Development Tools" などとすると image size が 190.6 MB → 693.9 MB

となり、やはりストレージは食うのかなと。

根本的に使い方が間違っているのかもしれませんが、
通常は git とか コンパイラはコンテナに含めないのでしょうか？

>>297

> アプリはアプリだけで動くのではない。動的リンクライブラリやCLIコマンドまで含めて
> 1つの動作するアプリとして完全体となる。つまりアプリとアプリを正しく動かすのに
> 必要なものを含めた完全体がコンテナ。

なるほど参考になります。

コンテナ =
Ruby で言うところの（ 例にあげて頂いた rbenv というよりは）bundler とか、
Node.js の npm (のローカルインストール) の延長で、
OS のストレージにあるものすべて（動的リンクライブラリやCLIコマンドなども含む）を
1つのアプリ環境としてパッケージできるもの

という理解で落ち着きました。

>>298
> 通常は git とか コンパイラはコンテナに含めないのでしょうか？
含めない。

もちろんコンテナイメージ作成中は適当にやっていいし、
利便性を考えて入れておくのもありだけど、

例えばgitを使ってソースコードを配置したいなら、
RUN apt-get install git & git clone 〜 & apt-get remove git (例なので適当）
のようにしてgitを入れて必要な処理が終わったら削除する。

（注 1つのRUNでインストールとアンインストールを実行すること。
複数に分けると、それぞれで中間イメージが保存されるのでサイズが減らない）