Docker Part3

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

http://www.docker.io/

前スレ
Docker Part2
https://mao.5ch.net/test/read.cgi/linux/1506574845/

>>297-298
みたいにゴールじゃなく明後日の方向にたどり着いてるやつもいるけどなｗ

>>330
Dockerのテストは意味不明。

Dockerはアプリに環境を付加しただけだから
アプリのテストをやれば良いんだよ。

>>330
serverspecはなんか違うんだよなって思うところがあって、
名前で訂正するならば、servicespecにするべきだと思っている。

例えば、トップページのこれなんだけど、
describe package('apache2'), :if => os[:family] == 'ubuntu' do
it { should be_installed }
end

httpdパッケージがインストールされてることをテストする必要はないと思ってる。
なぜならhttpdパッケージをインストールするっていうのはansibleなどに
書いてあるわけで単なる二重定義でしかない。
本当にやるべきは、httpdサービスが動いていること。

それに関して、以下のようにやっているから良いだろと思うかもしれない。
describe service('apache2'), :if => os[:family] == 'ubuntu' do
it { should be_enabled }
it { should be_running }
end

でもこれは何を調べているのだろうか？ apache2プロセスがいることだろうか？
もちろん違う。systemdなどの情報をチェックしている。だがsystemdで問題ないからと言ってサービスが必ず動いているとは限らない。
動いているけど正しく設定されていない場合がある。また、標準パッケージをやめてdockerを使うようにするかもしれない。
Linux版homebrewを使うかもしれない。サービスとしてみれば正しく動いてるのにテストで失敗することになる。

これはサービスのテストをしていないのが原因
本当にやるべきテストは特定のポートに接続して想定したレスポンスが返ってくるとか、
特定のコマンドが正しく実行できるかだろう。

serverspecがpackageやserviceで抽象化している理由はわかるが、それにより何のテストをしているのか不明確になり、
そしてテストではなく単なる構成管理ツールとの二重定義になってしまっている。
Dockerに関しても、Dockerのテストをやるのではなく、Dockerで作った"もの"のテストをやるべきである。

5chに長文書き込める情熱は正直ちょっと羨ましい

素人は、Dockerfile さえ、まともに書けていないから、

1行でも追加したら、
まず、httpd がインストールされたことを、Serverspec で確認すればよいのでは？

次に、httpdが起動したら、
また起動したかどうかを、Serverspec で確認する

統合テストは、curl, wget, Selenium WebDriver などで、web サーバーへアクセスして、

実際のDOM を取得するとか、画像を撮影するなど、すれば？

>>334
もっとアツクナレヨ

>>335
それやったことある？

ある大きな欠点のせいで、それ簡単にはいかないよ。

やってみてねってことね。

vagrantfileもそうだけどdockerfileとかはそもそも何に対するソリューションなの？
1000大規模の鯖を迅速にスケールしたいという問題に対しては確かに有効だとは思うけど
それ以外の人には殆ど関係ない。
何か存在しない問題に対するソリューションを提供されて、そのソリューションに対する
テスティングフレームワークも提供されて、仕事としてのWEBサービスのというミッションからは
どんどん離れていく気がするね。
興味在る奴は良くこんな事やるよ。

>>340
またかよｗ何度も言ってるだろ。
一言で言えば可搬性

開発したアプリをあちこちに簡単にデプロイできるようにするもの。
デプロイ先は実機Linuxだけじゃない。
手元のWindowsやMac、仮想マシンでも物理マシンでもOK
大規模なクラスタの上いデプロイすることもできる。

さらに同じPC上に複数デプロイすることもできる。
（同じポートを使うって？ Dockerの機能でそれを変更できるんだよ！）

お前のマシンで俺が作ったアプリ（最新版rubyとソースからビルドする○○が必要です！）を
動かすとき、手順書無しで作れると思うか？ Dockerなら最小一行で動かすことができる。

>>341
まるでそれはVMに可搬性がないかのように言っているけど実際は在る。

>さらに同じPC上に複数デプロイすることもできる。
>（同じポートを使うって？ Dockerの機能でそれを変更できるんだよ！）

これも全く同じ。なんでVMにそれが出来ないと思うの？
まるでVMに問題があってその問題をdockerが解決するの様に宣伝されるから
なんのこっちゃ？となる。

>Dockerなら最小一行で動かすことができる。

OVAを解答してダブルクリックする。
終わり。

>>342
> まるでそれはVMに可搬性がないかのように言っているけど実際は在る。

え？ まさかVMでイメージ作って、
そのイメージをMacやLinuxやクラウドの仮想マシンで動かすって話してるの？

どうやって？

例えば、AWSやGCPは仮想マシンとしてKVMを使ってるけど
その仮想マシンで動くVMイメージの形式って何？
そのVMイメージをMacやLinuxで使えるの？

>>342
> OVAを解答してダブルクリックする。

どうやってAWSやKVMでOVAファイルを使うの？
いや、無理だからさｗ あんた無理しないほうが良いよｗ

Infrastructure as code (IaC)

GUI・コマンド入力などで環境構築すると、再現性がない。
手順書に、手順を書いておかなければいけない

コマンドの打ち間違いも生じるから、
環境構築ツールのコードで書いておくべき！

OVAファイルをmacOSで使うにはどうしたら良いんだろうねｗ

>>343
意味わかんね。
そんな事やる必要ないだろ？クラウド上で動くのは本番機であり検証機であり
公式なもの。しかも1回やったら終わり。
何故そこが問題だと思うのか解からない。
前に言ったように1000大規模なら確かに問題であろうとは思う。
とりあえずウチは２，３０台で運用しているけどそれが問題になった事は無い。

>>347
「やる意味がわからない」っていうはお前の問題だろ。
お前が理解できないだけ。それはお前自信で解決しろ。

で、結局できないんでしょ？
その作ったOVAファイルを、AWSやGCPで動かす。
そしてそのOVAをWindowsやmacOSで動かすってことが

>>345
その弊害としてmozcのような例が在る。
IaCを書いた人が継続的にメンテないないとbuildすら間々ならなくなる。
これはdockerの実践ガイドなんかにも書かれていたけど、dockerfileの
パブリックリポジトリ使うときはそのリポジトリのみならず、ubunntuならubuntu
なんかの「外部の」リポジトリに依存するから、ある日突然build出来なるなる事は
ある、だから一度build出来たらイメージをバックアップすべし、的なことを書いて
唖然としたわ。
mozcの人もメンテしてないようだけど、面倒くさいというか、そこまでやる価値ない
と思ったんだろうね。

>>346
Macでは動かさない。ESXiだろ？
君が言っているのはDockerfileをvagrantで動かすにはどうしたら良いんだろうね？
と言っているに等しい。

>>348
それがdockerのメリットなの？本当にその程度？
それなら、相当多くの人にとって別にdockerというのは有難がる
モノでも何でもない、という気しかしない。

>>350
ほらもうできなくなったｗ
可搬性無いじゃん。ESXi使わないと動かないだろ。
そのESXiはWindowsのWSLなどと同居できない。
ライセンスの問題でクラウドのVMで使用できない。

>>351
> それがdockerのメリットなの？本当にその程度？
いや、もっとメリットは有る。
だからまず手始めに、そのOVAをイメージを一切変更することなく
WindowsやmacOSで動かす方法書いてみ

>>349
> IaCを書いた人が継続的にメンテないないとbuildすら間々ならなくなる。
SSL証明書が古くなって接続先サーバーにに接続できないんだけど
仮想マシンでどうやって解決するの？ｗ

まさかビルド済みのDockerイメージを使えば解決する話を出さないよね？ｗ

> mozcの人もメンテしてないようだけど、面倒くさいというか、そこまでやる価値ない
> と思ったんだろうね。

ブーメラン、ブーメラン

つまりVM作る価値がないからOVAファイルがないと？ｗ

>>352
>ほらもうできなくなった

おれ自身が普段使わない、という意味なんですが・・
MacにVMWwareWorkstation入れれば普通に動くだろ。

>>355
普段使わないなら話にならんな。
俺が質問しても的はずれな答えしか来ないだろう。

お前が普段使っているのを言え
お前が俺の質問に正しく答えられると自身があるものを言え。
普段どのOSでOVAファイルを使ってるんだ？

>>356
OVAとかは、これで終わりな。
可搬性がない、という事は当てはまらない。
以上。

>>357
逃げるの？まだ質問の一歩目なんだけど？
その後いろいろとOVAではできないことがあるんだけど

>>358
何つーか君のために、そんな作業するのがだるすぎる。
可搬性の話だよな？じゃあ、もっと手前で、

�@windowsにvmware workstation入れる。
�A何でも良いから適当にOSつくる
�Bそのファイルをマックにコピる。
�Cmacにvmware workstation入れる。
�Cマックで�Bを開く。

自分でやってみれば？

OVAファイルではできないこと。
ブラウザから http://localhost:8080 で接続できない。

できるというのなら、その手順を一行で書いてみてね。

docker run -d -p 8080:8080 image
↑可搬性があるからこんなに簡単にできる。
どのOSでも同じやり方、ポート番号を変えたければ引数を変えるだけ

こんなのは序の口

>>359

�@windowsにvmware workstation入れる。
�A何でも良いから適当にOSつくる ← ここが手動。これ笑う所なｗｗｗｗ
�Bそのファイルをマックにコピる。
�Cmacにvmware workstation入れる。
�Cマックで�Bを開く。

>>340
> それ以外の人には殆ど関係ない。
あなたにとっては、少なくとも関係ないだけですね。
まぁ、頑張ってねっ！

>>360
>OVAファイルではできないこと。
>ブラウザから http://localhost:8080 で接続できない。

Serverspec でテストすれば？

command(コード)で、汎用コマンドも実行できる。
ping, wget, curl とか

Selenium WebDriver を使った、Ruby スクリプトも実行できるかな？

>>361
OSの仮想化技術なんだから当然だろ？
君は何の技術か意味を理解しているの？
何かこういう書き込み見てると、コイツ何処まで理解して話してるんだろうな？と言う気がするね。
2つの全然違う技術をゴチャにしている

>>360
/etc/hosts

IPアドレス 起動したOS
http://起動したOS

> docker run -d -p 8080:8080 image

そもそもこんな事を書く必要は無い。遣りたければプロキシかませば？
言ってしまえばDockerが内部にリバースプロキシを持っているだけだけど、
これも、そうだね。存在しない問題に対するソリューション。
君はこれによって、何の問題を解決するんだい？

余程の事が無い限り誰もこんな事を遣りたいとは思わない。
余程の事が在る人は自前でリバースプロキシ構築する。
例えばMozcのDocker作った人がこれを有難がる事は絶対にない。

一方で標準としてネットワークをこの構成にしてしまった為に>>173と言う疑問はすぐに出る。
俺も全く同じ感想。

総じて君の言うdockerの利点はそもそも存在しない問題というか、恐ろしくニッチな何かに対する
利点を鬼の首でも取ったかの様に喧伝するから、こちらに全く伝わらない。

「Dcokerはこんなことが出来るから凄い」では無く、Dockerはこんな問題を解決しようとして、
XXと言う方式にしている、と言う言い方をしなければ、ごく一般的なITのエンジニアや顧客を
納得させることは出来ない。

>>364
＞2つの全然違う技術をゴチャにしている
全くの別物であるdockerと汎用の仮想マシンを比較する意味なんてないからお前の疑問もまるごと解決だな
さようなら

>>364
> ごく一般的なITのエンジニアや顧客を納得させることは出来ない。
別に納得させなくて良いよ。

>>365
いやいや逃げなよ？まだ質問の一歩目なんだろｗ？

まだやってんのかよ。

>>363

> Serverspec でテストすれば？

？ なに使ってもlocalhostで接続できないじゃん

>>364
> OSの仮想化技術なんだから当然だろ？

だからDockerとは違うって言ってるんだろ？
お前意味不明だな。Dockerと同じことができないって言ってるのに

「Dockerと同じことができる。でも仮想化技術なんだから、それはできない！」

だーかーらー、Dockerと同じことできないじゃんｗ


> そもそもこんな事を書く必要は無い。遣りたければプロキシかませば？
今できるかどうかの話をしてる。できないんだね？プロキシを自分で建てなきゃできないんだね？
ほらまた一つ。VMではできないことが増えたｗ

仮想マシンを使った問題は、mozcの例でわかる。
仮想マシンじゃ、古いバイナリしか持っておけないんだよ。
最新のソースコードを持ってきてビルドしたいときに
古いOVAファイルは全く役たたない

これもVMでは無理なことの一つ

なぜmozcを作ってる人は、仮想マシンを使わなかったのか？
理由はわかるよね？

> 「Dcokerはこんなことが出来るから凄い」では無く、Dockerはこんな問題を解決しようとして、

だから、可搬性。
作ったイメージをあちこちに持っていける。

OVAファイルを作れば同じことができる？
どうやってawsやgcpで動かすのさ？
KVM使ってるんだぞ。

さて、VMではできないこと＝Dockerが解決してることを一つ追加。

Dockerは最新のソースコードから簡単に素早くビルドしてイメージを作ることができる。

仮想マシンはタダの仮想マシンでしかない。
仮想マシンを使っても、ビルド済みの古いバイナリしかとっておけない
新しいソースコードからイメージを生成できない。

>>369
>お前意味不明だな。Dockerと同じことができないって言ってるのに
>「Dockerと同じことができる。でも仮想化技術なんだから、それはできない！」

お前が意味不明だろｗ
いつの間に何が出来て何が出来ない、と言う話になったのｗ？

>今できるかどうかの話をしてる。できないんだね？プロキシを自分で建てなきゃできないんだね？

Dockerはこれを標準で持ってしまっている為に余計な管理コストを強いている、
無ければ必要な人だけが学習して立てれば良いものを標準として強制するから、余計な
教育コストが掛かると>>173は言っている。

XXができてYYが出来ないと言う話をするのなら、Dockerは物理マシンA上に立てたAAと言うマシンが
物理B上に立ってたBBと言うマシンと通信したいと言うだけで、スゲー面倒くさいことをしなければならない。

>仮想マシンを使っても、ビルド済みの古いバイナリしかとっておけない

逆にdockerは古いビルドイメージ取っとくだけでスゲー苦労するじゃん
実務では、当たり前だが、そういう事は多く存在する。君の指摘は大体実務を無視してるけどね。
出来ないことの列挙もそう。普通に訊いて「だから何？」と思うものばかり。

>>372
>OVAファイルを作れば同じことができる？
>どうやってawsやgcpで動かすのさ？

だから本番機と開発機は別だっていってるでしょ。
相変わらず、実務を無視した指摘ばっかりしている。
そこで可搬性が無いのは寧ろメリットだろ。
仮に、本番機を誰でもエクスポートしてローカルのVMなんかで
動かしたら情報漏洩が簡単すぎて大問題だわ。

とてもあたまがわるそう

亞北ネル

まあネットワーク周りとか、どう見てもデメリットでしかないことを
XXが出来る！スゲーだろｗとか言い出すからね・・・。
自分で問題を作って、その解決策を自分で提供して俺スゲーVMにゃ出来ねーだろとかｗ
訊いてるこっちはポカーンだよ。

>>373
実務じゃ多少古くても動作確認済みのバイナリをとっておいて使うので、
動くか分からない最新ソースコードをネットから拾ってビルドなんて、実験段階のPoC作成ぐらいでしかやらない。

Dockerが好きなのは分かったけど、比較が素人丸出しだから、これ以上の恥の上塗りはやめた方がいいよ。

やらないんじゃなくてできない
開発中に毎日数回ソースコードコミットしたら
新しくしなきゃいかんのに馬鹿じゃないのかこいつｗ

ここまで出たVMではできないこと・不便なこと

・VMイメージ（OVAファイル）を手動で作成する必要がある
・新しいソースコードからVMイメージをを作成できない
・ESXiが必要。KVM、HyperV、macOS上で動かない
・OVAファイルから手動で仮想マシンを作成しなければいけない
・仮想マシンに接続するときlocalhostで繋げない。プロキシを自分で設定する必要がる

まだまだ増えます。

>>378
ネットワークは仮想マシン弱いよ？

例えばデータベースの仮想マシンを作る
アプリの仮想マシンを作る。
この二台の仮想マシンをどうやって接続する？

dockerは簡単に繋げられるし、変更もできるから
イメージに一切手を加えることなく、
開発時はローカルのMacに２つを動かして
本番環境では、別々の仮想マシン上に配置することができる
柔軟性が高い。

>>374
> 逆にdockerは古いビルドイメージ取っとくだけでスゲー苦労するじゃん
何も大変なことはない。（プライベート）リポジトリにpushするだけ
OVAファイルは？いちいちファイル転送してダブルクリックするの？
dockerならrunするだけで新しいイメージも古いイメージも自由に使えるのに

> 仮に、本番機を誰でもエクスポートしてローカルのVMなんかで
VMはエクスポートするしか無いんだよなｗ
ソースコードからビルドするということができない
dockerでエクスポートなんかシない



リストに追加

ここまで出たVMではできないこと・不便なこと

・VMイメージ（OVAファイル）を手動で作成する必要がある
・ソースコードを新しくするたびにVMイメージを作成しなければいけない
・イメージが大きすぎて古いイメージをとっておくのが大変
・docker runのように簡単に新旧のイメージを使う方法がない
・ESXiが必要。KVM、HyperV、macOS上で動かない
・OVAファイルから手動で仮想マシンを作成しなければいけない
・仮想マシンに接続するときlocalhostで繋げない。プロキシを自分で設定する必要がる
・本番環境と開発環境で同じものを使えない
・環境を複製するときは既存のものをエクスポートしなければいけない。ゼロからの作り方がわからないから

>>382
だから、何？
結論は？

>>383
レス待ち。

最終的な答えは前から言ってる通り、VMはdockerの代わりにならないし
その逆にdockerもVMの代わりにならない。全く別のもの。

あとdockerないと不便すぎる。VMイメージーのコピーなんてやってられない。

ggrks

>>384
つまり比較すること自体が無意味で
>>382
の書き込みはバカ丸出しということですね。
わかります。

>>387
> つまり比較すること自体が無意味で
最初からそう言ってる。VMはDockerとはぜんぜん違う。

VMを持ち出してきて、dockerはいらないって言ったバカ丸出しはあいつ
>>382の書き込みはバカ丸出しに言ってる

> Dockerはこれを標準で持ってしまっている為に余計な管理コストを強いている、
> 無ければ必要な人だけが学習して立てれば良いものを標準として強制するから、余計な
> 教育コストが掛かると>>173は言っている。

VMを使うと教育コストが掛からないとバカが言っている。
このことを覚えておこう。バカ丸出しにこれがブーメランとして帰ってくることになるだろう

>>388
「狂人の真似とて大路を走らば、即ち狂人なり」

>>390
もしかしてお前が、バカ丸出しのバカか？
さっさとレスしろ。VMはDockerの代わりにならんだろうが

>>391
他人だよ

いつまで執着してるんだよ。

この話題が出るたびだよｗ

>>388
お前、>>167だろ？日本語読めずに勝手に脳内で変な補完して話すからすぐ分かるよ。

> VMを持ち出してきて、dockerはいらないって言ったバカ丸出しはあいつ

誰もこんな事は言ってない。

結論　VMがあろうがなかろうがdockerは必要

Linuxディストリビューション自体の配布には使えないから
VMが無くなる事はない
でもアプリの配布は特にできない理由がない限りdockerイメージだな

Dockerイメージでやりにくいのはカーネル設定の指定
コンテナに特権を与えれば変更は出来るが、同一のマシンで動いているすべてのアプリケーションに影響を与えるので注意が必要

Elasticsearchのhelmチャートが
vm.max_map_countを変更するのに特権付きのコンテナを使うが
それが嫌な場合は自分でOSに設定すればよい

まだやってんのかよ(2回目)。

hyperkubeやk3sを使えばdockerでKubernetesを動かすことさえ可能
他のコンテナを立ち上げたりするので特権が必要だが

>>395
多分君は、自分の出したdockerの利点に対する意見を否定されれた瞬間に
Docker自体を否定されたと感じているんだろうね。
否定しているのは君の意見、というだけだから。

>>375
それは管理ポリシーの問題じゃね？Linuxデスクトップは不便で利用者少ないからウィルスに強いと言っているのと同じだぞ

vmに対するdockerの利点で重要なのは開発者視点ではリソースを食わない＝金がかからないことだろう
これはマンパワーの不足している現在経営的にも重要で
新興国の開発者を取り込むのにvmでは進まないのだ

新興国だけではないぞ
日本の新人開発者の多くはノートを好み貧弱な環境で開発している
vm動かすリソースは無い

dockerはマンパワーを得るためにも有効なのです

>>399
俺が言ってる意見は、Dockerのメリットなのだから
俺の意見を否定することは、Dockerのメリットを否定することになるはずだが？

それとも、俺が言ってることとは別に、Dockerのメリットが他にあるって言いたいの？
俺の意見を否定して、Dockerを否定しないっていうのは、そういうことになるはずだけど

ちなみに俺はDockerのメリットをまだ全て書いてない

あと（あのバカが）「VMでも（頑張れば）できる」って言ってるだけで
俺が言ってるDockerのメリットを否定されたところはないはずだけど？

折角の休み、他にやることないのかね？

>>401
>俺の意見を否定することは、Dockerのメリットを否定することになるはずだが？
>
>それとも、俺が言ってることとは別に、Dockerのメリットが他にあるって言いたいの？
>俺の意見を否定して、Dockerを否定しないっていうのは、そういうことになるはずだけど

君はボッチでニートだから、そういう事になるんだろうけど、普通のITエンジニアは
会社単位で動くからね。Dockerへの移行は会社が決めたこと。確かに、今の利用者の
伸び率を見ているとシステム全体でやがて100台超えるサーバーにはなりそうだし、
社長の意向は世界展開したいとか言っているので、やがて1000台になる可能性はある。
DevOps/CircleCIのイチ技術としてDockerが入り込むのは、当然だなと。
だから別に最初からDockerを否定する気は全くない。そんな話はしていない。
ただ癖が強すぎるし、VMと比べて何故ここまで違いが大きいのかといった、当然の疑問に
誰も答えないから、話が長引いていると言うだけ。
ずっとそういう比較をしていたはずだが？

packer使えばVirtualboxでもESXiでもAWSでもGCPでもDockerでもなんでもよくなるよ

俺が納得できない=答えない
この思考パターンの人間は相手にするだけ無駄
特にネットでは

ええやん、別に VM でやりたければ、やればよいだけ。

Docker を使っても分からんやつは、分からんだけ。
Docker を使って分かるやつは、分かる。

VM を使っても分からんやつは、分からんだけ。
VM を使って分つやつは、分かる。

まぁ、VM を頑張ってね！

>>405
お前は悪口しか言わないな（笑） 品性の低さが溢れ出てる。

Mozcの例から理解しなかったのかな？ Mozcのビルドのどこにクラウドが関係してる？
100台のサーバーとかDevOpsとかCircleCIとか言ってるが、
Mozcのビルドとは関係ないぞ。Dockerfileのおかげで簡単にビルドができた。
（ビルドスクリプトが古いという問題はDockerと関係ない。
実機でもVMでも最新のソースから新しいビルドを作成したら同じことになる）

お前の頭の中からにはこの使い方が完全に抜け落ちてるんだわ
そういうやつが語っても説得力無いよ。

VMとDockerは組み合わせて使うもの。最初から俺はそう言ってる。

Docker （前々スレ。何年前だよｗ）
https://mao.5ch.net/test/read.cgi/linux/1374861492/760
> 760 名前：login:Penguin[sage] 投稿日：2016/10/30(日) 19:57:56.57 ID:PgdoAzbd [1/2]
> AMI or Dockerじゃないんだよ。
>
> AMI + Dockerというふうに組み合わせて使うんだよ。
> っていうかDockerだけじゃ使えない。

当時はDockerだけじゃ使えないと書いているが、
今は、Dockerイメージをそのまま動かすサービスが生まれてるな。
まあもちろん実際にはその下にVMがいるわけだけど。
Dockerイメージを指定するだけで動かせるという意味ね。

>>405
> ただ癖が強すぎるし、VMと比べて何故ここまで違いが大きいのかといった、当然の疑問に

VMと全く別のものだから
違うも何も、別のものだから違って当たり前

初心者は勘違いしてVMと比べてしまうが、そもそもDockerはVMとは関係ないものだから
俺は違いがどうとか比較なんかしてない。お前は初心者から抜け出せてないんだよ。

>>409
相変わらずお前はズレまくってるな！ｗ
もうマジでこの件に関するDockerに出てくるDocker特有の問題はDockerのせいじゃなく、
VMに関する全ての操作はやってられないとｗ。

>Mozcの例から理解しなかったのかな？
これも
>お前の頭の中からにはこの使い方が完全に抜け落ちてるんだわ
これも君にそっくり返すよW
もうお前はレスするなｗ馬鹿すぎて話にならない。
ボッチでニートで実務経験に乏しすぎるお前じゃ、俺が何も止めているのか絶対にわからないｗ
話をしても無駄だから話はしないｗ

>> AMI + Dockerというふうに組み合わせて使うんだよ。

うん、正にそういうことだね。
おれはお前以外の人の書き込みからそれを学んで、心から納得したよ。
お前の書き込み「だけ」ズレすぎているし一人よがり過ぎるから、その点で突っ込まずにはいられなかった、と言うだけ。

>>412のレスについて

ズレまくってると言うばかりで、どこがズレてるのか言わない。
相変わらず、俺に対して、何も指摘できていない。
ただただ、文句を言うばかり。

> VMに関する全ての操作はやってられないとｗ。
VMは関係ないと言ってるのに、またVMの話を持ち出す。
全ての操作はやってられないなどと俺は言ってない。全部>>412の思い込み。

Ruby 製のVagrant の作者、HashiCorp のMitchell Hashimoto は、今世紀最大の起業家！
今は、Go 製のTerraform, Packer を作っている

彼が時代の中心だから、彼についていけばよい

他には、CircleCI, GitHub Actions

> おれはお前以外の人の書き込みからそれを学んで、心から納得したよ。

ようやくVMとDockerは使い方が違う。組み合わせて使うものと理解したようだが
お前のその書き込みは「お前から学んだということは認めたくない」と言うためだけの書き込みだなｗ

「組み合わせて使う」と書き込んでるのはたいてい俺だと思うけど、
俺以外の書き込みから学んだとは、一体どの書き込みから学んだんだろうか？
指摘してみてほしいところだが、ま、いえないよなぁｗ

>>415
CircleCIもGitHub ActionsもDockerベース

CircleCIは2.0でDockerベースに変わったし、
GitHub Actionsは以前はDockerfileが必須だった。

Packerも随分前からDockerイメージを作れる
（Packerはしばらく使ってないが、dockerのキャッシュ使うようになった？
正直これができないと、使い物にならないレベルなんだけど）

Terraformはすまんね。知らない。

世の中Dockerだらけｗ

VagrantはVirtualBoxがHyperVと共存できないから使うのやめたな。
Vagrant+HyperVという使い方ができるのは知ってるけど、
WSLができてWindowsがLinux同等に使えるようになったから実機で必要十分になった。
（Macはもとより実機で開発。もちろんDockerはWindowsでもMacでも使える。）
わざわざ開発マシン（実機）の中に、別の開発マシン（VM）を作るという二重構成にする必要がない。

Windowsでdocker自体を動かすのには
さすがに仮想マシンが必要
ホストOSもLinuxなら要らない

Docker for WindowsはLinux使うからHyper-Vが必要
WSL2もHyper-Vを利用する

WSL2は必要なHyper-V機能の一部がHome Editionにも配布されるので
Homeでも利用可能になる

仮想マシンを利用する方式に変更した事で
WSL1では動かなかったdockerもWSL2では使えるようになった

GAFAMは普通にDockerの考え方に順応して使ってるよな

最近出てきた訳でもない
登場してかなり経つ安定した技術なのに
まだ全く使ってないというのは流石に頭硬すぎ

GoogleはDockerが登場する前からコンテナ使ってたらしいしな
そういう所は今、一日に何十回（何百回？）もデプロイしてる。

古いやり方、多くても一ヶ月に一回、一週間前までにデプロイ計画立てて
サービス停止して深夜作業でデプロイするようなやり方では到底無理

顧客も賢くなってきてるから、丁寧にやってるから遅いんですよとかいう
言い訳はもう通じなくなってる。

みんながコンテナ使ってる中、あなたはコンテナ使わずに
同じぐらいの速度で開発ができますか？ってことだよ。

オフラインで使う組み込み系だと開発環境構築をちょっと楽するぐらいしか使い道ないわ

1. あるマシンに他ユーザーから隠しておきたい秘密情報のファイルがある
2. rootから隠すことはできない。
3. だから他ユーザーはrootになったりsudoが使えてはいけない。（自分はなって良い）
4. ユーザーがdockerを使えるということはrootの権限があるのと同じことである
（例えばボリュームを使えば、どのディレクトリも読み書きができる。）
5. dockerグループに追加してdockerコマンドの実行にsudoを不要にした所でそれは変わらない

以上のことから、あるマシンに他ユーザーから隠しておきたい秘密情報がある場合は
そのマシンで他にdockerが使えるユーザーがいてはならない

言い換えると、自分以外のdocker使用者がいる場合はそのマシンに秘密情報を置くことができないので
「秘密情報を置いて安全に管理してる」ならば「他に自分以外のdocker使用者がいない」を意味する

あってるよね？

dockerサーバーがリモートにある場合がよくわからないんだよな

マシンAとマシンBがあってそれぞれ所有者は異なる。
dockerサーバーがリモートにあって
マシンAとマシンBの両方から接続する

ん？ローカルのディレクトリってリモートマシンのボリュームにできるの？

マシンAがdockerサーバーでコンテナを作ったとして、
マシンBが同じdockerサーバーに接続したらそのコンテナは見えてしまうのか？
つまりdocker execで乗り込めてしまうのか？

もしできてしまったら、マシンAが渡したボリュームにたいして
マシンBから読み書きできてしまう？

どこかで実験したいな

ローカルをリモートのボリュームには通常できないでしょう。

>>425
NFSやらSMBやらで共有するという話ではなくて？

>>425
そのとおりでした。なんか勘違いしてましたね。

つまりはDockerサーバーにアクセスできるユーザーは
そのDockerサーバーが動いているマシンのroot権限を
持ってるのに等しいと理解しました。

だから例えばCIサービスとかを作るとして、複数の人が同じサーバーで
コンテナを動かす場合、Dockerに直接接続させてはならないわけですね。
ウェブインターフェースやRESTインターフェースをもたせて
そこで認証かけて、やれることも制限しろと

root持ってりゃdocker停止もアンインストールもOSシャットダウンもできるわけなので

docker composeがルート権限必要だから、AとBでコンテナ作れたらどちらでもなんでもありになる。

あれ非特権モードでも？