Installer Portainer Linux avec Docker Compose pour administrer ses conteneurs depuis une interface web

Installer Portainer sur Linux avec Docker Compose

User avatar placeholder
Écrit par Vincent

Mis à jour le 7 septembre 2026

Portainer est une interface web open source qui permet de gérer des conteneurs Docker sans taper la moindre commande docker. Elle affiche en un coup d’œil conteneurs, images, volumes et réseaux, et permet de les piloter depuis un navigateur. Ce tutoriel explique comment installer Portainer sur Linux via Docker Compose, sécuriser l’accès et couvre trois points que la plupart des guides passent sous silence : les failles de sécurité corrigées en 2026, la procédure de mise à jour, et la sauvegarde/restauration de la configuration.

L’essentiel

  • Commande clé : docker compose up -d
  • Prérequis : Docker et Docker Compose installés, port 9443 libre
  • Distributions : universel — toute distribution avec Docker
  • Vérifié le : 7 septembre 2026 · Portainer CE 2.45.0 LTS (27 août 2026)

Prérequis

Avant de commencer, vérifiez que Docker et Docker Compose sont installés et fonctionnels :

docker --version
docker compose version

Si Docker n’est pas encore installé, consultez le guide d’installation de Docker sur Linux avant de continuer — Portainer est lui-même un conteneur Docker, il en dépend entièrement.

Vous avez également besoin :

  • d’un accès sudo sur la machine, pour toutes les commandes de ce tutoriel qui touchent au socket Docker (/var/run/docker.sock) : le $ des blocs de code est une convention typographique, pas une indication que la commande fonctionne sans droits élevés ;
  • du port 9443 libre (interface web HTTPS) ;
  • de 5 minutes environ pour l’installation, plus le temps de créer le compte administrateur au premier lancement — ce délai expire après 5 minutes.

Un point qui prête à confusion sur les forums d’entraide : le volume nommé portainer_data ne contient que la configuration de Portainer (comptes, paramètres, connexions aux environnements). Il est distinct des volumes que vos futurs conteneurs utiliseront eux-mêmes — ne cherchez pas vos données applicatives dedans.

Installer Portainer sur Linux avec Docker Compose

La documentation officielle propose une commande docker run directe. Ce tutoriel utilise Docker Compose à la place : le fichier de configuration reste lisible, versionnable, et cohérent avec le reste de votre parc de conteneurs si vous suivez déjà le guide Nginx Proxy Manager, ou d’autres stacks Docker Compose du site comme Jellyfin et Vaultwarden.

Schéma des 5 étapes pour installer Portainer sur Linux : prérequis, compose.yaml, lancement, compte admin, sécurisation

Créer le fichier de configuration

Créez un répertoire dédié et le fichier compose.yaml :

mkdir -p ~/portainer && cd ~/portainer
nano compose.yaml

Collez ce contenu :

services:
  portainer:
    container_name: portainer
    image: portainer/portainer-ce:lts
    restart: always
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - portainer_data:/data
    ports:
      - "9443:9443"
      - "8000:8000"

volumes:
  portainer_data:
    name: portainer_data

Le volume /var/run/docker.sock donne à Portainer un accès direct au démon Docker de l’hôte : c’est ce qui lui permet de piloter vos conteneurs. Le port 8000 ne sert que si vous prévoyez de connecter des Edge Agents (gestion multi-hôtes distants) ; vous pouvez le retirer sur une installation mono-serveur.

Cas particulier SELinux. Si SELinux est actif sur votre machine, la documentation officielle précise : « SELinux is disabled on the machine running Docker. If you require SELinux, you will need to pass the --privileged flag to Docker when deploying Portainer » — ajoutez privileged: true au service dans le fichier ci-dessus. Sur une installation standard sans SELinux, ignorez cette note.

Lancer et vérifier

docker compose up -d

Docker Compose crée le réseau, le volume, puis démarre le conteneur :

 Network portainer_default  Created
 Volume portainer_data      Created
 Container portainer        Started

Vérification — le conteneur doit apparaître à l’état Up, avec les deux ports publiés :

docker compose ps
NAME        IMAGE                        COMMAND   SERVICE     CREATED         STATUS         PORTS
portainer   portainer/portainer-ce:lts   ...       portainer   10 seconds ago  Up 9 seconds   0.0.0.0:8000->8000/tcp, 0.0.0.0:9443->9443/tcp

La colonne PORTS est celle qui compte : si elle est vide, le conteneur tourne sans que ses ports soient publiés, et l’interface restera inaccessible.

Vous pouvez confirmer le mappage indépendamment :

docker port portainer
# 8000/tcp -> 0.0.0.0:8000
# 9443/tcp -> 0.0.0.0:9443

Niveau de preuve : le fichier compose.yaml ci-dessus a été déployé réellement avec Docker 29.4.3 et Docker Compose v5.1.3 — création du réseau, du volume nommé et du conteneur, publication des deux ports, montage du socket et du volume vérifiés par docker inspect. La sortie de docker compose ps reproduite ici est celle réellement produite par Compose v5 (sept colonnes). Seule l’image officielle portainer/portainer-ce:lts n’a pas pu être tirée depuis l’environnement de test : la colonne IMAGE et la colonne COMMAND afficheront donc chez vous les valeurs de l’image officielle. Le comportement applicatif de Portainer lui-même (interface web, écran de création de compte) reste conforme à la documentation officielle, non testé.

Première connexion et création du compte admin

Ouvrez https://<ip-du-serveur>:9443 dans votre navigateur. Portainer utilise un certificat auto-signé : votre navigateur affichera un avertissement de sécurité qu’il faut accepter manuellement (voir la section Erreurs courantes).

Vous disposez de 5 minutes après le démarrage du conteneur pour créer le compte administrateur — c’est une mesure de sécurité documentée officiellement, pas un bug. Passé ce délai, le conteneur doit être redémarré (docker compose restart) pour rouvrir la fenêtre de configuration.

Renseignez un nom d’utilisateur et un mot de passe d’au moins 12 caractères, puis validez l’écran de bienvenue pour prendre la main sur l’environnement Docker local, détecté automatiquement.

Vérification — le tableau de bord doit afficher votre environnement Docker local avec le nombre de conteneurs, images, volumes et réseaux détectés.

Prendre en main l’interface

Section Rôle
Containers Démarrage, arrêt, redémarrage, logs et console interactive (exec) d’un clic
Images Images Docker téléchargées, suppression et nettoyage des images inutilisées
Volumes Volumes de données, inspection du contenu
Networks Réseaux Docker et conteneurs qui y sont rattachés
Stacks Ensembles de conteneurs définis par un fichier Compose, gérés comme une unité

Déployer un stack via Portainer

Portainer permet de déployer un fichier Docker Compose complet sans passer par le terminal. Depuis la section de gestion des stacks (voir tableau ci-dessus), créez un nouveau stack, donnez-lui un nom, puis collez le contenu d’un fichier compose.yaml existant — par exemple celui utilisé pour installer Nginx Proxy Manager — dans l’éditeur intégré, avant de lancer le déploiement.

Vérification — le stack apparaît avec le statut active, et ses conteneurs sont visibles dans la section de gestion des conteneurs.

Portainer CE ou Business Edition : que choisir ?

La question revient souvent et la plupart des tutoriels français n’y répondent pas. Portainer Community Edition (CE), utilisée dans ce tutoriel, est gratuite, open source, sans limite de conteneurs pour un usage personnel ou une petite structure.

Portainer Business Edition (BE) ajoute des fonctionnalités orientées équipes et conformité : contrôle d’accès basé sur les rôles (RBAC) avancé, authentification LDAP/OAuth centralisée, gestion de licences et support éditeur. Elle est gratuite jusqu’à 3 nœuds (« Get 3 Nodes Free »), avec un essai étendu au-delà, d’après la page officielle des tarifs.

Pour un usage personnel ou un homelab, CE couvre l’essentiel de ce tutoriel sans restriction. BE se justifie à partir du moment où plusieurs administrateurs doivent avoir des droits différenciés sur les mêmes environnements, ou où une authentification d’entreprise (LDAP, SSO) est nécessaire — un besoin qui dépasse le cadre de cet article.

Comparatif entre Portainer Community Edition et Business Edition : fonctionnalités, limites et prix

Sécuriser l’accès

Trois précautions s’imposent avant d’exposer Portainer, même sur un réseau local.

Restreindre le port 9443 au réseau local. Si UFW est actif sur la machine, limitez l’accès à votre sous-réseau plutôt que de l’ouvrir à toute adresse :

sudo ufw allow from 192.168.1.0/24 to any port 9443 proto tcp

Voir le guide de configuration d’UFW pour la logique complète des règles de pare-feu.

Éviter le certificat auto-signé en production. Il est fonctionnel mais génère un avertissement navigateur à chaque connexion et n’est validé par aucune autorité. Pour un accès depuis l’extérieur de votre réseau local, placez Portainer derrière un reverse proxy avec certificat Let’s Encrypt — voir le guide Nginx Proxy Manager — plutôt que d’exposer le port 9443 directement sur Internet.

Limiter les accès au socket Docker. Le montage de /var/run/docker.sock donne à Portainer — et donc à quiconque a accès à son interface — un contrôle équivalent à root sur l’hôte. Un compte Portainer compromis équivaut à un accès root complet. Ne créez pas de comptes utilisateurs Portainer superflus, et activez l’authentification à deux facteurs, disponible dans les réglages d’authentification de l’interface.

Sécurité : les failles 2026 et pourquoi rester à jour

Deux vulnérabilités critiques touchent Portainer et méritent d’être connues avant toute mise en production : CVE-2026-44848 et CVE-2026-44849, chacune notée 9,4 sur 10 sur l’échelle CVSS, selon l’alerte publiée le 20 mai 2026 par le Centre pour la Cybersécurité Belgique (CCB).

CVE-2026-44848 touche la gestion des plugins Docker : les points d’accès /plugins/* ne vérifiaient pas les autorisations, permettant à un utilisateur authentifié non-administrateur d’installer et d’activer des plugins arbitraires — Docker exécutant les plugins activés en root sur l’hôte, cela ouvrait la voie à une exécution de code au niveau système. CVE-2026-44849 touche la création de services Swarm : les contrôles de sécurité n’étaient appliqués qu’à la création (POST /services/create) et pas aux mises à jour, permettant de contourner les restrictions en ajoutant des capacités élevées ou des montages de chemins hôte après coup.

Les versions concernées sont les séries 2.33.0–2.33.7, 2.39.0–2.39.1 et 2.40, d’après l’alerte du CCB. Le correctif initial a laissé une lacune résiduelle : les notes de version officielles de la 2.45.0 LTS (27 août 2026) indiquent explicitement « Closed a remaining gap in the CVE-2026-44849 (GHSA-5fxq-qcf3-244w) fix and broadened bind-mount restrictions for non-admin users, now including Compose and Swarm stack deployments » — la restriction couvre désormais aussi les déploiements via Compose, le mode d’installation retenu dans ce tutoriel. La version installée ici (2.45.0 LTS) intègre ce correctif complet.

Niveau de preuve : conforme à l’alerte officielle du CCB Belgium et aux notes de version publiées par Portainer — non testé (aucun accès à un environnement vulnérable pour reproduire l’exploitation).

Ce que cela signifie concrètement pour vous : Portainer publie deux canaux, LTS (support long, lignes 2.39.x puis 2.45.x) et STS (support court, lignes 2.40.x à 2.44.x). Le correctif complet est arrivé le 27 août 2026 dans la 2.45.0 LTS et, pour ceux qui restent sur la ligne LTS précédente, dans la 2.39.7. Si vous gérez une instance antérieure à ces versions, la mise à jour n’est pas une simple précaution : elle ferme une porte d’accès root documentée publiquement.

Mettre à jour Portainer

La documentation officielle décrit la procédure de mise à jour pour un déploiement docker run : arrêter le conteneur, télécharger la nouvelle image, redéployer avec le même volume nommé pour conserver les données.

docker compose pull
docker compose up -d

Niveau de preuve : cette commande suit le même principe que la procédure officielle documentée pour docker run (arrêt implicite du conteneur, récupération de la nouvelle image, redéploiement sur le volume portainer_data existant). Elle n’est cependant pas explicitement documentée pour Docker Compose sur la documentation officielle à la date de rédaction, et n’a pas été testée dans le cadre de cet article. Vérifiez le résultat avec docker compose logs portainer après exécution.

Les données de configuration (comptes, connexions aux environnements) sont conservées automatiquement grâce au volume persistant portainer_data:/data, quelle que soit la méthode de déploiement.

Sauvegarder et restaurer Portainer

Toute la configuration de Portainer (comptes, environnements Docker connectés, identifiants de registre, stacks enregistrés) vit dans une base BoltDB stockée sur le volume nommé portainer_data. Deux méthodes de sauvegarde existent, à ne pas confondre : la fonction de sauvegarde intégrée à l’interface, et une sauvegarde brute du volume au niveau de Docker.

Méthode recommandée : la sauvegarde intégrée de Portainer

Portainer propose une fonction de sauvegarde native, accessible depuis les réglages généraux de l’interface. Elle génère un fichier .tar.gz téléchargeable directement depuis le navigateur, avec un chiffrement par mot de passe optionnel.

Cette sauvegarde couvre la base de données Portainer et les fichiers stack déployés depuis Portainer. Elle ne couvre pas ce qui tourne dans vos environnements Docker : conteneurs, images, volumes applicatifs ne sont pas inclus, seule la configuration de Portainer l’est.

La restauration se fait uniquement au moment d’un déploiement neuf : installez Portainer sur un volume portainer_data vide, et l’assistant de premier démarrage propose une option de restauration à partir d’un fichier de sauvegarde et d’un jeton d’installation (setup token, affiché dans les logs du conteneur). Après restauration, vous retrouvez la page de connexion et vos identifiants d’origine fonctionnent.

Niveau de preuve : conforme à la documentation officielle (docs.portainer.io/admin/settings/general), non testée dans le cadre de cet article — la génération réelle du fichier de sauvegarde suppose une instance Portainer fonctionnelle, indisponible dans l’environnement de vérification (voir plus haut la limite sur les registres Docker).

Méthode alternative : sauvegarde brute du volume Docker

Utile en scripts d’automatisation, en l’absence d’accès à l’interface, ou pour une sauvegarde système incluant tout le contenu du volume plutôt que la seule configuration applicative.

Avertissement — un volume Docker ne doit jamais être copié à chaud avec des écritures en cours sur des fichiers ouverts (bases embarquées de type BoltDB, comme celle utilisée par Portainer). Arrêtez le conteneur avant la sauvegarde pour garantir une archive cohérente : une sauvegarde à chaud peut capturer un fichier en cours d’écriture et produire une archive corrompue, inutilisable au moment de la restaurer.

Sauvegarder le volume

# 1. Arrêter Portainer sans supprimer le volume
docker compose stop

# 2. Sauvegarder le contenu du volume dans une archive, via un conteneur jetable
docker run --rm \
  -v portainer_data:/data \
  -v "$(pwd)":/backup \
  alpine tar czf /backup/portainer-data-$(date +%Y%m%d).tar.gz -C /data .

# 3. Relancer Portainer
docker compose start

Niveau de preuve : la commande tar czf ... -C /data . a été testée réellement (GNU tar) sur un volume Docker nommé au contenu connu, ainsi que le cycle complet suppression du volume puis restauration à partir de l’archive obtenue, qui a rendu un contenu identique à l’original. Le conteneur jetable alpine n’a en revanche pas pu être testé tel quel : les registres Docker (docker.io) n’étaient pas joignables depuis l’environnement de vérification de cet article. La mécanique (montage du volume en lecture, montage du répertoire courant en écriture, tar vers l’extérieur) a été validée avec un conteneur équivalent construit localement. Alpine et sa commande tar intégrée sont conformes à la documentation officielle Docker pour ce cas d’usage.

L’archive obtenue (portainer-data-AAAAMMJJ.tar.gz) contient l’intégralité du volume : copiez-la vers un stockage externe à la machine (autre serveur, stockage objet, sauvegarde locale hors du disque hébergeant Docker). Une sauvegarde qui reste sur la même machine que l’original ne protège pas contre une panne disque ou une erreur de manipulation sur cette machine. Le fichier est créé par le conteneur, donc appartenant à root sur l’hôte : un compte non-root devra utiliser sudo pour le déplacer ou le lire.

Restaurer le volume

La restauration suppose un volume portainer_data vide ou tout juste recréé — jamais un volume contenant déjà des données à conserver, puisque l’extraction fusionne son contenu dans le volume cible sans le vider au préalable.

# 1. Arrêter et supprimer le conteneur (le volume nommé survit à cette étape)
docker compose down

# 2. Si le volume existe encore et doit être repris à zéro, le supprimer explicitement
docker volume rm portainer_data

# 3. Recréer le volume vide
docker volume create portainer_data

# 4. Restaurer l'archive dans le volume
docker run --rm \
  -v portainer_data:/data \
  -v "$(pwd)":/backup \
  alpine tar xzf /backup/portainer-data-AAAAMMJJ.tar.gz -C /data

# 5. Relancer Portainer sur le volume restauré
docker compose up -d

Niveau de preuve : le cycle docker compose down → docker volume rm → docker volume create → extraction de l’archive → vérification du contenu a été testé réellement dans son intégralité ; le fichier de test placé dans le volume avant sauvegarde était identique, octet pour octet, après restauration. Comme pour la sauvegarde, seul le conteneur alpine utilisé pour l’extraction n’a pas pu être tiré directement dans l’environnement de vérification ; la commande tar xzf elle-même a été validée avec GNU tar.

Après restauration, connectez-vous à Portainer : les comptes, environnements et stacks enregistrés avant la sauvegarde doivent apparaître à l’identique. Si l’interface se comporte comme une première installation (écran de création de compte), la restauration n’a pas fonctionné — vérifiez que l’archive n’était pas vide (tar tzf portainer-data-AAAAMMJJ.tar.gz doit lister des fichiers) avant de relancer la procédure.

Vérifier que tout fonctionne

Trois vérifications rapides confirment une installation saine :

# 1. Le conteneur tourne et publie ses ports
docker compose ps
# La colonne STATUS doit indiquer « Up », la colonne PORTS doit lister 9443

# 2. Le port est bien mappé sur l'hôte
docker port portainer
# 9443/tcp -> 0.0.0.0:9443

# 3. Les logs ne montrent pas d'erreur au démarrage
docker compose logs portainer --tail 20

Le certificat de Portainer étant auto-signé, un test HTTPS en ligne de commande doit désactiver la vérification du certificat, sinon il échoue alors que le service fonctionne :

curl -k -I https://localhost:9443

Une réponse HTTP, quel qu’en soit le code, suffit à prouver que le service écoute. Une erreur de connexion, en revanche, indique que le conteneur ne tourne pas ou que le port n’est pas publié — revenez alors aux deux commandes précédentes.

Niveau de preuve : les commandes docker compose ps et docker port ont été exécutées réellement (Docker 29.4.3, Compose v5.1.3). Le code HTTP exact renvoyé par Portainer sur le port 9443 n’a pas pu être observé, l’image officielle n’ayant pas pu être tirée dans l’environnement de test : aucun code précis n’est donc annoncé ici.

Désinstaller Portainer

Pour retirer Portainer sans toucher aux autres conteneurs de la machine :

cd ~/portainer
docker compose down
# Container portainer  Removed
# Network portainer_default  Removed

Cette commande ne supprime pas vos données. Le volume portainer_data survit à un docker compose down : vos comptes et vos réglages sont toujours là, et un simple docker compose up -d restaure l’instance à l’identique. C’est ce qui rend la mise à jour sans risque, mais c’est aussi ce qui explique qu’une réinstallation « propre » retrouve l’ancien mot de passe administrateur.

Pour supprimer également les données de configuration (comptes, stacks enregistrés), une fois le conteneur arrêté :

docker volume rm portainer_data

Niveau de preuve : testé. Le volume nommé a bien survécu à docker compose down, puis a été supprimé par docker volume rm (Docker 29.4.3, Compose v5.1.3).

Les conteneurs que Portainer a déployés via des stacks ne sont pas supprimés par cette opération : ils continuent de tourner indépendamment, gérables ensuite avec docker compose classique.

Erreurs courantes

« Votre connexion n’est pas privée » dans le navigateur

Normal : Portainer génère un certificat TLS auto-signé au premier démarrage. Votre navigateur ne peut pas le valider auprès d’une autorité reconnue et affiche un avertissement — l’option pour poursuivre malgré tout se trouve généralement dans les paramètres avancés de l’écran d’alerte, avec un libellé qui varie selon le navigateur. Pour supprimer cet avertissement durablement, placez Portainer derrière un reverse proxy avec un certificat valide.

Le port 9443 est déjà utilisé

Le conteneur est créé puis refuse de démarrer. Sur Docker 29, le message complet est le suivant :

Error response from daemon: failed to set up container networking: driver failed programming
external connectivity on endpoint portainer: Bind for 0.0.0.0:9443 failed: port is already allocated

Sur Docker 28 et antérieur, le segment failed to set up container networking: est absent, le reste est identique.

Un autre service occupe déjà le port. Identifiez lequel :

sudo ss -tlnp | grep 9443

Arrêtez ensuite ce service, ou changez le port publié dans compose.yaml — en modifiant uniquement la valeur de gauche, qui est celle exposée sur l’hôte :

    ports:
      - "9444:9443"

Puis relancez docker compose up -d. L’interface sera alors sur https://<ip-du-serveur>:9444.

« permission denied » en lançant les commandes

Le message exact dépend de votre version de Docker. Depuis Docker 29, il mentionne l’« API Docker » :

permission denied while trying to connect to the docker API at unix:///var/run/docker.sock

Sur Docker 28 et antérieur, encore très répandu sur les distributions stables, la formulation parle du « daemon socket » :

Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock

Dans les deux cas, la cause est identique : le socket Docker appartient à root. Chaque commande de ce tutoriel doit être précédée de sudo, y compris les commandes docker compose, pas seulement la première. C’est le point de friction le plus fréquent relevé sur les forums d’entraide francophones lors d’une première installation.

L’alternative durable consiste à ajouter votre utilisateur au groupe docker, décrite dans le tutoriel d’installation de Docker.

Avertissement — appartenir au groupe docker équivaut à disposer des droits root sur la machine : tout membre du groupe peut démarrer un conteneur qui monte l’intégralité du système de fichiers hôte. Sur un serveur partagé, conservez sudo plutôt que d’élargir ce groupe.

La fenêtre de création du compte admin a expiré

L’interface affiche un message indiquant que l’instance a expiré pour des raisons de sécurité — la FAQ officielle intitule ce cas « Your Portainer instance has timed out for security purposes ».

Le délai de 5 minutes après le démarrage du conteneur est dépassé. Redémarrez le conteneur pour rouvrir la fenêtre :

docker compose restart portainer

Impossible d’accéder à l’interface après l’installation

Ce cas recoupe le plus souvent le délai de 5 minutes ci-dessus, d’après la FAQ officielle : passé ce délai sans création du compte admin, le serveur Portainer arrête complètement d’écouter les requêtes, et un simple redémarrage du conteneur rouvre la fenêtre. Si le conteneur tourne (docker compose ps) et que ce délai n’est pas en cause, vérifiez ensuite qu’un pare-feu ne bloque pas le port 9443 en amont de Docker — une cause plausible mais non documentée officiellement pour ce cas précis, à vérifier avec curl -k -I https://localhost:9443 en local sur la machine avant de suspecter Portainer lui-même.

Questions fréquentes

C’est quoi Portainer ? Portainer est une interface web open source qui simplifie la gestion des conteneurs Docker, Podman et Kubernetes. Elle remplace les commandes docker par des actions cliquables : démarrer, arrêter, consulter les logs, déployer un stack Compose.

Quelle est la différence entre Portainer CE et Business Edition ? La CE est gratuite et open source, sans limite de conteneurs pour un usage personnel. La BE ajoute RBAC avancé, authentification d’entreprise (LDAP/SSO) et support éditeur, gratuite jusqu’à 3 nœuds.

Quelle est la différence entre Portainer et Docker Desktop ? Docker Desktop est une application locale pour développeurs, centrée sur une seule machine. Portainer est un service web accessible à distance, pensé pour administrer un ou plusieurs serveurs, avec gestion des utilisateurs et des accès.

Portainer est-il disponible en français ? Oui, l’interface propose une traduction française activable dans les paramètres de langue du compte utilisateur, bien que la documentation officielle reste en anglais.

Quel est le port par défaut de Portainer ? Le port 9443 pour l’interface web HTTPS, et le port 8000 pour le tunnel Edge Agent (optionnel, à retirer si vous n’utilisez pas d’agents distants).

Quelles sont les alternatives à Portainer ? Dockge et Yacht sont deux alternatives légères orientées gestion de stacks Compose plutôt que gestion complète de conteneurs individuels. Portainer reste l’option la plus complète pour qui veut aussi piloter des environnements Kubernetes depuis la même interface.

Comment sauvegarder Portainer ? La fonction de sauvegarde intégrée à l’interface génère un fichier .tar.gz téléchargeable, avec chiffrement par mot de passe optionnel, à restaurer au moment d’une nouvelle installation sur un volume vide. Une sauvegarde brute du volume portainer_data avec docker et tar fonctionne aussi et couvre l’ensemble du volume, voir la section dédiée plus haut.

Conclusion

Portainer donne une vue d’ensemble sur vos conteneurs sans sacrifier le contrôle : chaque action de l’interface reste traçable dans les logs, et rien n’empêche de repasser en ligne de commande à tout moment. L’installation via Docker Compose plutôt que docker run documente votre configuration et se redéploie à l’identique en cas de migration de serveur. Le point qui distingue une installation de homelab d’une installation de production reste la sécurité : rester en version 2.45.0 LTS ou ultérieure n’est pas une optimisation facultative, c’est ce qui ferme un accès root documenté publiquement.

Pour aller plus loin, sécurisez l’accès avec un reverse proxy et un certificat SSL valide via Nginx Proxy Manager, et revoyez vos règles de pare-feu avec le tutoriel UFW pour limiter l’exposition du port 9443 à votre seul réseau local.

Sources officielles

Vincent

Vincent est le créateur de MémoLinux. Venu de Windows par curiosité, il est resté sur Linux pour sa logique et le plaisir de comprendre ce qui se passe sous le capot. Il documente ici les commandes et les procédures qu’il utilise lui-même, avec leurs sources officielles et leur date de vérification.

Laisser un commentaire