LXCを使った軽量仮想環境。
これからの動向が気になるところ。
情報共有しましょう。
前スレ
Docker
http://mao.2ch.net/test/read.cgi/linux/1374861492/
前スレからそのまま持ってきてしまったか
本番系のマシンと、Docker動かしてるホストとで、カーネルのバージョンって
みなさんどこまで合わせてます?
うちはRHELで動いてる本番系と、それとコピーの総合試験環境があって、
そいつらはカーネルもパッケージもバージョン揃えてあるんだけど、
その手前の、コーディングとか単体試験とかをやるコンテナ動かすDockerのホストも
やっぱしカーネルのバージョン揃えるべき?
>>6
うちは本番系から単体試験ホストまですべてカーネル揃えることにしてるよ
Docket導入前だったけど、errataレベルの違いでI/Oスケジューラだったかの挙動が変わったことがあってね
理想はどうあれ、揃えておきなよ
本番系と、カーネルだけ揃えておけばいつでもコンテナ作れるっていうのが仮想マシンに対するDockerの大きな利点
カーネルをバージョンアップしてコンテナが壊れたんならさっさと作り直す、さっさと作り直せるように周辺の仕組みを整える、
消されて困るコンテナは作らない、他とカーネルを揃えられないコンテナも作らない、なんてことがDockerカンファレンスでも
強く言われてた
Bash on UbuntuにDockerも使えてWindowsPC強制されて虐げられてもなんとかなるぜ
Windows以外で使えるHyper-Vなんてあるの？
アホって綺麗なサンプルいっぱいあるのになぜか設定ファイルグチャグチャ作るのな
結局構成管理出来ないだろ、あんなんじゃ
色々入れたり設定が必要だし。
お勧めなディストリはやはりubuntuやfedoraなどですか？
>>21
docker自体は日進月歩すぎるところがあるので、OSは枯れたモノを使うというのがベストプラクティス
fedoraでdocker運用するのって、fedoraのカーネル自体が不安定すぎて、コンテナ上げすぎると落ちたりするよ
自前でリポジトリをシコシコ築いてきたディストリベンダーも
もはややる意義を失っちゃったりするんですかね？
>>41
コンテナ使い出すと便利すぎてディストリあれこれこだわってたのが笑えてくるほどだね
そして指摘の通り、独自にバグ潰しとかやってる一番活発なリポジトリ持ってるところと
逆に古いツールを保守し続けてるところはもてはやされてるが、それ以外が意気消沈してる
二極化だな
Linuxに来るのが遅かっただけで
どこもそう説明してるんだけど、ベースイメージにlinuxつかってその上にmysqlとか載せてイメージ化してるって認識だったんだが。
おい、素人同士で勝手に話をすすめるなｗ
>>55
> カーネルの上で動かすカーネルとかもうそれVMじゃん
VM=仮想マシン＝マシン（ハードウェア）を仮想化してないならVMにはならない
>>54
> dockerコンテナってホストOSのカーネル使ってるの？
そもそもホストとかゲストとかいうものがない
Linuxっていうのはカーネル（https://www.kernel.org/ で配布しているやつ）に
DebianやらUbuntuやらRedhatなんかが、いろんなアプリをセットにして配布してる
カーネルは基本的に汎用。だから同じカーネルを使っても
DebianやCentOSなんていう別のディストリが作れる
さてパソコンにDebianをインストールしたとする。そこにはカーネルといろんなアプリが有るわけだが
Dockerで作ったDockerコンテナはこのうちカーネルだけを利用する。
例えばFROM debian:jessieであれば、debian:jessieのディスクイメージを使うと考える
そのディスクイメージにはもしかしたらカーネルのバイナリも含まれてるかもしれないがそれは使わない。
パソコンにインストールしてあるカーネル + FROMの元になったディスクイメージ を使ってアプリを動かす
そんなもんだから、Debianをインストールしていたとしても、UbuntuやCentOSのディスクイメージを使うこともできる
>>55
ありがと。
そうなるとwindowsだとdockerインストール出来るけど、エンジンとかに工夫してあるのか
ttps://www.slideshare.net/zembutsu/docker-images-containers-and-lifecycle
ここの19ページめに、ベースイメージにイメージ層を載っけていくて記載あるけど、
これは間違ってるの？
>>57
https://github.com/docker-library/mysql/blob/6c414e7f38c2079c7193beae5dc7c34ee46cd6e7/8.0/Dockerfile
mysqlのdockerfileだと FROM debian:jessie ってあるけど、
これはどうなの？？
何かこんがらがってきた。
sshで入れるし、やっぱ根底はlinux立ち上がってるのか？
パソコンにインストールしたカーネルを使う。
そこで疑問になるかもしれない。
幾つものDockerコンテナが同じカーネルを使っているとしたら
psコマンドでプロセス見た時、他のコンテナのプロセスまで見えてしまわないのか？と
そこで出てくるのがLinuxカーネルに搭載されたコンテナ機能
この機能によって各コンテナは別々に隔離されることになる
同じカーネルを使っているというのに、それぞれ別々の環境を持っているようにみえる
ファイルシステム空間を分離したり、プロセス空間を分離したり、
メモリ空間を分離したり、ネットワーク空間を分離したり
ありとあらゆるものを分離して独立した環境を作り出している
それが大変な作業だった
さて、ここまではパソコンにインストールされたものがLinuxの場合だけど
WindowsやMacOSはどうなっているのか？
コンテナ機能っていうのはLinuxカーネルが持っている機能だが
WindowsやMacOSはLinuxではない。
どうやってLinuxのカーネルの機能を使っているのか？
答えを言ってしまえばあたり前のことだが、WindowsやMacOSでは
裏で仮想マシンが起動していてLinuxがインストールされている
ちょっと前までの、Docker Toolboxと呼ばれていた時代はVirtualBoxを使っていた。
今のDocker for Windows および Docker for Macでは
WindowsではWindows標準のHyperVを
MacOSではMacOS標準のHypervisor Frameworkを利用したHyperKitを使っている
仮想マシンを使っていると言ってもDockerに最適化されており
Windows もしくは MacOS のCUIからdockerコマンドを動かすとちゃんと
使えるように構成されており、まるでLinuxと同じようにOSの上に直接dockerが
起動しているようにみえる。だけど実際は仮想マシン上で動いているので
Dockerの設定画面にはメモリをどれだけ仮想マシンに割り当てるかなどという設定が存在する
余談だがWindows 10ではWSLという仕組みによって
LinuxカーネルをNTカーネルでエミュレートしている
今ではLinuxカーネルを使っていないのにUbuntuが
Windows上で動作するようになっている。
もしこのWSLがコンテナ機能までエミュレートする完璧なものになったら
その時はWindowsでHyperVを使わずにDockerが動くようになるだろう
親切すぎて草
下手な記事よりわかりやすい
>>62
帰ってきたらすごい丁寧なレス来てたっ
ありがとうございます
> 例えばFROM debian:jessieであれば、debian:jessieのディスクイメージを使うと考える
> そのディスクイメージにはもしかしたらカーネルのバイナリも含まれてるかもしれないがそれは使わない。
ttps://github.com/aws/amazon-linux-docker-images/blob/10641478ad16c6f44b691dc41acfc221c7a7594f/Dockerfile
たしかにamazon linuxの中見ると、コマンドとかは設置してるけど/boot のカーネルとかは置いてなかったわ
windows, macも結局裏では仮想化されてたのね
色々わからなかった所が一遍にわかったわ！
WindowsやMacOSで使った時のDockerのボリュームって謎だよね
例えばWindowsでdockerコマンド使った時、Windowsのディレクトリを
ボリュームとして指定すれば、dockerコンテナの中から見える
Linuxでは当たり前の動作だけど、WindowsやMacOSでは仮想マシンで
dockerが動いてるのだから、単純に考えれば仮想マシンの中にボリュームができるはず
まあホストOSのディレクトリを仮想マシンのディレクトリにマッピングしてるんだろうけど
Docker for WindowsやDocker for Macではそういうことを感じさせない作りになってる
Dockerっていうのはクライアント・サーバー型の設計になってる
つまり通常端末から実行しているdockerコマンドとサービスとして実行する
dockerサーバーが存在する(紛らわしいことにどちらもdockerコマンド)
サーバーの方のdockerは説明したとおりWindowsやMacOSでは仮想マシンなしには動かない
だけどクライアントはWindowsやMacOSでも動く
(dockerはgoで作られておりマルチプラットフォームになってる)
クライアントーサーバー型ということは、ようするにdockerサーバーを
リモートのLinuxで動かしていて、手元のWindowsでdockerコマンドを叩いて
接続するということができる。ちなみにdocker buildを実行すると手元のDockerfileやDockerfileと
同じディレクトリにあるファイルを全てリモートに送信してDockerイメージをビルドしている
(なので手元にごみファイルがあると遅くなるよ = dockerignoreの話につながるが省略)
使い方の一つとしてあちこちのLinuxサーバーでDockerサービスが動いていて
手元から接続先を切り替えて操作するというものがある
この時に使うのがdocker-machineで環境変数DOCKER_HOSTなどを管理する機能がある
Linuxでローカルのdockerサーバーに接続するときはsocket経由で接続するんだが
Docker Toolboxの時代ではTCPで接続するためにWindowsやMacOSXではdocker-machineが必要だった
でも最新のDocker for WindowsやDocker for Macではdocker-machineが必要なくなっている
どういう仕組みになってるんだろうね？ｗ
少し前の手順を見るとdocker-machineがでてくると思うがローカルのDockerに接続するだけなら忘れていい
今はWindowsでもMacOSでも、ローカルのDockerに接続するときはTCP通信を使っていない(はず)だけど
WSL(Linux用Dockerサーバーは動かない)環境から、dockerクライアントのLinux用バイナリを使って
HyperV上で動いているDockerサーバーに接続するときは、TCPでつなぐ必要がある。その時に必要になるのが
「Expose daemon on tcp://localhost:2375 without TLS」というやつ。詳しくはぐぐってくれ
もう一つ思い出したが、Docker for WindowsはHyperVで動いているのでVirtualbBoxとは同居できない
vagrantを使うのならVagrant+VirtualBoxではなくVagrant+HyperVで使う必要がある
>>73
勉強になります
最近はOS、仮想化、dockerと色々と入り乱れて全体像を理解するのに苦労するなぁ
ま、所詮パンピーですから
dockerとkubernetesの間にクラウド（aws、gcp等）があるね
クラウドを使わなければkubernetesはでてこないだろう
ローカルでのサービス開発用途であればdocker-composeで十分だし
kubernetesはなんかクラウドの上でクラウドを作ってる感じで、
将来的には、いろんなクラウド会社の共通インターフェースに
なるんじゃないかって思ってるけど、今は各社のクラウドのサービスに
kubernetesが対応しきれない感じ。だって自社のGCPすら完璧にコントロールできないもの
例えばオートスケールしたいならkubernetesを使わないで直接クラウドの
機能のオートスケールとかした方がいいんじゃないかな
なぜならkubernetesの場合コンテナのオートスケールになるわけだけど
起動しているVMの中でコンテナをオートスケールするだけなので
VMの数もオートスケールしないとコストは下げられないから
kubernetesを使っても頑張ればコストを下げられるオートスケールは
実現できるんだろうけど、コンテナとVMの二重のオートスケールが実行されて
少数のコンテナだと多分不安定になりそう。何十台レベルで常時コンテナが
起動してる状態じゃないと安定させられないんじゃないかな？
それが将来はコンテナのオートスケール = VMのオートスケールになるんじゃないかって思ってる
で最終的にはVMを使う＝裏で勝手にkubernetesが動いてる時代になるんじゃないかな
そうなってくるとkubernetesは確かに必須。だけど意識しない状態になってると思う
でも個人的にはkubernetesの方向じゃなくて、クラウド自体がコンテナに
直接対応してくれる方を望んでるけどｗ（例えばGCEは起動するコンテナをデプロイできるようになった）
kubernetesはバージョンが勝手にアップグレードする（GCPの場合）ことを考慮しないといけないのと
kubernetesを動かすだけで各VMで1.5GB以上のメモリを使用するのが気に入らない
コンテナをビルドするとき Dockerfile 内で
RUN yum list
した結果を、ホスト側に残したいんだけど、なんか良い方法ないかな？
>>95
Debian 使いだから勘違いしてる可能性が高いけどこういう感じで tee とかリダイレクトじゃダメなの？
$ cat Dockerfile
FROM centos
RUN yum list installed | tee yum.list
$ docker build -t yumlist .
~~snip~~
$ docker run –rm yumlist head -n5 /yum.list
Loaded plugins: fastestmirror, ovl
Installed Packages
acl.x86_64 2.2.51-12.el7 @CentOS
audit-libs.x86_64 2.7.6-3.el7 @CentOS
basesystem.noarch 10.0-7.el7.centos @CentOS
便利なやり方が無いかなーと思って。
一度起動してその出力を回収する方法しかないね。
/var/lib/docker/tmp
/var/lib/docker/containers
→単純にtmpfsにできる
/var/lib/docker/overlay2
→ここをtmpfsにすると再起動で空になったとき整合性エラーでコンテナが起動できなくなる
→かと言ってtmpfsをupperとしてoverlayfs化しても別エラーが出る（恐らくlower側のハードリンクが作れなくなるため）
/var/lib/docker全体をtmpfsにすれば整合性もハードリンク問題も解決するけど
消費メモリが増えるのとanything-sync-daemonとかでバックアップの手間も増える
システム再起動後にコンテナ自動起動しないならsync不要だけどイメージダウンロードからやり直しになって鬱陶しかった
>>98
その問題は /var/lib/docker 以下が ext4 なら、fstab でマウントオプションに commit=300 とか付けると結構な対策になる
短命コンテナをバンバン使い捨てるケースで …/docker/overlay2 にゴチャゴチャ置かれても
sync 前にすぐ消えたファイルやディレクトリは単に無視されてディスクには書き戻されなくなって安心
デフォの 5 秒だとちょっと早すぎるんだよな
欠点はもちろん不意の電源ダウンで指定秒数ぶんだけデータロストする可能性があることだけど
ノートだったり UPS あったり、吹っ飛んでもいいや的な状況なら sync-daemon 系も不要だから楽
俺は USB メモリだけで運用してると 1 年ちょっとで寿命が来て色々と試行錯誤の後
Arch のフォーラムかどっかに書いてあったこのシンプルな方法に落ち着いた
物理で構築してたPlaybookのTarget SectionにDocker使うよって一行追加すれば使えるし(厳密には使えるようにするまでに色々設定は必要だけど)、
仮にコンテナのデファクトみたいなものがDockerじゃなくなっても最悪SSHで接続さえ出来れば流用できるからこのやり方良いなと思ってるんどけど。
>>101
使っていませんｗ
ansibleを使ってDockerイメージを作ると、Dockerのキャッシュが
効かなくてイメージ作るの遅くなるでしょ？その問題もう解決したの？
あとansible使うならイメージにpythonインストールされてないとダメなんだよね？
Dockerはalpineとかpythonすら入ってないイメージをベースとすることも有るからなねぇ
君にとっては役にたたない話かもしれないど、どうしてansible使おうと思ったのか？
質問していい？ >>101にも書いてあるけど他のコンテナに乗り換えたいときのためだけ？
俺は流用するならばシェルスクリプトが一番だと思ってるよ。
だってansibleで書いたYAMLって、ansible以外に流用できないでしょ？YAML書くのめちゃくちゃ手間だし
Dockerfileはシェルスクリプトにかなり近いので流用したいならDockerfileのままでいい
Dockerのイメージを作る時に限らず、なんでansibleなんか使うのか俺には理解できないよ
すごい煽られててビックリしましたｗ
>>104
用途は
1. 公式OSイメージからコンテナを作る
2. 良い感じのコンテナになってたらイメージ化する
という感じです。
「2.」のイメージ作るとこは最終段階で、そう頻繁に行う作業ではないの
仮にイメージ一つ作るのに数十分かかったとしても、自分の用途に関してはそれほど問題はないです。
Ansibleを使おうと思ったのは、昔は動いてたけど今は動くなくなっているようなPlaybookでも
失敗した箇所がピンポイントでわかるのでメンテする気が起きるからです。
人のシェルスクリプト読んだり、昔の自分のイキリシェルスクリプトを読解するのに疲れた
というのが大きいですね。
コンテナのイメージ化という事も検証の一環として行いますが、メインの用途は
コンテナでPlaybookを高速で検証して、検証した構築用Playbookを本番のVMに放つという感じです。
(本番に放つ前に一度は検証用VMにも放って確認はします)
昔はVM作り直したり、スナップショットから復元したりしてたけど、今はそのマウス操作すら煩わしくなってしまってる。
>>103
> クリーンな状態からのAnsibleの実行検証がコマンドレベルでできて便利。
君を煽るわけじゃなく、そういうのをやってる人見てると、ワロスワロスだよｗ
なに無駄に苦労しちゃってるの？って思う
Ansibleは実行検証が必要なほど信頼できないってことだからね
Ansibleは理想としては、クリーンな状態にしなくても、冪等性とやらで
書いてあるとおりになるはずなんだが、その理想は破綻してる。
書いてない部分がどうなるのかは不定だからplaybookを変更した時に
クリーンな状態からやったのと同じ状態になるとは限らない
いやもちろんシェルスクリプトも同じだよ。でも検証時にサーバーに乗り込んで
手動でやったものがそのままコマンドにできる
playbookとして書いたものが、手動でやったことと同様のことを
行ってくれるか？という “二重の検証” は必要なくなるのさ
>>105
私も冪等性なんてあてにするものではないと思ってて、
Ansibleに限らず、そのほかのツールも検証してないものは信頼しないというのが私の基本スタンスです。
(特に、かなり昔に作った構築系スクリプトはそのまま実行して一回で動くとは思ってません。)
シェルスクリプトは構築コマンドそのまま列挙すればよいので便利なのですが、
例えばCentOSのOS基本設定入れてRuby入れてApache入れてアプリ入れて、
みたいな構築の場合、Role単位で過程を完全に分離できるので、管理がすごく楽なんです。
例えば構築が失敗したとき、シェルスクリプト場合
何でコケたのか、どこでコケたのか、というのを探すところから始める必要がありますが
Ansibleだとコケた場所とコケた原因のコマンドが一目瞭然なのでとてもメンテしやすいのです。
あちこちで煽ってるけどようやくまともな意見を返す人が見つかったな
ふぉーん。ってことはシェルスクリプトでもどこで失敗したか
ピンポイントでわかれば問題ないってことじゃねーか。
あとは書き方が統一されていればいい
それなら解決可能な問題だな。っていうか俺の手元ではほぼ解決済みだ
> Role単位で過程を完全に分離できるので、管理がすごく楽なんです。
> Ansibleだとコケた場所とコケた原因のコマンドが一目瞭然なのでとてもメンテしやすいのです。
それもほぼ解決済みだ
シェルスクリプトで解決可能なたったそれだけの問題のために
Ansibleみたいな内部で何が行われているかわからない
重量系なブラックボックスツールをありがたがって使ってんのか
なんであれ（Ansibleとか）が無駄に重いソフトだってみんな気づかないんだろうか
> 2ch書き込みのブランクありすぎて色々ひどい。。
一体いつからここが２ちゃんねるだと錯覚していた？
なんかアドレスが5chになってる。いつの間に。。
>>109
言ってしまうと、自分のスクリプト力もあまり信頼してなくて、
今書いた複雑なスクリプトを一年後の自分が読めるとは思ってないのです。
ベテランの人が自分で方針を決めて数年後でもメンテできるように書いていれば
その人は問題なく使えると思うのですが、他の人はそれを読めるかどうかというところですね。
Ansibleのベストプラクティスに従っていれば、そんなベテランの腕がなくても
仕組みで自然とそのようなメンテがしやすい形にはなるのです。
ただ、ベストプラクティスもそのままだと実用としてどうなのというケースも多いので
現場に合わせてアレンジする作業は必須だと思いますが。
(教科書そのままでは現実では役にたたない、とよく言われるアレみたいな感じです)
Ansibleそのものの挙動はブラックボックスなところもあるかもしれませんが、
品質の担保はServerSpecのテストでやってます。
何か問題があったらServerSpecのテストを足せば良かったりします。
手順書に確認手順を追加するよりテスト書いてgitで管理して必要に応じて実行する方が簡単で確実かなと思ってます。
テストや確認事項を手順書に追加するのは手順書のメンテナンスも確認作業も面倒ですが
テストなら足して実行すればよいだけなので、細かすぎるような確認作業も気兼ねなくガンガン追加できます。
>>111
> 今書いた複雑なスクリプトを一年後の自分が読めるとは思ってないのです。
環境構築ごときでなんで複雑になるのかそこが不思議。
まず一つだけアドバイスするなら、設定はファイルの項目ごとに変更するのではなく、
設定ファイルをまるごとcopyすること。これで冪等性も担保される。
環境構築なんてファイルおいて数個のコマンド実行して大抵はこれだけで
終わるはずなんだが、なんで複雑になってるのか知りたいよｗ
冪等性を考えると前の状態を考慮する必要がでてくるので条件分岐なんかが出てくるが
Dockerだと最初から作り直しになるので関係ない
あんな大量のモジュールができてしまったのは、冪等性を考慮したことが根本原因かね？
> Ansibleのベストプラクティスに従っていれば、そんなベテランの腕がなくても
> 仕組みで自然とそのようなメンテがしやすい形にはなるのです。
細かいファイルに分かれていて、notifyとはhandlersとか使っていて、これどうなってるんだ？って頭を抱えたことが有るんだがｗ
単純にメンテしやすい形になればいいのかねぇ。詳しくは言えないがそれなら俺の手元では解決済みなんだ。
> Ansibleそのものの挙動はブラックボックスなところもあるかもしれませんが、
> 品質の担保はServerSpecのテストでやってます。
テストのためだけにRubyをサーバーに入れなきゃいけないってのもナンセンスだよなｗ
入れない方法もあるんだっけ？
> 何か問題があったらServerSpecのテストを足せば良かったりします。
> 手順書に確認手順を追加するよりテスト書いてgitで管理して必要に応じて実行する方が簡単で確実かなと思ってます。
俺は一言も手順書なんて言ってないんだよね。テストもシェルスクリプトでやればいいでしょ？当然gitで管理できる。
あとServerSpecでも同じくブラックボックス問題がある。ServerSpecでは一体何を調べてるんだって話だよ
例えばpackageでパッケージがインストールされているか調べられるが、パッケージの管理方法はディストリで違うはずだ
packageはAlpineのapkでも使えるのか？という質問に自信をもって答えられるのか？すぐにソース読みとけるのか？
（まあそこはコマンドが実行できればOKとするのが、やるべきテストだと思うけどさ）
Ansibleがブラックボックスツールということの
意味がわからない人がいるかもしれないから
軽く説明しておいてやろう
まずお前らは環境構築をしているよな？それが仕事だ
その仕事をしている最中に、Ansible関連でバグとか
モジュールが対応してなくてうまく動かない自体が発生した。
それらをお前らすぐになおせるの？
pythonを知っていたとしてもまず無理だろ？
重量級のAnsibleをブラックボックスで使ってるからな
でも本来のお前らの仕事である環境構築は
手作業やシェルスクリプトですぐに解決できるだろ？
Ansibleの範囲でうまくできてりゃいいさ、だが
それができない場合、大きなボトルネックになってんだろ
多少はやったことありますが、AnsibleのモジュールそのものをPython書いて修正するというのは敷居がけっこう高いですね。。
確かに、廃止されたりオプションが変わったり、変な挙動のモジュールもあります。
解決策はそのモジュールが使えてるAnsibleのバージョンを固定するか
最悪、shellやcommandモジュールでLinuxコマンドべた書きするかでしょうか。
ただ、shell, commandモジュールを使うと冪等性が担保できないので
非推奨なのですが、そもそも私は冪等性というものを信用してなかったりするので
自分の場合は特に問題なかったり。
Ansibleが用意しているモジュールがあるのにshellやcommandでやろうとすると
こっちのモジュール使えという警告が出て煩わしかったりします。
使えるモジュールは使うとシンプルにかけたり良しなに処理してくれたりと確かに便利ではあるのですが
さっき書いたように廃止や挙動が変更されるリスクもあります。
そこでdockerコンテナを使ったPlkaybookの高速検証が活きてくるという。
ServerSpec実行してOKがでればOKと信用すりゃいいんだろうけどさ、何をテストしているのかさっぱりわからん。
ServerSpec（というかrspec）というフレームワークはブラックボックスで良いんだが
肝心のテスト内容（matcher）で何をやってるのかは把握してなきゃだめだろ？
>>112
> ただ、shell, commandモジュールを使うと冪等性が担保できないので
Dockerや最近のImmutable Infrastructureではサーバ作ったら変えないので
ありがたいことに冪等性は不要になった。実行前は必ずクリーンな状態なのでね。
俺も冪等性は信頼してない。特にAnsibleとかブラックボックスなので。
ただしここではいわないが、冪等性に変わるアイデアを持ってる
> さらさらっと書いてますが、このようなdocker,ansible,Serverspecの環境を作るのはそれなりに大変だと思うので、
Dockerはともなく、ansible とか Serverspec だから大変なんだよ。
Serverspecとか今度はRubyいるだろ？
参考になった。まあ気にすんなよ。あんたを煽ってるわけじゃなく
ちょうどansible使おうとしてるやつがいたから、なんでか聞きたかっただけだ。
Ansibleとかほんとクソだって思ってるので
最初の質問にもう一度答えると
> dockerfile使わずにAnsibleでコンテナ構築してる人居ます？
つかわん。dockerなら冪等性いらないし、1コンテナで動かすものは極力シンプルにするので
構築内容は短くなる。逆にAnsibleを動かすための部分のほうが長くなる
コマンドが異様に長くなるのでラッパースクリプト書いたりするのですが、
シェルスクリプトはそこで今でも大活躍してます。
なんだかんだで便利なんですよねシェルスクリプト。
Dockerfile に関しては冪等性なんていらないのでそのまま使う派
Ansible が便利なのはわかるけど、Dockerfile に関しては 1 のことをするのに
10 できる道具で頑張る感じがつらい。
Dockerfile 以外のセットアップに関してはマニュアルとか書き方とか面倒すぎるので
学習コスト払ってもシェルスクリプトは使わないで Ansible でも良いんじゃねって思う。
私にとってはトラブル解決時に 1000 行とかの自作のシェルスクリプトなんかより Ansible のコードを読むほうが楽。
まぁ、自分しか使わないシェルスクリプト100行ぐらいで済むものならどっちでもいいけどね。
インフラテストに関しては goss 使ってるな～。Rspec の記述や Ruby 入れるのだるいので。
goss は golang 製だからバイナリ置くだけだし、stdin つないでテスト渡せるので実行が簡単。
Yaml でかけて、機能が多すぎないのでテスト書くのもむっちゃ楽。
欠点は PullRequest などへの反応が鈍い、もともと作者が golang の勉強で作ったものなので設計が気になる（特に比較方法とか）
DockerImage のみのテストならば countainer-stracuture-test という google 製のものが出てきたのでこれも面白い
これに関しては、できたてなのでバグがかなり多い。新たなコミットのたびにバグができるｗ
テストできる機能は少ないが、docker engine 無しでイメージテストができたり、メンテナの反応も速いしコードも読みやすい。
今後ちゃんと出来上がれば化けるかも
> 私にとってはトラブル解決時に 1000 行とかの自作のシェルスクリプトなんかより Ansible のコードを読むほうが楽。
> まぁ、自分しか使わないシェルスクリプト100行ぐらいで済むものならどっちでもいいけどね。
俺の観測ではシェルスクリプトが100行だと
Ansibleのコードは1000行って感覚なんだけどね
大きな会社だと仮想サーバ一つ立てるのにいちいちインフラエンジニアにお伺い
たてないといけないけど、リソース多めのVM一つ作ってもらえばそこにdocker入れて
いろんなコンテナたててやりたい放題できるという。
4vCPU,8GBMem,100GBHDDあればデフォルト設定でコンテナ5くらいはいける。
もちろん検証用DBコンテナとか立てるときはMySQLのinnodb_buffer_pool_size小さめにしておくとか
ちょっとした工夫はいるけど。
>>131
まあ会社が会社だとそういうことなんだろうけど
> 4vCPU,8GBMem,100GBHDDあればデフォルト設定でコンテナ5くらいはいける。
それ個人用に配給されてるPCレベルだよね？って思わなくもないｗ
うちは入社当時のMac Book Proの一番上当たりの性能
CPUは忘れたけど、16GBのメモリと、512GBのSSDだったかな？
やっぱりシェルスクリプトだとなんでそんなに
メンテナンス性が悪いものが出来上がるのか？
書くことはAnsibleとかわらんだろ（むしろ短く書ける）
と思ってるわけだが。
ふと気づいたがもしかしてシェルスクリプトで書く時に関数作ってないのか？
ただ単に上から下へとコマンドを書き連ねるだけ？
プログラマの感覚だとどんな言語であれ可読性・メンテナンス性が
高くないように記述するもんなんだが、インフラエンジニアってのは
それができてないレベルだったりするの？
bash のスクリプトだろうと、Python だろうと golang だろうと関数は普通に使うね。
で、シェルスクリプト 100 行だと Ansible のコード1000 行ぐらいという感覚も正しいと思うよ。
実際は、500とか600 ぐらいだと思うけど。
Ansible の yaml だと 30 行くらいかな。
てか、コードが短く “も” 書けるのが嫌なんだけどね。
例えば、2つまでつなげるなら期待通りに動くから if を使わずに || や && でつないだりとかね。
私自身はもともと Perl からの出身だから、色々な書き方があって(TIMTOWTDI)
書き方によっては短く書けるのが楽しいとか良いと思う面はある。
ただ、コードゴルフをやるならまだしも、自分以外が見るコードは
そういうことをする余地がなければ無いほど良いと思ってる。
あと、shell も perl も（Cも）変数のスコープがデフォルトでグローバルなのが良くない。
ちゃんと動くからって、スコープ意識しない使い方のコード書かれてそれをレビューで指摘したり
そのために CI を準備したりとか考えたくない。
そういう点では python の pep とか golang の fmt/lint とか最高だと思ってる。
Dockerfile も「どれだけ削るか」などで人によって書き方がまちまちになってしまうんだけど、
普通は大規模にはならないし、出来上がるイメージをバイナリだと思ってちゃんと動けば
中身がどうであれとりあえずは良いのかなと思えたりするので結構好き。
「プログラマの感覚だとどんな言語であれ可読性・メンテナンス性が高くないように記述するもんなんだが」
は可読性、メンテナンス性が高いようにじゃない？
今はdockerで混乱してる
開発環境はどうやって整えるんだ、これ
コンテナの外と中は完全に分かれているのかよ
今あるエディタやアナコンダを呼べないぞ
コンテナを作る時に全部詰め込まきゃダメなのか?
NGCをつかっているけど
>>164
はいはい、いつもの仮想マシンの使い方とごっちゃにしてる人ね（笑）
Dockerは環境を作るものじゃなくて、
アプリケーションを作るものです。
ディープラーニングの何をしたいのか知らないけど
コマンドを実行するだろ？
そのコマンドを実行するのにライブラリとか必要だろ？
そのコマンドにライブラリなんか全部くっつけて
一つのDockerコンテナ＝アプリケーションを作るものです。
いや、知らんよ
俺は開発元が進めてきたものを使うだけ
aptコマンドもないんだけど・・・
docker search ubuntuで出てくるうち全部入りのイメージってどれ？
>>172
欲しけりゃ自分のDockerfileに入れるか
全部のコンテナでそれやるのがアレってなら
新しくvimコンテナ作って編集したいファイルだけマウントするか
ホストのファイルをマウントして
ホスト側でvimで編集すれば良い
てか開発環境だよな
本番環境でそれやったら
ちゃんと動く環境を保存出来るっていうDockerの魅力を殺している
場合によっては仕方ない事もあるが
>>172
> pullしたubuntuイメージにvimが入っていないんだけど・・・
Dockerの使い方を間違ってる。
あんたが言ってるのは、pullしてきたffmpegコマンドの中に
vimが埋め込まれてないんだけどって言ってるようなもの
Dockerコンテナ = 実行ファイル
ffmpegの処理にvimなんていらないんだから入っていなくて
当たり前だし入れるべきではない
だがaptコマンドは普通入ってるはずだけどな
>>172
> dockerってコンテナが動いてる途中でdocker終わらせたらコンテナ内に保存してたファイルはなくなるの？
ffmpegコマンドの中で内部的に使用しているファイルはコンテナ削除とともに消える。
Dockerコンテナの中のファイルはメモリと考えればいい。
コマンドを終了するとメモリも解放される
（Dockerコンテナ版の）ffmpegコマンドから書き出したいなら、
ボリュームでコマンド（コンテナ）外部への読み書き場所を指定する
アドバイスありがとう
ということは、dockerで起動したOS内でvimが使いたければ
vimのコンテナを探してきて追加起動しろってこと？
どこのサイトにどんな名前でvimのコンテナがあるのか調べるみたいなことを
アプリごとにやってたら、環境を作るまでどれだけの手間と時間がかかることやら
このソフトの何が持てはやされているのか全く理解できない
>>178
だから使い方が間違ってる。
全く理解できないのは、あんたが正しい使い方がわかってないからだよ
そもそもDockerコンテナは使うものじゃない。作るものだ。
アプリのビルド・コンパイルと一緒だよ
もちろん誰かが作ったものがそのまま使えるのなら
使っていいんだが、基本はアプリの開発者が作るもの
vimとかそういうのは、どうせあんたUbuntuとか有名所の
ディストリ使ってるんだろ？そういうのはパッケージメンテナが
ちゃんと動くようにメンテしてくれてる。それで満足してるならそれ使えばいい。
Dockerの出番はそれで満足できない場合だよ。
vimにそういうのがあるのかしれないが、独自にビルドしないと使えない機能を使いたいときや
例えばvimの新しいバージョンを使いたい時。ビルドするためにライブラリも新しくしなければいけない
でもOSのライブラリを新しくすると、他のプログラムに影響が出るかもしれない
そういうときにvimのビルドとそれを動かす環境までも一体化させて、独自のvimを作る
ってときに使うんだよ。実行環境まで含まれてるから、OS標準のライブラリなどを
置き換えたりもしないし、どこに持っていってもそのまま使える
オレオレvimバイナリ（=Dockerコンテナ）の出来上がりってわけだ
で、そんなもん普通はやらねーだろ？ だからアプリの開発者が作るものだって言ったわけだ。
vimなどのパッケージはパッケージのメンテナが頑張って動くようにしてくれてる
だけど、自分で作ったアプリは、自分が頑張るしかないだろ？ でも頑張りたくもない
いろんなディストリや、WindowsやMacでも動くようになんかするの大変じゃないか
だからDockerコンテナ化することで、Dockerデーモンさえ動いていれば、
どこに持っていっても同じように動かせるってわけさ
一言で言えば可搬性だな
>>178
> ということは、dockerで起動したOS内でvimが使いたければ
それから通常はdockerで起動したOSの中に乗り込んでvim実行して
ファイル修正とかしないからな
独自のDockerイメージを作るときに、デバッグ目的にやることはあるけど
「dockerで起動したOS」なんて考え方を持ってはいけない
なぜなら、何らかのプログラムに実行環境をくっつけただけで、
作られるものは、実行環境付きのなんらかのプログラムなんだから
そこにOSなんてものはないと思え
>>173
正確にはコンテナを削除すると無くなる
停止しただけでは無くならない
ゆえに削除するまではdocker logsでログも見れるし
docker commitでイメージ化すれば
docker runで中身を見れる
単にコンテナ内でvim使うかどうかって話だとしたら本気で意味分からん。
>>238
Dockerはアプリケーションコンテナと言って、
アプリケーションをコンテナ化するもの
システムコンテナと違って、コンテナの中で作業するためのものじゃない。
だから、vimという手動で作業するツールをコンテナに入れる意味はないし、
vim自体をコンテナ化しても使いづらいことは説明済み
> 良くあるベストプラクティスに書いてあるから
ベストプラクティスレベルの話じゃない。Dockerの使い方の基本の話。
とりあえずアプリケーションコンテナとシステムコンテナの
違いぐらい学習してから出直せ
>>233
アプリケーションコンテナとシステムコンテナの違い、ですか。そうですか。
教科書にはきっとそう書いてるんでしょうね。その辺はよく知らないけど、たぶん間違ってないんだと思います。
でも、私はDockerで開発するファイルも編集します。はい。
>>236
コンテナの中にあるファイルはコンテナ削除すると消えるでしょ？永続化しない。
残っていてほしいファイルはボリュームでコンテナの外にだすわけだから
そのファイルの編集はコンテナの外でやれば良いわけ
中にvimを入れておくのは開発中とかの一時的にしかやらんよ
っていうか使いづらいでしょ？ あんたvimの設定とかしてないの？
デフォルト設定で使いづらいからカスタマイズするのが常識だけど
コンテナの中にあるのはなんの設定もされてないvimじゃん
>>239
残ってほしい開発後のプログラムがあるならgitでpushしとけば良くない？
設定あんまりシナイ派だけど、仮にするとしても、それこそvimrcとかgitでpushしてるものをcloneで持ってくれば設定なんて一撃で終わらない？それじゃあダメな理由とかある？
>>241
gitは作業中断時に一時保存するための道具じゃないし、
設定しないなんて使いづらいだけだし、
いちいちcloneするとか面倒くさいことこの上ないし、
ホストでやれば普通にできることを、いちいちやらないといけないのか？
間違ってる方向に進むとこれから、あれやこれが使いにくいって愚痴るだけだぞ
すでに愚痴ってそうだがｗ その原因はすべて間違った使い方にある
変な癖が付く前に矯正したほうがいい
>>243
一時保存なんて利用用途で言った覚えはないけど、仮にそうだとしても何で一時保存でgit使ったらダメなの？
あなたって基本に従うってことに束縛されて思考が限定されてる気がする。自分だけでそういう方針で進めるのは勝手だけど、人にやり方強制しだすと嫌われるから考え改めた方が良いよ。
新卒ならまだ良いけど。
>>246
gitはバージョン管理するための道具であって、
バージョン管理しないならタダの保存に過ぎないから
それにgit使うなら、コミットする時に、メールアドレスと名前の設定がいるだろ？
gitでpushするならssh鍵が必要だろ？
rootでやるわけないから、自分のhomeディレクトリがいるだろ
お前本当にコンテナの中でgitでpushとかしてるんか？
してねーだろ。使いづらいもんな
お前はまだ初心者で、どうせgitもオープンソースものをcloneするぐらいのことしか
したこと無いんだろ。基礎ができてないんだからまず教科書通りにやれと
けどそんなの関係ねぇ。
実際エンジニアに開発環境としてコンテナ提供するのにsshでアクセスできないって不便でしかない。
関係ないとか言ってないで、自分の解釈が大きくずれているって考えたほうが良いよ
ちょっと間違いレベルじゃなくて、方向性が大きくずれている
変な使い方をしているから、使いづらく感じるんだよ
>>240
解釈がどうじゃなくて、実際便利に使えるかどうかが問題なんだけど。
どんなに正しくても実際に使い難ければ正しくてもやらない。
もちろんセキュリティーや影響は考慮するけど、その辺問題なければ基本がどうとか関係ない。
PMBOKとかAgileとか、基本に忠実にそのままやったら余計効率が悪くなって使えたもんじゃないでしょ。教科書守れば良いって思考は実用的な効率を犠牲にする。
教科書通りやって現場がうまくまわってるならそうすればいいよ。
というか、むしろ教科書なぞってうまくいってる現場があるならそれ勉強会とかで話してほしい。見に行くので。
>>249
そのPMが教科書通りにやってないだけだよｗ
教科書通りにやることが簡単だと思ってはいけない
教科書に反論するときは、教科書の場合と何が違っているかまで
理解してからじゃないといけない。
教科書になってるぐらいだから基本的には正しいんだよ。
それが当てはまらない理由を見つけない限り、教科書に反論してはいけない。
当てはまらない理由がわからないのは、理解してないってことになるんだから。
いまWSL使ってDockerを使っているんですが、atomでホストに置いたファイルを修正して
それをイメージに反映させたいのですが、修正するたびにビルドするのが面倒です。
なのでボリュームを使ってホストのディレクトリをコンテナ内に共有しようと思っています。
Linuxではうまく動いているのですが、WSLだとうまく動かないのですが、
何が問題だと考えられますか？
WSLで使ってるのはWindows上のDockerなので
パスの指定をC:\～でやらないといけないきがします。
ビンゴでした！
こんな感じでホストのディレクトリがコンテナから見えました。
これでWindowsのatomを使って簡単に編集できそうです。
スレ汚し申し訳ありません
インフラエンジニアの居ない規模の企業でアプリエンジニアが勉強して開発から本番運用までやってるって言うなら分かるけど。
インフラエンジニアいるのにミドル部分までアプリエンジニアが制御するって問題無いの？
部署をまたいだアプリエンジニア同士で宗教論争はじまってまとまらないと思うんだけど。。
>>281
お前さ、アプリケーションが動くサーバー作ったことないだろ？
どうせデータベースサーバーのセットアップぐらいしかしてねーだろ？
データベースサーバーのセットアップなんて簡単だもんな
設定ファイルをいじるだけ。そんな簡単な仕事はお前にやらせるよ
で、アプリ開発してないやつが、どうやってアプリケーションが
動くサーバーを作れるっていうの？
あぁ、どうせお前、オープンソースのアプリ動かしてるだけだっけ？ｗ
俺が作ったアプリ、そのアプリが動くのになんのライブラリが必要か言ってみ？
アプリを開発してる俺は当然わかるが、教えないからなｗ
アプリのコード読んで必要なものを調査するとかやんなくていいよ
俺がコンテナのイメージつくってやっからさ、
お前はそれ動かすだけ。おまえにできないことはやらなくていい
お前はDockerr動くLinuxマシンだけ用意してればいい
俺本読んでもさっぱりわからんかったもん
コンテナがIPアドレスを持つって聞いて、ファッ?ってなったわ
コンテナ=アプリとその動作環境をパックにしたものと
ここで教わったが、アプリがIPアドレスを持つわけないだろう
UNIXソケットを使わない場合にアプリケーション間のデータのやり取りはTCPやUDPで行われることが多いと思うのだけれど, そうするとIPアドレスがないと困るだろう
特にロードバランシングしていると同一ホスト上でないことが普通なので, ソケットが使えないことが多い
>>288
> コンテナがIPアドレスを持つって聞いて、ファッ?ってなったわ
> コンテナ=アプリとその動作環境をパックにしたものと
> ここで教わったが、アプリがIPアドレスを持つわけないだろう
そう。認識としてはIPアドレスを持ってないと考えていい。
内部の仕組みの話だから。
コンテナ = アプリで、環境の仮想化を行っているため、
そのコンテナ（＝アプリ）は自由にサービスを提供するポートを変更できる。
仮にコンテナの中で80番ポートでアクセスを受け付けているからって、
コンテナ（＝アプリ）は80番ポートでアクセスを受け付ける必要はない。
コンテナが受け付けるポートは自由に変更できる。
それが「仮想化」で実現している機能の一つ
それを実装するために、内部的にルーティングしているというわけ
Dockerの仕組みに詳しい人はネットワークについても勉強するだろうけど
Dockerを使っている段階では、コンテナがどのIPアドレスを
持ってるかなんて意識していない
>>288
> それだけDockerの理解・運用は難しいということだな
技術職っていうのはそういうもんだよ。
ソフトウェアにおいて技術=知識
知識を得て楽をするか、知識ない人は力ずくで頑張れと
そこで働く人間無視して仕事できる訳ないし、やってるつもりなら大した仕事してない。
勝手なことやるなら本当にインフラも含めて別予算で独自にやってほしい。
えらそうな事言って勝手な事やって、結局尻拭いはインフラ側に押し付ける勝手なアプリエンジニア見ると文句の一つも言いたくなる気持ち分かるでしょ。
インフラエンジニア要らないってのは理想。ただ、その理想を妨げる事が多いのが声がでかいアプリエンジニア。
大概やりたいようにやって自分では運用回らなくなって、別の誰かに運用を押し付けて自分はフェードアウトするってのがお決まりのパターン。
>>300
そういう話じゃねーよ
人を持ち出してきたら、どんな結論でも覆せるんだからここで話す意味ないだろってこと
例えばウェブサーバー運用するのにLinuxが適しているとなっても
うちではLinux使える人がいないので、Linuxはだめなんですってなるだろ
Javaが適していてもうちではJava使える人がいないでJavaだめなんです。
COBOL使ってください。ってなるだろーが。
もはや適しているかどうかの話じゃなくなるんだよ。
「Dockerの適している使い方は○○です」って結論した後
心の中で「でもうちでは技術者のスキルが低くて使えるやついないんだよ。」って泣けばいいだろ
他の人には関係ない話だ
>>300
> インフラエンジニア要らないってのは理想。
そんなこと言ってない。アプリエンジニアがやるべきことはアプリエンジニアがやって
インフラエンジニアがやるべきことはインフラエンジニアがやれってだけ
アプリがなんの言語で使ってるかなんて、アプリエンジニアが知っていればいい情報だろ
言語もそうだしアプリ動かすのにインストールしなきゃいけないライブラリやパッケージを、
アプリエンジニアに聞かないでわかると思うか？
インフラエンジニアにはコンテナのイメージ渡すから、それを動かす環境を作ってくれればいい
中が何で動いているかなんか、知ったこっちゃねーだろ？
それとも勝手にディストリやパッケージを適当に入れた挙げ句、ライブラリのバージョンの違いで
動かなかくて、その責任をとってくれんのか？
どうせこういうことすら思いつかなかったんだろ？
だからお前がアプリケーションが動くサーバー作ったことねーだろってわかるんだよ。
数日かけてDocker使って個人用のミニアプリ書いたぜ
内容はサーバーのとある情報を、別のマシンからブラウザで
グラフで見れるようにする一種の監視ツール
zabbix や nagios みたいに本格的な物はいらない。むしろおもすぎて邪魔
先に結論から言うと、このアプリを新しいサーバーで動かすには
docker run -d -p80:80 -vなどのオプション –restart=always コンテナ名
とdockerサーバーが動くマシンで、たった一行実行するだけでデプロイは完了する
（docker hubにイメージ置けるのであれば、本当にこの一行で終わり。
置けないならばプライベートレジストリから取ってくるように少し準備がいるだろう）
これは個人用のアプリで１人でやっているが、もしインフラエンジニアに伝えるとすれば、
このコマンドとどんなオプション（環境変数）があるかを伝えるだけで終わり
あとは必要なサーバーにデプロイしてくれるだろう
もしDockerを使わずにインフラエンジニアがデプロイをしようとしたら大変なことになるだろう。
なぜかって？だってこれだけの情報じゃ、どんなサーバーを構築すればいいか
インフラエンジニアにはわからないでしょ？何をインストールする必要があるのか？
なんの言語が必要でどのパッケージを入れておかないといけないのか？
スクリプトのパスは？どんなコマンドが必要なのか？などなど
docker使えば、さっき書いたdocker run～のコマンドだけで構築できるというのに。
>>308
chroot使うぐらいならDocker使うなー
chroot用のディレクトリを準備するのでさえめんどくさい
debootstrapだっけ、懐かしいな。
/procや/devのマウントとかも必要だし。
同じdebianでもDockerだと最小構成で用意されてるから
ダウンロードの時間からして差があるし
誰かがDockerfileのようなものを公開してくれてるわけでもないし
懐かしくてちょっとググってみたけど、
あんな面倒なことやってたのかって思った
いわゆるインフラ屋はDockerを使って
ディストリによってパッケージが用意されてるようなものを
Dockerイメージ化するという発想になりがちに思える
つまりDocker使わなくても、普通にパッケージ入れたり
VM使えばいいだろという発想
違うんだよね。Dockerは独自に開発したアプリのために使う
独自に開発したアプリは、誰かが依存関係を
解決したりしてくれないからね
だからアプリが動く環境も含めてDockerイメージにする
そうすりゃDockerさえ動いていれば、簡単にどこでも動くものが作れる
これらをホストゲストで共有してるDockerは、ライフラインを共有しているゲストハウスみたいなもの
カーネルぶんのメモリ(敷金礼金)は浮くがinit以降のメモリ(賃料)は当然払わなければならない
起動も10秒以下の差
つまりデスクトップならVM常道
>>343
今までの話の流れからすると、CIでテスト実行するたびにVMの作成と破棄をしていたってことでしょ？
>>327がVMでも10秒以下の差しか無いから問題ないみたいなことを言ってるから
（VMの中でDocker-Composeが動いてるのは、この話にあまり関係ない）
当たり前だけどDockerコンテナの起動に比べればVMの起動は遅い
起動の差を10秒以下にするには、VMのイメージを作ってないと不可能
あとできればSSDとかクラウド使うとか。それでもDockerの1秒に比べたら遅い
そして肝心のVMのイメージを作成するのに時間がかかるっていうねｗ
Dockerの場合はアプリの実行環境が含まれる。だから構築に時間がかかるVMは
色んな種類のアプリのテストに使い回すことができる。
Dockerを使わないなら、アプリを動かすためにVMのイメージに
実行環境を含めないといけない。当然アプリごとにVMのイメージが必要になる。
DockerでもアプリごとにDockerイメージが必要になるのは同じだが
Dockerはキャッシュがあるから、Dockerイメージの作成は短時間でできる。
VMだとキャッシュはないし起動に10秒かかるし、作成したイメージの
サイズもでかいし頻繁にVMイメージの作成なんかやってられないよ
ま、そもそもVMとDockerは違うもので、両方を組み合わせて使うものなんだけどね
クラウドを使っていればわかるはず。
VMを増やすと金はかかるが、新しいスペックのマシンを
手に入れることで、クラスタの合計性能が増える
Dockerコンテナを増やすだけじゃ、クラスタの合計性能は増えない
Dockerコンテナは一つの（仮想）マシンの中でCPUやメモリを
無駄にすることなく（サンドボックス化された）プロセスを複数起動したり
アプリのデプロイを用意（手元で動いたイメージをそのまま使うとか）にするために使う
目的が違うものなんで、Dockerの代わりにVMを使うとか
VMの代わりにDockerを使うとかいう発想がそもそもズレてる
物理マシンもVM（仮想マシン）も、俺にとっては同じマシン扱いなんだわ
形あるハードウェアで形作られてるかそうでないかの違い。
そのマシンにアプリをデプロイする時にDockerを使えば、
そのアプリは同じマシンの他の環境の影響を受けないので
簡単にデプロイできる。
Dockerのメリットはアプリの配布と実行環境なんだよ
「アプリ＋実行環境」でコンテナ化されるから、
LinuxやMacやWindowsに持っていっても動く。
簡単にまとめるなら、
マシン（物理 or 仮想）の中 に
アプリ（パッケージ or Dockerイメージ）をインストール
ってこと。
アプリをサンドボックス化するためにマシンを作るとか重すぎでしょｗ
まさに牛刀割鶏、鶏をさばくのに大きな牛刀を使うようなもの
Dockerがやはりまだ理解しきれておらず、、、
理解が全然違うか教えて欲しいのだけど、
nginx + uwsgi + flaskでサイトを開発したい場合は、ローカルでコードを書いて、
DockerfileにBusyBox + nginx + uwsgi + flaskを入れるように？設定して
docker buildを行うと、書いていたpythonコードと必要なコンポーネントが
まとまったdocker imageがサーバー上に出来上がり
docker runする事によりdocker imageから生成されてインスタンスが立ち上がる
であってる？
docker imageがclassでrunするとオブジェクトが出来上がると理解しているのだけれど、、、
なぜあえてクラスとオブジェクトに絡めて理解しようとするのか。
仕事で必要とかじゃなければ無理して理解する必要ないと思うよ
一般庶民が微分積分を理解できないように、一般プログラマにはDockerは難解過ぎる
× 一般プログラマにはDockerは難解過ぎる
○ お前にはDockerは難解過ぎる
>>448
なにを一塊のウェブアプリにしたいかだよ。
まず前提としてflaskだけでも、組み込みサーバーを使うことでウェブアプリとして使える
だけど、これは開発用なので公開用としては使わない。なのでflaskだけでは
ウェブアプリにはできないという扱いにする
では、flask + uwsgi ではどうか？ ウェブアプリとして使えるよね
（pythonあんまり詳しくないから間違ってるかもしれないが）
https://qiita.com/ekzemplaro/items/7757a6544205384e40ad
だから flask + uwsgi で1つのDockerコンテナにするのもあり
この場合、nginxとはhttpでつなぐことになるかな。
socket経由でできるかはわからない。
nginxはnginxで1つのコンテナにして、2コンテナでシステムを構成する
（docker-composeを使えば、複数のdockerコンテナを同時に起動できる）
また flask + uwsgi + nginx まで入れてしまうのも良い
前者との違いとしては、例えば静的ファイルはnginxで配信したい場合に
前者なら別のサーバーで配信することで負荷を下げるという構成が取れる
その反面2コンテナなので少し面倒になる。使うのがお手軽なのは後者
ま、理解できてないのはこの話じゃなさそうだけどねｗｗｗ
>>451
伝わらなくてごめんごめん
たしかにコンテナ分けると負荷が下がるとかは知りたいこととはまったく関係ない
今後職場でDockerを使うかもという話が出てて、
インフラチームではないから詳しい構造とか構成は知らなくていいんだけど、開発側からして
なにか変わるのか事前に理解したくて。
調べていくとdocker runした後にdocker container pruneすると実行して終了したcontainerが
パージされて変更内容がリセットされると書いてあったので、コードはdocker image作成時に
コミットしてないとコード消えるのか？？？ってなってしまったわけなのよ
一般プログラマーからしてdocker imageは関係ないのなら調べるのやめるんだけど、
インフラから事前告知があったので影響あるのかと不安になった
>>454
C言語とかコンパイル言語使ったことある？
dockerのbuildは、C言語などのビルド（コンパイル）と同じ
言語はソースコードをビルドして実行バイナリを作成する
Dockerはすでにある複数のバイナリをもとに、Dockerイメージを作成する
さて、実行バイナリは、データを保存したらどこに保存されるか？
実行バイナリの中に埋め込まれるわけじゃないよね。実行バイナリの外のファイルに保存する。
実行バイナリ自体は読み取り専用。ビルドしたときに作成したバイナリから変更することはない
Dockerも同じように考える。Dockerイメージっていうのはビルドして作成した状態から変更しない
内部的には変更されていてそのデータはどこかに残っていたりするが、そういうのは内部の話なんで忘れる
Dockerイメージは読み取り専用で、Dockerイメージをrun（実行）するとプロセスが起動する
あ、ここも実行バイナリと同じだね。バイナリを実行するとプロセスが起動する
Dockerイメージをrunして作ったプロセス（＝Dockerコンテナ）はどこにデータを保存するか？
Dockerイメージは読み取り専用なので、当然Dockerコンテナの外のファイルに保存する。
C言語 ・・・ ソースコード -> [Makefileでビルド] -> 実行バイナリ
Docker・・・ソースコード等 -> [DockerfileでDockerビルド] -> Dockerイメージ
Dockerのソースコード等には本当にいろいろ含まれる
アプリのソースコードだったり、nginxだったり。カーネル以外の全て
で、コード消えるのか？っていう疑問の答えは、実行バイナリ消してもソースコードをビルドすれば作れるでしょう？
Dockerも同じでソースコード等をビルドすれば、Dockerイメージができるんだから何も問題ない
>>454
> インフラチームではないから詳しい構造とか構成は知らなくていいんだけど、開発側からして
> なにか変わるのか事前に理解したくて。
インフラが全部やりますっていうのなら、開発側に影響はない。今までどおりだ。
そう今までどおり、開発側で新しいライブラリとか追加や更新しようと思たら
インフラにこれ変えたいんですけどとお伺いを立てたり
本番用環境とバージョンが違うとかでバグがでたり
そういう今ある問題がそのまま残るという意味で開発側に「影響がない」ということだ
Dockerfileはソースコードのリポジトリに追加するのが良い
（もちろん分離することもできるが、いろんな問題は解決するのが難しくなる）
そして開発側で新しいライブラリとか追加するなら、ソースコードのビルドスクリプトと同じように
Dockerfile等をインフラチームではなく開発チームがメンテナンスする。
そして最終的にソースコードのリポジトリから簡単な操作でDockerイメージが作れるようになれば
インフラチームはそのDockerイメージを動かすことだけに集中すれば良くなる
開発チームとインフラチームのやり取りが、Dockerイメージを実行する手順だけを伝えれば良くなる。
（例えば必要な環境変数など）
理想は
開発チーム・・・Dockerfileのメンテナンス（Dockerイメージを作成できるようにする）
インフラチーム・・・Dockerイメージの実行
なのだが、現実としてDockerはインフラチーム主導で導入されることが多いので
インフラチームのサポートでDockerfileを作っていくことになるだろう
で、ウェブ開発の際に使う場合に、これじゃ使いづらい場合がある
C言語の場合、ビルドしないと動く実行バイナリはできないから
これで納得するかもしれないけど、ウェブ開発とかしてると
ビルドしなくてもソースコードを修正したらすぐに反映されるわけだ
毎回Dockerビルドしないといけないのは辛い。こういう場合にボリュームを使う手がある
データはDockerイメージの外に置くといったけど、ソースコードもDockerイメージの外に置けばいい
Dockerイメージの中にはPython実行環境などが入っているけど、ソースコードは含めない
ホームディレクトリ以下のいつもの場所をそのまま参照する
当然エディタもDockerイメージの中に入れない。
今までどおりエディタで編集して、実行環境がDockerイメージなっただけ
ただね。Dockerイメージで作る実行環境は、本番用環境と同じにだいたいするので
デバッグなどはし辛い。だから通常のアプリ開発はDockerを使わないほうが楽だろう
だが、いつでも本番用環境を手元で作り出せると、本番用環境でのみ発生するバグなど避けられる
他の人も誰でも本番用環境で検証できるようになるわけだ
すごいわかりやすい説明
コンパイラに例えてもらえると分かりやすいわ
ありがとう
Dockerを仮想マシンの代わりとしてとか考えてると
> 調べていくとdocker runした後にdocker container pruneすると実行して終了したcontainerが
> パージされて変更内容がリセットされると書いてあったので、コードはdocker image作成時に
> コミットしてないとコード消えるのか？？？ってなってしまったわけなのよ
↑これとかで、混乱する。
Dockerは仮想マシンじゃないんだよ。
Dockerfileから作成したDockerイメージはビルドした状態から変更しないもの。（もちろん再ビルドはOK）
Dockerコンテナに乗り込んで、中身を書き換えて再イメージ化なんてこともしない。
できるけど、通常の使い方ではやらない
バイナリに例えれば、C言語のプロセスに乗り込んで（デバッガで？）
プロセスのメモリを書き換えて、プロセス部分をディスクに書き出すようなもんだよ
そんなことしないだろ？
> 今までdocker = vmと考えてたのでファイルの保存などが混乱してたけど、virtualenvの凄い版と考えた方がいいのね
virtualenvといわれると、少し違和感があるな
VMよりずっとましだけど
virtualenvは実行環境を作るもの
Dockerは実行環境を含めた実行イメージ＝Dockerイメージ＝実行バイナリの凄い版を
作るものだから
>>461
やっとそこの理解ができた
インフラがDocker推すのわかるわ
virtualenvのpython周りをなんとなくコンテナ化したのとはちがって、OS含めた実行環境コンテナを作れるとなると、ほんといろいろ解決できるな！
>>462
Dockerイメージを新しく（バージョンアップ）したから、
次からこれ使ってーって開発チームはインフラチームに依頼するだけでよくなる
インフラが気にするのはDockerイメージを実行することだけ
だからDockerイメージが起動さえすれば、物理（or 仮想マシン）の
OSを変えることだってできちゃう。
そのDockerイメージが動きさえすれば良いんでしょ？程度の気楽なもん
開発チームは開発チームで、物理（or 仮想マシン）のOSの機能に
（カーネル以外）依存しているわけじゃないので、
Dockerイメージのベースとなるディストリを変更したりなんでもできちゃう
物理（or 仮想マシン）のOSが変更になったって？別にOSのパッケージに
依存してるわけじゃないのでどうでもいいよ。程度の気楽なもん
いままでDebianベースでやってきたけど、ライブラリのバージョンが古いや
Ubuntuに乗り換えよう。なんてことも気楽にできちゃう
客先が使ってるマシンがCentOSだって？ Dockerがあれば関係ない。
UbuntuベースのDockerイメージが、そのまま動く
本気でやれば、いろいろ解決するよ。ただそのためには
インフラチームに丸投げじゃだめだけどね
やっとdocker-composeわかりかけて
きたとこなのに(>_<)
いやいや、docker理解できないと使えないから安心して
そもそも、個人開発でkuburnetes必要なくない？
>>591
> Kubernetesが登場してORIとOCIが標準化された時点でdockerは役割終えた感ある
KubernetsってDockerを使うんだけど、なんで役割終えたの？
KubernetsでDockerは使えるけど必須ではなくなったからな
将来的には使われなくなるでしょ
>>614
知ってる知ってる。rktとかいうやつな
あれどうなったんだ？w
結局、Docker以外も使えると言う状況に満足して
終わりなんだよ。本気出してないからDocker以外普及しない
rktは違うわ
そもそも個人開発でdockerなんか何に使うの？
コンテナ仮想化って個別にインフラを面倒見れないほどアプリがポコポコ作られるような組織で使うもんだろ
PaaSへのデプロイに使うくらいか？
docker動かすだけの鯖やVMならカーネルだけ乗っててdockerの依存関係だけインスコできるパッケージがあればいいって発想から
ディストリとかvmも小さいものや、専用のものを使いましょうってだけの話だろ。
リソースを気にしなくてすむのなら普通のlinux鯖で動かせばいい。
引用元
https://maguro.2ch.sc/test/read.cgi/linux/1506574845/
管理人からひと言
![[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]](https://hbb.afl.rakuten.co.jp/hgb/16d8db5d.6e8cbd44.16d8db5e.abfeeddc/?me_id=1213310&item_id=19239248&m=https%3A%2F%2Fthumbnail.image.rakuten.co.jp%2F%400_mall%2Fbook%2Fcabinet%2F0339%2F9784297100339.jpg%3F_ex%3D80x80&pc=https%3A%2F%2Fthumbnail.image.rakuten.co.jp%2F%400_mall%2Fbook%2Fcabinet%2F0339%2F9784297100339.jpg%3F_ex%3D240x240&s=240x240&t=picttext "[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]")
この記事へのコメントはありません。