Problèmes connus

La fonctionnalité d'espace de noms utilisateur (userns) du noyau Linux ajoute une autre couche de sécurité aux conteneurs Linux. Elle permet à un ordinateur hôte d'exécuter des conteneurs en dehors de son espace de noms d'ID utilisateur ou d'ID de groupe. Cela signifie que tous les conteneurs peuvent comporter un compte root (ID utilisateur 0) dans leur propre espace de noms et exécuter des processus sans recevoir les privilèges root de l'ordinateur hôte. Lorsqu'un espace de noms userns est créé, le noyau Linux fournit une correspondance entre le conteneur et l'ordinateur hôte. Par exemple, si vous démarrez un conteneur et exécutez un processus contenant l'ID utilisateur 0 (généralement le compte root dans le conteneur), le noyau Linux met en correspondance l'ID utilisateur 0 du conteneur avec un ID utilisateur sans privilège sur l'ordinateur hôte. Le conteneur peut ainsi exécuter un processus comme s'il s'agissait de l'utilisateur root alors que l'exécution est effectuée par un utilisateur autre que root sur l'ordinateur hôte.

L'erreur est due à un échec de la nouvelle mise en correspondance de userns. Lorsque les fichiers de l'ordinateur hôte sont configurés avec un ID utilisateur ou un ID de groupe valide pour la nouvelle mise en correspondance, cet ID doit être compris entre 0 et 65535. Lorsqu'un travail démarre le conteneur Docker, Docker extrait une image et les couches de cette image. Si une couche contient des fichiers avec un ID utilisateur ou un ID de groupe en dehors de la plage acceptée, Docker ne peut pas effectuer de nouvelle mise en correspondance et le conteneur ne démarre pas.

Par exemple : il existe un fichier avec un ID utilisateur ou un ID de groupe au-delà de la plage autorisée. Si vous copiez ce fichier dans l'image Docker, il peut conserver cet ID élevé.

Si vous exécutez l'image de conteneur et que le fichier doit être utilisé dans le conteneur, ce dernier échoue.

Assurez-vous qu'aucun des fichiers utilisés dans l'image Docker ne présente un ID utilisateur ou un ID de groupe élevé.

Si vous ne savez pas quel fichier présente un ID utilisateur ou un ID de groupe élevé dans l'image, vous pouvez le retrouver :

1. Entrez le conteneur :

   docker run it <image-name> sh

2. Recherchez les fichiers avec un ID utilisateur/ID de groupe élevé :

   • Recherchez les utilisateurs :

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

   • Recherchez les groupes :

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

   Le numéro 1000000 est différent car il s'agit de l'erreur d'ID.

3. Si vous trouvez des fichiers, faites en sorte que l'ID utilisateur ou l'ID de groupe soit inférieur, à l'emplacement de stockage du fichier ou dans le conteneur.

Dans le fichier Docker, une fois que vous avez copié les fichiers dont vous avez besoin dans l'image, exécutez l'une des commandes suivantes :

Sur le dossier :

RUN chown -R root:root /root 

Directement sur le fichier :

RUN chown -R root:root job_logs.py

Cette erreur survient lorsque vous utilisez un stockage de système de fichiers local ne se trouvant pas à l'emplacement /home/datascience.

Dans les travaux, vous pouvez indiquer la taille du stockage de blocs. Le stockage de blocs est monté sur le dossier local /home/datascience, que vous pouvez utiliser lors du traitement de travail. Sa taille de stockage est égale à la taille définie pour le stockage de blocs avant le traitement de travail. Si vous utilisez ou créez un répertoire en dehors de cet emplacement, il peut rapidement manquer d'espace et le message d'erreur apparaît. Tout dépend de la taille du contenu stocké.

Assurez-vous que vous travaillez toujours dans le dossier principal qui bénéficie de la taille complète du stockage de blocs, à savoir /home/datascience. Créez, modifiez et téléchargez l'ensemble du contenu à cet emplacement. Créez des répertoires sous cet emplacement.

Par défaut, Docker sur une instance M1 MacBook crée des images linux/arm64, qui fonctionnent uniquement sur les machines qui utilisent l'architecture ARM. Les machines basées sur Intel utilisent l'architecture AMD. Par conséquent, les images docker créées sur un fichier M1 MacBook risquent de ne pas fonctionner sur des machines basées sur Intel.