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/

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

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

そんなもんそれぞれのプロセスが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配れば良いじゃん
何も問題ない

>>307
くそデカイメージと小さいイメージ2種類用意するのが面倒

docker-composeなら簡単にかけて
小さいイメージ1種類で済む

>>305
それとな、内部DBと外部DBを選択できるコンテナは、わりとよくある
スタンドアロンだとsqlite、そうじゃないとpostgres、mysqlのどっちか
てなわけよ
スタンドアロンファースト
(・∀・)ｲｲﾈ!!

>>309
小ささにこだわって、オーケストレーションマニフェスト書かせたり、運用の手間を増やすな
カリッカリにチューニングしたい、オタク共に合わせるのは、大半のユーザーにとっては面倒でしかないんだよ
多少、重くていいから、お手軽に使わせろ、ってーの

>>310
sqliteはプロセス要らないからいいが
mysqlやpostgresqlを突っ込めというのはキ○ガイの所業
複数DB対応するには普通は対応コストがかかる
DBラッパー使っても特定DBにしか対応してない拡張は使えないし

docker-composeで書いても大した記述量でもあるまいに
意図的に無視してるな

>>311
docker-compose配ればいいだけだろ
基地外

>>313
podmanで動くようにしろ
K8Sで動くようにしろ
Nomadで動くようにしろ
うちの環境はだと動かないんだが？
、、、

お前これ全部対応できんの？

手軽に試すなら普通はdocker-compose使うから
そんな特殊なやり方で対応する必要がない。
k8sやらnomadに手軽さは求めてないし。

k8sでやるんだったらhelmチャートあると便利。

マルチコンテナだとこうやって、実行環境に会わせて、オーケストレーションマニフェストをたくさん書かなきゃならん
一方でシングルコンテナなら、docker runするだけ
超簡単で、みんなハッピー
しかも、podmanでも、同じように動く

そんな手軽さ別に求めてないし。馬鹿なの？
docker-compose用意してたら大体想定されている使い方分かるから、
自分でYAMLなり何なり書けば良いだけ

>>317
ユーザーに、手間をかけさせちゃ、だめだ
GitLabはこれをよくわかってる、から、1コンテナに詰め込んだ
ユーザーはdocker runするだけで、GitLabを使えるようになった
これが、マルチコンテナだったら、まあ、大変だよ

自作PCとスマホ、みたいなもんかなー

マルチコンテナ≒自作PC
このパーツ、あのパーツ、色々集めて、ミスしないようにくみたてて、ドライバとかも探して、入れて下さい
ツールは別売りなんで、それも自分で探して、入れてください
組み合せが悪いと、動かないかもしれません
でも、まあ、自己責任です

スマホ≒シングルコンテナ
スマホを購入して、箱から出して、電源を入れて下さい
WIFIとアカウントの入力だけ、お願いします
驚きましたか？そうです、もう使えます！
必要になりそうなアプリケーションも、予め揃えてあります
おめでとうございます！

>>318
作る側の手間がかかり過ぎるって言ってんだろ馬鹿なの？
だから誰も真似しない

本格運用しないならdocker-composeで動けば十分だろバーカ

なんでそんなちょっと試して見るだけのくそでかイメージが
あらゆる環境で動く事を気にする必要がある？？？

>>320
大した手間じゃないよ

一流は自分達の、多少の手間を惜しんで、ユーザーの負担を、増やそうとはしない
二流は自分達が、ほんの少し楽したいからって、ユーザーに手間をオシツケテル

GitLabは超一流だ
だから、シングルコンテナを選んだ
そのほうが、ユーザーが、楽だからだ

>>321
世界に公開するイメージなら、どの環境でも、簡単な手順で、動いたほうがいいに、決まってる

>>322
そんな物誰も求めてないから真似しないんだと思うよ。

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock my-awesome-app docker-compose up

docker.sockをさらけ出すとあぶない

>>226でDockerてのは設計としては1コンテナ1プロセスを推奨してますよ、普通は>>308みたいにymlとdocker-compose
で構築してくださいね、でもまあ>>277見たいなケースで複数プロセス動かしたい時は>>288みたいな仕組みは用意して
ますから使ってくださいね、このケースの成功例はGitLabがありますよ。
唯>>296の様なリスクも在りますので気をつけてくださいね。

と、たったこれだけの話なのに一流だ二流だDockerfileもyamlも書かずに使ってるだけだから分かってないと、兎に角
相手をDisらなければDocker原理主義者の皆さんの会話でしたｗ

暇だから適当なこと言ってからかって遊んでるだけだぞ

GitLabは例外でしかないだろ
GitLabのDockerfileみてみろ、めちゃくちゃ大変なことしてるぞ

あれはそこまで頑張ってでも1コンテナにしたほうが
利用者にとっては便利だから、工数かけてやっただけで
作る側にとっては大変だってことの証明になってる

GitLabはDockerが推奨する「普通の」やり方で作った非公式イメージが前からあった
あのやり方に疑問を抱く者は少なくなかった

公式helmチャートも出来たようだ
helmでそんな巨大イメージにする必要ないので
普通のやり方で作られてる

> あのやり方に疑問を抱く者は少なくなかった

それは使う側から見た話だろ？
作る側はどれだけ大変か、Dockerfileを見ればわかる

オーケストレーション前提じゃオペレーターも大変だ
オペレーターはレゴブロック遊びに付き合うほど暇じゃない

https://github.com/sameersbn/docker-gitlab
GitLab使うならこっちでよくね？

readmeなっが
お手軽な公式版、使うわ

な？「使うわ」という使う側の立場でしか見てないんだよ
作る側の大変さの話をしてるのにな

バカの一つ覚えのように一つのコンテナなら手軽に試せるしか言わねえし
何言っても無駄だろ

>>334
https://github.com/sameersbn/docker-gitlab#quick-start

redisとpostgresを何らかの手段で起動し
シークレットの暗号化に使う文字列を3つ作れば良い
たったこれだけ
これ以上簡単になりようがない

それを>>332はできないと言って
先程から大騒ぎしている

GitLabはウェブサービスも運営してるが
そのGitLabがそのDockerfileを使ってると思うのか？って話だよな

スケールさせるためには、アプリとデータベースを分離させるのは当たり前だし
Dockerを使うっていうのは、そういうウェブサービスも運営するときの
システムを作るために有るのだから、そういうときにどういう構成にしますか？の
話でサービス毎にコンテナを分けるのは当たり前

作る側の視点がかけてる
これはDockerコンテナを動かすだけの
インフラ屋にありがち

ごった煮イメージが本番運用に堪えないって点に異論は無いらしい

>>338
めんどくせー
ポスグレでも、Redisでも、シークレットでもねえ
GitLabを、使いてえんだよ
なんだよこの、野球してえのに、サッカーボールでリフティングの練習しろ、みたいな要求は

コンテナひとまとめが効率的おじさんは放置推奨。