Depuis peu, j'ai choisi de passer de docker à podman, j'ai donc décidé d'écrire un petit article dessus.
Podman est au même titre que docker un outil pour créer et gérer des conteneurs, avec des images au format OCI.
Différences podman / docker
Avant de parler des différences, nous allons parler des points communs, podman et docker utilisent exactement la même CLI, c'est à dire que créer un alias docker pointant vers podman fonctionnera parfaitement :
docker run -ti alpine
devientpodman run -ti alpine
docker pull alpine
devientpodman pull alpine
- etc ...
Pas de clustering
Par contre avec podman, pas de clustering, podman swarm
n'existe pas.
Daemonless
Mais nous avons une différence de taille, podman est daemonless
. Contrairement à docker, il n'a pas besoin d'exposer une API, nous avons donc une architecture beaucoup plus simple.
Sous docker, nous avons la commandline docker
qui appelle l'API exposé par dockerd
qui lui même appelle l'API exposé par containerd
, qui lance containerd-shim
qui lui lance runc
qui lance enfin notre processus.
Sous podman, nous avons notre commandline podman
qui lance conmon
, qui lui lance runc
pour lancer notre conteneur. Et c'est tout.
Nous avons donc beaucoup moins d'étape avec podman qu'avec docker, et donc nous réduisons la surface d'attaque.
De plus sous docker, containerd
devient un SPOF, car il devient le maitre du lancement de tout les conteneurs, contrairement à podman qui lance un process conmon
par conteneur.
Rootless
Même si docker le permets désormais (mais toujours avec son daemon) (cf documentation), podman
est entièrement rootless Out-of-box. Cela veut dire que vous lancez vos conteneurs avec vos droits utilisateurs, pas de sudo
, pas de groupe docker
(qui vous donner beaucoup trop de permissions), vous lancez vos conteneurs, et ils tournerons avec vos permissions.
Dans votre conteneur, vous aurez tout de même l'utilisateur root, mais niveau host, il correspondra à votre utilisateur.
Petit exemple, mon utilisateur est xataz, il à l'UID 1000 sur ma machine Je lance donc mon conteneur comme ceci :
$ podman container run -d alpine ping 9.9.9.9
$ podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
6430b1dca84e docker.io/library/alpine:latest ping 9.9.9.9 6 seconds ago Up 5 seconds ago clever_euler
Si je fais un podman container top clever_euler
, j'obtiens :
USER PID PPID %CPU ELAPSED TTY TIME COMMAND
root 1 0 0.000 1m48.153058015s ? 0s ping 9.9.9.9
Dans le conteneur, on nous dit que c'est l'utilisateur root qui lance le ping
, mais si on regarde sur l'hôte :
$ ps aux | grep 9.9.9.9
xataz 106366 106354 0 00:28 ? 00:00:00 ping 9.9.9.9
Nous avons donc l'utilisateur root du conteneur qui se retrouve mappé sur l'utilisateur qui lance le conteneur.
Cependant, le mode rootless à quelques limitations :
- Pas de gestion de réseau, sur l'hôte seul root peut gérer ceci.
- Un support partiel des cgroups, via les cgroups v2, mais tout n'est pas limitable.
- Le mappage des ports limités au port supérieur à 1024.
Donc pour communiquer entre deux conteneurs, nous n'avons que 3 solutions :
- Mappé les ports sur l'hôte et contacter directement l'IP de l'hôte (ex :
podman container run -d -p 3306:3306 postgres
) - Utiliser le network host, pour que les ports soit directement mappé (ex :
podman container run --network host postgres
), comme ceci chaque conteneur partage le localhost. - Utiliser les pods, nous verrons donc cette méthode ensuite.
D'ailleurs, tout les tests réalisé dans cette article l'on été en mode rootless, je n'ai fait aucun test en rootfull.
Les Pods
Le concept de POD vient de kubernetes. C'est un groupe de un ou plusieurs conteneurs qui partagerons plusieurs ressources, notamment le réseau, avec un namespace partagé, mais aussi les cgroups par exemple.
Création et gestion d'un pod
Pour gérer un pod, c'est assez simple, nous avons la commande podman pod
, avec les sous-commandes create
, ps
, start
, stop
, rm
etc ...
Nous restons dans la même logique que docker, les commandes restent simples et explicites.
Nous allons pour tester rapidement un pod nommé test, avec un conteneur nginx, et un conteneur qui fait un curl sur le localhost. Ce pod exposera donc le port 8080.
Nous commençons donc par créer notre pod :
$ podman pod create --name test -p 8080:80
480348ec0517b5815053755386d0bc563f5f22e17d7db35c44662680ec05d796
Puis nous lançons notre premier conteneur dans notre pod test :
$ podman container run -d --pod test nginx
A ce stade nous avons donc notre pod test, et un conteneur nginx dedans, nous pouvons vérifier avec :
$ podman ps --pod
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES POD POD NAME
df295bc43cfa docker.io/library/nginx:latest nginx -g daemon o... About a minute ago Up About a minute ago 0.0.0.0:8080->80/tcp vibrant_bardeen 480348ec0517 test
Nous pouvons donc en local sur notre hôte acceder à locahost:8080, qui nous fournira la jolie page Welcome to nginx!.
Mais si d'un autre conteneur je veux accéder à cette page, comment faire ??
Il faudra taper sur le port 80, et non le port 8080 car celui n'est monté que sur l'hôte.
Donc si je fais un podman container run -ti --rm --pod test alpine wget 127.0.0.1 -O-
, nous avons bien notre page Welcome to nginx! qui s'affiche.
Ce pod n'étant qu'un test, nous pouvons le supprimer, et supprimer tout les conteneurs associés :
$ podman pod rm -f test
Nextcloud + redis + postgres
Pour un exemple un peu plus concret, nous allons créer un pod nommé cloud, avec 3 conteneurs, nextcloud, redis et postgres.
Nous utiliserons les images officiels pour ces 3 conteneurs.
Création du pod
Nous avons donc besoin de notre pod, nous savons déjà que nous aurons besoin de rediriger le port 80 du conteneur vers l'exterieur, nous utiliserons ici le port 8080.
Donc pour créer notre pod, nous lançons :
$ podman pod create --name cloud -p 8080:80
14130d03a965cad53f1b3792533d1fef5494650c8f7ae32b9f242d025b22b33e
Création du conteneur postgres
Ceci n'étant qu'un test, je vais faire une configuration plutôt simpliste, pas de mot de passe complexe, je lance donc mon conteneur postgres :
$ podman container run -d \
--pod cloud \
--name nextclouddb \
-e POSTGRES_USER="nextcloud" \
-e POSTGRES_PASSWORD="nextcloud" \
postgres
b4a4ef68b1b19226e8c3f259824ad289b56eff045ab077562b92aeca8a152f74
Création du conteneur redis
Pareil pour redis, nous utilisons l'image officiel :
$ podman container run -d \
--pod cloud \
--name nextcloudredis \
redis
b7eacdeb95e57128b30d9d0d2f6a46571764349ead3dbc2f1b73769fc66b2266
Création du conteneur Nextcloud
Puis la création la plus compliqué, mais pas insurmontable non plus, puisque c'est pour du test :
$ podman container run -d \
--pod cloud \
--name nextcloud \
-e POSTGRES_HOST="127.0.0.1" \
-e POSTGRES_DB="nextcloud" \
-e POSTGRES_USER="nextcloud" \
-e POSTGRES_PASSWORD="nextcloud" \
-e NEXTCLOUD_ADMIN_USER="xataz" \
-e NEXTCLOUD_ADMIN_PASSWORD="xataz" \
-e REDIS_HOST="127.0.0.1" \
nextcloud
Normalement, vous devriez pouvoir accéder à votre nextcloud avec l'IP de l'hôte sur le port 8080.
Analyse des conteneurs et du pod
Que pouvons nous voir de ces conteneurs ??
Déjà nous pouvons voir qu'il partage le même pod :
$ podman ps --pod
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES POD POD NAME
4658539082d1 docker.io/library/nextcloud:latest apache2-foregroun... 16 hours ago Up 16 hours ago 0.0.0.0:8080->80/tcp nextcloud e234d8f0f183 cloud
0844854e09aa docker.io/library/redis:latest redis-server 16 hours ago Up 16 hours ago 0.0.0.0:8080->80/tcp nextcloudredis e234d8f0f183 cloud
3b265454c8c0 docker.io/library/postgres:latest postgres 16 hours ago Up 16 hours ago 0.0.0.0:8080->80/tcp nextclouddb e234d8f0f183 cloud
Nous pouvons également voir que les conteneurs partages des namespaces :
$ podman ps --ns
CONTAINER ID NAMES PID CGROUPNS IPC MNT NET PIDNS USERNS UTS
4658539082d1 nextcloud 134799 4026531835 4026533078 4026533084 4026532736 4026533085 4026532734 4026533077
0844854e09aa nextcloudredis 134529 4026531835 4026533078 4026533082 4026532736 4026533083 4026532734 4026533077
3b265454c8c0 nextclouddb 134427 4026531835 4026533078 4026533080 4026532736 4026533081 4026532734 4026533077
Ici nous constatons que les namespaces CGROUP, IPC, NET, USER et UTS sont les mêmes.
Nous constatons également que nous avons 4 conteneurs dans notre pod :
$ podman pod ps
POD ID NAME STATUS CREATED # OF CONTAINERS INFRA ID
e234d8f0f183 cloud Running 16 hours ago 4 e82ce3139620
Pourquoi 4 conteneurs ? Nous n'en avons créés que 3 !!!
Tout simplement que dans un pod, nous avons un conteneur qui ne sert qu'à maintenir les namespaces partagés ouvert, car un namespace est forcément utilisé, sinon il est supprimé.
Nous pourrions utiliser une autre image, par exemple une image qui permet la gestion du pod, ou même un reverse proxy par exemple, je n'ai pas d'image en tête, mais cela reste une possibilité.
Bonus
L'intégration avec systemd
Podman intègre une fonction sympathique qui permets de générer des fichiers de configuration systemd, afin de l'utiliser en tant que service.
podman generate systemd --help
Generate a systemd unit file for a Podman container
Description:
Command generates a systemd unit file for a Podman container
Usage:
podman generate systemd [flags] CONTAINER | POD
Examples:
podman generate systemd ctrID
Flags:
-f, --files generate files instead of printing to stdout
-n, --name use the container/pod name instead of ID
--new create a new container instead of starting an existing one
--restart-policy string applicable systemd restart-policy (default "on-failure")
-t, --timeout int stop timeout override (default -1)
L'utilisation est plutôt simple.
La génération simple n'est pas des plus recommandé, car il ne permet que de lancer et stopper le conteneur déjà créé, il ne le créera pas :
$ podman generate systemd nextcloud
# container-4658539082d1f28bbd6c3d5fa59b525affa8cc1b7aa4247110cc5a87e049e3b4.service
# autogenerated by Podman 1.8.2
# Tue Apr 14 20:27:46 CEST 2020
[Unit]
Description=Podman container-4658539082d1f28bbd6c3d5fa59b525affa8cc1b7aa4247110cc5a87e049e3b4.service
Documentation=man:podman-generate-systemd(1)
Wants=network.target
After=network-online.target
[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
ExecStart=/usr/bin/podman start 4658539082d1f28bbd6c3d5fa59b525affa8cc1b7aa4247110cc5a87e049e3b4
ExecStop=/usr/bin/podman stop -t 10 4658539082d1f28bbd6c3d5fa59b525affa8cc1b7aa4247110cc5a87e049e3b4
PIDFile=/run/user/1000/containers/vfs-containers/4658539082d1f28bbd6c3d5fa59b525affa8cc1b7aa4247110cc5a87e049e3b4/userdata/conmon.pid
KillMode=none
Type=forking
[Install]
WantedBy=multi-user.target default.target
Nous pouvons donc via l'option --new
créer un service qui le créera proprement :
$ podman generate systemd --new nextcloud
# container-4658539082d1f28bbd6c3d5fa59b525affa8cc1b7aa4247110cc5a87e049e3b4.service
# autogenerated by Podman 1.8.2
# Tue Apr 14 20:28:02 CEST 2020
[Unit]
Description=Podman container-4658539082d1f28bbd6c3d5fa59b525affa8cc1b7aa4247110cc5a87e049e3b4.service
Documentation=man:podman-generate-systemd(1)
Wants=network.target
After=network-online.target
[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
ExecStartPre=/usr/bin/rm -f %t/%n-pid %t/%n-cid
ExecStart=/usr/bin/podman run --conmon-pidfile %t/%n-pid --cidfile %t/%n-cid --cgroups=no-conmon -d --pod cloud --name nextcloud -e POSTGRES_HOST=127.0.0.1 -e POSTGRES_DB=nextcloud -e POSTGRES_USER=nextcloud -e POSTGRES_PASSWORD=nextcloud -e NEXTCLOUD_ADMIN_USER=xataz -e NEXTCLOUD_ADMIN_PASSWORD=xataz -e REDIS_HOST=127.0.0.1 nextcloud
ExecStop=/usr/bin/podman stop --ignore --cidfile %t/%n-cid -t 10
ExecStopPost=/usr/bin/podman rm --ignore -f --cidfile %t/%n-cid
PIDFile=%t/%n-pid
KillMode=none
Type=forking
[Install]
WantedBy=multi-user.target default.target
L'option --name
est vraiment pas mal également, rends les services générés beaucoup plus clair :
$ podman generate systemd --new --name nextcloud
# container-nextcloud.service
# autogenerated by Podman 1.8.2
# Tue Apr 14 20:28:45 CEST 2020
[Unit]
Description=Podman container-nextcloud.service
Documentation=man:podman-generate-systemd(1)
Wants=network.target
After=network-online.target
[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
ExecStartPre=/usr/bin/rm -f %t/%n-pid %t/%n-cid
ExecStart=/usr/bin/podman run --conmon-pidfile %t/%n-pid --cidfile %t/%n-cid --cgroups=no-conmon -d --pod cloud --name nextcloud -e POSTGRES_HOST=127.0.0.1 -e POSTGRES_DB=nextcloud -e POSTGRES_USER=nextcloud -e POSTGRES_PASSWORD=nextcloud -e NEXTCLOUD_ADMIN_USER=xataz -e NEXTCLOUD_ADMIN_PASSWORD=xataz -e REDIS_HOST=127.0.0.1 nextcloud
ExecStop=/usr/bin/podman stop --ignore --cidfile %t/%n-cid -t 10
ExecStopPost=/usr/bin/podman rm --ignore -f --cidfile %t/%n-cid
PIDFile=%t/%n-pid
KillMode=none
Type=forking
[Install]
WantedBy=multi-user.target default.target
Nous pouvons bien évidemment générer directement le fichier :
$ podman generate systemd --new --name --files nextcloud
/home/xataz/Documents/Projects/podman/container-nextcloud.service
Pour l'utiliser il suffit donc de le mettre dans ~/.config/systemd/user/
, si le répertoire n'existe pas, il faudra le créer.
Puis le lancer avec systemctl --user start container-nextcloud
.
Nous pouvons également en générer plusieurs pour un pod complet, malheureusement je trouve dommage qu'il n'est pas possible d'utiliser l'option --new
avec un pod (Peut être dans une prochaine version):
$ podman generate systemd --new --name --files cloud
Error: error generating systemd unit files: cannot generate generic files for a pod
$ podman generate systemd --name --files cloud
/home/xataz/Documents/Projects/podman/pod-cloud.service
/home/xataz/Documents/Projects/podman/container-nextcloudredis.service
/home/xataz/Documents/Projects/podman/container-nextclouddb.service
/home/xataz/Documents/Projects/podman/container-nextcloud.service
Génération de fichier kubernetes
Podman permets également de générer des fichiers de configuration pour kubernetes, la commande est similaire à celle de systemd :
$ podman generate kube --help
Generate Kubernetes pod YAML from a container or pod
Description:
Command generates Kubernetes Pod YAML (v1 specification) from a podman container or pod.
Whether the input is for a container or pod, Podman will always generate the specification as a Pod. The input may be in the form of a pod or container name or ID.
Usage:
podman generate kube [flags] CONTAINER | POD
Examples:
podman generate kube ctrID
podman generate kube podID
podman generate kube --service podID
Flags:
-f, --filename string Filename to output to
-s, --service Generate YAML for kubernetes service object
Nous pouvons générer un fichier que pour notre conteneur (podman create --name test alpine
) :
$ podman generate kube alpine
# Generation of Kubernetes YAML is still under development!
#
# Save the output of this file and use kubectl create -f to import
# it into Kubernetes.
#
# Created with podman-1.8.2
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: "2020-04-14T18:47:56Z"
labels:
app: alpine
name: alpine
spec:
containers:
- command:
- /bin/sh
env:
- name: PATH
value: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
- name: TERM
value: xterm
- name: container
value: podman
- name: HOSTNAME
image: docker.io/library/alpine:latest
name: alpine
resources: {}
securityContext:
allowPrivilegeEscalation: true
capabilities: {}
privileged: false
readOnlyRootFilesystem: false
seLinuxOptions: {}
workingDir: /
status: {}
Ou alors pour notre pod directement :
$ podman generate kube cloud
# Generation of Kubernetes YAML is still under development!
#
# Save the output of this file and use kubectl create -f to import
# it into Kubernetes.
#
# Created with podman-1.8.2
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: "2020-04-14T18:48:26Z"
labels:
app: cloud
name: cloud
spec:
containers:
- command:
- redis-server
env:
- name: PATH
value: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
- name: TERM
value: xterm
- name: container
value: podman
- name: GOSU_VERSION
value: "1.11"
- name: REDIS_VERSION
value: 5.0.8
- name: REDIS_DOWNLOAD_URL
value: http://download.redis.io/releases/redis-5.0.8.tar.gz
- name: REDIS_DOWNLOAD_SHA
value: f3c7eac42f433326a8d981b50dba0169fdfaf46abb23fcda2f933a7552ee4ed7
- name: HOSTNAME
value: cloud
image: docker.io/library/redis:latest
name: nextcloudredis
ports:
- containerPort: 80
hostPort: 8080
protocol: TCP
resources: {}
securityContext:
allowPrivilegeEscalation: true
capabilities: {}
privileged: false
readOnlyRootFilesystem: false
seLinuxOptions: {}
workingDir: /data
- command:
- postgres
env:
- name: PATH
value: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/lib/postgresql/12/bin
- name: TERM
value: xterm
- name: LANG
value: en_US.utf8
- name: PG_MAJOR
value: "12"
- name: GOSU_VERSION
value: "1.11"
- name: PGDATA
value: /var/lib/postgresql/data
- name: POSTGRES_PASSWORD
value: nextcloud
- name: PG_VERSION
value: 12.2-2.pgdg100+1
- name: POSTGRES_USER
value: nextcloud
- name: container
value: podman
- name: HOSTNAME
value: cloud
image: docker.io/library/postgres:latest
name: nextclouddb
resources: {}
securityContext:
allowPrivilegeEscalation: true
capabilities: {}
privileged: false
readOnlyRootFilesystem: false
seLinuxOptions: {}
workingDir: /
- command:
- apache2-foreground
env:
- name: PATH
value: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
- name: TERM
value: xterm
- name: APACHE_CONFDIR
value: /etc/apache2
- name: PHP_EXTRA_CONFIGURE_ARGS
value: --with-apxs2 --disable-cgi
- name: NEXTCLOUD_VERSION
value: 18.0.3
- name: PHP_CFLAGS
value: -fstack-protector-strong -fpic -fpie -O2 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
- name: REDIS_HOST
value: 127.0.0.1
- name: PHP_LDFLAGS
value: -Wl,-O1 -Wl,--hash-style=both -pie
- name: PHP_INI_DIR
value: /usr/local/etc/php
- name: PHP_EXTRA_BUILD_DEPS
value: apache2-dev
- name: POSTGRES_HOST
value: 127.0.0.1
- name: NEXTCLOUD_ADMIN_USER
value: xataz
- name: GPG_KEYS
value: CBAF69F173A0FEA4B537F470D66C9593118BCCB6 F38252826ACD957EF380D39F2F7956BC5DA04B5D
- name: PHP_VERSION
value: 7.3.16
- name: POSTGRES_DB
value: nextcloud
- name: NEXTCLOUD_ADMIN_PASSWORD
value: xataz
- name: PHP_ASC_URL
value: https://www.php.net/get/php-7.3.16.tar.xz.asc/from/this/mirror
- name: PHP_MD5
- name: POSTGRES_USER
value: nextcloud
- name: APACHE_ENVVARS
value: /etc/apache2/envvars
- name: PHP_SHA256
value: 91aaee3dbdc71b69b4f3292f9d99211172a2fa926c3f3bbdb0e85dab03dd2bcb
- name: container
value: podman
- name: PHP_CPPFLAGS
value: -fstack-protector-strong -fpic -fpie -O2 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
- name: PHPIZE_DEPS
value: "autoconf \t\tdpkg-dev \t\tfile \t\tg++ \t\tgcc \t\tlibc-dev \t\tmake
\t\tpkg-config \t\tre2c"
- name: POSTGRES_PASSWORD
value: nextcloud
- name: PHP_URL
value: https://www.php.net/get/php-7.3.16.tar.xz/from/this/mirror
- name: HOSTNAME
value: cloud
image: docker.io/library/nextcloud:latest
name: nextcloud
resources: {}
securityContext:
allowPrivilegeEscalation: true
capabilities: {}
privileged: false
readOnlyRootFilesystem: false
seLinuxOptions: {}
workingDir: /var/www/html
status: {}
Avec un fichier c'est mieux :
$ podman generate kube --filename cloud.yaml cloud
Cependant, comme nous pouvons le voir, la génération n'est pas totalement complète et correcte, car nous avons mappé les ports sur le pod, et non sur le conteneur redis, nous avons bien l'option --service
, mais celui ci monte les ports sur des ports aléatoires :
$ podman generate kube --service cloud
# Generation of Kubernetes YAML is still under development!
#
# Save the output of this file and use kubectl create -f to import
# it into Kubernetes.
#
# Created with podman-1.8.2
[...]
---
apiVersion: v1
kind: Service
metadata:
creationTimestamp: "2020-04-14T18:54:47Z"
labels:
app: cloud
name: cloud
spec:
ports:
- name: "80"
nodePort: 30004
port: 80
protocol: TCP
targetPort: 0
selector:
app: cloud
type: NodePort
status:
loadBalancer: {}
J'espère sincèrement que tout ceci sera amélioré dans de futures versions.
podman-compose
Comme précedemment dit, il existe un podman-compose. Je ne vais pas expliquer ici l'installation de l'outil, ou même son fonctionnement, car il est 100% compatible avec docker-compose.
Podman-compose n'est différent que dans la gestion des conteneurs, il part du principe que chaque fichier yaml est un pod, et donc va créer un pod et y mettre les conteneurs dedans. Pour un soucis de transparence avec docker, il va cependant ajouter les noms des conteneurs dans le fichier /etc/hosts
afin de pouvoir simuler un réseau docker (en rootless évidemment).
Cependant j'ai remarqué un petit défaut, par exemple j'avais l'habitude avec docker-compose de simplement lancer un docker-compose up -d
pour mettre à jour les modifications apporté, il gérait donc automatiquement les conteneurs à mettre à jour ou non. Avec podman-compose
, cela ne fonctionne malheureusement pas, il faut d'abord supprimer le pod, puis le relancer.
TroubleShooting
J'ai pu observer quelques bugs :
- Problème de purge des répertoires, j'avais beau avoir supprimer mes images et conteneurs, ainsi que volumes, mon répertoire home était toujours pleins, et pleins de layers liés à podman. Je n'ai pas observé ce problème sous Manjaro ou CentOS 8.
- Des problèmes aléatoires sur le mappage de port, enfin plutôt des fonctionnements aléatoires. J'ai créer un pod en mappant des ports, au premier lancement les ports se sont correctement mappés, mais il m'a fallu environ 50 lancements pour qu'ils remappent correctement. Pareil, que sur debian et apparemment ubuntu, je n'ai pas vu le soucis sur Manjaro et CentOS.
- Un soucis également avec le localhost dans un pod, qui ne pointe pas sur 127.0.0.1, donc j'ai pris l'habitude d'utiliser 127.0.0.1.
Problème avec le rootless
Il faudra peut être que vous autorisiez les utilisateurs à créer des namespacesv pour ceci il suffit de modifier le fichier en root /proc/sys/kernel/unprivileged_userns_clone
en y écrivant un 1
dedans :
echo 1 > /proc/sys/kernel/unprivileged_userns_clone
Ceci ne sera modifier que jusqu'au reboot de la machine.
Pour le modifier définitivement, soit vous modifiez le fichier /etc/sysctl.conf en y ajoutant kernel.unprivileged_userns_clone = 1
, toujours en root
Conclusion
Podman est vraiment un très bon outil, je l'ai testé que en mode rootless, ceci manque cruellement de maturité pour un usage en production.
Pour le l'usage personnel, c'est vraiment top, je l'utilise sur mon PC portable depuis quelques temps, j'ai remplacé mes docker par podman, même si je pense de plus en plus à passer sur du k3s pour clusterer le tout.
Podman a vraiment un énorme potentiel, déjà il rend le rootless facilement accessible, puis en plus il est daemonless, ce qui en fait l'outils parfait pour le développement.
Je l'ai déjà dis, j'ai tout testé en mode rootless, peux être que certains beug rencontrer ne le sont pas en rootfull.
Comments
February 11, 2023 01:41
I really enjoyed your post. I learned a lot of new and interesting knowledge krunker about technology and programming. Thank you for sharing. tetris unblocked