私はフォローしています最初からKevin Booneコンテナの作成
/mnt/container/ の下にアルパインミニルートファイルシステムがあります。
chrootとunshareでマウントがどのように機能するかは少し混乱しています。
共有を解除すると、共有を解除する必要はありません。
chroot /mnt/container /bin/sh -l
ホストシステムに「/」（ルート）を持つコンテナ（一種の）を取得します/mnt/container。
コンテナ内で次のコマンドを実行します。
mount -t proc proc /proc >& /dev/null
mount -t devtmpfs dev /dev/ >& /dev/null
ホストシステムの/procおよび/devがマウントされていることを確認するため、ホストで実行されているプロセスを表示し、ホストps -efで生成される/devにファイルを生成することもできます。まだ名前空間の分離がないため、これは予想される結果です。
名前空間分離を作成するには、次の手順を実行します。
unshare -mpfu chroot /mnt/container /bin/sh -l
その後、コンテナ内で実行します。
mount -t proc proc /proc >& /dev/null
mount -t devtmpfs dev /dev/ >& /dev/null
今回は、ps -efコンテナ内の2つのプロセスのみが表示されます。私の理解（間違っている場合は修正してください）は、mount -t proc proc /proc >& /dev/nullホストシステムの/ procはマウントされていませんが、procfsタイプの新しいディレクトリ/ procが作成され隔離されていることです。
ただし、コンテナ内の/ devはまだホストの/ devと同じです。それでも/devにファイルを作成でき、ホストに表示されます。
/devが/procのように隔離されないのはなぜですか？
答え1
devtmpfs名前空間がありません（参照コンテキストに従ってshmem初期化される）、ユーザーの名前空間内での使用には適していません（参照：名前空間用devtmpfsに特別なものがありますか？権限の問題）。
これを変更しようとしました。Seth Forsheeが提出した2014パッチシリーズ。ただし、カーネル管理者、特に Greg KH は、devtmpfsホストとユーザーの名前空間間でインスタンスまたは名前空間認識インスタンスを共有する場合役に立たない:
Loopdevfsの議論では、devtmpfs名前空間を分離するのが賢明かもしれません。しかし、名前空間devtmpfsを保護するために、ユーザースペースの場合、コンテナが起動するたびにデバイスのグローバルdevtmpfsをプライベートtmpfsにバインドマウントする必要があると言いたいです（システムの考慮事項では、コンテナrootfsにしか存在できません）。避ける価値があるようです。
コンテナで目的のデバイスノードを選択する必要があるのは良いことだと思います。実際には、とにかくカーネルで同じことをする必要があります。具体的には、ユーザー空間がカーネルよりも必要な操作をよりよく知っているので、ここで決定を下すのに問題があります。
デフォルトでは、ユーザーの名前空間内にある必要がある場合は、/dev手動で入力する必要があります。
/ procはPID名前空間とどのようにやり取りしますか？/procこの動作は説明されています。
答え2
Kevin Booneのコンテナ技術は、Dockerまたは仮想マシンで可能なコンテナ化技術と同じではありません。
Linuxでは、/ devと/ procはファイルシステムディレクトリではありません。これは、ファイルシステムオブジェクト（オブジェクトなど）にアクセスできるオペレーティングシステムの特別なエンティティです。
多くのコマンドでは、これらのエンティティの内容を確認する必要があります。
「dev」と「proc」という名前のディレクトリはどこでも作成できますが、実際の/ devおよび/ proc疑似ファイルシステムディレクトリの「カバー」として表示されることがあります。