Docker Part5

DockerはLinuxが持つコンテナ技術を使ったアプリケーション仮想化技術です。
アプリケーションを動かすために必要な各種ライブラリ等を一つのDockerイメージに
まとめることで、さまざまな環境へのデプロイが容易になります。
例えばWindowsやmacOSを使って開発・テストしたDockerイメージを
そのままクラウド上のLinuxの本番環境で使うことができます。

クラウド上の環境が仮想マシンであるため、Dockerは仮想マシンと併用して使うことが多いですが
仮想マシン技術とは無関係の技術です。実際Linux環境において仮想マシンは必須ではありません。
WindowsとmacOSでは仮想マシンを使いますが、これはOSがLinuxではないからです。

Dockerは主にアプリケーションを動かすために設計されているのでデータを保存するのには適していません。
データはDockerイメージの外部、ボリュームを使ってホスト環境に保存するかネットワーク通信で外部サーバーに保存します。
またDockerコンテナは一つのサービスを実行し、複数のサービスが必要な場合はdocker-composeやk8sなどを使って連携させます。
Dockerを仮想マシンの代替として、コンテナ内で複数のサービスを起動しようとすると困難が待ち受けています。
それはDockerの設計方針とあっていないからです。

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

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

http://www.docker.io/

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

注意　Dockerを仮想マシンの代替として使いたいと考えてる人は、DockerではなくLXCを使いましょう
LXC(Linux Containers)
https://mao.5ch.net/test/read.cgi/linux/1330826939/

>>179
ありがとうございます。それはつまり、

>3. デフォルトの設定ファイルをイメージ内に配置して、使用する側で上書きしてもらう

これでいいってことですかね？

>>180
それでいいです

設定ファイルの書き換えをスクリプトで行いたいユーザーのために、エントリーポイントにフックを仕掛けるとより親切

なるほど、ありがとうございました！

rktって開発中止されてたのか。

>>184
気づくの遅くね？

結局dockerがメジャーなままなのね

podmanとK8S

docker楽でいいね
docker-composeをアップすると自動でやってくれるレンタルサーバとかクラウドサーバないでっか？

Windows、Macはまだdockerが主流なんだっけ？

K8SがデファクトスタンダードだからDCでの運用ノウハウを探すの大変だよ
素直にK8Sを勉強したほううがいい
大変なのは最初だけ

1ノードしかない場合のそのへんの得失ってどうなんだろう。
サーバー1台だとオーバースペックというか無駄に複雑になるだけにも思うけど。

kubernetesは色々運用管理に必要なものが揃ってて便利だが
使わないならオーバーキルな気はする
k3sは知らんが、本家のKubernetesは重過ぎ

使うなら最初はマネージドで
コントローラーに追加費用要らない所も多い

GKEは高可用性無しなら1つだけ無料
AKSやLinodeは無料
DigitalOceanは無料だが日本のデータセンターが無い

EKSは未だに有料

最初はっていうかずっとマネージドでいいと思う
オンプレミスでK8S管理は辛いよ

Kubernetesは起動するだけでメモリ1GBを消費する
つまり最小構成のVMではかろうじて動くが
そのVMを実用的に使うことはできない

最初からそれだけのメモリをKubernetesに
与えてもいいぐらいの規模が前提となってる

k8sはYAMLの記述量が多過ぎなのも嫌われる一因

helmもYAMLとGoTemplateと言うやばい組み合わせのせいで汚い
kustomizeもなんかアレ

tankaとかkapitanならjsonnetで書ける
YAMLをテンプレートでやるより100倍いい

https://github.com/grafana/tanka
https://github.com/deepmind/kapitan

k0sってどうなの？

docker-composeが一番だ
k8sよりswarmのほうが完成度が高いのになぜ使わないんだろう？

複雑怪奇なYAMLベースのDSLを作らないでほしいね

*.hcl
わかりやすい

.hcl自体はわかりやすくても
それをもとに作られたDSLがなぁ

ところで質問。
docker-compose のサービスをいきなり docker run 相当で起動するんじゃなくて
docker create -> docker cp -> docker start みたいなことってできないのかな？
あるいは swarm や k8s だとどうだろう。

なるほど。ただ、podmanであってもdockerfileの置き換えには至ってない雰囲気。

軽くしようとすると途端に難易度が高くなるツールだ

Buildahというのがあるようだ。
どの程度の性能か謎ではあるが……。

>>201
docker-composeなら
ファイルはボリュームでマウントすれば良いし
イメージがshとかbashでのcommand実行に対応してれば何らかの初期化処理も可能だ
scratchイメージでsh入ってなかったら無理だが

Docker BuildKit: faster builds, new features, and now it’s stable
https://pythonspeed.com/articles/docker-buildkit/

直接そういうことができる機能は無いから別の手を考えないとならないということね。ありがとう。

docker-composeで独自モジュールをpipでいストールしたけど
その独自モジュールのソースを微妙に変更して、docker-composeやり直しても更新してくれない。。
docker-compose down --rmi all --volumes --remove-orphans
してもコンテナもイメージも残ったままなのがたぶん原因なんだろうけど・・
手動でポチポチ消すしかないのかなぁ

docker-compose build --no-cache

>>208
ちょっとだけ構築速度おそくなったけどできた！�dクス！

no cacheオプションだから遅くなるのは当然でしょ

メモ
docker image prune
で消えねえと思ったら-aオプションいるのね・・
docker image prune -a
消したくないやつは稼働させたままやったら
稼働してないやつだけ消えてめちゃくちゃ捗った
（稼働中のやつには無影響なのかはわからないけど）

できれば、pipでインストールする自作ライブラリの訂正部分だけ更新できるようにしたいけど
--no-cacheするかイメージもコンテナも全部消してから再ビルドしないと適用してくれない・・

非公開gitからクローン　→　python setup.py sdist → pip install ○○
みたいにDockerファイルのRUNでやってるのがだめなのかな

>>212
自作ライブラリをインストールした以降のイメージだけを削除したら。

ARGでタグかブランチを指定するんですよ

>>213
>>214
なるほやってみる�d

>>1
>Dockerを仮想マシンの代替として、コンテナ内で複数のサービスを起動しようとすると困難が待ち受けて

具体的に言うと？

hypervisord最強おじさんktkr

super...

>>216
困難は特にないよ

具体性0

面倒なだけで問題はないよね。
面倒という指標だとk8sは更に最初が面倒なわけで

dockerわかってないのにわかった風のおじさんが、僕には困難です、と書いただけだから気にせんでええ
次スレまでいったら、テンプレから削除していいよ

説明になってない

>>216
複数のサービスを起動する場合、systemdが一般に使われるが
systemdを使うのは大変

https://stackoverflow.com/questions/51979553/is-it-recommended-to-run-systemd-inside-docker-container

可能な限り、コンテナ内のsystemdは避けることをお勧めします。

Systemdは、ファイルシステムをマウントし、いくつかのカーネルパラメータを制御し、
プロセス出力をキャプチャするための独自の内部システムを持ち、システムスワップスペースを構成し、
巨大なページとPOSIXメッセージキューを構成し、プロセス間メッセージバスを開始し、
端末ごとのログインプロンプトを開始し、システムサービスのスワス。
これらの多くは、Dockerがあなたのために行うことです。
その他は、Dockerがデフォルトで防止するシステムレベルのコントロールです（正当な理由があります）。

通常、コンテナに1つのことを実行させたい場合があります。これには、複数の調整プロセスが必要になる場合がありますが、
通常、systemdがプロセスマネージャーを提供する以外のことを実行したくない場合があります。
systemdは非常に多くのホストレベルのパラメーターを変更するため--privileged、
Dockerの分離を破るような実行が必要になることがよくありますが、これは通常は悪い考えです。

質問で言うように、通常、コンテナーごとに1つの「ピース」を実行するのが最適と見なされます。
これができない場合は、DockerとUnixの両方の哲学において、
initプロセスに必要な最小限の処理を実行するsupervisordのような軽量プロセスマネージャーの方が適しています。

>>216
これとか読むといいかも。公式がVMじゃないと言ってる。

Containers are not VMs
https://www.docker.com/blog/containers-are-not-vms/

> しかし、これを言っても、VMに関する現在の考えやプロセスを適応させ、
> コンテナーに適用しようとしています。
>
> 「コンテナをバックアップするにはどうすればよいですか？」
> 「実行中のコンテナのパッチ管理戦略は何ですか？」
> 「アプリケーションサーバーはどこで実行されますか？」
>
> 私にとって、Dockerは仮想化テクノロジーではなく、アプリケーション配信テクノロジーで
> あることに気付いたとき、電球の瞬間が訪れました。


これとかも

So, You’re Saying Docker Isn’t A Virtual Machine???
https://derickbailey.com/2016/08/29/so-youre-saying-docker-isnt-a-virtual-machine/

A Docker container is not a virtual machine.
A Docker container is application virtualization.

複数のサービスを実行することは可能だが、推奨しないと書いてある。
そしてこの記事に書いてある複数のサービスを実行する方法を見ればわかるように
仮想マシンのように気軽にはできずコードを書く必要がある

Run multiple services in a container
https://docs.docker.com/config/containers/multi-service_container/

コンテナの主な実行プロセスは、ENTRYPOINTおよび/またはCMDの最後ですDockerfile。
一般に、コンテナごとに1つのサービスを使用して、関心のある領域を分離することをお勧めします。
そのサービスは複数のプロセスに分岐する可能性があります（たとえば、Apache Webサーバーが
複数のワーカープロセスを開始します）。複数のプロセスがあっても問題ありませんが、
Dockerを最大限に活用するには、1つのコンテナーがアプリケーション全体の複数の
側面を担当することを避けてください。ユーザー定義のネットワークと共有ボリュームを使用して、
複数のコンテナーを接続できます。

そもそもコンテナを仮想マシンの代替として使うケースはほぼないだろ。

1に書くような話ではないな

> Handling such processes this way is superior to using a full-fledged
> init process such as sysvinit, upstart, or systemd to handle process lifecycle within your container.

sysvinit, upstart, or systemd を使うよりも
自分でコンテナのメインプロセスを作ったほうがいい

たとえばnginxとphp-fpmを別コンテナにする気もないから自作シェルエントリポイントにしてる
俺はやらないがsupervisordで制御してもいいだろう

systemdまで入れるならlxcかkvmにするけど

つまりは仮想マシンであれば標準でsystemdなどが起動してるから
サービスを起動させるにはパッケージインストールして
ちょっと設定ファイルを書き換える程度の簡単な作業だが

Dockerでやる場合、systemdなどを使わずに
自分でスクリプト書いて起動と停止を制御しなきゃいかんのよ（Docker推奨の方法）

頑張ればsystemdを動かすことも出来るが、そのために --privileged オプションが
必要になるかもしれないし、その他の調整が必要になるかもしれない
何が必要かは起動するサービスによって違うので試行錯誤が必要になる
だからDockerはsystemdを使わずに自作スクリプトで制御することを推奨してる

systemdを使うぐらいならより軽量のsupervisordを使うほうがいい
もちろんパッケージインストールして終わりではなく
自分で設定ファイルを書く必要がある

😫マルチプロセスコンテナ否定派
・1つのサービスのために多数のコンテナイメージをリリース
・イメージ使用者に面倒くさいymlを書かせる

🤗マルチプロセスコンテナ肯定派
・1つのサービスのために1つのコンテナイメージをリリース
・Supervisor等の設定を開発側が書いて出荷するのでイメージ使用者はdocker runするだけ

じゃあちゃんと責任持って管理してね🤗

仮想マシンみたいなことしたかったらLXCでよくね？
しらんけど

・イメージ使用者に面倒くさいymlを書かせる
別に良くね？

>>233
仮想マシンみたいなことがしたいならシステムコンテナでいいと思うよ
単にマルチプロセスってだけならアプリケーションコンテナのほうがいい

「プロセス」「サービス」を意図的に混同して相手を貶める

>>234
良くない
負担を減らせるなら減らしたほうがいい
ホスピタリティの精神だよ
セルフサービスで全部やってねなんてのは二流だ

もちろん分散型のイメージを提供するなと言ってるわけじゃない
分散型をオプションとしてサポートするのも良い事だ

マルチプロセス派は配布して終わり！じゃなくてその後の運用まで考えてるのか？

>>238
運用もシングルコンテナのほうが簡単でしょ

>>239
なんで？

>>240
1つの物管理するのと多数の物を管理するのじゃ前者のほうがかんたんだ
常識的に考えればいい

複数サービスのログ管理はどうする？
まさかファイル出力にしてlogrotatedとかも突っ込むの？
それかコンテナ自体のログを複数のサービスからのログが流れてる状態にするの？

ログ管理のSaaSへログの集約がしたくなったらどうする？
エージェントもコンテナに突っ込むのか？

複数コンテナで
ログは全部コンテナのログにしておけば
dockerのログだけローテーションすれば済むじゃん
ロギングドライバ変えたり
ログ転送のエージェントは別コンテナにしたりできる

個別に更新するのだから、バラバラの方が管理しやすい。負荷分散も容易。

一箇所にまとめるのは滅多に変えない時だけね。

そんなもんそれぞれのプロセスがstderrに流すだけ
あとはホスト側でどうにでも

纏めた方が楽という人は、k8sのメリット関連の文献を読んだほうが良い。基本的に個人でも同じ。
依存関係が原因のレガシー化を防ぐには、細かく分けて疎結合というのがマイクロサービスの基本。

supervisord管理下のプロセスの死活監視やリソース使用の監視はどうするんだ？
同じイメージに監視ツールのエージェント突っ込むのか？
もうめちゃめちゃ複雑だし、イメージに汎用性がない
複数アプリがあったら全部これやれってアプデも対応しろって言うの？面倒過ぎ

普通にマルチコンテナで動いてたら
Dockerコンテナが動いてるかどうかや、コンテナのCPU、メモリ使用量などの監視で済む
監視ツール変えたくなってもアプリのイメージをいじる必要がない

アプリ固有のメトリクスを記録監視するならアプリイメージに対応必要だが、
これらの基本的なメトリクスを取りたいだけなら対応不要

>>244
ホスト側！？
結局分けるんじゃん

じゃあsupervisordもやめたら良くね？

>>242
コンテナのログとして出せばいいだけ

>>243
実は他者製のクラスタを個別に更新することは少ない

>>245
k8sは大規模すぎるので導入障壁が大きい
1コンテナシステムは小規模から手軽に開始できる

>>245
なんでもかんでもバラす必要性はない
Spotifyの事例にもあるようにミクロサービスからモジュラーモノリスに回帰した大規模サービスもある

>>246
昔からやってる事をやるだけ
開発側にばノウハウが大量にあるのでなにも苦にならない
重要なことは利用者側が楽になること

弊社の勤怠管理システムはIE限定です！

一箇所にまとめるとこうになる。

まあ、慣れてるからそれが良いという人はご自由にどうぞかな

>>252
>開発側にばノウハウが大量にあるのでなにも苦にならない
よくわかんない

>>253
意味不明な論点ずらし乙

>>254
わかる

仕事に戻るからまた後でな

>>251
Spotifyにsupervisord最強おじさんはいない

>>247
supervisord使うなんて一言も言ってないけど
コンテナ別にログ分けるのはホスト側のrsyslogdで十分

>>255
まとめるとレガシー化しやすいってこと。

1コンテナマルチプロセスにしろってsupervisordにしろってことだろ
そんな事やったらサービス単位で更新できないし、
supervisordの面倒見るのもいやだな

Docker自体がある意味supervisordみたいな物だから
supervisord in supervisordするって事じゃん？

「プロセス」「サービス」を意図的に混同して話をややこしくする

nginxとphp-fpmを別コンテナにするメリットがあるのかね

>>251
Shopifyじゃなくて？

>>262
まあマルチプロセスなベースイメージをそうと知らないまま使っている阿呆も中にはいるだろうね

バカには疎結合なんか、分からんから、ほっとけほっとけって

>>261
オーケストレーションの手間暇を利用者側に押し付けるか、開発側でやってあげるかの違い
小規模のスタートアップなら全部開発側に丸投げしてdocker runするだけのほうがかんたんだ

>>265
疎結合と一言で言っても色々ある

ミクロサービスは疎結合の代表だが
別にミクロサービスじゃなきゃ疎結合できないわけじゃない

さっきも言ったように
サービスとしてはモノリスでもコードレベルで高度にモジュール化することで疎結合を達成するモジュラーモノリスのような考え方もある

コンテナは1つでも内部のサービスが疎結合ならなんの問題もないのだ

>>263
そうだっけ？正確にはググって

で、この1コンテナ、マルチプロセス(サービス)で成功してる代表的なコンテナがGitLabね
薄っぺらい表面的な知識しかない連中と違って、流石にGitLabのエンジニア達は深く理解してる
杓子定規にコンテナを分ける必要はない、背景が不明な不特定多数に配布するなら、むしろバンドルしたほうがいい、と理解してる

GitLabはセルフホスティング対応が大前提だからそうなってるんだよ
シングルインスタンスなSaaSとは別次元の話

つまり利用者側からは1コンテナのほうがいいってことだ

基本は1コンテナなんだよ
ちゃんと利用者のことを考えてるならな
で厳しい要件満たすために、分散管理したい連中のために、いちおうバラ売りコンテナも用意しとく
それがベストプラクティス
さいしょっから分散管理のみサポートします、なあんて、怠惰もいいとこだ

それはご苦労なこった
俺は怠惰だからメインのコンテナ以外はありあわせのイメージ使うぜ

自社以外に誰も求めてないマイナーサービスは最初からバラ売りでもいい

複数のサービスを一つのコンテナにまとめたほうがいいって言ってるやつは

複数のサービスが一つのコンテナになってるから
"使うのが楽"って言ってるんだよ。
作るのが大変の否定になってない

>>1は作るのが大変と言っている

> Dockerを仮想マシンの代替として、コンテナ内で複数のサービスを起動しようとすると困難が待ち受けています。


Dockerを使ってると言いつつ、自分でDockerfileもyamlも書かずに
ただ誰かが作ったものを使うだけのやつは、Dockerを使ってるとは言えない
んで、使ってるだけのやつが、使うのが楽と言ってる

複数のサービスを一つのコンテナに入れるのがどれだけ大変かわかってない
だって自分で作ってないんだもの

いやいや、作るのもめちゃくちゃ簡単だぞ？
Supervisorとか使うだけ
Dockerfileも既存のchefなんかが、殆どそのまま使える

コンテナを分けないことで、お互いのサービスの提供するコマンドラインツールを使いやすくなるのも、便利だな

ある古いサービスAの、管理者用のコマンドラインがあるんだが、、、
これはサービスAをインストールしたマシンで、ローカル実行する必要があった
もちろん、RPCなどという気の利いたものは、ない
開発者からすると、SSHがあればいいでしょ？みたいな気持ちだったんだろうな

そして、サービスBからこのコマンドラインを実行したい、と、なったわけだ

もし、サービスAとサービスBのコンテナを、分けてしまったら
サービスBから、このコマンドラインを実行するのは、普通の方法では、不可能だ
docker.sockをマウントして、サービスBコンテナからdocker execするか、、、
サービスAを拡張してRPAを追加しなきゃならない
あるいは、サービスAを、マルチサービス、にして、SSHを追加するか、、、

1コンテナだったら簡単なのに！

オンプレの延長だな

データベースは既存のサーバーが使えたほうが便利と思うけど
AWSのRDSとか使わせろ

>>276
> いやいや、作るのもめちゃくちゃ簡単だぞ？
> Supervisorとか使うだけ

使うだけじゃなくて設定ファイルとか書かないと駄目だろ
ログをどうするかとかさ、永続的なファイルをどうするかとかさ