Une approche de code d'abord pour déployer des applications sur Kubernetes – Un bon serveur Minecraft

Présentation de Cellery

Qu'est-ce que Cellery et comment peut-il aider au déploiement et à la gestion d'applications sur Kubernetes? Cellery est une approche basée sur le code qui permet de créer, d’intégrer, d’exécuter et de gérer des applications composites sur Kubernetes. Les éléments constitutifs de telles applications composites sont appelés cellules. D'où le nom Cellery, NOT Celery. Pour comprendre les cellules et Cellery, voyons comment une application Kubernetes existante écrite par Google peut être déployée, gérée et observée à l'aide de Cellery. Mais avant d’examiner cette question, commençons par connaître ce que sont les cellules et comment fonctionne Cellery.

Qu'est-ce qu'une cellule?

Voyons pourquoi il est intéressant d’avoir des composants composites dans une architecture de microservices.

Les microservices sont un choix courant pour la construction d'applications complexes et évolutives avec un temps de production inférieur et une capacité d'innovation plus rapide. Chaque service peut être développé indépendamment par une équipe concentrée sur ce service et est libre de choisir les technologies qui lui conviennent. Surtout, les microservices sont réutilisables et chaque service peut être mis à l’échelle indépendamment, permettant aux équipes d’utiliser une infrastructure de déploiement optimisée qui correspond le mieux aux besoins en ressources du service. Les développeurs peuvent apporter des modifications locales à leur service et les déployer dès qu'ils ont été testés. Alors, quels sont les défis?

L'utilisation de microservices (y compris les fonctions sans serveur) se développe rapidement, car les entreprises cherchent à accélérer le développement et à améliorer l'évolutivité. Elles doivent également s'adapter aux équipes axées sur les capacités de l'entreprise. Dans une entreprise comptant des dizaines, voire des centaines d'applications, gérer autant de microservices à couplage lâche est non seulement un cauchemar opérationnel, mais pose également des problèmes en termes de communication d'équipe, de découverte, de contrôle de version et d'observabilité des services. Il y a plus de services, plus de voies de communication, des dispositions de mise en réseau beaucoup plus compliquées et davantage de domaines de défaillance potentielle. Cela crée un besoin de constructions de niveau supérieur, qui agrègent plusieurs microservices et fonctions sans serveur en blocs de construction facilement gérables et réutilisables.

L'architecture à base de cellules, modèle d'architecture de microservices, propose de regrouper les microservices, les données et les autres composants fonctionnels d'un système (y compris les applications frontales, les services hérités, les courtiers, les passerelles et les adaptateurs des systèmes hérités), de manière cohésive. unités d'architecture déployable, appelées cellules.

Ce regroupement de composants est généralement effectué en fonction de la portée, de la propriété et des interdépendances entre ces composants. Chaque cellule doit être conçue et développée individuellement et doit pouvoir être déployée, gérée et observée de manière indépendante. De plus, les composants à l'intérieur de la cellule peuvent communiquer entre eux à l'aide de transports pris en charge pour la communication intra-cellulaire. Cependant, toutes les demandes de service entrantes doivent d'abord passer par la passerelle de cellules, qui fournit des API, des événements ou des flux sécurisés via des points de terminaison de réseau régis à l'aide de protocoles de réseau standard. Les équipes peuvent s'auto-organiser pour produire des cellules qui sont déployées en permanence et mises à jour progressivement. Vous trouverez ci-dessous une représentation d'une cellule simple dans une architecture à base de cellules:

(Cliquez sur l'image pour l'agrandir)

Figure 1: Une unité d’architecture autonome: cellule

Une approche pratique de l'architecture à base de cellules

Cellery est conçu pour créer des applications qui suivent les principes de l’architecture cellulaire sur Kubernetes. Avec Cellery, nous pouvons écrire du code pour définir une cellule et ses composants en pointant sur des images de conteneur existantes des microservices constitutifs de la cellule (et d'autres composants) et définir la relation entre ces composants, les dépendances avec d'autres cellules et l'API de cellule (passerelle). . Le code de définition de cellule peut ensuite être utilisé pour produire des images de cellule. En fait, nous pouvons déclencher un pipeline CI / CD après avoir validé le code de définition de cellule dans un référentiel de contrôle de version. Un système CI / CD tel que Jenkins peut créer l’image de cellule, la tester et la transférer dans un référentiel de conteneur. Ensuite, le système CI / CD peut extraire l’image de la cellule et la déployer dans l’environnement de production correspondant. Sans oublier que nous pouvons mettre à jour, mettre à l'échelle et observer les cellules déployées comme n'importe quelle autre application déployée sur Kubernetes.

(Cliquez sur l'image pour l'agrandir)

Figure 2: Le flux de DevOps pour Cellerie

Création de cellules avec Cellery

En un mot, Cellery est une combinaison d'un SDK, d'un environnement d'exécution et d'un framework de gestion. Lorsque vous installez Cellery, vous pouvez exécuter des commandes à l'aide de la CLI de Cellery pour effectuer diverses tâches.

Tout d'abord, vous devez créer un cluster Kubernetes sur votre ordinateur local ou pointer vers un cluster Kubernetes existant en tant qu'environnement d'exécution Cellery. En tapant dans le simple commander cellery Lors de la configuration, vous serez invité à sélectionner vos préférences de déploiement via une interface de ligne de commande interactive et Cellery configurera le cluster Kubernetes pour vous en fonction de vos préférences.

Une fois l'environnement d'exécution Cellery configuré, vous pouvez commencer à coder des cellules avec le langage Cellery. Le langage Cellery est basé sur le langage de programmation Ballerina et est donc livré avec le support IDE via VSCode et IntelliJIdea. Pour générer automatiquement un fichier de définition de cellule avec les instructions d'importation standard et les fonctions requises, vous pouvez utiliser le cellery init commander. Ensuite, vous pouvez définir les composants, terminer la construction et exécuter la logique à l'aide du langage Cellery. Le compilateur Cellery compilera ensuite le code et créera les artefacts Kubernetes correspondants avec un simple script. cellery construire commander.

Pour déployer les cellules dans l'environnement d'exécution Cellery, exécutez le cellery courir commande avec les paramètres nécessaires. Vous pouvez envoyer une image construite dans un référentiel d’images de cellule avec le cellery pousser commande, extraire une image de cellule d'un référentiel avec le cellery tirer commande et intégrer les flux de génération et de déploiement dans un pipeline CI / CD. De plus, vous pouvez voir une représentation visuelle de la cellule à travers le cellery vue commander. Cellery offre également des fonctionnalités permettant de tester l'observabilité des cellules et des outils permettant de surveiller, de consigner et de suivre les cellules.

Pourquoi Cellery? Pourquoi ne pas configurer un déploiement Kubernetes pour les cellules avec YAML?

Pour les organisations qui ont adopté des conteneurs, les développeurs doivent non seulement créer des microservices, mais également comprendre les nuances d'un système d'orchestration de conteneurs tel que Kubernetes. En outre, la création d'une CBA à partir de rien implique des tâches telles que la configuration d'un maillage de service, la gestion de l'authentification de service et la configuration de politiques de sécurité conformes aux principes de la CBA, en plus de l'approvisionnement des clusters Kubernetes et de la création, du déploiement et de la gestion d'applications. Par conséquent, la configuration de cellules avec des ressources Kubernetes standard nécessite une expertise sérieuse de Kubernetes.

De plus, les ressources Kubernetes, telles que les pods, les services et les déploiements, sont créées de manière déclarative à l'aide de fichiers YAML. Ainsi, à mesure que les déploiements prennent de l'ampleur, les équipes de DevOps doivent faire face à des lignes de code YAML de plus en plus complexes et de plus en plus complexes, sans le support d'EDI sophistiqués pour les rendre productifs. De plus, de par sa nature, YAML encourage la répétition d’énormes morceaux de code en raison de l’absence de prise en charge de concepts de programmation tels que les fonctions, les abstractions et l’encapsulation. Ainsi, la création de déploiements complexes sur Kubernetes signifie que les équipes de DevOps doivent suivre le processus fastidieux et intimidant d’écriture et de maintenance de fichiers YAML pouvant durer des milliers de lignes. Cela peut être très sujet aux erreurs.

Pour définir les déploiements, Cellery utilise non seulement le code YAML, mais son code de sécurité, et respecte le type. Il prend également en charge les complexités sous-jacentes de la configuration du déploiement, du câblage entre les cellules, des services, de la mise à l'échelle automatique, etc. par défaut via des mécanismes de sécurité tels que l'authentification unique, les jetons, le contrôle d'accès basé sur des règles et mTLS. Cellery est conçu autour des pratiques de DevOps afin que la création, le transfert, l'extraction, le test, le déploiement et la mise à jour à l'aide de déploiements bleu / vert et canary puissent être effectués de manière transparente. Les déploiements sont également observables avec surveillance et traçage.

En bref, Cellery vise à simplifier la configuration, la construction, les tests et le déploiement d'applications sur Kubernetes. Comme expliqué ci-dessus, le projet a tenté de résoudre ce problème sous différents angles: développement, DevOps, sécurité et observabilité.

Utiliser Cellery: Un exemple

Jetons un coup d’œil à un exemple de microservices du monde réel que vous pouvez essayer vous-même. (Pour apprendre à coder des cellules avec Cellery, vous pouvez vérifier la syntaxe de Cellery et essayer quelques exemples.)

À cette fin, nous avons utilisé l’application de démonstration «Hipster Shop» de Google. Vous trouverez ici tous les détails, le code source, les fichiers Docker, etc., de l’application de démonstration originale de Hipster Shop. Cet exemple est compatible avec Cellery version 0.3.0.

L'application Hipster Shop est une application de microservices multi-niveaux et polyglottes, qui est une application de commerce électronique basée sur le Web. Les utilisateurs peuvent parcourir les éléments, les ajouter au panier et les acheter à l'aide de l'application. Hipster Shop est composé d’un frontal et de plusieurs microservices, qui communiquent les uns avec les autres via gRPC. L'architecture du service est illustrée à la figure 3 et les descriptions des microservices de Hipster Shop figurent au tableau 1.

(Cliquez sur l'image pour l'agrandir)

Figure 3: Architecture de service de l'application Hipster Shop

Tableau 1: Services existants de l'application Hipster Shop

Afin de mapper les microservices de Hipster Shop sur une architecture à base de cellules, nous avons regroupé les microservices en cinq cellules: annonces, produits, panier, paiement, et l'extrémité avant. Nous avons conçu cette catégorisation en fonction des tâches individuelles effectuées par chaque microservice et de la manière dont il est étroitement lié au reste des microservices d'une cellule. Une cellule appartiendra à une seule équipe, mais une équipe peut posséder une ou plusieurs cellules. La définition des limites de cellules peut être basée sur d'autres critères, tels que le nombre de connexions composant-composant, et ne se limite pas à la fonctionnalité et à la propriété. En savoir plus sur la granularité cellulaire ici.

Il est également important de noter qu’aucun des microservices originaux de Hipster Shop n’a été modifié pour fonctionner avec Cellery; Cellery fait simplement référence aux images de conteneur existantes des microservices. Les cellules et leurs composants respectifs sont énumérés dans le tableau 2 et décrits dans la figure 4 ci-dessous.

Tableau 2: Services Hipster Shop mappés aux cellules

(Cliquez sur l'image pour l'agrandir)

Figure 4: Architecture cellulaire de l'application Hipster Shop

La cellule l'extrémité avant contient l'application frontale en tant que composant unique et le trafic HTTP est autorisé vers la cellule via sa passerelle. l'extrémité avant parle au reste des cellules sur gRPC.

La cellule check-out est la seule autre cellule de cette architecture qui communique avec des cellules externes: des produits et Chariot, tandis que le reste des cellules, produits, annonces, et Chariot sont des cellules indépendantes, dans lesquelles seules les communications internes entre leurs composants ont lieu. Vous trouverez ici tous les fichiers de définition de cellule complets (fichiers avec l'extension .bal) ainsi que les instructions permettant d'exécuter et de déployer les cellules Hipster Shop. Veuillez noter que cet exemple a été testé sur la version 0.3.0 de Cellery.

Créer une cellule simple

Jetons un coup d’œil au code de les publicités, qui contient un seul composant: adservice

ads.bal

importer ballerine / config;
importer celleryio / cellery;

la fonction publique build (cellery: ImageName iName) renvoie une erreur? 
   int adsContainerPort = 9555;
   // composant de service publicitaire
   // Ce composant fournit des annonces textuelles basées sur des mots de contexte donnés.
   cellery: Component adsServiceComponent = 
       nom: "annonces",
       la source: 
           image: "gcr.io/google-samples/microservices-demo/adservice:v0.1.1"
       ,
       entrées: 
           grpcIngress: 
           backendPort: adsContainerPort,
           gatewayPort: 31406
       
       ,
       envVars: 
           PORT: 
               valeur: adsContainerPort
           
       
   ;

   // Initialisation de cellule
   cellery: CellImage adsCell = 
       Composants: 
           adsServiceComponent: adsServiceComponent
       
   ;
   retour cellery: createImage (adsCell, untaint iName);

fonction publique exécutée (cellery: ImageName iName, map instances) renvoie une erreur? 
   cellery: CellImage adsCell = vérifier cellery: constructCellImage (untaint iName);
   retour cellery: createInstance (adsCell, iName, instances);

Tout d'abord, une définition de cellule commencera par les instructions d'importation standard et contiendra deux fonctions: construire et courir (ceux-ci sont générés automatiquement si vous utilisez le cellery init commander). le construire Les fonctions function et run seront invoquées lorsqu'un utilisateur exécute cellery construire et cellery courir commandes respectivement.

Dans la fonction de construction, un composant nommé composant adService est défini pour représenter adservice en pointant sur son URL d'image publique Docker (la source) et définissant ses points d'entrée accessibles par le réseau (entrées) et variables d’environnement (envVars). Ensuite, une cellule est initialisée et définie sous le nom adsCell, et la définition précédemment définie composant adService est ajouté à sa liste de composants. Ensuite, une image de cellule est créée avec le procédé cellery:créer une image.

Enfin, la fonction run prendra l’image de la cellule construite (cellery: NomImage mon nom), qui contient à la fois l'image de la cellule et le nom de l'instance correspondante, et crée une instance en cours d'exécution à partir de l'image de la cellule avec la méthode cellery: createInstance.

Communication inter-composant (intra-cellule) au sein d'une cellule

Maintenant que nous avons vu la structure de code d’un fichier de cellule de base, examinons le code d’une cellule qui a deux composants ou plus et comment ces composants sont configurés pour communiquer entre eux.

La cellule des produits a deux composantes: catalogues de produits et service de recommandations. Comme le montre la figure 4, service de recommandations a besoin de parler catalogues de produits parce qu'il recommande des produits en fonction des produits inclus dans le panier. La communication entre les composants d'une cellule est activée via des variables d'environnement.

Comme indiqué dans l'extrait de code ci-dessous, recommendationServiceComponent attend l'adresse du productCatalogServiceComponent à travers la variable d'environnement (envVars) PRODUCT_CATALOG_SERVICE_ADDR. Aditionellement, productCatalogServiceComponent est étiqueté comme une dépendance sous la les dépendances domaine, qui assure que productCatalogServiceComponent est opérationnel pour résoudre les dépendances.

produits.bal

..
 // composant de service de recommandation
 // Recommande d'autres produits en fonction de ce qui est indiqué dans le panier.
 cellery: Composant recommendationServiceComponent = 
     nom: "recommandations",
     la source: 
        image: "gcr.io/google-samples/microservices-demo/recommendationservice:v0.1.1"
     ,
     entrées: 
        grpcIngress: 
        backendPort: recommendationsContainerPort,
        passerelle Port: 31407
       
     ,
     envVars: 
        PORT: 
            valeur: recommendationsContainerPort
        ,
        PRODUCT_CATALOG_SERVICE_ADDR: 
            valeur: cellery: getHost (productCatalogServiceComponent) + ":" + productCatalogContainerPort
        ,
        ENABLE_PROFILER: 
            valeur: 0
        
     ,
     dépendances: 
        Composants: [productCatalogServiceComponent]
     
   ;
 ..

La cellule est initialisée et définie par le nom produitsCell, et les deux productCatalogServiceComponent et recommendationServiceComponent sont ajoutés à la liste des composants, comme indiqué dans l'extrait de code ci-dessous.

..
   // Initialisation de cellule
   cellery: CellImage productsCell = 
       Composants: 
           productCatalogServiceComponent: productCatalogServiceComponent,
           recommendationServiceComponent: recommendationServiceComponent
       
   ;
..

Communication intercellulaire

Maintenant que nous avons abordé la communication inter-composants, voyons comment les composants d’une cellule peuvent communiquer avec les composants d’une autre cellule. Nous savons déjà que l’ABC stipule que toutes les communications entrantes externes doivent passer par la passerelle cellulaire. Alors, examinons le code de la cellule l'extrémité avant, dont l’application Web frontale est le seul composant et doit communiquer avec divers composants résidant dans différentes cellules.

front-end.bal

..
   cellery: Composant frontEndComponent = {
       nom: "front-end",
       la source: 
           image: "gcr.io/google-samples/microservices-demo/frontend:v0.1.1"
       ,
       entrées: 
           portail:  // Web ingress est exposé globalement.
           port: frontEndPort,
           gatewayConfig: 
               vhost: "my-hipstershop.com",
               le contexte: "/"
               
           
       ,
..

Le code ci-dessus montre comment frontEndComponent expose un serveur HTTP pour desservir le site Web Hipster Shop. Le même composant attend les valeurs de plusieurs variables d'environnement afin de pouvoir communiquer avec les microservices internes et externes pertinents. Jetons un coup d’œil au code qui permet frontEndComponent parler aux composants de des produits cellule.

envVars: 
    ..
    PRODUCT_CATALOG_SERVICE_ADDR: 
      valeur: ""
    ,
    RECOMMENDATION_SERVICE_ADDR: 
      valeur: ""
    ,
    ..
,

Comme indiqué dans l'extrait de code ci-dessus, frontEndServiceComponent attend les adresses des productCatalogServiceComponent et recommendationServiceComponent à travers les variables d'environnement (envVars) PRODUCT_CATALOG_SERVICE_ADDR et RECOMMENDATION_SERVICE_ADDR respectivement.

dépendances: 
    cellules: 
productsCellDep: org: "wso2cellery", nom: "products-cell", ver: "latest",
..
 
      

le l'extrémité avant la cellule dépend de des produits cellule, et cette dépendance est définie via le les dépendances champ dans le frontEndComponent Comme montré ci-dessus.

cellery: Reference productReference = cellery: getReference (frontEndComponent, "productsCellDep");

frontEndComponent.envVars.PRODUCT_CATALOG_SERVICE_ADDR.value = productReference.gateway_host + ":" +productReference.products_grpc_port;

frontEndComponent.envVars.RECOMMENDATION_SERVICE_ADDR.value = productReference.gateway_host + ":" +productReference.recommendations_grpc_port;

La méthode cellery: getReference (frontEndComponent, "productsCellDep") va nous donner une référence à l'instance de cellule de produits déployés, et en utilisant cette référence, nous pouvons résoudre les valeurs des variables d'environnement PRODUCT_CATALOG_SERVICE_ADDR et RECOMMENDATION_SERVICE_ADDR comme indiqué dans le code ci-dessus. De même, l'extrémité avant cellule communique avec le reste des cellules en suivant l’approche ci-dessus.

Les deux fichiers de définition de cellule restants suivent les mêmes principes et sont disponibles dans le dépôt github.

cart.bal
Chariot cellule est une cellule indépendante à deux composants.

checkout.bal
check-out cellule contient cinq composants et parle à Chariot et des produits cellules afin d'invoquer service de voiture et catalogues de produits respectivement de service de caisse.

Maintenant que nous avons terminé de coder toutes les définitions de cellules, nous pouvons créer et déployer ces cellules. Vous pouvez également comparer le fichier complet Kubernetes YAML requis pour déployer les microservices de Hipstershop avec le code Hipstershop Cellery, dans lequel ce dernier déploie non seulement les microservices sur Kubernetes, mais crée également une architecture cellulaire autour de ces microservices.

Construction et déploiement de cellules

Suivez les instructions fournies ici pour créer et exécuter toutes les cellules de Hipster Shop.

Exécution de cellules indépendantes

Voyons maintenant comment nous pouvons construire et exécuter les publicités cellule, qui est une cellule indépendante.
Ouvrez un terminal où le les publicités.bal fichier réside et exécutez la commande suivante pour construire le les publicités cellule:

$ cellery build ads.bal wso2cellery / ads-cell: dernière

Le nom de notre organisation dans Docker Hub est wso2celleryet nous avons utilisé cellule-annonces comme nom de l'image de la cellule et dernier comme la balise. La sortie suivante peut être vue après l'exécution de la commande de construction:

✔ image de bâtiment wso2cellery / ads-cell: dernière
✔ Suppression de l'ancienne image
✔ Enregistrement d'une nouvelle image dans le référentiel local


✔ Image de cellule construite avec succès: wso2cellery / ads-cell: dernière

Et après?
-------------------------------------------------- ------
Exécutez la commande suivante pour exécuter l'image:
  $ cellery run wso2cellery / ads-cell: dernière
-------------------------------------------------- ------

Pour exécuter l'image de la cellule wso2cellery / ads-cell:dernier avec le nom de l'instance cellule-annonces, exécutez la commande suivante:

$ cellery run wso2cellery / ads-cell: dernière -n ads-cell

La sortie suivante peut être observée:

✔ Extraction de l'image de la cellule wso2cellery / ads-cell: dernière

Instance principale: ads-cell

✔ Reading Cell Image wso2cellery / ads-cell: dernière
✔ Validation des dépendances

Instances à utiliser:


  INSTANCE NOM CELLULE IMAGE UTILISÉE INSTANCE PARTAGÉE
 --------------- ----------------------------- ------ --------- --------
  ads-cell wso2cellery / ads-cell: le dernier To be Created -

Arbre de dépendance à utiliser:

 Pas de dépendances

? Souhaitez-vous continuer en commençant au-dessus des instances de cellules (Y / n)? y

✔ Cellule de l'instance principale de départ


✔ Image de cellule déployée avec succès: wso2cellery / ads-cell: dernière

Et après?
-------------------------------------------------- ------
Exécutez la commande suivante pour répertorier les cellules en cours d'exécution:
  $ instances de liste cellery
-------------------------------------------------- ------   

Exécution de cellules dépendantes

Voyons maintenant comment construire et exécuter une cellule qui dépend d’autres cellules. Prenons l'extrémité avant cellule comme notre exemple. La commande de construction sera similaire à la commande que nous avons exécutée pour les publicités cellule.

$ cellery build front-end.bal wso2cellery / front-end-cell: dernières

Toutefois, lorsque vous exécutez une image de cellule avec des dépendances, vous devez également répertorier les noms des instances en cours d'exécution des autres cellules dont dépend la cellule. Ceci peut être vu dans la commande d'exécution pour l'extrémité avant cellule, comme indiqué ci-dessous.

$ cellery run wso2cellery / front-end-cell: dernière -n front-end-cell -l cartCellDep: cart-cell -l produitsCellDep: produits-cell -l adsCellDep: ads-cell -l checkoutCellDep: checkout-cell -d

La sortie sera comme suit:

✔ Extraction de la cellule Image wso2cellery / front-end-cell: dernière

Instance principale: cellule front-end

✔ Reading Cell Image wso2cellery / front-end-cell: dernière
Utilisation d'une instance cart partagée d'instance pour un alias dupliqué cartCellDep
Utilisation d'une cellule de produits d'instance partagée pour l'alias dupliqué productsCellDep
✔ Validation des liens de dépendance
✔ Génération d'un arbre de dépendance
✔ Validation de l'arbre de dépendance

Instances à utiliser:

  INSTANCE NOM CELLULE IMAGE UTILISÉE INSTANCE PARTAGÉE
 ---------------- ---------------------------------- - ---------------------- --------
  checkout-cell wso2cellery / checkout-cell: dernière disponible en exécution -
  produits-cell wso2cellery / products-cell: dernière disponible en exécution partagée
  ads-cell wso2cellery / ads-cell: dernière disponible en exécution -
  cart-cell wso2cellery / cart-cell: dernière disponible en exécution partagée
  front-end-cell wso2cellery / front-end-cell: dernier à être créé -

Arbre de dépendance à utiliser:

 cellule frontale
   ├── checkoutCellDep: cellule de caisse
   ├── productsCellDep: produits-cell
   ├── adsCellDep: ads-cell
   └── cartCellDep: cart-cell

? Souhaitez-vous continuer en commençant au-dessus des instances de cellules (Y / n)? y

✔ Dépendances de départ
✔ Cellule frontale d'extrémité principale de démarrage


✔ Image de cellule déployée avec succès: wso2cellery / front-end-cell: dernière

Et après?
-------------------------------------------------- ------
Exécutez la commande suivante pour répertorier les cellules en cours d'exécution:
  $ instances de liste cellery
-------------------------------------------------- ------

Nous pouvons également afficher la représentation graphique d'une cellule unique ainsi que ses dépendances à l'aide de la commande view. Par exemple, pour voir l'extrémité avant cellule, tapez la commande suivante:

cellery vue wso2cellery / front-end-cell: dernier

Cela nous donne une page Web décrivant l'extrémité avant cellule comme indiqué à la figure 5.

(Cliquez sur l'image pour l'agrandir)

Figure 5: Une représentation graphique générée de "front-end"

Observabilité

Pour surveiller et dépanner les cellules déployées, Cellery fournit des outils d’observabilité, notamment un tableau de bord. Le tableau de bord Cellery affiche de nombreuses vues des cellules, notamment des diagrammes de dépendance, des métriques d'exécution des cellules et un traçage distribué de bout en bout des demandes transitant par les passerelles et les composants de la cellule. Toutes les métriques sont collectées à partir des composants et des passerelles. Elles incluent les métriques système relatives aux pods et aux nœuds Kubernetes (y compris l'utilisation du processeur, de la mémoire, du réseau et du système de fichiers) et les métriques demande / réponse (métrique d'application).

(Cliquez sur l'image pour l'agrandir)

(Cliquez sur l'image pour l'agrandir)

Figure 6: Cellerie observabilité tableau de bord

Avez-vous vraiment besoin de cellier?

Si vous souhaitez obtenir une réponse à cette question, vous devrez également vous demander si votre projet de microservices sera basé sur le cloud et s'il évoluera avec le temps. Si la réponse est oui, vous devrez garder à l'esprit que la gestion de centaines de microservices faiblement couplés peut rapidement devenir un cauchemar. C'est pourquoi l'architecture à base de cellules a été conçue, mais créer une CBA sur une plate-forme d'orchestration de conteneur telle que Kubernetes à partir de zéro en utilisant YAML n'est en aucun cas une tâche facile. C'est là que Cellery entre en jeu pour permettre aux développeurs de suivre une approche axée sur le code d'abord et de gérer les complexités sous-jacentes de la mise en œuvre d'une CBA, leur permettant ainsi de tirer pleinement parti des avantages des microservices en nuage et d'éviter leurs pièges.

Vous pouvez trouver du contenu plus intéressant et du matériel d'apprentissage sur le site Web Cellery et le référentiel GitHub.

A propos de l'auteur

Dakshitha Ratnayake est un architecte d’entreprise à WSO2 avec plus de 10 ans d’expérience dans le développement de logiciels, l’architecture de solutions et la technologie middleware. Ceci est le premier article de l'auteur pour InfoQ.