Démarrer Redis à partir d'un modèle versionné
Utilisez le modèle Redis 7 comme contrat de service, puis connectez uniquement les applications et les workers qui ont besoin de son cache ou de ses fonctions de messagerie.
Services de données · offres à partir de $10/mois
Déployer Redis.Décidez de ce qui doit survivre à un redémarrage.
Démarrez Redis 7 pour le cache, les sessions, le pub/sub ou la gestion rapide d’état, puis vérifiez la connectivité, la persistance attendue, l’éviction et le comportement en cas d’échec de cette dépendance.
Conserver le dépôtExaminer la compilation et les journauxDomaines personnalisés et TLS
Déploiement Adios
Version candidate
Redis
SOURCE
Git
REGION
de
ROUTE
HTTPS
01Source reçue
02Compilation terminée
03Environnement d’exécution démarré
04Vérification de santé réussie
Route promue en production
production.adios.run
Une mise en production adaptée à
Redis 7CacheSessionsPub/SubPersistance
Le parcours de mise en production
Même opérationnel, un projet Redis doit être mis en production en toute sécurité.
L’application ou le service ne représente qu’une partie de la production. Les résultats de compilation, l’état d’exécution, les contrôles de santé, les secrets, les journaux, les routes et la version promue doivent pouvoir être examinés ensemble.
Faire de la persistance une décision explicite
Le modèle actuel utilise la persistance append-only avec un volume de données monté. Déterminez si votre charge de travail utilise Redis comme cache non essentiel ou comme stockage de données à restaurer.
Garder l'état de service visible pour les opérateurs
Testez les opérations set et get, l’expiration, la reconnexion et le redémarrage. Pour les files d’attente ou les sessions, vérifiez aussi le traitement en double et l’impact sur les utilisateurs lorsque Redis est indisponible.
Du code source à la mise en production
Trois étapes vous permettent de vérifier le parcours de déploiement.
Utilisez le code source et le fonctionnement en production déjà définis pour le projet. Le manifeste décrit ce que la plateforme doit compiler ou provisionner et les critères à remplir pour que le résultat soit prêt.
- 01
Commencer par la source ou un modèle
Importez le dépôt existant, ou examinez et déployez l’une des variantes de modèles précisément référencées ci-dessous.
$adios login - 02
Revoir le contrat de déploiement
Consignez dans adios.yaml les commandes, la version de l’environnement d’exécution ou du service, les critères de santé et les références aux secrets.
$git diff -- adios.yaml - 03
Déployer et inspecter le résultat
Suivez les résultats de compilation et d’exécution, vérifiez la version candidate, puis ouvrez la route ou la connexion de service promue en production.
$adios up
adios.yaml
Votre projetname: application-cache
template: redis:7Déployez le modèle, puis injectez ses paramètres de connexion dans chaque application qui en dépend, via des secrets ou la configuration de l’environnement.
Points de départ déployables
Démarrer Redis à partir d'un modèle lorsque le dépôt n'est pas prêt.
Le modèle Redis 7 définit la version du service, la configuration de persistance et le parcours de déploiement pour une première connexion rapide.
Services de données
Redis 7
Un modèle de cache Redis 7 avec persistance par journal append-only.
Key-value dataGéré par Adios
- Clé du modèle
- redis:7
- Environnement d’exécution
- redis
- Dépôt
- template-redis-7
- Emplacement de la source
- .
git clone https://github.com/adiosdotdev/template-redis-7.git
cd template-redis-7
adios upAvant production
Vérifier la charge de travail.Puis promouvez la version en production.
Pour sécuriser la première mise en production, partez d’une compilation ou d’une configuration de service reproductible et d’un aperçu qui sollicite les dépendances réellement utilisées en production.
Prêt quand...
- La charge de travail détermine si Redis sert de cache ou de stockage d’état durable.
- Les clés suivent une stratégie d’expiration définie.
- Les applications se reconnectent après le redémarrage du service.
- Les besoins en mémoire et le comportement d’éviction attendu sont documentés.
Prévisualiser quand...
- Les sessions, les files d’attente ou les verrous dépendent du bon fonctionnement de Redis.
- Le mode de persistance ou la politique d’éviction change.
- Un préchargement important du cache affecte le trafic de l’application.
Les réponses à vos questions
Ce qu’il faut savoir avant de déployer Redis.
Vérifiez les limites de l’environnement d’exécution ou du service, le chemin du modèle, le comportement en cas d’échec et les contrôles de production avant de créer la première version.
Puis-je déployer Redis à partir d’un modèle officiel ?
Oui. Choisissez le modèle Redis correspondant à la version ou à la configuration souhaitée, stockez les identifiants dans des secrets Adios et déployez-le depuis la console ou avec adios up.
Le modèle Redis utilise-t-il un stockage persistant ?
Le modèle actuel utilise la persistance append-only avec un volume de données monté. Déterminez si votre charge de travail utilise Redis comme cache non essentiel ou comme stockage de données à restaurer.
Puis-je utiliser Redis pour des tâches en arrière-plan ?
Oui, si la bibliothèque de tâches choisie prend en charge Redis. Testez les nouvelles tentatives, la visibilité, les livraisons en double, l’arrêt des workers et le comportement lors d’un redémarrage du broker.
Toutes les clés Redis doivent-elles être persistantes ?
Non. Classez d’abord les données. Un cache non essentiel peut être reconstruit, tandis que les sessions, les files d’attente ou l’état de coordination peuvent nécessiter des mesures de restauration et de disponibilité plus robustes.
Où stocker les mots de passe de la base de données et du broker ?
Stockez les valeurs sensibles dans les secrets Adios et référencez-les avec secret://NAME. Ne placez pas les identifiants de production directement dans adios.yaml et ne les enregistrez pas dans Git.
Que dois-je vérifier avant de recevoir du trafic de production ?
Vérifiez l’authentification, la connectivité applicative, les écritures et lectures, la persistance après redémarrage, les besoins de sauvegarde ou de restauration, la capacité et le comportement en cas d’échec de chaque application dépendante.
Autres options de déploiement
Connectez le reste de votre stack.
Déployer PostgreSQL
Choisissez une version de PostgreSQL, conservez les identifiants de la base de données hors de Git, ajoutez un stockage persistant, connectez l’application et vérifiez les données après un redémarrage.
Déployer RabbitMQ
Démarrez RabbitMQ avec un accès à l’interface de gestion, protégez les identifiants du broker, connectez les producteurs et les consommateurs et testez les accusés de réception, les nouvelles tentatives et la persistance.
Déployer Node.js
Déployez un processus web ou un worker Node.js persistant à partir de ses scripts de packages existants, avec les contrôles de santé de la version, les journaux, les secrets, le routage et l’historique Git associés.
Déployer Ruby on Rails
Installez les gems aux versions verrouillées, préparez les ressources, lancez Puma, vérifiez la santé de l’application et associez la base de données, Redis, les secrets, les journaux et les domaines à cette version.
La première version
Déployer Redis avec le code source et les éléments de vérification associés.
Partez du dépôt ou d’un modèle, vérifiez le contrat de déploiement et examinez la version qui sera promue en production.