Développement basé sur Kubernetes avec Devspace

Les applications modernes reposent de plus en plus sur des micro-services. La division de grandes applications en petits morceaux rend l’ensemble plus facile Ă  maintenir et Ă  dĂ©velopper. Cependant, au lieu de dĂ©velopper un gros monolithe, nous travaillons sur un ensemble de petites applications, ce qui rend plus difficile le dĂ©bogage et le dĂ©ploiement de l’ensemble du systĂšme. Heureusement, il existe de nombreux outils pour nous aider. Une comparaison intĂ©ressante de certains d’entre eux peut ĂȘtre trouvĂ©e ici. Dans ce qui suit, nous voulons voir Ă  quel point il est facile de faire du dĂ©veloppement basĂ© sur Kubernetes avec devspace.

network cloud hosting hidora

Une application micro-services

Supposons que nous dĂ©veloppions une application de micro-services, par exemple une boutique en ligne. En substance, notre boutique en ligne consiste en une application frontale qui communique avec un backend par le biais d’une API. Par souci de simplicitĂ©, disons que notre backend ressemble Ă  ceci :

Kubernetes-based development with Devspace

La gestion des utilisateurs est assurĂ©e par le service iam. Les commandes sont traitĂ©es via la file d’attente de messages. La plupart de la logique mĂ©tier de notre backend est emballĂ©e dans des fonctions serverless servies par le faas. L’Ă©tat de notre application est conservĂ© dans notre base de donnĂ©es. Enfin, pour quelques bonnes raisons (par exemple, la facilitĂ© de configuration des tests), nous dĂ©veloppons notre logiciel dans un monorepo.

Avec le temps, notre application micro-services contiendra nĂ©cessairement beaucoup de logique mĂ©tier qui sera emballĂ©e dans encore plus de code micro-service ou de fonctions serverless. Par exemple, nous pourrions avoir besoin d’un service connecteur entre notre file d’attente de messages et notre faas, ou d’un service d’actifs avec une certaine logique pour ajouter de nouveaux actifs de maniĂšre contrĂŽlĂ©e. Une façon trĂšs pratique d’hĂ©berger nos microservices est de les dockeriser et de laisser Kubernetes les orchestrer.

GĂ©nĂ©ralement, notre service IAM est un tiers comme keycloak ou fusionauth que nous pouvons facilement dĂ©ployer sur Kubernetes au moyen d’un diagramme helm. Helm est un gestionnaire de paquets trĂšs pratique pour Kubernetes. Par exemple, un dĂ©ploiement typique de fusionauth ressemblerait Ă  quelque chose de ce genre :


                                                                                    

Notre file d’attente de messages est probablement redismq, rabbitmq ou kubemq, pour lesquels nous trouvons aussi facilement des diagrammes de barre.

Viennent ensuite nos propres services personnalisés pour lesquels nous devons écrire nos propres ressources Kubernetes (déploiements, services, ingresses, etc.). Enfin, nous pouvons écrire une sorte de script pour installer tous les diagrammes de barre nécessaires et appliquer nos ressources Kubernetes.

Parce que notre logiciel traite des donnĂ©es sensibles et fait notre mĂ©tier, nous devons ĂȘtre prudents lorsque nous dĂ©ployons une nouvelle version. Par consĂ©quent, nous voulons d’une certaine maniĂšre la tester avant de la diffuser, ce qui est trĂšs facile Ă  faire sur les clusters Kubernetes. En effet, nous pouvons imaginer que nous avons deux environnements, un pour les tests et un pour la production. L’environnement de test (ou staging) serait synchronisĂ© avec la branche principale de notre dĂ©pĂŽt de logiciels tandis que l’environnement de production serait le pendant de la branche de production de notre dĂ©pĂŽt. Nous dĂ©veloppons sur la branche principale et, dĂšs que le Q&A est satisfait du logiciel qui y est poussĂ©, nous le poussons vers la production.

Nous sommes maintenant dans une situation compliquĂ©e oĂč nous voulons dĂ©velopper notre logiciel sur une machine de dĂ©veloppement, le tester d’une maniĂšre ou d’une autre sur un environnement presque productif, et le diffuser dans un environnement de production. Cela nous conduit Ă  trois procĂ©dures de construction et de dĂ©ploiement diffĂ©rentes. Sur une machine de dĂ©veloppement, nous voulons sĂ»rement interagir avec une base de donnĂ©es Ă©phĂ©mĂšre. De plus, les identifiants de connexion Ă  nos microservices (comme le service de gestion des actifs) doivent ĂȘtre triviaux. Sur une machine de dĂ©veloppement, nous pouvons souhaiter accorder un accĂšs non protĂ©gĂ© Ă  certains de nos services, Ă  des fins de dĂ©bogage. En production, nous voulons sĂ©curiser et cacher autant que possible.

Enfin, si notre environnement de dĂ©veloppement Ă©tait proche de l’environnement de production, nous rĂ©duirions au minimum les surprises qui suivent un dĂ©ploiement vers le staging ou la production, ce qui augmenterait notre productivitĂ©.

Entrer dans le devspace

Devspace est un outil de clique qui permet d’automatiser Ă  la fois la construction et le dĂ©ploiement d’images de conteneurs. En outre, cet outil pourrait aussi bien remplacer nos configurations makefile ou docker-compose et nous offre la possibilitĂ© de faire du dĂ©veloppement basĂ© sur Kubernetes. GrĂące Ă  cette derniĂšre possibilitĂ©, supposons que nous ayons mis en place un petit cluster sur notre machine de dĂ©veloppement. En un clic, vous pouvez demander Ă  Jelastic de configurer ce cluster de dĂ©veloppement pour vous via une interface trĂšs simple.

Kubernetes-based development with Devspace
Kubernetes-based development with Devspace

Vous pouvez également configurer manuellement votre propre cluster de bureau de type, minikube ou docker.

La façon la plus simple d’installer devspace (non pas sur votre cluster Kubernetes, mais sur une machine distante Ă  partir de laquelle vous dĂ©veloppez votre code !


                                                                                    

Ensuite, en fonction de notre cas d’utilisation, nous pourrions exĂ©cuter


                                                                                    

et suivez les instructions. Dans notre cas particulier, nous voulons construire

  • notre API
  • un ensemble de micro-services personnalisĂ©s

C’est ce que nous faisons avec la configuration suivante :


                                                                                    

La configuration ci-dessus dĂ©finit la maniĂšre de construire notre API et nos micro-services. Lorsqu’elles sont poussĂ©es vers leur registre docker, les deux images docker auront la mĂȘme Ă©tiquette alĂ©atoire (dĂ©finie par la variable intĂ©grĂ©e DEVSPACE_RANDOM). Au lieu d’utiliser un dĂ©mon docker, nous pouvons Ă©galement choisir d’utiliser des commandes de construction personnalisĂ©es ou kaniko. Nous pouvons utiliser des variables d’environnement, comme SOME_IMPORTANT_VARIABLE et fournir les options habituelles pour construire des images docker.

Ensuite, nous voulons déployer

  • notre API
  • nos micro-services personnalisĂ©s
  • divers services tiers (iam, message queue, faas, assets)

Pour s’en occuper, nous complĂ©tons la configuration prĂ©cĂ©dente avec le snippet suivant :

Le premier déploiement, my-custom-service, se résume à


                                                                                    

Le deuxiĂšme dĂ©ploiement, api, est une installation helm ordinaire. Au lieu d’Ă©crire notre propre diagramme helm, nous aurions pu utiliser les diagrammes de composants intĂ©grĂ©s qui offrent un compromis entre la dĂ©finition de nos propres diagrammes helm et la simplicitĂ© de la configuration de nos ressources Kubernetes. Avec la configuration actuelle de notre devspace en place, nous pouvons dĂ©marrer notre environnement de dĂ©veloppement :

Cette commande construit nos images docker et dĂ©ploie notre logiciel dans l’espace de noms par dĂ©faut de notre cluster Kubernetes de dĂ©veloppement. Nous sommes maintenant dans une situation oĂč nous pouvons dĂ©velopper notre code sur notre machine de dĂ©veloppement et le pousser vers notre cluster Kubernetes de dĂ©veloppement. Avec le rechargement Ă  chaud ou le rechargement automatique, nous pouvons mĂȘme corriger notre code et le rĂ©sultat est automatiquement propagĂ© Ă  notre cluster.

Déployer dans plusieurs environnements

Nous avons maintenant une configuration qui fonctionne pour le dĂ©veloppement. Nous ne sommes pas trĂšs loin de la configuration de notre environnement de mise en scĂšne. PremiĂšrement, nos images docker doivent ĂȘtre marquĂ©es en suivant le modĂšle /:staging-. DeuxiĂšmement, notre environnement de staging repose sur une base de donnĂ©es externe et des services IAM. Par consĂ©quent, nous ne voulons pas les dĂ©ployer sur staging et nous devons adapter les services qui en dĂ©pendent. Dans devspace, nous pouvons dĂ©finir des profils. Jusqu’Ă  prĂ©sent, notre configuration ne fait rĂ©fĂ©rence Ă  aucun profil, il s’agit donc du profil de dĂ©veloppement. Nous pouvons dĂ©finir le profil de staging, le laisser se baser sur le profil de dĂ©veloppement et l’adapter comme nous venons de le dĂ©crire. Pour ce faire, ajoutons la configuration suivante Ă  notre devspace.yaml :

Nous pouvons bien sĂ»r suivre la mĂȘme philosophie couplĂ©e au concept de profils parents pour dĂ©finir notre profil de production. Ensuite, la construction et le dĂ©ploiement vers la phase de test ou la production sont aussi simples que

Évidemment, le dĂ©bogage Ă  distance de ces profils est Ă©galement possible.

Nous n’avons fait qu’effleurer la surface…

De nombreuses autres fonctionnalités sont disponibles, comme la définition de commandes personnalisées, la redirection (inverse) de ports, la synchronisation de fichiers, le streaming des journaux de conteneurs, etc . Utilisé judicieusement dans les pipelines CI / CD, devspace peut simplifier considérablement la façon dont vous publiez vos logiciels.

Écrit par

Laurent Michel
Propriétaire de produit chez Softozor

Client d’Hidora depuis 2017, utilisant le PaaS jelastic et le ci/cd gĂ©rĂ© gitlab pour rĂ©duire les frais gĂ©nĂ©raux d’infrastructure de leur plateforme e-commerce.

Recevoir nos actualités