<divclass="col-main cell cell--auto"><!-- start custom main top snippet --><divid="results-container"class="search-result js-search-result"></div><!-- end custom main top snippet -->
<articleitemscopeitemtype="http://schema.org/Article"><divclass="article__header"><header><h1style="color:Tomato;">Podman développer, gérer et exécuter des conteneurs</h1></header></div><metaitemprop="headline"content="Podman développer, gérer et exécuter des conteneurs"><divclass="article__info clearfix"><ulclass="left-col menu"><li>
<p><em>Podman (« POD manager ») est un outil Open Source qui sert à développer, gérer et exécuter des conteneurs sur des systèmes Linux®. Développé par des ingénieurs Red Hat® et des membres de la communauté Open Source, Podman gère l’ensemble de l’écosystème de conteneurs à l’aide de la bibliothèque libpod.<br/>
Son architecture inclusive et sans démon le rend plus accessible et sécurisé pour gérer les conteneurs.Ceci permet d’accéder aux différentes applications virtualisées sans droits root.<br/>
Il est également possible d’utiliser les principales commandes de Docker dans Podman, il suffit d’utiliser l’alias <codeclass="language-plaintext highlighter-rouge">alias docker=podman</code></em></p>
<p>Podman se distingue également par ses pods qui sont un regroupement de plusieurs conteneurs au sein d’un namespace Linux commun et partageant certaines ressources.<br/>
Podman permet d’exécuter les différents conteneurs sur l’hôte en tant qu’utilisateur habituel, sans droits root.
Les processus nécessitent uniquement des droits root au sein d’un conteneur.</p>
<p>Le noyau d’un pod est formé par des <strong>infraconteneurs</strong> responsables exclusivement de la fonctionnalité du groupe et ayant pour fonction de gérer et de garantir les différentes ressources comme les namespaces, les ports réseau, le processeur, la mémoire vive, etc. <br/>
Podman utilise l’outil de monitoring codé en C <strong>Conmon</strong> qui surveille les différents composants virtualisés et sécurise par exemple les journaux et il sert également d’interface avec le terminal du conteneur concerné.Podman utilise en plus le logiciel <strong>runC</strong>.<br/>
<p>Vous pouvez également exécuter la commande <codeclass="language-plaintext highlighter-rouge">podman info</code> ci-dessous pour obtenir plus d’informations sur votre installation Podman.</p>
<p>Les fichiers de configuration du comportement des conteneurs se trouvent dans <codeclass="language-plaintext highlighter-rouge">/usr/share/containers/</code>.<br/>
Vous devez copier les fichiers nécessaires dans <codeclass="language-plaintext highlighter-rouge">/etc/containers</code> avant de les modifier.<br/>
Pour configurer l’interface de pont réseau utilisée par Podman, voir <codeclass="language-plaintext highlighter-rouge">/etc/cni/net.d/87-podman.conflist</code></p>
<pclass="warning">Attention : Podman sans racine repose sur l’utilisation de l’espace de noms de l’utilisateur non privilégié (CONFIG_USER_NS_UNPRIVILEGED) qui a de sérieuses implications en matière de sécurité, voir <ahref="https://wiki.archlinux.org/title/Security#Sandboxing_applications">Security#Sandboxing applications</a> pour plus de détails.</p>
<p>Par défaut, seul l’utilisateur root est autorisé à exécuter des conteneurs (ou des espaces de noms en langage kernels). L’exécution de Podman sans root améliore la sécurité car un attaquant n’aura pas les privilèges de root sur votre système, et permet également à plusieurs utilisateurs non privilégiés d’exécuter des conteneurs sur la même machine.</p>
<p>Le paquetage <ahref="https://archlinux.org/packages/?name=slirp4netns">slirp4netns</a> est installé en tant que dépendance pour exécuter Podman dans un environnement sans racine.</p>
<p>Si Podman utilise le backend réseau <ahref="https://archlinux.org/packages/?name=netavark">netavark</a>, il est alors nécessaire d’installer <ahref="https://archlinux.org/packages/?name=aardvark-dns">aardvark-dns</a> pour avoir une résolution de nom dans les conteneurs sans racine.</p>
<h4id="activer-les-overlays-natifs-sans-racine">Activer les overlays natifs sans racine</h4>
<p>Auparavant, il était nécessaire d’utiliser le paquetage <ahref="https://archlinux.org/packages/?name=fuse-overlayfs">fuse-overlayfs</a> pour les montages FUSE dans un environnement sans racine. Cependant, les versions modernes de Podman et du noyau Linux prennent en charge les superpositions sans racine natives, ce qui permet d’obtenir de meilleures performances. Pour migrer de fuse-overlayfs, exécutez</p>
<divclass="language-plaintext highlighter-rouge"><divclass="highlight"><preclass="highlight"><code>podman system reset
</code></pre></div></div>
<divclass="language-plaintext highlighter-rouge"><divclass="highlight"><preclass="highlight"><code>WARNING! This will remove:
- all containers
- all pods
- all images
- all networks
- all build cache
- all machines
- all volumes
Are you sure you want to continue? [y/N] y
</code></pre></div></div>
<p>Cette commande supprimera malheureusement tous les conteneurs tirés.</p>
<p>Pour vérifier que les superpositions natives sans racine sont activées, exécutez</p>
<divclass="language-plaintext highlighter-rouge"><divclass="highlight"><preclass="highlight"><code>podman info
</code></pre></div></div>
<p>Il devrait y avoir <codeclass="language-plaintext highlighter-rouge">graphDriverName : overlay</code> et <codeclass="language-plaintext highlighter-rouge">Native Overlay Diff : "true"</code></p>
<p>Si la valeur est actuellement de 0, activez-la en mettant 1 via sysctl ou un paramètre du noyau.</p>
<blockquote>
<p>Remarque : pour linux-hardened, kernel.unprivileged_userns_clone est défini à 0 par défaut.</p>
</blockquote>
<h4id="définir-subuid-et-subgid">Définir subuid et subgid</h4>
<p>Pour que les utilisateurs puissent utiliser Podman sans racine, une entrée de configuration subuid et subgid doit exister pour chaque utilisateur qui souhaite l’utiliser.<br/>
Les nouveaux utilisateurs créés à l’aide de useradd ont ces entrées par défaut.</p>
<pclass="info">Les utilisateurs créés avant la version 4.11 de shadow n’ont pas d’entrées dans <codeclass="language-plaintext highlighter-rouge">/etc/subuid </code>et <codeclass="language-plaintext highlighter-rouge">/etc/subgid</code> par défaut. Une entrée peut être créée pour eux en utilisant la commande <codeclass="language-plaintext highlighter-rouge">usermod</code> ou en modifiant manuellement les fichiers.</p>
<p>La commande suivante permet à l’utilisateur et au groupe username d’exécuter des conteneurs Podman (ou d’autres types de conteneurs dans ce cas). Elle attribue une plage donnée d’UID et de GID à l’utilisateur et au groupe donnés.</p>
<p>L’intervalle ci-dessus pour le nom d’utilisateur peut déjà être utilisé par un autre utilisateur, car il définit l’intervalle par défaut pour le premier utilisateur du système. En cas de doute, consultez d’abord les fichiers <codeclass="language-plaintext highlighter-rouge">/etc/subuid</code> et <codeclass="language-plaintext highlighter-rouge">/etc/subgid</code> pour trouver les plages déjà réservées.</p>
<ul>
<li>De nombreuses images nécessitent 65536 uids / gids pour le mappage (notamment les images de base busybox et alpine). Il est recommandé d’allouer au moins ce nombre d’uids / gids pour chaque utilisateur afin de maximiser la compatibilité avec docker.</li>
<li>Si vous utilisez systemd-homed, l’UID et le GID minimum pour les conteneurs doivent être au moins 524288 (vérifiez la valeur “begin container users” dans la sortie de userdbctl). [1]</li>
</ul>
<h4id="propager-les-changements-de-subuid-et-subgid">Propager les changements de subuid et subgid</h4>
<p>Podman sans racine utilise un processus de pause pour maintenir en vie les espaces de noms non privilégiés. Cela empêche toute modification des fichiers <codeclass="language-plaintext highlighter-rouge">/etc/subuid</code> et <codeclass="language-plaintext highlighter-rouge">/etc/subgid</code> d’être propagée aux conteneurs sans racine pendant que le processus de pause est en cours d’exécution.<br/>
Pour que ces changements soient propagés, il est nécessaire d’exécuter</p>
<divclass="language-plaintext highlighter-rouge"><divclass="highlight"><preclass="highlight"><code>podman system migrate
</code></pre></div></div>
<p>Après cela, l’utilisateur/groupe spécifié dans les fichiers ci-dessus est en mesure de démarrer et d’exécuter les conteneurs Podman.</p>
<h4id="ajouter-les-capacités-sys_chroot-optionnel">Ajouter les capacités SYS_CHROOT (optionnel)</h4>
<p>À partir de la version 4.4, certaines capacités par défaut ont été supprimées, y compris SYS_CHROOT (expliqué dans un billet de blog officiel). Cela affecte les conteneurs qui utilisent chroot (comme archlinux:base) et donc les opérations de pacman échouent à l’intérieur du conteneur (c’est-à-dire l’installation de paquets qui exécutent des scripts de post-installation). Vous pouvez identifier ces problèmes si, lorsque vous construisez avec podman, vous obtenez des erreurs comme celles ci-dessous pendant la construction</p>
could not change the root directory (Operation not permitted)
error: command failed to execute correctly
...
</code></pre></div></div>
<p>Pour résoudre ce problème, modifiez le fichier <codeclass="language-plaintext highlighter-rouge">/etc/containers/containers.conf</code> et ajoutez le <strong>SYS_CHROOT</strong> à la liste :</p>
<p>Vous pouvez également le faire temporairement depuis la ligne de commande avec <codeclass="language-plaintext highlighter-rouge">--cap-add sys_chroot</code> lorsque vous exécutez <codeclass="language-plaintext highlighter-rouge">podman-build</code></p>
<h3id="stockage">Stockage</h3>
<p>La configuration de la manière et de l’endroit où les images de conteneurs et les instances sont stockées se fait dans le fichier <codeclass="language-plaintext highlighter-rouge">/etc/containers/storage.conf</code></p>
<pclass="info">Lors de l’utilisation de <strong>Rootless Podman</strong>, des dérogations aux paramètres de stockage peuvent être ajoutées à <codeclass="language-plaintext highlighter-rouge">$XDG_CONFIG_HOME/containers/storage.conf</code> sur une base individuelle.
Définir le pilote en fonction du système de fichiers utilisé pour l’emplacement de stockage</p>
<p>Podman est capable d’exécuter des images construites pour une architecture CPU différente de celle de l’hôte en utilisant le système <ahref="https://en.wikipedia.org/wiki/binfmt_misc">Wikipedia:binfmt_misc</a>.</p>
<p>Pour l’activer, installez <strong>qemu-user-static</strong> et <strong>qemu-user-static-binfmt</strong></p>
<p>systemd est livré avec le service <strong>systemd-binfmt.service</strong> qui devrait activer les nouvelles règles.</p>
<p>Vérifiez que les règles binfmt ont été ajoutées</p>
<p>Podman devrait maintenant être capable d’exécuter des images d’architecture étrangère. La plupart des commandes utilisent l’architecture étrangère lorsque l’option –arch est passée.</p>
<p>Exemple :</p>
<divclass="language-plaintext highlighter-rouge"><divclass="highlight"><preclass="highlight"><code>podman run --arch arm64 'docker.io/alpine:latest' arch
</code></pre></div></div>
<p>aarch64</p>
<h3id="docker-compose">Docker Compose</h3>
<p>Podman 3.0.0 introduit le support de docker-compose. Cela nécessite l’activation d’un socket Podman qui prétend être docker ; démarrez l’unité podman.service.<br/>
Pour les conteneurs sans racine, vous devez démarrer l’unité utilisateur podman.service à la place et définir la variable DOCKER_HOST :</p>
<p>Pour obtenir la résolution du nom d’hôte entre les conteneurs en cours d’exécution, installez <ahref="https://archlinux.org/packages/?name=podman-dnsname">podman-dnsname</a></p>
<p>Note : Si vous avez activé buildkit dans docker, l’intégration ne fonctionnera pas. Vous devez désactiver buildkit : <codeclass="language-plaintext highlighter-rouge">$ export DOCKER_BUILDKIT=0</code></p>
<h3id="gpu-nvidia">GPU NVIDIA</h3>
<p>NVIDIA Container Toolkit fournit des conteneurs pour les GPU NVIDIA. Installez le paquet <ahref="https://aur.archlinux.org/packages/nvidia-container-toolkit/">nvidia-container-toolkit</a></p>
<p>Testez l’installation :</p>
<divclass="language-plaintext highlighter-rouge"><divclass="highlight"><preclass="highlight"><code>podman run --rm nvidia/cuda:12.0.0-runtime-ubuntu20.04 nvidia-smi
</code></pre></div></div>
<p>Pour pouvoir exécuter des conteneurs sans racine avec podman, le paramètre <codeclass="language-plaintext highlighter-rouge">no-cgroups</code> doit être mis à <codeclass="language-plaintext highlighter-rouge">true</code> dans <codeclass="language-plaintext highlighter-rouge">/etc/nvidia-container-runtime/config.toml</code></p>
<h2id="images">Images</h2>
<pclass="info">Vous pouvez omettre le préfixe de registre dans les images, car Podman cherchera automatiquement l’image dans tous les registres définis dans <codeclass="language-plaintext highlighter-rouge">/etc/containers/registries.conf</code> à <codeclass="language-plaintext highlighter-rouge">unqualified-search-registries</code> dans l’ordre défini. Les images suivantes contiendront toujours le préfixe, pour permettre des configurations sans docker.io dans la configuration.</p>
<h3id="arch-linux">Arch Linux</h3>
<p>La commande suivante extrait l’image Arch Linux x86_64 de Docker Hub.</p>
<p>Voir la page Docker Hub pour une liste complète des balises disponibles, y compris les versions avec et sans outils de construction.</p>
<p>Voir aussi <ahref="https://gitlab.archlinux.org/archlinux/archlinux-docker/blob/master/README.md">README.md</a>.</p>
<h3id="alpine-linux">Alpine Linux</h3>
<p>Alpine Linux est un choix populaire pour les petites images de conteneurs, en particulier pour les logiciels compilés sous forme de binaires statiques. La commande suivante extrait la dernière image Alpine Linux de Docker Hub :</p>
<p>Alpine Linux utilise l’implémentation <ahref="https://musl.libc.org/">musl</a> libc au lieu de l’implémentation <ahref="https://www.gnu.org/software/libc/">glibc</a> libc utilisée par la plupart des distributions Linux. Parce qu’Arch Linux utilise la glibc, il y a un certain nombre de différences fonctionnelles entre un hôte Arch Linux et un conteneur Alpine Linux qui peuvent avoir un impact sur la performance et la correction des logiciels. Une liste de ces différences est documentée dans <ahref="https://wiki.musl-libc.org/functional-differences-from-glibc.html">https://wiki.musl-libc.org/functional-differences-from-glibc.html</a>.</p>
<h3id="debian">Debian</h3>
<p>La commande suivante extrait la dernière image <ahref="https://hub.docker.com/_/debian">Debian</a> de <ahref="https://hub.docker.com/">Docker Hub</a> :</p>
<p>Voir la page Docker Hub pour une liste complète des balises disponibles, y compris les versions standard et slim pour chaque version de Debian.</p>
<h2id="résolution-des-problèmes">Résolution des problèmes</h2>
<h3id="ajouter-une-pause-au-processus">Ajouter une pause au processus</h3>
<divclass="language-plaintext highlighter-rouge"><divclass="highlight"><preclass="highlight"><code>WARN[0000] Failed to add pause process to systemd sandbox cgroup: Process org.freedesktop.systemd1 exited with status 1
</code></pre></div></div>
<p>Peut être résolu en utilisant : <ahref="https://github.com/containers/crun/issues/704">https://github.com/containers/crun/issues/704</a></p>
<h3id="le-dns-de-conteneur-ne-sera-pas-activé">Le DNS de conteneur ne sera pas activé</h3>
<divclass="language-plaintext highlighter-rouge"><divclass="highlight"><preclass="highlight"><code>WARN[0000] binary not found, container DNS will not be enabled
</code></pre></div></div>
<p>Si vous utilisez <ahref="https://archlinux.org/packages/?name=netavark">netavark</a> comme backend réseau de podman, vous devez installer <ahref="https://archlinux.org/packages/?name=aardvark-dns">aardvark-dns</a>.</p>
<h3id="les-conteneurs-se-terminent-lors-de-la-déconnexion-du-shell">Les conteneurs se terminent lors de la déconnexion du shell</h3>
<p>Après s’être déconnecté de la machine, les conteneurs Podman sont arrêtés pour certains utilisateurs. Pour éviter cela, <ahref="https://wiki.archlinux.org/title/Systemd/User#Automatic_start-up_of_systemd_user_instances">activez l’option lingering</a> pour les utilisateurs qui utilisent des conteneurs.</p>
<p>Vous pouvez également créer une unité utilisateur systemd comme décrit dans <ahref="https://man.archlinux.org/man/podman-auto-update.1#EXAMPLES">podman-auto-update(1) § EXEMPLES</a>.</p>
<h3id="échec-du-déplacement-de-netns-sans-racine">Échec du déplacement de netns sans racine</h3>
<divclass="language-plaintext highlighter-rouge"><divclass="highlight"><preclass="highlight"><code>docker-compose up
</code></pre></div></div>
<divclass="language-plaintext highlighter-rouge"><divclass="highlight"><preclass="highlight"><code>ERRO[0000] failed to move the rootless netns slirp4netns process to the systemd user.slice: Process org.freedesktop.systemd1 exited with status 1
</code></pre></div></div>
<p>Peut être résolu en démarrant/activant <strong>podman.service</strong></p>
<p>Par défaut, la liste de registre n’est pas remplie car les fichiers du paquet proviennent de l’amont. Cela signifie que par défaut, essayer d’extraire une image sans spécifier le registre résultera en une erreur similaire à la suivante</p>
<divclass="language-plaintext highlighter-rouge"><divclass="highlight"><preclass="highlight"><code>Error: short-name "archlinux" did not resolve to an alias and no unqualified-search registries are defined in "/etc/containers/registries.conf"
</code></pre></div></div>
<p>Une configuration de départ pourrait être la suivante :</p>
<p>Ceci est équivalent à la configuration par défaut de Docker.</p>
<p>Une alternative moins pratique, mais plus compatible avec les systèmes sans noms courts configurés, consiste à utiliser le chemin complet du registre dans le <strong>Containerfile</strong> ou le <strong>Dockerfile</strong>.</p>
<h3id="pousser-des-images-vers-docker-hub-accès-refusé-authentification-requise">Pousser des images vers Docker Hub, accès refusé authentification requise</h3>
<p>Lors de l’utilisation de podman push pour pousser des images de conteneurs vers Docker Hub, les erreurs suivantes peuvent se produire :<br/>
<codeclass="language-plaintext highlighter-rouge">Requested access to the resource is denied</code> ou <codeclass="language-plaintext highlighter-rouge">Authentication required</code><br/>
Les conseils suivants peuvent aider à résoudre les problèmes potentiels :</p>
<p>Marquez l’image locale :</p>
<divclass="language-shell highlighter-rouge"><divclass="highlight"><preclass="highlight"><code>podman tag <localImage> docker.io/<dockerHubUsername>/<dockerHubRepository>:<Tag>
<p>Ajouter <codeclass="language-plaintext highlighter-rouge"><dockerHubUsername></code> comme collaborateur dans l’onglet Docker Hub Collaborators du dépôt.</p>
<h3id="-is-not-a-shared-mount">”/” is not a shared mount</h3>
<divclass="language-shell highlighter-rouge"><divclass="highlight"><preclass="highlight"><code>WARN[0000] <spanclass="s2">"/"</span> is not a shared mount, this could cause issues or missing mounts with rootless containers
</code></pre></div></div>
<p>Buildah/Podman fonctionnant en tant que rootless s’attend à ce que le montage bind soit partagé, vérifiez s’il est défini sur private :</p>
<p>Dans ce cas, voir <ahref="https://man.archlinux.org/man/mount.8#Shared_subtree_operations">mount § Shared_subtree_operations</a> et définir <strong>temporairement</strong> le montage comme partagé avec :</p>
<p>Pour le définir de manière permanente, éditez le fichier /etc/fstab et ajoutez l’option shared au montage souhaité, puis redémarrez. Il en résultera une entrée du type</p>
<h3id="activation-des-registres-oci">Activation des registres OCI</h3>
<p>Avant d’utiliser Podman pour créer des conteneurs, assurez-vous que Podman peut communiquer avec les registres OCI . Podman prend en charge plusieurs registres OCI simultanément afin que vous puissiez créer des conteneurs à l’aide de différents référentiels.</p>
<p>Ouvrez le fichier <codeclass="language-plaintext highlighter-rouge">/etc/containers/registries.conf</code> avec l’éditeur de texte de votre choix. Ce fichier définit tous les registres avec lesquels Podman peut communiquer. Podman consulte ce fichier pour savoir à quels registres il doit se connecter.</p>
<p>Ces lignes configurent Podman pour utiliser le registre public sur Docker Hub ( docker.io , register.access.redhat.com ) et le registre privé ( quay.io ), ce qui est recommandé.</p>
<h3id="exécuter-des-conteneurs-podman-avec-des-privilèges-podman">Exécuter des conteneurs Podman avec des privilèges Podman</h3>
<p>Maintenant que vous avez installé Podman et configuré les registres, vous pouvez commencer à exécuter des conteneurs Podman avec les privilèges Podman. Le noyau Linux prend en charge un large éventail de contrôles d’autorisations sur ses appels système, tels que les <ahref="https://man7.org/linux/man-pages/man7/capabilities.7.html">fonctionnalités (capabilities)</a> .</p>
<p>Dans le cas des conteneurs Podman, les fonctionnalités contrôlent le comportement par défaut de root dans l’espace de noms de l’utilisateur. Vous pouvez utiliser l’indicateur <codeclass="language-plaintext highlighter-rouge">--privileged</code> lors de l’exécution d’un conteneur pour ajouter toutes les fonctionnalités qui ne sont pas déjà présentes dans le conteneur.</p>
<ol>
<li>
<p>Exécutez la commande <codeclass="language-plaintext highlighter-rouge">podman run</code> ci-dessous pour créer un conteneur fedora sans fonctionnalités.</p>
<divclass="language-plaintext highlighter-rouge"><divclass="highlight"><preclass="highlight"><code> podman run -d fedora sleep 100
</code></pre></div></div>
<p><imgsrc="/images/podman002.png"alt=""/><br/>
<em>Création d’un conteneur Fedora</em></p>
<divclass="language-plaintext highlighter-rouge"><divclass="highlight"><preclass="highlight"><code> podman run -d fedora sleep 100
</code></pre></div></div>
<p><imgsrc="/images/podman003.png"alt=""/></p>
</li>
<li>
<p>Ensuite, exécutez la commande <codeclass="language-plaintext highlighter-rouge">podman top</code> ci-dessous pour répertorier toutes les fonctionnalités.</p>
<divclass="language-plaintext highlighter-rouge"><divclass="highlight"><preclass="highlight"><code> podman top -l capeff
</code></pre></div></div>
<p>Comme indiqué ci-dessous, le conteneur sans racine standard a des capacités limitées.<br/>
<imgsrc="/images/podman004.png"alt=""/><br/>
<em>Lister toutes les capacités</em></p>
</li>
<li>
<p>Exécutez la commande <codeclass="language-plaintext highlighter-rouge">podman run</code> ci-dessous pour créer un conteneur avec toutes les fonctionnalités ( –privileged).</p>
<divclass="language-plaintext highlighter-rouge"><divclass="highlight"><preclass="highlight"><code> podman run --privileged -d fedora sleep 100
</code></pre></div></div>
<p><imgsrc="/images/podman005.png"alt=""/></p>
</li>
<li>
<p>Enfin, réexécutez la commande <codeclass="language-plaintext highlighter-rouge">podman top</code> pour vérifier la différence de capacités.</p>
<divclass="language-plaintext highlighter-rouge"><divclass="highlight"><preclass="highlight"><code> podman top -l capeff
</code></pre></div></div>
<p>Vous remarquerez que toutes les fonctionnalités sont disponibles pour ce conteneur en raison de l’indicateur <codeclass="language-plaintext highlighter-rouge">--privileged</code> qui permet au conteneur de s’exécuter avec toutes les fonctionnalités, pas seulement celles déjà présentes dans le conteneur. Cet indicateur est important car il mappe l’espace de noms d’utilisateur du conteneur à l’espace de noms de l’hôte, lui donnant toutes les capacités des processus exécutés sur votre système.
<imgsrc="/images/podman006.png"alt=""/><br/>
<em>Vérification de la différence d’autorisations</em></p>
</li>
</ol>
<pclass="info">Si vous ne définissez pas l’indicateur <codeclass="language-plaintext highlighter-rouge">--privileged</code> lors du lancement d’un conteneur, le conteneur aura un ensemble restreint de fonctionnalités. Dans le cas de conteneurs qui utilisent leur propre espace de noms d’utilisateur, vous devrez leur donner explicitement toutes les fonctionnalités.</p>
<h3id="travailler-avec-des-images-et-des-conteneurs-podman">Travailler avec des images et des conteneurs Podman</h3>
<p>Maintenant que vous avez appris à ajouter des registres et des fonctionnalités OCI pour un conteneur, vous pouvez travailler avec des images et des conteneurs Podman.</p>
<p>Pour cette démo, vous utiliserez NGINX pour une image afin de créer un conteneur.</p>
<ol>
<li>
<p>Exécutez la commande <codeclass="language-plaintext highlighter-rouge">podman search</code> ci-dessous pour répertorier toutes les images Podman disponibles pournginx</p>
<p>Ci-dessous, vous pouvez voir que vous obtenez toutes les images étiquetées disponibles pour NGINX à partir des référentiels docker.io , quay.io et redhat.com que vous avez ajoutés précédemment<br/>
<imgsrc="/images/podman007.png"alt=""/><br/>
<em>Liste des 3 images par registre Podman disponibles pour NGINX</em></p>
</li>
<li>
<p>Après avoir choisi une image NGINX à utiliser, exécutez la podmancommande ci-dessous pour télécharger ( pull) l’image sur votre ordinateur local.</p>
<p>Cette démo utilise nginx:alpine car il s’agit de la plus petite image et ne peut s’exécuter que sur la mémoire, ce qui permet de gagner du temps sur les étapes de construction ultérieures.</p>
À ce stade, vous disposez d’une nouvelle image que vous pouvez utiliser pour créer un conteneur ou l’utiliser comme image de base pour d’autres conteneurs.
Téléchargement de l’image NGINX Téléchargement de l’image NGINX</p>
</li>
<li>
<p>Exécutez la commande <codeclass="language-plaintext highlighter-rouge">podman images</code> pour voir les informations de votre nouvelle image</p>
<p>podman images</p>
<p><imgsrc="/images/podman009.png"alt=""/><br/>
<em>Lister toutes les images</em></p>
</li>
<li>
<p>Maintenant, exécutez la commande <codeclass="language-plaintext highlighter-rouge">podman run</code> ci-dessous pour créer un conteneur à partir de l’image ( nginx:alpine) et exécutez un nginxserveur sur cette image.</p>
<p>Cette commande effectue les opérations suivantes :</p>
<ul>
<li>Démarre le conteneur de manière interactive ( <codeclass="language-plaintext highlighter-rouge">-it</code>) et vous permet d’attacher un terminal.</li>
<li>Supprime (<codeclass="language-plaintext highlighter-rouge">--rm</code>) le conteneur après sa sortie/arrêt.</li>
<li>Exécute le conteneur en arrière-plan ( <codeclass="language-plaintext highlighter-rouge">--d</code>) et publie ( <codeclass="language-plaintext highlighter-rouge">-p</code>) le port 80 sur toutes les interfaces à porter 8080 sur le conteneur.</li>
<li>
<p>Spécifiez le nom du conteneur ( <codeclass="language-plaintext highlighter-rouge">--name web</code>).</p>
<divclass="language-plaintext highlighter-rouge"><divclass="highlight"><preclass="highlight"><code> podman run -it --rm -d -p 8080:80 --name web nginx:alpine
</code></pre></div></div>
</li>
</ul>
<p>Vous obtiendrez un ID de conteneur aléatoire, comme indiqué ci-dessous, que vous pourrez utiliser pour surveiller/démarrer/arrêter/supprimer le conteneur. Notez l’ID du conteneur car il est utile lors de la vérification des journaux ou de l’arrêt d’un conteneur spécifique.<br/>
<imgsrc="/images/podman010.png"alt=""/><br/>
<em>Exécution du conteneur (web)</em></p>
</li>
<li>
<p>Exécutez la commande <codeclass="language-plaintext highlighter-rouge">podman ps</code> ci-dessous (sans arguments) pour vérifier si votre conteneur est en cours d’exécution.</p>
<p>Vous pouvez voir que le conteneur Web est Up et utilise le port 8080/TCP sur votre machine hôte pour exposer sa ressource.<br/>
<imgsrc="/images/podman011.png"alt=""/><br/>
<em>Vérifier si le conteneur (web) est en cours d’exécution</em></p>
</li>
<li>
<p>Pour une double vérification, ouvrez votre navigateur Web et accédez à <strong>localhost:8080</strong> ou <strong>your-server-ip:8080</strong> , où <strong>your-server-ip</strong> est l’adresse IP de votre serveur.</p>
<p>Si votre conteneur fonctionne, vous verrez l’écran d’accueil NGINX par défaut, comme illustré ci-dessous.<br/>
<imgsrc="/images/podman012.png"alt=""/><br/>
<em>Affichage de l’écran d’accueil NGINX par défaut</em></p>
<p>Si vous n’êtes pas sûr de la configuration du conteneur ou s’il contient des erreurs, exécutez la commande podman logs ci-dessous pour obtenir les fichiers journaux du conteneur. Remplacez mycontainer par votre ID de conteneur cible.</p>
<em>Vérification des fichiers journaux pour le conteneur (Web)</em></p>
</li>
<li>
<p>Exécutez l’une des commandes <codeclass="language-plaintext highlighter-rouge">podman stop</code> ci-dessous pour arrêter votre conteneur. Remplacez mycontainer par votre ID de conteneur cible ou remplacez-le web par le nom réel du conteneur.</p>
<p>Puisque vous avez utilisé l’indicateur –rm à l’étape quatre, Podman supprime votre conteneur dès que vous arrêtez ce conteneur. Cette configuration permet de garder votre espace de travail sans encombrement.</p>
<divclass="language-plaintext highlighter-rouge"><divclass="highlight"><preclass="highlight"><code> podman stop web
</code></pre></div></div>
<p><imgsrc="/images/podman014.png"alt=""/><br/>
<em>Arrêt d’un conteneur</em></p>
</li>
<li>
<p>Enfin, exécutez la commande <codeclass="language-plaintext highlighter-rouge">podman ps</code> pour répertorier tous les conteneurs, y compris un conteneur arrêté.</p>
<divclass="language-plaintext highlighter-rouge"><divclass="highlight"><preclass="highlight"><code> podman ps -a
</code></pre></div></div>
<p>Votre conteneur a été supprimé lorsque vous l’avez précédemment arrêté, vous n’obtiendrez donc rien sur la liste, comme indiqué ci-dessous.<br/>
<li><ahref="https://linuxconfig.org/how-to-share-data-between-a-docker-container-and-host-system-using-volumes">How to share data between a Docker container and host system using volumes</a></li>
<li><ahref="https://www.digitalocean.com/community/tutorials/how-to-share-data-between-the-docker-container-and-the-host">How To Share Data Between the Docker Container and the Host</a></li>
