Carnet DevOps prod

Cette page montre, en direct, ce que la plateforme du VPS fait pour une application. Chaque bloc correspond à une notion ; en bas, la commande pour la vérifier vous-même sur le serveur.

État en direct

Version déployée

Commit: 7545b3f4a564
Conteneur: 58670c06e180
APP_ENV: production
PHP / Laravel: 8.4.26 / 13.34.0

HTTPS et proxy

Hôte: skills-devops.visibilitycam.com
HTTPS: oui
Votre IP: 216.73.217.165

Base de données

connectée pgsql

Visites enregistrées : 10
Ce compteur survit aux déploiements : les données sont dans un volume.

Cache (Redis)

opérationnel redis

Worker (file d'attente)

aucun job traité

Scheduler

actif
dernier passage il y a 28 s

Ce qu'il faut retenir (et comment le vérifier)

1. Un sous-domaine sans rien créer dans le DNS

La zone DNS (chez Contabo) contient *.visibilitycam.com → IP du VPS. Tout nom à un niveau arrive donc sur le serveur. Cette app n'a eu besoin que d'un nom libre, déclaré dans son .env (APP_PUBLIC_HOST).

dig +short skills-devops.visibilitycam.com                         # → l'IP du VPS
/app/vps-platform/bin/vps-hosts.sh --free autre-nom.visibilitycam.com

2. nginx-proxy envoie la visite au bon conteneur

Le conteneur app déclare VIRTUAL_HOST : nginx-proxy le voit et route ce nom vers lui. Aucun port ouvert sur le serveur.

docker inspect skills-devops-prod-app-1 --format '{{range .Config.Env}}{{println .}}{{end}}' | grep VIRTUAL_HOST

3. HTTPS automatique (Let's Encrypt)

acme-companion lit LETSENCRYPT_HOST et obtient le certificat en 1 à 2 minutes, puis le renouvelle seul.

docker logs nginx-proxy-acme 2>&1 | grep skills-devops.visibilitycam.com | tail -5

4. Staging automatique, production par promotion de la même image

deploy.sh construit une image par commit. Le staging la reçoit automatiquement ; la production reçoit exactement la même, quand vous le décidez. Le commit affiché ci-dessus doit être identique en staging et en prod après une promotion.

cd /app/skills-devops/staging && /app/vps-platform/bin/deploy.sh watch
cd /app/skills-devops/prod && /app/vps-platform/bin/deploy.sh promote
/app/vps-platform/bin/deploy.sh status

5. Migrations avant la bascule, retour arrière automatique

Si une migration échoue, rien n'est basculé. Si la nouvelle version ne répond pas sur /up, l'ancienne revient seule. Retour arrière manuel :

cd /app/skills-devops/prod && /app/vps-platform/bin/deploy.sh rollback prod
tail -20 /var/lib/vps-platform/skills-devops/deploy.log

6. Sauvegardes chiffrées

Une sauvegarde est prise avant chaque mise en production, et chaque nuit. Le compteur de visites ci-dessus est dedans.

docker run --rm -v skills-devops-prod_backups:/b busybox ls -lh /b

7. Un processus par conteneur, relancé par Docker

app (web), worker (file d'attente), scheduler (tâches planifiées), db, redis : si l'un s'arrête, Docker le relance. Essayez avec le worker, puis renvoyez un job :

docker restart skills-devops-prod-worker-1
docker ps --filter label=com.docker.compose.project=skills-devops-prod

8. Journaux centralisés

Les conteneurs portent le label observability.enable=true : leurs journaux arrivent dans Grafana (app=skills-devops), sans rien configurer d'autre.

docker logs skills-devops-prod-app-1 --tail 20