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/

>>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とか使うだけ

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

> Dockerfileも既存のchefなんかが、殆どそのまま使える

chefを使うってアホじゃないか
Docker使う意味がなくなってる

このように、1サービス1コンテナの精神で細かく分離すると
サービス同士が疎結合になり、一見すると良いように思える
しかし、疎結合である、ということは、サービス間の連携のオーバーヘッドが増える、ということだ
サービスはRPCを実装しなければならず、開発者は疲弊する
サービスメッシュの管理コストは増大し、運用者は疲弊する

これはミクロサービスの功罪と同じことだが、なんでもかんでも、小さく分けて、疎にするのが、常に正解なわけじゃない
全てはトレードオフなのだ！

たしか、マーティンファウラーだったと思うが
彼曰く、最初からミクロサービス的な思想に傾倒した案件は、失敗することが多い、らしい

最初はモノリスのほうが、うまく行くのだ
システムが、モノリスでは到底手に負えないほど、巨大化してから初めて、分割することを考えれば、よろしい

>>280
そんなことも出来ないの？

>>277
それ、仮想マシン使えって話なんだ

>>283
作るのが大変だって話をしてる
出来るできないの話ではない

>>281
あるぞ
GitLab公式コンテナはChefで動いてる

>>285
大変じゃないけど？

まあここを読めって話だな

Supervisor と Docker を使う
https://docs.docker.jp/engine/articles/using_supervisord.html

>>287
apt-getでインストールするだけ vs 設定ファイルを自分で書く

>>286
> GitLab公式コンテナはChefで動いてる

それを同じことをお前が作るのは大変だって話をしてる

>>284
仮想マシンは重いからやだ

>>289
どっちも大変じゃないけど？

supervisordの方が面倒くさい
docker-composeの方が楽

>>290
大変じゃないけど？
もちろんGitLabほどの製品を作るのは無理だろうけどChefでコンテナを作るのは誰だってできる

>>293
そりゃ、手間を利用者側に、オシツケテル、からでしょ

docker-compose psしたらsupervisordが生きてたらupと表示されるが
設定にミスがあった場合や問題が起きた場合もsupervisordさえ生きてたらupと出る
判定するにはログやsupervisordのあるコンテナ内でコマンド実行が必要
どこが優しいねん

>>288
A container’s main running process is the ENTRYPOINT and/or CMD at the end of the Dockerfile.
It is generally recommended that you separate areas of concern by using one service per container.
That service may fork into multiple processes (for example, Apache web server starts multiple worker processes). It’s ok to have multiple processes, but to get the most benefit out of Docker, avoid one container being responsible for multiple aspects of your overall application.
You can connect multiple containers using user-defined networks and shared volumes.

https://docs.docker.com/config/containers/multi-service_container/

>>296
ミスがある前提なら何やっても駄目だろ
ひでー詭弁だな

avoid one container being responsible for multiple aspects of your overall application.
avoid one container being responsible for multiple aspects of your overall application.

>>298
開発や運用でトラブルが一切無いと考える方が頭おかしい

dockerやdocker-composeだけでsupervisordのやってる事と同じ事が出来る
余計なコンポーネントを増やすな

>>300
なら1コンテナ1プロセスでも間違いは起こるなー

>>301
aupervisorだけでdockercomposeがやるようなことはできる
余計なコンポーネントを増やすな

>>303
supervisordあったらdocker要らなくね？

既存のデータベース使うとかは考えないの？
データベースの入ってないDockerイメージと
入ってるイメージ2種類作るのか？
それか起動時のスクリプトにフラグ追加？

だったら最初から分けとけよ
めんどくさい

>>304
要る
svに限らず、全ての依存関係を、imageにパッケージングする機能
インスコした物を、キレイサッパリ、廃棄する機能
お手軽サンドボックス
ありがとう、docker！

>>305
お前さー、少しはレス読みなよ
分散用に、分けたコンテナをオプションで配布する、ことまではヒテイしとらんだろ
言うなれば、マルチサービスコンテナファーストだよ
シングルサービスコンテナはオプションだ

>>306
LXCか仮想マシンに直接インスコでよくね？

docker使うならsupervisord使わなくても
docker-composeのyml配れば良いじゃん
何も問題ない