Intégration/Déploiement Continue sur OpenShift

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:

  1. construire,
  2. vérifier la qualité,
  3. archiver,
  4. déployer
  5. exécuter
  6. tester
  7. 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

  1. leur définition,
  2. le déploiement des machines,
  3. 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 ».

Lire la suite

AWS Summit 2016

Cela faisait 2 ans que je n’avais pas mis les pieds à un événement AWS. (cf. Blog Sodifrance). J’y suis allé avec quelques questions: Depuis 2014, quelles sont les nouveautés ? Comment Amazon continue à tenir le marché des offres Cloud ? Où en sont les offres PaaS sur le SOA, BPM, API, Micro-Services et Streams ?

Voici un petit aperçu de ma journée et de ce que j’en ai retenu.

Keynote

3h de show de Werner Vogels qui a balayé toutes les fonctionnalités de AWS. Quel marathonien et quel showman !

Lire la suite

SOA as a Service

L’utilisation de ressources IaaS et PaaS posent de nombreux problèmes d’interconnexion entre les parties prenantes d’un Système d’Information. Dans cet article, je vous propose une vision simplifiée d’une démarche de transformation de votre SOA en un service externe « SOA as a Service ». Elle vous permettra de mettre en oeuvre une infrastructure AWS, Azure, etc. pour vos solutions actuelles SOA et BPM.

Outre la question financière, la principale motivation de cette évolution est de bénéficier de l’élasticité de ces offres XaaS. La SOA et le BPM, au cœur du Système d’information, doit aussi en bénéficier afin d’évoluer et de s’adapter aux contraintes de trafic et de charges exceptionnelles.

Comme exemple, j’utiliserai d’un cas d’école simple et représentatif avec ses 4 couches applicatives:

  1. Le navigateur des utilisateurs
  2. L’ application Front-End qui agrège les informations métier pour générer une vision contextualisée
  3. La partie SOA avec:
    1. le bus d’entreprise (ESB) qui virtualise et routent les services métier
    2. l’orchestrateur SOA qui gère la complexité des enchaînements entre les services du SI
    3. le moteur BPM qui porte les workflows métier
  4. Le Back-Office qui expose des services techniques, métier ou utilitaires sur des technologies variées.
Architecture du cas d'exemple
Architecture du cas d’exemple

Cette représentation reste valable pour N applications web dans la partie Front-End et N applications dans la partie Back-End. Les technologies sous-jacentes sont sans impact tant qu’elles communiquent avec des protocoles standards HTTP comme SOAP ou REST.

La démarche d’externalisation des solutions SOA s’articule autour de 2 contraintes fortes: la sécurité et la performance. Il est évident que les flux qui transitent en dehors des réseaux de l’entreprise doivent être sécurisés. Par exemple, la sécurité des flux provenant du Front-End et du Back-End doit être maximale… même au détriment de la performance. Cette dernière bien qu’importante, se doit d’être acceptable pour l’utilisateur.

Lire la suite