既知の問題

Linuxカーネルのユーザー・ネームスペース(userns)機能は、Linuxコンテナに別のセキュリティ・レイヤーを追加します。これにより、ホスト・マシンは、ユーザーID (UID)またはグループID (GID)ネームスペースの外部でコンテナを実行できます。つまり、すべてのコンテナは、独自のネームスペースにrootアカウント(UID 0)を持ち、ホスト・マシンからroot権限を受け取らずにプロセスを実行できます。usernsが作成されると、Linuxカーネルはコンテナとホスト・マシン間のマッピングを提供します。たとえば、コンテナを起動し、その内部でUID 0(通常はコンテナ内のrootアカウント)のプロセスを実行すると、LinuxカーネルはコンテナのUID 0をホスト・マシン上の特権のないUIDにマップします。これにより、コンテナはrootユーザーであるかのようにプロセスを実行できますが、実際にはホスト・マシン上のroot以外のユーザーによって実行されます。

エラーは、usernsの再マッピングの失敗によって発生します。ホスト・マシン・ファイルが再マッピング用に有効なUIDまたはGIDで構成されている場合、UIDまたはGIDは0 - 65535の範囲内である必要があります。ジョブがDockerコンテナを起動すると、Dockerはイメージをプルし、そのイメージからレイヤーを抽出します。許可された範囲外のUIDまたはGIDを持つファイルがレイヤーに含まれている場合、Dockerは正常に再マップできないため、コンテナの起動に失敗します。

たとえば、許可された範囲よりも高いUIDとGIDのファイルが存在する場合です。このファイルをDockerイメージにコピーすると、UIDおよびGIDは高いままになります。

コンテナ・イメージを実行し、そのファイルをコンテナで使用する必要がある場合、コンテナは失敗します。

Dockerイメージで使用されるどのファイルにも高いUIDまたはGIDがないことを確認します。

イメージ内のUIDまたはGIDが高いファイルがわからない場合は、次の方法で検索できます:

1. 次を使用してコンテナに入ります:

   docker run it <image-name> sh

2. UID/GIDが高いファイルを検索します:

   • ユーザーの検索:

     find / \( -uid 1000000 \) -ls 2>/dev/null

   • グループの検索:

     find / \( -gid 1000000 \) -ls 2>/dev/null

   1000000はIDエラーであるため、違います。

3. ファイルが見つかった場合は、ファイルが格納されている場所またはコンテナ内のいずれかで、UIDまたはGIDが低いことを確認してください。

Dockerファイルで、イメージに必要なファイルをコピーした後、次のいずれかを実行します:

フォルダで:

RUN chown -R root:root /root 

ファイルに直接:

RUN chown -R root:root job_logs.py

このエラーは、/home/datascienceの場所にないローカル・ファイル・システム・ストレージを使用すると発生します。

ジョブでは、ブロック・ストレージのサイズを指定できます。ブロック・ストレージは、ジョブ実行中に使用できるローカル・フォルダ/home/datascienceにマウントされます。ジョブ実行前のブロック・ストレージのサイズ・セットと同じストレージ・サイズがあります。この場所の外部でディレクトリを使用または作成すると、すぐに領域不足になり、エラー・メッセージが表示されます。これは、格納されるコンテンツのサイズによって異なります。

ブロック・ストレージのフル・サイズを持つメイン・フォルダ(/home/datascience)下で常に作業するようにします。この場所ですべてのコンテンツを作成、編集およびダウンロードします。この場所にディレクトリを作成します。

デフォルトでは、M1 MacBook上のDockerは、ARMアーキテクチャを使用しているマシンでのみ動作するlinux/arm64イメージを作成します。Intelベースのマシンは、AMDアーキテクチャーを使用します。その結果、M1 MacBook上に構築されたdockerイメージは、Intelベースのマシンでは機能しない可能性があります。