Morpheus
Services / Plateforme de conteneurs

Docker sur Arch Linux

Installation, validation du moteur et base d'exploitation Docker sur Arch Linux avec un modèle de privilège explicite et des extensions futures vers Compose et les services homelab.

Docker Compose volumes réseaux Dockerfile
Position publique de Docker dans les services du lab
Vue publique: Docker Engine, images, conteneurs, volumes persistants, réseaux applicatifs et maintenance.
01

Installer

Préparer Docker Engine, Compose et le service système avec une lecture explicite du modèle de privilège.

02

Exécuter

Lancer un service Nginx réel avec exposition HTTP locale et contrôle de santé lisible.

03

Composer

Décrire et lancer une stack Compose minimale avec volume nommé et politique de redémarrage.

04

Maintenir

Contrôler logs, images, volumes, réseaux, espace disque et persistance après recréation du conteneur.

Contexte

Le problème réel.

Docker rend le déploiement rapide, mais le socket, les volumes, les secrets et le groupe docker peuvent donner un pouvoir équivalent root. La documentation doit donc expliquer le workflow sans exposer les configurations réelles.

Objectifs

Ce que la solution devait garantir.

  • Installer Docker et valider l'engine sans supposer que le groupe docker est neutre.
  • Documenter une stack Compose exploitable avec volume persistant et service HTTP simple.
  • Documenter maintenance, monitoring et dépannage sans publier les chemins, ports ou secrets privés.
Architecture publique

Structure documentée, détails exploitables retirés.

Exemples anonymisés

Ce qui peut être montré sans exposer le système réel.

Concepts Docker publics

La page distingue clairement les objets Docker avant de montrer les commandes.

image        template en lecture seule avec app et dépendances
container    instance en cours d'exécution d'une image
volume       données persistantes hors cycle de vie du conteneur
network      frontière de communication entre conteneurs
compose      stack déclarative multi-conteneurs

Stack Compose anonymisée

La structure est montrée sans reprendre les noms, ports, secrets ou chemins privés.

services:
  app:
    image: <APP_IMAGE>:<TAG>
    ports:
      - "<HOST_PORT>:<CONTAINER_PORT>"
    volumes:
      - <APP_VOLUME>:<APP_DATA_PATH>
    restart: unless-stopped

volumes:
  <APP_VOLUME>:

Cycle de maintenance

Le workflow public montre ce qui doit être contrôlé avant et après mise à jour.

docker compose config
docker compose pull
docker compose up -d
docker logs --tail 100 <CONTAINER_NAME>
docker system df
docker volume ls
Runbook public

Commandes et états attendus issus de la documentation privée.

Les commandes ci-dessous sont volontairement anonymisées: chemins, noms de machines, interfaces, dépôts, périphériques et actions destructrices sont remplacés par des placeholders.

Documentation privée: Docker

Contrôles d'installation

Commandes anonymisées

systemctl status docker.service --no-pager
sudo docker version
sudo docker run --rm hello-world
groups <operator> | rg 'docker'

État attendu

le service Docker est actif
le client parle bien au moteur côté serveur
le conteneur de test se termine correctement
l'appartenance au groupe docker est traitée comme un risque équivalent root
Documentation privée: Docker

Volumes et réseaux

Commandes anonymisées

docker volume ls
docker volume inspect <volume-name>
docker network ls
docker network inspect <network-name>
docker inspect <container-name>

État attendu

les données persistantes sont identifiées
l'exposition réseau est explicite
les montages du conteneur sont relus
les chemins et adresses privés ne sont pas publiés
Documentation privée: Docker

Compose et maintenance

Commandes anonymisées

docker compose config
docker compose up -d
docker compose logs -f
docker compose pull
docker compose up -d
docker system df

État attendu

le fichier Compose est syntaxiquement valide
les services démarrent et exposent les logs attendus
les mises à jour recréent proprement les conteneurs
l'usage disque est surveillé avant pruning
Travail réalisé

Décisions techniques publiables.

Installation contrôlée

Les paquets sont présents, le service démarre correctement et le test hello-world valide la chaîne client -> daemon -> runtime.

Modèle de privilège relu

L'usage validé aujourd'hui passe par sudo docker; le groupe docker n'est pas utilisé sur cet hôte.

Stack Compose démontrée

Un mini lab Nginx piloté par `docker compose` sert une page HTML locale sur `127.0.0.1:8080` avec healthcheck et redémarrage automatique.

Persistance validée

Le volume `morpheus_nginx_data` reste intact après restart puis suppression/recréation du conteneur, sans perte du service HTTP.

Validation

Preuves et contrôles retenus.

Preuves visuelles

Contrôles observables et portée de la preuve.

Résultats publics

Ce que le chantier démontre.

Anonymisation

Ce qui reste privé.

  • Pas de docker-compose privé.
  • Pas de variables d'environnement, mots de passe, chemins de volumes ou ports réels.
  • Pas de noms de domaines, réseaux privés ou registres privés; seul le nom du volume de démonstration est publié.
  • Les commandes utilisent des placeholders et des valeurs d'exemple non sensibles.
Sources privées

Documentation d'origine.

  • Guide Docker sur Arch Linux.
  • Notes de services conteneurisés.
  • Runbooks volumes, réseaux et Compose.
  • Hardening système et gestion des privilèges.

Supplément de documentation privée anonymisé

Docker sur Arch Linux

Guide public pour installer, exploiter et maintenir Docker sur Arch Linux dans un homelab. Cette version documente surtout une base moteur validée et le modèle de privilège retenu. Les exemples conservent la logique opérationnelle, mais les noms de services, ports, chemins, domaines et secrets sont anonymisés.

La seconde passe de validation publique ajoute un mini lab Compose avec Nginx, un volume nommé de démonstration et des contrôles de persistance après redémarrage puis recréation du conteneur.

Qu'est-ce que Docker ?

Docker exécute des applications dans des conteneurs isolés qui partagent le noyau de l'hôte. Le gain principal est la reproductibilité: même image, mêmes dépendances, même lancement.

  • Léger: démarrage rapide et consommation réduite.
  • Portable: même image sur plusieurs hôtes compatibles.
  • Isolé: système de fichiers et réseau séparés par conteneur.
  • Reproductible: configuration déclarée par image ou Compose.

Prérequis

Contrôler le noyau et l'architecture avant installation:

uname -r
uname -m

Le poste doit être à jour et l'opérateur doit comprendre que Docker manipule des ressources proches du système hôte.

Installation

Installer Docker Engine et Compose, puis activer le service:

sudo pacman -S docker docker-compose
sudo systemctl start docker.service
sudo systemctl enable docker.service
sudo systemctl status docker.service
Groupe docker = privilèges élevés

Un membre du groupe docker peut monter des chemins de l'hôte et obtenir un accès équivalent root. Sur cette machine, l'usage validé reste sudo docker et l'utilisateur courant n'est pas membre du groupe. Sur une machine durcie, préférer un usage root explicite, rootless, Podman ou un compte dédié selon le risque accepté.

sudo usermod -aG docker <OPERATOR>
groups <OPERATOR> | rg 'docker'
sudo docker run --rm hello-world

Concepts de base

ObjetRôle
ImageModèle en lecture seule avec application, dépendances et commande de lancement.
ConteneurInstance exécutée depuis une image.
VolumeDonnées persistantes qui survivent à la suppression du conteneur.
RéseauIsolation et résolution entre conteneurs ou vers l'extérieur.

Commandes essentielles

Lancer, lister, diagnostiquer et inspecter:

docker run -d --name <CONTAINER_NAME> <IMAGE>:<TAG>
docker run -it <IMAGE>:<TAG> <SHELL>
docker run -d -p <HOST_PORT>:<CONTAINER_PORT> <IMAGE>:<TAG>
docker ps
docker images
docker logs --tail 100 <CONTAINER_NAME>
docker exec -it <CONTAINER_NAME> <SHELL>
docker inspect <CONTAINER_NAME>
docker stats <CONTAINER_NAME>

Exemples pratiques

Exemple web statique avec port et chemin anonymisés:

docker run -d \
  --name <WEB_CONTAINER> \
  -p <HOST_PORT>:80 \
  -v <HOST_HTML_DIR>:/usr/share/nginx/html:ro \
  nginx:alpine

Exemple base de données avec volume persistant et secrets remplacés:

docker run -d \
  --name <DB_CONTAINER> \
  -e POSTGRES_PASSWORD=<DB_PASSWORD> \
  -e POSTGRES_USER=<DB_USER> \
  -e POSTGRES_DB=<DB_NAME> \
  -v <DB_VOLUME>:/var/lib/postgresql/data \
  -p <HOST_DB_PORT>:5432 \
  postgres:<TAG>

Les services comme cloud personnel, interface de gestion ou monitoring suivent la même logique: réseau dédié, volumes nommés, secrets externalisés et exposition minimale.

Docker Compose

Compose décrit une stack multi-conteneurs dans un fichier YAML. La version publique montre la structure, pas les valeurs privées:

services:
  web:
    image: <WEB_IMAGE>:<TAG>
    ports:
      - "<HOST_PORT>:80"
    volumes:
      - <WEB_DATA>:/usr/share/nginx/html:ro
    restart: unless-stopped

  db:
    image: <DB_IMAGE>:<TAG>
    environment:
      POSTGRES_PASSWORD: <DB_PASSWORD>
      POSTGRES_USER: <DB_USER>
      POSTGRES_DB: <DB_NAME>
    volumes:
      - <DB_DATA>:/var/lib/postgresql/data
    restart: unless-stopped

volumes:
  <WEB_DATA>:
  <DB_DATA>:
docker compose config
docker compose up -d
docker compose logs -f
docker compose down
docker compose pull
docker compose up -d

Exemple de mini lab réellement démontré publiquement:

services:
  nginx:
    image: nginx:alpine
    ports:
      - "8080:80"
    volumes:
      - ./nginx/html:/usr/share/nginx/html:ro
      - morpheus_nginx_data:/data
    restart: unless-stopped

volumes:
  morpheus_nginx_data:
    external: true

Gestion des volumes

Les volumes sont traités comme des données à sauvegarder:

docker volume create <VOLUME_NAME>
docker volume ls
docker volume inspect <VOLUME_NAME>
docker volume rm <VOLUME_NAME>

Backup et restauration anonymisés:

docker run --rm -v <VOLUME_NAME>:/data -v <BACKUP_DIR>:/backup alpine tar czf /backup/<ARCHIVE>.tar.gz -C /data .
docker run --rm -v <VOLUME_NAME>:/data -v <BACKUP_DIR>:/backup alpine tar xzf /backup/<ARCHIVE>.tar.gz -C /data

Gestion des réseaux

Utiliser des réseaux explicites pour limiter la communication entre services:

docker network create <NETWORK_NAME>
docker network ls
docker network inspect <NETWORK_NAME>
docker network connect <NETWORK_NAME> <CONTAINER_NAME>
docker network disconnect <NETWORK_NAME> <CONTAINER_NAME>
docker network rm <NETWORK_NAME>

Dockerfile

Créer une image applicative minimale:

FROM <RUNTIME_IMAGE>:<TAG>
WORKDIR /app
COPY <DEPENDENCY_FILES> ./
RUN <INSTALL_DEPENDENCIES>
COPY . .
EXPOSE <APP_PORT>
USER <APP_USER>
CMD ["<START_COMMAND>"]

Les instructions critiques sont FROM, WORKDIR, COPY, RUN, EXPOSE, USER, CMD et ENTRYPOINT.

Bonnes pratiques

  • Ne pas stocker de secrets dans une image ou dans l'historique de build.
  • Créer un utilisateur non-root dans les images applicatives.
  • Limiter les volumes au strict nécessaire.
  • Préférer des tags contrôlés plutôt que latest pour les services importants.
  • Limiter les logs avec une politique de rotation.
  • Documenter les politiques de redémarrage: unless-stopped, always, on-failure ou no.

Maintenance et nettoyage

Mesurer avant de nettoyer:

docker system df
docker container prune
docker image prune -a
docker volume prune
docker network prune
docker system prune -a --volumes
Nettoyage destructif

Les commandes prune peuvent supprimer des ressources non attachées mais encore utiles. Faire un inventaire et un backup avant exécution réelle.

Validation publique réalisée

docker compose ps
curl -i http://127.0.0.1:8080
docker volume inspect morpheus_nginx_data
docker compose restart
docker compose rm -sf
docker compose up -d
curl -i http://127.0.0.1:8080

État observé publiable:

la stack Compose démarre proprement
nginx répond en HTTP 200 sur 127.0.0.1:8080
le volume morpheus_nginx_data est identifié explicitement
le service reste disponible après redémarrage
le service revient après suppression puis recréation du conteneur

Monitoring et statistiques

docker stats
docker stats <CONTAINER_NAME>
docker logs -f <CONTAINER_NAME>
docker logs --tail 100 <CONTAINER_NAME>

Les interfaces de gestion et les agents de monitoring doivent être traités comme des services sensibles, surtout s'ils montent le socket Docker.

Dépannage

Contrôles de base:

docker logs <CONTAINER_NAME>
docker inspect <CONTAINER_NAME>
ss -tlnp | rg '<HOST_PORT>'
docker exec <CONTAINER_NAME> ls -la <DATA_PATH>
docker network inspect <NETWORK_NAME>
docker pull <IMAGE>:<TAG>

Les erreurs fréquentes viennent d'un port déjà utilisé, d'un volume avec permissions incorrectes, d'une variable manquante, d'une image inaccessible ou d'un réseau mal choisi.

Ressources

  • Documentation officielle Docker.
  • Documentation Docker Compose.
  • Wiki Arch Docker.
  • Notes privées de services et de backups, non publiées.