Homelab Proxmox : une plateforme DevOps auto-hébergée, entièrement en code

Mon homelab repose sur deux machines.

Le Raspberry Pi, la machine de production : il héberge 24 heures sur 24, une pile de services personnels que j'utilise réellement au quotidien (reverse proxy, DNS, gestionnaire de mots de passe, cloud personnel, synchronisation de notes).

Le PC sous Proxmox, à côté, ne faisait tourner qu'un seul conteneur : Uptime Kuma, un simple outil de vérification de disponibilité.

Ce projet est né de ce constat : plutôt que de laisser ce Proxmox inutilisé, en faire une vraie plateforme d'infrastructure - et surtout, saisir l'occasion pour sortir de ma zone de confort sur des sujets que je maîtrisais peu jusque-là : l'Infrastructure as Code, l'observabilité multi-machines, les pipelines CI/CD de bout en bout.

Le PC a peu de RAM, donc conteneurs LXC plutôt que VM classiques pour rester léger.

Les deux machines physiques communiquent via un réseau mesh Tailscale, le Proxmox jouant le rôle de routeur de sous-réseau (subnet router) : il expose tout le réseau local du homelab au mesh, de sorte que les deux machines et leurs services se rejoignent comme s'ils étaient sur le même LAN - sans jamais ouvrir le moindre port en frontal sur Internet.

Les quatre conteneurs LXC

Schéma d'architecture

flowchart TB
    Dev(("Moi - git push")) --> GHA["GitHub Actions"]
    GHA --> Runner

    subgraph Proxmox["PC Proxmox - ~2,7 Go RAM - routeur Tailscale"]
        direction TB
        Runner["CI/CD Runner (LXC)"]
        Registry["Docker Registry (LXC)"]
        Kuma["Uptime Kuma (LXC)"]
        Prom["Prometheus + Grafana (LXC)"]
        ExpProxmox["node_exporter"]
    end

    subgraph Pi["Raspberry Pi - production 24/7"]
        direction TB
        Services["Services personnels"]
        API["Démo API FastAPI"]
        Daemon["Daemon télécommande (Python)"]
        ExpPi["node_exporter"]
    end

    Runner -->|"build croisé + push"| Registry
    Runner -->|"SSH : pull + redeploy"| API
    Registry -.-> API
    Kuma -.-> Services
    Kuma -.-> API
    Prom --> ExpProxmox
    Prom --> ExpPi
    Proxmox <-.->|"mesh Tailscale"| Pi
    Remote["Télécommande C++/Qt 6"] -.->|"socket TCP"| Daemon
    Daemon -.-> API
              

Le fil conducteur du projet est l'Infrastructure as Code. Plutôt que de cliquer dans des interfaces et de taper des commandes que j'oublierais six mois plus tard, j'ai décrit l'intégralité de l'infrastructure dans du code Ansible versionné sur Git.

Concrètement : le dépôt Git est l'infrastructure. Chaque conteneur, chaque service, chaque réglage réseau y est déclaré noir sur blanc, sous forme de rôles Ansible modulaires - un rôle par service, jamais un script monolithique.

- name: Créer le conteneur LXC du registre Docker
  community.general.proxmox_lxc:
    api_host: "{{ proxmox_api_host }}"
    api_token_secret: "{{ proxmox_api_token_secret | vault }}"
    hostname: docker-registry
    ostemplate: "local:vztmpl/debian-12-standard_amd64.tar.zst"
    memory: 256
    cores: 1
    state: present

- name: Déployer le conteneur registry (idempotent)
  community.docker.docker_container:
    name: registry
    image: "registry:2"
    state: started
    restart_policy: unless-stopped
    ports:
      - "127.0.0.1:5000:5000"
    volumes:
      - registry_data:/var/lib/registry

Extrait illustratif, représentatif de la structure réelle des rôles du dépôt homelab-proxmox-iac.

Reproductibilité, historique des changements dans Git, et une doc qui ne se périme jamais - c'est le code lui-même.

« Voir l'état de tout mon homelab depuis un seul écran. »

Prometheus collecte les métriques système - CPU, RAM, disque, réseau - du Raspberry Pi et de l'hôte Proxmox, via un agent node_exporter déployé sur chaque machine. Il interroge (scrape) chaque agent à intervalle régulier et conserve l'historique : c'est la seule source de vérité chronologique de l'infrastructure, indépendante de l'état actuel des machines.

Grafana agrège le tout dans un tableau de bord unique, avec un sélecteur pour basculer d'une machine à l'autre en un coup d'œil. Chaque tableau de bord est lui-même défini en JSON versionné dans le dépôt - la même logique d'Infrastructure as Code appliquée à la supervision elle-même.

Les deux machines dialoguent au-delà de la simple remontée de métriques : l'hôte Proxmox expose l'état de ses conteneurs, que ce tableau de bord central peut exploiter, tandis que les outils du Raspberry Pi mesurent le trafic généré par l'ensemble de l'infrastructure.

« Je pousse mon code, et il se déploie tout seul. »

C'est le cœur du projet : une boucle CI/CD complète où, à chaque git push sur une application, une chaîne entièrement automatisée se déclenche. Pour la démontrer bout en bout, j'ai développé une petite API en FastAPI dédiée à cette démonstration (demo-api).

name: Build & Deploy demo-api
on:
  push:
    branches: [main]

jobs:
  build-and-deploy:
    runs-on: self-hosted   # runner auto-hébergé, sur le Proxmox
    steps:
      - uses: actions/checkout@v4

      - name: Set up QEMU (émulation ARM64)
        uses: docker/setup-qemu-action@v3

      - name: Build croisé + push
        run: |
          docker buildx build \
            --platform linux/arm64 \
            --tag registry.internal:5000/demo-api:{{ github.sha }} \
            --push .

      - name: Déploiement SSH sur le Raspberry Pi
        run: |
          ssh -i {{ secrets.PI_DEPLOY_KEY }} deploy@pi.tailnet \
            "docker pull registry.internal:5000/demo-api:{{ github.sha }} && \
             docker compose up -d demo-api"

      - name: Health check
        run: curl --fail https://demo-api.tailnet/health

Extrait illustratif du pipeline réel - la forme exacte du workflow.

Quatre problèmes ont demandé un vrai travail de diagnostic technique (un cinquième, l'idempotence des rôles Ansible, est traité en section 3, car il relève davantage de la méthode que d'un incident ponctuel).

[registry."registry.internal:5000"]
  http = true
  insecure = true

Liens du projet