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/

このように、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を、使いてえんだよ
なんだよこの、野球してえのに、サッカーボールでリフティングの練習しろ、みたいな要求は

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

>>339
殆どのユーザーは、有料Gitlabサービス運営なんかせんだろ
オンプレで、テキトーに、運用したいだけ

なーんか、噛み合わねえんだよな

昼休憩にラーメン食いたいなぁ、って思ったら、まあ、カップ麺が手軽でいいわな
そうじゃなきゃ、チョイと割高だけど、ラーメン屋にでも行くかぁ、ってそういう話をしてんだよ

それなのにお前らは、
麺はどこそこの業者から原材料を仕入れて、手打ちが至高だの
チャーシューは、最高級の肉を使い、じっくりコトコト煮込んだものが、究極だ
スープはどーしろ、野菜はあーしろ
よし、一週間まってくれ
最高のラーメンを、食わせてやりますよ！
とまあ、こんな感じ
おいおい、昼休み、とっくに終わってる、つーの！

dockerがどこから収益得てるのか考えたら
単なる1ユーザーがdocker使えるわ〜とかに
なるわけない
配布と奴隷を効率的に使うためにある

二択で話をしたって言い争いにしかならねーぞ

いつも、Docker をsupervisord とか、
仮想マシンみたいに使おうとする香具師が来て、1日で100レス以上進む。
同じ香具師だろ

1つの関心事につき、コンテナは1つ。
Docker Compose は本番では使えない

そもそもポートフォワーディング方式だと、スケールできないし。
既にポート80番を使っていたら、
8080番とか、ポートを変えないといけないから、ユーザーがアクセスできない

Kubernetes みたいに、cgroup, namespace が無いと運用できない

>>341
> GitLabを、使いてえんだよ
ただのユーザーですか？
ここは開発者のスレです。

使うだけならDockerでもパッケージでもなんでもいいだろが

本番swarmでdocker compose使うよ

docker desktopからdocker-compose.ymlで書いたものを使ってコンテナ起動する方法を教えてください

docker-compose up

nixでDockerfile書かずにDockerイメージビルドしてみた

イメージは作成出来たが、bashの履歴やタブ補完が使えない
なんか設定したら使えるのか？

bash-completion入れてみたが、効果無かった
Dockerfileと組み合わせて使うか、普通にDockerfile使う方が楽かも

まさかDockerの中でbashの履歴やタブ補完がほしいとか思ってるのか？
デバッグ用は別として、Dockerコンテナの中で作業するものじゃないぞ
>>1をちゃんと読め

>>353
devcontainerも知らんの？

アンチパターンの名前がどうかしたのか？

アンチパターン？

docker原理主義者は･･･まあ馬鹿だから分からんわな。
ウチの職場でもこんなツールあるんだぜと、紹介はあったな。

https://youtu.be/Uvf2FVS1F8k

環境依存するものをコンテナに入れていくと、
その環境では便利だけど、可搬性が無くなる

コンテナを別の環境へ持っていくと、環境依存のために動かなくなるので、
別の環境用への環境構築が必要となり、Docker を使う意味が無くなる

>>347
に書いた、
Dockerに、supervisord などを入れて、
仮想マシンみたいに使おうとする香具師と同じ

WSL2, Ubuntu などで直接構築しているのと同じになってしまう。
Dockerを使う意味がない

サーバーのメンテナンス作業のために
Dockerイメージに仕込んだスクリプトを実行するとか
開発中にbashに入ってデバッグはするだろう

シェル内でTabと上下キーすら使えない
地味に不便
Tabキーやカーソルキーを打つと空白や謎の文字が入力される

>>353
alpine, debianとかはコマンド履歴はちゃんと動くぞ
履歴はコンテナ削除すると失われるけど

コマンド履歴用などの機能があるシェルが入ってないだけでしょ。入れるだけ。軽量目指すとサンドボックスに近くなって作業性は低下する。

devcontainerも知らない冬獅郎がイキってたんか

VSCode の拡張機能で出来ないの？

Remote(WSL, Docker, SSH) とか

>>360
bashじゃなくてbashInteractiveを入れる必要があったようだ

nixはパッケージが別になってるようだ
ややこしいね

>>359
> Dockerイメージに仕込んだスクリプトを実行するとか
そういうのはね、maintenance.sh とかいう名前で
次のような内容のスクリプトを作って

#!/bin/sh
docker run -it maintenance:1.0 script.sh "$@"


$ maintenance.sh list
とかやって実行すれば良いんだよ

管理者に配布するのはこのスクリプトだけ
内部で勝手ににdockerイメージ引っ張ってきて実行してくれる

軽量イメージで有名なalpineも最初からインタラクティブシェルが入ってるぞ
サイズ小さくするためとか何とか言って
そこまで拘りだしたらきり無いだろ

セキュリティリスク最小化のために、サイズに依らず極限まで削るという考えがあるので文句言っても仕方ないね

セキュリティ的にはアプリをGoか何かでシングルバイナリで作って
本番用イメージはshすら入れないのがさいつよじゃね？

イメージにシェル入れるなら、インタラクティブ版でよかね

シェルスクリプトのインタープリターはどうしても要るって場合、
タブ補完と履歴機能は削った方がセキュアに・・・なるかな？
多少複雑さは減るのでその分セキュアにはなるかもしれないが、微妙

devcontainerにはお気に入りの鉄板ツールは全部ぶっこむに決まってんだろ

nixは利便性を二の次にして、最軽量コンテナ作ってドヤ顔したいだけなんでしょ。

nixは書くのが難しいイメージだがどうなんだろう。謎の表記法だ

関数型いいね

テキトーにnix-buildでイメージ作ったらalpineよりでかくなった
なんでだろう

glibcとtzdataがでかいな

31M 33idnvrkvfgd5lsx2pwgwwi955adl6sk-glibc-2.31
1.6M czc3c1apx55s37qx4vadqhn3fhikchxi-libunistring-0.9.10
552K ifnmhjrvk3f0hbz3f25s3izlb9yk8x0f-iana-etc-20200729
100K r2wvgnr54vmwnjvzyqdixv8xbn362jgh-mailcap-2.1.48
4.8M w1g27pgslf28nh1py1szj7lk4xksdhqq-tzdata-2020c
276K xim9l8hym4iga6d4azam4m0k0p1nw2rm-libidn2-2.3.0

musl版のパッケージもあるが、ソースからビルドが多くてとても時間が掛かる
テストまで実行してる
一向に終わる気配がないので中止した

alpineでもtzdataは設定だけしてパッケージは消すな

>>365
alpineに入ってるのはbusybox ashだね。
インタラクティブな機能がまったくないシェルなんてないだろ？
インタラクティブシェルが入ってるからなんだっていうんだ？

>>367
シングルバイナリで外部コマンドは全く使用しない
ライブラリは全く使用しない

それってDockerで動かす意味有るの？
だってそのシングルバイナリ以外はなにもないんでしょ？
カーネルの機能だけあれば動くなら、
Dockerの外で動かせばいいじゃないｗ

外部に依存しているものを動かしたいという前提があるから
Dockerを使うのであって、その前提を無視するなら意味がない

>>378
コンテナオーケストレーター使うなら
意味あると思う
何言語で書かれていようが
同じ方法で環境変数の設定やら監視やらローリングアップデートができる
Goも例外ではない

>>377
nixはbashとbashInteractiveに分かれてる
Interactiveなしの方はインタラクティブシェルに普通はある機能が省略されてて
シェルのインタラクティブモードに入っても
タブで補完できないし
上を押すとASCIIコードがそのまま出る

>>378
オーケストレーターがシングルバイナリに対応してるならコンテナは要らんよ

ローカルでCLIツール動かすだけならバイナリを直接配布でもよい

Webサーバーとか動かすならコンテナオーケストレーターの機能は便利