Déployer votre application (Docker Rootless)

Ce guide vous accompagne pas à pas : prérequis d’accès, connexion à votre environnement, adaptation du modèle fourni, déploiement, puis vérification de conformité.

Astuce

En résumé : copiez le Golden Template, adaptez-le à votre application, déployez avec docker compose up -d, puis vérifiez avec check-compliance.sh.

Introduction 

L’offre Docker Managé Rootless vous permet de déployer et gérer vos applications via Docker Compose en toute autonomie, dans un environnement sécurisé et isolé.

Contrairement à un hébergement géré classique où chaque modification nécessite une intervention d’Alfa-Safety, cette offre vous donne la main sur votre stack applicative, vous déployez quand vous voulez, sans ouvrir de ticket.

Votre VM vous est dédiée. Sur cette VM, chaque utilisateur dispose de son propre daemon Docker isolé, vos conteneurs sont complètement séparés des autres utilisateurs de votre VM. Un incident sur un utilisateur ne peut pas impacter les autres.

Pour vous accompagner et assurer la qualité de vos déploiements, vous disposez de :

Un Golden Template : un modèle de référence Docker Compose commenté qui vous guide dans la structure de vos déploiements
Un script de validation : pour vérifier que votre déploiement respecte bien les règles de l’offre avant mise en ligne
Des notifications de conformité : si vous choisissez de les activer, vous recevez un email vous informant de l’état de conformité de vos déploiements

Alfa-Safety reste responsable de l’infrastructure, de la sécurité globale et du monitoring en temps réel.

Gestion des utilisateurs et des droits 

Votre environnement Docker Rootless est associé à un utilisateur Linux dédié sur la VM, créé et configuré par Alfa-Safety.

Dans vos conteneurs, vous pouvez exécuter des processus en tant que root, c’est nécessaire pour certaines applications. Ce root est un root fictif, limité à votre conteneur. Sur la VM, ces processus s’exécutent sous votre utilisateur Linux dédié, sans aucun privilège root sur le système.

En d’autres termes :

root dans votre conteneur → autorisé
root sur la VM → impossible

Prérequis : accès SSH 

Vous devez disposer d’une paire de clés SSH et nous avoir transmis votre clé publique, que nous déploierons sur notre bastion afin de vous donner accès à votre environnement.

Si vous n’avez pas encore de clé SSH, consultez la section Utilisation de clés SSH de ce wiki (pourquoi les utiliser, comment les créer, comment vous en servir pour vous connecter).

1. Se connecter à votre environnement 

Une fois votre clé déployée de notre côté :

ssh -i <chemin-vers-votre-clé-privée> -p 2222 <votre-identifiant>@bastion-ssh.fr-01.cloud.alfa-safety.net

Avertissement

Si vous avez plusieurs clés SSH sur votre poste, précisez toujours l’option -i <chemin_de_votre_clé>, le bastion ne prend en compte que la première clé envoyée par défaut.

Dès la connexion, un message d’accueil vous rappelle l’emplacement de votre modèle de référence et la commande de vérification, vous pouvez vous y référer à tout moment.

2. Votre modèle de référence (Golden Template)

Un fichier docker-compose-golden-template.yml est déjà présent dans votre dossier personnel, un exemple fonctionnel qui respecte déjà toutes les règles attendues.

ls ~
less ~/docker-compose-golden-template.yml

Créez un dossier dédié à votre application, puis copiez-y le modèle pour créer votre propre fichier :

mkdir -p ~/mon-application
cp ~/docker-compose-golden-template.yml ~/mon-application/compose.yml
nano ~/mon-application/compose.yml

Si vous hébergez plusieurs applications, chacune doit avoir son propre dossier dédié :

/home/<votre-utilisateur>/application-1/compose.yml
/home/<votre-utilisateur>/application-2/compose.yml

3. Les règles à respecter 

Votre fichier doit respecter les règles suivantes. Chacune répond à un besoin concret, les respecter garantit la fiabilité de votre application et évite d’impacter les autres applications hébergées sur le même serveur.

Vue d’ensemble 

Règle	Niveau	Résumé
Pas de volumes nommés	Bloquant	Utiliser uniquement des bind mounts
Healthcheck	Recommandé	Un healthcheck par service
Labels Traefik	Bloquant si exposé	Obligatoires si accessible depuis Internet
Politique de redémarrage	Recommandé	`restart: unless-stopped`
Limites de ressources	Recommandé	CPU et RAM définis
Tag d’image précis	Recommandé	Jamais `:latest`

Pas de volumes Docker nommés 

Utilisez uniquement des dossiers locaux montés directement (bind mounts), jamais un volume Docker nommé.

# À éviter
volumes:
  - mon_volume:/var/lib/mysql

# Utilisez un chemin relatif vers un dossier local
volumes:
  - ./data/mysql:/var/lib/mysql

Pourquoi : un volume nommé est géré en interne par Docker, à un emplacement peu visible, il devient difficile à localiser, sauvegarder, ou migrer vers un autre serveur. Un dossier local reste toujours visible et accessible directement.

Un healthcheck par service 

healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost"]
  interval: 10s
  timeout: 5s
  retries: 3
  start_period: 10s

Pourquoi : sans lui, Docker considère votre conteneur comme fonctionnel tant que son processus tourne, même si votre application a planté ou ne répond plus. Le healthcheck permet une vraie détection de l’état de santé.

Labels Traefik complets (si votre application doit être accessible depuis Internet)

labels:
  - "traefik.enable=true"                                          # active le routage Traefik pour ce service
  - "traefik.http.routers.mon-app.rule=Host(`mon-domaine.com`)"     # nom de domaine par lequel votre application sera accessible
  - "traefik.http.services.mon-app.loadbalancer.server.port=8080"   # port exposé (PublicPort) du conteneur — obligatoire, sinon Bad Gateway

Pourquoi : sans ces labels, votre conteneur reste invisible pour le système de routage, votre application resterait inaccessible depuis l’extérieur, malgré un déploiement réussi.

Une politique de redémarrage 

restart: unless-stopped

Pourquoi : garantit que votre application redémarre automatiquement en cas de crash inattendu, sans intervention manuelle de votre part.

Des limites de ressources 

deploy:
  resources:
    limits:
      cpus: '1.0'
      memory: 512M

Pourquoi : évite qu’un service mal configuré ne consomme l’intégralité des ressources du serveur, ce qui impacterait toutes les autres applications hébergées sur la même machine, pas seulement la vôtre.

Un tag d’image précis 

# À éviter
image: nginx:latest

# Priécisez le tag
image: nginx:1.27.1

Pourquoi : le tag :latest ne garantit aucune reproductibilité, le contenu réel de l’image peut changer sans que vous le sachiez, et il devient impossible de revenir à une version précédente en cas de problème.

4. Déployer votre application 

Une fois votre fichier prêt :

docker compose up -d

Votre application démarre normalement, aucun contrôle automatique ne bloque le déploiement à ce stade.

5. Vérifier la conformité de votre déploiement 

Deux façons de vérifier que votre configuration respecte les règles ci-dessus.

Validation manuelle, à votre initiative 

Après chaque déploiement ou modification, lancez :

check-compliance.sh

Cette commande analyse votre configuration réellement déployée (pas seulement votre fichier source) et affiche un rapport détaillé :

INFO : la règle est respectée
WARNING : un point à corriger, recommandé mais non bloquant
ERROR : un point à corriger, qui compromet le fonctionnement de votre application

Exemple de rapport avec un point à corriger :

WARNING - Service "mon-app" : healthcheck absent
         → Ajouter :
           healthcheck:
             test: ["CMD", "curl", "-f", "http://localhost"]
             interval: 10s
             timeout: 5s
             retries: 3
             start_period: 10s

Avertissement

Cette vérification n’est pas automatique, pensez à la lancer après chaque modification de votre configuration ou chaque redéploiement.

Validation hebdomadaire automatique (optionnel)

Si vous le souhaitez, nous pouvons activer une vérification automatique de votre configuration, chaque lundi. En cas de non-conformité détectée, vous recevez un email à l’adresse que vous nous aurez communiquée, uniquement lorsque votre statut change (vous ne recevrez pas de rappel chaque semaine si tout reste conforme).

Pour activer cette option, transmettez-nous l’adresse email à laquelle vous souhaitez recevoir ces notifications.

Besoin d’aide ?

Si un point du rapport n’est pas clair, ou si vous rencontrez une difficulté, contactez nous.