Docker Part4

Linuxが持つコンテナ技術を使った、仮想マシン必要ないアプリケーション仮想化技術で
アプリケーションのデプロイが用意になります

Docker（アプリ仮想化）は仮想マシンと併用して使うことで最も効果を発揮し
開発・テストで使ったDockerイメージと全く同じものを本番環境で使えます
さらにWindowsとmacOSでも同じDockerイメージが動きます。
（Linuxは仮想マシンが不要ですが、WindowsとmacOSは仮想マシン技術を併用して実現しています。）

Dockerイメージ（Dockerfile）はアプリケーション開発者が作成します
動かすのに必要なもの全てがDockerイメージに含まれるので
インフラ担当者はそれを動かすだけ、本来のインフラの作業に集中できるようになります

Dockerは主にウェブ業界でサービスのデプロイの必須技術になりました
情報共有しましょう

http://www.docker.io/

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


注意　同じコンテナ技術を使うが異なるアプローチで仮想マシンの
代替を目指しているのがLXC。目的が全く異なるので注意
LXC(Linux Containers)
https://mao.5ch.net/test/read.cgi/linux/1330826939/

Circle CIとかGitHub ActionsとかのSaaSは
仮想マシンは同じIPを再利用する事ある？
同じユーザー扱いになってCIが急に失敗するようになりそう

レジストリのミラー作るのって
なんか難しそう

>>70
レジストリをメンテするぐらいなら金払うよ
たった月5ドルだろ？

>>71
別のユーザーによるpullでCIがこける可能性があるんだよな
でもそれはCIサービス側が対応する問題になるだろう
その対応の内容には安定したpullがしたければ
金払えっていうのも含まれるけどｗ

ちなみにオープンソースでツール公開してるんだけど、この間から
おそらく誰かがCIに組み込んだようでGitHubのGit Clone数が跳ね上がった
その数が大体1日500〜600cloneで、ユニーククローン数が300〜400clone
つまりGitHub側から見れば1日300〜400人が来て2回pullしてるように見えてる

このデータから一概に言えるわけじゃないけど、同じIPアドレスを使われる可能性は低いと思う
CI実行するたびにクラウドの仮想マシン作り直してるだろうし、クラウドの仮想マシンは
固定にしない限り作り直せば変わるわけで、問題が発生することは殆どないと考えてる

>>68
Docker社はずっと大赤字だろうけど、GitHub のようにプラットフォームとして成長していればいずれエンプラで黒字化するだろうという目論見だったのが、
KubeやECS等にエコシステムを乗っ取られエンプラ事業が大失敗に終わったことで完全に収益化の望みが断たれた
Docker Hubはプラットフォームといえども所詮はいくらでも替えのきくストレージに過ぎず、タダ乗りベンダー連中との間の差別化要因も乏しいためGitHubのような赤字を余裕で帳消しにするレベルの大型買収にも期待できない
もう焼畑しかないというわけだ

ふーん
Docker終わったな
これからはpodmanが勝つるか

Dockerがエンプラで黒字なんて無理だろ。
そもそも本番機で使えるエコシステムがECSであれEKSであれ他社の製品だし。
しかも本命は不在だし。
問題がはっきりしているのに何でこの分野でDocker社は何も提供しないの？
個人的にはECSであれEKSであれ下で動くインスタンス（VM)がサービスの前面に
出てきている時点でDockerは本番機には使いたくない。
VM管理とコンテナ管理の二度手間以外の何物でもないからね。
アマゾンはよく理解してる様でAWS Fargateでインスタンス隠しているけど、普及しているかどうかは知らない。
Docker社とも関係ない

何を言ってんだ
ホスト管理がいやだからクラウドのコンテナサービを使うんだろうが

dockerを使わないと逆にインスタンス管理が大変になると思うが

また仮想マシンイメージ最強おじさんの登場？

>>77
https://vmware-juku.jp/whatsvm/containers-benefits-why-kubernetes/2/

>Kubernetesは外部のOSSと連携することによってNATを経由することなく
>別のホストのコンテナ同士の通信を実現しています。
>OSSを利用する場合のいくつか選択肢がありますが、
>flannelを採用した場合はオーバーレイによるカプセリングを行うことで、
>従来の仮想マシンのようにIPアドレスを割り当てることが出来るようになります。

こういう単語が出ている時点でホストの管理もしなければならないのは明かだろ。
AWS Fargateで「ホスト」と言う単語が一切なくなるのなら、標準になるかもしれないけど
そうなるとコンテナランタイムがdockerである必要もない。

dockerを採用するとhost machineの管理が単純化されるので全体としての管理が楽になるということですね

>>80
> こういう単語が出ている時点でホストの管理もしなければならないのは明かだろ。

どういう理屈？

1. Kubernetesは別ホストと通信できます
2. しかもホストを管理しなくていいです

こういう話だよね？
どこからホストを管理しなければならないなんて話が出てきたの？

>>82
いやいや意味が分からない。
ホストの管理をしなくていい→「ホスト」と言う単語は出てこない。
でなければならないって話だが。

何でDockerだとホストの管理をする必要が無いと思うの？

クラウドだから管理不要

>>84
それはDockerじゃなくても同じだねｗ。

最初からそう言ってる
いったいどっからホストの管理が必要なんて話になったんだ？

いやもう日本語通じない通じないｗ
このトピずーとそうだけどｗ
>>77 ホスト管理がいやだからクラウドのコンテナサービを使う
>>78 インスタンス管理が大変
>>84 クラウドだからホストは管理不要ｗ←Now!

>>83
お前がホストって言葉を知らんだけじゃね？ｗ

わかりやすくパソコンにしようか？ｗ
息子がやってくれるからパソコンの管理はしなくていい
パソコンの管理をしなくていいが、パソコンという単語はでてくる。
例えば「パソコンを使う」「パソコンの電源を入れる」とかね

「（ホストの）管理しない」という話と「（ホストという）単語が出てこない」には
まったく繋がりがない

ホストの管理をしなくても、ホストという単語は出てくる

>>83
> 何でDockerだとホストの管理をする必要が無いと思うの？

Kubernetesだからホストの管理をする必要がないって話だろ
話をすり替えんなって

また発狂してる

Kubernetesはノードを意識した細かい制御ができすぎてな
ホストに強く依存した変なオーバーエンジニアリングをやりだす問題児が必ず出てくる
ECSより遥かにホストを意識してるわ

>>88
そんなレベルの話をするなよ初心者くんｗ
君の言う「パソコン」＝物理サーバは
完全に抽象化されててこのスレ内では全くでないだろｗ
Dockerの中で「ホスト」と言っているのはDockerが動く基盤であってそれが物理サーバであるかVMであるかは問わない。
非常に多くの場合はVMであり、それは「インスタンス」と言う名前で出ている。
つまりこの文脈ではホスト＝インスタンスって事
で何でk8sだからホスト管理しなくて良いの？

https://knowledge.sakura.ad.jp/3681/

例えば、上記の構成で本番機を作ったとして、192.168.0.50が死んだらどうするの？
「ホスト管理しなくていい」と言っているのは生存管理すら必要ないと言っているんだよね？

>>92
> 例えば、上記の構成で本番機を作ったとして、192.168.0.50が死んだらどうするの？

ああ、おまえ、GKEとかEKSというサービスを知らんのかｗ
上記の構成を作って"管理"するのはクラウドサービス側なんで
”お前がやらなければいけないと思ってること”を全部クラウドサービス側がやってくれるんだよ

>>93
いやマジ君の言っている（言わんとする事）の意味がつかめないんだがｗ
君の説明はどうでも良いよ。君の行動を話してくれ。
192.168.0.50が死んだとしよう、君はどうする？

お前らよくこんなニッチなものでいつまでも言い争いできるな
素直に感心するわ

>>94
サーバーの管理って何のことかわかってる？
サーバーが死んだら新しいインスタンス起動して自動的に再起動やろ
やらなくていいのはサーバーの管理だってわかってる？

FargateってEBSはマウント出来ないよな
データベースとかはFargateで動かせないね

EFSとか言うネットワークファイルシステムはマウント出来るが
複数マシンで同期を取るために速度は遅い

コンテナに確保するリソースは0.25vCPU、0.5GB未満は選択出来ないので
これ未満の能力しかいらない場合は
EC2に詰め込んだほうが安い
Fargate自体が同等のEC2と比べると少し高い

Fargateはサーバーレスと言っても
管理の手間が少ないだけでサーバーは存在するので
セキュリティパッチを当てるためにサービスの再起動が必要な場合はある

イメージのマージ機能はいつになったらサポートされんだ
devcontainer作るときいちいちインストール方法調べてDockerfile書くの不便なんだが

インストール方法？
自分で開発したアプリのインストール方法もわからんのか？

いや他人の作ったものも使うだろ

そりゃチームの人が作ったら他人だろうけどそういう話じゃないだろｗ

いやいやそうじゃなくてオープンソースのツールとかあるだろ
ネット遮断でもしてんのかお前んとこ

Dockerfileも拾えよ

>>102
オープンソースのものを自分でDockerfile作る意味は？
殆どのものは公式が用意してるでしょ

>>104
公式サポートない物もいくらでもある
それに組み合わせて使えないからマージしたいときは自分で作らなきゃならん
なんでこんな基本的なこと説明してやらんといかんのだ？

いや、自分で「マージしたDockerfile」作れよ
それが自動でできなくてゴネてるの？

めんどくせぇ

go製ツールならバイナリ落としてくればすぐ動くが

Pvthonとかのスクリプト言語を使う系や
C/C++で書かれている物はそうも行かない

パッケージマネージャにあれば良いが
あっても古い、このパッケージもインストール必要とか面倒

glibc使ってるC/C++製ツールで動的リンクしてたら
alpineにそのまま持って行っても動かない
muslで再コンパイルするか
イメージサイズの肥大化を覚悟でglibcを入れる必要がある

OSに最初から入ってるツールの扱いはどうするのか？とか考えたら
自動的にマージできるとか思うわけない
Dockerからしたら全てただのファイルであり
依存関係も把握してないし区別もしない

結局のところ必要だったのはdockerじゃなくてより賢いパッケージマネージャだったんだよな
方向性としてはsnapなどのほうが正しかった

賢いパッケージマネージャよりdockerが便利

>>105
> それに組み合わせて使えないからマージしたいときは自分で作らなきゃならん
docker-compose使えよ

１つのコンテナに複数のサービスを入れ込もうとしているからそうなるんやで？
ベストプラクティス通り1コンテナ1サービスにすれば
既存のものをそのままつかえるのに

ベストプラクティスから外れることを自分でしておいて
自分が苦労してるのって間抜けじゃねーか？ｗ

>>110
Dockerはパッケージマネージャーが対応してないような
自分（自社）で開発したアプリケーションを使って
自分でサービスを運営するためのパッケージマネージャーです
開発者向けのツールです。

snapはアプリ開発者がエンドユーザーにアプリケーションを
提供するためのもの。用途が全く違います。

apacheのバーチャルホストで20個のサイトを運営するのと
1つのイメージを使って1コンテナ1サイトを作るのでは
どっちがメモリとCPU使用率が高いですか？

メモリとCPU使用率が重要なら、
1つのイメージを使って1コンテナ20サイトを作れば？

1コンテナ1サイトって発想が出るのもやっぱりいつもの
Dockerを仮想マシンの代わりだと思ってるからなんだろうか？

Dockerはアプリの代わりと考えれば、この場合apacheだとわかる
１つのapacheアプリでバーチャルホストをするのであれば
Dockerの1つのapacheアプリでバーチャルホストをすればいいだけ

そのバーチャルホストの設定を予め終わらせておいた
カスタマイズ済みapacheを簡単にデプロできるのが
Dockerのメリットなわけで

1サイトをバックエンドとフロントエンドとDBに分けても良いよ？

>>112
アホか
何でもかんでもサービスにしたら効率が悪いこともある

何か変なのがいる。この後どうなるか楽しみ。

メインの言語でwebアプリを作って内部で別言語製のCLIツールを呼び出すようなシステム
業務システムなら普通にあるよなあ

別言語でapi鯖構築してメイン言語と別言語の2コンテナ構成にするって手もないこたないけど
そのためにワザワザ別言語とそのweb apiフレームワークを習得するのはコスパ悪いだろ

こういうときは1つのコンテナに複数の言語ランタイムやパッケージをまとめちゃって素直にサブプロセス呼んだほうが製造コスパがいい

んでそういうときに公式イメージのマージができたら便利なんだがサポートされてないからDockerfileをワザワザ書かなきゃならん
コンテナを分離する間抜けなアイデアよりは遥かに楽だけどそれでもDockerfileを書く手間は残る

>>112
ベストプラクティスは1コンテナ1責務だ

素人は1コンテナ1プロセスと間違って覚える
脱初心者を目指してるぐらいのレベルだと1コンテナ1サービスとか言い始める

docker-in-dockerとかdocker-outside-of- dockerをやれば良いんじゃね？
セキュリティについては知らん

Dockerコンテナ内からDockerを使うことについて
https://esakat.github.io/esakat-blog/posts/docker-in-docker/

この明後日の方向に突っ走る感じ

Dockerだけで云々言っている人は、
オーケストレーションまで頭がまわらないだろうし、
どないしようもないと思う。
CRIだけの世界でせいぜいがんばってください。

COPY --from=some/image /source/path /dest/path

Docddkerfileにこれを書いておけば
some/imageという既存Dockerイメージからファイルをコピー出来るぞ

依存関係が色々あって何をコピーしたいかわからない場合は知らん

マージ君は自動でやってほしいんだからそんなもんお呼びでないだろう

>>125
マージには役に立たんわ
そもそも必要なファイルがどこにあるか探すのめんどくせぇーだろ

欲しいのはレイヤーをコピペする機能だよ
それかdocker最適化されたパッケージマネージャでもいいかな

俺たちが本当に欲しかったのってこれな

FROM alpine:latest

# ディストリ差異対応とか依存関係解決とか環境変数とかボリュームとかキャッシュクリアとかよしなにやってくれる素晴らしいdockerfile専用パッケージマネージャ
PACKAGE openjdk:11 somevendor/somepythonclitool:latest

COPY bin /myapp
ENTRYPOINT /myapp/entrypoint.sh

openjdkイメージとsomepythonclitoolイメージって形式でリリースしちゃったら再利用性が低すぎるんだわ

>>128
Dockerは○○専用に作るものなのに
それをなにに再利用するんだよｗ

>>129
世の中なんの外部依存関係もないピュアなアプリケーションだけじゃない
そしてすべての外部依存関係がネットワークを通じて呼び出せるエンドポイントを持っているわけじゃない
こんな基本的なことをなんで説明しなきゃわからないんだ

「よしなに」が仕様のツール誰が作るの
トラブったら>>128みたいなのに文句言われるんだろ

>>131
docker公式かツールベンダが作るんだよ当たり前だろ

>>130
反論に全くなってないけど、だから何？

>>133
うーんこの理解力

ほらな、説明できない（笑）
言ってることが不明瞭の場合は聞き返してみるに限るね

はぁ…┐(´д｀)┌ﾔﾚﾔﾚ
>>130だから同じイメージに複数のパッケージを入れて環境変数やボリューム設定をするというユースケースが当たり前のように出てくる
そのためにはimageではなくパッケージって単位で再利用できねーと非効率的なんだよ
わかったかなボウヤ

>>136
主張を繰り返せって言ってるんじゃなくて
主張の理由を言えって言ってんの
ほんと会話ができんやつだなｗ

>>137
これがdockefile専用パッケージマネージャが必要な理由に見えないならもう話にならんわ
会話が通じないレベルの差があるってことだ

お前が言ってるのは、ユースケースと主張だけ
理由を言ってない

>>139
>>136

>>139
>>130

「同じイメージに複数のパッケージを入れて環境変数やボリューム設定をするというユースケース」
これはユースケース

「imageではなくパッケージって単位で再利用できねーと非効率的」
これは主張

「なぜなら、・・・・」
これが理由

「世の中なんの外部依存関係もないピュアなアプリケーションだけじゃない
そしてすべての外部依存関係がネットワークを通じて呼び出せるエンドポイントを持っているわけじゃない」
これは事実

「こういう場合に、・・・」
これが理由

>>142
>>141

>>144
>>143

理由をさっさと書きましょう

>>145
書いてある
あとはお前が理解するだけだ
理解する気がないなら無駄な問答が続くだけだからもうレスしなくていいよ
バイバイ

お前が言った言葉の全てに対して「それは理由じゃない」と説明したんだがｗ

>>147
間違った説明だから意味ない
理解する気がないならレスするな
2回目だよ

俺の説明のどこが間違っているか言える？ｗ
主張じゃなくて理由を言え

できたらコテ班付けてくれませんか
誰と誰の主張がぶつかってるのか日が変わるとわからないので

お前らはどのコンテナセキュリティスキャナ使ってるん？

>>149
いつものDocker原理主義者？
傍から見ていると、君が何故そんな下らない方向に持っていくのかスゲー疑問。
君が>>98に対する解決策を知っていれば教えれば良いだけ。知らなきゃ黙ってろよ。
俺はこの人がなぜ欲しががっているのか理解はできるよ。
解決策知らないから黙ってるけど。
確かにDockerのビルドはスタック上に積み上げてるから、その一部分だけ抜き取ってマージしたいとは思うわな。
何で「理由を言え、Dockerの本来の使い方はどうのこうの」の話を50レスも繰り返すの？

> 何で「理由を言え、Dockerの本来の使い方はどうのこうの」の話を50レスも繰り返すの？

理由を答えないからでは？

> 確かにDockerのビルドはスタック上に積み上げてるから、その一部分だけ抜き取ってマージしたいとは思うわな。

思わないな

同じファイルを使うとか同じポートを使うとか
事情がわかってないとイメージだけマージしてもしょうがのにな

>>153
理由を答えてるけど君が理解しないだけだよね？>>136はどこからどう読んでも
理由にしか見えないんだが？しかし別に理由はどうでも良いよ。
知ってるんなら答えろよ。知らないんなら黙っとけ。
スレの無駄だ。

そういう面倒なところを解決するためにスマートなDockerfile専用パッケージマネージャがあるといいなぁって話だろ

それは同一イメージ内でyumやaptを複数回使うのと何が違うの

>>156
じゃあ重要でない言葉をマスクしてみようか？

○○というユースケースが当たり前のように出てくる
そのためには○○できねーと非効率的なんだよ

見ての通り、理由が書いていない

環境変数の設定やインストールの手順がわからないことがあり、
イチイチ調べてDockerfile書かないといけないから、って話じゃなかったの？

>>158
Dockerfile専用パッケージマネージャは
理屈は不明、何をしてくれるかもわからないが
面倒なことを魔法のように解決してくれるのです

どうにかして〜って叫ぶだけで
何かが解決するのです

>>159
もう良いよｗお前は黙っとけ！ｗ

「できねーと非効率的なんだよ」

何でこれが理由だと読めないんだよ！アスペ野郎ｗ

サービス起動するときにあれこれ設定して起動するの面倒だなぁ
↓
Dockerfileの中で基本設定は全部済ませたで、必要最小限の
環境変数を渡すだけで起動可能だ、やったー
↓
Dockerfileの中で設定を済ませるの面倒だな
Dockerfile専用パッケージマネージャがあれば解決するはずだ！
↓
Dockerfile専用パッケージマネージャ
「インストールだけしておいたで、設定は全部Dockerの外でやるんやで」
↓
Docker使ってサービス起動するときにあれこれ設定して起動するの面倒だなぁ
（本末転倒）

>>162
じゃあ同じように"理由"を言うね

「imageではなくパッケージって単位で再利用できねーからこそ効率的なんだよ」
これがお前の言う"理由"です
理由を言ったので納得しますよね？ｗ

>>164
元の文章：
「imageではなくパッケージって単位で再利用できねーと非効率的なんだよ」

>これがお前の言う"理由"です

×「imageではなくパッケージって単位で再利用できねーからこそ効率的なんだよ」
○「imageではなくパッケージって単位で再利用できれば効率的なんだよ」

君はマジでここに粘着するより、病院に行ったほうが良い。

>>165
元の文章が間違ってるから
俺が正しい"理由"を言っただけですが？

俺はこれを"理由"とは認めてないが、
お前は"理由"だというのだから問題ないはずだが？

レス番飛ぶなぁ

>>166
なるほど、君は>>136に、

「俺はそれを理由として認めない、お前はエスパーになって、
　俺の納得いく理由を答えろ、それ以外は会話できると見なさない」

と、こう言いたかったのですね。

>>167
話の九割はDocker関係ないけどな！

>>168
納得がいくかどうかじゃなくて
"理由"そのものになってない。

もしその文章が本当に"理由"であれば、
頭に「なぜなら」や「その理由は」をくっつけて自然な文章になる

「なぜなら、imageではなくパッケージって単位で再利用できねーからこそ効率的なんだよ」
「その理由は、imageではなくパッケージって単位で再利用できねーからこそ効率的なんだよ」

自然な文章になってないので、これは理由ではない
これは単なる主張