Démarrer RabbitMQ à partir d'un modèle versionné
Utilisez le modèle RabbitMQ 3 avec interface de gestion, créez des identifiants stockés dans des secrets et limitez l’accès au broker aux applications et aux opérateurs qui en ont besoin.
Services de données · offres à partir de $10/mois
Déployer RabbitMQ.Vérifiez le parcours du message de bout en bout.
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.
Conserver le dépôtExaminer la compilation et les journauxDomaines personnalisés et TLS
Déploiement Adios
Version candidate
RabbitMQ
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 à
RabbitMQ 3AMQPFiles de messagesInterface de gestionPersistance
Le parcours de mise en production
Même opérationnel, un projet RabbitMQ 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 ajoute un stockage persistant, mais la durabilité des files d’attente dépend aussi des choix applicatifs concernant les exchanges, les files, les messages, les accusés de réception et les confirmations de publication.
Garder l'état de service visible pour les opérateurs
Publiez et consommez un message représentatif, examinez les accusés de réception et les nouvelles livraisons, puis testez les redémarrages des consommateurs et l’indisponibilité du broker avant le lancement.
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-broker
template: rabbitmq:3-management
env:
RABBITMQ_DEFAULT_USER: app
RABBITMQ_DEFAULT_PASS: secret://RABBITMQ_DEFAULT_PASSStockez le mot de passe du broker dans un secret Adios avant le déploiement et remplacez les identifiants par défaut pour l’utilisation en production.
Points de départ déployables
Démarrer RabbitMQ à partir d'un modèle lorsque le dépôt n'est pas prêt.
Déployez RabbitMQ avec son plugin de gestion, puis connectez un producteur et un consommateur pour vérifier l’ensemble du parcours de la file d’attente.
Services de données
RabbitMQ 3 Management
Un modèle RabbitMQ 3 avec accès à l’interface de gestion.
AMQPGéré par Adios
- Clé du modèle
- rabbitmq:3-management
- Environnement d’exécution
- rabbitmq
- Dépôt
- template-rabbitmq-3-management
- Emplacement de la source
- .
git clone https://github.com/adiosdotdev/template-rabbitmq-3-management.git
cd template-rabbitmq-3-management
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...
- Les identifiants du broker sont stockés dans des secrets.
- Les exchanges, les files d’attente et les bindings sont déclarés de manière reproductible.
- Les consommateurs accusent réception uniquement après un traitement réussi.
- Le comportement des nouvelles tentatives et des files de messages non traités (dead-letter) est documenté.
Prévisualiser quand...
- La durabilité ou la topologie des files d'attente est en train de changer.
- Les consommateurs peuvent traiter le même message plus d'une fois.
- Les files de tâches en attente peuvent dépasser les capacités actuelles de stockage ou de traitement.
Les réponses à vos questions
Ce qu’il faut savoir avant de déployer RabbitMQ.
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 RabbitMQ à partir d’un modèle officiel ?
Oui. Choisissez le modèle RabbitMQ 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 RabbitMQ utilise-t-il un stockage persistant ?
Le modèle ajoute un stockage persistant, mais la durabilité des files d’attente dépend aussi des choix applicatifs concernant les exchanges, les files, les messages, les accusés de réception et les confirmations de publication.
Le modèle inclut-il l’interface de gestion de RabbitMQ ?
Oui. Le modèle actuel rabbitmq:3-management active l’interface de gestion. Protégez son accès et évitez d’exposer les identifiants d’exploitation aux clients de l’application.
Les applications Node.js, Python, Go ou .NET peuvent-elles s’y connecter ?
Oui. Utilisez un client AMQP pour le langage de l’application, injectez les identifiants du broker sous forme de secrets et testez la reconnexion ainsi que les livraisons en double.
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 Redis
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.
Déployer Workflows Adios
Déployez des tâches planifiées, des traitements de webhooks, des étapes d’approbation, des tâches de maintenance et des automatisations opérationnelles à partir d’un manifeste de workflow versionné.
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 Go
Compilez un service Go à partir du dépôt, lancez le binaire de production, vérifiez son endpoint de contrôle de santé et promouvez la version exacte que vous avez examinée.
La première version
Déployer RabbitMQ 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.