Jenkins X : Installation
Officialisé en Mars 2018, Jenkins X est un projet d'employés de CloudBees , ayant pour objectif de donner le plus d'autonomie possible aux équipes de développement via l'automatisation de l'outillage et des bonnes pratiques DevOps sur l'ensemble de la chaîne de production.
Concrètement, Jenkins X fournit un ensemble de conventions et de commandes permettant l'installation d'une usine logicielle dans Kubernetes, qui permettra non seulement de gérer les environnements de recette et de production, mais également ceux de développement en mettant à disposition des outils comme Nexus ou ChartMuseum.
Tout cela est effectué via l'encapsulation d'outils tel kubectl : vous ne dépendez donc pas totalement de Jenkins X, qui ne fait qu'exécuter des commandes d'outils existants.
Une autre particularité de Jenkins X est sa propension à fonctionner en mode GitOps: la définition de l'environnement a persisté sur Git et chaque commit déclenche une réévaluation de la configuration et donc un redéploiement des applications/environnements concernés.
Mon Opinion : Jenkins X fait pour moi partie des technologies que nous verrons partout par le futur : Kubernetes est en train de devenir le leader incontesté des clusters docker mais reste pour le moment bien trop complexe à utiliser compte tenu du grand nombre de connaissances qu'il demande. Jenkins X, dans sa philosophie, vise à simplifier au maximum cette utilisation de Kubernetes afin que les équipes de développement ne soient pas limitées par ce que supportent leurs équipes d'intégration. Un objectif louable qui devrait, à terme, permettre de fournir l'autonomie souhaitée aux équipes. Parce que, soyons honnêtes, tout n'est pas rose pour le moment. La plateforme évolue à vue d'oeil en appliquant elle même les principes qu'elle prône, puisque Jenkins X est gouverné par une plateforme Jenkins X, et cela n'a pas que des avantages. En effet, avec à peu près 4 livraisons par jour ouvré, Jenkins X en est déjà à sa 2324ème version de sa ligne de commande jx. Dans un monde parfait, la documentation et les tests évolueraient à la même vitesse que les fonctionnalités et les fonctionnalités elles-mêmes évolueraient de manière incrémentale jusqu'à éventuellement être dépréciées puis complètement supprimées. Dans la pratique toutefois, il n'est pas rare de voir qu'une commande qui fonctionnait la veille ne fonctionne plus et ce ne sera qu'en parcourant le Slack ou le Github que vous découvrirez que la fonctionnalité a été remplacée par une autre. En attendant que le projet atteigne sa maturité, il est donc extrêmement important que la personne en charge de votre usine logicielle ait des connaissances approfondies de Kubernetes et des éléments adjacents (Docker, Helm, Ingress, etc...) ainsi qu'une bonne compréhension du fonctionnement de Jenkins X afin que ces problèmes ne soient pas handicapants. Jenkins X n'étant qu'un emballage de commandes Docker, Helm et Kubernetes existantes, il est toujours possible de reproduire l'intention initiale. |
Notre objectif
Dans cette première partie, nous allons créer notre cluster et installer notre environnement Jenkins X qui nous permettra d'intégrer nos applications.
Une fois installé, le cycle de mise en production de nos applications devrait ressembler à ceci :
Installation
L'installation de Jenkins X se fait en 2 étapes, une première étape de création du cluster, et une seconde d'initialisation de la plate-forme dans le cluster créé.
Pré-requis
Google Cloud SDK
Puisque nous avons décidé d'utiliser Google Cloud, il nous faut au préalable :
jx
Comme nous vous l'expliquions plus tôt, Jenkins X encapsule des outils existants et fournit des commandes simplifiées via sa ligne de commande jx. Presque toute action exécutée sur votre plateforme se fera via jx.
Il nous faut donc commencer par installer cet outil. Pour cela, rendez-vous sur https://github.com/jenkins-x/jx/releases et sélectionnez la première release. Pour cet article, nous utiliserons la version 2.0.845 :
https://jenkins-x.io/docs/getting-started/setup/install/
Installation du cluster
Maintenant que nous avons installé jx, créons notre cluster :
Installation de Jenkins X
Une fois le cluster installé, nous pouvons initialiser Jenkins X dans ce nouveau cluster. Pour cela, nous allons utiliser l'outil jx boot, qui permet l'installation de la plateforme Jenkins X selon un ensemble de fichiers de configuration.
Cet ensemble de fichiers servira ensuite de base de configuration de référence pour travailler en mode GitOps : chaque modification apportée à votre répertoire de configuration déclenchera les modifications associées à votre Cluster.
La plupart du temps, vous ne modifierez que le fichier jx-requirements.yaml, mais si vous souhaitez ajouter une application non comprise dans le packaging de Jenkins X, c'est cet ensemble de fichiers que vous devrez modifier.
Le nom de domaine que nous allons utiliser se terminant en .dev, nous aurons besoin d'activer TLS pour l'ensemble des services exposés sur le web, toute connexion non TLS étant interdites sur ces extensions de domaine et pour gérer les secrets nous préférerons utiliser vault pour plus de sécurité.
Configuration de jx boot
Si nous exécutions la commande jx boot tout de suite, jx boot lancerait l'installation directement à partir de la dernière version sortie du template de configuration. Comme nous souhaitons utiliser notre propre nom de domaine, ainsi qu'activer Vault et TLS, nous allons récupérer manuellement le template de configuration et modifier la configuration par défaut :
Editons maintenant le fichier jx-requirements.yaml et modifions la configuration :
Configuration de Cloud DNS
Nous venons désormais de spécifier que nous voulions que Jenkins X utilise des URL accessibles via le domaine esensconsulting.dev. Pour qu'il puisse effectuer ce travail, nous lui avons précisé d'utiliser externalDNS, un service Kubernetes permettant la création automatisée d'alias sur serveur DNS, via l'utilisation de Google Cloud DNS.
Il nous faut donc au préalable configurer Google Cloud DNS pour qu'il puisse lui-même gérer les requêtes vers le domaine esensconsulting.dev . Dans la console Google Cloud DNS, nous créons une zone pour esensconsulting.dev. Une fois créée, Google Cloud DNS nous fournit une liste de serveurs de noms que nous pouvons utiliser à la place des serveurs de noms de notre fournisseur de nom de domaine.
ATTENTION : tous les fournisseurs de nom de domaine ne fournissent pas cette fonctionnalité permettant de changer les serveurs de noms
Notre nom de domaine ayant été pris sur Google Domains, il nous est relativement facile de changer nos serveurs de noms :
Je vous conseille d'attendre quelques heures pour vous assurer que les serveurs de noms ont été correctement changés. Si vous le voulez, vous pouvez vérifier que votre configuration est correcte en montant une VM avec un apache qui répond correctement et ajouter vos alias manuellement dans Google Cloud DNS. Vous pourrez ensuite interroger votre nom de domaine pour vérifier que vous accédez bien à la machine.
Exécution de jx boot
Maintenant que vous avez préparé la configuration et configuré Cloud DNS, vous pouvez lancer jx boot et laissé l'assistant vous guider dans l'installation :
Maintenant que Jenkins X est installé, il ne nous reste plus qu'à créer ou importer nos projets.
Test de la plateforme
Jenkins X fournit 2 méthodes permettant l'ajout d'un projet à l'usine logicielle :
- jx import, pour importer un de vos projet déjà existant
- jx create quickstart
Création du projet
Pour nous simplifier la tâche, nous allons utiliser un quickstart Spring Boot inclut dans la distribution Jenkins X. qui nous générera une application basique permettant d'afficher Hello World! dans notre navigateur :
Nous avons également la possibilité de créer nos propres quickstarts, ce que verrons dans de futurs articles.
jx create quickstart
Vérification du déploiement
Maintenant que votre projet est ajouté à votre usine logiciel, une pipeline de construction et de déploiement a été déclenchée. Vous pouvez suivre son déroulement avec la commande suivante :
jx get activity -f test-jenkins-x -w
Comme vous pouvez le voir dans les dernières étapes de la construction, une Pull Request a été effectuée sur l'environnement de staging. Une nouvelle pipeline va alors être déclenchée afin de déployer la nouvelle version de votre application sur cet environnement.
Une fois cette pipeline terminée, vous devriez avoir vos pods Kubernetes et vos services de configurés et déployés sur votre cluster :
Notre application, dans sa version de staging, est donc désormais accessible depuis internet :
Développements et Preview
Bien sûr, vous pouvez désormais modifier votre projet nouvellement créé. Chaque commit sur la branche master déclenchera un nouveau build et un nouveau déploiement.
Mais pousser directement sur master n'est jamais une bonne idée, et il est toujours conseillé de fonctionner par Pull Request. De plus, ouvrir une Pull Request sur une application Jenkins X signifie commencer un processus de validation de votre Pull Request.
Pour vous faciliter la validation de vos features, Jenkins X déploie le résultat de la Pull Request sur un environnement dit : " de Preview". Cet environnement à la même durée de vie que votre Pull Request : une fois votre Pull Request fermée, l'environnement sera détruit.
Regardons cela de plus près en créant une nouvelle Pull Request sur notre projet :
Vous pouvez voir dans GitHub qu'un build a été exécuté pour construire le résultat de la PR. Une fois la PR déployée sur l'environnement de Preview, vous devriez voir un écran semblable à celui-ci :
La PR n'étant plus qu'en attente de validation, vous pouvez vérifier son contenu sur l'environnement de Preview :
Le mot de la fin
C'est tout pour le contenu de cet article. Dans un prochain article, nous verrons en plus de détails ce qui constitue Jenkins-X et comment nos projets interagissent avec. Dans ce contexte, nous verrons comment déployer des applications d'une plus grande complexité, avec des dépendances sur des services externes.
A Bientôt !
PS : Certains auront remarqué que les URL des dernières étapes se terminent non pas par un .dev mais par un .org.
Cela s'explique par un manque actuel de Jenkins-X dans sa gestion des environnements avec des échanges TLS : les certificats ne sont pas générés pour tous les environnements de manière automatique. Les certificats n'étant pas signés par une autorité valide, les sites en .dev deviennent inaccessibles.
C'est un bon exemple du genre de surprise qu'on peut avoir à l'heure actuelle avec Jenkins-X, qui reste encore très jeune et en développement intense.
Cela dit, l'opération de changement de domaine nous aura pris tout au plus 15 minutes. ;)
------------------------------
Article rédigé par Emmanuel, Tech Lead chez ESENS | Retrouvez tous nos articles sur le Blog ESENS
Vous êtes à la recherche d'un nouveau challenge ? Rejoignez l'équipe ESENS en postulant à nos offres d'emploi !
