Applications conteneurisées

JelinaOS intègre un moteur de conteneurs Docker complet, mais applique un principe commun au déploiement : utiliser les Releases plutôt que démarrer manuellement les conteneurs sur l’équipement. En production, il est recommandé de gérer tous les conteneurs par ce processus pour maîtriser définition, déploiement, surveillance, mise à jour et retour arrière.

Procédure recommandée

Construire et pousser l’image → Déclarer l’application conteneurisée dans la Release → Déployer sur l’équipement → L’agent récupère et exécute

Étape 1 : préparer l’image

Construisez l’application sous forme d’image de conteneur et envoyez-la vers un registre privé d’entreprise ou public :

docker build -t registry.example.com/myapp:1.0.0 .
docker push registry.example.com/myapp:1.0.0

Étape 2 : déclarer l’application dans la Release

Dans JelinaCloud, créez une Release et ajoutez l’application conteneurisée :

• Indiquez l’adresse de l’image et son étiquette de version ; utilisez une version explicite pour éviter une mise à niveau imprévue ;
• Configurez les variables d’environnement, les mappages de ports et les volumes ;
• Définissez la stratégie de redémarrage, de préférence always, et les limites de ressources.

Étape 3 : déployer

Déployez la Release sur la flotte ou l’équipement cible. L’agent effectue automatiquement les opérations suivantes :

• Téléchargement de l’image et création du conteneur ;
• Injection des variables, mappage des ports et montage des volumes selon la configuration ;
• Démarrage et surveillance continue, avec reprise après sortie anormale ou redémarrage de l’équipement.

Persistance des données

Le système de fichiers d’un conteneur est perdu lors de sa recréation. Montez les données à conserver sur la partition de données :

• Déclarez un volume dans la Release ou montez un répertoire de la partition de données de l’équipement ;
• Les données restent indépendantes du cycle de vie du conteneur et sont conservées lors des mises à niveau et recréations.

Observation et diagnostic

Sur l’équipement, les commandes Docker servent à l’observation et au diagnostic, pas à la gestion du déploiement :

docker ps                     # Afficher l’état des conteneurs
docker logs <nom-conteneur>           # Afficher les journaux du conteneur
docker events                 # Suivre les événements du conteneur pour diagnostiquer

Bonnes pratiques en production

• Version fixe : utilisez une étiquette de version explicite dans la Release ;
• Contrôle de santé : configurez les contrôles de santé et les stratégies de redémarrage pour la récupération automatique ;
• Limites de ressources : plafonnez mémoire et processeur pour éviter de perturber l’ensemble de l’équipement ;
• Registre privé : en entreprise, utilisez un registre privé, avec distribution centralisée par l’agent ;
• Mise à niveau et retour arrière : publiez une nouvelle Release pour mettre à niveau et réaffectez l’ancienne pour revenir en arrière, le tout orchestré dans le cloud.

Questions fréquentes

Peut-on déployer directement avec docker run sur l’équipement ? C’est techniquement possible, mais déconseillé : l’application reste hors du système de Releases et ne bénéficie pas d’une surveillance, de mises à jour et de retours arrière unifiés. En production, déployez par Release.

Que se passe-t-il si le conteneur s’arrête anormalement ? Si la Release configure restart: always, l’agent redémarre automatiquement l’application.

Documentation associée

• Gestion des applications — Vue d’ensemble des Releases
• Orchestration des conteneurs avec Compose — Assemblage d’applications multiconteneurs
• Déploiement cloud et OTA — Publication et mise à jour