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