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 images and their layers explained
https://dominikbraun.io/blog/docker/docker-images-and-their-layers-explained/

>>813
何がすばらしいのか解説してくれ。
長すぎて読むのが面倒くさい。

イメージレイヤーってすごいよね
複数イメージで共有してディスク領域や転送時間を節約できるし
いろいろ変更してもコンテナを立ち上げ直したら綺麗さっぱり消えるし

別に何も凄くないｗ

はてぶでバズってたけど
https://sysdig.jp/blog/dockerfile-best-practices/

特定のUIDにバインドしない
↑
UIDをバインドしないとパーミッションで書き込みできないんだよなLinuxでは

>>817
いいね。ベストプラクティスが広まればVMの代わりとして使おうとするやつも減るかも
これらのベストプラクティスはVMとして使えなくする制約に近いから

1. 不要な特権を避ける
　コンテナを root で実行しないようにする
　特定のUIDにバインドしない
　実行可能ファイルを root が所有し、書き込み可能ではないものする
2. 攻撃対象を減らす
　マルチステージビルドを活用する
　distroless イメージを使うか、ゼロからビルドする
　イメージを頻繁に更新する
　暴露されたポートに注意する
3. 機密データの漏洩を防ぐ
　Dockerfileの命令にシークレットや認証情報を入れないようにしましょう
　ADDよりもCOPYを優先してください
　Dockerのコンテキストを意識し、.dockerignoreを使用する
4. その他
　レイヤーの数を減らし、インテリジェントに並べる
　メタデータとラベルを追加する
　lintersを活用してチェックを自動化する
　開発中にイメージをローカルでスキャンする
5. イメージのビルドの先には
　docker socketとTCP接続を保護します
　イメージに署名し、実行時に検証します
　タグの変異を避ける
　環境を root で実行しない
　ヘルスチェックを含める
　アプリケーションの機能を制限する

やっぱdockerならではのめんどくささってあるよな

>>819
これが面倒って感じるんだな ほぼ Dockerfile だけなのに無知は恥だよ

「面倒くさい」には二通りの意味がある

1. 作業が面倒くさい
2. 作業を"効率化するのが"面倒くさい


>>819の意味は2番目

>Dockerfileの命令にシークレットや認証情報を入れないようにしましょう

ってDockerは単体でシークレット提供して無いじゃん。
何でdaemonで動いてる癖にdocker composeから使えるsecret提供しないんだ？

っていっても今じゃ Buildx もあるしな

>>822
お前シークレットを何だと思ってるんだ？
アプリのバイナリの中に秘密情報入れないだろ
Dockerも同じでDockerイメージの中に秘密情報を入れたりしないんだよ

で、Dockerコンテナ（＝アプリ）起動時に、Dockerの外の情報に
環境変数やボリュームでアクセスできるんだから何の問題もない

訂正

Dockerコンテナ（＝アプリ）起動時に、環境変数やボリュームで
認証情報を含む任意の情報を渡せるんだから何の問題もない

>>824
馬鹿は黙っててね。よろしくｗ

馬鹿じゃないから黙らないし
何も言い返せないのはお前だ

何度もいうが匿名掲示板で馬鹿を見抜くのもエンジニアのスキル。
とっくの昔に概出なのに理解できてねーとか
マジなんでそんな馬鹿が生きていけるんだ？

戯言言うばかりで「言い返さない」のが何よりの証拠

> 概出
バカは見つかったみたいだな

馬鹿って本当、大変だよな！一人でシコシコ自己満足のプログラムばっかり作って悦に浸ってるんだろうｗ
チーム開発なんてやったことも無いんだろうねｗ

な？「言い返してない」の部分を見なかったことにしてるだろ？

ヒントは概出。
ちゃんと過去を遡れば話は出ている。
馬鹿には理解できないだろうけどｗ
・・・俺って優しいな！771とか馬鹿発見したらレスしないもんなｗ
カネも貰ってないのに手取り足取り教えてあげたしねーけどｗ
お前のレスは大体一発目で「あ、この人現場で作業してないな」ってのが透けて見えるんだよｗ
その癖謎の上から目線だから、ただの馬鹿にしか見えないｗｗ
本当、馬鹿ってどうしようもないよな！

言い訳ばかり口達者

またこの流れだ…

UIDを指定できるようにするべきだね
そんなのWindowsだったらはまらないけど
Linuxで動かすときにボリュームマウントしたときにファイルの編集ができないカラ

>>820
いや面倒だろ
そのぐらい自動でやってくれ
〜〜を気にしながら書かないとダメなんてのはすべてめんどくさい

>>837
じゃあそのまま時代遅れの老害で居てください笑

https://sysdig.jp/blog/dockerfile-best-practices/ の意識が高すぎて読めなかった

特定のUIDにバインドしないってどういうことだ
まいかいランダムにUID決めるってか？

>>837
メンテナンス性を気にしながら書かないとダメなんてのはすべてめんどくさい

ってお前言ってるだろ？ｗ

>>840
https://sysdig.jp/blog/dockerfile-best-practices/
> Openshift はデフォルトでは、コンテナを実行する際にランダムな UID を使用します。

「Openshiftは絶対に使わない」ことが保証されているなら無視しても良いかも知れない

YAGNI

Openshiftへの対応が必要になることはない

毎回UID違うってボリューム使わんのか

OpenShiftなんか非対応で結構、むしろ積極的に非対応にすべき
IBMがオンプレや自社クラウドで顧客を囲い込むためだけに存在する有害な技術だよ

dockerHubにあるApacheとかnginxのイメージって最初からroot以外で動いてるよね？

UIDの話はDockerの問題じゃなくてOpenShift特有の問題

Why do my applications run as a random user ID?
https://cookbook.openshift.org/users-and-role-based-access-control/why-do-my-applications-run-as-a-random-user-id.html

プロジェクト固有のUIDを割り当てる事で
マルチテナント環境でも
他のアプリのデータが読める事が無いようにって事らしい

そんな事はあり得ないなんて思われがちな
他のセキュリティ対策が破られるという想定外を想定するのがレッドハットなんだろう

A Guide to OpenShift and UIDs
https://www.openshift.com/blog/a-guide-to-openshift-and-uids

イメージに予めファイルやディレクトリを入れる時に
アプリが読み書きするファイルやディレクトリはrootグループに所属させる
rootグループに所属してるユーザーなら読み書き出来るようになるので、
UIDがプロジェクト固有のランダムIDでも問題ないって事らしい

それだとroot所属してる他プロジェクトのユーザーも
読み書き出来ちゃうんでは？って思うけど
新しく作成するファイルはグループIDが0（root）じゃなくてそのユーザーIDと同じグループIDになるんじゃね？
しらんけど

テナントごとに異なるUIDが割り当てられればいいだけであって、別にランダムにする必要はないよね
むしろランダムにしたせいでうっかりかぶっちゃいました、ランダムなのでテスト見逃しましたみたいな変なミスしそう

root を取られないように、
UID に、1,000 を足すようなシステムがあったような

1 → 1,001
2 → 1,002

>>849
IDの範囲をテナント別で衝突しないように割り当てるんじゃね？
しらんけど

>>849
他のテナントのUIDが推測できればそれを攻撃に利用できる可能性もないとは言えないからでしょ

>>852
OpenShiftはランダムと言ってますが、それはコンテナごとに
違うという意味で、実際には推測可能なUIDが割り当てられます

namespaceを作るとUID、GIDの範囲が自動的に割り当てられ
同じnamespace内のポッドは同じUIDとグループIDになる

これによって他のnamespaceやホストマシンで動いてるプロセスが使用してるファイルなど、
無関係のファイルを読み書き出来てしまうのを防ぐ

何も指定しないとUIDとGIDは範囲内で使える最初の値になるようだ
だから同じ名前空間内のボリュームだったら
どのポッドも読み書きできるね

podがどうのこうのと言っている時点で既にDockerの話じゃないんだけどな。
不特定のnode, podに対してUSER指定させたらマルチテナント環境でバッティングするから
ランダムにしよーぜなんてのはDockerレベルで考える事じゃない。

今話をしてるのはUIDの話であって
USER指定の話ではない

>>6
Chromeでもエラー出るようになったｗｗｗ

レスする場所間違えたｗ

ほらなdockerならではの面倒くささあるじゃん

>>859
それを判断するのは、お前がDockerを使わない場合に
同じ問題をどう解決できるかを言ってからだ

早くレスしてくれ

はいいつもの奴NG

ほらな？逃げただろ。こいつは反論が一切できない。
なぜならNGにして見えないからだｗ

まあ実際は見てるんだろうがな
だから実際には反論できないというが正解

>>855
ランダムUIDは万が一コンテナのサンドボックスが破られてホストに侵入された時のためで
ファイルの所有者がバッティングするからどうこうではない

ランダムなら何度も繰り返し攻撃したらそのうち通るんじゃね

この流れでコンテナのサンドボックスが破られるぐらいなら
最初からDocker（コンテナ）を使わずに、サンドボックスの外で
直接動かせばいいとか言うんだろうなｗ

OpenShiftのためだけにUID指定するながベストプラクティスってやべえな

Dev image作る人
Ops image使う人
☝あってる？

>>867
あってる
ただしDevが作るイメージとは自分たちで開発したアプリのイメージ

自分たちで開発してないアプリ、オープンソースなどは
Docker公式や開発公式が作ってることが多いので
そういうのをイメージする作業は開発とは言わない

アプリ開発の一環としてDockerイメージも作る

Introducing fixuid: Tool for Changing Docker Container UID/GID at Runtime
https://boxboat.com/2017/07/25/fixuid-change-docker-container-uid-gid/

One of the most helpful things about using Docker containers for development is that it reduces developer onboarding time from a few days to a few hours or less.
Developers are able to clone a repository, start a container or run Docker compose, and start contributing immediately.

Development containers are often very different from production containers.
They usually include package managers, build tools, SDKs, remote debugging, and more.
Source code can be mounted into the development container via a host mount and changes can be immediately re-rendered via live-reload build tools.

This is where the road gets bumpy – Docker containers run as a single user. Users/groups, UIDs/GIDs, and file ownership must be decided when an image is built with docker build.

Host volumes, however, are owned by a user on the host and the host user's UID may or may not match the container user's UID.
There's an issue in the Moby repository with over 100 comments about this very topic.

Host volumes are mounted using bind mounts in Linux.
There is no way to remap UIDs/GIDs using bind mounts so often development containers end up with a mismatch of UIDs/GIDs.
This is why we created fixuid, a tool to change a Docker container's user/group and file permissions that were set at build time to the UID/GID that the container was started with at runtime.

To explain how fixuid solves this problem, let's take a look at a story about Alice and Bob, who are both developers working with development Docker containers.

nix使ったらDockerイメージのマージはできないけど
nixのパッケージ使ってDockerイメージ作れば似たような事は出来るね

使いたいCLIツールのパッケージが依存してるランタイムのバージョンが違ってても共存させる事が出来る
No dependency hell

ビルド時にだけ必要なパッケージと
実行時に必要なパッケージが明確に区別されてるので
要らない一時ファイルを誤ってDockerイメージに含める心配がない

nixpkgsのパッケージが豊富だし
無くても自分で書けば良い
GitHubで自作パッケージを公開し、ビルド済みバイナリをcachixに置いておけば
複数のプロジェクトから再ビルドせずに使い回せる

https://mao.5ch.net/test/read.cgi/linux/1597591176/98

98 login:Penguin sage 2020/08/28(金) 11:22:41.35 ID:0ih4XZ3G
イメージのマージ機能はいつになったらサポートされんだ
devcontainer作るときいちいちインストール方法調べてDockerfile書くの不便なんだが

前にも言ったと思うけど
俺らが本当に欲しかったものってdockerじゃなくてスマートなパッケージマネージャ(とリポジトリ)なんだよね
Container imageってアイデアは失敗だった

一応nixにもnixパッケージ使って隔離されたNixOS環境を作る
nixos-containerってのがあるがDockerみたいに完璧な隔離ではないらしい

nixos-containerの隔離が完璧になって
自前のバイナリキャッシュも
ローカルのnixストアみたいにGCで最小構成で保存出来たら
Dockerみたいに使えるかも

あらゆるCLIツールがnixでインストール可能になれば
開発環境ではnix-shell使って
本番では必要なパッケージを一つに固めたDockerイメージをk8sとかで使うってやり方が実現できる
そんな世界をまず目指そう

そうじゃなくて
開発も本番もパッケージはホストにインストールするんだよ
で本番はコンテナにパッケージを読み取り専用でマウントすんの
全部固めたイメージなんてものは要らない

>>871
> 俺らが本当に欲しかったものってdockerじゃなくてスマートなパッケージマネージャ(とリポジトリ)なんだよね

パッケージマネージャーだけだと
実行するときの分離ができないだろ

「俺らが」じゃなくて「お前が」欲しいものはパッケージマネージャーなので
Dockerでパッケージマネージャー相当のことがしたい
できないのは苦痛だなどと言わないように
お前の目的にあってないのよ

Dockerは開発者が自分で作ったアプリを
デプロイするためのツールだって何度も言ってるだろ

それをやろうとしてるのはnixos-containerじゃね
コンテナ起動時にパッケージへのシンボリックリンクを動的につくるか、
PATHをパッケージの絶対パスで埋め尽くせばDockerでも行けそう

後はバイナリキャッシュのバイナリだけを利用するとか、実行時に必要なパッケージだけをダウンロードするモードがnixにないとか
その辺がなんとかなれば
本番で不要なビルド用パッケージを落としたりソースからビルドとかしたくないし

nix expressionの評価が遅いって問題もあるが
それはnix flakesで解決しそう

dockerTools.buildLayeredImage使えば
パッケージ毎にイメージレイヤーを作ってくれるので
ストレージ効率は良い
ただ、Dockerのレイヤー数は128までなので
それを超えると最後の方のレイヤーは合体される

これも最後のイメージレイヤーは各パッケージへのシンボリックリンクになる
ビルド用パッケージは除外されるし
現状では最適解

>>874

なんでパッケージマネージャーが欲しいやつがDockerなんて使おうとするんだろ？ｗ

例えばapacheのDockerイメージ、nginxのDockerイメージ
どちらもポート80で起動する

というDockerイメージを、同一のホストで複数起動する場合どうすればいいのか？
Dockerイメージを変更すること無く、待受ポート番号を変更するにはどうすればいいのか？
それができるように作られたのがDockerなんだが

ファイルを置くだけのパッケージマネージャーじゃこんな事はできない
実行時のプロセスの分離を行う仕組みが必要

>>875
実行する時の分離はできるだろ
コンテナに読み取り専用でマウントするだけ

>>877
nginxのパッケージを入れて2つの隔離されたnginxプロセスを起動するだけだろ

独自のコンテナランタイムとか作らないってこと？

今使ってるコンテナのイメージレイヤーは削除出来たらだめって挙動をパッケージでやるのは
独自のコンテナランタイム作らずには難しくね

今コンテナで使ってるパッケージを削除してしまったり
逆に古いパッケージが消えないってなりそう

>>879
> nginxのパッケージを入れて2つの隔離されたnginxプロセスを起動するだけだろ

パッケージを１つだけ入れて２つのnginxプロセスを起動したりしたいんだよ
それもnginxの設定を変更せずに

Dockerとパッケージマネージャーは使う目的が全く違うんだから

パッケージマネージャーが欲しい人がDockerをパッケージマネージャーの代わりとして使って
「Dockerはパッケージマネージャーで代用できる！」なんて適当なことを言わないでくれ

それはお前がDockeをパッケージマネージャーという
間違った用途で使ってるだけだ

ただの設定ファイルの形式変えてるだけじゃん
イメージいらないって、イメージなくしてどうやって起動速度上げるのさ？
どうやって全く同じイメージだと保証できるのさ？

同じ設定ファイルから作ったとしても一年後にやって同じイメージが出来る保証はない

済まない
↑のリポジトリのURLは適当に架空のURLを書いたつもりだったが存在するドメインだったので無視してくれ

あとrubyしか書いてないけど、ディストリに含まれる
全てのライブラリのバージョンも書かないと駄目だろｗ

>>884
ファイル形式を変えてるだけじゃない
パッケージを分離してる
イメージは必要ない
必要なのはパッケージ、メタデータだけ

>>886
rubyに必要な依存はrubyパッケージのメタデータに書く

多数の仮想マシンに同一のイメージを配布することは出来るが
多数の仮想マシンに設定ファイルから一からインストールするなんて時間かかるし

すべてのファイル（OSに含まれる全てのファイル）を、そのリポジトリとやらに
アップしてそれをダウンロードして使うってならそれがDockerのイメージの仕組みです
としか言いようがない

メタデータから再インストールするのは
時間がかかるって言ってます。

完成済みのファイルをコピーしたほうがずっと速い
それがイメージ

>>889
dockerとの違いはイメージに固めないこと
これによって同じパッケージを使うアプリでパッケージ共有できる
ディスク容量や通信時間を大幅に節約できる

>>890
重複を避けて少量のファイルをpullしたほうが速い
imageだと同じパッケージを使ってても別のimageと認識されるから無駄が大きすぎる

パッケージだけあったって、インストールの順番で
出来上がるものは違うだろうが

あとからnanoをインストールするのと
あとからvimをインストールするので
同じものが出来ると思うか？

> 重複を避けて少量のファイルをpullしたほうが速い
だからそれがイメージ

>>893
インストール順番に依存しないようにするための賢いパッケージマネージャだろ
Dockerfileは手続き型だから順番を気にしないといけないがnixのような関数型のパッケージマネージャならそれを克服できるというわけだ

パッケージだけあったって、同じイメージは作れないんだが？
インストール済みの状態のファイル＝レイヤーが必要

nixのような関数型のパッケージマネージャは
バージョンごとに複数のパッケージをインストールするというだけ

>>894
imageでは重複をうまく回避できない
RUN xxx
RUN apt-get hoge

RUN yyy
RUN apt-get hoge

たったこれだけで別物と見なされてhogeの重複ダウンロードされる
これじゃ効率が悪すぎる

そしてnixのような関数型のパッケージマネージャは
ポート番号を変えて起動とかしてくれない

Dockerの目的をパッケージマネージャーは満たしてくれてない

>>896
パッケージバージョンを完全に指定すれば同じ

>>899
起動時のオプションで変えるだけ

>>898
> たったこれだけで別物と見なされてhogeの重複ダウンロードされる

nixのような関数型のパッケージマネージャも
バージョンが異なれば重複ダウンロードされる

>>901
「パッケージマネージャー」に起動時のオプションを変更する機能があるんですか？ｗ

>>902
imageの場合はバージョンが全く同じでも重複
パッケージマネージャはバージョンが同じなら重複ダウンロードしない

>>903
いやいやそうなるように作るべきって話だろ
今はまだ無い賢いパッケージマネージャの話をしてんだ

nixはbrewやyum, apt-getみたいなのじゃないぞ
nixはパッケージマネージャーの皮を被ったビルドツールだ
ビルド結果をS3に保存できるのはバイナリキャッシュ機能のおかげ

ビルド時のフラグや依存関係などを利用して生成したユニークIDを自動的にパッケージに付ける
少しでも設定変えればIDも変わる

パッケージはみんな/nix/storeの下に入る
/usrを直接変えるような事はしない
使う時は各パッケージの/binにsymlinkをはる

次スレわっちょい付けますか？

今の所不要じゃね