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/

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
>開発側にばノウハウが大量にあるのでなにも苦にならない
よくわかんない