Scripts de déploiement Docker pour petits services

Pourquoi cette note existe

Exécuter un service avec Docker est simple la première fois.

Le maintenir devient agaçant lorsque chaque mise à jour nécessite de se souvenir de la commande build exacte, nom du conteneur, fichier d'environnement, mode réseau, politique de redémarrage, commande logs et étapes de nettoyage.

Cette note documente l'orientation pratique de la création de petits scripts d'aide autour des services Docker.

Le but n'est pas de cacher complètement Docker. L'objectif est de rendre les opérations communes répétables de sorte que le déploiement devient moins sujet aux erreurs.

Contexte

Ce type de script est utile pour les petits services tels que:

Boots
API légères
outils internes
des services autogérés
petits travailleurs de l'automatisation
utilitaires personnels
services déployés sur un VPS ou un périphérique compatible OpenWrt

Le service peut être simple, mais les étapes opérationnelles sont toujours importantes.

Un mauvais processus de mise à jour peut créer des problèmes comme :

vieux conteneurs toujours en cours d'exécution
nouvelle image construite mais non utilisée
variables d'environnement manquantes
mauvais nom du conteneur
contenants en double
journaux difficiles à trouver
Aucun chemin de redémarrage propre
commandes oubliées de nettoyage

Les scripts d'aide réduisent cette friction.

Ce que cette configuration veut prouver

le déploiement doit être répétable, non basé sur la mémoire
les petits services ont encore besoin de démarrage, d'arrêt, de redémarrage, de registres et de flux de nettoyage
scripts peuvent réduire les erreurs sans introduire une plate-forme CI/CD complète
les fichiers environnementaux doivent être traités de manière cohérente
Les commandes Docker ne doivent être enveloppées que lorsqu'elles améliorent la fiabilité
Les mises à jour de service devraient être faciles à tester et à retourner mentalement
de bons outils locaux même pour les petits projets personnels ou indépendants

Outils et domaines utilisés

Calque Docker

Dockerfile
Construction de l'image Docker
fonctionnement du conteneur
arrêt/suppression du récipient
politique de redémarrage
chargement du fichier environnement
journaux
État du conteneur
nettoyage de l'image

Calque Script

scripts shell
commande d'aide
traitement des arguments
État du produit
écoulement d'arrêt/de redémarrage sûr
nommage cohérent
Actions de déploiement d'un commandement

Couche de service

petit service Node.js
bot ou processus ouvrier
variables environnementales
configuration persistante
journaux et sortie d'erreur
vérification du service après redémarrage

Construction prévue

Le résultat prévu est un petit script d'aide au déploiement ou un dossier de script qui fournit des opérations de service commun.

Une configuration terminée devrait permettre :

construire l'image
exécuter le service
arrêter le service
redémarrer le service
afficher les journaux
afficher l' état
nettoyer les vieux contenants/images le cas échéant
imprimer l'aide
éviter de taper de longues commandes Docker manuellement
continuer à nommer les mises à jour de façon cohérente

L'aide devrait faciliter l'entretien du service sans devenir un cadre de déploiement important.

Commandes de script recommandées

Un script pratique devrait supporter des commandes comme:

help
build
run
stop
restart
logs
status
clean
rebuild

Les noms exacts des commandes peuvent changer, mais le but doit rester clair.

Exemple de forme de projet

Un simple dossier de service peut ressembler à ceci :

service-name/
  Dockerfile
  package.json
  src/
  .env.local
  .env.example
  scripts/
    service.sh

Ou, pour un projet plus petit:

service-name/
  Dockerfile
  .env.local
  deploy.sh

La partie importante est que le script vit près du service et documente le flux de travail prévu.

Gestion des fichiers d'environnement

Un script helper devrait utiliser un fichier d'environnement prévisible.

Exemple :

.env.local

Le script doit vérifier qu'il existe avant d'exécuter le conteneur.

Exemple de comportement :

if .env.local is missing:
  print a clear error
  stop before running the service

C'est mieux que de démarrer un conteneur cassé qui sort immédiatement parce que le jeton, la clé API ou la valeur de configuration est manquante.

Désignation des conteneurs

Le script devrait définir un nom de conteneur clair.

Exemple :

CONTAINER_NAME="service-name"
IMAGE_NAME="service-name:latest"

Cela évite les noms générés au hasard par Docker et rend les commandes logs/status/restart prévisibles.

Sans noms cohérents, la maintenance devient plus difficile.

Construisez la commande

La commande build devrait créer ou mettre à jour l'image Docker.

Exemple de direction:

docker build -t service-name:latest .

Un script d'aide devrait imprimer ce qu'il fait:

[+] Building service-name:latest

Cela facilite la lecture des scripts.

Exécuter la commande

La commande d'exécution doit démarrer un nouveau conteneur avec la configuration correcte.

Options communes:

--name
--env-file
--restart unless-stopped
--network
-d

Dans le cas d'un petit robot ou d'un travailleur à l'étranger, les ports publics peuvent ne pas être nécessaires.

Exemple de direction:

docker run -d --name service-name --env-file .env.local --restart unless-stopped service-name:latest

Si le service nécessite un réseau hôte, le script devrait le rendre explicite.

Commande d'arrêt

La commande stop doit s'arrêter et enlever le conteneur en cours d'exécution proprement.

Exemple de direction:

docker stop service-name
docker rm service-name

Le script ne doit pas échouer bruyamment si le conteneur n'existe pas. Il peut imprimer un message clair à la place.

Redémarrer la commande

La commande de redémarrage doit être prévisible.

Deux significations communes existent:

Redémarrer le conteneur existant

docker restart service-name

C'est rapide, mais il ne reconstruit pas ou n'utilise pas de nouveau code.

Recréer le conteneur à partir de l'image actuelle

stop → run

Ceci est utile après la reconstruction de l'image.

Le script devrait clarifier le comportement.

Pour les mises à jour de code, le flux plus sûr est généralement:

build → stop → run → logs/status

Reconstruire la commande

Une commande utile est :

rebuild

Signification:

build image
stop old container
run new container
show logs/status

C'est la commande utilisée après avoir changé de code.

Il évite l'erreur courante de construire une image mais oublie de recréer le conteneur.

Commande des journaux

Les journaux devraient être facilement accessibles.

Exemple de direction:

docker logs -f service-name

Une commande helper comme celle-ci est utile :

./deploy.sh logs

Les journaux sont le premier endroit à vérifier après un redémarrage.

Commande d'état

L'état doit indiquer si le conteneur fonctionne.

Exemple de direction:

docker ps -a --filter name=service-name

Un bon script peut aussi montrer:

Nom du conteneur
Nom de l'image
État de fonctionnement/sortie
redémarrer le nombre si disponible
journaux récents si utile

Commande propre

Le nettoyage devrait être prudent.

Une commande propre peut supprimer les anciens conteneurs arrêtés ou les images inutilisées, mais elle ne devrait pas supprimer les ressources Docker non liées sans avertissement.

Bon comportement de nettoyage:

enlever ce service
supprimer ce service l'ancienne image si prévu
éviter le nettoyage destructif mondial par défaut

Évitez de faire tourner clean quelque chose de dangereux comme:

docker system prune -a

à moins que le script ne demande clairement une confirmation.

Exemple Script Direction

Il s'agit d'un exemple simplifié:

#!/bin/sh

APP_NAME="service-name"
IMAGE_NAME="$APP_NAME:latest"
CONTAINER_NAME="$APP_NAME"
ENV_FILE=".env.local"

case "$1" in
  build)
    docker build -t "$IMAGE_NAME" .
    ;;

  run)
    if [ ! -f "$ENV_FILE" ]; then
      echo "Missing $ENV_FILE"
      exit 1
    fi

    docker run -d       --name "$CONTAINER_NAME"       --env-file "$ENV_FILE"       --restart unless-stopped       "$IMAGE_NAME"
    ;;

  stop)
    docker stop "$CONTAINER_NAME" 2>/dev/null || true
    docker rm "$CONTAINER_NAME" 2>/dev/null || true
    ;;

  restart)
    "$0" stop
    "$0" run
    ;;

  rebuild)
    "$0" build
    "$0" stop
    "$0" run
    "$0" logs
    ;;

  logs)
    docker logs -f "$CONTAINER_NAME"
    ;;

  status)
    docker ps -a --filter "name=$CONTAINER_NAME"
    ;;

  help|*)
    echo "Usage: $0 {build|run|stop|restart|rebuild|logs|status|help}"
    ;;
esac

Ceci n'est pas censé être universel, c'est un modèle de départ qui devrait être adapté à chaque service.

Décisions pratiques

Gardez les commandes petites et évidentes

Un script de déploiement devrait être ennuyeux.

Si le script devient trop intelligent, il devient une autre chose à déboguer.

Reconstruction différente du redémarrage

Le redémarrage d'un conteneur n'applique pas de nouveau code si l'image a été reconstruite, mais le conteneur n'a pas été recréé.

Une commande rebuild séparée rend cela plus clair.

Vérifier le fichier env avant d'exécuter

Échec tôt si la configuration requise est manquante.

Cela évite la sortie de conteneurs avec des erreurs peu claires.

Éviter le nettoyage global par défaut

Le nettoyage devrait cibler le service à moins que l'utilisateur ne demande explicitement un nettoyage complet Docker.

Ceci protège les autres contenants sur la même machine.

Imprimer des messages d'état lisibles

Quelques messages simples rendent la sortie du script beaucoup plus facile à comprendre.

Exemple :

[+] Building image
[+] Stopping old container
[+] Starting new container
[+] Showing logs

Garder une seule voie de déploiement principale

Évitez d'avoir plusieurs façons contradictoires pour exécuter le même service.

Si Docker est le chemin de déploiement, le script devrait être la manière normale de le gérer.

Points communs de défaillance

Image construite mais ancien code fonctionne toujours

Cause:

docker build was run, but the old container was not recreated

Correction :

build → stop → run

ou:

rebuild

Nom du conteneur existe déjà

Cause:

old stopped container still exists

Correction :

docker rm service-name

Une bonne commande stop devrait gérer cela.

Variables d'environnement manquantes

Symptômes:

sortie immédiate du service
Erreurs de jeton/API
config non défini
bot ne se connecte pas
Le serveur API échoue au démarrage

Correction :

vérifier .env.local
vérifier --env-file
vérifier les noms des variables
vérifier la configuration de l'application

Les journaux ne montrent rien d'utile

Causes:

app ne enregistre pas les erreurs de démarrage
sortie du processus avant l'enregistrement
logs vérifiés pour mauvais conteneur
Inadéquation du nom du conteneur
service redirige les journaux ailleurs

Correction :

utiliser des noms de contenants cohérents
log configuration du démarrage sans secrets
vérifier docker ps -a
vérifier docker logs

Problèmes d'architecture Docker

Sur les appareils ARM, l'architecture d'image compte.

Symptômes:

Erreur de format exec
sortie immédiate du conteneur
binaire ne peut pas courir

Fixez la direction & #160;:

construire pour l'architecture cible
utiliser des images de base qui supportent le périphérique
éviter de forcer la mauvaise plate-forme à moins d'imiter intentionnellement

Remplissage de stockage

Les images et les conteneurs Docker peuvent prendre de l'espace avec le temps.

Contrôles utiles:

docker images
docker ps -a
docker system df

Le nettoyage doit être fait avec soin.

Ce qu'une configuration terminée devrait montrer

Une configuration solide devrait montrer:

Dockerfile présent
.env.example documenté
.env.local utilisé localement mais non engagé
script helper avec sortie d'aide
build command fonctionne
Exécuter la commande fonctionne
le comportement de redémarrage/reconstruction est clair
La commande log fonctionne
La commande état fonctionne
La commande de nettoyage est sûre
README explique le flux normal
service survit au redémarrage si la politique de redémarrage est utilisée
aucune commande manuelle longue requise pour les actions communes

Preuves à retenir

Voici quelques éléments de preuve utiles à cette note :

fichier script
aide à la sortie
Dockerfile
.env.example
construire la sortie
Sortie docker ps
sortie des journaux
Reconstruction de la capture d'écran de flux
exemple de conteneur défaillant et correction
Section de déploiement README
notes sur l'architecture/plateforme en cours d'exécution sur ARM

Hypothèses techniques

Cette configuration suppose que le service est suffisamment petit pour fonctionner confortablement sur la machine cible.

Il suppose également que Docker est déjà installé et fonctionne.

Le script ne remplace pas la compréhension Docker. Il rend seulement les opérations répétées cohérentes.

Principaux risques

cacher trop de comportement Docker derrière un script
script supprimant des conteneurs ou des images non liés
fichier environnement accidentellement engagé
ancien conteneur utilisant un ancien code
Inadéquation du nom du conteneur
manquant de journaux
Pas de plan de renversement
inadéquation de l'architecture sur les appareils ARM
L'utilisation du disque augmente avec le temps
script devenant plus compliqué que le service

État actuel

La présente note représente le plan de maintenance du déploiement utilisé pour les petits services.

La valeur est de créer une simple boucle opérationnelle:

edit → build → stop old container → run new container → check logs

Cette boucle est suffisante pour de nombreux petits services sans avoir besoin d'un système complet d'IC/DC.

Ce que la présente note ne prétend pas

Cette note ne prétend pas que les scripts helper remplacent les plates-formes de déploiement appropriées.

Elle ne prétend pas que Docker soit requis pour chaque petit service.

Elle ne prétend pas qu'il s'agit d'un système d'orchestration de qualité de production.

C'est un modèle pratique pour maintenir les petits services Docker à jour.

À emporter pratique

Un script de déploiement Docker est utile lorsqu'il empêche les erreurs répétées.

Les parties utiles sont:

nom de l'image cohérent
nom du conteneur cohérent
fichier env prévisible
une commande pour reconstruire
des journaux faciles
écoulement d'arrêt/d'arrêt sûr
sortie d'aide claire
pas de magie inutile

Cela suffit pour rendre le déploiement de petits services beaucoup moins ennuyeux.