[過去ﾛｸﾞ] Docker Part5 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
795: 運用情報臨時板でワッチョイ導入議論中 2021/03/10(水)12:04 ID:uMYHMW6J(4/11) AAS
マネージドK8S必須だとして、それをDockerを使わないでやる場合
どうやるのか？そっちの方がコストかかるだろって話なんだが
結局逃げたもんなｗ
クラウドでマネージドK8S必須、つまりクラスタ構成で
Dockerよりも金がかからない方法があるなら言ってみろって
例えその方法を出した所で、その方法＋DockerならマネージドK8S使わないから
サーバーへのデプロイが楽になる分、コストは下がりますねという反論が控えてるわけだがｗ
796: 運用情報臨時板でワッチョイ導入議論中 2021/03/10(水)12:06 ID:yB05zoUe(1) AAS
podman
797: 運用情報臨時板でワッチョイ導入議論中 2021/03/10(水)12:38 ID:vS2MWwBS(3/6) AAS
会話の滑りっぷりがひどすぎｗ
798: 運用情報臨時板でワッチョイ導入議論中 2021/03/10(水)12:42 ID:01iiLQ7f(1) AAS
Docker を NG ワードにしたらすっきりした
799: 運用情報臨時板でワッチョイ導入議論中 2021/03/10(水)13:09 ID:Eu5Q0iPT(1) AAS
podman 2 〜Dr. ワイリーの謎〜
800: 運用情報臨時板でワッチョイ導入議論中 2021/03/10(水)14:08 ID:uMYHMW6J(5/11) AAS
これの話だってわかってないやつがいるのか？
> 771 名前：運用情報臨時板でワッチョイ導入議論中[sage] 投稿日：2021/03/09(火) 20:14:53.28 ID:Ui3x5dki
> ホスト管理がめんどくさい
> ボリューム管理がめんどくさい
> セキュリティ対策がめんどくさい
801: 運用情報臨時板でワッチョイ導入議論中 2021/03/10(水)14:25 ID:vS2MWwBS(4/6) AAS
君が会話していると思い込んでいる相手はそんな話をしていない。
802: 運用情報臨時板でワッチョイ導入議論中 2021/03/10(水)14:55 ID:uMYHMW6J(6/11) AAS
逆だろう。俺は最初からそいつとしか会話してないんだが
関係ないやつが絡んできてる
803(1): 運用情報臨時板でワッチョイ導入議論中 2021/03/10(水)15:20 ID:vS2MWwBS(5/6) AAS
771を発端とした会話は772が既にお門違いで滑ってるがｗ
804: 運用情報臨時板でワッチョイ導入議論中 2021/03/10(水)15:21 ID:uMYHMW6J(7/11) AAS
>>803
どこがお門違いなの？
まずそこでしょう
805: 運用情報臨時板でワッチョイ導入議論中 2021/03/10(水)15:22 ID:uMYHMW6J(8/11) AAS
何も言い返さないくせに
「お、お門違いだから（ふるえ）」はやめたほうがいいよ
806(1): 運用情報臨時板でワッチョイ導入議論中 2021/03/10(水)16:38 ID:vS2MWwBS(6/6) AAS
>馬鹿を見抜くのもエンジニアのスキル
って言ってるだろ？771がレス返さなくなったと言うなら、そいつは（多分）優秀だよ。
たった1回のやり取りで「あコイツと会話続けても無駄だな」と悟ったのだろう。
807: 運用情報臨時板でワッチョイ導入議論中 2021/03/10(水)17:20 ID:uMYHMW6J(9/11) AAS
何も言い返せなくなったからレスしてないだけ
808: 運用情報臨時板でワッチョイ導入議論中 2021/03/10(水)17:21 ID:uMYHMW6J(10/11) AAS
>>806
なんなら代わりにお前がレスすればいいし、他の誰でも引き継いでレスすればいい
誰も>>771の後を引き継がないのは、>>771に勝ち目がないからだよ
809: 運用情報臨時板でワッチョイ導入議論中 2021/03/10(水)17:23 ID:+wwE/KLD(1) AAS
勝ちとか負けとか変なこだわりがある人がいるんすねぇ...
810: 運用情報臨時板でワッチョイ導入議論中 2021/03/10(水)17:33 ID:Q8+Vst7D(2/2) AAS
明らかにいつもの奴だしワンパだからレスバしても発展性ないんだよね
ワッチョイが待ち遠しい
811: 運用情報臨時板でワッチョイ導入議論中 2021/03/10(水)20:21 ID:ivn403GC(2/2) AAS
レスバに勝ちたい！
812: 運用情報臨時板でワッチョイ導入議論中 2021/03/10(水)20:23 ID:uMYHMW6J(11/11) AAS
あなたはそうなんですね
813(1): 運用情報臨時板でワッチョイ導入議論中 2021/03/10(水)22:19 ID:jGOWOSeF(1) AAS
Docker images and their layers explained
外部ﾘﾝｸ:dominikbraun.io
814: 2021/03/11(木)21:12 ID:T3GHjcYC(1/2) AAS
>>813
何がすばらしいのか解説してくれ。
長すぎて読むのが面倒くさい。
815: 2021/03/11(木)21:27 ID:/6wLYBLL(1) AAS
イメージレイヤーってすごいよね
複数イメージで共有してディスク領域や転送時間を節約できるし
いろいろ変更してもコンテナを立ち上げ直したら綺麗さっぱり消えるし
816: 2021/03/11(木)23:39 ID:T3GHjcYC(2/2) AAS
別に何も凄くないｗ
817(1): 2021/03/12(金)10:29 ID:Is0xlw0S(1/2) AAS
はてぶでバズってたけど
外部ﾘﾝｸ:sysdig.jp
特定のUIDにバインドしない
↑
UIDをバインドしないとパーミッションで書き込みできないんだよなLinuxでは
818: 2021/03/12(金)10:43 ID:Ckt9hMHN(1/9) AAS
>>817
いいね。ベストプラクティスが広まればVMの代わりとして使おうとするやつも減るかも
これらのベストプラクティスはVMとして使えなくする制約に近いから
1. 不要な特権を避ける
コンテナを root で実行しないようにする
特定のUIDにバインドしない
実行可能ファイルを root が所有し、書き込み可能ではないものする
2. 攻撃対象を減らす
マルチステージビルドを活用する
distroless イメージを使うか、ゼロからビルドする
省18
819(2): 2021/03/12(金)11:38 ID:fsIGodsX(1) AAS
やっぱdockerならではのめんどくささってあるよな
820(1): 2021/03/12(金)14:34 ID:M0oFRexN(1/4) AAS
>>819
これが面倒って感じるんだな ほぼ Dockerfile だけなのに無知は恥だよ
821: 2021/03/12(金)15:29 ID:Ckt9hMHN(2/9) AAS
「面倒くさい」には二通りの意味がある
1. 作業が面倒くさい
2. 作業を"効率化するのが"面倒くさい
>>819の意味は2番目
822(1): 2021/03/12(金)15:41 ID:y0GdntGH(1/5) AAS
>Dockerfileの命令にシークレットや認証情報を入れないようにしましょう
ってDockerは単体でシークレット提供して無いじゃん。
何でdaemonで動いてる癖にdocker composeから使えるsecret提供しないんだ？
823: 2021/03/12(金)16:05 ID:M0oFRexN(2/4) AAS
っていっても今じゃ Buildx もあるしな
824(1): 2021/03/12(金)16:25 ID:Ckt9hMHN(3/9) AAS
>>822
お前シークレットを何だと思ってるんだ？
アプリのバイナリの中に秘密情報入れないだろ
Dockerも同じでDockerイメージの中に秘密情報を入れたりしないんだよ
で、Dockerコンテナ（＝アプリ）起動時に、Dockerの外の情報に
環境変数やボリュームでアクセスできるんだから何の問題もない
825: 2021/03/12(金)16:26 ID:Ckt9hMHN(4/9) AAS
訂正
Dockerコンテナ（＝アプリ）起動時に、環境変数やボリュームで
認証情報を含む任意の情報を渡せるんだから何の問題もない
826: 2021/03/12(金)16:28 ID:y0GdntGH(2/5) AAS
>>824
馬鹿は黙っててね。よろしくｗ
827: 2021/03/12(金)16:30 ID:Ckt9hMHN(5/9) AAS
馬鹿じゃないから黙らないし
何も言い返せないのはお前だ
828: 2021/03/12(金)16:32 ID:y0GdntGH(3/5) AAS
何度もいうが匿名掲示板で馬鹿を見抜くのもエンジニアのスキル。
とっくの昔に概出なのに理解できてねーとか
マジなんでそんな馬鹿が生きていけるんだ？
829: 2021/03/12(金)16:33 ID:Ckt9hMHN(6/9) AAS
戯言言うばかりで「言い返さない」のが何よりの証拠
830: 2021/03/12(金)16:38 ID:rhpCrQLw(1) AAS
> 概出
バカは見つかったみたいだな
831: 2021/03/12(金)16:41 ID:y0GdntGH(4/5) AAS
馬鹿って本当、大変だよな！一人でシコシコ自己満足のプログラムばっかり作って悦に浸ってるんだろうｗ
チーム開発なんてやったことも無いんだろうねｗ
832: 2021/03/12(金)16:44 ID:Ckt9hMHN(7/9) AAS
な？「言い返してない」の部分を見なかったことにしてるだろ？
833: 2021/03/12(金)16:53 ID:y0GdntGH(5/5) AAS
ヒントは概出。
ちゃんと過去を遡れば話は出ている。
馬鹿には理解できないだろうけどｗ
・・・俺って優しいな！771とか馬鹿発見したらレスしないもんなｗ
カネも貰ってないのに手取り足取り教えてあげたしねーけどｗ
お前のレスは大体一発目で「あ、この人現場で作業してないな」ってのが透けて見えるんだよｗ
その癖謎の上から目線だから、ただの馬鹿にしか見えないｗｗ
本当、馬鹿ってどうしようもないよな！
834: 2021/03/12(金)16:58 ID:Ckt9hMHN(8/9) AAS
言い訳ばかり口達者
835: 2021/03/12(金)17:10 ID:M0oFRexN(3/4) AAS
またこの流れだ…
836: 2021/03/12(金)17:31 ID:Is0xlw0S(2/2) AAS
UIDを指定できるようにするべきだね
そんなのWindowsだったらはまらないけど
Linuxで動かすときにボリュームマウントしたときにファイルの編集ができないカラ
837(2): 2021/03/12(金)18:44 ID:I1TSqDN6(1) AAS
>>820
いや面倒だろ
そのぐらい自動でやってくれ
〜〜を気にしながら書かないとダメなんてのはすべてめんどくさい
838: 2021/03/12(金)20:11 ID:M0oFRexN(4/4) AAS
>>837
じゃあそのまま時代遅れの老害で居てください笑
839: 2021/03/12(金)23:04 ID:FvB/dbLo(1/2) AAS
外部ﾘﾝｸ:sysdig.jp の意識が高すぎて読めなかった
840(1): 2021/03/12(金)23:13 ID:Si74965R(1) AAS
特定のUIDにバインドしないってどういうことだ
まいかいランダムにUID決めるってか？
841: 2021/03/12(金)23:15 ID:Ckt9hMHN(9/9) AAS
>>837
メンテナンス性を気にしながら書かないとダメなんてのはすべてめんどくさい
ってお前言ってるだろ？ｗ
842: 2021/03/12(金)23:56 ID:FvB/dbLo(2/2) AAS
>>840
外部ﾘﾝｸ:sysdig.jp
> Openshift はデフォルトでは、コンテナを実行する際にランダムな UID を使用します。
「Openshiftは絶対に使わない」ことが保証されているなら無視しても良いかも知れない
843: 2021/03/13(土)00:03 ID:67vo3F6m(1) AAS
YAGNI
Openshiftへの対応が必要になることはない
844: 2021/03/13(土)00:55 ID:fBnyEFkA(1/3) AAS
毎回UID違うってボリューム使わんのか
845: 2021/03/13(土)02:05 ID:iF+JSheD(1) AAS
OpenShiftなんか非対応で結構、むしろ積極的に非対応にすべき
IBMがオンプレや自社クラウドで顧客を囲い込むためだけに存在する有害な技術だよ
846: 2021/03/13(土)08:24 ID:OV1njusz(1) AAS
dockerHubにあるApacheとかnginxのイメージって最初からroot以外で動いてるよね？
847: 2021/03/13(土)08:49 ID:OkB9sWH0(1/2) AAS
UIDの話はDockerの問題じゃなくてOpenShift特有の問題
848: 2021/03/13(土)11:03 ID:w6Cw4gKa(1/4) AAS
Why do my applications run as a random user ID?
外部ﾘﾝｸ[html]:cookbook.openshift.org
プロジェクト固有のUIDを割り当てる事で
マルチテナント環境でも
他のアプリのデータが読める事が無いようにって事らしい
そんな事はあり得ないなんて思われがちな
他のセキュリティ対策が破られるという想定外を想定するのがレッドハットなんだろう
A Guide to OpenShift and UIDs
外部ﾘﾝｸ:www.openshift.com
イメージに予めファイルやディレクトリを入れる時に
省7
849(2): 2021/03/13(土)12:25 ID:Iwj7PB1I(1) AAS
テナントごとに異なるUIDが割り当てられればいいだけであって、別にランダムにする必要はないよね
むしろランダムにしたせいでうっかりかぶっちゃいました、ランダムなのでテスト見逃しましたみたいな変なミスしそう
850: 2021/03/13(土)13:46 ID:fKVUCcqC(1) AAS
root を取られないように、
UID に、1,000 を足すようなシステムがあったような
1 → 1,001
2 → 1,002
851: 2021/03/13(土)13:54 ID:w6Cw4gKa(2/4) AAS
>>849
IDの範囲をテナント別で衝突しないように割り当てるんじゃね？
しらんけど
852(1): 2021/03/13(土)14:12 ID:kGTBX6vY(1) AAS
>>849
他のテナントのUIDが推測できればそれを攻撃に利用できる可能性もないとは言えないからでしょ
853: 2021/03/13(土)14:35 ID:OkB9sWH0(2/2) AAS
>>852
OpenShiftはランダムと言ってますが、それはコンテナごとに
違うという意味で、実際には推測可能なUIDが割り当てられます
854: 2021/03/13(土)16:08 ID:w6Cw4gKa(3/4) AAS
namespaceを作るとUID、GIDの範囲が自動的に割り当てられ
同じnamespace内のポッドは同じUIDとグループIDになる
これによって他のnamespaceやホストマシンで動いてるプロセスが使用してるファイルなど、
無関係のファイルを読み書き出来てしまうのを防ぐ
何も指定しないとUIDとGIDは範囲内で使える最初の値になるようだ
だから同じ名前空間内のボリュームだったら
どのポッドも読み書きできるね
855(1): 2021/03/13(土)19:00 ID:CGLHT5pS(1) AAS
podがどうのこうのと言っている時点で既にDockerの話じゃないんだけどな。
不特定のnode, podに対してUSER指定させたらマルチテナント環境でバッティングするから
ランダムにしよーぜなんてのはDockerレベルで考える事じゃない。
856: 2021/03/13(土)19:28 ID:nRE6g312(1/6) AAS
今話をしてるのはUIDの話であって
USER指定の話ではない
857: 2021/03/13(土)19:29 ID:nRE6g312(2/6) AAS
>>6
Chromeでもエラー出るようになったｗｗｗ
858: 2021/03/13(土)19:30 ID:nRE6g312(3/6) AAS
レスする場所間違えたｗ
859(1): 2021/03/13(土)19:38 ID:fBnyEFkA(2/3) AAS
ほらなdockerならではの面倒くささあるじゃん
860: 2021/03/13(土)19:45 ID:nRE6g312(4/6) AAS
>>859
それを判断するのは、お前がDockerを使わない場合に
同じ問題をどう解決できるかを言ってからだ
早くレスしてくれ
861: 2021/03/13(土)19:52 ID:fBnyEFkA(3/3) AAS
はいいつもの奴NG
862: 2021/03/13(土)19:54 ID:nRE6g312(5/6) AAS
ほらな？逃げただろ。こいつは反論が一切できない。
なぜならNGにして見えないからだｗ
まあ実際は見てるんだろうがな
だから実際には反論できないというが正解
863: 2021/03/13(土)20:04 ID:w6Cw4gKa(4/4) AAS
>>855
ランダムUIDは万が一コンテナのサンドボックスが破られてホストに侵入された時のためで
ファイルの所有者がバッティングするからどうこうではない
864: 2021/03/13(土)20:07 ID:WuKb+LRj(1) AAS
ランダムなら何度も繰り返し攻撃したらそのうち通るんじゃね
865: 2021/03/13(土)20:12 ID:nRE6g312(6/6) AAS
この流れでコンテナのサンドボックスが破られるぐらいなら
最初からDocker（コンテナ）を使わずに、サンドボックスの外で
直接動かせばいいとか言うんだろうなｗ
866: 2021/03/13(土)21:43 ID:9K/sAZAs(1) AAS
OpenShiftのためだけにUID指定するながベストプラクティスってやべえな
867(1): 2021/03/17(水)19:41 ID:ajiqTOqm(1) AAS
Dev image作る人
Ops image使う人
☝あってる？
868: 2021/03/18(木)01:46 ID:4WrbQg+w(1) AAS
>>867
あってる
ただしDevが作るイメージとは自分たちで開発したアプリのイメージ
自分たちで開発してないアプリ、オープンソースなどは
Docker公式や開発公式が作ってることが多いので
そういうのをイメージする作業は開発とは言わない
アプリ開発の一環としてDockerイメージも作る
869: 2021/03/18(木)09:38 ID:QA403diq(1) AAS
Introducing fixuid: Tool for Changing Docker Container UID/GID at Runtime
外部ﾘﾝｸ:boxboat.com
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.
省4
870: 2021/03/19(金)13:01 ID:edcYEDQK(1/6) AAS
nix使ったらDockerイメージのマージはできないけど
nixのパッケージ使ってDockerイメージ作れば似たような事は出来るね
使いたいCLIツールのパッケージが依存してるランタイムのバージョンが違ってても共存させる事が出来る
No dependency hell
ビルド時にだけ必要なパッケージと
実行時に必要なパッケージが明確に区別されてるので
要らない一時ファイルを誤ってDockerイメージに含める心配がない
nixpkgsのパッケージが豊富だし
無くても自分で書けば良い
GitHubで自作パッケージを公開し、ビルド済みバイナリをcachixに置いておけば
省5
871(1): 2021/03/19(金)13:14 ID:dlChmxiq(1/2) AAS
前にも言ったと思うけど
俺らが本当に欲しかったものってdockerじゃなくてスマートなパッケージマネージャ(とリポジトリ)なんだよね
Container imageってアイデアは失敗だった
872: 2021/03/19(金)13:43 ID:edcYEDQK(2/6) AAS
一応nixにもnixパッケージ使って隔離されたNixOS環境を作る
nixos-containerってのがあるがDockerみたいに完璧な隔離ではないらしい
nixos-containerの隔離が完璧になって
自前のバイナリキャッシュも
ローカルのnixストアみたいにGCで最小構成で保存出来たら
Dockerみたいに使えるかも
873: 2021/03/19(金)15:13 ID:edcYEDQK(3/6) AAS
あらゆるCLIツールがnixでインストール可能になれば
開発環境ではnix-shell使って
本番では必要なパッケージを一つに固めたDockerイメージをk8sとかで使うってやり方が実現できる
そんな世界をまず目指そう
874(1): 2021/03/19(金)15:28 ID:OafZaxWN(1/15) AAS
そうじゃなくて
開発も本番もパッケージはホストにインストールするんだよ
で本番はコンテナにパッケージを読み取り専用でマウントすんの
全部固めたイメージなんてものは要らない
875(1): 2021/03/19(金)16:22 ID:R4CRH11B(1/18) AAS
>>871
> 俺らが本当に欲しかったものってdockerじゃなくてスマートなパッケージマネージャ(とリポジトリ)なんだよね
パッケージマネージャーだけだと
実行するときの分離ができないだろ
「俺らが」じゃなくて「お前が」欲しいものはパッケージマネージャーなので
Dockerでパッケージマネージャー相当のことがしたい
できないのは苦痛だなどと言わないように
お前の目的にあってないのよ
Dockerは開発者が自分で作ったアプリを
デプロイするためのツールだって何度も言ってるだろ
876: 2021/03/19(金)16:25 ID:edcYEDQK(4/6) AAS
それをやろうとしてるのはnixos-containerじゃね
コンテナ起動時にパッケージへのシンボリックリンクを動的につくるか、
PATHをパッケージの絶対パスで埋め尽くせばDockerでも行けそう
後はバイナリキャッシュのバイナリだけを利用するとか、実行時に必要なパッケージだけをダウンロードするモードがnixにないとか
その辺がなんとかなれば
本番で不要なビルド用パッケージを落としたりソースからビルドとかしたくないし
nix expressionの評価が遅いって問題もあるが
それはnix flakesで解決しそう
dockerTools.buildLayeredImage使えば
パッケージ毎にイメージレイヤーを作ってくれるので
省6
877(1): 2021/03/19(金)16:25 ID:R4CRH11B(2/18) AAS
>>874
なんでパッケージマネージャーが欲しいやつがDockerなんて使おうとするんだろ？ｗ
例えばapacheのDockerイメージ、nginxのDockerイメージ
どちらもポート80で起動する
というDockerイメージを、同一のホストで複数起動する場合どうすればいいのか？
Dockerイメージを変更すること無く、待受ポート番号を変更するにはどうすればいいのか？
それができるように作られたのがDockerなんだが
ファイルを置くだけのパッケージマネージャーじゃこんな事はできない
実行時のプロセスの分離を行う仕組みが必要
878: 2021/03/19(金)16:30 ID:OafZaxWN(2/15) AAS
>>875
実行する時の分離はできるだろ
コンテナに読み取り専用でマウントするだけ
879(1): 2021/03/19(金)16:32 ID:OafZaxWN(3/15) AAS
>>877
nginxのパッケージを入れて2つの隔離されたnginxプロセスを起動するだけだろ
880: 2021/03/19(金)16:54 ID:edcYEDQK(5/6) AAS
独自のコンテナランタイムとか作らないってこと？
今使ってるコンテナのイメージレイヤーは削除出来たらだめって挙動をパッケージでやるのは
独自のコンテナランタイム作らずには難しくね
今コンテナで使ってるパッケージを削除してしまったり
逆に古いパッケージが消えないってなりそう
881: 2021/03/19(金)16:57 ID:R4CRH11B(3/18) AAS
>>879
> nginxのパッケージを入れて2つの隔離されたnginxプロセスを起動するだけだろ
パッケージを１つだけ入れて２つのnginxプロセスを起動したりしたいんだよ
それもnginxの設定を変更せずに
882: 2021/03/19(金)17:00 ID:R4CRH11B(4/18) AAS
Dockerとパッケージマネージャーは使う目的が全く違うんだから
パッケージマネージャーが欲しい人がDockerをパッケージマネージャーの代わりとして使って
「Dockerはパッケージマネージャーで代用できる！」なんて適当なことを言わないでくれ
それはお前がDockeをパッケージマネージャーという
間違った用途で使ってるだけだ
883: 2021/03/19(金)17:37 ID:OafZaxWN(4/15) AAS
作るとしたらこんな感じだろうな
デベロッパ
myapp:
name: MyApp
version: 2.0
packages:
- ruby == 3.0.0
- hoge.com/hoge-cli == 1.2
files:
- src: ./src
省16
884(1): 2021/03/19(金)17:40 ID:R4CRH11B(5/18) AAS
ただの設定ファイルの形式変えてるだけじゃん
イメージいらないって、イメージなくしてどうやって起動速度上げるのさ？
どうやって全く同じイメージだと保証できるのさ？
同じ設定ファイルから作ったとしても一年後にやって同じイメージが出来る保証はない
885: 2021/03/19(金)17:41 ID:OafZaxWN(5/15) AAS
済まない
↑のリポジトリのURLは適当に架空のURLを書いたつもりだったが存在するドメインだったので無視してくれ
886(1): 2021/03/19(金)17:41 ID:R4CRH11B(6/18) AAS
あとrubyしか書いてないけど、ディストリに含まれる
全てのライブラリのバージョンも書かないと駄目だろｗ
887: 2021/03/19(金)17:43 ID:OafZaxWN(6/15) AAS
>>884
ファイル形式を変えてるだけじゃない
パッケージを分離してる
イメージは必要ない
必要なのはパッケージ、メタデータだけ
888: 2021/03/19(金)17:44 ID:OafZaxWN(7/15) AAS
>>886
rubyに必要な依存はrubyパッケージのメタデータに書く
889(1): 2021/03/19(金)17:44 ID:R4CRH11B(7/18) AAS
多数の仮想マシンに同一のイメージを配布することは出来るが
多数の仮想マシンに設定ファイルから一からインストールするなんて時間かかるし
すべてのファイル（OSに含まれる全てのファイル）を、そのリポジトリとやらに
アップしてそれをダウンロードして使うってならそれがDockerのイメージの仕組みです
としか言いようがない
890(1): 2021/03/19(金)17:45 ID:R4CRH11B(8/18) AAS
メタデータから再インストールするのは
時間がかかるって言ってます。
完成済みのファイルをコピーしたほうがずっと速い
それがイメージ
891: 2021/03/19(金)17:46 ID:OafZaxWN(8/15) AAS
>>889
dockerとの違いはイメージに固めないこと
これによって同じパッケージを使うアプリでパッケージ共有できる
ディスク容量や通信時間を大幅に節約できる
892: 2021/03/19(金)17:47 ID:OafZaxWN(9/15) AAS
>>890
重複を避けて少量のファイルをpullしたほうが速い
imageだと同じパッケージを使ってても別のimageと認識されるから無駄が大きすぎる
893(1): 2021/03/19(金)17:47 ID:R4CRH11B(9/18) AAS
パッケージだけあったって、インストールの順番で
出来上がるものは違うだろうが
あとからnanoをインストールするのと
あとからvimをインストールするので
同じものが出来ると思うか？
894(1): 2021/03/19(金)17:48 ID:R4CRH11B(10/18) AAS
> 重複を避けて少量のファイルをpullしたほうが速い
だからそれがイメージ
上下前次1-新書関写板覧索設栞歴
あと 108 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.024s