Docker Part6

テンプレとかいらんやろ

最近はマイクロ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倍楽だ

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

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

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

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

>>377
デーバーにデプロイの話はなんでしないの？
まだそこまで理解してないから？

訂正

>>377
サーバーにデプロイの話はなんでしないの？
まだそこまで理解してないから？

Docker Hub に、Tensorflow のイメージぐらい、誰か作って公開していないのか？

>>383
サーバーがなにか理解してないだろ
pcと同じものだぞ
自分の家のpcでwordpressを起動して公開するのもvpsに配置するのも同じ事
実機を使うかsshで遠隔操作するかの違いだけだろ
awsのサービスとかの話なら既出だし
なにが言いたいのかわからんw

>>385
俺はサーバーを知ってるんだぞ自慢はいいからさｗ
Dockerが解決してるデプロイの話を
なんでしないの？
デプロイの話をしない理由を言ってみ

そこらへんの話は仕事でやんのか趣味でやんのか違いっしょ
流石に仕事で >>385 みたいなこと言われんやろ 流石にね

>>387
pbxの設置から鯖の設置、基地局設備の設置までやってたけどな

Dockerを軽量版仮想マシンぐらいの理解でいるとこうなるという分かりやすい例だな

>>388
機材の搬入までしていたとか言いそうで草

ソフトウェアのデプロイの話をしろよ

苦労話をすればいいんやで？
サーバーのバージョンが古くてライブラリが古くて
それをインストールしようとしたけど、ビルドが出来なくてーとか
あるやろ？

今はDockerですっかりなくなってしまったがなｗｗｗ

デプロイとかしたことないから
デプロイの苦労話なんてないんだろｗ
Dockerのメリットがわからないやつは所詮素人ということがわかる

老害お得意の苦労話()

5chは老害の巣窟ですよ。
子供は他所で遊んだ方が良いですよ。

デプ＝ロイ
1721-1758

若い衆は他SNSメインですよ＾＾；
老害どうしで喧嘩してるだけ

wordpressが鯖の上で動くアプリって事すら知らないでデプロイの事を話せってw
知恵遅れにもほどがある
というかdockerすら使ったこと無いだろ
dockerの話一つもしてないのはお前だw

>>396
Dockerはデプロイに使う道具なんだが？
わかってないのか？

docker使ってて便利に感じるのは環境差分が吸収されることよねー

>>397
dockerってデプロイしないと使えないんだぞw
お前あれだろ、linux使ったことすらなくてwindows使ったら快適だったスレとかで暴れ回ってるうんこやろうだろ

もうDockerの話題やめようぜ

スレチだろこのスレはPartのスレだぞ

>>399
Dockerのデプロイと
開発したアプリのデプロイじゃ
全然難易度が違うだろ

linuxすら使ったこと無いんだろw
wordpressが起動した時点でホスト名登録してルーター設定したらサービスを提供できる状態って事だからな
普通のレンタル鯖にdockerを入れられるとでも妄想してみたんだろうけど、最初から言ってるがdockerインストールする必要があるから対応サーバーか自前の鯖やvpsを使う前提だ
dockerの話してる段階で最初からサーバーを提供する側の話なんだよ
鯖を立てるという意味が分かってたら絶対に言わない事言ってるからね