‫ブランドンは1番で入っています｡
‫次の質問は､ 訴訟とユーザーについてです｡
‫コンテナで非 root ユーザーを使用し､ ファイルパーミッションを維持する方法や Hossain をどのようにするのが良いでしょうか｡
‫現在のベストプラクティスは何かというと､ Dockerにおけるパーミッションです｡
‫特にバインドマウントを使用している場合､ バインドマウントはホストのファイルとコンテナで実行されているファイルのパーミッションを結合するので､
‫髪を引っ張って少し気が狂いそうになることがよくあります｡ 私の最も難しいプロジェクトのいくつかは､
‫異なるホストの複数のコンテナが同じファイルに正しいパーミッションでアクセスできるように､
‫マルチサーバ共有ファイルストレージが必要な場合でした｡
‫だから､ それは本当に厄介なことなんです｡
‫ユーザーvs.goと言ったところでしょうか｡
‫ブランドン・ユーザーについて質問されたら､ 私はDRイメージ構築のことをおっしゃるのだと思います｡
‫そして､ それは犬や画像を構築する内部でスーが行うよりもうまく機能する傾向があるに行く｡
‫Dockerイメージの中でビルドする際にgo Sueがよく使われる理由は､ 少なくとも私の理解ではそうなっていて､
‫実は私はその理由を知らないのですが､ おそらく何年も前のある時点で学んだのでしょうが､ すぐに忘れてしまいました｡
‫ご質問の本当の内容は､ イメージをビルドするときのことだと思いますが､
‫Dockerのファイルラインを使用する際のベストプラクティスは､ 実行コマンドの内部で特定の部分のパーミッションを変更する必要がある場合､
‫ユーザーと言えると思います｡
‫だから､ その時にスルーなどを正しく選択しているのかもしれませんね｡
‫ですから､ パーミッションの問題で最終的に起こるのは､ イメージ内のファイルではなく､
‫ランタイム中のファイルだと思います｡
‫コンテナが起動したら､ ノードアプリがユーザーノードで実行されていて､
‫ユーザーアップロードディレクトリがあり､ ファイルはホスト上に保存されているので､ ユーザーノードとして保存されることになり､
‫それがノードで実行されているので､ 他のプロセス（別のコンテナ､ 共有ボリュームなどを使用､ 購入量）が同じユーザーで実行していない場合､ そのファイルにアクセスする必要があり､
‫パーミッションに関する問題が発生します｡
‫だから､ 結局のところ､ MODで見せてもこれらの問題が解決できないのであれば､ それはないのだと言いたいです｡
‫つまり､ Dockerファイルの中で､ 例えばdoctorファイルの代わりにcopyコマンドを実行している場合､
‫その上でshowを実行することができますので､ ファイルをコピーしているときに､ そのファイルにパーミッションが与えられている正しいユーザーでコピーすると､
‫コマンドを実行することができません｡
‫それは実際に何かが追加され､ その多くを調べる機能かもしれませんが､ 私はまだ考えていません｡
‫ザ・ダッカー
‫そこで､ その右側にある公式ドキュメントにズームインして､ 「Yeah」と表示させたら｡
‫だから､ シマーで検索しても何も出てこないんです｡
‫でも､ 「shared」を見れば､ 広告やコピーを使えば､ 正しいパーミッションでそれらをコピーできることがわかります｡
‫これは1､ 2年前に起こった大きな出来事で､
‫ファイルのパーミッションを変更する必要がないため､
‫多くのスペースを節約することができました｡
‫そのためのエントリーポイントスクリプトです｡
‫例えばDocker Hubに戻り､
‫私の続編と呼ばれるDockerファイルにアクセスすると､
‫エントリーポイントスクリプトがあることが分かると思います｡
‫もちろん､ このスクリプトの問題は､ dockerファイルで設定したユーザとして実行されていることです｡
‫そのため､ ファイルのパーミッションを変更してノードユーザが読めるようにする必要があるのに､
‫スクリプトがノードユーザとして実行されていると､ ルートに移動できないため､ 別の問題が発生するのです｡
‫本来はその時点で
‫しかし､ パーミッションについては､ 数時間のトレーニングセッションを開催して､
‫パーミッションに関するさまざまな対処法を紹介することができます｡
‫そこでひとつ､ 小ネタを｡
‫最後に､ 質問の続きですが､ Linuxのファイルパーミッションは単なる数字だということがよく出てきます｡
‫実は､ これはPhil Estesが教えてくれたことなのですが､ 彼はユーザーネーム・スペースの問題を実装した人なんです｡
‫Dockerのユーザーネームスペースの機能は､ デフォルトでは有効になっていませんので､ 申し訳ございません｡
‫しかし､ すべてのコンテナを非 root で実行したい場合は､ それを有効にする必要があります｡
‫彼はその機能を追加することに貢献した一人で､ ある日話していたら､ 「Iというユーザーがいるじゃないか」と指摘されたんです｡
‫D. とグループIに分かれています｡ D. は単なるアイデアであり､
‫その数字を好きなように設定することができます｡
‫ただの数字に過ぎない｡
‫例えば､ ホスト上のファイルとコンテナ内のファイルを一致させる必要がある場合､ すべてをIで設定すればいいわけです｡
‫D. の場合､ その時点でユーザー名は関係なくなります｡
‫彼らは､ それが本当に私です｡ D. これらの権限にマッチするかどうかを確認するために使用されます｡
‫ですから､ 私がプロジェクトで作業しているときに､ 複数のコンテナでファイルを共有する必要があったのですが､ それらはすべて異なるユーザーとして実行されており､
‫パーミッションを一致させる必要があったというケースです｡
‫私たちは､ これらのファイルが正しい番号やIを使っているかどうかを手作業で確認しただけです｡ D. というのも､ 例えばホストで作成したユーザーと私が一致しないことは､
‫実は問題ではないからです｡
‫D. を容器内に入れる｡
‫Iを確認したところです｡ D. の数字が一致したので､ ちょっとしたヒントになりました｡
‫この仕組みを理解するのに時間がかかりましたが､ 結局のところ､ 読み取り回数や権限､
‫パーミッションが､ コマンドを実行するユーザーの操作と一致しているかどうかを比較することはしていないんです｡
‫いい質問ですね｡
‫最近この場で議論されたことがなかったので､ もっと話し合うべきことだと思うからです｡