---
title: "Self-Hosting et Cloud Hybride : Mon Infrastructure Perso avec Gitea et Scaleway"
date: 2025-11-20
authors:
  - name: Damien
    link: https://gitea.arnodo.fr/Damien
tags:
  - Homelab
  - DevOps
  - Self-Hosting
  - Network Engineering
---

Retour d'expérience sur la construction de mon infrastructure personnelle : migration de GitHub vers Gitea auto-hébergé, et déploiement de labs réseau éphémères sur Scaleway. Le tout avec Proxmox et Wireguard.

<!--more-->

## Contexte et Motivations

En tant qu'ingénieur réseau travaillant dans le domaine de l'automatisation et de l'orchestration, j'ai toujours eu besoin d'un environnement pour expérimenter et apprendre. Jusqu'à récemment, j'utilisais GitHub pour mon code et ContainerLab en local/AWS via [DevPod](/documentation/devpod/) pour mes simulations réseau.

Mais plusieurs envies ont émergé :

- **Apprentissage** : Déployer et gérer un serveur Git complet avec CI/CD
- **Souveraineté** : Héberger mes données en France (à minima en Europe), contrôler mon infrastructure
- **Flexibilité** : Pouvoir lancer des labs réseau à la demande sans saturer ma machine locale
- **Automatisation** : Scripter le provisionnement complet de mes environnements

## L'Architecture Globale

![Architecture](global_architecture.fr.svg)

### Stack Technique

**Homelab** :
- **Proxmox VE** : Hyperviseur pour VMs et LXC
- **LXC Containers** : Gitea, runners, services divers
- **Ansible** : Gestion des configurations et mises à jour
- **Grafana/Prometheus/Loki** : Monitoring et supervision

**Exposition publique** :
- **Dedibox Scaleway** : Instance dédiée avec IP fixe
- **Nginx Proxy Manager** : Reverse proxy avec SSL automatique
- **Wireguard VPN** : Tunnel sécurisé entre Scaleway et homelab

**Cloud Scaleway** :
- **Object Storage** : Hébergement du blog Hugo (S3-compatible)
- **Instances** : Labs réseau éphémères provisionnés à la demande
- **Scaleway CLI** : Automatisation complète

## Partie 1 : Migration GitHub → Gitea Auto-Hébergé

### Pourquoi Gitea ?

[Gitea](https://gitea.io/) est un serveur Git leger, parfaite pour du self-hosting :

- **Léger** : Idéal pour un LXC sur Proxmox
- **Compatible GitHub Actions** : Migration des workflows sans réécriture
- **Complet** : Issues, PRs, CI/CD, webhooks
- **Open-source** : Communauté active

### Déploiement avec Proxmox Helper Scripts

Plutôt que de tout configurer manuellement, j'utilise les excellents [Proxmox Helper Scripts](https://community-scripts.github.io/ProxmoxVE/) qui automatisent la création de LXC préconfigurés.

**Installation de Gitea** :

```bash
# Sur le nœud Proxmox, exécuter le script
bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/ct/gitea.sh)"
```

Le script :
- Crée un LXC Debian 12
- Installe Gitea et sqlite
- Configure les services systemd
- Prépare l'environnement avec les bonnes permissions

**Configuration post-installation** :
- Accès web : `http://<IP_LXC>:3000`
- Configuration initiale via l'interface
- URL du site : `https://gitea.arnodo.fr`

### Architecture Réseau : Wireguard + Nginx Proxy Manager

**Le problème** : Gitea tourne dans mon homelab (IP privée), mais je veux y accéder depuis Internet.

**La solution** :
1. **Dedibox Scaleway** avec IP publique fixe et Nginx Proxy Manager
2. **Wireguard VPN** entre la Dedibox et le homelab
3. Le reverse proxy route `gitea.arnodo.fr` vers l'IP privée du LXC via le tunnel

**Configuration Wireguard (côté homelab)** :

```ini
[Interface]
Address = 10.0.0.1/24
PrivateKey = <private_key>
ListenPort = 51820

[Peer]
# Dedibox Scaleway
PublicKey = <dedibox_public_key>
AllowedIPs = 10.0.0.2/32
Endpoint = <dedibox_public_ip>:51820
PersistentKeepalive = 25
```

**Nginx Proxy Manager** :
- Proxy Host : `gitea.arnodo.fr`
- Forward Hostname/IP : `10.0.0.x` (IP du LXC Gitea via Wireguard)
- Forward Port : `3000`
- SSL : Let's Encrypt automatique
- Websockets : Activés

### Gestion avec Ansible

Pour maintenir Gitea à jour et gérer les configurations, j'utilise Ansible.

**Playbook de mise à jour** (`update-gitea.yml`) :

```yaml
---
- name: Update Gitea
  hosts: gitea
  become: yes
  tasks:
    - name: Update apt cache
      apt:
        update_cache: yes
        cache_valid_time: 3600

    - name: Upgrade Gitea and system packages
      apt:
        upgrade: dist
        autoremove: yes
        autoclean: yes

    - name: Restart Gitea service
      systemd:
        name: gitea
        state: restarted
        enabled: yes

    - name: Check Gitea version
      command: gitea --version
      register: gitea_version

    - debug:
        msg: "{{ gitea_version.stdout }}"
```

**Exécution** :

```bash
ansible-playbook -i inventory.ini update-gitea.yml
```

### Monitoring avec Grafana

Gitea expose des métriques Prometheus (https://docs.gitea.com/administration/config-cheat-sheet#metrics-metrics)    
Configuration :

**Dans Gitea (`app.ini`)** :

```ini
[metrics]
ENABLED = true
TOKEN = <secret_token>
```

**Prometheus scrape config** :

```yaml
scrape_configs:
  - job_name: 'gitea'
    metrics_path: /metrics
    bearer_token: '<secret_token>'
    static_configs:
      - targets: ['<gitea_lxc_ip>:3000']
```

**Dashboard Grafana** (https://grafana.com/docs/grafana-cloud/monitor-infrastructure/integrations/integration-reference/integration-gitea/#gitea-integration-for-grafana-cloud) :
- Nombre de repositories, utilisateurs
- Requêtes HTTP (rate, latence)
- État des runners CI/CD
- Utilisation CPU/RAM du LXC

### Migration du Code depuis GitHub

Simple et rapide :  
Utiliser la fonction d'import de Gitea (Settings > New Migration > GitHub) qui migre aussi les issues et releases.

### CI/CD : Déploiement Hugo vers Scaleway Object Storage

Mon blog Hugo se déploie automatiquement sur Scaleway Object Storage à chaque push.

**Installation de Gitea Runner** (https://docs.gitea.com/usage/actions/act-runner)

Créer l’utilisateur système runner :

```bash
useradd -r -m -d /var/lib/gitea-runner -s /bin/bash gitea-runner
```

Voici un petit script qui peut aider à installer le runner directement dans un LXC:

```bash
sudo apt install -y jq curl tar # si pas déjà

LATEST=$(curl -s 'https://gitea.com/api/v1/repos/gitea/act_runner/releases' | jq -r '.[0].tag_name')
echo "Latest act_runner: $LATEST"

# construire URL de binaire (nommage used: act_runner-<os>-<arch>)
OS=$(uname -s | tr '[:upper:]' '[:lower:]')
ARCH=$(uname -m)
# Certains serveurs distribuent binaire sans tar; adapter si archive
URL="https://gitea.com/gitea/act_runner/releases/download/${LATEST}/act_runner-${LATEST#v}-${OS}-${ARCH}"

# essayer télécharger binaire
curl -fL "$URL" -o /tmp/act_runner || {
  echo "Téléchargement direct échoué — vérifier le nom exact sur la page release." >&2
  exit 1
}

sudo mv /tmp/act_runner /usr/local/bin/act_runner
sudo chmod +x /usr/local/bin/act_runner
```

et pour valider 

```bash
/usr/local/bin/act_runner --version
```

>[!NOTE]
> Il est important d'enregistrer le runner pour qu'il soit reconnu par Gitea.  
> Pour plus d'informations sur la configuration du runner, consultez la documentation officielle de Gitea.  
> https://docs.gitea.io/fr/docs/usage/actions/runner/

**Workflow Gitea Actions** (`.gitea/workflows/deploy.yml`) :

```yaml
name: Build and Deploy Hugo

on:
  pull_request:
    types: [closed]
    branches:
      - main

jobs:
  build_and_deploy:
    if: github.event.pull_request.merged == true
    name: Deploy Hugo Website
    runs-on: self-hosted

    container:
      image: debian:bookworm-slim

    steps:
      - name: Install dependencies
        run: |
          apt-get update
          apt-get install -y git curl ca-certificates wget

      - name: Install Hugo
        run: |
          wget https://github.com/gohugoio/hugo/releases/download/v0.152.2/hugo_extended_withdeploy_0.152.2_linux-amd64.deb -O /tmp/hugo.deb
          dpkg -i /tmp/hugo.deb

      - name: Checkout code
        run: |
          git clone --recurse-submodules https://gitea.arnodo.fr/Damien/Notebook.git /tmp/workspace
          cd /tmp/workspace
          git checkout ${{ github.sha }}

      - name: Build site
        run: /usr/local/bin/hugo
        working-directory: /tmp/workspace

      - name: Deploy to Scaleway
        run: /usr/local/bin/hugo deploy --force --maxDeletes -1
        working-directory: /tmp/workspace
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.SCW_ACCESS_KEY }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.SCW_SECRET_KEY }}

```

**Configuration Hugo** (`hugo.yaml`) :

```yaml
deployment:
  targets:
    - name: "notebook-arnodo-fr"
      URL: "s3://notebook-arnodo-fr?endpoint=https://s3.fr-par.scw.cloud&region=fr-par"
```

**Configuration Scaleway Object Storage** :
1. Créer un bucket `notebook-arnodo-fr`
2. Activer le mode "Static Website Hosting"
3. Générer les credentials API (Access Key + Secret Key)
4. Les ajouter comme secrets dans Gitea (Settings > Secrets > Actions)

**Déploiement** :

```bash
git add .
git commit -m "New blog post"
git push origin main
```

Le workflow se déclenche automatiquement, Hugo génère le site, et le déploie sur Scaleway Object Storage. Le site est accessible instantanément via le CDN.

## Partie 2 : Labs Réseau sur Scaleway

### Le Problème

ContainerLab avec plusieurs Arista EOS en local, c'est :
- **Gourmand** : 4-8 GB RAM par conteneur cEOS
- **Local** : Pas d'accès depuis l'extérieur
- **Conflits** : Avec d'autres services Docker/K8s

### La Solution : Instances Scaleway à la Demande

**Concept** :
- Créer une instance Scaleway quand j'ai besoin d'un lab
- Installer automatiquement ContainerLab/le VPN via cloud-init
- Détruire l'instance après utilisation
- Facturation à l'heure (< 1€ pour quelques heures de lab)

### Script d'Automatisation : Scaleway CLI

J'ai développé un script Bash qui gère tout le cycle de vie d'une instance de lab.

**Fonctionnalités** :
- **Création** : Instance + Security Group (SSH depuis mon IP uniquement)
- **Start/Stop** : Gestion de l'instance
- **Suppression** : Nettoyage complet (instance, volumes, IP, SG)

**Structure du script** (`scaleway-instance.sh`) :

```bash
#!/bin/bash
# Configuration
INSTANCE_NAME="NetLab"
ZONE="fr-par-1"
IMAGE="debian_bookworm"
VOLUME_SIZE=20  # GB
USER_DATA_FILE="user_data.txt"
SECURITY_GROUP_NAME="${INSTANCE_NAME}-SG"

# Détecte l'IP publique actuelle
get_public_ip() {
  curl -4 -s ifconfig.me
}

# Crée un Security Group limitant SSH à l'IP publique
create_or_update_security_group() {
  PUBLIC_IP=$(get_public_ip)
  # Crée le SG avec inbound SSH uniquement depuis PUBLIC_IP/32
  # ...
}

# Actions : create, start, stop, delete
case "$1" in
  start)
    # Démarre l'instance existante
    scw instance server start "$INSTANCE_ID" --wait
    ;;
  stop)
    # Arrête l'instance
    scw instance server stop "$INSTANCE_ID" --wait
    ;;
  delete)
    # Supprime instance + volumes + IP + SG
    scw instance server terminate "$INSTANCE_ID" --with-ip --with-block
    scw instance security-group delete "$SG_ID"
    ;;
  *)
    # Crée une nouvelle instance
    create_instance "$1"  # Type d'instance (DEV1-S, GP1-XS, ...)
    ;;
esac
```

### Cloud-Init : Configuration Automatique

Le fichier `user_data.txt` contient les instructions cloud-init pour provisionner l'instance automatiquement.

**Exemple** (`user_data.txt`) :

```yaml
#cloud-config
package_update: true
package_upgrade: true

packages:
  - git
  - curl
  - docker.io
  - docker-compose

runcmd:
  # Installation de ContainerLab
  - bash -c "$(curl -sL https://get.containerlab.dev)"
  
  # Clone d'un repo avec des topologies
  - git clone https://gitea.arnodo.fr/Damien/network-labs.git /root/labs
  
  # Démarrage d'une topologie par défaut
  - cd /root/labs && containerlab deploy -t spine-leaf.clab.yml
```

### Utilisation Pratique

**Créer un lab** :

```bash
# Crée une instance DEV1-S avec 20 GB de stockage
./scaleway-instance.sh DEV1-S 20

# Attend quelques minutes pour cloud-init
# Récupère l'IP publique
scw instance server list name=NetLab -o json | jq -r '.servers[0].public_ip.address'

# SSH vers l'instance
ssh root@<IP_PUBLIQUE>

# ContainerLab est déjà lancé !
containerlab inspect
```

**Détruire le lab** :

```bash
./scaleway-instance.sh delete
```

### Intégration avec Raycast

Pour simplifier encore plus, j'ai créé un script Raycast qui me permet de gérer mes instances directement depuis mon Mac.

**Script Raycast** :

```bash
#!/bin/bash
# @raycast.schemaVersion 1
# @raycast.title Scaleway Instance
# @raycast.mode silent
# @raycast.icon 🖥️
# @raycast.argument1 { "type": "text", "placeholder": "Action or instance type" }
# @raycast.argument2 { "type": "text", "placeholder": "Volume size", "optional": true }
# @raycast.packageName NetLab

/path/to/scaleway-instance.sh "$1" "$2"
```

**Utilisation** :
- `⌘ + Space` → "Scaleway Instance DEV1-S" → Crée l'instance
- `⌘ + Space` → "Scaleway Instance delete" → Supprime l'instance

### Cas d'Usage : Lab BGP/EVPN avec Arista

**Topologie ContainerLab** (`spine-leaf.clab.yml`) :

```yaml
name: evpn-lab

topology:
  nodes:
    spine1:
      kind: ceos
      image: ceos:latest
    spine2:
      kind: ceos
      image: ceos:latest
    leaf1:
      kind: ceos
      image: ceos:latest
    leaf2:
      kind: ceos
      image: ceos:latest

  links:
    - endpoints: ["spine1:eth1", "leaf1:eth1"]
    - endpoints: ["spine1:eth2", "leaf2:eth1"]
    - endpoints: ["spine2:eth1", "leaf1:eth2"]
    - endpoints: ["spine2:eth2", "leaf2:eth2"]
```

**Workflow** :
1. Créer l'instance Scaleway
2. Cloud-init déploie la topologie
3. Configurer BGP/EVPN via Ansible ou manuellement
4. Tester, expérimenter
5. Détruire l'instance

**Coût** : Instance DEV1-S (2 vCPU, 2GB) = ~0.015€/heure. 4 heures de lab = 0.06€.

## Souveraineté Numérique : Pourquoi C'est Important

Cette infrastructure hybride reflète une conviction personnelle sur la souveraineté numérique.

### Le Contexte

Dans mon travail d'ingénieur réseau, je vois l'importance de la maîtrise de ses infrastructures.  

Choisir Scaleway (groupe Iliad, français) et self-hoster Gitea, c'est :
- **Soutenir l'écosystème tech européen**
- **Garantir la protection RGPD** : Juridiction française
- **Réduire la latence** : Datacenters à Paris
- **Comprendre** : Maîtriser sa chaîne complète

### Apprentissage par la Pratique

En tant que professionnel du réseau (Arista, BGP/EVPN, automation), self-hoster me permet de :
- Appliquer les principes Infrastructure as Code
- Comprendre en profondeur les mécanismes CI/CD
- Expérimenter sans limite
- Reproduire des environnements professionnels

## Bilan

### Ce qui Fonctionne Bien

**Gitea auto-hébergé** :
- Très rapide et stable
- Proxmox Helper Scripts = installation en 5 minutes
- Ansible gère les mises à jour proprement
- Grafana surveille tout

**Wireguard + Nginx Proxy Manager** :
- Exposition sécurisée du homelab
- Performances excellentes
- Configuration simple

**Labs Scaleway** :
- Provisionnement en 3 minutes
- Flexibilité totale (taille, durée)
- Coûts prévisibles (facturation à l'heure)

**CI/CD Hugo → Scaleway Object Storage** :
- Push to deploy en 2 minutes
- Gratuit (quelques centimes/mois pour le stockage)
- CDN intégré = site ultra rapide

### Les Défis

**Complexité initiale** :
- Wireguard + reverse proxy = courbe d'apprentissage
- Première configuration Proxmox/LXC = quelques heures

**Maintenance** :
- Responsabilité des mises à jour (heureusement Ansible aide !)
- Monitoring à configurer soi-même
- Sauvegardes à automatiser

**Dépendances** :
- Si la Dedibox tombe, Gitea n'est plus accessible
- Solution : Failover avec une 2e Dedibox ou VPS (à venir)

## Prochaines Étapes

- **Haute disponibilité** : Seconde Dedibox pour du failover
- **Backup automatique** : Scripts pour sauvegarder Gitea vers Scaleway Object Storage
- **Plus d'automation** : Terraform pour provisionner toute l'infra Scaleway
- **MCP Arista** : Développer un serveur MCP pour interagir avec les équipements réseau via LLM Locaux
- **Intégration Netbox** : Webhook depuis Netbox vers pipeline de validation réseau

## Conclusion

Cette infrastructure hybride (homelab Proxmox + cloud Scaleway) offre le meilleur des deux mondes :

- **Contrôle** : Données sensibles (code, configurations) dans le homelab
- **Flexibilité** : Ressources cloud pour les besoins ponctuels
- **Apprentissage** : Environnement complet pour expérimenter
- **Souveraineté** : Tout hébergé en France, chez des acteurs européens

Le self-hosting n'est pas qu'une question de coûts (spoiler : je paie autant qu'avant, voire plus), mais d'apprentissage, de maîtrise et de compréhension profonde des systèmes.

Pour un ingénieur réseau ou DevOps, c'est l'environnement idéal pour reproduire des cas d'usage professionnels et monter en compétences.

## Ressources

### Documentation
- [Gitea](https://docs.gitea.io/)
- [Proxmox Helper Scripts](https://community-scripts.github.io/ProxmoxVE/)
- [Scaleway CLI](https://www.scaleway.com/en/cli/)
- [ContainerLab](https://containerlab.dev/)
- [Nginx Proxy Manager](https://nginxproxymanager.com/)

### Mes Repos
- [Blog Hugo](https://gitea.arnodo.fr/Damien/blog)
- [Network Labs](https://gitea.arnodo.fr/Damien/arista-evpn-vxlan-clab) (topologies ContainerLab)
- [Scaleway Scripts](https://gitea.arnodo.fr/Damien/scaleway-automation)

### Communauté
- [Proxmox Forum](https://forum.proxmox.com/)
- [r/homelab](https://reddit.com/r/homelab)
- [ContainerLab Slack](https://containerlab.dev/)