- Rename project name across code, configs, docs, dev/prod infra - Dev: DOCKER_APP_NAME + POSTGRES_DB switched to starseed, containers become php-starseed-fpm / nginx-starseed / starseed-db-1 - Dev: mount nginx.conf on default.conf instead of starseed.conf to avoid alphabetical-order clash with image's default site - Makefile: export CURRENT_UID/CURRENT_GID at top level so docker compose builds (db-reset etc.) get them - Prod: image registry path, container_name, volumes, vhost server_name + paths, DATABASE_URL, CORS, CI workflow - Add doc/prompt-rename-prod.md with the migration runbook for the prod server (DB rename, FS move, vhost, Let's Encrypt)
8.0 KiB
Prompt — Migration prod Coltura -> Starseed
Copier-coller integralement dans une session Claude lancee sur le serveur de prod apres que :
- le push develop + build CI ont publie l'image
gitea.malio.fr/malio-dev/starseed:latest, - le DNS
starseed.malio-dev.frresout vers ce serveur, - un certificat Let's Encrypt existe (ou est pret a etre genere) pour
starseed.malio-dev.fr.
Prompt a fournir au Claude prod
Tu es sur le serveur de production d'une app Symfony+Nuxt qui s'appelait Coltura et qui doit etre renommee en Starseed. Le rename cote code est deja fait et merge. Le repo Gitea s'appelle deja starseed. L'image gitea.malio.fr/malio-dev/starseed:latest est publiee.
Le DNS starseed.malio-dev.fr resout vers ce serveur. Le certificat Let's Encrypt pour ce nom de domaine est gere a la main par l'admin (a confirmer avant l'etape nginx).
Objectif : basculer la prod sur le nouveau nom (registry, container, DB, path FS, vhost) sans perdre les donnees et avec downtime minimal (mode maintenance pendant la migration).
Etat actuel a verifier en premier (donne-moi le retour de chaque commande avant de continuer) :
# 1. Container actuel + image
sudo docker ps --filter name=coltura-app --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'
# 2. DB existante
sudo -u postgres psql -c "\l" | grep -E "coltura|starseed"
# 3. Path FS app
ls -la /var/www/coltura/ 2>/dev/null | head -5
ls -la /var/www/starseed/ 2>/dev/null | head -5
# 4. Vhost nginx system
sudo ls -la /etc/nginx/sites-enabled/ | grep -E "coltura|starseed"
# 5. Cert Let's Encrypt
sudo ls /etc/letsencrypt/live/ | grep -E "coltura|starseed"
Apres confirmation de l'etat, executer dans cet ordre, en demandant validation utilisateur AVANT chaque etape destructive (DB drop, rm -rf, certificat) :
Etape 1 — Mode maintenance
cd /var/www/coltura
touch maintenance.on
# Verifier qu'une requete renvoie 503
curl -s -o /dev/null -w "HTTP %{http_code}\n" https://coltura.malio-dev.fr/
Doit renvoyer 503.
Etape 2 — Backup DB (CRITIQUE — ne pas skipper)
BACKUP_FILE="/root/coltura_prod_backup_$(date +%Y%m%d_%H%M%S).sql"
sudo -u postgres pg_dump -F c -f "$BACKUP_FILE" coltura_prod
ls -lh "$BACKUP_FILE"
Stocker ce chemin — il sera utilise pour le rollback.
Etape 3 — Creer la DB cible et migrer
Recuperer l'owner et le user de connexion actuels :
sudo -u postgres psql -c "\l coltura_prod"
grep DATABASE_URL /var/www/coltura/.env
Puis (adapter l'owner si different de malio) :
sudo -u postgres psql <<'SQL'
CREATE DATABASE starseed_prod OWNER malio;
SQL
sudo -u postgres pg_dump coltura_prod | sudo -u postgres psql starseed_prod
sudo -u postgres psql starseed_prod -c "\dt" | head -20
Verifier que les tables sont bien copiees. Si le user PG s'appelle coltura, le renommer ou en creer un starseed est OPTIONNEL — la connexion peut continuer avec coltura tant que GRANT est OK. Confirmer avec l'utilisateur s'il veut renommer le role PG :
# Optionnel : renommer le role PG (si user de connexion s'appelle 'coltura')
# sudo -u postgres psql -c "ALTER ROLE coltura RENAME TO starseed;"
Etape 4 — Renommer le path FS
sudo mv /var/www/coltura /var/www/starseed
# Verifier le contenu
sudo ls -la /var/www/starseed/ | head -10
# Verifier que .env existe encore
sudo test -f /var/www/starseed/.env && echo ".env OK"
Etape 5 — Mettre a jour .env de prod
Editer /var/www/starseed/.env :
DATABASE_URL: remplacer/coltura_prod->/starseed_prod(et user si renomme a etape 3)CORS_ALLOW_ORIGIN: remplacercoltura.malio-dev.fr->starseed.malio-dev.frDEFAULT_URI:https://starseed.malio-dev.fr
Diff attendu :
- DATABASE_URL="postgresql://malio:xxx@host.docker.internal:5432/coltura_prod?..."
+ DATABASE_URL="postgresql://malio:xxx@host.docker.internal:5432/starseed_prod?..."
- CORS_ALLOW_ORIGIN='^https?://coltura\.malio-dev\.fr$'
+ CORS_ALLOW_ORIGIN='^https?://starseed\.malio-dev\.fr$'
- DEFAULT_URI=https://coltura.malio-dev.fr
+ DEFAULT_URI=https://starseed.malio-dev.fr
Etape 6 — Stopper et supprimer l'ancien container
cd /var/www/starseed
sudo docker compose down
# Verifier qu'il n'y a plus de coltura-app
sudo docker ps -a --filter name=coltura
Etape 7 — Pull la nouvelle image et demarrer
Le docker-compose.prod.yml du dossier deja a jour pointe sur gitea.malio.fr/malio-dev/starseed:latest et container_name: starseed-app.
cd /var/www/starseed
sudo docker compose pull
sudo docker compose up -d
sleep 5
sudo docker ps --filter name=starseed-app
sudo docker logs starseed-app --tail 30
Etape 8 — Migrations Doctrine + cache
cd /var/www/starseed
sudo docker compose exec -T -u www-data app php bin/console doctrine:migrations:migrate --no-interaction
sudo docker compose exec -T -u www-data app php bin/console cache:clear --env=prod
sudo docker compose exec -T -u www-data app php bin/console cache:warmup --env=prod
Etape 9 — Vhost nginx system + certificat
Copier le nouveau vhost (a jour avec server_name starseed.malio-dev.fr et root /var/www/starseed/public) :
sudo cp /var/www/starseed/infra/prod/nginx-proxy.conf /etc/nginx/sites-available/starseed.conf
sudo ln -sf /etc/nginx/sites-available/starseed.conf /etc/nginx/sites-enabled/starseed.conf
sudo rm -f /etc/nginx/sites-enabled/coltura.conf
sudo nginx -t
Avant de reload nginx, generer le certificat Let's Encrypt pour le nouveau domaine (l'utilisateur doit confirmer ; certbot peut casser temporairement le vhost actuel pendant la challenge) :
# Verifier le DNS d'abord
dig +short starseed.malio-dev.fr
# Generer le cert (l'utilisateur valide)
sudo certbot --nginx -d starseed.malio-dev.fr --non-interactive --agree-tos -m matthieu@malio.fr
Puis :
sudo systemctl reload nginx
Etape 10 — Desactiver le mode maintenance et tester
rm -f /var/www/starseed/maintenance.on
# Tests externes
curl -s -o /dev/null -w "HTTP %{http_code}\n" https://starseed.malio-dev.fr/
curl -s https://starseed.malio-dev.fr/api/version
/api/version doit renvoyer du JSON avec la version courante.
Etape 11 — Cleanup (apres 24-48h de stabilite)
A faire plus tard, seulement quand on est sur que tout marche :
# Backup deja conserve en /root/coltura_prod_backup_*.sql.
# Apres validation utilisateur :
sudo -u postgres psql -c "DROP DATABASE coltura_prod;"
sudo rm -f /etc/nginx/sites-available/coltura.conf
sudo docker image prune # nettoie les vieilles images coltura
Rollback (si echec apres etape 5)
# 1. Remettre maintenance
touch /var/www/starseed/maintenance.on 2>/dev/null || touch /var/www/coltura/maintenance.on
# 2. Restaurer le path FS
sudo mv /var/www/starseed /var/www/coltura 2>/dev/null || true
# 3. Restaurer le vhost coltura
sudo rm -f /etc/nginx/sites-enabled/starseed.conf
sudo ln -sf /etc/nginx/sites-available/coltura.conf /etc/nginx/sites-enabled/coltura.conf
sudo systemctl reload nginx
# 4. Redemarrer l'ancien container (l'image coltura est encore dans le registry)
cd /var/www/coltura
# Editer docker-compose.prod.yml pour pointer sur coltura:latest si necessaire
sudo docker compose up -d
# 5. Si la DB starseed_prod a ete modifiee, restaurer depuis le backup
sudo -u postgres psql -c "DROP DATABASE IF EXISTS coltura_prod;"
sudo -u postgres pg_restore -C -d postgres "$BACKUP_FILE"
# 6. Lever maintenance
rm -f /var/www/coltura/maintenance.on
Regles de comportement pour le Claude prod
- Ne jamais skipper le backup (etape 2).
- Demander confirmation utilisateur avant :
DROP DATABASE,rm -rf,certbot, et avant de lever le mode maintenance final. - Une seule operation destructive a la fois, attendre le retour utilisateur entre chaque.
- Logger systematiquement la sortie des commandes critiques (pg_dump, docker compose up, certbot).
- Si une etape echoue, NE PAS continuer — declencher le rollback.
- Ne commit rien sur le repo depuis le serveur prod.