Docker Part6

テンプレとかいらんやろ

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

仮想マシンで動作させる 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みたらわかる

>>330
だからDockerは試行錯誤しても時間がかからないように
高速にビルドができるようにレイヤーでキャッシュされてる
ビルドするのにやっていることを固める必要がない
試行錯誤をビルドして行えばいいだけ

つまり不思議システムってことか

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

>>264
に書いただろ

山浦清透の動画内の、AWS の構成を見てみろ

開発中は、Docker 外の共有フォルダへbind しておけばよい

>>332
わかりやすいレスありがとうございました。
なるほど。

コンテナの「ルートディレクトリ」ごと
ホスト側に移してバインドしておいておけば、
そのコンテナで試行錯誤してもコンテナ自体は太りませんね。
必要があれば、変更のきりのよいところで、
ホストに置いている「ルートディレクトリ」ごとバックアップ取ればいいのかもしれない。

というのは、yumとか、外部から落としてきたtarをコンテナ内で使うと、
どのディレクトリに変更が生じるかわからないので、
いっそのことその「ルートディレクトリ」ごとホストに置いてバインドすればいいと思った次第です。

buildのコマンドで「ルートディレクトリ」全体をコンテナにコピーすればいいわけですね。

最後のところは、目からうろこです。
というのはいちいち設定内容をコマンド化（テキスト化）しなければならないと思っていたからです。

ひどいバッドノウハウの誕生を目撃した

>>332はルートディレクトリ以下全部なんて意図してなかろうに

ルートディレクトリでやってみたらいいとおもうよ
パーミッションの問題もあるしchroot環境構築するくらいの難易度で挫折するだろうけど
そこから学べることもある

頑なにテキスト化したくないってことは、buildでステップ的に構築しなくていいんでしょ
ならコンテナ内でvi編集でもyum installでもしたものをexportしてイメージとして使えばいいんじゃないの

1から作り直すことはできないけど、いらないんだろうし

だからコンテナは仮想マシンじゃないと何度も言う必要があるわけだよ
わかった？

月数百円程度でもいいのでplay with dockerみたいにさくっと試せるサイトないかな

なんで自分のマシンに入れないの？

ん？自分のマシンにも入れてるけど？

自分のマシンで試せばいいじゃんDockerなんだから

Dockerなのにそんなサービス欲しい理由が分からない

それはそんなサービス作ったエンジニアかだれかに言えよｗ

>>342
お金はらうなら
VPSかりて、リモート接続できるDocker環境つくればいい

Google Cloud ShellとかGCEの無料インスタンスで似たようなこと出来るんじゃね

docker machineの勉強をしようと思ってネット上の記事を色々読んでいたのですが
公式サイトに飛んだら
Docker Machine has been deprecated. Please use Docker Desktop instead.
とありました
Docker Machineを使うとAWSにDockerホストを展開するようなこともできたようですが
そういうこともDocker Desktopでできるんですか？
何か機能的に重ならない気がするのですが、どうなのでしょうか

Dockerは仮想マシンじゃない

アプリを配布するためのコンテナで
一般的には仮想マシンと一緒に使うもの

WindowsやMacの人はdockerデスクトップより
AWSのlightsailとか安いサーバでdocker-ce入れた方が
色々捗るんじゃ無いかと思う

何も使い勝っては変わらんのだが？

>>350
AWSに展開するならECSかEKSを使用するので、実行環境でDockerコマンドを直接使用することはない
というかDockerエンジン自体もほとんど使用されなくなっている

Dockerはプレハブハウス
VMwareはモデルハウス

モデルハウスの中にプレハブハウス入れるのか？
入れないだろ

例えはやめとけ

分かってないのバレるぞｗｗ

空き地（物理マシン）を借り切って、そこを小さな区画（仮想マシン）切り分けて

そのスペースに在来工法（環境設定）で家を建てるよりも
システム建築（コンテナ）で家を建てた方が早いって感じかな

システム建築と在来工法の違いはこちらｗ
https://www.systematization-building.com/comparison/

>>356
なんで混ぜるんだよｗ
Dockerってプレハブっていうか、工事現場にあるコンテナハウス？みたいなイメージあるんだよな
どこの現場でも速攻で事務所や休憩室になったりとかさ

対してVMは建売みたいに建てては売って(処分して)の繰り返しみたいな感じ

家の中に家を立てるのがVM
家の中にプレハブ置くのがDocker

>>359
> 対してVMは建売みたいに建てては売って(処分して)の繰り返しみたいな感じ

だからVMの中にプレハブを建てては売って(処分して)の繰り返えすんだろ？

ん？まさかVMって設定済みVMイメージの話をしてるのか？

設定済みVMイメージをどうやって作る？
それが大変だからDockerを使うってわかってる？

アホしかいねえ

例え話ってのは有用な時もあるんだけど
「自分が対象を明確に理解している時」に限定しないと
知ったか同士が例え話に例え話返し始めると
収拾つかなくなるよ

桃太郎というのは、例えば鬼のようなものである

鬼というのは、牙が生えていて、上半身裸
しましまのパンツを履いていて、金棒を持っている
悪いやつのことである

なぁ・・・もう疲れた・・・
何をどうやってもoverlay2の配下にデータが保存されるんだが・・・俺は何のために16TBのHDDを買ったんだ・・・もぅ疲れた寝る...zzzZZZ

あっ、言い忘れてたよ・・・誰かタスケテ！！

何をどうやったかを言わなきゃ誰もなんもできねーよ
そうゆうとこだろお前が失敗してんのは

>>368
説明できん・・・のだ

イメージなりボリュームなりをリムーバブルメディアに置きたいんじゃないの

Macだと悩まないのでWindowsなら
ジャンクションつかえばかいけつする

いやさ全録サーバー構築してんだが・・・
SSDの方にLinuxとDockerとコンテナ入れてさ、録画したファイルをHDDの方に保存したかったんだけど・・・どこをどうしてもoverlay2の配下に保存されるんよ・・・

これが昨夜までの状態・・・

で、今帰ってきてLinuxから入れ直したらできたわ！どこが悪かったのか謎のままだが動けばオッケー
まずは地上波全録して何日分録り溜めできるか試さなきゃ

ノシ

きっとお化・・・霊の仕業だと思う

先にコンテナがマウントしたディレクトリかその上位に後からHDDマウントしようとしてnot emptyになってたんじゃないの

ローカル上で動かすとバリ速い処理があるんだけども、EKSで動かすもCPU(limitつけてないのに）使い切ってくれない

何の設定が悪いんだか教えてくれだれか
たすけて

ストレージとかが遅いんやろ？

wordpressをpullして起動するだけでとりあえず使える状態になるのはしびれたけどそれ以上のメリットあんのかって気はするよな
Tensorflowでgpu使うのに便利だって書籍に書いてたからやってみたら必要なものを入れる度にリビルドしろってアホかと
ローカルに入れた方が100倍楽だ

じゃけんローカルに入れたやつを他のサーバーに移動させようや

アホやな
一生レンタルサーバー契約してろ

最初から全部入れとけっていう

でも実際こういうやついるからな 一緒に仕事したくないわ