Maintenance

Logs

ssh ansible@10.1.21.13
sudo -u tamagotchi bash -c 'cd /opt/tamagotchi/app && docker compose --env-file .env.prod -f docker-compose.prod.yml logs -f backend'   # ou celery, edge, postgres, redis

État des conteneurs

sudo -u tamagotchi bash -c 'cd /opt/tamagotchi/app && docker compose --env-file .env.prod -f docker-compose.prod.yml ps'

Backups Postgres

• Un timer systemd (tamagotchi-backup.timer, installé par Ansible) lance un dump quotidien : sudo systemctl list-timers | grep tamagotchi.
• Les dumps compressés vivent dans /opt/tamagotchi/backups/, rétention 7 jours (réglable via backup_retention_days dans ansible/group_vars/prod/vars.yml).
• Restaurer un dump :

  sudo -u tamagotchi bash -c '
    cd /opt/tamagotchi/app
    gunzip -c /opt/tamagotchi/backups/tamagotchi-AAAA-MM-JJ.sql.gz | \
      docker compose --env-file .env.prod -f docker-compose.prod.yml exec -T postgres psql -U tamagotchi tamagotchi
  '
  

  Attention : ça restaure par-dessus la base actuelle (les données existantes ne sont pas automatiquement vidées avant — pour une restauration propre, vider les tables ou repartir d'un volume Postgres vide).

Les backups restent uniquement sur le serveur lui-même pour l'instant (pas de copie hors-site) — à prévoir si la donnée devient critique.

Secrets (SECRET_KEY, REFRESH_SECRET_KEY, mot de passe Postgres)

Gérés via ansible-vault (ansible/group_vars/prod/vault.yml), jamais en clair dans le dépôt.

cd ansible
ansible-vault edit group_vars/prod/vault.yml --vault-password-file ~/.secrets/tamagotchi_ansible_vault_pass.txt
ansible-playbook -i inventory.ini playbook.yml --vault-password-file ~/.secrets/tamagotchi_ansible_vault_pass.txt

Rejouer le playbook régénère .env.prod sur le serveur avec les nouvelles valeurs, mais ne redémarre pas automatiquement les conteneurs — il faut un docker compose up -d (ou un push qui déclenche un déploiement) après coup pour qu'ils relisent les nouvelles variables.

Rotation d'une clé SSH de déploiement (ansible/files/deploy_key ou repo_read_key) : régénérer la paire (ssh-keygen), mettre à jour la clé publique référencée par le playbook (ou l'entrée Deploy Key Forgejo), rejouer le playbook, puis mettre à jour le secret Forgejo Actions DEPLOY_SSH_KEY si c'est la clé de déploiement CI qui a changé.

Mémoire (contrainte importante)

Le serveur n'a que 1.5 Go de RAM. Le design est volontairement frugal :

• celery fait tourner worker + beat dans un seul process (--beat) plutôt que deux conteneurs séparés.
• Redis est plafonné à 128 Mo (--maxmemory 128mb --maxmemory-policy allkeys-lru).
• 2 workers uvicorn seulement pour le backend.

Si l'usage augmente et que la RAM devient limitante : free -h sur le serveur pour surveiller, envisager de séparer worker/beat en deux conteneurs (nécessaire si on veut plusieurs workers Celery en parallèle un jour), ou upgrader le serveur.

node_exporter tourne déjà sur le serveur (port 9100) — un futur scrape Prometheus permettrait un suivi mémoire/CPU dans le temps sans action supplémentaire côté serveur.

Pistes d'évolution (pas fait, pas urgent)

• Registre d'images Docker (Forgejo Packages ou autre) pour ne plus builder sur le serveur de prod — voir Mise à jour.
• Backups Postgres hors-site.
• Séparer Celery worker et beat si la charge augmente.
• Rare/Légendaire côté boutique + système de quête pour les distribuer (côté applicatif, sans lien avec l'infra).