Docker

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

http://www.docker.io/

>>158
blogで検索しろ

>>159
すまんな完全に耄碌してた

結局、windowsで動かすdockerはvmwareでcolinuxじゃないということかなぁ
あと、リソースのリミットやcgroupはより実利用に向けてだね。あとは、レジストリのメモリサイズ減っててほしいな減ってたら使いたい
何よりもラベル助かる。というか必須にしようや

と、食いつきにくい餌をばらまく

>>157
公式から実行ファイル落としてきて差し替えるだけでアップデートできるしねえ

> 結局、windowsで動かすdockerはvmwareでcolinuxじゃないということかなぁ

誰か解読してくれ

スマン。俺では読解不能。

>>161
Windowsを使うなっていうことだよ。　

>>164
それをいうのならMacOSXもじゃね？
Docker動かんし。

>>162
colinuxは仮想マシンじゃないってことじゃないの？

ああ、「Winだと仮想経由になっちゃってコンテナとは言い難いな」ってことか？
それ踏まえて読み直すとやっと腑に落ちた

しかし読解レベルで食いつきにくいのは勘弁してもらいたいなw

とはいえコンテナが増えてくるとVMでモジュール化しないと管理しきれなくなる

モジュール化するのはいいが、
なんでVMでなんだ？
もっと軽いものでモジュール化しろよ

その軽いものでホスト環境ごと分離できるなら

>>170
Docker in Docker

>>170
それがコンテナ（プロセス）のグループ化って考え方なんだろうけどね。

ようするのpsコマンドの表示の仕方が悪いって話でしょ？
psした時に、特定のグループは一つにまとまって見れて
そのグループ単位で起動とか停止できればいいんでしょ？

複数のコンテナをまとめて管理するなら、docker-composeが使えるし
イメージやコンテナにラベルが付けられるようになったから
自分でコマンド作ればいい。

最終的にはsystemdと連携してプロセスグループとして管理される。
これが現在進行中の流れだよ。

今すぐ使いたかったら、
GoogleのKubernetes等のコンテナ管理ツールを使えば良い

>>171-172
実行状態もだけどコンテナ間通信のためのポート構成のカプセル化が目的
今度試してみる

DebianでDockerを使いたい

>>173
コンテナ間の通信であればポートを気にすることはない。
普通にコンテナ間でIPアドレス指定してアクセスできる。

ポートを気にするのはコンテナの外から
アクセスする部分だけ。

どっかの馬鹿がDockerに関しての話題をここじゃなくて、
こっちでやれって言ったからこっちに書いてるよ。

興味があったらどうぞ

プログラムに詳しくなりたい
http://peace.2ch.net/test/read.cgi/tech/1346595505/

ドッカーポエムが繰り広げられていますね。

DockerでCentOS7使おう思ったら
systemctlが無いやら(7.0)、B-Busがなんやら（7.1）出てしまうので
先人の教えを請うて次の魔法の言葉を打ったらsystemctl使えたけど
docker run --rm -v /usr/local/bin:/target jpetazzo/nsenter
docker run -p 80:80 centos:centos7 /sbin/init
sudo nsenter -t $(sudo docker inspect --format '{{.State.Pid}}' centos) -m -u -i -n -p /bin/sh
なんですの？これ

どこが魔法なんだ？。/sbin/initか？。

>>179
たぶんnsenterがゲストのCentOS7でsystemctl使えるようにする魔法の言葉だと思うんだけど
なにしてるの、これ？
（ちなみに-p 80:80はいらなかったのかも知れないがとりあえず入れただけ）

普通に、CentOSを起動した時に動くデーモンを全部起動してるだけ。
必要なものだけに厳選するなら、supervisordとか他の手段を使ったほうが良いと思う。

これを会社のシステムに使おうとしてる俺の会社って狂ってるよね
社内にLinuxに精通した奴なんておらんし

>>181
ありがと、
とりあえず/sbin/initでコンテナ上げとけばsystemctlが使えるようになるから
あとはnsenterとかsupervisordやらでコンテナのshに入ればいいってことなのかな？

>>182
Dockerを使おうって会社っていうとNTTデータ？IBM？
大きな会社だね。

>>183
今のコンテナに入る方法はdocker execだよ。
nsenterとか使わない。

あとコンテナの中でsystemdも使わない。
そもそも使い方が間違っていて
コンテナは仮想マシンじゃない。

コンテナは原則として一つのアプリを動かすもの。
その一つのアプリを動かすのに必要なものを
固めたのがコンテナ。

動かすのは一つのアプリだけなのだからsystemdもいらない。

>>185
なるほどハイパーバイザーみたいに使うのは違うんか
VPS借りてさらにその上で仮想化したくて
KVMはQEMUしか動かなくて糞遅く、VBは32bitしか使えず、
Dockerもsystemd使えなくて駄目かと思っていたら使えてウハウハしてしまった

>>185
最初はdocker execでCentOS7コンテナの/bash/shに入ったらsystemctl使えなくて
ホストのUbuntu14.04自体に無いからかな？と14.10に上げてsystemctlあるなと思ったが駄目で
インターネッツ探したらnsenterでごにょごにょ書いていたからやってみたら出来たっていきさつです

何を動かしたいんだ？。
webserverか？。
開発環境？。

>>188
Clamdscanを動かしたよ、試験で

これってWindowsでいうApp-Vみたいなもん？

>>186
実際マシンの仮想化はしてないからね。
ハードウェアのエミュレートなどはしていない。
chrootの技術の延長

WindowsでDLL Hell とかいう言葉を知っていればわかりやすけど
アプリAとアプリBがあります。どちらもOSのDLL（ダイナミックライブラリ）を使います。
アプリAをバージョンアップするために、OSのDLLのバージョンアップも必要です。
OSのDLLのバージョンアップしたら互換性がなくて、アプリBが動かなくなりました。
というのがDLL Hellというやつで、Linuxでも同じことは起きる。

この対策としてアプリAのディレクトリにOSのDLLを含めました。
などとアプリAのディレクトリに、OSのDLLすべてをコピーしちゃう。

更にプロセス空間やネットワーク関連も独立させて、完全に隔離された状態で
アプリケーションを動かすっていうのがアプリケーションコンテナ。

あくまで一つのアプリを動かすために、そのアプリに必要なものを
すべてまとめてしまってるだけなので、ホストOS上で
（コンテナ化された）アプリを動かすという考え方をする。

同じコンテナ技術を使って仮想マシンのように使うOpenVZとかあるけど
あれとは考え方が違うので注意。

一つのコンテナの中で動かすターゲットは一つ（＋それを動かすために必要物）なので
わざわざsystemd使う必要もないってわけ。

>>190
これか。
http://www.atmarkit.co.jp/ait/articles/1006/24/news108_2.html

ざっと見た感じだとかなり似ているな。
なんだかんだでWindowsは既に実現してるんだなｗ

仮想マシンの使い方だと、マシンを新たに作って
OSのインストールを終わらす。そこまでが仮想マシンを作る段階で、
それから、よーしこれからアプリケーションをインストールするぞーって
考え方だと思うけど、

Dockerの場合、アプリケーションが使えるようにする所までが一連の作業になる。
Dockerfileに定義した内容に従って、すぐに使えるDockerイメージを作る。
そのイメージを共有することで、

あ、あのアプリ使いたいな。って思った時にyumやapt-getでインストールする代わりに、
イメージをpullしてきてそれを起動する。
（Dockerイメージを起動して作られるのがDockerコンテナ、実行ファイルと起動したプロセスのような関係）

Dockerコンテナの中にはアプリを動かすため必要なカーネル以外のすべてのものが
含まれているから、Dockerさえ動く環境があれば、すぐにアプリが使えるようになる。

ちなみに、CentOSとかUbuntuの違いというのは

* カーネル + CentOS独自のパッケージと設定
* カーネル + Ubuntu独自のパッケージと設定

であるため、Dockerコンテナにはカーネル以外のすべての部分が含まれているということは
ホストOSがCentOSであっても、Ubuntuベースで作られたコンテナが使えるということ。
カーネル部分は多少のバージョンの差があるにしろ同じものだからね。

>>186
＞VPS借りてさらにその上で仮想化したくて
＞KVMはQEMUしか動かなくて糞遅く、VBは32bitしか使えず、

そういう用途だとLXCそのまま使うのが良いかもよ
http://knowledge.sakura.ad.jp/tech/2108/

>>194
そうなの？結構前だけどLXC使おう思ったが面倒そうでOpenVZに逃げたんだがｗ
（その時はホストがCentOSだったから面倒だった気もするけど）
今やDockerでまとまってウハウハ

そうか？。CoreOSと喧嘩したり、色々きな臭い感じじゃん。

和解しとるやん。
情報遅いな。

CRIU使ってマイグレーション辺り、やってる人いる？

>>193
お前まだそんな事言ってるのか
Dockerは小さな単位の仮想環境だよ

>>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ってやってみて。