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.

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 :

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 :

helm repo add fusionauth https://fusionauth.github.io/charts 
helm install fusionauth --create-namespace fusionauth/fusionauth --namespace auth \ 
	--set database.protocol=postgresql \ 
	--set database.user= \ 
	--set database.password= \ 
	--set database.host= \ 
	--set database.port=5432 \ 
	--set database.name= \ 
	--set database.root.user= \ 
	--set database.root.password= \ 
	--set app.runtimeMode=production \ 
	--set search.engine=database

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.

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 !

npm install -g devspace

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

devspace init

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 :

version: v1beta10 
vars: 
- name: SOME_IMPORTANT_VARIABLE 
	source: env 
	default: the-important-value 
images: 
	my-custom-service: 
		image: my-repo/my-custom-service 
		tags: 
		- ${DEVSPACE_RANDOM} 
		dockerfile: ./my-custom-service/Dockerfile 
		context: . 
		build: 
			docker: 
				options: 
					target: app 
					buildArgs: 
						SOME_IMPORTANT_VARIABLE: ${SOME_IMPORTANT_VARIABLE} 
api: 
	image: my-repo/api 
	tags: 
	- ${DEVSPACE_RANDOM} dockerfile: ./api/Dockerfile 
	context: .

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 :

deployments: 
# for the custom service, we have regular k8s manifests 
- name: my-custom-service 
	kubectl: 
		manifests: 
		- my-custom-service/manifest.yaml 
# for the api, we have written a helm chart 
- name: api 
	helm: 
		chart: 
			name: api/chart 
		values: 
			image: my-repo/api 
			postgres: 
				database: my-database 
				hostname: postgres 
				username: my-username 
				password: my-password 
# the database service is a 3rd party 
- name: postgres 
	helm: 
		chart: 
			name: postgresql 
			repo: https://charts.bitnami.com/bitnami 
		values: 
			postgresqlDatabase: my-database 
			postgresqlUsername: my-username 
			postgresqlPassword: my-password 
# the iam service is a 3rd party 
- name: iam-service 
	helm: 
		chart: 
			name: fusionauth/fusionauth 
		values: 
			database: 
				protocol: postgresql 
				user: iam-user 
				password: iam-password 
				host: postgres 
				name: iam-database 
					user: root-db-username 
					password: root-db-password 
			search: engine: database

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

kubectl apply -f my-custom-service/manifest.yaml

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 :

devspace dev

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 :

profiles: 
- name: staging 
	patches: 
	# images -> adapt tag 
	- op: replace 
		path: /images/0=${DEVSPACE_RANDOM} 
		value: 
		- staging-${DEVSPACE_GIT_COMMIT} 
	# postgres -> remove, we have an external database 
	- op: remove 
		path: /deployments/name=postgres 
	# iam service -> remove, we have an external iam service 
	- op: remove 
		path: /deployments/name=iam-service 
	# api 
	# -> we need an ingress 
	- op: replace 
		path: /deployments/name=api/helm/values/ingress 
		value: 
			enabled: true 
			annotations: 
				kubernetes.io/ingress.class: nginx-cert 
				cert-manager.io/cluster-issuer: letsencrypt-prod 
			hosts: 
			- host: api-staging.my-staging-domain.com 
				paths: 
				- / 
			tls: 
			- secretName: api-tls 
				hosts: 
				- api-staging.my-staging-domain.com 
	# -> we need up-to-date database accesses 
	- op: replace 
		path: /deployments/name=api/helm/values/postgres 
		value: 
			database: my-external-database 
			hostname: my-external-database-hostname 
			username: my-external-username 
			password: my-external-password 
	# my-custom-service -> nothing to do

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

devspace deploy -p staging 
devspace deploy -p production

É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.

Lire les articles similaires

Comment déployer Graylog sur Hidora ?

Comment déployer Rocket.Chat et intégrer Jitsi pour la communication en ligne ?