CI/CD avec l’API Management Azure

Publié le par Emmanuel LESNELaisser un commentaire sur CI/CD avec l’API Management Azure

Objectifs

L’intégration continue (CI) et le déploiement continue (CD) sont des pratiques indispensables aujourd’hui. Tant pour construire, déployer ou encore configurer une plateforme. Elles sont progressivement absorbées par les pratiques DevOps. Ces pratiques CICD ont pour principaux objectifs de:

  • automatiser le build des artefacts,
  • automatiser le déploiement de ces artefacts vers des environnements cibles.

Dans le cas de l’API Management pour Azure, il est nécessaire de déployer les éléments suivants:

  • les API et leurs contrats respectifs,
  • les Policies, stratégies ou traitements internes,
  • les BackEnds, cibles des API,
  • les NamesValues, ou tables de références externes.

Une version d’une API est alors la combinaison de tous ces éléments. C’est leur combinaison qui est le résultat d’un déploiement vers une plateforme de Recette ou de Production, par exemple.

Chaque API possède son propre cycle de vie. Les étapes de construction, de validation et de déploiement sont temporellement décorrélées les unes des autres API. Au quotidien, chaque API doit être gérée de manière unitaire.

Contextualisation ou Variabilisation

L’automatisation est un point important mais il s’accompagne systématiquement par la capacité à déployer dans plusieurs environnements. Pour cela, il est nécessaire d’intégrer des variables externes aux scripts CI/CD. Un livrable d’un environnement n’est donc pas égal à celui d’un autre.

Diffusion d’une API versionnée dans les environnements cibles.

Avec quels outils ?

Microsoft propose plusieurs outils, complémentaires ou non, pour supporter ces actions. La richesse et la multiplicité des solutions n’aide pas toujours…

Cet article détaille le résultat de mes travaux qui ont pour objectifs de mettre en place un socle de CI/CD complet et efficace pour l’ API Management Azure.

Lire la suite “CI/CD avec l’API Management Azure” →

Caches Infinispan sur Talend ESB

Publié le par Emmanuel LESNELaisser un commentaire sur Caches Infinispan sur Talend ESB

Il n’existe que peu de références pour mettre en place un cache Infinispan avec un ESB camel comme Talend ESB ou RedHat Fuse.

Après quelques travaux sur cette mise en oeuvre, je vous propose mon mode d’emploi. Ceci vous permettra de répartir des caches de données entre ces runtimes ESB.

Architecture de caches dans Talend ESB

Ce partage de collections peut être utilisé pour répondre à plusieurs besoins:

  1. Manipuler efficacement de grandes collections en mémoire en les chargeant que partiellement,
  2. Partager en temps-réel des données entre plusieurs processus,
  3. Distribuer des ressources mémoires en fonction de consommateurs multiples,
  4. Offrir une solution de Haute Disponibilité à moindre coût,
  5. Permettre des accès multiples à des ressources communes sans dé-duplication.

C’est ce dernier besoin qui m’a intéressé avec le besoin de permettre des consommateurs multiples de fichiers sFTP sans duplication.

Lire la suite “Caches Infinispan sur Talend ESB” →

De QuarkusIO à Kubernetes en 10 secondes

Publié le par Emmanuel LESNELaisser un commentaire sur De QuarkusIO à Kubernetes en 10 secondes

Le framework Quarkus regroupe, uniformise et simplifie le développement Java. A mes yeux, il représente l’avenir de la plateforme Java.

Cet article démontre comment Quarkus simplifie la gestion des applications dites de “nouvelles générations” en mettant à profit Docker, un packaging universel et standard, et Kubernetes, l’orchestrateur de ces applications.

Je vous montrerai comment, en quelques commandes, une application Java Quarkus peut être mise à disposition dans un cluster Kubernetes. Pour cet exemple, je construirai une des applications quickstart de Quarkus pour la déploier vers mon cluster local microk8s sous Ubuntu.

Mon Objectif est de 10 secondes pour passer du code Java à l’exécutable géré par Kubernetes !

Lire la suite “De QuarkusIO à Kubernetes en 10 secondes” →

Exemple d’ API avec WSO2 ESB

Publié le par Emmanuel LESNELaisser un commentaire sur Exemple d’ API avec WSO2 ESB

Je profite d’une expérience récente pour vous montrer, dans un cas pratique, les qualités de la solution ESB de WSO2. Pour le situer dans les produits de WSO2, ce bus est le coeur de l’ Enterprise Integration (Intermédiations de Systèmes) et de l’ API Management (Plateforme de partage d’API). En quelques mots, ce bus est spécialisé dans les intermédiations de services HTTP.

L’exemple que je vous propose est assez simple et est pour moi représentatif. Vous allez, je n’en doute pas, constater la lisibilité et la clarté des médiations réalisées avec cet ESB.

Le sujet que je vous propose est une API “utilisateur”. Elle présente des profils d’ utilisateurs. Elle puise ses données dans un annuaire Active Directory de Microsoft. Je ne m’attarde ici qu’à la médiation en tant que telle. Les outils WSO2 EI ou API Management portent d’autres fonctionnalités que je détaille pas dans cet article.

La conception de la route tient en 4 étapes:

  1. initialisation de la connexion LDAP,
  2. préparation de la requête,
  3. construction de la réponse.
  4. optionnel: la gestion d’erreurs.

Je vais dans la suite de cet article commenter cette API par étape, par bloc de code. Cela permettra de bien commenter chaque partie.

Lire la suite “Exemple d’ API avec WSO2 ESB” →

Déployer efficacement et gouverner simplement les intermédiations

Publié le par Emmanuel LESNELaisser un commentaire sur Déployer efficacement et gouverner simplement les intermédiations

L’intégration continue est un classique dans les enjeux actuels de productivité des développements logiciels. Elle est répandue et maîtrisée pour les technologies comme Java.

Pour l’intégration des médiations ESB et API, cet aspect est plus délicat. Un projet d’ intermédiation est un ensemble de routes, elles-mêmes composées de sous-éléments tels que les demi-interfaces. Le CD/CD des bus d’entreprise ou des API finissent par être très riches. Il est alors difficile de gérer les déploiements de Projets qui englobent plusieurs médiations.

Pour m’être confronté à ce problème plusieurs fois, je vous propose une solution efficace qui se veut simpliste, basée sur le concept de séparation des cycle de vie, le tout sur des produits Open Source.

Lire la suite “Déployer efficacement et gouverner simplement les intermédiations” →

Intégration/Déploiement Continue sur OpenShift

Publié le par Emmanuel LESNELaisser un commentaire sur 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 “Intégration/Déploiement Continue sur OpenShift” →

Gravitee sur OpenShift

Publié le par Emmanuel LESNE5 commentaires sur Gravitee sur OpenShift

Voici ma très courte procédure d’installation de la solution d’API Management Gravitee.io sur Openshift. Du simple et rapide comme j’aime 🙂 .

Objectif

Gravitee se compose de 2 DB: ElasticSearch et MongoDB ainsi que 3 modules: UI, API et Gateway.

Je souhaite avoir un environnement simple et bien compartimenté pour mes futurs projets d’API Gravitee, quelque chose comme ceci:

Lire la suite “Gravitee sur OpenShift” →