Aujourd’hui, je m’attaque à la problématique d’Intégration et de Déploiement Continue avec OpenShift. Mes interrogations sont les suivantes: Qu’apporte une plateforme Docker ? Quels sont les gains en productivité ? Quels intérêts pour les développeurs ? pour les Ops ? Quelles contraintes sur un projet classique JEE ? Bref, pour m’aider à y répondre, j’utiliserai le superbe projet CI/CD Demo on OpenShift de Siamak Sadeghianfar comme base. Il est très complet, merci Siamak 😉 . Cependant je n’ai pas résisté à y apporté une touche personnelle suite à quelques envies et incompatibilités… Mon environnement Windows 10 et la finalisation de MiniShift en 1.0-rc2 en sont probablement la cause.
Objectifs
Mon objectif principal est d’ accélérer les déploiements des applications Java sur des environnements prêt à consommer. La finalité est de déployer une version stable d’une application JEE dans un environnement “STAGE” après l’avoir testée et évaluée.
Pour cela, les outils doivent me permettre un certain nombre d’actions sur le logiciel en cours de développement:
- construire,
- vérifier la qualité,
- archiver,
- déployer
- exécuter
- tester
- mesurer.
Je vais utiliser 2 environnements différents, un pour les tests unitaires, l’autre pour les tests d’intégration. Openshift m’apportera son aide sur la gestion de ces environnements avec
- leur définition,
- le déploiement des machines,
- le portage des instances.
Quand à l’intégration continue (construction, mesure et archivage), les outils opensource Jenkins, Sonar et Nexus sont mes amis 😉 .
Ma vision globale de la problématique de CI/CD est celle-ci:
Toutefois, une précision de vocabulaire s’impose.
La notion d’environnement dans OpenShift est appelé PROJET (un namespace kubernetes). Cela est similaire à un sous-réseau où les instances dockers (pods) peuvent communiquer entre elles.
Dans la suite de l’article, je parlerai d’environnement pour PROJET “OpenShift” et projet pour PROJET “Maven”.
Pré-requis
cf. Installation de Minishift et Optimisation de Minishift.
Vision d’ensemble
Le projet cobaye est un projet JEE classique. Il a été créé par Simiak défini via son projet GitHub. J’y ai apporté quelques modifications, donc je l’ai cloné afin de partager mes modifications.
L’environnement d’Intégration Continue est commun à tous les projets maven construits. Les environnements d’exécution DEV sont dédiés alors que le STAGE est mutualisé.
Il est alors possible de:
- créer 1 environnement STAGE par version majeure du produit (ensemble de projets),
- créer n environnement DEV en fonction des besoins et des runs.
Installation et configuration des environnements
Création des environnements
Les 3 environnements (projets) OpenShifts sont créés:
- STAGE pour la recette
- DEV pour les dev
- CI/CD pour l’outillage de build.
oc login -u developer -p developer oc new-project dev --display-name="Dev" oc new-project stage --display-name="Stage" oc new-project cicd --display-name="CI/CD"
Il est nécessaire de donner les droits d’édition du service jenkins du projet CI/CD sur les autres: DEV et STAGE.
oc project cicd oc policy add-role-to-user edit system:serviceaccount:cicd:jenkins -n dev oc policy add-role-to-user edit system:serviceaccount:cicd:jenkins -n stage
Les environnements sont alors disponibles.
Environnement CI/CD
Ensuite, pour créer les déploiements Jenkins, Sonar et Nexus, il suffit d’utiliser le docker-compose que je vous fournis docker/cicd :
oc project cicd oc new-app jenkins-persistent oc import docker-compose -f .\docker-compose.yml
Cela importe les déploiements de:
Gogs avec PostgreSQL | |
Jenkins avec son node JNLP | |
Nexus v3 | |
SonarQube avec PostgreSQL |
Les services importés avec docker compose doivent être exposés.
oc expose svc/gogs oc expose svc/sonarqube oc expose svc/nexus3
Environnements DEV et STAGE
Rien à faire pour ces 2 là 😀 . Les ajouts seront pilotés par Jenkins.
Construction et Déploiement Continue
Tâche Jenkins
Le build importé dans la configuration de m’a pas plu. Il utilise la notion de pipeline intégrée à OpenShift. Je n’ai pas vu l’intérêt de cette fonctionnalité dans OpenShift…
J’ai donc recréé un projet Jenkins multibranches Pipeline.
Nexus
Jenkins construit le projet via un agent JNLP sur un node dynamique (nouveau à chaque build). Le téléchargement des jar maven est alors TROP long et redondant. Mais Nexus est là !
Il faut alors:
- Ajouter les proxy suivant dans la configuration (http://nexus3-cicd.minishift.local/, admin/admin123)
- Apache Public: https://repository.apache.org/content/groups/public/
- JBoss Public Repository Group: https://repository.jboss.org/nexus/content/groups/public/
- OpenShift Public: https://mirror.openshift.com/nexus/content/groups/public/
- Ajouter chaque proxy dans le Groupe maven-public.
Ainsi il servira de cache pour tous les builds. Ce miroir est alors utilisé par maven lors des builds via:
- le fichier cicd-settings.xml du projet Git
- le plugin config file provider de Jenkins
<mirror> <id>nexus</id> <mirrorOf>*</mirrorOf> <name>Public Nexus repository</name> <url>http://nexus3:8081/repository/maven-public/</url> </mirror>
Les builds sont alors beaucoup plus rapides. Ouf 😉 !
Le Jenkinsfile utilise le plugin Configfile, les build à la main ou sur mon poste le fichier cicd-settings.xml.
Sonar
Pour analyser le code Java, des modules sont à installer.
Dans Sonar, se sonnecter en admin et Aller dans Administration > System > Update center
Ajouer ensuite les plugin suivant: SonarJava est le minimum 😉 .
Sans cela, les rapports sonar échoueront avec cette erreur:
[ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.2:sonar (default-cli) on project jboss-tasks-rs: No quality profiles have been found, you probably don't have any language plugin installed. -&amp;gt; [Help 1]
Pipelines
Le fichier Jenkinsfile est composé des étapes suivantes:
- Build
- Deploy DEV
- Unit Tests
- Push to Nexus
- Deploy INT
- Integration Tests
- Deploy RECETTE
Ces étapes se visualisent bien dans le résultat des runs Jenkins.
Synthèse
Au final, le cycle d’ Intégration Continue est assez similaire à un usage plus classique. Il est complété par une légère étape de définition des environnements. Même si les environnements DEV et STAGE ne sont pas bridés en ressources matérielles, la reproductibilité est très importante.
OpenShift (comme orchestrateur Docker) simplifie la gestion des environnements. L’utilisation d’environnements parallèles en STAGE est ici simple.