Docker Part6

テンプレとかいらんやろ

>>232
オーバヘッドいってもベアメタル比較で9割以上の性能出るよ
最近の技術はすごいね 頭の中の知識アップデートしてったほうがいいよ！

そもそもクラウドは仮想マシンって前提でおかしいわ
勉強してからレスしろ

>>232
あごめん 読んでもらえば分かると思うけどプログラマー向け環境のことね開発環境ね

それでもサーバー側がリソース潤沢なら VM でもなんでもいいんじゃないのかなと思うよ
それこそプロジェクトによって予算は違うんだからね
以前は VM で動かしていたわけですし今でもそういうプロジェクトは存在するでしょう

>>233
それはKVMを使った場合の話
クラウドでKVMは使えないので遅い

どこをソースとしたかちゃんと書こうな

QEMU is very slow
https://forums.gentoo.org/viewtopic-t-1077552-start-0.html

Why VM QEMU is very slow ?
https://superuser.com/questions/1471510/why-vm-qemu-is-very-slow-still-a-newbie-here

>>235
サーバーがリソース贅沢って何いってんだ？
クラウドのことを何もわかってないな

クラウドというのは必要なリソースを必要な時に確保する
リソース＝コストだ。VMを使ったらその分多くのリソース＝コストが必要になる

サーバーだからって贅沢なリソースということにはならない
それはオンプレミスの世界の話
クラウドでは適切なリソースを使う

>>225
言ってないｗ

>>237
まあ多分同じ認識を持っているんだと思うよ
私もコンテナを利用するし

いくらでも財力があれば富豪的プログラミング的な事が出来るって事だよ
実際はないから多くのケースではコンテナを使うでしょう

で何の話からこんな風になったかって言うとDockerつかなきゃいけないのコンテナ使わなきゃいけないの開発者が？という話があって 別に VM でもいいんじゃないそれはて感じの流れだったんじゃないかな

コンテナはLinux上でVMがいらないんだよ
ネイティブに動く

>>236
視野が狭すぎるよ… よくもまあそんな自信満々に言えるよな
下請け客先常駐の人間か？

同情するわ

>>240
> ネイティブに動く
VMかてふつうは「ネイティブ」に動いとる。

>>249
動いてないよ。VMは仮想マシンの中のカーネル経由で動いてる
ホストOSのカーネルを使ってない。
カーネルを二重に使うことになるのがVM

>>244
それは「ネイティブ」に関係ない。
システムコールとかがラップされとるだけ。

>>245
システムコールがラップされてるから遅い
どちらにしろ遅いってちゃんと言うようｗ

qemuのゲストエージェントのインストールが大変というのを付け加えておこう

このスレには素の状態からオンプレにVMを建てて使う可哀想な人と、それ以外が居るから話がごちゃまぜになるね！

オンプレでもLinuxインストール＋DockerサーバーインストールでDockerコンテナが動く

仮想マシンだと何をするんだろうか
サーバーにqemuをインストールするところまでは変わらないが
ネットワークの設定は？ゲストエージェントはどうするのか？
メモリの調整などは？手元で作ったVMをサーバーでそのまま動かすには大変な作業が必要

その辺は自動化ツールがありますしおすし

Windows のコンテナはないんだから Windows のインフラを作りたいときには VM になるんじゃないですか選択肢が

その自動化ツールの名前が言えない時点で嘘

>>250
何度言っても理解できないようだから何度も言うしかないが
Dockerはインフラを作るものじゃない
アプリケーションをデプロイするものだ

あとWindowsのコンテナもあるし
無知も大概にしろ

>>252
コンテナがインフラそのものではないことは確かです
水道管はインフラですが水道管の中を流れる水はインフラではない あなたはそういうことが言いたいのではないでしょうか

Windows のコンテナについて無知ですみません これは VM を介在しないものなんでしょうか？

>>253
Dockerはアプリケーションを配布するもの
理解したか？ YES NO で答えよ

>>254
イエス

Windows のコンテナについて Vm を介在しないかはわからかいですか？

DockerスレなのにVMで戦ってるのなんなん？

データサイエンス分野だとライブラリ等を一式整えた軽量版仮想マシンみたいな感じで使うことも多い
デプロイ用途というのは単によく使われる一つの用途に過ぎない
別の使い方をしたければ好きに使えばいいだけのこと

こわく

ミス すまん

真っ赤なVMおじさんは下請けだからトイレに行かないと5chできない

かわいそうに

平日の真昼間から連投してる連中が何を偉そうに…ｗ
こういう連中の会話って、話のレベルがガタッと落ちるよな。

＞Dockerはアプリケーションを配布するもの
＞理解したか？ YES NO で答えよ

(笑)

また、いつもの、仮想OS とコンテナの違いが分からない、香具師が来ているのか

下の動画の4分ぐらいの所を見てみろ

AWS のECS on Fargate コンテナ内には、2つのアプリしか無いだろ。
永続化するようなOS の機能は、コンテナ外にあるだろ

山浦清透、8/20

【金額公開】Webサービスの運用費用、実際いくらかかっているか1円単位までお見せします
www.youtube.com/watch?v=nRO7pFCdM8E

AWS Solution Architect の資格を勉強しろ。
米国年収では、ついにRuby on Rails を越えて、1,400万円となった！

「こういうDockerの使い方をすると便利ですよ」というだけのことなのに「Dockerはこのように使わなければならない」と履き違えているのはわざとなのかな

単なるコンテナ型の仮想化技術であってそれ以上でもそれ以下でもないのに勝手にデプロイ専用ツール扱いされてもね

>>265
「DockerはVMと同じような使い方をして、VMと比べなければいけない」
と履き違えてるよねｗ

VMと比べてなんかいないんですよ

>>266
Dockerはデプロイ専用じゃなくて
デプロイ機能が強化されたツール

だから単なる仮想マシン技術では、デプロイには適していない
という話をしてるんだよ

Dockerがアプリのデプロイに適しているところはたくさんある
VMの構築なんか数ヶ月に一回やればいい程度だろうが
アプリだと一日に何回もやらないといけない
アプリ更新のたびにイメージの更新の必要がある

そういった超強力なツールが、VMとしても使えるからと言って
Dockerの一部でしかないVMだけの範囲で比較するのはフェアではない

CLIツールの配布手段としても使えるだろ
どんなディストリでもdocker runだけで手軽に使えて便利

>>2は勝手にWebアプリ限定にしてておかしい

>>262
その時間に退勤？かわいそうに

社内向けのちょっとした本番環境作るのにもDocker便利だから別に開発とか社外向けの本番サイトとか規模の差でしかないと思うけど…

>>270
これ嫌い
コマンドラインはシングルバイナリで頼むわ

dockerで個々につくったのが10個、20個同時に組み合わせて使うとか、普通の家庭用PCで大丈夫なの？

家庭用PCてなんや？ｗ
性能にこだわらなきゃなんでもええやないか。
用途次第。

>>274
Dockerは個々に作ったアプリを包むだけのラッパー

普通の家庭用PCで10個、20個のアプリを
お前は組み合わせて使ってるんだろ？
なら動くに決まってるだろ

仮想マシンじゃねーんだからさぁ
仮想化されたハードウェアをいくつも変換かまして
二重にカーネル経由してなんて無駄なことしてないの

Dockerはネイティブに動いてる

家庭用 PC って書いてあるから開発用途なんじゃね
Windows Mac の場合はネイティブに動作しないで乾癬仮想化かませてるんだよね？

いや、ネイティブ。
仮想マシンがあってもネイティブはネイティブ。

非ネイティブで実用的な速度になるわけないやろ。

え
mac → virtualbox → linux → docker
ちゃうの

オーバーヘッドは出てるんちゃう？cuiだから感じにくいだけで

オーバーヘッドとネイティブは関係ない。
別の話。

ネイティブの対義語って何なの？

仮想マシンで動作させる Windows をネイティブに動作する Windows と言いたいのかな

対するのは Windowsのシステムコールを再現しようとするwineなどのエミュレートソフトウェアかね

後述が非ネイティブだとすれば現実的な動作速度とは関係なくね？
>>278

>>279
仮想マシンだとアプリごとにOSイメージが必要となり
仮想マシンの起動が必要になり仮想マシンの数だけメモリが必要になる

DockerはLinuxだと、仮想マシンが0個
WindowsとmacOSだと、たった1個だけで
10個、20個のアプリを動かすことができる
もちろんそれぞれのアプリは隔離されている

>>281
エミュレーション？
でも、そんな簡単でもないなあ。

>>282
そういう環境としてのエミュレーションは、システムコールやAPIの差し替えとかラップとかフックとかやろ。
それだけなら、バイナリの動作自体はネイティブといえる。

何が言いたいかというと、こういう文脈でネイティブ云々は意味がないのでは、と。
オーバーヘッドの重さは、エミュレーションレイヤーのつくりによる。

>>283
その通りや
君の言うネイティブというのはLinuxの透過ファイルシステムと隔離機能を利用するという意味なのだね
それが例え仮想マシンの上で動作していても

>>285
Linuxだと仮想マシン上で動作してないから
ネイティブだって言ってんだろ
頭悪いのか？

>>286
上で仮想マシンがあってもネイティブはネイティブって書いとるの何やねん

勝手な「ネイティブ」

リンドウズでも動かせたら買うのになぁ

>>274
Windows 10, WSL2, Linux, Docker では、8GB メモリじゃキツイ。
最低16GBで、32GBが推奨

例えば、Ruby on Rails なら、

Windows側で、VSCode とブラウザでテストする。
Linux側で、Rails, Node.js、データベース

コンテナが10個とかなら、自動的にコンテナ数を増減する、Kubernetes(k8s)。
Dockerに付いてる

今は、ほとんどの企業がk8s

>>290
日本語でおk

>>290
ユーチューブで勉強した人？
それともしょうもないスクール生？

>>287
Linuxの上で仮想マシンを動かしてるわけじゃないという意味だよ
知らんの？DockerはLinuxの上で直接プログラムが動いている。

・Linux←仮想マシン←Linux←プログラム
プログラムはネイティブで動いていない

・Linux←プログラム
プログラムはネイティブで動いている

>>293
それは当然の認識で前提だった

そこから話が派生して他 OS の話になっていたのだよ流れをもう一度読んでもらえば分かると思うけど

コイツラ何で「コンテナは高機能なchroot」で済む話をダラダラくっちゃべってんの？

ぜんぜんちゃうからや。ｗ
あたりまえやけど。ｗ

chrootもDockerコンテナもOSのプロセス制御の拡張に乗っかってるだけ
活用具合がだんちだけど

chrootって分離してくれるのファイルシステムだけじゃね
イメージレジストリとかボリュームマウントとかの概念もないし

dockerはプロセス・ネットワーク分離とCPU・メモリのリソース制限も出来る

停止しない限り、マシンを再起動したらコンテナも再度立ち上がるプロセス管理機能もある

chrootとcgroupsだな

>>299
リソースの分離はDockerというかcgroupsとかnamespaceに依存した機能
Dockerだから出来るというわけじゃない

え、そこから教えなきゃいけないレヴェルなんか
ツイッタでイキイキしてる奴らの方が上じゃんｗ

最近はマイクロVMによって、仮想マシンとコンテナの境界は曖昧になりつつある
コンテナは分離技術としては不完全で、セキュリティ観点では全く当てにならない
だからVM立ち上げてその中でコンテナを動かすの

またそれか


アプリをデプロイするためにコンテナ作ったでー

分離技術は不完全、セキュリティでは〜

だから、アプリをデプロイするためのものだって言ってんだろ


仮想マシンの代わりとして使おうとしたり
セキュリティのために使おうとしたり
最初っからそんなもののために作ってねーよヴァーカ

>>303
そんなケースバイケースな話されても
セキュリティ要件上オンプレ且つVM不可な案件もあるんだよ
了見の狭い

シングルバイナリのがいいよね

>>306
RubyやPythonをシングルバイナリにできるならね

でも、まあ、仮想マシンみたいに、コンテナという単位で取り扱うことができるから、
内部動作はホストでネイティブで動作しているにせよ、便利だからそれでいい。

まだDスレでVMの話してんのか・・・

Dockerコンテナはそのままで内容を改変する度に、新しくイメージ化（コミット）しています。

縦がコンテナで同じものです。

□→◯イメージ１
↓
コンテナの内容変更
↓
□→◯イメージ２
↓
変更
↓
□

このようにするとき、変更の度合いに比べて、
イメージサイズが大きくなりすぎるのはなぜなのでしょうか。
簡単にサイズを最適化する方法はあるのでしょうか。

何をどう変更したのか書かれてませんが

docker commitは現在のイメージの上に現在のコンテナによる変更内容を差分としてレイヤを追加する
だからcommitするたびにイメージサイズは肥大化する
これ言うとまた荒れそうだけど、dockerを仮想マシンのように使ってはいけないと言われる大きな理由の一つだね

更新の都度buildで構築できるように組むのが一般的
もし動的な更新部分を外部のリポジトリ等から取得できないなら
マルチステージで旧イメージからコピーするとか

>>312
レスありがとうございます。

おっしゃっているのは、コンテナからイメージを作成して、
そのイメージから別のコンテナを作成し、また新たにイメージを作成する場合ですよね。
（ちがっていたらすみません）

□→◯→□→◯・・・


しかし、>>310のように、
同一コンテナから時系列でイメージを作成しているのですが、
コンテナの変更の割に、それらのイメージが大きく膨らむのです。

同一コンテナ上での変更だから、同一レイヤで更新が成されるはずです。
そうやってレイヤの更新の都度、そこからイメージをコミットしても、
無駄に大きくはならないだろうとにらんだのですが。

>>313
buidができるように設定を組めたらよいのですが、まだそこまでシステムが固まっていないんです。

>>314
あのな。お前のそのレスの内容から
Dockerの完全な初心者だってことバレバレなの

お前は知らない単語を聞いた時、その単語の意味から
こういうことだろ？と思い込んで突き進んでるだろ
思い込みを書き込むんじゃなくて
知らない単語をちゃんと調べてDockerを勉強しろ

システムが固まってないんじゃない
お前は>>313が言ってることがわからないだけだ

あーあー確信ついちゃった・・・発狂するぞｗ

○核心

>>317
おい馬鹿ヤメロｗ

>>318
ではではタメ口ならいい？

>>314
コンテナの変更って何したんだ？
commitでイメージに追加される新たなレイヤは元のイメージとの差分だから、
愚かにもdockerを仮想マシンのように使っているならログのローテーションやパッケージの更新などで常に元のイメージとの乖離は拡大し続け、
その乖離の分だけレイヤのサイズは増大する
事実を疑う愚かな悪癖を捨て、まずはそれだけの差分が実際に生じている事実を認め、その差分の内容をdocker diffなどで調べろ

まだシステムが固まってないんなら別に肥大化してていいんでは
fixしたらホスト側からCOPYしてbuildしたらいいだけ

>>310
> Dockerコンテナはそのままで内容を改変する度に、新しくイメージ化（コミット）しています。

そんな使い方はしてはいけません

作るのはイメージだけで、コンテナからイメージ作るとかしないんだわ
してはいけないって言っておこうか？
最終手段として用意してあるだけでdocker commitなんて全く使わない
それが必須な時点で使い方が間違っている

requirements.txtで独自ライブラリをgithubからインストールして
あとからライブラリ更新したとき
その更新は適用されない
適用させるにはまたゼロから（imageから）構築し直さなきゃいけない
って認識でいいでしょうか？

補足
＞requirements.txtで独自ライブラリ
Dockerfileからpip install requirement.txtです

Dockerは更新されたとか関知しないのでrebuild要

そういうときは更新検知用コンテナ入れるけどな

>>324
だからDockerfileでイメージのビルドが簡単にできるようになっていて
レイヤーのキャッシュで高速にリビルドが完了するようになってる

イメージは消してビルドし直すのは当たり前で
それはバイナリの実行コマンドを削除してビルドし直すのと同じこと

実行コマンド（イメージ）の中にデータを入れるな
データが入ってなければ、イメージの削除とリビルドも
何も気にすることがない作業だ

当初の質問から外れてしまっているのですが、
本質的な話だと思います。

ぜーーんぶ、設定に費やしたコマンドを明確に表して、buildせよっていうことですね。
それはつまり、コンテナの中でviでせっせと作成したスクリプトも全部、予め用意してbuildせよってことですよね。
でも、まだやろうと思っていることが試行錯誤で、固まっていないんですよ。

>>326-329
なるほど・・そういうものなんですね
まだよくわかっていませんが勉強してみます

>>330
Docker Hubなんかにあるベースイメージつくるなら最終的にDockerfileに全記載となるけど
試行錯誤中はcommitでも外部ボリュームマウントでもぜんぜんOK
アプリ開発なら特定のディレクトリしか使わないようにし(他には設定ファイルくらい)
開発中はディレクトリ全体をホストに置いてマウントするのが常套
buildではそのディレクトリ全体をCOPY(開発中はマウントで隠れる)
適当なプロジェクトのDockerfile, compose.yamlみたらわかる