|
Etude et mise en place d'un service cloud d'iam basé sur keycloakpar Saratou Diallo Institut Supérieur d'Informatique (ISI) Dakar - Master 2 2022 |
ConclusionUne étude exhaustive de toutes les solutions de gestion des identités et des accès ne pouvant être faite dû à la pluralité des solutions sur le marché. Nous avons, cependant, suite à cette étude, une idée globale et déterminante des services fournis par les différents acteurs du domaine. Qu'il s'agisse de la solution RH-SSO de Redhat, de Okta et Auth0 qui ont fusionné ou de Amazon Cognito d'AWS, le principe reste quasi identique, ils offrent tous un service très bien fait qui répond aux besoins des entreprises de toute taille. FusionAuth quant à elle est l'une des rares solutions pensées pour les développeurs. Nous avons également pu constater qu'à nos jours, ces solutions sont disponibles dans divers paysen dehors de l'Afrique mis à part Auth0 qui est disponible en Guinée-Bissau et en Afrique du Sud. Nous conclurons donc que malgré l'existence d'une multitude de solutions de gestions des identités et des accès, clouds ou natives, le besoin d'une solution cloud de gestion des identités et des accès facilement intégrable par les développeurs et ou les entreprises ou professionnels, dans n'importe quelle application et surtout en afrique, demeure d'actualité. Nous pouvons affirmer que notre plateforme, non seulement trouvera sa place mais plus encore elle se démarquera par sa cible principale: les développeurs, et son emplacement(l'Afrique) qui n'est encore pas ou très peu couvert par les plateformes existantes. 3. Chap 3: Solution ProposéeIntroductionAprès l'état de l'art sur les solutions de gestion des identités et des accès existantes, nous allons, dans ce chapitre, nous intéresser à l'étude de la solution que nous proposons. Nous allons dans un premier temps spécifier les besoins fonctionnels et non fonctionnels du système et identifier les acteurs. Nous procéderons par la suite à l'analyse et la conception des besoins fonctionnels et nous terminerons par la réalisation du système qui enveloppe l'implémentation, le déploiement et les tests de la solution. Dans cette partie nous apporterons également une justification du choix des technologies et outils adoptés pour l'implémentation de la solution. L'analyse de la thématique et des différentes propositions existantes sur le marché ainsi que la compréhension des besoins des utilisateurs a permis de dégager les fonctionnalités qu'offre notre plateforme. Les contraintes auxquelles est soumis le système pour sa réalisation et son bon fonctionnement seront décrites par la suite comme étant des besoins non fonctionnels.
Deux types d'acteurs sont à identifier. Les acteurs qui interagissent directement avec notre système, c'est sont les acteurs principaux et les acteurs qui participent à la réalisation de certaines actions au sein de notre système plus communément appelés les acteurs secondaires. a. Les acteurs qui interagissent directement avec notre système sont: Le développeur: c'est l'acteur qui s'inscrit sur la plateforme et ajoute ses applications. L'app-client: Représente l'application d'un développeur Le end-user: qui est l'utilisateur final de l'application du développeur. Tout au long de l'analyse ces appellations seront conservées. b. Les acteurs secondaires sont les suivants: Keycloak: intervient dans la réalisation de bon nombre des interactions des nos principaux acteurs avec le système. Le système de paiement: qui intervient lors du paiement d'une facture ou lors de l'abonnement à un plan qui inclut le paiement d'une facture de 0 francs. Dans cette partie, nous dégageons l'ensemble des besoins fonctionnels auxquels devra répondre notre solution cloud. Les besoins fonctionnels et les attentes par rapport à notre plateforme varient suivant l'acteur. Les besoins fonctionnels auxquels doit répondre notre plateforme se résume dans les points suivants: Le système doit permettre au client: a. De s'inscrire b. De se connecter c. D'ajouter une application d. De fournir ses utilisateurs e. De voir la liste de ses applications f. De configurer ses applications g. De consulter son activité h. De souscrire à un abonnement mensuel i. De payer que ce qu'il consomme PAYG(Pay As You Go) j. De choisir un mode de paiement k. D'ajouter des utilisateurs l. D'accéder à une console m. D'Activer la fédération des utilisateurs n. De supprimer une application du service o. De mettre fin à son abonnement p. De supprimer son compte Le système doit pouvoir faire les actions suivantes auprès de keycloak: a. S'identifier b. Créer un realm pour chaque utilisateur inscrit c. Créer un client keycloak dans le realm du client inscrit à notre plateforme, à chaque fois que celui ci crée une application d. Ajouter un User Provider pour gérer les utilisateurs d'un client e. Configurer le realm d'un client f. Gérer les utilisateurs, leurs rôles et groupes d'un client g. Modifier un realm h. Supprimer un realm i. Modifier un client j. Supprimer un client Dans cette section, nous dégageons l'ensemble des besoins non fonctionnels auxquels devrait répondre notre plateforme. Il s'agit des besoins qui caractérisent le système. Ce sont des besoins en matière de performance,de type matériel ou de type conceptuel. Ces besoins peuvent concerner les contraintes d'implémentation comme le langage de programmation, le type de la base de données, le type du provider, .... L'ensemble des fonctionnalités à réaliser devront répondre aux besoins suivants: a. Ergonomie de l'interface: L'application doit être facile à utiliser, les interfaces utilisateurs doivent être conviviales c'est à dire simples, ergonomiques et adaptées à l'utilisateur b. Fiabilité: Il s'agit ici de la fiabilité de notre plateforme par rapport aux résultats qu'elle transmet aux clients lorsque ces derniers envoient une requête d'authentification. c. Sécurité: La plateforme qui s'occupe de la sécurité des applications de ses clients doit elle-même répondre aux exigences de sécurité les plus strictes. d. Scalabilité: Notre application doit être capable de fonctionner de manière optimale avec 1 ou 1 000 000 utilisateur(s). La scalabilité d'un service désigne la capacité de l'application et de l'infrastructure à s'adapter automatiquement pour traiter un niveau de sollicitation variable. e. Élasticité: L'élasticité est la capacité d'ajuster les ressources à la hausse ou à la baisse automatiquement. Notre application doit pouvoir ajuster les ressources disponibles entre ses différents utilisateurs à la hausse tout comme à la demande, de façon à ce que chacun ait accès aux ressources nécessaires à ses besoins. f. Résilience: On désigne par résilience la capacité d'un service à continuer de fonctionner malgré la défaillance d'un ou plusieurs composants (base de données, serveurs Web, accès réseau, ... ). La résilience désigne également la capacité du service à revenir dans un mode normal de façon automatisée. Notre application doit être en mesure de fournir son service à ses clients ce même en cas de défaillance d'un ou plusieurs de ses composants. g. Performance : L'application doit être performante c'est-à-dire à travers ses fonctionnalités, répondre à toutes les exigences des usagers d'une manière optimale. h. Mesurable: Le principe des plateformes cloud est le Pay As You Go c'est-à-dire que l'utilisateur ne paye que ce qu'il consomme et pour cela il doit être possible de mesurer sa consommation auprès de son fournisseur. Une identification et une analyse méticuleuse des besoins fonctionnels est indispensable pour la réalisation d'une conception qui répond aux exigences de notre plateforme. a. Diagramme de cas d'utilisation La connaissance des fonctionnalités à implémenter nous a permis d'établir le diagramme de cas d'utilisation de la plateforme. Nous avons élaboré un diagramme de cas d'utilisation global dans lequel nous avons représenté des packages pour un souci de transparence et de lisibilité. Chaque package sera représenté de façon détaillée par la suite.
Figure 3.1: Diagramme de cas d'utilisation globale de l'application Nous avons jugé nécessaire de représenter les actions que notre système aura sur celui de keycloak dans un diagramme à part. Figure suivante.
Figure 3.2: Diagramme de cas d'utilisation illustrant les actions de notre système keycloak Par la suite nous allons montrer les diagrammes détaillés de chaque package de notre diagramme de cas d'utilisation globale.
Figure 3.3: Package Abonnement
Figure 3.6: Package Application
Figure 3.7: Package AppRequest
Figure 3.8: Package Authentication
? Diagramme de séquence Authentification
Figure 3.10: Diagramme de séquence Authentification ? Diagramme de séquence paiement: Scénario
Table 3.1: Scénario de Payement
Figure 3.11: Diagramme de séquence Payement ? Diagramme de séquence Abonnement Scénario : Abonnement
Table 3.2: Scénario Abonnement
Figure 3.12: Diagramme de séquence Abonnement ? Diagramme de séquence Ajout des utilisateurs Scénario Ajout des utilisateurs
Table 3.3: Scénario Ajout des utilisateurs
Figure 3.13: Diagramme de séquence AddUsers ? Diagramme de séquence Envoie d'une requête d'authentification Scénario Envoie d'une requête d'authentification
Table 3.4: Scénario Envoie d'une requête d'authentification
Figure 3.14: Diagramme de séquence requête d'authentification ? Diagramme de séquence Ajout d'une application
Figure 3.15: Diagramme de séquence AddApplication Le diagramme de classe nous a permis d'identifier les différentes entités de notre système et leurs relations.
Figure 3.16: Diagramme de classe d. Architecture de la solution L'architecture d'un projet est vitale pour la vie du projet lui-même et comment celui-ci sera en mesure de faire face à l'évolution des nouveaux besoins à l'avenir. Les avantages d'une architecture propre et bien pensée sont nombreuses, en voici quelques unes: a. Une architecture bien pensée nous permet d'obtenir un code propre et lisible b. Dans une bonne architecture, les morceaux de code sont réutilisables dans l'application c. On peut éviter les répétitions en mettant en place une architecture adaptée. d. L'évolution d'une application dont l'architecture est bien pensée est beaucoup plus facile. Dans ce projet, nous avons opté pour une architecture trois tiers. L'idée est d'utiliser le principe de séparation des préoccupations pour éloigner la logique métier des routes de l'application.
Figure 3.17: Architecture 3-tiers La couche de données: Dans l'architecture 3-tiers, comme en MVC, la couche donnée réside dans ses propres modules. Le but est de découper la logique métier des opérations de base de données. Ainsi, il est possible de faire évoluer le métier et la base de données séparément. La couche métier: Cette couche implémente les algorithmes "métier" de l'application. Elle est indépendante de toute forme d'interface avec l'utilisateur. Ainsi elle doit être utilisable aussi bien avec une interface console, une interface web, une interface de client riche. Elle doit ainsi pouvoir être testée en dehors de l'interface web et notamment avec une interface console. C'est généralement la couche la plus stable de l'architecture. Elle ne change pas si on change l'interface utilisateur ou la façon d'accéder aux données nécessaires au fonctionnement de l'application. La couche de présentation: Cette couche est l'interface (graphique le plus souvent) qui permet à l'utilisateur de piloter l'application et d'en recevoir des informations. Établissement des règles Nous pouvons maintenant discuter de ce qu'on appelle habituellement le flux de la structure de l'application. Le flux de la structure applicative est un ensemble des règles et des pratiques courantes à adopter lors du développement d'une application. Express.js est un excellent framework pour node.js, mais il ne vous donne aucune indication sur la manière d'organiser votre projet node.js, c'est sont donc là, les résultats d'une recherche approfondie sur les méthodes de codages de personnes expérimentées avec les technologies node.js/express.js qui seront adoptés. Règle n ° 1: organiser correctement nos fichiers dans des dossiers Tout doit avoir sa place dans notre application, alors les dossiers sont l'endroit idéal pour regrouper les éléments communs. En particulier, nous voulons définir une séparation très importante entre les modules de notre application, ce qui nous amène à la règle n°2. Règle n ° 2: garder une séparation claire entre la logique métier et les routes Les frameworks comme Express.js sont incroyables. Ils nous fournissent des fonctionnalités incroyables pour gérer les demandes, les vues et les itinéraires. Avec un tel support, il pourrait être tentant pour nous d'intégrer notre logique métier dans nos routes. Mais cela induit rapidement des blocs monolithiques géants qui se révéleront ingérables, difficiles à lire. La testabilité de notre application diminuerait, et par conséquent le temps de développement devient plus long. « Comment pouvons-nous résoudre ce problème, alors? Où mettre notre logique métier de manière claire et intelligente? » La réponse est révélée dans la règle n°3. Règle n ° 3: utiliser une couche de service et Bibliothèque C'est ici que doit vivre toute notre logique métier. Il s'agit essentiellement d'un ensemble de classes, qui implémentent la logique de base de notre application, chacune avec ses méthodes. Je préfère que les classes soient fusionnées avec les modèles. Les « lib » présentent notre bibliothèque qui sont des fonctions (plus ou moins des middleware) prédéfinis dans notre application tel que connexion mongo, authentification, logger, security etc... Maintenant que nous avons défini ces trois règles initiales, nous pouvons représenter graphiquement le résultat comme ceci:
Figure 3.18: Architecture de l'application D'après ce graphique nous aboutissons à l'arborescence suivant pour notre application:
Figure 3.19: Arborescence des dossiers de l'application En UML, Les diagrammes de composants sont utilisés pour visualiser l'organisation des composants du système et les relations de dépendance entre eux. Ils fournissent une vue de haut niveau des composants d'un système. Les composants peuvent être un composant logiciel tel qu'une base de données ou une interface utilisateur ; ou un composant matériel tel qu'un circuit, une micropuce ou un dispositif ; ou une unité commerciale telle qu'un fournisseur, un service de paie ou d'expédition.
Figure 3.20: Diagramme de composant En UML, un diagramme de déploiement est une vue statique qui sert à représenter l'utilisation de l'infrastructure physique par le système et la manière dont les composants du système sont répartis ainsi que leurs relations entre eux. Les éléments utilisés par un diagramme de déploiement sont principalement les noeuds, les composants, les associations et les artefacts. Les caractéristiques des ressources matérielles, physiques et des supports de communication peuvent être précisées par stéréotype.
Figure 3.21: Diagramme de déploiement Ayant opté pour une application cloud, il est donc impératif de choisir le provider qui héberge notre application. Les fournisseurs cloud étant nombreux, nous allons faire une étude comparative et choisir le provider le mieux adapté; l'étude va se porter sur les 4 providers suivants: Redhat, Amazon Web Services, Microsoft Azure et Google Cloud Platform. Les critères d'études sont les suivants: a. Système d'exploitation OS: ce critère vise à identifier les différents systèmes d'exploitations pris en charge par chacun des providers. b. Facilité et rapidité d'accès: la rapidité et la facilité d'accès des services d'un provider cloud se détermine par la proximité de ses datacenters DC. Ce critère est l'un des plus indispensable dans une étude comparative des providers cloud. c. Coût: un service cloud est mesurable donc a un coût. Nous allons nous attarder sur les coûts proposés par les différents fournisseurs. d. SLA Service-Level Agreement: est un accord entre un fournisseur de services cloud et un client qui assure le maintien d'un niveau de service minimum. Il garantit les niveaux de fiabilité, de disponibilité et de réactivité des systèmes et des applications, précise qui est responsable en cas d'interruption de service et décrit les pénalités en cas de non-respect des niveaux de service. e. Scalability: la Scalabilité est la capacité d'ajuster les ressources pour répondre à la hausse ou à la baisse de la demande. f. Failover: le failover, ou basculement est un mode de fonctionnement de secours qui consiste à basculer automatiquement sur une base de données, un serveur ou un réseau placé en attente si le système principal tombe en panne ou est arrêté le temps d'une maintenance. g. Langages: nous identifions les langages de programmation pris en charge par chacun des providers. h. Security: Nous nous intéressons
ici, à qui revient la responsabilité du service entre le client
et le fournisseur.
Table 3.5: Tableau comparatif des providers cloud
a. Node js: Node.js est une plateforme logicielle libre en JavaScript, orientée vers les applications réseau événementielles hautement concurrentes qui doivent pouvoir monter en charge. Ce qui est le cas de notre application. Le choix s'est porté sur Node.js également pour les raisons suivantes: Node.js est un système single thread non bloquant: Ce qui veut dire qu'il n'attend pas la fin d'exécution d'une requête pour en traiter une autre. Cela octroie une certaine rapidité aux applications qui font beaucoup de requêtes car Node.js est capable de gérer énormément de requêtes en parallèle sans les faire attendre les unes les autres. Node.js est flexible: Node.js est très light comme plateforme et n'a pas beaucoup de fonctionnalités déjà intégrées. Ce qui nous donne le choix des modules à lui greffer pour l'utiliser. Il n'y a pas de conventions strictes sur comment s'y prendre, cela nous laisse pas mal de marge de manoeuvre pour décider de tout. Ce qui fait qu'il est possible de commencer avec quasiment rien et avancer petit à petit dans la direction qu'on pense être la meilleure au fur et à mesure que nous avançons dans ton projet. Node.js c'est du javascript: Bien souvent il peut s'avérer un peu déstabilisant de coder avec un langage du côté front-end et un autre langage du côté back-end, avec Node.js ce casse-tête est fini parce qu'on reste dans le même langage partout. Au niveau organisation du code, c'est encore mieux. On pourra avoir les mêmes conventions de noms, les mêmes bonnes pratiques dans tout le code de notre projet, aussi bien en Front qu'en Back. b. Le framework Express JS: Express js est un framework utilisé pour construire des applications web basées sur node.js. C'est le plus populaire de tous les framework node.js et il est doté d'une prise en main très facile. C'est de fait le framework standard de node.js. c. MySql: MySQL est un système de gestion de base de données relationnelle (SGBDR) open source, basé sur le langage SQL (Structured Query Language). Cette solution, parmi les plus populaires au monde, est connue pour délivrer de hautes performances dans le stockage de larges volumes de données (notamment dans le big data) ou la Business Intelligence. Fondé en 1994, MySQL a été racheté par Sun Microsystems en 2008 et appartient à Oracle Database depuis 2010. MySQL est utilisé par de nombreuses entreprises dans le monde, dont Google, Yahoo!, YouTube, et Adobe, dans le digital, Airbus, Alstom, et Alcatel-Lucent dans l'industrie, Crédit agricole, dans le secteur de la banque et de l'assurance, .... d. Docker: Docker est une plateforme logicielle virtualisée de système lancée en 2013 ayant largement contribué à la démocratisation de la conteneurisation. Elle permet de créer, déployer et exécuter facilement des applications dans des conteneurs. Il en existe d'autres, mais celle-ci est la plus utilisée. Elle est par ailleurs plus facile à déployer et à utiliser que ses concurrentes. Le fonctionnement de Docker repose sur le noyau Linux et les fonctions de ce noyau, comme les groupes de contrôle cgroups et les espaces de nom. Ce sont ces fonctions qui permettent de séparer les processus pour qu'ils puissent s'exécuter de façon indépendante. En outre, Docker permet d'automatiser le déploiement des applications au sein d'un environnement de conteneurs. Grâce à ces divers outils, les utilisateurs profitent d'un accès complet aux applications et sont en mesure d'accélérer le déploiement, de contrôler les versions et de les attribuer.
a. Star UML pour la modélisation des diagrammes: StarUML est un logiciel de modélisation UML (Unified Modeling Language) open source qui peut remplacer dans bien des situations des logiciels commerciaux et coûteux comme Rational Rose ou Together . Étant simple d'utilisation, nécessitant peu de ressources système, supportant UML 2, ce logiciel constitue une excellente option pour une familiarisation à la modélisation. b. Git et Github pour le versionning et le dépôt: Git est un logiciel de versionning gratuit et open source. GitHub est un service d'hébergement de référentiel open source.Il héberge vos projets de code source dans une variété de langages de programmation et garde une trace des différentes modifications apportées à chaque itération. c. Visual Studio Code pour l'écriture du code: Visual studio code ou VS Codeest un éditeur de code développé par Microsoft en 2015 et est développé avec le framework Électron et conçu principalement pour développer des projets avec Javascript, Node.js ou encore TypeScript. Le choix a été donc très facile d. Figma pour la conception des wireframes: Figma est une plateforme web collaborative qui permet la création d'interfaces pour le web et le mobile. Nous l'avons utilisé pour construire nos wireframes et les schémas explicatifs. Le choix s'est porté sur figma pour sa simplicité et son coût qui est gratuit contrairement à bon nombre de ses concurrents. Dans les sections précédentes de ce chapitre, nous avons eu à étudier notre solution dans tous ses contours. Nous avons spécifié les besoins fonctionnels et non fonctionnels tout en mettant en avant les différentes fonctionnalités de l'application et en décrivant les interactions des utilisateurs avec le système. Nous avons également fait l'analyse et la conception des besoins fonctionnels et le choix des différents outils et technologies a été mis au clair.L'architecture de l'application a également été dégagée. Dans cette section, nous allons entamer la phase de l'implémentation. La page d'accueil est la page sur laquelle tout visiteur est amené à voir en premier lorsqu'il visite notre application. Cette page présente notre application en expliquant le service et les fonctionnalités offert.
Figure 3.22: Page d'accueil de l'application ? Page de connexion d'un utilisateur A partir de cette page, un utilisateur peut se connecter pour accéder à son espace client.
Figure 3.23: Page de connexion ? Page d'inscription d'un utilisateur Si un utilisateur n'a pas de compte il peut en créer un pour ainsi bénéficier de nos services.
Figure 3.24:Page d'inscription ? Page d'ajout d'une application Cette page permet d'ajouter une application en 4 étapes: a. Informations de l'application: Sur cette partie le client renseigne les informations basiques de son application comme le nom, les technologies utilisées et une description éventuelle.
Figure 3.25: Page d'ajout d'une application étape 1 b. Providing des utilisateurs: Ici, le client spécifie de quelle manière il va nous fournir les utilisateurs. Il pourra choisir parmi les deux méthodes disponibles.
Figure 3.26: Page d'ajout d'une application étape 2 c. Mode d'authentification: Le client va ensuite choisir un mode d'authentification pour ses utilisateurs: soit ces derniers restent sur son interface à lui, soit ils sont redirigés sur notre interface et seront renvoyés sur son application après authentification.
Figure 3.27:Page d'ajout d'une application étape 3 d. Mode de facturation et mode de paiement: En dernière étape, le client choisit un mode de paiement et de facturation pour son application; à ce stade seul le mode de facturation PAYG et le mode de paiement par mobile money sont disponibles.
Figure 3.28: Page d'ajout d'une application étape 4 Après l'ajout si tout s'est bien passé on lui affiche un récapitulatif de ses informations et un fichier de configuration à télécharger.
Figure 3.29: Page d'ajout d'une application récapitulatif ? Page de liste des application d'un client Cette page liste toutes les applications d'un client.
Figure 3.30:Page liste des applications ? Page détail d'une application d'un client Cette page affiche les détails d'une application et permet de les modifier
Figure 3.31: Page détails et configuration d'une application Dans cette partie nous passons au déploiement de notre plateforme. Nous avons, plus haut dans la partie conception, fait le choix de notre provider qui s'est porté sur AWS. Nous allons conteneurisé notre application avec docker et le déployer sur le service EKS d' AWS qui est un service géré utilisé pour exécuter Kubernetes sur AWS sans avoir besoin d'installer, d'exploiter et de maintenir un plan de contrôle ou des noeuds Kubernetes. Le flux de travail est donc très simple : ? Créer un utilisateur IAM sur AWS. ? Installer et configurer AWS CLI. ? Conteneuriser notre application avec une configuration Dockerfile ? Pousser l'image construite vers un registre de conteneurs, par exemple ECR. ? Créer un cluster sur AWS ? Déployer l'image vers le cluster en utilisant kubectl sur AWS CLI. ? Créer et configurer une base de données MySQL avec Amazon RDS ? Configurer et déployer keycloak sur notre cluster Installation et Configuration de AWS CLI Commençons par installer AWS CLI en ligne de commande. Pour cela tapons la commande suivante dans le terminal:
Figure 3.32: Installation de AWS CLI Nous allons vérifier que l'installation a bien réussie:
Figure 3.33: Configuration de AWS CLI Conteneuriser l'application avec une configuration Dockerfile Maintenant, créons un Dockerfile pour construire notre application Express dans une image de conteneur :
Construire l'image Docker Construisons et taguons l'image Docker :
Figure 3.35: Containerisation de l'application Pousser l'image construite vers un registre de conteneurs Nous allons taguer puis pousser notre image vers notre registry ECR créé sur AWS.
Figure 3.36: Résultat de la commande de containerisation Créer un cluster sur AWS Un cluster Kubernetes est un ensemble de machines nodales permettant d'exécuter des applications conteneurisées. L'usage de Kubernetes implique l'usage d'un cluster.
Déployer l'image vers le cluster en utilisant une kubectl sur AWS CLI Maintenant que l'image est poussée vers le repository ECR, la manière la plus simple de la déployer vers le cluster est d'utiliser la console aws. Nous pouvons utiliser cette approche pour des raisons de simplicité. En premier lieu, nous allons configurer kubectl à cet effet nous faisons recours à docker desktop.
Figure 3.38: Configuration de k8s dans docker Nous allons maintenant créer un déploiement. Un Deployment indique à Kubernetes comment créer et mettre à jour les instances de notre application. Une fois que nous avons créé un Deployment, le maître Kubernetes planifie les instances de l'application incluses dans ce Deployment pour qu'elles s'exécutent sur les différents noeuds du cluster. Dans Kubernetes, un service est une abstraction qui définit un ensemble logique de pods et une politique permettant d'y accéder. Les services permettent un couplage souple entre les pods dépendants. Ici, nous allons ajouter le déploiement et le service dans un seul fichier manifest.yml :
Figure 3.39: Fichier manifest.yml Créons le déploiement avec la suivante:
Figure 3.40: Commande pour déployer le fichier .yml Ensuite nous vérifions la bonne exécution de la commande de déploiement:
Figure 3.41: Résultat des commandes de vérification du déploiement. Configurer une base de données MySQL avec Amazon RDS: Voici un aperçu de notre base de données créée dans RDS
Figure 3.42: Base de données Amazon RDS Configurer et déployer keycloak sur notre cluster: Pour configurer keycloak et le déployer sur notre EKS, nous sommes passé par un fichier de configuration : deployment.yaml
Figure 3.43: Fichier yaml pour keycloak Ce fichier contient à la fois les configurations pour le déploiement et le service qui seront utilisés par EKS. Nous allons maintenant le pusher vers notre EKS.
Figure 3.44: Résultat après déploiement de keycloak Nous avons créé et configuré un cluster sur Amazon EKS dans lequel nous avons déployé notre application dockeurisée pusher dans un registry sur ECR. Puis nous avons configuré et lié une base de données Amazon RDS à notre application et nous avons déployé keycloak sur notre cluster. Après toutes ces étapes, notre application tourne maintenant sur notre cluster et on peut le constater sur l'image suivante.
Figure 3.45: Vérification du déploiement de l'application |
|
VS 
VS 
