[過去ﾛｸﾞ] Docker Part5 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
781: 運用情報臨時板でワッチョイ導入議論中 2021/03/09(火)22:25 ID:xOuTaRGb(2/2) AAS
流石Docker原理主義者だなぁ・・・
無料でオープンソースのDocker以外のことは何も知らないｗｗ
・・・とツッコミを期待するネタだよね？
意味不明だけど面白いよ！
782: 運用情報臨時板でワッチョイ導入議論中 2021/03/09(火)22:25 ID:thtVz5nz(6/6) AAS
>>780
マネージドk8s と同じことをDockerを使わないで
どうやってやるんですか、まず話はそこからな
お前のターン、早くレスしやがれ
783: 運用情報臨時板でワッチョイ導入議論中 2021/03/09(火)22:45 ID:aIUI+/Sm(6/6) AAS
あー、いつものやつか
784: 運用情報臨時板でワッチョイ導入議論中 2021/03/10(水)02:53 ID:dmKl+QZO(1) AAS
>>780
答えられない、知らないなら、適当なこと言うんじゃなかったな
Dockerは単にアプリをデプロイしやすくするためのもので
マネージドk8sを使わない、単体の仮想マシンでも使えるって
気づいて逃げたか？ｗ
785: 運用情報臨時板でワッチョイ導入議論中 2021/03/10(水)09:34 ID:O0EPXOHE(1) AAS
ワッチョイまだかな
786(1): 運用情報臨時板でワッチョイ導入議論中 2021/03/10(水)09:42 ID:vS2MWwBS(1/6) AAS
いらんだろ。
レス見てあれ？変な事言ってるな？と思ったら大体同一人物だろ。
787: 運用情報臨時板でワッチョイ導入議論中 2021/03/10(水)09:49 ID:ivn403GC(1/2) AAS
原理主義者はせいぜい2人くらいか
788(1): 運用情報臨時板でワッチョイ導入議論中 2021/03/10(水)10:19 ID:TzedVAf5(1) AAS
>>786
その同一人物をあぼーんするのに便利だから導入しようって流れでしょ？
このスレでことあるごとに粘着してくるいつもの奴とか消したらスッキリするよ
789(1): 運用情報臨時板でワッチョイ導入議論中 2021/03/10(水)10:34 ID:vS2MWwBS(2/6) AAS
いや。別にいらんな。
馬鹿を見抜くのもエンジニアのスキルだろ。
Linuxスレにﾜｯﾁｮｲ有無の議論なんか必要ないというのも同じ理屈。
790(1): 運用情報臨時板でワッチョイ導入議論中 2021/03/10(水)10:44 ID:uMYHMW6J(1/11) AAS
>>788
ワッチョイは回線つなぎ変えたら変わるけど
どうやってあぼーんするの？
それっぽいレスを見かけるたびにNG登録していくの？
791: 運用情報臨時板でワッチョイ導入議論中 2021/03/10(水)10:45 ID:uMYHMW6J(2/11) AAS
Docker使ったらマネージドk8sを使わないといけないって
思ってるやつってアホなのかな？
792: 運用情報臨時板でワッチョイ導入議論中 2021/03/10(水)10:47 ID:Q8+Vst7D(1/2) AAS
>>789
目に入るだけで邪魔だからあぼーんは有効だよ
>>790
変えられると言ってもある程度パターンあるからね
793: 運用情報臨時板でワッチョイ導入議論中 2021/03/10(水)11:54 ID:uMYHMW6J(3/11) AAS
ワッチョイはIPアドレスとユーザーエージェントから出してるから
回線つなぎ替えるたびに変えられるよ
794: 運用情報臨時板でワッチョイ導入議論中 2021/03/10(水)11:58 ID:wDA4Uuzi(1) AAS
運用するならマネージドK8S必須かな
開発環境は好きにすればいい
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 イメージを使うか、ゼロからビルドする
イメージを頻繁に更新する
暴露されたポートに注意する
3. 機密データの漏洩を防ぐ
Dockerfileの命令にシークレットや認証情報を入れないようにしましょう
ADDよりもCOPYを優先してください
Dockerのコンテキストを意識し、.dockerignoreを使用する
4. その他
レイヤーの数を減らし、インテリジェントに並べる
メタデータとラベルを追加する
lintersを活用してチェックを自動化する
開発中にイメージをローカルでスキャンする
5. イメージのビルドの先には
docker socketとTCP接続を保護します
イメージに署名し、実行時に検証します
タグの変異を避ける
環境を root で実行しない
ヘルスチェックを含める
アプリケーションの機能を制限する
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
イメージに予めファイルやディレクトリを入れる時に
アプリが読み書きするファイルやディレクトリはrootグループに所属させる
rootグループに所属してるユーザーなら読み書き出来るようになるので、
UIDがプロジェクト固有のランダムIDでも問題ないって事らしい
それだとroot所属してる他プロジェクトのユーザーも
読み書き出来ちゃうんでは？って思うけど
新しく作成するファイルはグループIDが0（root）じゃなくてそのユーザーIDと同じグループIDになるんじゃね？
しらんけど
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.
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.
870: 2021/03/19(金)13:01 ID:edcYEDQK(1/6) AAS
nix使ったらDockerイメージのマージはできないけど
nixのパッケージ使ってDockerイメージ作れば似たような事は出来るね
使いたいCLIツールのパッケージが依存してるランタイムのバージョンが違ってても共存させる事が出来る
No dependency hell
ビルド時にだけ必要なパッケージと
実行時に必要なパッケージが明確に区別されてるので
要らない一時ファイルを誤ってDockerイメージに含める心配がない
nixpkgsのパッケージが豊富だし
無くても自分で書けば良い
GitHubで自作パッケージを公開し、ビルド済みバイナリをcachixに置いておけば
複数のプロジェクトから再ビルドせずに使い回せる
2chｽﾚ:linux
98 login:Penguin sage 2020/08/28(金) 11:22:41.35 ID:0ih4XZ3G
イメージのマージ機能はいつになったらサポートされんだ
devcontainer作るときいちいちインストール方法調べてDockerfile書くの不便なんだが
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使えば
パッケージ毎にイメージレイヤーを作ってくれるので
ストレージ効率は良い
ただ、Dockerのレイヤー数は128までなので
それを超えると最後の方のレイヤーは合体される
これも最後のイメージレイヤーは各パッケージへのシンボリックリンクになる
ビルド用パッケージは除外されるし
現状では最適解
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
dst: /myapp
volumes:
- name:myappvol
path:/var/myapp
envvars:
HOGE: fuga
entrypoint: /myapp/bin/myappentrypoint.sh
godpkgmgr push . 外部ﾘﾝｸ:my.repos.com
//メタデータとfilesがリポジトリに送信される
ユーザー
godpkgmgr run MyApp:2.0 -v ./tmp:myappvol
//rubyとhoge-cliがローカルにあるなら再利用なければpull
//MyApp:2.0のfilesとメタデータをpull
//コンテナにpaclagesとfilesをマウント、メタデータを設定、entrypointを実行
な？
image要らんだろ
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したほうが速い
だからそれがイメージ
895: 2021/03/19(金)17:48 ID:OafZaxWN(10/15) AAS
>>893
インストール順番に依存しないようにするための賢いパッケージマネージャだろ
Dockerfileは手続き型だから順番を気にしないといけないがnixのような関数型のパッケージマネージャならそれを克服できるというわけだ
896(1): 2021/03/19(金)17:48 ID:R4CRH11B(11/18) AAS
パッケージだけあったって、同じイメージは作れないんだが？
インストール済みの状態のファイル＝レイヤーが必要
897: 2021/03/19(金)17:50 ID:R4CRH11B(12/18) AAS
nixのような関数型のパッケージマネージャは
バージョンごとに複数のパッケージをインストールするというだけ
898(1): 2021/03/19(金)17:50 ID:OafZaxWN(11/15) AAS
>>894
imageでは重複をうまく回避できない
RUN xxx
RUN apt-get hoge
RUN yyy
RUN apt-get hoge
たったこれだけで別物と見なされてhogeの重複ダウンロードされる
これじゃ効率が悪すぎる
899(1): 2021/03/19(金)17:51 ID:R4CRH11B(13/18) AAS
そしてnixのような関数型のパッケージマネージャは
ポート番号を変えて起動とかしてくれない
Dockerの目的をパッケージマネージャーは満たしてくれてない
900: 2021/03/19(金)17:51 ID:OafZaxWN(12/15) AAS
>>896
パッケージバージョンを完全に指定すれば同じ
901(1): 2021/03/19(金)17:52 ID:OafZaxWN(13/15) AAS
>>899
起動時のオプションで変えるだけ
902(1): 2021/03/19(金)17:52 ID:R4CRH11B(14/18) AAS
>>898
> たったこれだけで別物と見なされてhogeの重複ダウンロードされる
nixのような関数型のパッケージマネージャも
バージョンが異なれば重複ダウンロードされる
903(1): 2021/03/19(金)17:53 ID:R4CRH11B(15/18) AAS
>>901
「パッケージマネージャー」に起動時のオプションを変更する機能があるんですか？ｗ
904: 2021/03/19(金)18:00 ID:OafZaxWN(14/15) AAS
>>902
imageの場合はバージョンが全く同じでも重複
パッケージマネージャはバージョンが同じなら重複ダウンロードしない
905: 2021/03/19(金)18:01 ID:OafZaxWN(15/15) AAS
>>903
いやいやそうなるように作るべきって話だろ
今はまだ無い賢いパッケージマネージャの話をしてんだ
906(1): 2021/03/19(金)18:08 ID:edcYEDQK(6/6) AAS
nixはbrewやyum, apt-getみたいなのじゃないぞ
nixはパッケージマネージャーの皮を被ったビルドツールだ
ビルド結果をS3に保存できるのはバイナリキャッシュ機能のおかげ
ビルド時のフラグや依存関係などを利用して生成したユニークIDを自動的にパッケージに付ける
少しでも設定変えればIDも変わる
パッケージはみんな/nix/storeの下に入る
/usrを直接変えるような事はしない
使う時は各パッケージの/binにsymlinkをはる
907: 2021/03/19(金)19:25 ID:r5P2gC/O(1) AAS
次スレわっちょい付けますか？
上下前次1-新書関写板覧索設栞歴
あと 95 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.045s