Optimiser les workflows asynchrones en intégrant la file d'attente OCI aux fonctions OCI

Le service Oracle Cloud Infrastructure (OCI) Queue vous permet d'envoyer des messages entre les systèmes de manière asynchrone, ce qui vous permet de découpler vos systèmes et d'améliorer leurs performances. Il est conçu pour gérer des volumes importants de données transactionnelles et garantit que les messages sont traités sans perte ni duplication.

Le service OCI Queue est entièrement géré et s'adapte automatiquement en fonction du débit des producteurs et des consommateurs, en utilisant des normes ouvertes pour prendre en charge la communication avec n'importe quel client ou producteur avec un effort minimal. Les applications sans serveur reposent souvent sur une combinaison de différents services (API Gateway, Functions, etc.) pour fonctionner correctement. Toutefois, pour que ces composants distribués communiquent entre eux, le service File d'attente est essentiel. Elle permet également à votre application d'étendre la communication à d'autres composants OCI ou même en dehors d'OCI.

Architecture

Cette architecture de référence déploie un exemple d'application Python vers Oracle Container Engine for Kubernetes (OKE), qui interroge régulièrement la file d'attente configurée pour extraire les nouveaux messages, appelle une fonction configurée à l'aide des messages extraits et, en cas de réussite de l'exécution, supprime les messages de la file d'attente.

L'application s'authentifie en tant que instance_principal lorsqu'elle interagit avec les services OCI. La file d'attente et les fonctions peuvent se trouver dans n'importe quelle région, et les OCID de file d'attente et de fonction doivent être spécifiés lors de la création de la pile. S'il est nécessaire de mettre à jour les OCID de file d'attente et de fonction après le déploiement Terraform, vous pouvez modifier l'artefact de déploiement Kubernetes (partie du projet OCI DevOps créé).

Le déploiement Terraform inclut la création des pipelines et des référentiels nécessaires dans un service OCI DevOps afin d'automatiser les étapes requises pour mettre en production le code source de l'application. Le code source de l'application est hébergé sur un référentiel de code DevOps. L'utilisateur peut ensuite valider le code dans le référentiel, ce qui déclenche le démarrage d'un pipeline de build.

Le diagramme suivant illustre cette architecture de référence.

Description de l'image queue_fn_automation_arch.png

Description de l'illustration queue_fn_automation_arch.png

queue-fn-automation-arch-oracle.zip

L'architecture comprend les composants suivants :

Région
Une région Oracle Cloud Infrastructure est une zone géographique localisée qui contient des centres de données, appelés domaines de disponibilité. Les régions sont indépendantes des autres régions et de vastes distances peuvent les séparer (dans tous les pays ou même les continents).
Projet DevOps
Regroupement logique de ressources DevOps nécessaires pour implémenter un workflow d'intégration continue et de déploiement continu. Les ressources DevOps peuvent être des artefacts, des pipelines de build, des pipelines de déploiement, des connexions externes, des déclencheurs et des environnements. Les projets DevOps facilitent l'activation de la journalisation, de la surveillance et des notifications pour toutes vos ressources DevOps.
Pipeline de build
Un pipeline de build prend un ID de validation à partir des référentiels de code source et utilise ce code source pour exécuter les instructions de build. Les pipelines de build définissent un ensemble de phases pour le processus de build : création, test et compilation d'artefacts logiciels, distribution d'artefacts aux référentiels OCI et déclenchement éventuel d'un déploiement. Vous pouvez définir le flux et les instructions de votre exécution de build dans le fichier de spécification de build.
Référentiel de code
Référentiels Git privés hébergés par le service DevOps. Vous pouvez stocker, gérer et développer du code source avec les référentiels de code OCI DevOps.
Pipeline de déploiement
Séquence d'étapes de distribution et de déploiement d'un ensemble d'artefacts vers un environnement cible. Le flux et la logique de votre version logicielle peuvent être contrôlés en définissant des étapes pouvant être exécutées en série ou en parallèle.
Phases de déploiement
Les phases sont des actions individuelles qui ont lieu pendant l'exécution d'un pipeline. Le pipeline de déploiement DevOps inclut les types de phase prédéfinis suivants que vous pouvez utiliser dans votre processus de publication :
- Déploiement non simultané : version incrémentielle vers OKE, Functions ou groupes d'instances.
- Wait : Wait N seconds.
- Approbation manuelle : Continuez si l'approbation est donnée ; arrêtez si l'approbation est rejetée.
- Appeler une fonction : Effectuer des tâches ou des intégrations personnalisées en appelant une fonction et en transmettant un artefact des paramètres de demande.
Artefact DevOps
Un artefact DevOps est une référence ou un pointeur vers un fichier, un fichier binaire, un package, un manifeste ou une image qui constitue votre application. Lors de la création d'un artefact, informez Oracle DevOps de l'emplacement source de l'artefact réel. DevOps prend en charge les référentiels OCI Container Image Registry et OCI Artifact Registry.
Services OCI Logging et Notification
Le service OCI Logging stocke les journaux liés au déploiement. La sortie d'exécution du déploiement et les résultats finaux du déploiement sont affichés en tant qu'entrées de journal. Le service OCI Notifications fournit une visibilité sur l'état le plus récent du projet de déploiement et de ses ressources, et prend toutes les mesures nécessaires. Par exemple, vous êtes averti lorsqu'un événement important, tel qu'une phase d'un pipeline de déploiement en attente d'approbation. Lorsque vous recevez le message de notification, vous pouvez accéder au pipeline de déploiement DevOps et approuver la phase.
Environnements de déploiement
Un environnement est un ensemble de ressources informatiques d'un client dans lesquelles des artefacts sont déployés. Les environnements peuvent être une fonction, une machine virtuelle de calcul, une instance Bare Metal ou un cluster OKE.
- Cluster OKE : OCI Container Engine for Kubernetes est un service entièrement géré, évolutif et hautement disponible que vous pouvez utiliser pour déployer vos applications en conteneur vers le cloud.
- Instances de calcul : le service OCI Compute vous permet de provisionner et de gérer des hôtes Compute dans le cloud. Vous pouvez déployer des instances Compute avec des formes correspondant aux besoins en ressources en matière d'UC, de mémoire, de bande passante réseau et de stockage.
- Fonctions : Oracle Functions est une plate-forme de services en tant que service entièrement gérée, colocative, hautement évolutive et à la demande. Ce service s'appuie sur Oracle Cloud Infrastructure pour les entreprises et s'appuie sur le moteur open source du projet Fn.
Les environnements peuvent se trouver dans des régions OCI différentes de celles du pipeline de déploiement. Cette séparation permet aux développeurs de déployer plusieurs régions OCI à l'aide du même pipeline de déploiement.
Stratégies et groupes dynamiques IAM
Un groupe dynamique est un type spécial de groupe contenant des ressources (telles que des instances de calcul) qui correspondent aux règles que vous définissez (l'appartenance peut donc changer dynamiquement lorsque des ressources correspondantes sont créées ou supprimées). Ces instances agissent comme des acteurs "principaux" et peuvent effectuer des appels d'API vers des services en fonction des stratégies que vous écrivez pour le groupe dynamique.

Une stratégie est un document qui indique qui peut accéder à quelles ressources et comment. L'accès est accordé au niveau du groupe et du compartiment. Vous pouvez donc écrire une stratégie qui offre à un groupe un type d'accès spécifique au sein d'un compartiment précis ou à la location elle-même.

Recommandations

Utilisez les recommandations suivantes comme point de départ. Vos besoins peuvent différer de l'architecture décrite ici.

Déploiement
Lors du déploiement de l'architecture via Resource Manager, conservez autant que possible les valeurs par défaut si aucune modification explicite n'est requise.

Considérations

Lors du déploiement de la solution et de l'utilisation de l'application, tenez compte des aspects suivants :

Déploiement de la solution
Des privilèges d'administration sont requis pour configurer les groupes dynamiques requis et les stratégies associées. Le nom utilisateur et le jeton d'authentification OCI sont requis pour l'autorisation du référentiel OCI DevOps Git et la configuration des clés secrètes dans OKE.
Utilisation de l'application
L'ajustement des paramètres d'application Python peut être traité dans le projet DevOps créé en modifiant les variables au début du programme queue_automation.py et en configurant la clé secrète OCIR dans OKE.

Déployer

Le code Terraform de ce déploiement, ainsi que le code source de l'application Python, sont disponibles sur GitHub.

Cliquez sur .
Si vous n'êtes pas déjà connecté, entrez les informations d'identification de la location et de l'utilisateur.
Sélectionnez la région dans laquelle déployer la pile.
Suivez les invites à l'écran et les instructions pour créer la pile.
Après avoir créé la pile, cliquez sur Actions Terraform et sélectionnez Planifier.
Attendez que le travail soit terminé et vérifiez le plan.
Pour apporter des modifications, revenez à la page Détails de la pile, cliquez sur Modifier la pile et apportez les modifications requises. Exécutez ensuite à nouveau l'action Planifier.
Si aucune autre modification n'est nécessaire, revenez à la page Détails de la pile, cliquez sur Actions Terraform et sélectionnez Appliquer.

En savoir plus

Consultez ces ressources supplémentaires pour en savoir plus sur les fonctionnalités de cette architecture de référence.

Remerciements

Author: Andrei Ilas