Docker

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

http://www.docker.io/

やめて！>>643のライフはもうゼロよ！

>>672
やっぱりメリットなんてないのかよ

酸っぱい葡萄程度の教養もない人間を抱えてる腐った大企業にはメリットないから使わないほうがいいよ
ITの巨人がこぞってDockerと提携出資してるし俺も価値を知ってるから使うけどお前には関係ないよ
大手と仕事したことのある大手じゃないお前の企業に帰りなさい
外に出ても恥をかくだけでつらいでしょう

だまって導入しちゃったけどな。。

恐竜に体温調節機能は要らない
メリットがないと言うのはそういうこと
開発が楽になるなんて技術者使い捨ての会社には不要だからさ

SI系ならバッチ処理の運用に使うのはアリだね
塩漬けにできるってのはドカタITには非常に受けるし、開発や運用やインフラの体制をほとんど変えずに導入できる

結局「メリット」は誰もわからないわけか
ここもレベル低いな

そんなの使い方によるし

>>670
お抱え業者じゃなくて、ちゃんとDockerの導入実績のある業者に打診しなきゃダメなのは当然では？
大手のお抱えは、大手と同様安定重視でリスクとらなさそうだもん

技術を理解しようともせずに下請けにDocker流行ってるから使ってみてくんない？コスト下がるかもしれないし、とか丸投げしてくる大手の発注元とつきあってくためには、
うちはそういうの出来ませんからって言って新しいことに挑戦しないで旧態依然の方法で今までと高い金取ってた方が楽だと思うもん

確かに、>>661で言ったとおりに日本のシステム産業って糞なんだろな。上流が腐ってるから下流も腐るしか無い

>>682
まさにそれ
腐ってるんだけど、唯一腐ってない俺がDockerでやるって上を説得さえすれば軍隊のごとくそっちに向かうのも事実。
サラリーマンとしてはいろいろ根回しうまい方で説得する自信はある。しかしDockerとかディープラーニングをうちの下請け（グループ会社なんだけど）がちゃんとやってくれるか不安なんだよね。

>>678
開発岳じゃなくて、運用が楽になるんだけど

>>683
似てるけど両方とも下には出してない
というか、DLなんて下請けに回したところで何もできんよ。スクレイピングが関の山

>>682
下請け側としては、コストが下がったとしても黙ってるよなｗ
従来と同じ金をもらってればいいんだし。>>670はアホなんだろうな。

下請けにおんぶに抱っこしかできない元請け様が恥をかいただけでしたね
SIerとは思えない。製造業の窓際システム部門かな？

>>686
普通はそうだよね
効率化して原価下がったとしても、高く売れる限りは高く売る

とはいっても、競合に低コストで売り込まれて切り替えられる可能性がある分野だとそんなことはないだろうけど

新たな手法を用いて効率化できるかもしれないけど、テストケースを膨大にこなさないと本当に安全かどうか分かんない、みたいな場合なら、
黙っては効率化しないよな。リスク回避を考えると。

本当に新手法を取り入れてコストカットしていきたいなら、ちゃんと下請けと元請けが協力して共通のゴールを目指せるような体制を作って、
上手く行く行かないにかかわらず検証費用を支払っていくような仕組みにしないとうまくいかないと思うんだけどな

受託業者の開発にDocker順次適用なんて無理だと思うけどまあやってみればｗ

ここは中小企業の低レベル技術者達の吹き溜まりみたいな所だからこんな質問お門違いだろ
フェイスブックとかで質問してみれば？知らんけどw

Docker使うメリットはミドルウェアのバージョン固定のため
じゃダメなのか？

イントラ限定のアプリやバッチならそうだけど、そういうところにDocker使ってるのは少数派じゃないの?
ベアメタルだろうがDockerだろうがセキュリティパッチ当てなきゃいけないのは変わらないんだから、
パブリックなサイトでセキュリティのためだけの更新が多いなら、いちいちイメージ更新しなきゃいけない分手間は余計に増えるよ

普通のLinux>セキュリティアップデートは自動
Docker内のLinux>固定されているので手動でセキュリティアップデートする必要がある。

(´・ω・｀)トラブって責任追及された
やっぱ安易に導入したらダメだわｗ

導入しなくてもトラブったら
責任追及されるんだが？

責任取れるほどの地位ないから平気だな。。

>>694
責任追及された結果、どうなった？

俺が責任追及する立場なら、今後一切のDocker使用を禁じる通達を本人から全社員に出させるかな
技術者には謝罪以上に最も屈辱的なことだろう

>>698
そういう通達出す人って無能な上司感半端なくね？
学校でハサミを使ったトラブルがあったらハサミを使用禁止にした教師思い出すわ

もう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 で入って
修正するということができません。
他になにか修正する方法はないでしょうか？

ドッカーン