Docs / Concepts de base / Apps et services

Apps et services

Les apps sont les unités déployables au sein d'une stack. Chaque app s'exécute comme un ou plusieurs services (conteneurs). Comprendre cette relation est essentiel pour gérer efficacement vos déploiements.

Apps vs services

Dans sh0, la distinction entre une app et un service est importante :

App

Une app est une configuration -- elle définit quoi déployer, depuis quelle source (Git, image, template), avec quels paramètres (variables d'env, domaines, limites de ressources). Une app est une entité persistante qui survit aux déploiements.

Service

Un service est une instance en cours d'exécution -- le conteneur Docker réel créé à partir d'un déploiement. Les services sont éphémères. Chaque déploiement crée un nouveau service et (après la réussite des vérifications de santé) supprime l'ancien.

Pensez à une app comme le plan et à un service comme le bâtiment construit. Quand vous redéployez une app, sh0 crée un nouveau service à partir du plan mis à jour, vérifie qu'il fonctionne, puis démonte l'ancien service.

Diagram showing an App box containing configuration (Git URL, env vars, domain), with arrows pointing to Service v1 (old, being removed) and Service v2 (new, running)

Apps persist across deployments; services are recreated each time

Cycle de vie de l'app

Une app passe par plusieurs états au cours de son cycle de vie, de la création au déploiement actif :

États du cycle de vie

État	Badge	Description
Créée	Gray	L'app est configurée mais n'a jamais été déployée.
En construction	Blue	Le code source est en cours de clonage et l'image du conteneur est en cours de construction.
En déploiement	Yellow	Le conteneur démarre et les vérifications de santé sont en cours.
En cours d'exécution	Green	L'app est en ligne et sert le trafic. Les vérifications de santé réussissent.
Arrêtée	Gray	L'app a été arrêtée manuellement. Le conteneur ne tourne pas.
Échoué	Red	Le build ou le déploiement a échoué. La version précédente continue de tourner si disponible.

App list showing apps in different states: 'frontend' with a green Running badge, 'worker' with a yellow Deploying badge, and 'migration-job' with a gray Stopped badge

Apps display their current lifecycle state

Déploiements sans interruption

Lorsqu'une app est dans l'état En cours d'exécution et que vous déclenchez un nouveau déploiement, sh0 utilise une stratégie blue-green. L'ancien service continue de gérer le trafic pendant que le nouveau se construit et démarre. Le trafic ne bascule qu'après que le nouveau service a réussi sa vérification de santé. Si le nouveau service échoue, l'ancien reste actif.

Créer une app

Les apps sont créées à l'intérieur d'une stack. Naviguez vers une stack et cliquez sur Add App. Vous pouvez créer des apps depuis trois sources :

Dépôt Git -- Fournissez une URL, et sh0 clone, détecte la stack, construit et déploie automatiquement.
Image Docker -- Télécharger et exécuter une image existante depuis Docker Hub, GitHub Container Registry ou tout registre privé.
Template -- Choisissez parmi plus de 170 templates préconfigurés pour les applications populaires.

Add App dialog showing three source options as cards: Git Repository with a branch icon, Docker Image with a container icon, and Template with a grid icon

Choose your app source

Paramètres de l'app

Chaque app dispose d'un panneau de paramètres complet organisé en plusieurs catégories.

Paramètres généraux

Nom -- L'identifiant de l'app au sein de la stack. Aussi utilisé comme nom de conteneur Docker et hostname interne.
Port -- Le port sur lequel votre application écoute à l'intérieur du conteneur. sh0 route le trafic externe vers ce port.
Source -- L'URL Git, l'image Docker ou la configuration du template.
Branche -- Pour les apps basées sur Git, la branche à suivre et depuis laquelle déployer.
Déploiement automatique -- Lorsqu'activé, les pushes vers la branche suivie déclenchent des déploiements automatiques.

Paramètres de build

Commande de build -- Remplacer la commande de build par défaut (ex. : npm run build).
Commande de démarrage -- Remplacer la commande de démarrage par défaut (ex. : node server.js).
Chemin du Dockerfile -- Utiliser un Dockerfile personnalisé au lieu de celui auto-généré par sh0.
Arguments de build -- Passer des variables de build au processus de construction Docker.

App settings page showing the Build Settings section with fields for Build Command, Start Command, Dockerfile Path, and Build Arguments

Customizing build and start commands

Limites de ressources

Vous pouvez définir des limites CPU et mémoire sur chaque app pour empêcher une seule application de consommer toutes les ressources du serveur :

Paramètre	Défaut	Description
Limite CPU	Pas de limite	Maximum de cœurs CPU que le conteneur peut utiliser (ex. : 0.5, 1, 2)
Limite mémoire	Pas de limite	Maximum de RAM (ex. : 256m, 512m, 1g). Le conteneur est tué si dépassé.
Réservation mémoire	Pas de limite	Limite souple. Docker essaie de maintenir le conteneur près de cette valeur.

Setting Limits via API

curl -X PUT http://localhost:9000/api/apps/APP_ID \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"cpu_limit": 1.0, "memory_limit": "512m"}'

Dépassement de mémoire

Quand un conteneur dépasse sa limite de mémoire, Docker le tue immédiatement (OOMKilled). Si votre app atteint fréquemment la limite, augmentez l'allocation ou investiguez les fuites de mémoire. Consultez la section Surveillance pour les graphiques d'utilisation mémoire.

Politiques de redémarrage

Les politiques de redémarrage déterminent ce qui se passe quand un conteneur s'arrête ou plante :

Politique	Comportement
`always`	Toujours redémarrer le conteneur, quel que soit le code de sortie. Par défaut pour les apps.
`on-failure`	Redémarrer uniquement si le conteneur sort avec un code de sortie non nul.
`unless-stopped`	Redémarrer sauf si explicitement arrêté par l'utilisateur.
`no`	Ne jamais redémarrer. Utile pour les tâches ponctuelles comme les migrations.

Tip

Pour les services de longue durée (serveurs web, API), utilisez always. Pour les tâches ponctuelles (migrations de base de données, scripts de seed), utilisez no pour que le conteneur s'arrête après la fin de la tâche.

Vérifications de santé

Les vérifications de santé vérifient que votre app fonctionne correctement après le déploiement. sh0 supporte deux types :

Vérification de santé HTTP -- sh0 envoie une requête HTTP GET à un chemin spécifié (défaut : /) et attend une réponse 2xx.
Vérification de santé TCP -- sh0 vérifie que le conteneur écoute sur le port configuré. Utilisé pour les services non-HTTP.

Health Check Configuration

{"health_check": {"type": "http", "path": "/health", "interval": 10, "timeout": 5, "retries": 3, "start_period": 30}}

App health check settings showing type selector (HTTP/TCP), path field, interval, timeout, retries, and start period fields with sensible defaults

Configuring health checks for your app

Note

Pendant le déploiement, sh0 attend que la vérification de santé réussisse avant de router le trafic vers le nouveau conteneur. Si la vérification de santé échoue après les tentatives configurées, le déploiement est marqué comme échoué et la version précédente continue de servir le trafic.

Stacks

Domains & SSL