Loading...

Modules complémentaires

Modules complémentaires gérés

Utilisez les modules complémentaires gérés lorsque la plateforme doit créer, faire pivoter et lier des détails d'infrastructure au lieu de demander aux clients des valeurs host, port ou mot de passe.

Retour à l'Aide Plateforme

Managed Redis

Lorsque Redis est activé, le service est créé automatiquement et attaché à la plateforme en tant que variables d'environnement et secrets.

  • Les valeurs host, port ou mot de passe Redis ne sont pas demandées aux utilisateurs.
  • Activer ou désactiver le service ultérieurement est appliqué via une mise à jour de déploiement.
  • Le panneau affiche des messages d'état tels que "Managed Redis is running".

Managed Database

Pour les plateformes telles que WordPress, les noms d'utilisateur et mots de passe de base de données sont générés par le système.

  • Les valeurs des secrets ne sont pas renvoyées dans les réponses GET.
  • Les opérations d'installation et de réinitialisation ciblent uniquement la ressource de plateforme concernée.
  • Si des informations de base de données sont nécessaires, elles peuvent être régénérées ou alternées via une action du panneau.

Object Storage

Object Storage compatible S3 fournit la gestion des buckets et des clés d'accès lorsque Ceph RGW est prêt.

  • Les buckets clients ne sont pas créés tant que la porte de santé Ceph RGW n'est pas ouverte.
  • La clé d'accès secrète n'est affichée qu'une seule fois lors de la création ou de la rotation.
  • Après la liaison, les variables d'environnement S3 sont ajoutées lorsque l'app est redéployée.
  • AWS CLI et les SDKs compatibles S3 peuvent utiliser l'endpoint https://s3.cdn.com.tr avec la clé d'accès générée.

Connecter votre application aux modules

Lorsque vous activez un module, la plateforme injecte automatiquement ses informations de connexion dans votre application sous forme de variables d'environnement (et les mots de passe sous forme de Secrets Kubernetes). Lisez-les depuis l'environnement de votre application dans le code ; inutile de copier manuellement les valeurs d'hôte, de port ou de mot de passe.

  • Redéployez l'application après avoir activé un module afin que les variables soient montées dans les conteneurs.
  • Les mots de passe ne sont jamais affichés dans le panneau ni dans les réponses de l'API ; seuls les noms des variables sont visibles. Lisez la valeur depuis l'environnement ou utilisez l'URL de connexion prête à l'emploi (DATABASE_URL / REDIS_URL).
  • Les préfixes des variables (REDIS, DB, DATABASE, NATS) peuvent être personnalisés par module via env_prefix.
  • Utilisez un module depuis une autre application (par exemple une tâche de sauvegarde) : définissez une variable de cette application sur ${slug-app-source.VAR}, par exemple DATABASE_URL=${web.DATABASE_URL} ou DB_PASSWORD=${web.DB_PASSWORD}. La résolution est sécurisée au sein de votre compte et le mot de passe n'est jamais exposé.
Redis:       REDIS_HOST, REDIS_PORT, REDIS_DB, REDIS_URL, REDIS_PASSWORD
MySQL:       DB_HOST, DB_PORT, DB_DATABASE, DB_USERNAME, DB_PASSWORD, DB_URL, DATABASE_URL
PostgreSQL:  DATABASE_HOST, DATABASE_PORT, DATABASE_NAME, DATABASE_USER, DATABASE_PASSWORD, DATABASE_URL
NATS:        NATS_HOST, NATS_PORT, NATS_URL

Accès externe

Les modules gérés sont accessibles uniquement depuis l'intérieur de la plateforme, par conception.

  • Redis, MySQL, PostgreSQL et NATS sont créés en tant que services internes du cluster avec des noms d'hôte privés.
  • Ils ne sont accessibles que depuis les conteneurs de votre propre application, via les variables d'environnement injectées.
  • Il n'existe aucun point d'accès public ; vous ne pouvez donc pas vous connecter depuis l'extérieur (par exemple un client de base de données sur votre ordinateur).