Docker

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

http://www.docker.io/

>>900
当たり前だろ！

当たり、前田の〜♪

Docker for WindowsでWindowsのディレクトリをボリュームとして使うと正常に動作しないっぽい
WindowsのファイルシステムだとLinuxコンテナに必要な機能がないからか
ファイルやディレクトリの所有者はそのままになるからか

大量にディスクIOが発生してGitLabの動作が重たいから
sameersbn/docker-gitlabだけWindowsのディレクトリを使ったら正常に動作しなくなった
素直にLinuxマシンを用意しろってことか

windows10でアップデート後問題なく動いていたのにふと再起動かけたらShared Drivesで共有ドライブ認証出来なくなって困った
Apply押すと詳細な共有の設定も初期化されるしどういうことだ・・・

Linux板で何言ってるんだか

windows10で使っちゃダメだよ

そもそも、そこまでして頑なにWindows使う人の気持ちがわからない…

Windowsコンテナも同時に使いたいとか？

(´・ω・｀)別にdocker入れなくてもいいんだけど、
dockerを入れて複雑化して誰も触れない環境にするために使ってるようなもんかな

>>908
Windowsしか使えない人なんだからしょうがない。

職場環境とかだと割とOS限定されるし
どうしてもwindowsで実現しなくちゃ行けない場合もあるのかな？

ただ罵るだけとかlinux板も落ちたよなぁとオモタ

落ちたも何もUNIX板から追い出された隔離所だし

「Windows使ってる」が「Windowsしか使えない」に短絡するバカっていまだにいるんだなぁ。

WSL その81 - WSLでどのようなテストが行われているのか
https://kledgeb.blogspot.jp/2017/04/wsl-81-wsl.html

WindowsによるLinux互換レイヤー実装、
もうLinuxと8割ぐらい互換性があるようだな

DockerがWindows上でネイティブに動くという夢も
近いうちに実現するかもしれない。
そうなるとDocker動かすのに仮想マシンHyperVも必要なくなる

WSLはbetaが取れるまでは様子見

windowsでないと使えない人たちが何しにここ来てんの？ｗ

Dockerコンテナに特化した「RancherOS」正式版リリース。Linuxカーネル上でDockerを実行、システムもユーザーもすべてをコンテナ空間に − Publickey
http://www.publickey1.jp/blog/17/dockerrancheroslinuxdocker.html

マイクロソフト、Windows Serverのコンテナ機能でLinuxコンテナのサポートを発表。主要なLinux OSとLinuxKitに対応。DockerCon 2017
http://www.publickey1.jp/blog/17/windows_serverlinuxlinux_oslinuxkitdockercon_2017.html

WSL のようなものではなくて結局 Hyper-V 経由だけど「Hyper-V コンテナ」の実装として出してきたね。
すでに、Hyper-V コンテナで実装されている Windows コンテナと同様であると考えると、
Hyper-V でラップしてその中で kernel とプロセスが動く。

ただ、これをまとめて操作できるインターフェースが用意されるのかな。
docker run すれば hyper-v コンテナ経由で Linux の環境とコンテナが上る感じで engine は windows 側？
そうすれば、Docker for Windows みたいな専用VMを意識しなくて良くなる（この Linux が moby になるのかな）。
これがちゃんと実装されれば、windows 上では windows コンテナと Linux コンテナ混在で同じ操作性で扱うことができそう。
Hyper-V コンテナなら Windows10Pro でも動くのでその点も良い。

気になるのは Network と共有ファイルシステム。

Network は Hyper-V の設定で面倒なところだけど、Overlay に関しては windows/linux 混在できるようにわざわざしてくれてるので
使いやすく実装してくれることを期待。
https://blogs.technet.microsoft.com/virtualization/2017/04/18/ws2016-overlay-network-driver/

共有ファイルシステムは Docker for Mac でも性能や権限がよく問題になっているので
これがいい感じになるようならば、Windows で開発してもいいかなという人も増えるのでは。

意味の無いことだとは思うのですが
ドッカーッてsystemdな環境をinitな環境と切り替えて使えたり出来るもんなのでしょうか？

dockerは仮想環境のディストリビューションは何になるの？もしかしてホストOSと同じ？

>>921
ディストリはホストと別でもよい
ホストUbuntuでコンテナCentOSとかでもOK

docker用に最適化されたCoreOSってのもあるからそれでもいいのよ

>>920
何考えてんだ？レベル

coreOSは普通のディストロとはかなり使い勝手が違うから慣れてないのに使うのはオススメしないな
それとcoreOSはdockerじゃなくてrktだろ

セキュア重点の特化OSで使い勝手同じのってあるの

どうせならdockerkitにしようぜ

>>919
そこまでして、ホストでWindowsを使う必要がない。
窓は、窓でええやんと。

windowsユーザーが気軽にdockerを使えるようになるってことだろ
わざわざwindowsを使いに行くという話ではない
Linuxユーザーにとってはコンテナが増えることで利益を得られるんじゃないの

dockerってカーネルが同じものを共有する≒システムコールが同じじゃないとならない
と思っていた
Win上で動くって結局のところvmwareと中身が同じでいいのかな？

一方でwin自体がcuiにbashを可能にする動きがあるから、母艦がwinでもlinuxと同じコマンドでdockerが操作できて会社で泣く泣くwinを使わせるクソ製造業の皆様もdockerの恩恵を享受できると

>>930
WindowsもMacもLinuxカーネルではないので、
Docker用の仮想マシンを作成して、そこにLinuxをインストールして
コンテナを動かしています。

そのため、仮想マシンの設定（CPU数や搭載メモリ等）の影響を受けます。

ネイティブにDockerコンテナを動かしたいのであれば
Linuxカーネルの機能をOSが搭載する必要があります。

それをやっているのがBash on Ubuntu on Windowsで有名な、
Windows Subsystem for Linux (WSL) プロジェクトなのです。

>>931
一番の問題はファイルシステムじゃない？
その辺の問題は解決するんか

ファイルシステムはfuseみたいな物を使えばどうにでもなるんじゃねーの

だな。WindowsはISOファイルや読み書き可能なvhdファイルを
ディスクとしてマウントする機能がすでにある。

それ以前にBash for Ubuntu for Windowsだって書き込み先は実際にはNTFSのはずなのに、
lxfsとしてマウントされ、Linuxを動かすのに必要な情報が記録されている。

あとは、Linuxで動くアプリが正しく動作する事ができるlxfsというファイルシステムに
Dockerというアプリがデータを書き込むだけの話

Docker使ったら素人でも分散処理するWebサーバー立てられる？

無理

dockerゴミという話
http://anond.hatelabo.jp/20170422000230

Dockerの運用なんかクラウドプラットフォームに丸投げするもんでしょ
PaaSのための共通パッケージフォーマット、それ以上でも以下でもない

docker使って、開発の手間を惜しんで、
代わりに運用コストを上げてしまった
って話に見えるな。

実際、docker利用してるプロジェクトに、
後から参加するとそんな状態になってることが
多い気がする

>>935
こういう質問が来るって事は、Dockerがなんなのか分かってないんだろうな。

じゃあ何を使えばいいの？

>>941
そりゃREADME.mdでしょｗ

Dockerfileなんて、README.mdに書いて有ることを
自動的に実行できるようにしただけなんだから。

README.mdみてWordpressをインストールして
設定をvi使って書き換えてMySQLのセットアップしてって
やればDocker使わなくても同じことができる

そんなん面倒くさい

じゃシェルスクリプトでよくね

仕組みを理解して、readmeに書いてあることくらい読んで、
そんでdocker使うなり使わないなりすればいいのさ。
理解せずにdockerでやる！とか、拾ってきたイメージで
ガチガチャやって、動かないとか言いながら散々いじって、
車輪の再発明みたいなことして、他の人に理解できないような
ゴミを作って、動きました！とかやるから質が悪い

まあdockerに限らずなんでもそんな感じだけどね

>>937
たぶん、chrootとかlxcとかちゃんとやったことがないんだろうな。
おれだったら、systemd-nspawnのほうがイヤだｗ
（脱線：ちなみに、Docker、VMwareは好きだけど、vagrantも嫌いだし、JS系だったら、gruntも嫌いだ。grunt使うぐらいだったら、Rakefileでかまへん。）

Dockerなんか、chrootでtar、シェルスクリプトと同じだと言われればそうだけど、なんとなくDockerやろうぜとかだったら、結局めんどいってなるんだろうなーと。

意味のあるコンテナを作れていないだけな気がする。
なんとなくコンテナを拾ってガチャガチャだったら、あかんで。

VagrantもLinuxだとVMじゃなくてDockerコンテナが作れるらしいけど
なんかyml書くのが難しそう
Dockerfileの方が簡単に書ける

docker大好きっ子の俺だけど、
dockerfileだけは氏ねよと思うわ

>>946
RakefileはRubyな

本番運用してない部門だから、dockerfileは書かず公式に外から設定ファイルを突っ込む形だわ
本番の人たちはわざわざイメージ作ってるのかな？めんどくさそう

>>950
本番運用のシステムを作るとめんどくさいよ。
だからDockerをつかって、本番運用のシステムを
簡単に作れるようにするわけ

('・c_・` )ｿｯｶｰ

コンコンするのはノッカー

　質問なんですが、「立ち上げ直後に落ちてしまうコンテナから、原因となるファイルを削除する」手段は無いでしょうか？

事例：
　mongoのオフィシャルイメージから立ち上げたコンテナが、原因不明で立ち上げ後即落ちるようになった。
　特定のファイル( /tmp/mongodb-27017.sock )を削除すれば良い、という情報を得たので削除を行いたいが、
　普通に起動しても即座に落ちる(エントリポイントでmongodの立ち上げに失敗してシャットダウンしてる)ので、docker exec出来ない。

　最悪、コンテナ消してイメージから再作成すれば良いのですが、本来的にはどのように対処すべきでしょうか？

>>954
コンテナ消してイメージから再作成する
コンテナ自体にデータ持つ運用なんかありえないので問答無用で消してok

>>954
「イメージから立ち上げたコンテナが…即落ち」
「コンテナ消してイメージから再作成」

なんか日本語が間違えてるのか、
運用方法が決定的におかしいのか。

普段どうやってコンテナ作ったり、立ち上げたりしてんだ？

>>954
>　質問なんですが、「立ち上げ直後に落ちてしまうコンテナから、原因となるファイルを削除する」手段は無いでしょうか？

そのコンテナは破棄して、新たにDockerfileから作り直すだけ
簡単なこと

>>954
つまり使い方を間違えて覚えているから最初から学習し直せってこと

>>954
以前も書いたけど docker cp 使えば？

VSCode+TypeScript+Node.jsのサーバーサイド開発環境作りたいんだけどどうするのかよく分からない
ビルド用のNode.jsとTypeScriptはDockerだけじゃなくてホストPCにも入れるのが普通なの？

どういうことやVScodeを鯖側で動かしてVNCでもするんか？

>>960
volume

>>960
何をしたいのか書かないと誰もこたえられない。

VScodeで書いたコードをCOPYかVOLUMEで渡せばいいだろ
ローカルで動くの確認してからdocker内に渡す方が楽だろうけど
もしくはdocker内とVScodeをつなげて直接触るか

dataボリューム作って複数コンテナからマウントした場合も
どこかのコンテナでflock()すれば他でもちゃんとアドバイザリロックできてるのか

agettyとかいうプロセスにcpu食われまくるのってバグ？

DockerホストOSとしてもAlpine使えるのかな
余ってるNUC使ってホストもコンテナもalpineベース

余ってるならやってみればいいのに

おっしゃる通り書いてから自分でもそう思ってやってみました
普通にできました

>>965

data ボリュームは Docker for Mac/Windows のような shared volume などを対象としない限りは
単なる bind mount でしか無いので flock などのファイル操作は可能です。

>>966
docker 経由で /bin/init を起動してるのだと思うけど docker コンテナ内で一部の権限が無い為に
agetty が無限ループをしてるようです
--privileged を使うと大丈夫みたいですね。--cap-add SYS_ADMIN だけでも大丈夫かもしれません。
getty が恐らく原因ですので（systemd の場合ですが）
systemctl stop [email protected]; systemctl mask [email protected] （または disable）
してしまえばどうでしょうか

Debian Jessie では昨年9月の修正で docker 向けには起動しないようになってます。
https://packages.qa.debian.org/s/systemd/news/20160903T181714Z.html
> Don't start console-getty.service when /dev/console is missing.
> Avoids repeated unsuccessful start attempts of agetty inside (docker)
> containers. (Closes: #829537)
対象のバグ報告 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829537

こちらを見る限りは、docker コンテナ内に /dev/console が無いために発生しているようですね。

余計なお世話だと思いますが、systemd など init を利用する場合は docker より
lxc や systemd-nspawn を使うほうが幸せになれると思います。

>>971
まさか2chでこんなに丁寧なレスをもらえると思いませんでした
ありがとうございます

>docker コンテナ内で一部の権限が無い為に
agetty が無限ループをしてるようです

なるほど、そういうことか
ご指摘の通りgettyが問題だったのでこれを止めることで解決しました
色々情報を共有して下さりたいへんありがたいです

BargeOSっていうのはまだ物理マシンへのインスコには対応してないのかな

acbuild便利だな
でもこれ使うならdockerじゃなくてもいいな

debianは公式slim版やminidebみたいなコンテナ専用カスタマイズがあるけど
他ディストリにもそういうのあるのかな

ubuntu slimとgentoobbしか知らんな
gentoobbならalpineより小さく作れるよ

ググったらgentoobbがkublerとかいう名前に変わってたわ

最低限環境で動くバイナリやスクリプトなら定番、alpine(or alpine-glibc)
debianリポジトリにある成果物を使いたいならinstall_packagesで自動後始末、minideb(or 公式slim)
自分でビルドオプションを指定したいならportage利用して依存性も解決、gentoo-bb(kulber?)
軽量系だと現状こんな感じか

ArchやRedHat系にもコンテナ向けビルドがあるのかな

kubler知らなかったわ
17MBでnginx動かせるのは凄いな

Ubuntuが良いならblitznote/debootstrap-amd64っていうのもある
サイズはminidebと同じ50MB前後でinstall_packagesのような支援コマンドは無し

姉妹品のblitznote/baseimageはapt-getすら省いて26MB
COPYやRUN curlとかで間に合うなら、alpine{,-glibc}で動かないときなんかの避難先になるかも

Debian系は公式から野良まで選択肢に恵まれてるね

CentOSなら cgwalters/centosmin(74MB) を使ったことある
Fedora版 cgwalters/fedoramin(86MB) もあった

どっちもDL数少ないからあまり使われてないっぽいけどね・・・

(´・ω・｀)古いfire タブ2015の使い道がない

(´・ω・｀)

>>978-
Gentooだったら野良スリム版（と思われる） fr13nds/gentoo-amd64 が約190mbですね
公式は870mbだったから結構なシェイプアップだけれどさすがに gentoobb のビルドとはぜんぜん比べ物にならないほど大きい！

kublerの最低構成は3MBくらいかな？

>>980の`baseimage`の方ってapt-get外した結果perl(python?)依存も解消して
その合計で20mb以上減量できたのかな

でもapt完全排除はデプロイが面倒杉になってヤバそう
やっぱり軽量化の壁はパッケージ管理ツールがスクリプト言語依存なことが足かせに

perlやpythonはLinux Standard Baseに含まれてたりして依存は仕方ないとも言える
だが確かに今後はコンテナで使う機能に絞った小型スタンドアロン版apt/yum等の登場も期待したいなぁ

今になってわかるね。
1バイナリに全てリンクして
配布する方法のメリット

コンテナをrun restart=alwaysとかで実行しておくと
supervisordとかdaemontoolsの代わりになるのかな
システムがシンプルになっていいね

次スレ
http://mao.2ch.net/test/read.cgi/linux/1506574845/

PackerでDockerイメージをビルドするって
Packerでやると何かいい事あるの？

>>991
それな。俺もそういったたぐいのやついらねーと思ってるよ。
シェルスクリプトで十分
普段シェルで環境作ってるのに
なんでわざわざ別のツールを使わなければいけないのか
さっぱりわからない

packer push してーの terraform とか ottoとかの自動化できたはず

使わないなら無用

Ubuntuでドッカーイメージを作って、
それをCentOSへ移動させコンテナを作ることってできますか？

寧ろなぜ出来ないと？

超好意的解釈をすると
armイメージをx86上で作れますかという質問かもしれない。

例えばUbuntuで作ったら、UbuntuやイメージビルドしたCPUなどに最適化されて、
他には持って行けないのかな？って思ってしまいました。

ありがとうございました。

>>997
ある程度カーネルが近いバージョンのもの同士でないと
コアダンプしたり落ちたりと、問題がおこることがあるよ

次スレです
http://mao.2ch.net/test/read.cgi/linux/1506574845/

終わり

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 1553日 0時間 27分 6秒