PhpMyAdmin sur GKE Autopilot

phpMyAdmin est l'outil web open source (GPLv2) le plus populaire pour administrer des bases de données MySQL et MariaDB depuis le navigateur — parcourir et modifier des tables, exécuter du SQL, gérer les utilisateurs et importer/exporter des données. Ce module déploie phpMyAdmin sur GKE Autopilot au-dessus du socle App_GKE, qui provisionne et gère l'infrastructure Google Cloud et Kubernetes partagée.

Ce guide se concentre sur les services cloud qu'utilise phpMyAdmin 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 à toute application GKE — Workload Identity, entrée, mise à l'échelle automatique, CI/CD, Cloud Armor, IAP, Binary Authorization, VPC Service Controls et cycle de vie du déploiement — reportez-vous au guide du socle App_GKE plutôt que de les répéter ici.

1. Vue d'ensemble

phpMyAdmin s'exécute comme une charge de travail web PHP + Apache sans état sur GKE Autopilot. C'est l'un des déploiements les plus légers de ce dépôt — il n'assemble que les services dont il a réellement besoin :

Fonctionnalité	Service Google Cloud	Remarques
Calcul	GKE Autopilot	Pods PHP/Apache, mise à l'échelle automatique ; facturation du CPU et de la mémoire demandés
Base de données	Aucune provisionnée	phpMyAdmin n'a pas de base de données propre ; il se connecte à un serveur MySQL/MariaDB externe que vous lui indiquez
Stockage objet	Aucun	Sans état — aucun bucket GCS n'est créé
Cache	Redis (facultatif, désactivé)	Uniquement pour la limitation de débit/détection de bots sur les déploiements publics ; non requis
Secrets	Aucun généré	phpMyAdmin ne détient aucun secret ; les utilisateurs se connectent avec les identifiants propres du serveur MySQL cible
Image de conteneur	Artifact Registry	Build personnalisé minimal `FROM phpmyadmin/phpmyadmin`, dupliqué et épinglé par tag
Entrée	Cloud Load Balancing	Service LoadBalancer externe par défaut ; domaine personnalisé et certificat géré facultatifs

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

Aucune base de données n'est provisionnée pour phpMyAdmin. database_type = "NONE" est fixé et imposé par un garde-fou de validation au moment du plan. phpMyAdmin est un client — il administre un serveur MySQL situé ailleurs (l'IP privée Cloud SQL de la plateforme, une autre instance Cloud SQL ou tout hôte MySQL/MariaDB joignable). Rien ici ne crée ce serveur.
La cible MySQL est choisie par des variables d'environnement, pas par du code. PMA_ARBITRARY = "1" (la valeur par défaut) affiche un champ de saisie du serveur sur la page de connexion afin que les utilisateurs saisissent n'importe quel hôte. Définissez pma_host (et PMA_ARBITRARY = "0") pour épingler un seul serveur.
Aucun secret n'est généré. Il n'y a ni clé de chiffrement, ni secret JWT, ni mot de passe applicatif à protéger. L'authentification s'effectue avec les comptes propres de la base de données cible (authentification par cookie).
Deployment sans état, au moins 1 réplica. workload_type vaut par défaut un Deployment (pas un StatefulSet — il n'y a pas d'état par pod) et GKE maintient au moins un réplica en cours d'exécution (pas de mise à zéro) afin que la console soit toujours joignable.
Exposé via un LoadBalancer externe (service_type = "LoadBalancer"). phpMyAdmin étant un puissant outil d'administration de bases de données, envisagez sérieusement de le placer derrière IAP (via un Ingress) ou de restreindre le LoadBalancer avant de l'exposer à Internet.
NFS et Redis sont désactivés par défaut. phpMyAdmin ne conserve aucun état ; n'activez Redis que pour la protection contre les abus sur un déploiement public.
Le conteneur écoute sur le port 80 (Apache apache2-foreground).

2. Services Google Cloud et comment les explorer

Toutes les commandes supposent que vous avez exécuté gcloud container clusters get-credentials <cluster> --region <region> --project <project> et que PROJECT, REGION et NAMESPACE sont définis. L'espace de noms et les autres identifiants figurent dans les sorties du déploiement.

A. GKE Autopilot — la charge de travail phpMyAdmin

Les pods phpMyAdmin sont planifiés sur Autopilot, qui facture le CPU et la mémoire demandés par les pods. L'autoscaling horizontal des pods dimensionne le Deployment entre le nombre minimal et maximal de réplicas. Le conteneur écoute sur le port 80.

Console : Kubernetes Engine → Workloads → sélectionnez la charge de travail phpMyAdmin pour voir les pods et les événements. Kubernetes Engine → Services & Ingress affiche l'IP externe.

CLI :

kubectl get pods,svc,hpa -n "$NAMESPACE"
kubectl logs -n "$NAMESPACE" deploy/<service-name> --tail=100
# Confirm the MySQL-target env vars injected into the running pod:
kubectl exec -n "$NAMESPACE" deploy/<service-name> -- env | grep PMA_

Consultez App_GKE pour la gestion d'Autopilot, de la mise à l'échelle et du type de charge de travail (Deployment ou StatefulSet).

B. Le serveur MySQL/MariaDB cible (externe)

phpMyAdmin ne provisionne pas de base de données — il se connecte à une base que vous possédez déjà. Cette cible est choisie via pma_host / pma_port (fixe) ou PMA_ARBITRARY = "1" (l'utilisateur saisit l'hôte à la connexion). Une pratique courante consiste à pointer phpMyAdmin vers l'IP privée Cloud SQL partagée de la plateforme :

Console : SQL → sélectionnez l'instance pour trouver son IP privée et son nom de connexion.

CLI :

# Find a MySQL instance's private IP to use as pma_host:
gcloud sql instances list --project "$PROJECT" --filter="databaseVersion~MYSQL"
gcloud sql instances describe <instance-name> --project "$PROJECT" \
  --format='value(ipAddresses[0].ipAddress)'

Les pods atteignent directement un serveur MySQL à IP privée via le réseau VPC du cluster (aucun sidecar Auth Proxy n'est nécessaire — enable_cloudsql_volume vaut false pour phpMyAdmin, car il n'utilise pas l'intégration Cloud SQL propre à la plateforme). Les utilisateurs s'authentifient sur la page de connexion de phpMyAdmin avec les comptes MySQL propres à cette base.

C. Cloud Storage

Non utilisé. phpMyAdmin est sans état et ne déclare aucun bucket GCS. L'import et l'export dans l'interface de phpMyAdmin transitent par le navigateur, pas par GCS.

D. Redis (protection facultative contre les abus)

Redis est désactivé par défaut (enable_redis = false). Il n'est utile que si vous activez la limitation de débit/détection de bots de phpMyAdmin sur un déploiement public. Désactivé, phpMyAdmin fonctionne pleinement — Redis n'est pas requis pour un fonctionnement normal.

CLI (uniquement s'il est activé) :

kubectl exec -n "$NAMESPACE" deploy/<service-name> -- env | grep REDIS

E. Secret Manager

Ce module ne génère aucun secret. phpMyAdmin ne détient ni clé de chiffrement, ni secret JWT, ni mot de passe applicatif — la connexion s'effectue avec les identifiants propres du serveur MySQL cible, saisis sur la page de connexion de phpMyAdmin et jamais stockés. Vous pouvez néanmoins ajouter vos propres secret_environment_variables, que le socle matérialise via l'intégration Secret Store CSI.

Console : Security → Secret Manager.

CLI :

gcloud secrets list --project "$PROJECT" --filter="name~phpmyadmin"

Consultez App_GKE pour l'intégration Secret Store CSI.

F. Réseau et entrée

Par défaut, la charge de travail est exposée via une IP Cloud Load Balancing externe (service_type = "LoadBalancer"). Un domaine personnalisé avec un certificat géré par Google peut être activé, et une IP statique peut être réservée afin que l'adresse survive aux redéploiements. IAP (via un Ingress) peut conditionner l'accès à une connexion Google — vivement recommandé pour un outil d'administration de bases de données.

Console : Network services → Load balancing ; VPC network → IP addresses.

CLI :

kubectl get ingress,svc -n "$NAMESPACE"
gcloud compute addresses list --project "$PROJECT"

Consultez App_GKE pour le détail des domaines personnalisés, de Cloud CDN et des IP statiques.

G. Cloud Logging et Monitoring

Les sorties stdout/stderr des pods sont envoyées vers Cloud Logging ; les métriques GKE vers Cloud Monitoring. Des tests de disponibilité et des règles d'alerte facultatifs sont disponibles.

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

CLI :

gcloud logging read 'resource.type="k8s_container" AND resource.labels.namespace_name="'"$NAMESPACE"'"' \
  --project "$PROJECT" --limit 50

3. Comportement de l'application PhpMyAdmin

Aucune configuration de base de données au premier déploiement. Il n'y a ni job db-init ni schéma à créer — phpMyAdmin n'a pas de base de données propre. Le pod est prêt dès qu'Apache/PHP démarre.
Ni migrations, ni clés immuables. phpMyAdmin ne stocke rien entre les redémarrages ; il n'y a donc aucun schéma à migrer et aucune clé cryptographique qui puisse se corrompre lors d'un redéploiement. Les mises à jour progressives et les montées de version présentent peu de risques.
Deployment sans état. workload_type se résout en un Deployment et stateful_pvc_enabled est désactivé — il n'y a aucun état par pod à préserver. Une mise à jour progressive est sûre, car les pods ne partagent ni volume ni verrou.
Connexion par cookie. Les utilisateurs se connectent sur la page de phpMyAdmin avec le nom d'utilisateur et le mot de passe propres au serveur MySQL cible ; la session réside dans un cookie de courte durée. phpMyAdmin ne conserve jamais ces identifiants, et il n'y a pas de « compte administrateur » phpMyAdmin à créer après le déploiement.
Choix de la cible MySQL. Vérifiez les variables d'environnement PMA_* injectées dans le pod en cours d'exécution :
```
kubectl exec -n "$NAMESPACE" deploy/<service-name> -- env | grep PMA_
```
Avec PMA_ARBITRARY = "1", la page de connexion affiche un champ serveur ; avec un pma_host fixe, les utilisateurs ne voient que le nom d'utilisateur et le mot de passe pour ce seul serveur.
Chemin de santé. Les sondes de démarrage, de vivacité et de disponibilité ciblent / — Apache y sert la page de connexion avec un 200 dès que PHP est prêt. Le premier démarrage est rapide ; aucune longue fenêtre de migration n'est nécessaire.
Posture de sécurité. phpMyAdmin expose l'administration complète des bases de données à quiconque peut atteindre le LoadBalancer et détient des identifiants MySQL valides. Protégez-le par IAP ou restreignez le Service, et définissez PMA_ARBITRARY = "0" avec un pma_host fixe si les utilisateurs ne doivent atteindre qu'un seul serveur.

4. Variables de configuration

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