Castopod sur Google Cloud Run

Castopod est une plateforme open source d'hébergement de podcasts, nativement compatible ActivityPub, construite sur CodeIgniter 4 (PHP 8) et servie par FrankenPHP/Caddy. Ce module déploie Castopod sur Cloud Run v2 au-dessus du socle App_CloudRun, qui provisionne et gère l'infrastructure Google Cloud partagée.

Ce guide se concentre sur les services cloud qu'utilise Castopod et sur la manière de les explorer et de les exploiter depuis la console Google Cloud et la ligne de commande. Pour les mécanismes communs à toutes les applications Cloud Run — identité du service, ingress et équilibrage de charge, mise à l'échelle et concurrence, CI/CD, Cloud Armor, IAP, Binary Authorization, VPC Service Controls, sauvegardes et cycle de vie du déploiement — reportez-vous au guide du socle App_CloudRun plutôt que de les répéter ici.

1. Vue d'ensemble

Castopod s'exécute comme un conteneur PHP/FrankenPHP sur Cloud Run v2, à l'écoute sur le port 8080. Le déploiement assemble un ensemble restreint de services Google Cloud :

Fonctionnalité	Service Google Cloud	Remarques
Calcul	Cloud Run v2	Service FrankenPHP/Caddy, 1 vCPU / 2 GiB par défaut, autoscaling serverless ; mise à zéro prise en charge
Base de données	Cloud SQL for MySQL 8.0	Obligatoire — Castopod ne prend en charge ni PostgreSQL ni aucun autre moteur
Stockage des médias	Cloud Storage + Cloud Filestore (NFS)	Un bucket `media` est provisionné ; NFS est activé par défaut pour conserver les fichiers téléversés entre les redémarrages
Cache	Redis (facultatif)	Le cache fichier (`CP_CACHE_HANDLER = file`) est la valeur par défaut ; Redis est optionnel
Secrets	Secret Manager	`CP_ANALYTICS_SALT` généré automatiquement ; mot de passe de la base de données
Ingress	URL Cloud Run / Cloud Load Balancing	URL `run.app` par défaut ; équilibreur de charge HTTPS externe et domaine personnalisé facultatifs

Valeurs par défaut judicieuses à connaître d'emblée :

MySQL 8.0 est obligatoire. Le moteur de base de données est fixé (database_type = "MYSQL_8_0") par le module ; choisir PostgreSQL ou tout autre moteur empêche le démarrage.
La configuration de la base de données est écrite dans le .env de Castopod, et non dans des variables d'environnement. Castopod (CodeIgniter 4) lit des clés en notation pointée (database.default.hostname …) qui ne peuvent pas être des noms de variables d'environnement Cloud Run. Le point d'entrée du conteneur les matérialise dans .env à partir des variables DB_* injectées, et résout un hôte TCP (DB_IP), car le pilote mysqli de CI4 ne peut pas utiliser le répertoire de socket Cloud SQL.
CP_ANALYTICS_SALT est généré automatiquement et stocké dans Secret Manager. Conservez-le stable — il anonymise les statistiques d'écoute, et le modifier rompt la continuité de la déduplication pour les auditeurs déjà enregistrés.
La mise à zéro est activée par défaut (min_instance_count = 0). Les démarrages à froid ajoutent quelques secondes de latence à la première requête après une période d'inactivité. Définissez min_instance_count = 1 pour que Castopod reste toujours actif.
max_instance_count = 1 par défaut. Ne dépassez pas une instance tant qu'il n'est pas confirmé que le système de fichiers de médias partagé (NFS/GCS) et un cache partagé supportent plusieurs instances.
NFS est activé par défaut (enable_nfs = true) pour conserver les médias téléversés entre les redémarrages du conteneur. Castopod stocke l'audio et les illustrations des épisodes sur le système de fichiers, et non dans la base de données.
L'URL de base est dérivée automatiquement. Le point d'entrée définit CP_BASEURL à partir de CLOUDRUN_SERVICE_URL à l'exécution, de sorte que les URL du flux du podcast et des médias reflètent l'adresse réelle du service.
Les migrations CodeIgniter s'exécutent au démarrage du conteneur — il n'y a pas de job de migration distinct, car le point d'entrée de la surcouche de la plateforme (Castopod_Common/scripts/entrypoint.sh) exécute explicitement php spark migrate --all à chaque démarrage ; l'image de base castopod/castopod ne le fait pas automatiquement. Le schéma est créé au premier démarrage, après que le job db-init a provisionné la base et l'utilisateur (voir §3 ci-dessous).

2. Services Google Cloud et comment les explorer

Toutes les commandes supposent que PROJECT et REGION sont définis. Les noms du service et des ressources figurent dans les sorties du déploiement.

A. Cloud Run — le service Castopod

Castopod s'exécute comme un service Cloud Run v2 qui s'adapte automatiquement à la charge des requêtes, entre le nombre minimal et le nombre maximal d'instances. Chaque déploiement crée une révision immuable ; le trafic peut être réparti entre les révisions pour des déploiements progressifs sûrs.

Console : Cloud Run → sélectionnez le service pour voir les révisions, le trafic, les journaux et les métriques.

CLI :

gcloud run services list --project "$PROJECT" --region "$REGION" \
  --filter="metadata.name~castopod"
gcloud run services describe <service-name> --project "$PROJECT" --region "$REGION"
gcloud run revisions list --service <service-name> --project "$PROJECT" --region "$REGION"

Consultez App_CloudRun pour la mise à l'échelle, la concurrence, l'environnement d'exécution et la répartition du trafic.

B. Cloud SQL for MySQL 8.0

Castopod stocke toutes les données de l'application (podcasts, épisodes, utilisateurs, statistiques) dans une instance gérée Cloud SQL for MySQL 8.0. Le service s'y connecte de manière privée — le point d'entrée contacte l'IP privée de Cloud SQL en TCP (le pilote mysqli de CodeIgniter ne peut pas utiliser le répertoire de socket de l'Auth Proxy) ; aucune IP publique n'est exposée. Lors du premier déploiement, un Job d'initialisation crée la base de données et l'utilisateur de l'application.

Console : SQL → sélectionnez l'instance pour voir les connexions, les sauvegardes, les flags et les métriques.

CLI :

gcloud sql instances list --project "$PROJECT" --filter="name~castopod"
gcloud sql instances describe <instance-name> --project "$PROJECT"
gcloud sql connect <instance-name> --user=<db-user> --database=<db-name> --project "$PROJECT"

Le nom de l'instance, la base de données, l'utilisateur et le secret du mot de passe figurent dans les sorties. Consultez App_CloudRun pour le modèle de connexion, les sauvegardes et la rotation du mot de passe.

C. Cloud Storage et persistance des médias

Un bucket Cloud Storage media dédié est provisionné automatiquement. Comme Castopod écrit l'audio et les illustrations téléversés sur le système de fichiers du conteneur, sous /var/www/castopod/public/media, Cloud Filestore (NFS) est activé par défaut (enable_nfs = true, monté sur nfs_mount_path) afin que ces fichiers survivent aux redémarrages.

Console : Cloud Storage → Buckets ; Filestore → Instances.

CLI :

gcloud storage buckets list --project "$PROJECT" --filter="name~media"
gcloud filestore instances list --project "$PROJECT"

Consultez App_CloudRun pour les options GCS Fuse, NFS et CMEK.

D. Redis (cache d'objets)

Redis est désactivé par défaut — Castopod utilise un cache sur le système de fichiers (CP_CACHE_HANDLER = file). Lorsque enable_redis = true, le module injecte REDIS_HOST et REDIS_PORT pour le cache d'objets de Castopod. Lorsque redis_host est laissé vide et que enable_nfs vaut true, l'IP de la VM du serveur NFS est utilisée comme point de terminaison Redis.

Console : Memorystore → Redis (si vous utilisez une instance gérée).

CLI :

redis-cli -h <redis-host> ping
# Confirm the injected cache/redis env in the running revision:
gcloud run services describe <service-name> --region "$REGION" \
  --format='value(spec.template.spec.containers[0].env)'

E. Secret Manager

Un secret cryptographique est généré automatiquement et stocké dans Secret Manager : CP_ANALYTICS_SALT (utilisé pour anonymiser les statistiques d'écoute du podcast). Le mot de passe de la base de données est géré séparément par le socle.

Console : Security → Secret Manager.

CLI :

gcloud secrets list --project "$PROJECT" --filter="name~analytics-salt"
gcloud secrets versions access latest --secret=<secret-name> --project "$PROJECT"

Consultez App_CloudRun pour les détails d'injection et de rotation.

F. Réseau et entrée

Le service est accessible par défaut à son URL run.app, qui autorise l'accès public requis pour les flux de podcast publics et les téléchargements de médias. Un équilibreur de charge HTTPS externe avec domaine personnalisé, Cloud CDN et Cloud Armor peut être ajouté ; les paramètres d'ingress et le contrôle de sortie VPC régissent la connectivité.

Console : Cloud Run (URL du service) ; Network services → Load balancing.

CLI :

gcloud run services describe <service-name> --region "$REGION" --format='value(status.url)'
gcloud compute addresses list --project "$PROJECT"

Consultez App_CloudRun.

G. Cloud Logging et Monitoring

Les journaux du conteneur sont envoyés vers Cloud Logging ; les métriques de Cloud Run et de Cloud SQL vers Cloud Monitoring, avec des tests de disponibilité et des règles d'alerte facultatifs.

Console : Logging → Logs Explorer ; Monitoring → Dashboards / Alerting.

CLI :

gcloud run services logs read <service-name> --project "$PROJECT" --region "$REGION" --limit 50

3. Comportement de l'application Castopod

Configuration de la base de données au premier déploiement. Un Job d'initialisation exécute db-init.sh avec mysql:8.0-debian. Il se connecte via le socket du Cloud SQL Auth Proxy (ou, en repli, en TCP sur l'IP privée) et crée de manière idempotente la base de données et l'utilisateur de l'application, accorde les privilèges et vérifie que l'utilisateur de l'application peut se connecter. Le job peut être relancé sans risque.
Les migrations s'exécutent au démarrage du conteneur — via le point d'entrée de la plateforme, et non l'image de base. L'image castopod/castopod (construite sur serversideup/php) n'a pas de hook de migration CodeIgniter propre ; son seul comportement de migration automatique est spécifique à Laravel (php artisan migrate, conditionné par AUTORUN_ENABLED, par défaut false) et n'exécuterait pas le spark migrate de CI4 même s'il était activé. Le point d'entrée de la surcouche de la plateforme (Castopod_Common/scripts/entrypoint.sh) exécute explicitement php spark migrate --all — idempotent, sans risque à chaque démarrage — une fois .env/la connectivité à la base écrits ; le schéma est donc créé au premier démarrage, et la mise à niveau de la version de l'application applique les changements de schéma au démarrage suivant, sans job de migration distinct. Si cet appel explicite venait à être supprimé, chaque requête renverrait une erreur 500 avec Table '...' doesn't exist alors même que db-init a réussi — vérifiez d'abord entrypoint.sh lorsque vous diagnostiquez ce symptôme.
La configuration de la base de données réside dans .env, injectée à l'exécution. Le point d'entrée écrit database.default.hostname|database|username|password|port et app.baseURL dans le .env de Castopod à partir des valeurs DB_* et CLOUDRUN_SERVICE_URL injectées par le socle. Il résout l'hôte de la base de données vers l'adresse TCP de l'IP privée, car le pilote mysqli de CI4 ne peut pas utiliser le répertoire de socket Cloud SQL.
CP_ANALYTICS_SALT doit rester stable après le premier démarrage. Il est généré une seule fois et écrit dans Secret Manager ; le modifier rompt la continuité de la déduplication pour les auditeurs déjà enregistrés. Ne le renouvelez que délibérément.
Chemin de santé. La sonde de démarrage est une sonde TCP sur le port du conteneur et la sonde de vivacité un HTTP GET / — la page d'accueil non authentifiée de Castopod renvoie 200 une fois l'application démarrée et connectée à MySQL. Prévoyez plusieurs minutes au premier démarrage pour que les migrations CodeIgniter se terminent (la sonde de démarrage prévoit un délai initial de 30 secondes plus une fenêtre de 20 tentatives).
Configuration au premier lancement. Après le déploiement, ouvrez l'URL du service et suivez l'assistant d'installation web de Castopod pour créer le premier compte super-administrateur et définir le nom de l'instance et les paramètres par défaut des podcasts. Les médias téléversés sont ensuite conservés dans le répertoire de médias adossé à NFS.

Inspecter l'exécution des jobs :

gcloud run jobs list --project "$PROJECT" --region "$REGION"
gcloud run jobs executions list --job <job-name> --project "$PROJECT" --region "$REGION"

4. Variables de configuration

Les variables sont regroupées exactement comme elles apparaissent sur la plateforme de déploiement. Seuls les paramètres propres à Castopod ou notables pour lui sont listés ; toutes les autres entrées sont héritées d'App_CloudRun avec leur comportement standard.