Le travail de configuration que vous ne faites plus
Installer une base de données implique normalement de provisionner un serveur, d'installer le moteur, de créer des utilisateurs et des droits, de régler les limites de connexion, d'ouvrir les bons ports, et de garder le tout à jour. Pour une seule application, c'est beaucoup de travail indifférencié avant même d'écrire une seule ligne de logique métier. cdn.com.tr provisionne l'instance MySQL, MariaDB, PostgreSQL ou Redis pour vous et vous remet des identifiants prêts à l'emploi, si bien que vous passez directement à la connexion de votre application.
Des identifiants en environnement, pas en code
La plateforme génère le nom d'utilisateur et le mot de passe et injecte l'hôte, le port, la base de données, l'utilisateur et le mot de passe dans l'application attachée sous forme de variables d'environnement. Cela compte pour la sécurité et pour les opérations : les secrets ne se trouvent jamais dans votre historique Git ni dans votre image Docker, et comme l'application les lit au runtime, régénérer un mot de passe est une mise à jour de binding plutôt qu'un changement de code. Cela préserve la séparation douze-facteurs entre configuration et code sans que vous ayez à construire la plomberie.
Choisir entre MySQL, MariaDB et PostgreSQL
La plupart des stacks WordPress et PHP classiques attendent MySQL ou son cousin compatible MariaDB, et l'un ou l'autre est un choix par défaut sûr pour ces applications. PostgreSQL est le bon choix quand votre framework ou votre schéma repose sur des types, extensions ou un comportement SQL plus strict spécifiques à Postgres. Comme les trois sont proposés comme add-ons managés avec le même flux d'attachement et d'injection, la décision porte sur ce qu'attend votre application, pas sur la difficulté d'exploitation de chacun — tous sont provisionnés de la même façon.
À quoi sert vraiment Redis managé
Redis est un stockage en mémoire, et sur la plateforme il remplit typiquement l'un de ces trois rôles : mettre en cache des résultats de requêtes coûteuses et des fragments rendus, conserver les sessions utilisateur afin qu'elles survivent entre les réplicas de container, et servir de cache d'objets WordPress pour réduire les sollicitations répétées de la base de données sur des pages à fort trafic. Comme il vit en dehors du container applicatif, un service scalé horizontalement partage un seul cache et un seul stockage de sessions au lieu que chaque réplica garde le sien. C'est ce qui fait que le scaling horizontal se comporte correctement pour des fonctionnalités qui semblent avoir un état.
Cache d'objets Redis pour WordPress
Un site WordPress sous charge passe un temps surprenant à réexécuter les mêmes requêtes de base de données pour construire chaque page. Pointer WordPress vers un add-on Redis managé comme cache d'objets signifie que ces résultats sont servis depuis la mémoire plutôt que la base de données, ce qui réduit la pression sur les requêtes et stabilise les temps de réponse quand le trafic explose pendant une campagne. Associé au cache CDN pour les assets statiques, Redis gère le côté dynamique afin que la base de données ne soit pas le goulet d'étranglement.
Rotation, réinitialisation et usage partagé
Les mots de passe ne devraient pas être éternels, et parfois l'un d'eux fuite dans un log ou une capture d'écran. Le flux de réinitialisation/rotation génère un identifiant frais et les applications attachées le reçoivent via leur binding, si bien que vous ne chassez pas un mot de passe codé en dur à travers plusieurs bases de code. Quand plusieurs services partagent réellement une base de données, attacher le même add-on à chacun les garde cohérents, tandis que le statut de la plateforme vous donne un seul endroit pour confirmer que la couche de données est saine après tout changement.
Comment le configurer, étape par étape
Choisir le moteur dont votre application a besoin
Dans le panneau, ouvrez la zone Add-ons et créez une base de données. Choisissez MySQL ou MariaDB pour la plupart des workloads PHP et WordPress, ou PostgreSQL pour les applications qui attendent des fonctionnalités Postgres. Pour le cache, les sessions, ou un cache d'objets WordPress, créez un add-on Redis. Chacun est provisionné pour vous avec un nom de base de données, un utilisateur et un mot de passe généré.
L'attacher à une application
Depuis l'add-on ou depuis les paramètres propres de l'application, attachez la base de données à une Container App, une Plateforme PHP, ou un site WordPress. L'attachement câble les détails de connexion dans l'application au lieu de vous demander de les copier à la main, et le même add-on peut être partagé par les services qui en ont légitimement besoin.
Lire les identifiants depuis l'environnement
Une fois attachés, l'hôte, le port, le nom de la base de données, le nom d'utilisateur et le mot de passe arrivent sous forme de variables d'environnement dans l'application. Votre code les lit au runtime — par exemple un DSN PDO ou un client Redis construit à partir de ces variables d'env — si bien que rien de sensible n'est intégré dans l'image ni versionné dans le dépôt.
Laisser WordPress et PHP se câbler eux-mêmes
Pour un site WordPress, la plateforme remplit la connexion à la base de données pendant l'installation afin que vous n'ayez pas à éditer wp-config à la main, et un add-on Redis peut alimenter le cache d'objets. Pour une application PHP sur mesure, pointez la configuration de base de données et de cache de votre framework vers les noms de variables d'env injectées et vous êtes connecté.
Régénérer ou réinitialiser en cas de besoin
Si un identifiant est exposé ou que vous en régénérez simplement un selon un planning, utilisez le flux de réinitialisation/rotation sur l'add-on. Un nouveau mot de passe est généré et les applications attachées récupèrent la valeur mise à jour via leur binding, si bien que la rotation ne signifie pas une chasse manuelle au redéploiement à travers plusieurs services.
Surveiller la santé et automatiser avec cdnctl
Utilisez le statut de la plateforme pour confirmer que l'add-on est actif et joignable, et pilotez les tâches routinières — créer un add-on, l'attacher, déclencher une rotation — depuis cdnctl afin que le provisioning d'environnement s'intègre dans des scripts et de la CI plutôt que des clics manuels.
Exemples de scénarios
Un site de contenu est provisionné avec une base de données MySQL managée à l'installation et un add-on Redis comme cache d'objets, si bien que les pages se rendent depuis la mémoire et survivent aux pics de trafic sans marteler la base de données.
Une API Laravel attache un add-on PostgreSQL managé et un add-on Redis pour les queues et le cache, lisant les deux jeux de connexion depuis des variables d'environnement injectées sans aucune administration serveur.
Une application containerisée scalée sur plusieurs réplicas stocke les sessions dans Redis managé afin qu'un utilisateur reste connecté quel que soit le réplica qui sert la prochaine requête.
Une équipe régénère son mot de passe de base de données depuis le panneau chaque trimestre ; les applications attachées reçoivent le nouveau secret via leur binding, évitant un balayage manuel des fichiers de configuration.
Questions fréquentes
Quels moteurs de base de données puis-je provisionner ?
MySQL, MariaDB et PostgreSQL sont disponibles comme add-ons de base de données managés, et Redis est disponible comme add-on de cache managé. Choisissez MySQL ou MariaDB pour les applications WordPress et PHP typiques, et PostgreSQL quand votre application attend spécifiquement Postgres.
Comment mon application reçoit-elle les détails de connexion ?
Quand vous attachez un add-on à une application, l'hôte, le port, le nom de la base de données, le nom d'utilisateur et le mot de passe sont injectés sous forme de variables d'environnement. Votre code construit son DSN ou son client Redis à partir de ces variables au runtime, si bien qu'aucun identifiant ne vit dans l'image ou le dépôt.
Redis est-il un remplacement de base de données ou un cache ?
C'est un cache et un stockage en mémoire, pas un remplacement pour votre base de données principale. Utilisez-le pour la mise en cache de requêtes et de fragments, les sessions qui doivent être partagées entre réplicas, et comme cache d'objets WordPress — tandis que vos données durables restent dans MySQL, MariaDB, ou Postgres.
Comment régénérer un mot de passe de base de données sans casser les applications ?
Utilisez le flux de réinitialisation/rotation sur l'add-on. Un nouveau mot de passe est généré et les applications attachées le récupèrent via leur binding, si bien que vous n'avez pas à éditer la configuration dans chaque base de code. Confirmez ensuite la santé via le statut de la plateforme.
Plusieurs applications peuvent-elles partager une base de données ou une instance Redis ?
Oui. Attachez le même add-on à chaque service qui en a légitimement besoin et ils partagent l'instance tout en restant cohérents. Pour l'isolation, provisionnez plutôt un add-on séparé par application — les deux modèles utilisent le même flux d'attachement et d'injection.
WordPress nécessite-t-il une configuration manuelle de la base de données ?
Non. La plateforme remplit la connexion à la base de données pendant l'installation de WordPress, si bien que vous n'éditez pas wp-config à la main pour cela, et un add-on Redis peut être câblé comme cache d'objets pour réduire les requêtes de base de données répétées sur les pages à fort trafic.