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/

Kubernetes 1.20からDockerが非推奨に!!

感染広げるXantheマルウェア、誤った構成のDockerサーバが拡散の原因に
https://www.itmedia.co.jp/enterprise/spv/2012/02/news118.html

わざわざ会員登録までして記事見たのに危機感煽るだけ煽って結局何が悪いのかすら書かないとか記者辞めちまえよ

>>2
https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m

tl;dr
For developers
Don't panic, Docker containers and images are still alive. It's not that it will change everything.

tl; dr 開発者向け 慌てる必要はありません。Dockerコンテナとイメージはまだ生きています。
それがすべてを変えるというわけではありません。

まぁそう言うしかないわな
RIP

つーかDockerに代わるものなんてないじゃんｗ

ちゃんと記事読んでからコメントして♡

ほれみたことか
どんどんDockerがオワコンに向かっている
これからはPodmanだよ諸君

>>1
テンプレに間違いがあるね
コンテナ内部は複数のサービスにしてもよい
Gitlab公式コンテナが好例
そのほうが簡単に配布することができる

Dockershimとやらが無くても動くように
docker側が対応しないのは何で？

工数が足りないから

//jaco.udcp.info/entry/2020/12/03/172843

何がこれからは Podman だよ
バカにも分かりやすい記事を持ってきてやったから読んで理解してくれ

Dockerはオワコン
代替は今のところPodmanしかない

もともと落ち目だった
デーモンとかswarmとか要らんし、レジストリのpull制限かかるし、これじゃ安心して使えないよ

dockershimって単体でも使えんの？

Kubernetesとは別のリポジトリでメンテしていけば良くね？

Dockerは非推奨じゃないし今すぐ騒ぐのをやめろ
https://jaco.udcp.info/entry/2020/12/03/172843
Dockerはより開発者向けにシフトする感じかな

発展途上の技術が最適化されていくだけって話だったのね
5chでだけ声の大きい人の言う事は一番あてにしちゃいかんな

>>17
twitterで声の大きい人や
発表会（笑）だけで有名な人も同じ
当てにしちゃいかん

非推奨にも幅があるよ
ナルハヤで脱却して、って意味での非推奨
別に使うのは構わんけど、もっと良いモノあるよ？って意味での非推奨
Dockerは後者の意味での非推奨
なんたって、Podmanがあるからねぇ
天下の赤帽が、コマンド名にエイリアスを付けるぐらいだから、よっぽどだよ

Podmanの名前出てたか？
もっと良いものはあるのが事実だとして、そこにPodmanの名前が
出てないなら、それは良いものじゃないってことだろう？
Podmanの名前出てないよな？

podmanとdockerの比較表を作ってくれたら試してもいいよ

>>9
1の記載は本人の妄想と誤解が混ざり合ってるから気にしちゃいかん。
読んだ感じだと未だPart4以前から続く間違いが、未だわかってない様だね。
Part6が始まるまでにどんだけ間違いに気づくか見もの。

KubernetesはDockerのサポートはやめるけど
今後もDockerで作ったイメージは動くらしい
どういうこと？
KubernetesってそもそもDockerイメージを動かすことしかしないよね？

コンテナにも標準仕様があんだよ
それ満たしてればK8S的には何でもおｋなわけ
Dockerはそれを満たしてないからしょうがなくアダプタで無理やり動かしてた
でももう面倒になったからDocker切り捨てるわバイバイってこと

記事見る感じだとDocker自体がcontainerdのラッパーでしかないから
じゃあcontainerdで良くね？って話？
Dockerもう要らなくね？

開発環境で使うという意見もあるがpodmanで十分だ
WindowsかMacだったら仕方なくdockerを使う

WindowsならDockerはいらんな。
SSD換装できないMacは無駄にストレージ使う訳にもいかんから
消去法的にDockerって感じ。

>>16
この記事だと結局dockershimに非対応になるってことじゃね？

マジでバカしかおらんのか

podmanがどうのこうのという話？
単に信じた君が馬鹿なだけじゃね？

>>24
> Dockerはそれを満たしてないからしょうがなくアダプタで無理やり動かしてた

え？でも非推奨になってもDockerイメージ動くんでしょ？

>>28
つまりdockershimは非推奨だけど
dockershimを使わなくてもDockerイメージは動くってこと？

Dockershimで検索したらこれが一番目に出てきたよｗ

Dockershim Deprecation FAQ
https://kubernetes.io/blog/2020/12/02/dockershim-faq/

本家は最初から「Dockershim」って言ってたのか？
（それとも反響が大きくて後から出した？）

第一お前らKubernetes使ってないでしょ？

オーケストレーター使うならK8S
使わないならpodman
dockerは要らないね

>>34
Kubernetesつかってないけど
「本番環境ではKubernetes使います。Dockerはサポートされてないので作り直してください。」
って言われたら嫌じゃん

>>35
> オーケストレーター使うならK8S

K8Sだけじゃ何も動かない
せめてDockerイメージがないと・・・

>>36
Dockerイメージのフォーマットが変わるわけではない

>>38
つまり今まで通り
Dockerで開発してDockerイメージを作って
それをDockerリポジトリにpushしていれば
それをkubernetesから使えるってこと？

>>39
そりゃそうじゃ
誰がDocker「イメージ」を廃止するとか言った？

え？じゃあなんでこんなに騒いでるの？

docker imageは駄目っしょ。
それで作ったコンテナはdockershimに手伝ってもらわないと動かないだろうし
それは来年末に廃止するよ、って言ってるんだし。
代わりにBuildah使ってビルドしてね！って言ってるし。

まあmicrok8sで開発してたらDockerきえてCRIOになったし
そうなるだろうなとは思ったけど。
イメージのビルドはk8sからはやりづらく感じる。
クラスタ用の定義ファイルとアプリ用の設計書が一緒くたになりそうな

>>42
ばか？

> イメージのビルドはk8sからはやりづらく感じる。
k8sからイメージをビルドするってどういう事？
k8sからどうやってイメージをビルドするの？pullするだけでしょ？

k8sでビルドはする

k8sでビルド？意味不明

>>41
君みたいに解説記事を読まずに騒ぐ人が多いからじゃない？

逆にpodmanを使わない人はなんで使わないんだ

だからなんで昨日からの話の流れで podman が出てくるんだよ、いい加減にしろよボケ

dockerがオワコンだからpodmanに移行しようって話だよ

おわってんのはお前の脳みそじゃい！

↑は何をいきり立ってんの？
5chをDockerのサポート掲示板か何かと勘違いでもしてるのかな？

お前こそpodmanのスレは別にあるんだしそこ行ったら？

>>54
俺はpodmanに興味はない。
俺が焦点にしているのはお前だ。
スレチと言うならk8sからそもそもスレチだし、それなら>>2から
全部駄目なんだが？なんでpodmanにだけ反応するの？

解説読めば理解できるのに的外れな質問をしている人のほうがサポート掲示板と勘違いしているんじゃないですかね？

ちゃんと理解したならdockerがオワコンとわかるはずだろう
dockerはいま急速に切り捨てられようとしてる
今回の事件だけじゃねえんだ

>>56
悪いけど的外れな質問にも興味はない。
俺はDocker板で突然k8sの話題が始まった事に
ずっと違和感を持っていたけど、別にツッコミを入れたりはしない。
で>>50-52は何でそこをスルーするのにpodmanに「だけ」反応するの？って話。

>>58
podman は今回の件に関係ないからだけど？

知識が足りないからdocker = K8Sのような勘違いをしてるのかも
しっかり学ばずになんとなくでdockerを使ってる若手に多い

podmanはなんつーかもとから土俵の上にないっていうか
たぶん非推奨っていわれてもこんなに騒ぎにはならないだろうな

>>59
日本人の方のブログには「代替にpodmanが提供されている」という記載はある。
https://blog.inductor.me/entry/2020/12/03/061329

>>62
CRI-O に言及するついでに書いてあるだけだろ...
記載があるから関係があるという考え方はやめたほうがいいよ

>>63
k8sをちゃんと使ってDockerとの違いにやりづらさを感じた人なら
その一行で「なるほどな」と感じるはずだが？

>>64
docker との違いにやりづらさとあるが、主語がないので何と比較してやりづらさがあると言いたいのか分からない

> Dockerの代替ツールとしてはローカル用ランタイムのPodman、コンテナビルダーのBuildah、そしてCRIランタイムのCRI-Oをそれぞれ提供しています。
この一行に関してはそうだねとは思っても、なるほどと思える要素はないな

>>65
それは君が馬鹿だから。
資料を読めばなぜやりづらいと感じるのかもわかる。

>>66
これまで k8s -> dockershim -> docker api -> containerd となっていたのを k8s -> containerd にするっていう話なんだけど、
これのどこに podman が関連するか教えてくれない？

>>67
docker要らなくなるな
じゃあpodmanでいいか

>>67
その資料にはそうは書いてないな。
今まで：
k8s->dockershim->Dockerで動いていたけど、dockershimは廃止するよ
これから：
でも実はDockerは内部でcontainerdとして動いているから廃止後はk8s->containerdになるから安心だよ。

と言っていて、その背景の情報としてDockerはk8sとネットワークとかVolumeとかの機能が
被っていて邪魔、とかCRIとしてコンテナを動かす技術はdockershimのほかにCRIOやcontaienrd
があって、CRIOの人達は早くからpodman押してるよ、それは何故かと言うとk8sが求めていない余計な
機能は実装していないからだよ、と言っている。

だからこの文脈で>>51といえばそれが正しくて、>>50はお前何いってんの？としか思わない。
少なくとも>>50という感想には絶対にならない。

dockerを開発用に使ってる人
→今まで通り使い続けてOK。k8s上でdockerで作成されたコンテナは実行可能であり続ける。(コンテナのフォーマットは標準化されていて、dockerもそれに従っているから）

k8sのコンテナランタイムとしてdockerを使っている人
→cri-oかcontainerdに移行してください。
猶予は1年

って認識だけどこれでいいんだよね？

>>69
まず、前半部分(安心だよ。まで)って何が言いたいんだい？
私が書いた内容を君の言葉で言い直しただけ？

だからこの文脈でって言うけど、話を飛ばしすぎなんだよなぁ
私は最初から昨日の話の流れで podman が出てくるのはおかしいでしょと言ってるだけなんだけど
dockershim が非推奨になります、だから podman に移行しましょうなんて話が公式からありましたか？

>>70
いいと思うよ

https://qiita.com/kenkono/items/6221ad12670d1ae8b1dd
これのDockerfileの最後の行のADD . /code/には何の意味がありますか？
その手前でADD /code/してる気がするのですが
なぜ再度ADDする必要があるのでしょうか

>>73
依存性だけ先にダウンロードすんだよ

個々のDockerfileの意味とか流石に作者に聞けとしか
よく使われるテクニックとかならわかるが

どう見てもよく使われるテクニックなんですが...

dockerユーザーは初心者も多いからこんなもんでしょ
podmanは玄人ユーザーが多いからみんな「わかってる」けど

>>74
なるほど
ためしに最後のADD . /code/の行を消してもbuildできてしまったので
どのような目的があったのだろうと疑問だったのですが
まだいまいちピンときていませんがありがとうございました

>>71
もういいよ。
お前の脳味噌は相変わらず腐ってる。

>>78
最後のADD削ったら必要なものが入らないだろｗ
Dockerは上から一行ずつビルドしてるんだから
「最後の一行」を削っていって最終的に最初の一行だけになっても全部ビルドできる

別にこれでもビルドは正しく出来るんだよ
WORKDIR /code
ADD . /code/
RUN pip install -r requirements.txt

ただしこれだと、.（カレントディレクトリ）の内容が変わったときに
pip install -r requirements.txt という時間がかかる
パッケージのインストールを何度もすることになる

一般的に requirements.txt の内容が変わることは少なく
.（カレントディレクトリ）= ソースコードは変化しやすいので
記事の順番でやるとビルドに時間がかからなくなる

これはDockerを本来の目的＝自社開発アプリのデプロイとして
使う場合によく使われるテクニック
開発中に何度もソースコードを修正してビルドするからね
他人が作ったアプリをただビルドするだけの人だとこうする理由がわからない

>>80
＞上から一行ずつビルドしてるんだから
＞ただしこれだと、.（カレントディレクトリ）の内容が変わったときに
なるほど　まだわからない部分はたくさんありますが
簡単な構成でdocker buildで試し比べてみました
stepそれぞれに（上から順々に依存している？）１２文字のハッシュ値があって
最終stepの行がimage idになっているのをみてくしっくりきた感じがしました
ありがとうございました

Mirantis to take over support of Kubernetes dockershim
https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/

dockershimはKubernetesの外でメンテ継続するってよ

いずれにせよ独自のKubernetesディストリビューションを自分で作ってるユーザーにしか関係ない話だよねこれ
あるいはKubernetesのWorker Node上でdocker in docker使ってたりとかすれば関係あるけど

そりゃ短絡的すぎる
開発ツールとしてのDockerは全く金になってないわけで、実行環境として使われなくなればDocker社は潰れる
まあいずれにせよバイアウトは時間の問題だろうけど、変なところに買われないといいね
MSあたりなら万々歳か

ほんとそれだよな
dockershimっていう技術的1要素についてしか見れてない人はちと掘り下げが浅い

dockerで作ったのって所有者がrootになってるけど
別にそのままでいいよね

podmanなら安心

dockerはwindows

とMacだけで使うって方向になりそう

ALLOWED_HOSTSをコマンドから引数から書き換えられたらいいのに。。
せっかくdockerで自動で構築できてもそこだけ手動なのか
シェル書くしかないか

allowed_hosts=aaa docker run ...
でいいじゃん

>>90
settings.pyのALLOWED_HOSTSを切り替えてそれでやってみたけどだめだった

Djangoをディージャンゴって音読してしまう癖を矯正するコツを思いついた
限りなくデをジに近づけてデェンゴって発音する

ワンピース ねじまき島の冒険(同時収録:ジャンゴのダンスカーニバル)でも見ればいいんじゃないですかね？

DockerHubってイメージじゃなくてDockerfileとかダウンロード出来ないの？
今使ってるイメージ微妙に不便なとこあるからPRしようと思ってるんだけどやり方がわからない…

どっかにかいてあるだろ
Dockerfileは必須じゃないから
ないこともあるが

>>92
いたずらハゲたかジャンゴってスーパーマリオ64にあったよな

>>94
GitHubへのリンクが無くて
探しても分からなかったら諦める

>>84
こういうコメントって何なんだ？
薄気味悪い。

>>97
>>97

Docker 始めたばかりでよくわからないんだけど
docker-compose で複数プロジェクト起動したりするときってみんなどうしてるの？

数少なかったらコンソールから手入力でも行けそうだけど
プロジェクトとかオプションとか多くなるとしんどいですよね

シェルスクリプトとかでがんばるのかな

Ansible

Chef

Puppet

>>99
複数プロジェクトって？
それぞれのプロジェクト？が連携してるのなら
一つのdocker-compose.ymlでやるけど

プロジェクトは公式の単語だからドキュメント見てこい

>>103
たとえば WordPress と BBS を運用するサーバがあったとして、
両者は連携させないのでそれぞれに docker-compose.yml を書くとするじゃないですか

それでフロントエンドに httpd を置いて、リバースプロキシで振り分けるとして
これも docker-compose.yml を書いて運用するとプロジェクトが3つになります

関連はするので全部まとめて一つにするのが正義かもしれませんが
密に関連するのと比較的疎になってる部分があるのをごちゃまぜにするのがはたしてよいのかどうか

で、こういう場合は大抵どうしてるのかなと思ったのです

>>105
もう答え出てるよ？構成管理ツールを使えばいい
Dockerだからといって、急に昔ながらのやり方が変るわけじゃない
K8Sを使わないなら、Dockerなんてただのパッケージングツールでしかない
ビルドして、サーバーにリリースして、起動する
ほら、いつものやつだろ
だったら、いつものやつを使えばいい

>>106
ありがとうございます
構成管理ツールを利用している人も多いということですね
検討してみます

K8S はクラスターとかで使うので 1 サーバで運用の場合は用途が違うのかと思ってました
こちらも勉強します

構成管理ツールはサービスを起動するための「構成」を作るだけなので
「サービス起動」自体は自分で書かないといけない

Dockerだからと身構える必要はない
PCを起動した時にサービスを自動起動するのはなにか？
今だとsystemdがよく使われている

systemdを使ってサービスを自動起動させる
その中身がdocker-composeになるだけの話

systemdでラップしたほうがいいのか?

dockerコンテナ単体なら--restart=alwaysで出来るはずだから
docker-composeでもrestartオプションでなんとかなるんじゃね？

オレオレスクリプトよりは良いんじゃないかな
systemdの規則に則って設定が書かれるから引き継ぎしやすいだろう

DockerfileでRUN django-admin startproject mysite .するとエラーはでないけど何も作成されない
docker-compose runでやるとなぜか成功する

linuxでdocker使うとvolumeでroot以外書き込みできなくなるのにハマるから面倒くさい
windowsで使ったときは天国だった

rootが嫌ならpodman使えばいいよ

VOLUMEの設定忘れてただけだった

「イラストでわかるDockerとKubernetes」は完全に良書 - Cloud Penguins
https://b.hatena.ne.jp/entry/s/jaco.udcp.info/entry/2020/12/08/215058

↑
ブクマがすごい増えてるがこのスレの先輩方の意見も聞かせてください

読んでない

ちょろっと立ち読みしたけど概念解説本って感じ
手を動かす類のものではない

M1 Mac買ったんだけど、プレビュー版のメールが来ない

ドッカーン動いたら買い換えるわ

https://appleinsider.com/articles/20/12/11/docker-rolls-out-initial-support-for-apple-silicon-macs
動くのはもう動いているだろ。
>>120

動いてるのに買わないみたいだ…

x86のイメージもアップルシリコンで動く？

動く訳ないでしょ。

x86_64のイメージもいい感じにエミュレーションしてくれないのか

M1のdockerはarmもx86_64も動くよ

x86_64はqemuかなにかのCPUエミュレーションを使うらしいから相当遅いようだけど
ttps://twitter.com/ogrisel/status/1339508321078939650

docker run --platform linux/amd64
のようにすればx86_64のイメージが動くらしい
ttps://twitter.com/akhenakh/status/1339582893375418379
https://twitter.com/5chan_nel (5ch newer account)

docker-compose up -dでサーバを立ち上げたままストを再起動すると
WIndowsだと自動的に立ち上がりませんがUbuntuだと自動的に立ち上がりました。
この挙動の違いはなんか設定があるのでしょうか？

>>126
＞docker run --platform linux/amd64
＞のようにすればx86_64のイメージが動くらしい

これってターミナルをロゼッタで
開くのが必要なやつかな？
https://i.imgur.com/XrDGxYc.jpg

djangoのsqliteで日付ソートしたいとき
filterで__range=(start_date, end_date)ってやれば取得できたけど
この日付以降を取得したい、この日付までを取得したい
って場合はどうするの？？
end_dateのとこを最新のにするとか
start_dateのとこを0年？にするとかで対応できそうだけど
別の方法はないのだろうか

スレチ

Windows 10 Home 版に、WSL2, Docker を入れた

OS の連続アップデートに、3時間掛かった。
CPU-i3, 8GB メモリを、CPU・電力エコモードで使っているから、コンパイルが遅いのかも

その後、WSL1 から、WSL2への変更。
Windows 10 Home用のDockerのインストール自体は、簡単だった

これで、Windows10 プロ版じゃなくても、Dockerを使える。
Kubernetes も入っていた

最新OSイメージをUSBに焼いてインスコすればアプデすぐ終わるよww

ホストマシンにLinuxを使わないのなんで

とりあえず触ってみたいだけじゃないかな？
Linux用の他の物理PCが無いとか

>>133
これって、普段Win使っててもDocker
使うときは別のLinux入ってるPC使わないの？っていう質問なの？
それとも、Docker使うのに何でLinuxじゃなくて、Win10home入れてるの？
ていうこと？

>>135
後者
最初から全部Linuxだけでよかないか？

ふだん使いにはWindowsのがいいから。

そんなんやからLinuxが普及しないんや。。。

>>1
windowsでffmpegのビルド環境をDockerで構築するのはベターな使い方では無いって感じなんですかね

>>138
はい。ベターではありません。
Dockerはffmpegを作るものです。
その仮定でffmpegのビルド環境を作ることになるかもしれませんが
最終的に作るのはffmpegです。ビルド環境は途中の状態に過ぎません。

単体で配布できる動くffmpegバイナリがあれば嬉しいですよね？
Dockerはそれを実現するものです。

つまりどういう事だってばよ！

exeで配布したかったらLinux立ち上げるかwslでやれって事だな

playwithdocker
プログラムは動くけどウェブサーバーだけ５０３になる？
コードミスったのかとおもったけど前に成功して改変してないやつがダメだし

今やったら復活してた
playwithdockerみたいな感じで試せるとこないかな
有料でも

docker-composeでweb制作をしたいと思うのですが、
javascriptのeslintはホストとコンテナどっちにインストールするものなんでしょうか？

普段開発用はホスト
CI用はコンテナ

ホストのファイルシステムをマウントして使うとファイルシステムの通知機能は使えないよね

nodeをコンテナから使うとホットリロードはポーリングでしか出来ない

Unisonみたいの使えばファイルシステムはLinuxのになるから
一応いけると思うけど・・・

対応していれば使える
Windowsならできるやろ

ホストによるのでは

うん。だからWindowsは対応してる

https://www.infoq.com/jp/news/2020/03/docker-desktop-windows-fuse/

すまんWindowsはinotify対応あるのか

macもいける？

なんでWindowsは調べられてmacは調べられねーんだよｗ

タイムドッカーン

Docker Desktop for Windowsの3.0にアップデートしても大丈夫？
謎の不具合に遭遇したりしない？

昔、家でWSL2バックエンドで使ってたらアプデ後に起動できなくなった事があった
大したデータを入れてないのでリセットしたが、あんまり信用出来ないなと思った

Mac版は自分では使ってないが、メジャーアップデート後から奇妙な不具合が多数報告されてるのは知ってる
一応安定版リリースじゃないのか

Mac版は一応ダウングレード出来るようだ

会社ではWindowsでHyper-Vバックエンド

宗教上の理由ならしゃーない

Docker Desktop for Windowsの3.0でもHyper-Vバックエンド対応してるだろ？
WSL2バックエンドは、たぶん俺しか困らないだろうなってバグ
（カーネルの古いAPIの削除による仕様？）があって切り替えれないでいる
バグの内容を言うと、困る人は俺ぐらいだろうなって特定されかねないのでここでは言えないｗ

windows sandbboxで試せばいいだろ

>>155
カーネルAPIの互換性については弊社でも度々問題になりました。
古いディストリイメージを使う場合はHyper-Vバックエンドが安定しますね。

podmanいいね

podmanもっと使ってくれよ
このままrocktみたいに消えるのやだよ

Redhatが推してるから消えないよ

消えないのと普及しないのは違う
もっとRedHatが開発した独自ツールが普及するといいのに

dockerエイリアスはpodmanなので自動的に広まるよ

まだ広まらないんだよ
なんでだよ？

RedHat独自で普及したものがないのが不満

rpmがあるやろ！

本番クラスタはマネージドK8S
開発環境はDockerCompose
Podmanは…オンプレシングルノード本番専用？

RedHatにベンダーロックインされてる人が使うｗ
RedHatがDockerを切り捨てたから
それに従わないといけないのだ

商用はRedhatだからpodmanに従ったほうがよさそうだね

あとで移行すればいいよ
普及してから（そして大抵の代替技術は普及しないｗ）

podman 2〜Dr.ワイリーの謎〜

PodmanよりDockerRootlessのほうがええわな

docker-composeはConfigMapに相当する仕組みが無いから不便ですね

Wasmerも本格的に動き始めた
いよいよDockerの居場所がなくなってきた

rocktの登場で居場所はとうの昔になくなってたはずだが？

自作ソフトのdockerイメージを作って配布しようとしているんですが、設定ファイルの類はどうするのが普通ですかね？

1. 配置するディレクトリを決めておいて使用する側でmountしてもらう
2. volumeを作ってそこに置いてもらう
3. デフォルトの設定ファイルをイメージ内に配置して、使用する側で上書きしてもらう
4. その他

ケースバイケースの場合は判断ポイントなどを教えてください。

設定の構文が複雑ならファイルをサポート
そうでないならコマンドライン引数、環境変数、ファイルを全部サポート

>>175
コマンドラインの引数や環境変数は？
Amazon ECSはこれらの方法でしか設定を入れられないから
環境変数で設定出来た方が便利

ECSの機能を使わず、ホスト上にファイルを配置しておけば設定ファイルも使えるが、わりと面倒くさい

k8sだとConfigMap、Secretの内容をファイルとしてマウント出来たりして便利だった

パスワードのような機密情報はコマンドライン引数にするとまる見えになるから
設定ファイルや環境変数にすべき

Traefikだったら複数の設定方式に対応してて
・コマンドラインの引数
・設定ファイル（場所は固定っぽい）
・環境変数

どれも自由に選んで使えた

設定ファイルは変更を検知して自動的に反映する設定も可能なので
別途、同じディレクトリをマウントしたサイドカーコンテナを作って
独自のConfigProvider作れたりとか
夢が広がりんぐ

>>176
>>177
動かそうとしているアプリケーションは設定ファイルのみを使用しますので、それを実行する側の
ユーザー環境で差し替えさせるにはどういうやり方をすればいいかという質問でした。
実行環境は社内のユーザーにdockerを用意してもらう前提で、amazon等のcloudの利用は想定していません。
1.,のようにホストのディレクトリをマウントさせるのが普通ですかね？

>>178
差し替える方法はユーザーが自分達の環境に合わせて考えること、なのでイメージ提供者はあまり考えなくていい
どこに、どんな形式のファイルを置けばいいのか、だけを仕様として明確化すること

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

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

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

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

>>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サーバーとか動かすならコンテナオーケストレーターの機能は便利

>>380
コンテナ使うならシングルバイナリなんかいらんよｗ

シングルバイナリだと修正したときに全部ビルドし直しだろ？
それってDockerイメージ作り直しと同じことしてるだけだからね

シングルバイナリビルドし直しOKなら
Dockerイメージビルドし直しもOKなはずだ

>>381
中間は？Ruby（Rails）のように1バイナリを
作るわけじゃないけど起動するのは1アプリ

>>379
> Interactiveなしの方はインタラクティブシェルに普通はある機能が省略されてて

それはモードの違いであってバイナリは同じ

HashiCorpのサービスはどれもこれもシングルバイナリだ
たしかにあそこまで行くとDocker要らんわ

だからDockerは（シングルバイナリとかを）使うためじゃなくて
開発者が自分で開発するときに使うもの

シングルバイナリを作るのが難しい場合もたくさんある
スクリプト言語なんかはほぼ全てそれ

開発者のためのもの

大は小を兼ねるってことで
DroneCIはDockerコンテナ内での実行しかできない
割り切った設計になってる

コンテナさえ対応しとけばいろんな言語向けのツールを個別に作らなくて済むからな

alpineはパッケージのバージョンを固定する方法がないから
どうしてもalpineベースのDockerイメージをビルドする時は前回より新しいバージョンがインストールされる可能性がある

The problem with Docker and Alpine’s package pinning
https://medium.com/@stschindler/the-problem-with-docker-and-alpines-package-pinning-18346593e891

単にパッケージのバージョンを指定すると、そのうちパッケージがリポジトリから消えてビルド出来なくなる

古いバージョンのリポジトリを使うなら可能だが、マイナーバージョンのアップデートはされるだろう

特定のパッケージだけ最新メジャーバージョンにしたいから
複数のリポジトリを使い分けするぜ！みたいな使い方は
一応可能らしいが、
公式にはサポートされてない

もっと気軽にDinDできればいいんだが

>>388
古いリポジトリがアーカイブされている必要もあるし、
結局、Debian、CentOS（8以前）とか、硬派なバージョン管理をしているdistroを使うしかないと思う。
そうでないと、ABI互換されへんしな。

>>389
気軽にできないってことは使い方が間違っているということだよ
何に使ってるのさ？仮想マシンを使えば？

k3dはdocker in dockerのReal world example
中で起動するのはdockerじゃなくてcontainerdだけど
docker in dockerと同じパターン

コンテナの中でk3sやcontainerdを動かす

ん？だからk3dに相当するようななものを作ってるの？って話だよ
そういうのは例外的なシステムだよね

>>389はCIで欲しいんじゃね？
知らんけど

だからTravisCIのようなCIフレームワークを開発してる
会社だったらほしいというのはわかるけど
そういうのは例外的だって話

>>394
主にCI、開発コンテナだな
あとたまにバックエンドでコマンドラインを多用するサービスなんかもあって、そこでもDinDを使いたくなる

Dockerfileで静的にインストールすると、コマンドラインのバージョンが固定されちまう
が、DinDだったらコマンドラインのバージョンを実行時にダイナミックに変更できる
DinDならオフィシャルのイメージを使えるってのもいいね
自前でパッケージインストールすると最適化がどうしても甘くなる