Docker

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

http://www.docker.io/

もうPCも使用禁止にしたほうがいいよね

>>694
ぜひトラブった原因をqiitaとかに書いてくれ。ここに書いても便所の落書きにしかならないからな

同意同意
昔はココに書いてる事も役に立ったけど
今は全く使える事が無いのが残念

人が消えてしまったこともあるが
検索にかからなくなったのが大きい

Dockerそのもので話し合うことがなくなった
figまではよかったが、オーケストレーションとかやってる奴いるのかよ？

もうみんな歳を取ったんだよ
新しい技術に追い付けなくなったんだよ

インフラ系の新技術は枯れてくるにつれて話のスケールがでかくなってきて
半分趣味で触ってるような連中はついていけなくなるのが常

つうか、未だに何がうれしいのか全く分からない。

作ってる人が楽しいのは分かるし、バズワードでドヤ顔したいだけの
半可通がうれしいのも分かるけど、実生活にどう影響するのかと。

原始人「電気の何が嬉しいのかわからない。」

電気はシステムが出来たから、>>707みたいなバカでも嬉しさは分かるだろ。

古いOS動かしてるマシン用のrpmとか作るときで、そのマシンには開発環境入れたくないみたいなときに結構役立ってるけどな

半分趣味でやるのに手軽で便利だなーって感じ
もちろんDockerfileを一から書いたりはしない

>>707
つマイクロサービス

>>712
それこそユーザーに全く関係ないだろ

正直立ち上げが速いこと以外魅力感じないな

Dockerでサービスを再発明するよりクラウドネイティブでいいじゃん
AWSロックイン? 何が問題なの?
というのが主流になりつつあるよね。
Docker使うようなサイクルの短いアプリなら尚更。

なんかみんな新しい言葉好きだよね

>>715
クラウドネイティブってAWSを使うことじゃないよｗ

「Dockerを使うことでクラウドネイティブにしやすくなる」
こういう使い方をする。

>>683
お前が一番腐ってるだろ

最近dockerを触り始めたけど、
os updateがあった場合普通どういう手順になるのがよくわからない。

docker fileにupdateを書いておいて、
イメージを生成しなおして、旧コンテナ破棄?

それともコンテナ中で手動(or cron)でupdateする?

>>719
ベースイメージを取得し直してリビルド
それが負担になるほどアプリの更新頻度が低く、かつ塩漬け運用もできないというならその用途はdockerには向いてないよ

>>720
ある程度自動で更新出来るようにしておけば楽だけどね。

確かに面白い技術だけど、これとWineを使ってMinGWの（えせ）ネイティブ環境を作るのって、出来るのかな？(´･ω･`)

ホストがWindowsの場合VMwareなどの仮想環境下のLinuxに比べてパフォーマンス的にはどうなんだろう？

ホストがWindowsの場合は存在しないです

>>724
https://msdn.microsoft.com/en-us/virtualization/windowscontainers/quick_start/quick_start_windows_server

>>725
>>724はホストがWimdowsでLinuxコンテナは無いって話だろ

Bash on Ubuntu on WindowsのLinuxカーネルエミュレーション機能が
完璧になれば、WindowsでLinuxカーネルを使うこと無く、Linuxコンテナを
動かすことができるようになるけどね。

最近Bash on Ubuntu on Windowsの開発活発だし。
BashからWindowsアプリ起動できるようになったって。

できたら教えてくれ…と言いつつ、開発はlinuxとmacばかりになったな…

mac糞化したけどちゃんと使えてるの？

職場でlinux禁止されてしまったので期待！なんだが、
Windows 7 pro以外だめっていわれてるんで意味ないんだよな。

>>730
7 pro限定ってのはきっついな

VPSで数十人が使うWebアプリを公開しようと思ってるんだけど、
実行環境を含めたバックアップ目的にmondorescueを検討していたら
外部DB+Dockerコンテナという選択肢もあることに気付いた次第
もちろん外部DBは定期的にバックアップ取ることにするけど
可搬性から見てどっちが良いですか？
あるいは、外部DB+Dockerでうまいことバックアップとる構成があれば教えて下さい

Dockerコンテナというのは単なる1プロセス。プログラム。
バックアップを取るべきはデータであってプログラムではない。
だからDockerコンテナはバックアップする必要はない。

バックアップを取るのは外部DB。
つまりは普通のバックアップ方法と何も変わらない。

>>732
スナップショット機能のあるVPSやIaaSを使えば?
1台で運用するならDockerなんか余計な手間が増えるだけだぞ

>>733,734
なるほど、どうもありがとう
スナップショット機能のあるVPSを見繕ってみます

っconoha

将来的なクラウド適用領域の拡大を考えるならEC2がいいのでは
業務系ならさすがにAWSはクソ便利だよ

開発現場で窓OSなんか、窓から捨てちゃえばおｋだってば。

Dockerが動かないのはお前の愛するMacも同じじゃん
お前が言っているのはWinもMacも投げ捨ててみんなデスクトップLinuxを使えということだが、自覚してるのか?

え？何言ってんだMacはDocker動くだろ

VM上でということなら Win も Mac も動くな。

Docker for Mac も Docker for Windows も所詮 VM上の Linux。
Docker Toolbox とは VM 周りの実装とパッケージングの違いでしかない。

一応は Windows は Windowsコンテナならネイティブで動かせるし、
Docker for Windows にもクライアント側の Linux[VM] <-> Windowsコンテナ の
切り替え機能がついたらしいが

無知を晒さなくていいから。

だから>>731なんだろ

>>739
無知は黙ってろって。

DockerコンテナっていうのはLinuxカーネルを共有するものなので
Macでネイティブに動くことはない（MacはLinuxカーネルではないから）

もしOSがLinuxカーネルを完全にエミュレートできれば、
Dockerコンテナも動くだろうけどね。
Bash on Ubuntu on Windowsは、WindowsでLinuxカーネルを
不完全ではあるがエミュレートしてるので、これがもし完璧になれば
WindowsでDockerコンテナが動く可能性はある。

wine-linuxとBashOnWindowsなら前者を選ぶのがここのたしなみと考えていたのだか…

Docker使う人はこの板では少数派のいわゆる普通のLinuxユーザー(つまりサーバー系)なので
手元の作業端末はだいたいWinかMacが基本だと思うよ

この手の技術は進化が早いからついて行けないのはしょうが無いな

http://www.boycottdocker.org/
ちょっと極端な意見もあるように思うけど、まあそういう人もいるかもね。

VM vs コンテナと言うが、台数ベースではVirtualBoxの上でDocker動かしてるのが最も多いというオチ。

普通にクラウド使うだけでだいたい解決しちゃうからなあ
Dockerを運用できるほどがっつりインフラ作り込んでて
さらにDockerのメリットが得られるほどバリバリ開発してるようなシステムって
そんなに沢山あるとは思えないな

>>751
何か勘違いしているなこいつ。

hyper-VはVirtualBOXと共存できないのがつらい

VMwareとVirtualBoxもだめだった。

> Dockerを運用できるほどがっつりインフラ作り込んでて
何が必要なんだ？ インフラを作り込まなくて済むのが
Dockerのメリットなんだが。

>>751
単にWebサーバーを稼働とかならdockerなくてもいいげど、役割持たせたコンテナを運用したいならdocker使うのがよさげ。

>>754
Macで共存してるけど、問題ないね。

マイクロサービスアーキテクチャ＋Dockerだ！

>>755
インフラに手間かけたくないなら出来合いのPaaSや普通にEC2のAMIとか使ったほうがよほど手軽だよ
Dockerだとどうしてもセルフサービスの部分が大きくなるし、
独自に作り込めばその分クラウドプラットフォームが提供する便利な機能も活用しづらくなる
良く言えばベンダーロックインを避けられるということでもあるけどね

>>759
お前分かってないだろｗ

AMI or Dockerじゃないんだよ。

AMI + Dockerというふうに組み合わせて使うんだよ。
っていうかDockerだけじゃ使えない。

クラウドプラットフォームが提供する便利な機能も
Dockerで使うんだよ。

>>760
だから、その二重管理のコストに見合ったリターンが得られるか? ということなんだけどな
お前はきっと次のレスで反発するだろうが、一度落ち着いてよく考えてみたらいい
お前、Dockerを使うために結構手間かけてるだろ?

> だから、その二重管理のコストに見合ったリターンが得られるか? ということなんだけどな
二重管理なんかしてないが？

お前AMIを使ったら、すぐにWordPressが動くとでも思ってるのか？

>>762
いや、まさかとは思うが、FROM wordpressでWordPressが使えるから簡単だとか
「インフラを作り込まなくて済む」ってそんなレベルの話をしてたのか?

>>763
インフラ部分を面倒見てくれるのがあるからdockerを使うんだけど。

PaaS ならそのとおりだと思うけどなんでAMIを入れた。
AMI なんてただの OSイメージでしかなくそれ以上でもそれ以下でもない。

AMI を扱うということはIPアドレス設計やモニタリング、ロギングなどは
自前にしないといけなくなるし。
そうすると GKE などの DaaS を使うほうが結局手軽になる。
もう一つの大きな DaaS である ECS はあまりやってくれないらしいけど。

PaaS なら Docker と比較して手軽というのはその通り。
まぁ、そうは言っても Heroku がベータとは言え Docker サポートしちゃったから
ロックインを避けるために少し手間を掛けても
アプリの動作環境の構築とデプロイは Docker にしちゃうのも手だけど。

>>757
Windowsではだめだった。　VMwareが作った仮想ネットワークデバイスをVIrtualBoxが乗っ取ってしまって
VMwareのゲストがネットワークに繋がらなくなった。

Docker for Macのosxfsでのファイルアクセスが死ぬほど遅いんだけどどういう解決方法がオススメ？

Docker for Macなんか投げ捨てて逆にLinux上のディレクトリをsshfsかなんかでMacにマウントしたら

>>766
あらら、可能ならVmware communityに書き込むと改善されるかも。

>>766
Windows 7上で
VMware Workstation Player 12とVirtualBox5.0.16で共存できてるぞ
ネットワーク接続の
「VirtualBox Host-Only Network」のプロパティで「VMware Bridge Protocol」
のチェックを外して共存できたぞ

>>770
Win7 上で Workstation 10と VirtualBox 4.3だった。　もう解決された古い問題かも。

コンテナ内のファイルを間違えて変更してコンテナが立ち上がらなくなってしまいました。
変更したファイルを元に戻したいのですが、コンテナが立ち上がらないので docker exec で入って
修正するということができません。
他になにか修正する方法はないでしょうか？

ドッカーン

>>772
盆栽じゃないんだから、再構築する材料はとっておこうよ。

他に方法がなければ作り直すしかありませんが、ファイル修正できるならそっちの方が早いので。
docker diffで変更されたファイルが確認できるんで変更をrevertする方法もあったらいいんですが。

一体どうやったらそんな状況になるんだ

ENTRYPOINTがコケるような変更を加えてdocker stop
で簡単に再現できるかと。

docker cp 使って変えたファイルを取り出して修正した後に
docker cp でコンテナに放り込んで start すればOK

ありがとうございます！助かりました。

10:00に問題を書き込んで13:30に解決、
かかった時間は3時間30分

> 他に方法がなければ作り直すしかありませんが、ファイル修正できるならそっちの方が早いので。

本当に早かったんですかねぇ（・∀・）ﾆﾔﾆﾔ

？
そりゃ、cpで済む方が早いでしょ？

書き忘れてたけど、StorageDriver に aufs や overlay(fs) を使ってるなら実ファイルは
/var/lib/docker 以下にあるので最悪はそこからでも触れる。
変えてしまったファイルのパスの確認もできる。
ただし、DeviceMapper の場合だと簡単ではない。
btrfs や zfs の場合は試したこと無いから知らない。

http://paste.ofcode.org/QqeZLmXfui3HBPqTUDmD6j

>>781
まともな使い方してればdocker buildで終わりだってことでしょ

死んだコンテナのイメージを差し替えて立ち上げることが可能ならそれでもいいんですが、
ボリュームを回収して新しいコンテナを立ち上げるしかないんじゃないですか？
まぁ、コンテナが立ち上がらなくなること自体がまともな使い方じゃないと言えばそうですが。

いや永続化が必要なデータは外部のDBに置くかVOLUME使おうよ
コンテナは常に使い捨てが基本だよ

そこは使い方様々ですからねぇ。
自分も壊して構わない前提でいろいろいじくりまわしていて、仮にデータがすべて
失われたとしても作り直せばいいだけなんですが、その手間が省けるならそれに
越したことはないと。
というかそもそも>>772も、その問題を解決したいというよりも書いている通りそのまま、
そのような方法があるかどうか知りたいから質問したわけですけどね。

作り直す手間ってなに？
どこに手間があるの？

自分でケツも拭けないクソが偉そうに能書きたれてるな。哀れ

>>786みたいな盆栽遊びが好きな人には、ビルドとかものすごい手間に感じるんじゃないの。

>>787
>>786のことであれば、ボリュームに入っているデータのことだけど？
ようはコンテナ立ち上げた後のアプリケーションの設定やなんか。

>>790
コンテナ立ち上げた時点でアプリケーションの設定なんか終わってるんだが？

当たり前のことを言うね。

コンテナにログインとかやるやつは
頭がおかしい。

overlayfsを使ってる方ってCentosなんですか？Fedoraですか？
無知な学生ですが、プロの皆様にお聞かせいただきたいです

>>91
かなり遠い所へのレスだけどまさにこれ。
「へえ、docker使ってみるか」
「マ゛マ゛〜、sshdどご〜」
ってなったわ。

sentosではaufsがマージされなくなったのか
いつの間に

お前らはどうやってDockerfile書いてるの？
手動で手順を確認しながらメモって後でDockerfileに清書？

複雑なときはそうするけど基本的にはトライ&エラーだな
前のステップをなるべく弄らないようにすればビルド時間はそれほど問題にならない
で一通りできたらリファクタリングして完成

同一ホスト配下でブリッジ接続の複数コンテナに対して標準のポートでhttp, httpsをつなぎたい場合、nginxだったりのリバースプロキシを用意するのが標準？
redmineやjenkinsだったりを使いたいと思ってるんだけど、Dockerの機能を使ってルーティング出来たりする？

>>796

tmux などで上下分割して、上で docker run --rm -it debian bash して、試行錯誤
下では vim などで Dockerfile 開いて記述

ホスト側で透過プロキシとして squid を動かしているので（dockerで)、やり直しになってもそれほど気にならない。

コマンドの細かい挙動などをチェックしたい場合が多いので今のところは上の方法でやっているけど、
一旦 Dockerfile へは1行ずつ記述して最後にきれいにするほうが速くて良い場合も多いと思う。
1.13 からは squash も追加されるようなのでそこまでしなくて良くなるかもしれないし。

>>798

docker にはその機能はない。

nginx でのリバースプロキシで良ければ nginx-proxy というコンテナを起動するのが良いと思う。
これは、docker api が提供するどのコンテナが起動しているかなどのメタ情報とテンプレートをもとに、
コンテナ生成/削除時の設定ファイルの修正や、プロセスの再起動をしてくれる「docker-gen」という
アプリケーションと nginx を組み合わせている。
これにより、コンテナが立ち上がったり、終了したりすると nginx.conf を修正してそのコンテナへ
プロキシする設定の追加/削除を行い nginx の reload をしてくれる。

機能を実現するために、docker.sock を他人が管理するコンテナに見せないといけないので
そのセキュリティ上の問題点は理解すること。

https://github.com/jwilder/nginx-proxy

自動でなくてよければ、自分で管理する nginx を立てるのでも良いと思う。