Blog

Agrément CIR renouvelé pour DocDoku jusqu’en 2022

Agrément CIR depuis 2011

Pour la quatrième fois consécutive, DocDoku obtient son agrément Crédit d’Impôt Recherche (CIR) pour trois an,  jusqu’en 2022 donc. Nous détenons en effet cet agrément depuis 2011.
Pour rappel, cela signifie que DocDoku est reconnu comme organisme ayant la capacité à mener des travaux de Recherche et Développement (R&D) et que toutes les dépenses de réalisation d’opérations de R&D confiées à DocDoku ouvrent droit au Crédit d’Impôt en faveur de la Recherche, dans les mêmes conditions que pour des investissements internes.

Le CIR, c’est quoi ?

Pour rappel, le CIR est un dispositif d’incitation fiscale en faveur de la recherche et de l’innovation. Il permet aux entreprises de bénéficier d’un crédit d’impôt correspondant à un pourcentage du montant des dépenses investies dans l’année en recherche et développement. Cet avantage fiscal varie entre 30% et 50% de Crédit d’Impôt sur les dépenses engagées pour les projets éligibles (voir conditions sur le site du Ministère).

Qu’attendons-nous pour innover ensemble ?

Qu’attendez-vous pour innover et lancer de nouveaux projets R&D puisque ces derniers peuvent faire l’objet d’une prise en charge substantielle au travers du Crédit d’Impôt Recherche lorsque vous passez par notre intermédiaire ?
Pour toutes questions sur vos projets innovants, contactez-nous.

FNE-Formation ou comment financer vos formations à 100% en chômage partiel

Vous êtes nombreux à vous interroger sur le dispositif FNE-Formation aujourd’hui renforcé à cause de la crise sanitaire que nous traversons.
L’objectif de cet article est donc de vous apporter toutes les réponses afin de bénéficier au mieux de ce dispositif.

Qui peut y avoir droit ?

Tous les salariés du privé placés en chômage partiel (les contrats d’apprentissage et de professionnalisation étant exclus) ! La formation doit par contre avoir lieu durant les heures et jours de chômage partiel, donc pas pendant les congés, RTT ou jours fériés.

Quel montant est pris en charge ?

La totalité des coûts pédagogiques est prise en charge. Il faut cependant savoir que les formations en dessous de 1500 euros TTC par salarié sont traitées de manière plus rapide et de manière quasi automatique au niveau de votre DIRECCTE régionale.
Au-dessus de 1500 euros TTC par salarié une instruction plus avancée doit être engagée.

Quels types de formation ?

Toutes les formations sont éligibles, à condition d’avoir lieu à distance et à l’exception des formations en alternance et obligatoires à la sécurité incombant à l’employeur.

Quelle est la procédure à suivre ?

Il y a deux procédures possibles :

N’hésitez pas à nous contacter si vous souhaitez en savoir plus ou vous lancer, toutes nos formations au catalogue étant bien entendu disponibles à distance.

Sources :

Chaîne DevOps intégrant Jenkins avec Ansible ou OpenShift (2/2)

Introduction

Le but de cet article est de présenter brièvement le concept de DevOps, illustré par une implémentation concrète dans un environnement applicatif de microservices Restfull, développés dans le contexte d’une approche agile.

La première partie est consacrée au rappel des principes de DevOps et à la présentation du schéma architectural d’une chaîne DevOps avec Github, Jenkins, Artifactory et Ansible.

Cette deuxième partie présente une autre chaîne DevOps avec Github, Jenkins, Artifactory et OpenShift.

1 Exemple d’une mise en oeuvre avec OpenShift

La chaîne DevOps décrite ci-dessous permet d’assurer des déploiements dans une plateforme de containers (OpenShift) sur différents namespaces  (§. 1.1 ci-dessous) : INT, VAL et PROD.

Elle est composée des éléments suivants :

  • GitHub
  • Git local installé sur chaque poste développeur
  • OpenShift qui héberge différents namespaces. Dans chaque namespace, un pod Jenkins pilote les builds (compilation/packaging) et le déploiement
  • Artifactory : repository des artifacts

Dans ce cas d’utilisation, tout se passe dans OpenShift, plateforme de containers. La plateforme est structurée en namespaces. Chaque namespace correspond à un environnement technique d’un projet (VAL, INT, PROD, …).

Chaque namespace (§. 1.1 ci-dessous) dispose de son propre pod Jenkins. Celui-ci exécute, à chaque update du projet dans Github (déclenchement par webhook), un job de type pipeline qui comporte plusieurs phases (stages) :

    1. Git clone du repository Github
    2. Build par maven (compilation –> tests unitaires –> tests intégration –> packaging)
    3. Audit du code par sonar
    4. Déploiement exécuté en fonction d’une build configuration et d’une deployment configuration (§. 1.1 ci-dessous)
      • Création d’une image docker à partir des sources de l’application
      • Création d’un pod (host exécutant le microservice) incluant le container de cette image
      • Génération du service, interface externe correspondant aux différents pods d’une application, et joue le rôle de répartiteur de charge
      • Génération des routes qui permettent d’accéder au service d’un pod

Exemple d’un dashboard de pipeline Jenkins, illustré ci-dessous :

Par ailleurs, OpenShift assure d’autres fonctionnalités opérationnelles :

  • Il gère les variations de charge de l’application par l’intermédiaire d’un replication controller: ajuste le nombre d’instances d’un pod en fonction de la charge.
  • Il assure le monitoring des applications qu’il héberge
  • Il gère les logs : logs des builds et logs applicatifs
  • Il permet via une interface Web d’accéder et d’administrer toutes ces fonctionnalités (§. 1.3 ci-dessous)

 

1.1    Notion de namespace dans OpenShift

La notion de namespace dans OpenShift vient de Kubernetes dont il est une sur-couche. Elle permet de regrouper dans un même espace de nommage les ressources qui décrivent une application et comment elle doit être déployée. La figure ci-dessous regroupe tous les éléments qui constituent un namespace :

Contrairement à Kubernetes qui permet d’accéder à tous les namespaces d’un cluster, OpenShift encapsule chaque namespace dans un projet qui va permettre d’en contrôler les accès par un modèle d’authentification et d’autorisations basé sur les users et les groups.

Il existe 3 canaux pour interagir avec un cluster Openshift à travers son API Rest : une CLI (ligne de commande) oc, une interface Web et l’API elle-même. Plus de détails dans la documentation OpenShift.

1.2    CLI (Ligne de commande) OpenShift

L’objet de ce document n’étant pas d’exposer en détail le fonctionnement d’OpenShift, on se contentera de montrer ci-dessous quelques vues du déploiement d’un service de base de données PostgreSql en exécutant des commandes oc. Dans le paragraphe suivant, on verra les vues relatives à ce service dans la console Web.

  • Déploiement d’une base PostgreSql

  • Affichage de la description du déploiement dc/my-database, créé par la commande précédente :

1.3    Console web OpenShift

Ci-dessous, quelques vues dans la console Web relatives au déploiement décrit dans le paragraphe précédent :

  • Description du déploiement dc/my-database : on voit une représentation du pod correspondant. Les flèches haut/bas (encadrée en rouge) permettent d’augmenter/diminuer manuellement le nombre d’instances du pod.

 

  • Vue des services : Outre le service my-database, on distingue un autre service, (microservice springboot) déployé qui utilise le service my-database

  • Vue d’une route (URL) pour accéder au microservice :

  • Vue du monitoring :

 En résumé

Dans cet article ont été rappelés les concepts de DevOps en relation avec une approche agile du développement d’applications. Deux schémas architecturaux de chaînes DevOps sont présentés ayant en commun les outils de versionning et de repositories (GitHub et Artifactory) ainsi que Jenkins comme pilote de l’intégration et du déploiement continus.

Dans cette deuxième partie, la chaîne DevOps présentée utilise OpenShift. Celui-ci joue les rôles à la fois d’une plateforme de containers et d’un cloud privé. A travers la notion de namespace encapsulé dans un projet, il gère les aspects droits d’accès, cycle de vie des applications, répartition de charges, gestion des logs et monitoring.

La première partie de cet artice est consacrée à la présentation d’une autre chaîne DevOps.  Elle utilise Ansible pour exécuter les déploiements sur les différents nœuds et environnements de l’application. Ansible est installé sur un nœud unique et permet via les playbooks et son interface Ansible Tower d’automatiser le processus de déploiement sur un grand nombre de nœuds (serveurs, périphériques, …).

 Pour en savoir plus

Chaîne DevOps intégrant Jenkins avec Ansible ou OpenShift (1/2)

Introduction

Le but de cet article est de présenter brièvement le concept de DevOps, illustré par une implémentation concrète dans un environnement applicatif de microservices Restfull, développés dans le contexte d’une approche agile.

La première partie est consacrée au rappel des principes de DevOps et à la présentation du schéma architectural d’une chaîne DevOps avec Github, Jenkins, Artifactory et Ansible.

La deuxième partie présente une autre chaîne DevOps avec Github, Jenkins, Artifactory et OpenShift.

1      Agile et DevOps main dans la main

Image result for devops

Le développement d’applications dans le cadre d’une approche agile impose des livraisons fréquentes au rythme des itérations,  tout en préservant la qualité des livrables, la maîtrise des releases et l’adaptabilité à différents environnements techniques et applicatifs. Pour répondre à ces exigences, l’automatisation des processus est nécessaire ainsi qu’une synergie entre les équipes de développement et celles des opérations. C’est là que DevOps apporte la solution à ces problématiques d’intégration continue (IC) et de déploiement continu (DC).

2     Les apports de DevOps

  • Fréquence des déploiements accrue
  • Délai d’exécution réduit pour les modifications
  • Récupération plus rapide en cas de problème
  • Une sécurité plus robuste et mieux intégrée
  • Qualité accrue
  • Feedback rapide

3      Les outils de DevOps

A chacune des étapes du workflow automatisé de DevOps correspondent des outils open source ou propriétaires (ci-dessous une liste non exhaustive) :

  • Versionning-commit de code : SVN, Git, TFS, GitHub, Tuleap
  • Qualité de code : SonarQube, IntelliJ, Eclipse
  • Sécurité : SonarQube, Checkmarx, dependency-check-maven
  • Tests : JUnit, Mockito, Selenium, Postman, Gatling, Jmeter
  • Build : Maven, NPM
  • Intégration/Déploiement/Livraison continus : Jenkins, Teamcity, Bamboo, TFS
  • Gestion des releases : Nexus, Artifactory
  • Déploiement : Ansible, Docker, OpenShift, Azure, AWS, VmWare
  • Performance, monitoring : Nagios, Zabbix, Spring boot Actuator
  • Logs : Splunk, Logstash, Elasticsearch

4      Exemple d’une mise en oeuvre avec Ansible

La chaîne DevOps décrite ci-dessous permet d’assurer des déploiements sur différents environnements techniques : INT, VAL et PROD.

Elle est composée des éléments suivants :

  • GitHub
  • Git local installé sur chaque poste développeur
  • Jenkins assure les builds (compilation/packaging)
  • Artifactory : repository des artifacts
  • Ansible assure les déploiements


Dans ce cas d’utilisation, un job Jenkins pilote le build (compilation, tests unitaires automatisés, audit de code par SonarQube, packaging). L’artifact résultant (un jar, dans le cas d’un microservice springboot) est uploadé dans Artifactory.

En post-action, le job va déclencher un script Ansible chargé de déployer le microservice dans les différents nœuds d’un cluster.

4.1    Concepts utilisés dans Ansible

Ansible permet d’automatiser les tâches de configuration et de déploiement des applications. Son administration se fait par le biais d’une interface Web, Ansible Tower.

Cette administration est centralisée dans une seule machine, le Control Node, où est installé Ansible. Aucune installation d’un agent n’est faite sur les autres machines gérées par Ansible (Managed nodes). Les concepts énumérés ci-dessous permettent de comprendre le fonctionnement de Ansible :

  • Inventory (inventaire) : liste des nœuds gérés, spécifiant des informations telles que les adresses IP. Cette liste peut être organisée selon différents critères : localisation, fonction, …
  • Module: c’est une unité de code Ansible spécialisée sur un type de fonctionnalités qu’on peut invoquer pour exécuter des tâches : administration des utilisateurs sur un type spécifique de base de données, gestion des interfaces VLAN sur un type spécifique de périphérique réseau, etc …
  • Task: c’est une unité d’action Ansible qu’on peut exécuter par une commande
  • Playbook: Liste ordonnée de tâches, enregistrées à exécuter à plusieurs reprises. Les playbooks peuvent inclure des variables ainsi que des tâches. C’est des fichiers écrits en YAML.
  • Roles : les rôles sont définis pour charger automatiquement des fichiers de configuration, tâches et gestionnaires. Ils sont organisés sous forme de fichiers dans des répertoires ayant un nommage et une structure pré-définis. Les rôles sont invoqués dans les playbooks (comme les imports dans un fichier java).

Exemple de mise en œuvre d’Ansible dans   Integrating Ansible with Jenkins in a CI/CD process.

  En résumé

Dans cette première partie,  ont été rappelés les concepts de DevOps en relation avec une approche agile du développement d’applications. Un premier schéma architectural de chaîne DevOps est présenté ayant comme outil de versionning et de repositories GitHub et Artifactory,  Jenkins comme pilote de l’intégration et du déploiement continus.

Cette chaîne utilise Ansible pour exécuter les déploiements sur les différents nœuds et environnements de l’application. Ansible est installé sur un nœud unique et permet via les playbooks et son interface Ansible Tower d’automatiser le processus de déploiement sur un grand nombre de nœuds (serveurs, périphériques, …).

Dans la deuxième partie, un autre schéma architectural d’une chaîne DevOps utilisant OpenShift sera présenté.

  Pour en savoir plus

Comprendre l’approche Cloud Native…pour bien la vendre en interne.

Selon la Cloud Native Computing Foundation (CNCF), fondée en 2015 par la Linux Foundation, les technologies Cloud Native permettent aux entreprises de créer et d’exécuter des applications scalables au sein d’environnements modernes et dynamiques tels que le Cloud public, privé ou hybride.

En guise d’exemple de technologies, on peut citer les containers, le service mesh, les microservices, les infrastructures immuables, l’intégration continue ou encore les APIs déclaratives. Les applications créées avec cette approche sont généralement basées sur une infrastructure en tant que service IaaS ou une plateforme en tant que service PaaS qui sera ensuite combinée avec les outils précédemment cités.

Une approche Cloud Native présente plusieurs avantages.
Tout d’abord, elle permet aux entreprises de transformer plus rapidement leurs idées d’applications en produits disponibles sur le marché. Elle permet non seulement d’accélérer les changements, mais aussi d’en réduire les risques.

En outre, les technologies Cloud Native permettent aussi une scalabilité accrue pour les applications. À mesure que les entreprises attirent de nouveaux utilisateurs dans un plus grand nombre de régions et sur un plus grand nombre d’appareils, il est possible de préserver la réactivité de l’application et de maintenir les coûts.

Un autre avantage majeur est qu’il permet généralement aux entreprises de dépenser moins d’argent dans l’hébergement. Ainsi, il est possible de réduire efficacement les charges.

Les applications Cloud Native requièrent une architecture très différente des applications d’entreprise traditionnelles, et c’est pourquoi elles présentent de nombreuses différences avec les applications sur site.

Tout d’abord, alors que les applications sur site conçues pour être exécutées sur les serveurs de l’entreprise sont généralement écrites dans des langages traditionnels (C/C++, C#…), les applications Cloud Native sont écrites dans des langages centrés web comme le HTML, le CSS, le Java, le JavaScript, le .net, le Go, le Node.js, le PHP, le Python ou le Ruby.

Les applis Cloud Native présentent aussi la particularité d’être toujours à jour et disponibles. De leur côté, les applications sur site requièrent des mises à jour durant lesquelles elles sont indisponibles, et sont généralement proposées avec un modèle d’abonnement par le vendeur.

En cas de pic d’utilisation, les applications Cloud Native peuvent profiter de l’élasticité offerte par le Cloud en utilisant davantage de ressources. Ces dernières peuvent ensuite être désactivées lorsque l’utilisation retourne à la normale. C’est une flexibilité dont ne disposent pas les applis sur site.

Une application sur source peut aussi être exécutée au sen d’un environnement virtualisé et partager des ressources avec d’autres applications. En cas de panne de l’un des Data Centers du fournisseur de Cloud, le stack peut être immédiatement transféré vers une autre région. Le risque de downtime est donc largement réduit par rapport à une application sur site.

Grâce au Cloud, la gestion des applications Cloud Native est entièrement automatisée grâce aux outils d’automatisation et d’orchestration. De plus, les applications Cloud Native présentent un design modulaire, car un grand nombre de leurs fonctions peuvent être décomposées en microservices. Il est donc possible de désactiver certaines fonctions ou de déployer des mises à jour pour des modules spécifiques plutôt que pour l’application complète.

Besoins de compétences Cloud Native ?

Faites appel au centre de compétences Cloud Native DocDoku ou développez vos compétences grâce à nos offres de formations DevOps Cloud Native.

Source : d’après un article de Bastien L publié sur LeBigData

Quelles perspectives pour Java et le développement Mobile ?

Quelles perspectives pour Java et le développement Mobile ?

C’est la question posée aux intervenants et participants de notre dernier ApéroTech du 14 novembre dernier à Toulouse.

A la découverte de Flutter 

Pour lancer l’ApéroTech sur le sujet du futur du développement Mobile, Thibaud a présenté une alternative à React Native : Flutter, lancé par Google. Les participants ont ensuite pu bénéficier d’une démo en live de l’API Spatioport pour découvrir les capacités du framework.

Retour d’experiences croisées sur Oracle Code One 2019

L’ApéroTech s’est poursuivi avec l’intervention d’Olivier et Bertrand, heureux participants du dernier Oracle Code One à San Francisco qui ont fait le point sur l’avenir de l’écosystème Java.
JVM, GraalVM, JakartaEE, Microprofile et Kubernetes : de multiples bouleversements accompagnent les mutations des environnements d’exécution.
Les impressions à chaud de Bertrand sont à retrouver sur son article ici.

Merci aux intervenants et participants pour leurs échanges et leur belle énergie !

Nous avons hâte de vous retrouver en mars 2020 pour une nouvelle édition.

Informations et inscriptions sur la page Meetup Les Z’ApéroTech.

8 thématiques incontournables à connaître pour maîtriser HTML5

L’HTML va bientôt fêter ses 30 ans. Ce langage de balisage a beaucoup évolué depuis sa création, avec l’intégration de JavaScript et CSS (Cascading Style Sheets) qui sont venus grossir les rangs des technologies web.
Et côté utilisateurs, dynamiser dans son ensemble la navigation web.

Développer des applications web modernes comme le permet HTML5 et CSS3 ne s’improvise pas.
Voici le top 8 des sujets incontournables à connaître pour maîtriser ce langage :

  • Une brique essentielle : JavaScript
  • Les API de communication
  • Le stockage côté client
  • Graphisme et multimédia
  • Les nouveaux tags HTML5
  • La présentation avec CSS3
  • Architecture et conception
  • L’outillage et l’environnement de développement

Vous êtes Architectes, développeurs ou webmasters et certains de ces sujets vous échappent encore ?

Nous avons une piste pour vous permettre de mettre à jour rapidement vos compétences : rejoignez notre prochaine session de formation Développer des applications HTML 5.

Prochaines sessions HTML5 à Toulouse :
Du 26 au 28 février 2020 (dernières places disponibles!)
Du 18 au 20 mai 2020

Prochaines sessions HTML5 à Paris :
Du 22 au 24 janvier 2020
Du 18 au 20 mars 2020

 

Collaboration et efficacité au quotidien avec Git

Vous êtes chef de projets, développeur ou architecte et vous cherchez à gérer vos sources de façons innovante et efficace ?

Vous avez sûrement entendu parler de Git, le système de contrôle de version distribué en licence Open Source.
Mais l’avez-vous concrètement utilisé ?
Et le maîtrisez-vous ?

Devenu incontournable, Git est un gestionnaire polyvalent capable de gérer aussi bien les petits que les très gros projets informatiques.
Des équipes de développement réparties géographiquement peuvent bénéficier des fonctionnalités de Git, en permettant à chacun de travailler de manière déconnectée et de se resynchroniser au moment voulu.

Git s’impose aujourd’hui dans de nombreuses organisations mais ses fonctionnalités avancées le rendent inévitablement plus complexe que les gestionnaires de sources traditionnels.
Pour répondre à cet enjeu et maîtriser ses fonctions surpuissantes, pourquoi ne pas vous former à Git ?

Constitués de 50 % de travaux pratiques, profitez de 2 jours pour revoir les fondamentaux de Git, son utilisation efficiente au quotidien, maîtriser la gestion des branches et son usage en équipe.

Informations et inscriptions ici.

Prochaines sessions 2019 :
Toulouse, du 4 au 5 novembre
Paris, du 2 au 3 décembre

Découvrez un éclairage différent sur la Blockchain

Saviez-vous que la technologie Blockchain proposait des solutions concrètes pour :

  • Assurer la véracité et la pertinence de vos données
  • Obtenir une vision globale de votre chaîne de valeur
  • Coordonner parfaitement des process Métier hétérogènes
  • Trouver des solutions à la complexité et l’étendue de votre Supply Chain ?

La Team DocDoku vous propose de partager son éclairage sur les usages concrets de la Blockchain au cours d’un petit déjeuner le Vendredi 18 octobre 2019 à partir de 8h30. Commencez votre journée en découvrant comment la Blockchain peut se mettre au service de votre Métier, au travers de cas d’usage concrets mais également de best practices métier et techniques.

Programme
8h30-9h : Accueil
9h-9h15 : Définir la Blockchain et identifier les projets « Blockchain ready »
9h15-9h45 : Découvrir un usage de la Blockchain dans l’Aéronautique (MRO)
9h45-10h00 : Comprendre les enjeux techniques
10h00-10h15 : Réflexions et perspectives
10h15-10h30 : Echanges avec les participants

Accès libre sur inscription réservé aux acteurs de l’innovation (CTO, DSI, Responsable Métier, R&D, Data…)

Informations pratiques
Quand ? Vendredi 18 octobre de 8h30 à 10h30
Où ? Chez DocDoku, 76 allée Jean Jaurès, 31 000 Toulouse

Inscrivez-vous en ligne ici

Quarkus : le framework Cloud Native révolutionnaire

L’écosystème Java est en plein renouveau. Oracle a officiellement acté son désengagement de Java EE (renommé Jakarta EE), les spécifications et leur implémentation de référence se font désormais sous l’égide de la fondation Eclipse et non plus au JCP (Java Community Process). Si ce chamboulement a pu générer quelques craintes et appréhensions quant au futur de la plateforme, aujourd’hui les conditions de passation de témoin entre Oracle et Eclipse semblent dorénavant établies (voir ici pour plus de détails sur l’imbroglio au sujet de l’utilisation du nom de package javax).

Place donc à la technique et je dois dire, pour vivre les choses de l’intérieur (nous sommes membres du consortium Jakarta) que la dynamique Jakarta est bien réelle. Le tournant micro-service a été pris avec conviction (il était temps), l’axe Cloud Native est clairement une priorité pour le consortium.

Jakarta poursuit l’oeuvre de standardisation de Java EE et offre aux développeurs le choix de l’implémentation. Nous avons toujours la filière traditionnelle avec un modèle basé sur le serveur d’applications. Mais surtout nous avons désormais la déclinaison Microprofile du standard. L’application ne nécessite alors plus de serveur pour fonctionner mais est packagée sous la forme d’une application autonome taillée pour les containers Dockers et les clusters Kubernetes. L’approche prise par la spécification Microprofile est particulièrement intéressante : conserver tels quels les modules Jakarta EE (CDI, JAX-RS, JPA…) et y adjoindre de nouveaux composants dédiés aux nouvelles problématiques découlant des architectures microservices. Notamment sont couverts les sujets liés à la tolérance à la panne, l’authentification par token JWT, la documentation Open API, les métriques et les traces, le Health Check, la génération de clients REST, l’intégration aux services de messaging… Bien sûr pour chacun de ces thèmes, il y a d’un côté la spécification des API et de l’autres les implémentations.

Cela nous amène à Quarkus qui est la nouvelle proposition Microprofile de Red Hat. Je dis nouvelle parce qu’il y a déjà Thorntail qui est la déclinaison Microprofile du serveur d’application WildFly. Quarkus lui, est une réécriture pensée véritablement pour l’approche Cloud Native. En effet, l’objectif ultime de Quarkus est de permettre la compilation native des applications grâce à GraalVM et ainsi corriger les deux faiblesses historiques de Java que sont l’empreinte mémoire et le temps de démarrage. A une époque pas si lointaine où le modèle d’exécution était le gros serveur d’applications pas ou peu redondé qui devait être redémarré le moins souvent possible, ces deux lacunes posaient peu de problème. Aujourd’hui le paradigme a changé, les applications sont découpées en plusieurs unités d’exécution (microservices) qui sont démarrées, répliquées, déplacées sur un cluster Kubernetes de nombreuses fois par jour (potentiellement tout du moins). Il est ainsi crucial que nos processus soient faiblement gourmands en ressources et puissent être lancés juste en une fraction de seconde.

Quarkus est encore jeune, la compilation native échoue plus souvent qu’elle ne réussit, mais ce n’est pas bloquant, il suffit alors de se rabattre sur une exécution classique JVM qui reste bien plus performante que n’importe quel serveur d’applications ou que Thorntail. Quarkus nous montre le futur des applications Java d’entreprise orientées Cloud Native. Si vous êtes intéressés, n’hésitez pas à échanger avec nous ou à vous inscrire à une de nos sessions de formation.

 

AWS IoT Greengrass et NBitcoin au menu du 3ème ApéroTech DocDoku

Le 27 juin dernier avait lieu la 3ème édition des ApéroTech dans nos locaux de Toulouse.

Au programme, présentation de 2 thèmes portés par des collaborateurs passionnés, suivie par un bon moment de convivialité en ce début d’été.

AWS IoT Greengrass

Premier thème abordé : comprendre ce qu’est le Edge Computing et ses applications.
Passionné de nouvelles technologies et persuadé des applications prochaines de l’internet des objets, Pierre a donné aux participants les clés de cette notion et présenté en cas d’usage le fonctionnement de Greengrass ou comment intégrer AWS dans un contexte IoT.

A la découverte de NBitcoin

Benjamin a ensuite guidé les participants dans la découverte de #NBitcoin pour #Csharp : de la construction d’une transaction Bitcoin à son transfert, puis à sa diffusion sur le réseau.  Au delà de l’usage en tant que cryptomonnaie, les perspectives de cette technologie sont très variées et l’assemblée a pu découvrir d’autres applications innovantes du Bitcoin.

Merci à nos deux talentueux orateurs et rendez-vous à la rentrée pour un prochain ApéroTech.

Bel été à toutes et tous !

Réaliser une transaction avec NBitcoin C# .NET

Introduction

  • Par soucis de « vulgarisation » et d’accessibilité au plus grand nombre, certains concepts clés évoqués dans cet article ont été « simplifiés » ou « raccourcis ». Il conviendra à chacun d’étoffer sa recherche à l’aide des liens fournis dans la rubrique « Ressources ».
  • Généralement, les présentations autour de Bitcoin commencent par une approche théorique des mécanismes permettant de sécuriser le réseau.
  • Dans cette présentation nous allons faire abstraction de tout cela → ?.
  • Nous allons  considérer la blockchain Bitcoin comme un service de stockage décentralisé que l’on va exploiter en mode Blockchain As a Service.
  • Nous consommerons ce service à l’aide de la librairie NBitcoin.net et de l’api QBitNinja.
  • Nous auront une approche pratique, qui consistera à programmer et signer un transfert Bitcoin entre deux adresses que nous allons créer.
  • La notion de « transfert » et de « vérification de propriété » est fondamentale pour le réseau Bitcoin puisqu’il à été spécialement conçu pour cela !
  • Tout en construisant notre transfert, nous découvrirons notamment à quoi servent une adresse, une clé privé, une clé publique et une transaction …

Généralités sur Bitcoin

  • Un système de transfert et de vérification de propriété,
  • Repose sur un réseau pair à pair,
  • Pas d’autorité centrale,
  • L’application initiale et l’innovation principale de ce réseau est un système de monnaie numérique décentralisé,
  • L’unité de compte au sein du réseau Bitcoin est nommée « Bitcoin »,
  • Bitcoin fonctionne avec des logiciels et un protocole,
  • Permet à ses participant d’émettre et de gérer des transactions de façon collective et automatique,
  • Un protocole libre et ouvert dont le code source est publié sous licence MIT,
  • Bitcoin est conçu pour s’auto-réguler,
  • Son bon fonctionnement est garanti par une organisation générale que tout le monde peut examiner,
  • Tout y est public : protocoles de base, algorithmes cryptographiques, programmes opérationnels, données de comptes, débats des développeurs …

Bitcoin Transfert : Problématique

  • Des fonds initiaux ont été envoyés à Bob,
  • Bob à réalisé un transfert de Bitcoin à Alice en lui laissant un message,
  • Nous allons recréer la transaction entre Bob et Alice à l’aide de NBitcoin,

Configuration du projet (.netCore + VSCode)

Auteur de NBitcoin et QBitNinja.Client : Nicolas Dorier, METACO SA

$ mkdir btcMeetup

$ cd btcMeetup

$ dotnet new console

$ dotnet add package NBitcoin

$ dotnet add package QBitNinja.Client

$ dotnet restore

Eléments fondamentaux

Pour réaliser un transfert sur le protocole Bitcoin, on s’appuie sur 5 éléments fondamentaux :

Private Key :

  • Permet de signer une transaction,
  • Donne le droit de dépenser les fonds liés à une adresse,
  • Ne doit pas être partagé, doit être conservé en lieu sûr.

Public Key :

  • Permet de s’assurer que vous êtes le propriétaire d’une adresse pouvant recevoir des fonds,
  • Est générée à partir de la clé privée (l’inverse étant « impossible ») Permet de s’assurer que vous êtes le propriétaire d’une adresse pouvant recevoir des fonds,
  • La clé public permet de générer une adresse bitcoin et un scriptPubKey.

ScriptPubKey :

  • C’est un peu l’équivalent d’une BitcoinAddress mais au niveau du protocole.
  • Vous n’envoyez donc pas des fonds à une adresse mais à un ScriptPubKey.
  • N’est pas facilement partageable contrairement à une adresse.

Bitcoin Address :

  • Pour recevoir un transfert de fonds,
  • Information facilement encodable en QR Code, 
  • Peut être communiquée à tout le monde.

Transaction :

  • Structure de données permettant d’encoder un transfert de valeur entre un ou plusieurs participants au réseau Bitcoin.

Générer une adresse pour Bob et une adresse pour Alice

Une adresse Bitcoin est une information que vous allez partager avec les autres utilisateurs du réseau pour recevoir des fonds.

Mais pour obtenir une adresse vous devez d’abord générer une clé privée !

  • Elle est le seul moyen de dépenser les bitcoins envoyés à votre adresse.
  • Les clés privées sont personnelles et ne sont pas stockées sur le réseau.
  • Elles peuvent être générées sans être connectées à internet.

NBitcoin supporte plusieurs standards pour générer des clés privées …

Nous allons utiliser les standards BIP32 et BIP39 qui permettent de générer une clé racine à partir d’une wordlist. C’est sur ce principe que fonctionnent les cold-wallets tel que Ledger Nano ou Trezor. Cette wordlist ou seed ou mnemonic permet de re-générer indéfiniment la même suite de clé.

Ci-après le processus de génération de clés que nous allons suivre :

Etape 1 : Générer une nouvelle mnémonique :

Etape 1 (bis) : Restaurer une mnémonique existante :

Etape 2 : On génère la clé racine  qui dérive de notre « Mnémonique » et d’un mot de passe :

Etape 3 : On peut maintenant générer deux « sous-clés », une pour  Bob, une pour Alice, en dérivant de notre clé racine :

Remarque : Grâce à ce mécanisme de dérivation, il est possible de générer et régénérer des arborescences complexes de clés. On peut par exemple construire une arborescence de clés basées sur l’organigramme d’une entreprise.

Etape 4 : A partir de nos deux clés privées, nous allons pouvoir obtenir leurs clés publiques respectives :

  • On génère une clé publique à partir d’une clé privée au moyen d’une fonction à sens unique.
  • C’est à dire une fonction qui peut aisément être calculée mais difficilement inversée.
  • La clé publique permet de recevoir des fonds et d’attester que vous être le propriétaire d’une adresse.
  • En revanche, elle ne permet pas de dépenser les fonds d’une adresse.

Etape 5 : Après avoir généré les clés publiques d’Alice et Bob, nous allons pouvoir obtenir leurs adresses :

  • Il existe 2 réseaux Bitcoins : MainNet et TestNet,
  • On obtient une adresse Bitcoin à partir de sa clé publique, et en précisant le réseau sur lequel on souhaite opérer.
  • Remarque: sur le MainNet, les erreurs peuvent coûter cher ? !

Etape 6 : Consulter les comptes de Bob et d’Alice :

Adresse de Bob : 16joUFCsaVDfacYsDxCm2oF5mRyLTq6DvY

Adresse d’Alice : 13hA6HP6W4BCwmtr89CKh6fTra19Exm4bL

Si on regarde d’un peu plus près les informations fournies par BlockCypher concernant l’adresse de Bob, on peut remarquer deux choses plutôt curieuses au premier abord :

  • la différence entre le total des inputs et des outputs (0.000355 BTC) → Frais de minage.
  • Bob se renvoie à lui même une partie des fonds impliqués dans la transaction → Tous les fonds impliqués doivent être dépensés.

Etape 7 : Analyser une transaction Bitcoin

Pour envoyer des fonds de Bob vers Alice, il va donc nous falloir construire une transaction et la soumettre au réseau Bitcoin.

Les transactions sont au coeur du système Bitcoin, elles contiennent les informations relatives aux transferts de valeur entre les participants du réseau.

Pour envoyer des fonds à Alice, il va donc falloir faire référence à l’output d’une transaction qui à transféré des fonds initiaux à Bob et que ce dernier n’à pas dépensé …

En consultant la dernière transaction liées à l’adresse de Bob, on retrouve rapidement cette information :

Notre nouvelle transaction va donc « s’accrocher » à l’output non dépensé de celle-ci !

QBitNinja va nous permettre de récupérer ces informations afin de les manipuler dans notre application console.

Etape 8 : Récupérer une transaction stockée sur la blockchain avec le client QBitNinja :

Affichons l’intégralité de la transaction :

Résultat :

Etape 9 : Construire la transaction Bitcoin

Maintenant que l’ont sait quoi dépenser, on peut commencer à construire notre nouvelle transaction :

Et ajouter un nouvel input à cette nouvelle transaction :

Si on visualise notre transaction à ce stade, on obtient :

Voyons maintenant comment dépenser notre input …

On calcule la répartition des fonds entre les différents Outputs de notre future transaction en respectant le fait que :

  • tous les fonds en input de la transaction doivent être dépensés,
  • la différence entre le montant total des inputs et des outputs sera reversé au mineur,
  • des frais de minages trop faibles entrainent un traitement plus long de la transaction (voire elle n’est jamais traitée),

Pour calculer les frais de minages on peut directement chercher sur google :

  • plus vous payez, plus vite est traitée votre transaction,
  • il s’agit d’une moyenne, le prix est fixé en fonction du poids de votre transaction.
  • si vous ajoutez un message, vous devrez augmenter les frais.
  • pour calculer les frais adéquats :

https://bitcoinfees.earn.com/ (coût par byte)

La répartition des fonds entre les différents outputs est prête, on peut les créer et les ajouter à notre transaction :

Etape 10 : Joindre un message à votre transaction

Output contenant le message :

  • On peut donc stocker une information sans forcément transférer de la valeur, du moment que les frais de minage sont couverts !
  • Ce message est inaltérable et incensurable.
  • Vous payez pour écrire ce message, mais sa lecture est « gratuite », par n’importe qui ou n’importe quoi ayant accès au réseau Bitcoin.

Etape 11 : Signer la transaction avec votre clé privée :

Avant de pouvoir diffuser votre transaction, vous devez d’abord la signer à l’aide de votre clé privée :

Etape 12 : Diffuser la transaction sur le réseau Bitcoin :

Il est désormais temps de diffuser notre transaction au réseau !

Pour cela, il faut la transmettre à un noeud du réseau,

Plusieurs options s’offrent à vous :

  • Copier le code Hexadécimal de votre transaction et le pusher via un explorateur de blocks tel que BlockCypher :
  • Passer par l’API QBitNinja :

Etape 13 : Consulter l’état de la transaction diffusée :

Pour consulter l’état de notre transaction diffusée, rendez-vous sur un explorateur de Block tel que BlockCypher :

Transaction ID : a9172485a20e06b9a745f5105cd23cabd9f866e890b0bd4c25c3d29c073cce14

Si on consulte l’adresse d’Alice :

Conclusions et perspectives

L’application première du réseau Bitcoin est l’échange de la cryptomonnaie du même nom.

D’ailleurs sur ce réseau tout se paye en Bitcoins.

Mais il peut également servir à autre chose (et NBitcoin supporte tout cela):

  • stocker des données de façon indélébile et non-censurable,
  • émettre et détruire votre propre « tokens » pour représenter les parts d’une entreprise, des actions ou des votes,
  • attacher un « contrat ricardien » à un token (une sorte de smart contract lisible par l’homme et destiné au monde juridique).

Le protocole est en perpétuelle évolution et vise à devenir de plus en plus efficient (plus rapide, moins coûteux).

Il est également à noter que le coût de transaction n’est pas proportionnel au montant transféré et dépends de la « taille » en bytes de votre transaction. Ainsi, transférer 10$ ou 10M$ aura un coût de transaction équivalent !

Si aujourd’hui la lenteur et les frais de transaction élevés limite l’usage du réseaux, des mises à jour comme le « Lightning Network » ont le potentiel de changer la donne et maintenir Bitcoin sur le devant de la scène.

Ressources :

Programming the Blockchain in C# (Nicolas Dorier, Metaco SA)

NBitcoin (Nicolas Dorier, Metaco SA)

QBitNinja (Nicolas Dorier, Metaco SA)

Stratis Platform (Blockchain As A Service / BaaS, C# Smart-Contracts)

Microsoft Visual Studio Code (IDE)

IoT et Agriculture, SAFe et les secrets de JakartaEE8

Une nouvelle édition des ApéroTech a réuni il y a quelques jours une trentaine de passionnés de technologie dans les locaux de DocDoku à Toulouse.

IoT, méthodologie projet et programmation ont été les thèmes choisis et présentés par des intervenants particulièrement enthousiastes (et ce, alors que la partie Apéro n’avait pas encore commencé 😉 )

Les participants ont ainsi pu découvrir et échanger sur :

IoT : à la découverte d’une sonde connectée dernière génération.

Junior a immergé les participants dans la conception et le fonctionnement d’un device et de sa plateforme associée. Conçue en collaboration avec des agriculteurs pour connaître les besoins des sols en fonction des plantes cultivées, le projet présenté utilisait les technologies bluetooth4.0, Lorawan, Objenious, REST, PostgreSQL et Rails.

L’agilité à l’échelle de l’entreprise avec SAFe.

Bertrand a donné aux participants les clés de cette méthodologie, ses avantages, dans quels contextes l’utiliser sans toutefois oublier ses limites.

Les nouveautés de la plateforme #JavaEE ou plutôt #JakartaEE 8 .

Florent a fait le point sur les grandes familles de nouveautés à retrouver dans cette nouvelle plateforme : l’alignement entre modules, les nouveaux standards Web, les nouveaux modules…

Le prochain ApéroTech aura lieu le jeudi 18 avril à Paris.
Renseignez-vous et téléchargez votre invitation gratuite.

Mise en oeuvre de la Haute disponibilité dans PostgreSQL

Rappels de quelques notions

Avant d’aborder le sujet de la HA (High Availability), il est utile de rappeler quelques principes qui vont être utilisés dans la suite de cet exposé.

RPO et RTO

Il existe plusieurs méthodes de sauvegarde d’une base de données PostgreSQL, chacune présentant des avantages et des inconvénients eu égard à la volumétrie des données, à la granularité des sauvegardes qu’on veut réaliser, à la cohérence des données sauvegardées, au transfert des données entre différentes versions de PostgreSQL et entre machines d’architectures différentes. Par ailleurs, on distingue deux types de sauvegardes : les sauvegardes logiques et les sauvegardes physiques.

Une sauvegarde logique consiste à archiver les commandes sql qui ont servi à générer la base et à les rejouer pour la restauration de celle-ci. Pour celà, il existe 2 commandes dans PostgreSQL : pg_dump et pg_dumpall. On trouvera plus de détails sur ces commandes dans  la documentation de PostgreSQL https://www.postgresql.org/docs/10/backup.html.

Une sauvegarde physique ou sauvegarde au niveau du système de fichiers consiste à archiver les répertoires des données de la base en utilisant les commandes de copie ou d’archivage des fichiers du système d’exploitation : tar, cp, scp, rsync, … On peut aussi réaliser une “image gelée” (frozen snapshot) du volume contenant la base de données et ensuite copier entièrement le répertoire de données (pas seulement quelques parties) de l’image sur un périphérique de sauvegarde, puis de libérer l’image gelée.

Les objectifs d’une bonne procédure de sauvegarde sont exprimés par deux métriques :

  • le RPO (Recovery Point Objective) : représente la quantité maximum de données qu’on peut tolérer de perdre suite à un incident de la base de données.
  • le RTO (Recovery Time Objective) : représente la durée maximum d’une interruption de service qu’on peut tolérer, le temps de restaurer la base et la remettre en service.

L’objectif idéal étant que ces 2 paramètres soient nuls, PostgreSQL propose des approches qui permettent de s’en approcher. Elles sont basées sur la mise en oeuvre de l’archivage continu et la récupération  d’un instantané (PITR : Point In Time Recovery).

Archivage continu et PITR

Cette approche est basée sur l’utilisation des journaux WAL (Write Ahead Log), appelés aussi journaux des transactions. Ils enregistrent chaque modification effectuée sur les fichiers de données des bases. Ils sont stockés dans le sous-répertoire pg_wal/ du répertoire des données du cluster.

La sauvegarde consiste à combiner une sauvegarde de niveau système de fichiers avec la sauvegarde des fichiers WAL.

La restauration consiste à restaurer les fichiers de la base puis de rejouer les fichiers WAL sauvegardés jusqu’à emmener la base à son état actuel.

Avantages :

  • Il n’est pas nécessaire de disposer d’une sauvegarde des fichiers parfaitement cohérente comme point de départ. Toute incohérence dans la sauvegarde est corrigée par la ré-exécution des journaux
  • Puisqu’une longue séquence de fichiers WAL peut être assemblée pour être rejouée, une sauvegarde continue est obtenue en continuant simplement à archiver les fichiers WAL. C’est particulièrement intéressant pour les grosses bases de données dont une sauvegarde complète fréquente est difficilement réalisable.
  • Les entrées WAL ne doivent pas obligatoirement être rejouées intégralement. La ré-exécution peut être stoppée en tout point, tout en garantissant une image cohérente de la base de données telle qu’elle était à ce moment-là. Ainsi, cette technique autorise la récupération d’un instantané (PITR) : il est possible de restaurer l’état de la base de données telle qu’elle était en tout point dans le temps depuis la dernière sauvegarde de base.
  • Si la série de fichiers WAL est fournie en continu à une autre machine chargée avec le même fichier de sauvegarde de base, on obtient un système « de reprise intermédiaire » : à tout moment, la deuxième machine peut être montée et disposer d’une copie quasi-complète de la base de données.

Contraintes :

  • approche plus complexe à administrer
  • ne supporte que la restauration d’un cluster de bases de données complet, pas d’un sous-ensemble
  • espace d’archivage important requis : si la sauvegarde de base est volumineuse et si le système est très utilisé, ce qui génère un grand volume de WAL à archiver.

La réplication

Dans une architecture maître-esclave, le transfert des données de base et des WAL (Log shipping) peut se configurer de 3 manières légèrement différentes :

  • Warm Standby : les fichiers des transactions (WAL) archivés sont transférés du maître vers l’esclave par copie et rejoués, avec un retard d’un fichier WAL (16 MB) par rapport au maître. La perte éventuelle de données ne peut donc excéder 16 MB. Dans cette configuration, la base esclave n’est pas accessible.
  • Hot Standby : le fonctionnement est identique au Warm Standby. La différence est que la base esclave est accessible en lecture seule.
  • Streaming Replication :  dans cette configuration, chaque transaction est transférée vers la machine esclave via le réseau, et rejouée, sans attendre que le fichier WAL soit complété.  Ainsi, le RPO est quasiment nul (une transaction perdue au maximum dans une réplication asynchrone, 0 dans une réplication synchrone).

Tolérance à panne

La tolérance à panne (failover) est la capacité d’un système à maintenir un état de fonctionnement en dépit d’une défaillance logicielle ou matérielle. Elle est rendue possible par la réplication. Nous étudierons ici les moyens à mettre en oeuvre pour assurer une continuité de service en toutes circonstances.

Gestion du Failover avec repmgr

Une Architecture Maître/Esclave sert à gérer les situations de failover où la machine Esclave prend le relais en cas de défaillance de la machine Maître.

Pour ce faire, une réplication continue est instaurée entre les 2 machines de telle façon que les données des 2 machines soient quasiment identiques à chaque instant.

Pour pouvoir gérer en plus,  la capacité de déclencher la bascule (le failover) automatiquement, il existe plusieurs outils dans l’écosystème PostgreSQL tels que repmgr. Celui-ci peut-être utilisé seul ou en conjonction avec d’autres outils de backup comme BARMAN (Backup and Recovery Manager for PostgreSQL) développé par 2ndQuadrant (https://www.2ndquadrant.com/) avec une licence GPL v3, dont la dernière version est la 2.5 du 23/10/2018 (http://www.pgbarman.org/).

Présentation de repmgr

repmgr est une suite d’outils open source développés par 2dQuadrant ( https://repmgr.org/docs/4.2/index.html) qui mettent en oeuvre la réplication native de PostgreSQL et qui permettent de disposer d’un serveur dédié aux opérations de lecture/écriture (Primary ou Maître) et d’un ou plusieurs serveurs en lecture seule (Standby ou Esclave). Deux principaux outils sont fournis :

  • repmgr : outil en ligne de commandes pour les tâches d’administration :
    • configuration des serveurs standby
    • promotion d’un serveur standby en primary
    • inverser les rôles des deux serveurs (switchover)
    • afficher les statuts des serveurs
  • repmgrd : deamon qui supervise l’état des serveurs et qui permet de :
    • surveiller les performances
    • opérer un failover quand il détecte la défaillance du primary en promouvant le standby
    • émettre des notifications sur des événements qui peuvent survenir sur les serveurs à des outils qui vont déclencher des alertes (mail par exemple)

Architecture

Pré-requis système

  • Linux/Unix
  • repmgr 4.x compatible avec PostgreSQL 9.3+
  • La même version de PostgreSQL sur tous les serveurs du cluster
  • repmgr doit être installé sur tous les serveurs du cluster, au moins dans la même version majeure*
  • les connections entre serveurs doivent être ouvertes sur leurs ports respectifs
  • les accès ssh par échange de clés publiques pour le user postgres de chacun des serveurs doivent être configurés.

Installation

L’installation se fait pour :

  • RedHat/CentOS/Fedora à partir du repository yum de 2ndQuadrant
  • Debian/Ubuntu à partir des repository APT de postgreSQL (http://apt.postgresql.org/) ou du repository APT de 2ndQuadrant (https://dl.2ndquadrant.com/default/release/site/)

Pour la version 10 de PostgrSQL :

sudo apt-get install postgresql-10-repmgr

Configuration de PostgreSQL

Les exemples ci-dessous concernent une version 10.x de PostgreSQL

Ajuster les paramètres ci-dessous dans les fichiers de configuration des PostgreSQL (postgresql.conf) :

  # Enable replication connections; set this figure to at least one more
   # than the number of standbys which will connect to this server
   # (note that repmgr will execute `pg_basebackup` in WAL streaming mode,
   # which requires two free WAL senders)

 max_wal_senders = 10

   # Enable replication slots; set this figure to at least one more
   # than the number of standbys which will connect to this server.
   # Note that repmgr will only make use of replication slots if
   # « use_replication_slots » is set to « true » in repmgr.conf

max_replication_slots = 3

   # Ensure WAL files contain enough information to enable read-only queries
   # on the standby.
   #
   # PostgreSQL 9.5 and earlier: one of ‘hot_standby’ or ‘logical’
   # PostgreSQL 9.6 and later: one of ‘replica’ or ‘logical’
   # (‘hot_standby’ will still be accepted as an alias for ‘replica’)
   #
   # See: https://www.postgresql.org/docs/current/static/runtime-config-wal.html#GUC-WAL-LEVEL

wal_level = replica

   # Enable read-only queries on a standby
   # (Note: this will be ignored on a primary but we recommend including
   # it anyway)

hot_standby = on

   # Enable WAL file archiving
archive_mode = on

   # Set archive command to a script or application that will safely store
   # you WALs in a secure place. /bin/true is an example of a command that
   # ignores archiving. Use something more sensible.
 archive_command = ‘/bin/true’

Création du user repmgr et du schéma repmgr

Le schéma repmgr sert à enregistrer les données de monitoring de repmgr. On y accède avec le user repmgr. Ils doivent être créés sur chacun des instances des serveurs :

sudo -i -u postgres

psql -p 5432

create role repmgr with password ‘password123’ ; alter role repmgr login ; alter role repmgr replication ; alter role repmgr superuser;

CREATE DATABASE repmgr OWNER repmgr;

Configuration de pg_hba.conf

L’objectif de cette configuration est de permettre au user repmgr de se connecter en mode replication :

 local   replication   repmgr                       trust
 host    replication   repmgr 127.0.0.1/32            trust
 host    replication   repmgr 195.154.39.0/24      trust

  local   repmgr      repmgr                       trust
  host    repmgr      repmgr 127.0.0.1/32             trust
  host    repmgr      repmgr 195.154.39.0/24         trust

Vérifier que la base sur le serveur primaire est joignable à partir du serveur standby :

psql ‘host=195.154.39.62 user=repmgr dbname=repmgr connect_timeout=2’

Configuration de repmgr dans le noeud primaire

La configuration se fait dans le fichier /etc/repmgr.conf aux niveau du primaire (node_id=1, node_name=val) et du standby ((node_id=2, node_name=customers).

Remarques :

  • Les paramètres indiqués ci-dessus sont les paramètres de base pour un fonctionnement standard de repmgr. On trouvera d’autres paramètres disponibles dans le fichier repmgr.conf.sample  fourni dans la distribution.

Enregistrement du serveur primaire

L’enregistrement du serveur primaire auprès de repmgr va créer les métadata dans le schéma repmgr et y initialisera un enregistrement correspondant au serveur primaire :

  • Avec le user postgres , exécuter la commande suivante :
  • $ repmgr -f /etc/repmgr.conf primary register
  • Vérifier le statut du cluster avec  la commande suivante :

Les metatda sont affichés  avec la commande suivante :

Configuration du serveur standby

Créer le fichier de configuration /etc/repmgr.conf, similaire à celui du primaire. Il diffère essentiellement par le n° et le nom du noeud ainsi que la chaîne de connexion conninfo :

Clonage du serveur standby

On exécutera la commande de clonage en dry-run pour s’assurer que toutes les conditions de succès sont satisfaites :

  • postgres@customers:~$ repmgr -h 195.154.39.62 -U repmgr -d repmgr -p 5434 -f /etc/repmgr.conf -F standby clone –dry-run

Si pas de problème rapporté, exécuter la même commande sans l’option dry-run :

  • postgres@customers:~$ repmgr -h 195.154.39.62 -U repmgr -d repmgr -p 5434 -f /etc/repmgr.conf -F standby clone
  • Si le clonage s’est bien terminé , vérifier que la réplication se passe bien.
    • Dans le serveur primaire, exécuter la commande suivante :
  • Dans le serveur standby, exécuter la commande suivante :

  • Enregistrer le standby :

postgres@customers:~$  /usr/lib/postgresql/10/bin/repmgr standby register

  • Vérifier que le standby est enregistré :

Vérifier que tout fonctionne

  • Créer une table sur le maître :

CREATE TABLE rep_test (test varchar(40));

INSERT INTO rep_test VALUES (‘replique moi);

  • Vérifier qu’elle est répliquée dans le standby:

SELECT * FROM rep_test;

Failover automatique avec repmgrd

Dans le schéma ci-dessus, si val est indisponible , customers est promu en primary, et en mode read-write. Ce failover peut être exécuté manuellement avec 2 commandes de repmgr :

  • Au niveau de customers : /usr/bin/repmgr standby promote -f /etc/repmgr.conf –log-to-file
  • Au cas où il y aurait plusieurs serveurs standby, on exécute au niveau de chacun une commande de follow, qui leur indique le nouveau serveur maître :

/usr/bin/repmgr standby follow -f /etc/repmgr.conf –log-to-file –upstream-node-id=2

Le daemon repmgrd permet de surveiller l’état des serveurs du cluster et de déclencher automatiquement les 2 opérations décrites ci-dessus.

Configuration de repmgrd

  • Pour utiliser repmgrd, inclure la librairie associée via la configuration de postgresql.conf :

shared_preload_libraries = ‘repmgr’

  • ajouter dans /etc/repmgr.conf les lignes suivantes :

failover=automatic

promote_command=’/usr/lib/postgresql/10/bin/repmgr standby promote -f /etc/repmgr.conf –log-to-file’

follow_command=’/usr/lib/postgresql/10/bin/repmgr standby follow -f /etc/repmgr.conf –log-to-file –upstream-node-id=%n’

monitoring_history=yes

  • Si repmgr a été installé à partir des packages de Debian/Ubuntu, il faudra configurer pour que repmgrd tourne en daemon, via le fichier /etc/default/repmgrd , dont le contenu est le suivant :

Démarrage de repmgrd

Pour démarrer repmgrd, exécuter la commande suivante sur chacun des serveurs, en tant que postgres :

/usr/lib/postgresql/10/bin/repmgrd -f /etc/repmgr.conf

Vérification du fonctionnement du failover

En considérant l’architecture à 2 serveurs ci-dessus , effectuer les opérations suivantes :

  • Statut du départ :
  • Après le démarrage de repmgrd sur les 2 serveurs, vérifier sur leurs logs respectifs qu’ils sont bien actifs
  • Arrêter le serveur primaire :

/usr/lib/postgresql/10/bin/pg_ctl stop -D /var/lib/postgresql/10/main

  • Vérifier de nouveau le statut du cluster :

On remarque que le noeud 2 est devenu primaire.

  • Une fois, val  “réparé”, le retour à la situation initiale s’effectue en 2 temps : d’abord mettre val comme standby du primaire customers puis faire un switchover sur val pour qu’il redevienne primaire et customers redevient standby :
  • Cloner val à partir de customers et l’enregistrer comme standby :

postgres@val$ /usr/lib/postgresql/10/bin/repmgr -h 195.154.39.117 -p 5433 -U repmgr -d repmgr -f /etc/repmgr.conf standby clone –force

  • Redémarrer val :

postgres@val$ pg_ctlcluster 10 main start

  • enregistrer val en standby :

postgres@val$ /usr/lib/postgresql/10/bin/repmgr standby register –force

  • Vérifier l’état du cluster :

On constate que le cluster fonctionne avec customers comme primaire et val comme standby.

Pour inverser les rôles, on fait un switchover sur le standby :

  • Vérifier l’état du cluster

Remarque : le switchover agit sur le standby et sur les autres serveurs pour qu’ils soient avertis du nouveau primaire.

Conclusion

Ce post a permis d’exposer pas à pas les étapes pour configurer une HA sur un cluster à 2 noeuds, en mode primaire/standby. Pour ce faire, on a mis en oeuvre une streaming réplication avec repmgr et un monitoring des 2 noeuds avec le daemon associé à repmgr, ce qui permet de déclencher le failover automatique en cas de défaillance du noeud primaire. Le retour à la configuration initiale, après réparation de la défaillance, est réalisé avec un switchover. Le protocole de streamaing réplication permet de minimiser le RPO car il permet de rejouer les transactions au fil de l’eau au niveau du standby. Pour minimiser le RTO, il faut ajuster la fréquence des backup de base en fonction de la volumétrie des transactions.

La configuration qui a été présentée ici, peut être renforcée par un système de load balancing par un outil tiers dans le cas général , style pgpool-II ( http://www.pgpool.net ) ou par le driver jdbc si on est dans l’écosystème java.

Les Feature Toggles* : Activer / Désactiver dynamiquement une fonctionnalité d’un logiciel

* La désignation ne fait pas consensus et la liste des termes synonymes est très longue : Feature Flag, Feature Switch, Conditional Feature, Feature flipper, Feature Bits, Gatekeepers….

Le principe

À la livraison d’une nouvelle version d’un logiciel sur un environnement, toutes les nouvelles fonctionnalités sont rendues disponibles immédiatement. Au contraire, le modèle de design Feature Toggle* a pour but de fournir un interrupteur de fonctionnalités qui active ou désactive une partie du code sans nécessiter ni redéploiement ni redémarrage de l’application.

Les usages possibles

Cette fonctionnalité peut avoir de nombreux usages. Les cas suivants en sont un exemple et ne représentent pas l’exhaustivité des situations.

CAS 1 – Différents besoins sur différents environnements

Pratiquer des livraisons régulières, fréquentes et de petite taille est une des conditions à garantir pour l’agilité d’un projet (Continuous Delivery). L’enjeu est le maintien d’un cycle de développement court pour limiter les risques du rythme élevé de changements. Or si cette stratégie s’avère un atout en environnement de recette, où la validation de petites briques logicielles réduit la durée de la phase de tests, elle peut être difficile à réaliser en environnement de production. En effet, une fonctionnalité peut représenter plusieurs itérations de développements et il serait incongru de la mettre à disposition de l’utilisateur de façon incomplète. Le système de feature toggles rend possible la livraison de parties de fonctionnalités en mode désactivé sans que cela n’affecte la stabilité du code. L’activation pourra être réalisée au bout de quelques semaines, une fois que l’ensemble du code nécessaire aura été livré.

CAS 2 – Incident suite à une livraison

Lorsqu’un dysfonctionnement est rencontré en production par un utilisateur suite à une récente livraison, il sera possible de désactiver la fonctionnalité pour réduire l’instabilité du logiciel en attendant une résolution.

CAS 3 – Dépendances entre équipes

Il n’est pas rare que plusieurs équipes travaillent en parallèle sur des besoins différents et dans des délais qui leur sont propres tout en ayant en commun une ou plusieurs applications. Par exemple, l’interface peut être la même pour toutes les équipes. Lorsque le moment est venu pour une équipe de livrer son travail, elle se trouve gênée par les développements encore en cours ou en validation des autres équipes sur l’application partagée. Si chaque équipe a mis en place des toggles,  la livraison sera envisageable à la condition que chaque fonctionnalité non encore terminée soit désactivée.

CAS 4 – Tests comparatifs

Il existe une catégorie de Feature toggles dont l’activation se fait par utilisateur. La condition d’activation peut être déterminée par un profil de permissions ou encore l’appartenance à un échantillon. Au lieu de plusieurs environnements, un seul est nécessaire pour comparer des résultats entre différents groupe d’utilisateurs et valider une approche.

AUTRES CAS – L’activation de fonctionnalités peut aussi…

  • concerner la configuration d’un système opérationnel déjà en service afin de déterminer les meilleurs paramètres (court terme) ou bien de maintenir un service stratégique au détriment d’un autre en dégradant les performances à son profit (long terme)
  • être amenée à rester sur le long terme dans le cas du besoin de customisation de fonctionnalités par utilisateur (par exemple un mode « utilisateur premium»)

Selon Martin Fowler 1 – son blog, il existe deux axes de qualification pour un feature toggle, son dynamisme (changements au déploiement / à chaud / par requête) et sa longévité (nombre de jours / mois / années). Cette classification doit orienter vers le choix d’une implémentation.

Un rapide aperçu avec FF4J

FF4J  (Feature Flipping for Java) est un framework en licence libre apache 2.

Une fois les dépendances nécessaires ajoutées (ff4j-core, junit, ff4j-web) et la configuration paramétrée, il faudra créer un service fournissant une instance de la classe FF4J.

Étape 1. Créer un feature toggle

Cela consiste à insérer une nouvelle entrée dans un feature store (le système de stockage) précisant l’identifiant du toggle, sa description, son statut d’activation, son groupe d’appartenance, les rôles d’utilisateurs ou les stratégies associés. L’offre de système de stockage des données est large : mémoire, bases relationnelles ou no-sql.

CREATE TABLE FF4J_FEATURES (
  "FEAT_UID"            VARCHAR(100),
  "ENABLE"              INTEGER NOT NULL,
  "DESCRIPTION"         VARCHAR(1000),
  "STRATEGY"            VARCHAR(1000),
  "EXPRESSION"      VARCHAR(255),
  "GROUPNAME"           VARCHAR(100),
  PRIMARY KEY("FEAT_UID")
);

ci-dessus : Table prévue pour le stockage en base relationnelle, le champ « enable » stocke 1 pour le statut « activé » 0 pour « désactivé ».

Étape 2. Utiliser le feature toggle dans le code

L’identifiant choisi à l’étape 1 permettra de vérifier l’état d’activation.

If (ff4j.check("id.du.toggle")) {
	doBehiavorA()
}  else {
	doBehiavorB()
}

ci-dessus : si le toggle est activé alors le comportement A est joué sinon le comportement B fonctionne.

Étape 3 . Déployer le code sur un environnement

Étape 4 . Contrôler l’activation via la console d’administration

ci -dessus : Une interface graphique permet de réaliser l’opération sans nécessiter de compétences techniques.

Limites

     Ce mécanisme complexifie le code : deux cas de comportements sont implémentés en même temps donc deux fois plus de code. Il est donc conseillé de réfléchir aux bons emplacements stratégiques dans le code et de limiter le nombre de recours. Dans le même ordre d’idée, le nombre total de fonctionnalités couvertes se doit de rester faible pour rester maintenable.
     Heureusement, ce risque est diminué dans la plupart des usages puisqu’ils répondent à un besoin temporaire. Néanmoins, cette situation temporaire va induire une opération supplémentaire de nettoyage du code, une fois que la fonctionnalité est activée de manière définitive.
     Il existe également quelques cas où la sécurisation avec un toggle n’est pas envisageable. J’ai notamment déjà rencontré le cas lors d’un changement structurel important au niveau du modèle en projet .
     Il existe une controverse. En effet, les outils de gestion de versions (tel que Git) apportent une aide précieuse dans la résolution de certaines problématiques (ex. CAS 3). Si la pratique très courante du Feature Branching (séparation des fonctionnalités en branches) est jugée inadaptée face au défi de l’intégration et de la livraison continues pour les uns 1 – martin fowler blog, elle reste une réponse possible lorsque bien exécutée pour d’autres 2 – james mckay blog. Ces approches peuvent aussi être utilisées côte à côte.

     Enfin, cette approche va de pair et prendra tout son sens dans un contexte où l’automatisation des tests et des déploiements est déjà en place.

Quelques implémentations

Flaggr (Android), angular-feature-flags (Angular), rollout.io (javascript), Togglz (Java), au sein du framework Spring (Java)…

 

Les approches Test Driven Design et Behaviour Driven Design

Les erreurs de code ont un coût pour le commanditaire d’un logiciel. Lorsqu’elles surviennent en phase de production, elles ralentissent son activité. Durant le processus de recette, un nombre élevé de bogues dans une version retardera sa livraison. Il est donc important de minimiser les risques de survenue de ces comportements inattendus et des régressions de fonctionnalités dès la phase de développement.

Test Driven Design

Le Test Driven Design (TDD) place l’écriture des tests unitaires au rang de bonne pratique fondamentale dans la lutte contre ces risques. Le TDD préconise de commencer par l’écriture de tests, puis de procéder par itérations successives, alternant le lancement des tests avec l’implémentation ou la refonte du code livrable. La règle à suivre lors de la phase d’implémentation est de ne toujours implémenter que le minimum faisant passer le test. Une phase de remaniement (refactoring) peut s’avérer nécessaire une fois que l’ensemble des tests passe au vert pour maximiser sa qualité.

l’approche TDD

Les bénéfices

De cette manière, l’accent est mis sur le contrat que doit remplir la méthode testée. La réussite de tous les tests garantit que le contrat est rempli. Le développeur peut en disposer comme d’un outil de vérification pour faire évoluer le code sans risque de régression.
La qualité du code est également améliorée. D’une part, le code orienté par les tests se révèle souvent plus lisible car il tend à ne comporter que le minimum nécessaire.
D’autre part, les tests définissent une documentation précieuse d’une méthode en terme d’entrée et de sortie et de comportements attendus. C’est un atout intéressant dans le contexte de projet agile, aux mises à jour de code fréquentes, et de projet avec un renouvellement fréquent de l’équipe, face au besoin de montée en compétence rapide.
Cependant, le TDD ne résout pas tous les problèmes, en partie, car les tests sont orientés techniques.

Les limites

Dans la plupart des projets, le besoin du métier est recueilli par les profils fonctionnels. Or, avec l’approche TDD, le développeur est le seul profil de l’équipe qui écrit et déroule les tests. La réussite de ceux-ci dépendra de leur qualité, et en particulier, d’une bonne compréhension du besoin du métier, traduit dans la bonne granularité et avec une bonne couverture de tests.
Malgré la préconisation d’une implémentation minimale à chaque itération, il existe encore un risque que le développeur parvienne à faire passer les tests dans le non-respect des bonnes pratiques de programmation (nommages, découpage du code…) qui rendrait le code moins évolutif. Néanmoins, la présence des tests permettra de ré-usiner le code sans risque par la suite.
Enfin,en s’appuyant uniquement sur les tests unitaires, par définition indépendants et reproductibles unitairement, la vérification de la bonne marche d’un comportement du logiciel qui serait la succession de comportements interdépendants dans un contexte précis n’est pas envisagée.
L’approche BDD a été pensée pour répondre à la majorité de ces limites.

Behaviour Driven Design

Le Behaviour Driven Design (BDD) étend le potentiel du TDD en proposant la définition de tests orientés comportement, écrits par un profil fonctionnel dans un langage naturel. Les cas de tests sont structurés selon le modèle GIVEN-WHEN-THEN (nommé Gherkin). Comme le montre l’exemple ci-après, GIVEN décrit le contexte, WHEN l’action de l’utilisateur et THEN les comportements attendus.

SCENARIO paiement avec un code promotionnel
GIVEN  le client  « Mme D. » est authentifié
AND son panier comporte les produits suivants
     produit  | prix | quantité
     robe     |  65  |        1
AND le client a une adresse de livraison
AND le client a choisi un mode de paiement
AND le client indique le code promotionnel «MOINS10%»
WHEN le client  demande le paiement de sa commande
THEN le panier est vide
AND la facture donnée indique
    nom    | produit | prix total
    Mme D. |  1 robe |       58,5


La tenue d’un tri-amigos, une réunion confrontant les visions des profils fonctionnels et des profils techniques de l’équipe, favorise l’explicitation de tous les scénarios significatifs, y compris les traitement des erreurs, et la dissipation des imprécisions
Le fichier feature produit sert de trame pour le développeur. Chaque phrase est traduite sous forme d’une méthode, réalisant soit l’initialisation des conditions (GIVEN), soit les opérations (WHEN), soit les assertions de comportements (THEN) définis par le scénario. Le test est déroulé dans l’ordre des phrases par appels successifs de l’ensemble de ces méthodes interdépendantes.


L’approche BDD complète l’approche TDD en incluant les membres fonctionnels de l’équipe

Les bénéfices

La description des attentes est disponible pour tous dans un format compréhensible par tous. En favorisant la discussion entre fonctionnels et techniques, cette approche peut mener à l’émergence d’un langage commun aussi bien dans les définitions de tests que dans le code. Ce sera un atout pour la communication au sein de l’équipe.
Enfin, la mise en place du BDD contraint le développement à la validation de scénarios (tests d’intégration) là où le TDD ne contraint qu’à la validation de règles métier sans liaison entre elles (tests unitaires).

Les limites

La mise en place initiale de cette approche peut être longue avant que l’équipe ne soit suffisamment experte, mais sur le long terme, la présence des BDD deviendra un gain de temps en diminuant le nombre d’incidents.

Conclusion

Ces approches apportent au produit une meilleure stabilité et une meilleure documentation, et à l’équipe une vision partagée des problématiques métier. Afin de s’assurer de profiter de leurs bénéfices, les tests BDD et TDD doivent être lancés régulièrement avant chaque livraison et de préférence dès la livraison sur un environnement d’intégration. Il est fortement recommandé d’automatiser leur lancement.
Néanmoins, elles ne sont pas suffisamment contraignantes pour lutter contre d’autres facteurs d’apparition de bogues comme un mauvais design. De bonnes pratiques de développement doivent être mises en place comme par exemple le pair programming (code en binôme) ou la revue de code.

Retour sur EclipseCon France 2018

En septembre 2017, Oracle annonçait sa décision, en accord avec les autres grands acteurs du marché que sont IBM et RedHat, de transférer les technologies JavaEE à la fondation Eclipse pour «rendre le processus d’évolution de ces standards plus agile» [4].
Cette annonce a provoqué un séisme au sein de la communauté Java et a levé de grandes interrogations sur l’avenir de la plateforme, sur le positionnement du projet Eclipse MicroProfile et sur l’état d’avancement de cette transition.
Comme chaque année DocDoku1 était présent à l’EclipseCon France 2018, rendez-vous annuel de la communauté Eclipse à Toulouse.
Comme à chaque fois un thème est à l’honneur. Cette année il était légitime que ce soit le tour de la plateforme «entreprise» pour Java d’être sous le feu des projecteurs.
Étant moi même à l’affût d’information sur l’avenir de cette plateforme, j’ai profité de l’unique journée à laquelle j’ai pu venir, pour me concentrer sur JakartaEE et MicroProfile.

JakartaEE

JakartaEE


Au début de cette année, la communauté a choisi le nom JakartaEE pour désigner ce qu’Oracle appelait JavaEE. En effet Oracle a souhaité conserver ses droits sur la marque Java, il fallait donc trouver un autre nom.
Pourtant à la fin de l’année 2017 la fondation Eclipse avait annoncé la création du projet Eclipse Enterprise for Java (EE4J).

EE4J ou JakartaEE ?

Eclipse Enterprise for Java [5] est le projet «chapeau» pour tout ce qui concerne les technologies JavaEE, c’est à dire les API mais aussi les implémentations de référence transférées aussi par Oracle.
Eclipse JakartaEE Platform [6] est donc un sous-projet de EE4J qui reprend ce qu’était la spécifiaction de la plate-forme JavaEE : la définition d’un environnement d’exécution résultant de l’agrégation d’un ensemble spécifications d’API.
On trouve naturellement par ailleurs un sous-projet pour chaque API (Servlet, EJB, …) mais aussi les implémentations de références développées au sein de la fondation Eclipse ou par Oracle comme Yasson, EclipseLink, Glassfish, Grizzly, Jersey, …

Où en est la transition ?

Tout d’abord la procédure de transfert est longue car Oracle doit faire des vérifications (propriété intellectuelle, licence, …) pour chaque élément transféré.
En outre, les CTS2/TCK3 d’Oracle ne sont pas libres.
Nous apprenons que la transition se fera en plusieurs étapes :

  • Rendre JakartaEE 8 officiellement compatible avec JavaEE 8.C’est à dire obtenir une implémentation de référence JakartaEE qui passe les CTS/TCK actuels d’Oracle.
  • Fournir des CTS/TCK libres pour JakartaEE et s’assurer que l’implémentation de référence JakartaEE passe avec succès ces tests.
  • Une fois ces deux objectifs atteints JakartaEE pourra évoluer selon le processus normal de la fondation Eclipse.

En regardant l’état d’avancement on peut voir que la migration d’une bonne partie des projets est déjà bien avancée.

Un point sur les licences

Le système actuel de licence d’Oracle (CDDL4 et GPL5v2 des spécifications, API et RI ; TLDA6 pour l’usage des TCK et de la marque JavaEE) vont également changer en Eclipse Public License (EPLv2)

Comment la plateforme évoluera-t-elle ?

Les API sortent du giron de JCP7 et des JSR8 pour rejoindre le système des Working Group d’Eclipse et du processus de spécification de la fondation.
Grâce à ce changement, l’Eclipse Foundation espère une plus grande agilité et flexibilité.$
On nous indique que la stratégie d’évolution sera la standardisation a posteriori des bonnes idées qui ont fait leurs preuves à l’instar des exemples célèbres comme Hibernate, Weld, Jersey qui ont donné JPA, CDI et JAX-RS.
Notons que le JCP ne disparaît pas, il continue de fonctionner pour ce qui concerne JavaSE.

JakartaEE vs. MicroProfile

JavaEE 6 a vu l’arrivée de la notion de profil (Web Profile, Full Profile) au sein de la plateforme JavaEE. Le constat de l’époque étant que toutes les applications n’avaient pas besoin de l’ensemble des technologies de la plateforme.
Avec l’arrivée du Cloud Computing et succès des architectures micro-service (comprendre à base de VM), Eclipse MicroProfile propose une spécification de profil encore plus minimal, concurrent direct de Spring Boot [7], basé essentiellement sur les API standard CDI, JAX-RS et JSON-P auxquelles s’ajoutent quelques API nouvelles (Config, Health, Metrics, …).

MicroProfile

Eclipse MicroProfile [8] est donc une spécification alternative d’un ensemble d’API adaptées à la mise en œuvre d’applications architecturées sous forme de micro-service.
D’abord basé sur un nombre très limités d’API, la plateforme évolue comme le montre le tableau [Table:1]

Évolution de Microprofile
API/MicroProfile 1.0 1.1 1.2 1.3 1.4 2.0
CDI 1.2 2.0
JSON-P 1.0 1.1
JAX-RS 2.0 2.1
Config 1.0 1.1 1.2 1.3
Health Check 1.0
Metrics 1.0 1.1
Fault Tolerance 1.0 1.1
JWT Propagation 1.0 1.1
Open Tracing 1.0 1.1
Open API 1.0
Rest Client 1.0 1.1
JSON-B 1.0

Une des forces des spécifications ouvertes, comme pour JEE, est de permettre de fédérer divers éditeurs. Grâce à cela il existe plusieurs implémentations de MicroProfile (voir le tableau ci-dessous).

Implémentations de MicroProfile
Éditeur Implémentation
IBM Open Liberty [9]
RedHat WildFly Swarm [10]
Payara Payara Micro [11]
Apache Tomee [12]
Hammock Hammock [13]
Kumuluz KumuluzEE [14]

Avec les implémentations de MicroProfile, il est possible de déployer une application de plusieurs façons :

  • l’application, les dépendances et le runtime sont packagés dans un seul et même JAR exécutable.Format popularisé par Maven et Spring Boot, la taille de l’archive peut devenir si importante que cela peut poser des problèmes lors de déploiements fréquents (déploiement continu)
  • L’archive JAR contient l’environnement d’exécution, l’archive WAR les ressources métier et les éventuelles dépendances tierces.Avantage, Le WAR est plus léger à déployer car il ne contient que ce qui est spécifique au métier. Cela rappelle le mode de déploiement dans un serveur JavaEE.

12-Factor Application

Pour rappel, «Application à 12 facteurs» est une méthodologie pour construire des applications SAAS9.
Les 12 facteurs en question sont:

  1. Une seule base de code, versionnée (Codebase)
  2. Déclarer explicitement et isoler les dépendances (Dependencies)
  3. Ne pas stocker la configuration dans le code (Config)
  4. Tous les services sont vus comme des ressources «tierces» (Backing services)
  5. Stricte séparation entre la construction, la livraison et l’exécution d’une application (Build, release,run
  6. Les processus d’une application sont sans-étatProcesses
  7. Les services (Web) sont exposés via un port réseau (Port Binding)
  8. L’application se décompose en processus parallèles (Concurrency)
  9. L’application doit pouvoir être démarrée et arrêtée à la demande (Disposability)
  10. Garder les environnements (développement ,recette, production) aussi similaires que possible(Dev/Prod parity)
  11. Les logs sont un flux d’événements indépendant de la manière dont ils sont stockés (Logs)
  12. Les processus d’administration doivent s’exécuter dans le même environnement que l’application (Admin Process)

La présentation d’Emily Jiang [2] nous montre comment l’association de la plateforme MicroProfile et Kubernetes permettent de mettre en œuvre une application selon ces principes.

Codebase
Le code source de l’application est géré par Git (sur GitHub).
Dependencies
La construction et la gestion des dépendances est gérée par Maven.
Config
Les configmaps Kubernetes et l’API Config servent à injecter les propriétés de configuration dans l’application.
Build-Release-Run
Une plateforme d’intégration continue prend en charge le packaging pour chaque environnement.
Processes
L’API REST permet de mettre en œuvre les processus sans-état
Port Binding
Kubernetes et l’API Config sont responsable de l’affection des ports
Concurrency
Le découpage en micro-services et Kubernetes permettent de gérer la mise à l’échelle
Disposable
L’API Fault Tolerance permet de rendre l’application résiliente aux arrêts des processus.
Dev/Prod Parity
Kubernetes Helm permet de s’assurer que les différents environnements sont similaires
Logs
ELK10 permet d’indexer et de gérer les journaux.
Admin Process
L’outillage standard de Kubernetes (kubectl exec) permet des déclencher les processus d’administration.

Sécurité sans-état avec JWT

La sécurité est un aspect fondamental pour les applications d’entreprise, celui-ci est d’ailleurs pris en compte dans JavaEE (avec plus ou moins de souplesse) depuis les tous débuts de la plateforme.
Les architectures micro-service («SOA avec un nom sexy» dit Jean-Louis Monteiro [3]) ne font pas exception, mais l’aspect sans-état nécessaire pour faciliter la gestion de la charge change la donne.
Jean-Louis discute des inconvénients des différentes options d’authentification et de propagation des identités:

Basic Auth
présente plusieurs risques car :
– le couple login/motdepasse est envoyé à chaque requête,
– risque d’attaque DOS du référentiel de sécurité.
OAuth 2.0
basé sur une paire de jetons (access/refresh) recrée au final une session HTTP côté serveur pour garder une trace des jetons générés (et confiés au client) : cela consomme de la mémoire et du temps de calcul car chaque micro-service activé doit vérifier les tokens
JWT
est un format de jeton similaire à SAML mais codé en JSON. Ils contiennent des informations signées et potentiellement chiffrées. Dans ce cas de figure les informations signées, donc non altérables, sont stockées côté client.

L’association JWT + OAuth 2.0 permet de réduire considérablement les ressources nécessaires côté serveur : seules des références de jeton sont conservées (pour la révocation) et chaque service peut vérifier la signature du jeton de manière autonome.
Une présentation de la mise en œuvre de se mécanisme avec l’API JWT propagation de la plateforme MicroProfile vient enfin compléter la brillante démonstration.

JakartaEE + IOT

Une démonstration concrète de la mise en œuvre de technologies JavaEE et de l’Internet des Objets.
Payara Micro [11] est une déclinaison du serveur d’application Payara Server (basé sur Glassfish), pensée pour les micro-services «conteneurisés».
Ce micro-serveur d’application est compatible MicroProfile, mais malgré sa taille (moins de 70Mo),il supporte la mise en cluster, les connecteurs JCA, le Clustering, JCache, les EJB Timer, les événements CDI distribués.
Comment obtenir un serveur d’application si léger ? En faisant l’impasse sur les API historiques les moins pertinentes pour ce genre d’application m’a-t-on indiqué.
Grâce à sa légèreté, sans trop de compromis quant aux fonctionnalités, nous assistons à la démonstration d’une application capable d’agréger des données en provenance de capteurs (d’humidité dans le cas présent) à travers des applications JavaEE déployées sur des nano-ordinateur de type RaspberryPi.
Événements CDI distribués, connecteur JCA pour des échanges de messages asynchrone (MQTT), services REST sont au rendez-vous pour démontrer que les technologies JavaEE ont aussi leur place dans le monde des ressources contraintes de l’IOT.

Kubernetes : retour d’expérience

La fondation Eclipse est en cours de migration de sa plateforme d’intégration continue depuis Cloodbees Jenkins Enterprise vers une solution basée sur un cluster Kubernetes (OpenShift).
À partir de sa propre expérience de migration, Mikaël Barbero nous présente une excellente introduction à Kubernetes [1]
Kubernetes [15] est un système Open Source d’orchestration de conteneurs (VM) permettant d’automatiser le déploiement, la configuration, la gestion et la montée en charge d’applications ou de micro-service «conteneurisés».
Contrairement à la plateforme JavaEE où le conteneur – la machine virtuelle Java – est limitée à l’exécution de bytecode, les conteneurs (machines virtuelles) gérés par Kubernetes sont plus génériques car indépendants d’un OS, d’un langage et d’une plateforme pré-définis.
Là ou les serveurs d’application JavaEE permettaient d’orchestrer des machines virtuelles Java au sein d’un cluster, des outils comme Kubernetes réalisent sensiblement le même travail avec des conteneurs Docker dans le cas présent.
On perçoit comment ont évolués les usages ces dernières années: plutôt que de dépendre des capacités d’un serveur d’application JavaEE, limitées plus ou moins au monde Java, on préfère utiliser un outillage tiers pour gérer un cluster de machines virtuelles plus générales

Conclusion

Que ne lit-on pas ici et là sur la nature «monolithique» de la plateforme JavaEE, que l’on oppose à une architecture fragmentaire des micro-services.
Pourtant JavaEE/JakartaEE ne décrit pas comment doit être implémenté l’environnement d’exécution mais défini seulement un ensemble d’API qui doit être disponible et un format de packaging. Chaque type de composant est d’ores et déjà distribuable, alors pourquoi ne pourrait-on pas voir JEE comme la définition d’une PAAS11 tout à fait capable de construire des applications à base de micro-services ?
Est-ce la difficulté de morceler la plateforme comme ce qui a été réalisé lors des premiers profils (Web et Full) ? Est-ce la nécessité de conserver une compatibilité ascendante ?
Le succès des solutions MicroProfile (ou dans une certaine mesure Springboot ou Dropwizard) nous apprend que:

  • On doit pouvoir choisir les technologies strictement nécessaires à la mise en œuvre d’une application ou d’un composant applicatif.L’intégration de systèmes de modules dynamiques comme OSGI dans les implémentations des serveurs d’applications permet d’ores et déjà de ne charger en mémoire que les composants nécessaires, reste la configuration parfois complexe d’un domaine que l’on voudrait déléguer à des systèmes moins spécifiques.
  • Micro-service ou pas, le contexte des applications d’entreprise nécessite de disposer de solutions pour simplifier la mise en œuvre des aspects transverses (sécurité, transaction, distribution, tolérance aux pannes, métrologie, surveillance, journalisation, …).Il suffit, pour s’en convaincre, de regarder l’évolution des API de MicroProfile. Si les nouvelles API répondent à de nouveaux usages, elles peuvent également profiter à JakartaEE, mais à ce rythme MicroProfile restera-t-il «micro» ?
  • Le choix de la standardisation adoptée par Sun/Oracle ou la fondation Eclipse permet de fédérer les efforts des différents éditeurs et de favoriser la portabilité et l’interopérabilité.

Maintenant que JavaEE est en passe d’être libéré de la tutelle – soit-elle symbolique – d’Oracle, l’enthousiasme des participants à la conférence était au rendez-vous.
Grâce à la disponibilité de systèmes de virtualisation par conteneurs capables d’exécuter des composants (Java ou non); d’outils permettant la gestion d’infrastructures complexes de type Cluster ou Cloud; la modularité sera à mon avis le défi auquel devra répondre la plateforme JakartaEE, soit en intégrant ou définissant de nouveaux profils comme MicroProfile, soit plutôt en proposant une plateforme totalement modularisé pouvant être composée à la carte, à l’instar du travail réalisé sur JavaSE.
Demain, déployer une application JakartaEE consistera-t-il à découvrir à partir d’un paquetage les API utilisées, de provisionner un conteneur contenant le strict nécessaire et d’exécuter le tout ?
Merci enfin à toute l’équipe de la fondation Eclipse qui ont encore une fois réussi à organiser un événement fantastique.
Bravo à tous les conférenciers pour la variété et la qualité des présentations.

Références

1. Mikaël Barbero. 2018. Kubernetes 101. Retrieved from https://www.slideshare.net/mikaelbarbero/kubernetes-101-a-cluster-operating-system/
2. Emily Jiang. 2018. Build a 12-Factor Microservice in Half an Hour. Retrieved from https://www.eclipsecon.org/france2018/sites/default/files/slides/Build12FactorAppUsingMP.pptx
3. Jean-Louis Monteiro. 2018. Stateless Microservice Security via JWT, TomEE and MicroProfile. Retrieved from https://www.eclipsecon.org/france2018/sites/default/files/slides/2018_EclipseConEU_StatelessRESTSecurityWithMP-JWT.pdf
4. 2017. Opening Up Java EE – An Update. Retrieved from https://blogs.oracle.com/theaquarium/opening-up-ee-update
5. Eclipse Enterprise for Java. Retrieved from https://projects.eclipse.org/projects/ee4j
6. JakartaEE. Retrieved from http://microprofile.io/
7. Spring Boot. Retrieved from https://spring.io/projects/spring-boot
8. Eclipse MicroProfile. Retrieved from http://microprofile.io/
9. Open Liberty. Retrieved from https://openliberty.io/
10. WildFly Swarm. Retrieved from http://wildfly-swarm.io/
11. Payara. Retrieved from https://www.payara.fish/
12. Apache TomEE. Retrieved from http://tomee.apache.org/
13. Hammock. Retrieved from https://hammock-project.github.io/
14. KumuluzEE. Retrieved from https://ee.kumuluz.com/
15. Kubernetes. Retrieved from https://kubernetes.io/

  1. DocDoku est membre solution de la fondation Eclipse
  2. Compatibility Test Suite
  3. Tehnology Compatibility Kit
  4. Common Development and Distribution License
  5. Gnu Public License
  6. Technology License and Distribution Agreement
  7. Java Community Process
  8. Java Specification Request
  9. Software As A Service
  10. Elasticsearch, Logstash, Kibana
  11. Platform As A Service

Comment optimiser vos revues de conception produit ?

Votre entreprise développe des produits nécessitant des revues de conception régulières. Les différentes équipes qui interviennent sur le projet (R&D, Qualité, Marketing…) sont peut-être localisées sur différents sites de votre entreprise, voir dans différents pays.
Pour assurer à ces revues d’atteindre leurs objectifs, les conférences téléphoniques ne sont parfois pas suffisantes et se transforment souvent en réunion physique, mobilisant vos équipes mais également des budgets supplémentaires.

Existe-t-il des solutions pour optimiser l’impact et l’efficacité de vos revues de conception ?

En utilisant un module de revue de conception en temps réel, comme celui présent dans DocDokuPLM.
A première vue, son usage semble être le même qu’un outil de partage d’écran. Mais son périmètre fonctionnel va bien au delà.
DocDokuPLM s’adapte aux volumes de données de vos maquettes et peut gérer des sessions multi-utilisateurs.
Tout cela en se basant uniquement sur les technologies web : aucune installation de plug-in n’est nécessaire.

Prise dans un contexte opérationnel standard, la vidéo ci-dessous illustre le principe de cette technologie sur une revue de conception de maquette d’avion.

L’ordinateur de droite initialise la revue de conception virtuelle et invite les utilisateurs connectés sur l’autre PC à se joindre aux échanges.
Le module de revue de conception garantit la sécurité des données et le respect des règles de confidentialité des informations affichées. Ainsi, les participants visualisent uniquement les éléments sur lesquels leur accès est autorisé.

Pour en savoir plus sur DocDokuPLM

Demander une démo

Retrouvez DocDoku sur l’EclipseCon 2018

Les 13 et 14 juin prochains, DocDoku vous donne rendez-vous dans la ville rose pour l’EclipseCon France 2018, le grand rassemblement annuel français de la communauté Eclipse.

Comme lors de la précédente édition, DocDoku reste fidèle à son engagement en tant que sponsor de l’événement et vous accueillera sur son stand pour parler solutions et technologies, mais également présenter ses derniers cas clients.
Le programme de la conférence 2018 couvrira cette année des sujets en lien avec la modélisation, les systèmes embarqués, le Cloud, la Data Analytics, le DevOps et plus encore, le tout agrémenté de sessions de démonstration des outils basés sur Eclipse.

Cette année nous serons particulièrement attentifs aux conférences sur l’arrivée dans la fondation du groupe de travail JakartaEE, auquel DocDoku appartient désormais.
En effet, ce projet ambitieux prend la suite de la renommée plateforme de développement d’applications d’entreprise Java Enterprise Edition, maintenue par Oracle précédemment.

Nous resterons également captivés par les conférences du groupe de travail Polarsys, auquel DocDoku participe également au travers de la plateforme PLM d’Eclipse EPLMP.

13 et 14 juin 2018
Centre de Congrès Pierre Baudis
11 esplanade Compans Caffarelli
31000 Toulouse

Lien direct vers le formulaire d’inscription : ici

Agilité : l’engagement historique de DocDoku

 

« Aucune de mes inventions n’est arrivée par accident. J’ai entrevu un besoin qui méritait d’être comblé et j’ai fait essai après essai jusqu’à ce que cela vienne ».
Thomas Edison

Pour commencer, comment définir la méthodologie Agile dans le développement de projets logiciels ?

De façon simple, l’Agilité invite à exécuter en parallèle les activités suivantes :
  • gestion des exigences (expression des besoins du Client),
  • analyse et conception,
  • codage et test,
  • suivi du projet.

Quelle est la vision de DocDoku au regard de l’Agilité ?

Bien avant la création de DocDoku en 2006, ses fondateurs, Eric Descargues et Florent Garin, appliquaient déjà cette méthodologie dans les projets qui leur étaient confiés. Inscrite dans l’ADN de la société, l’Agilité fait donc naturellement partie des projets développés par DocDoku, qu’il s’agisse de Data Management ou du développement d’applications digitales métier.

Et concrètement comment l’engagement dans les méthodologies Agile se traduit-il ?

Tout projet est organisé en « realeases ». Chaque release se décompose en plusieurs itérations à la fin desquelles un incrément du projet est livré au client. 
Cette organisation permet de proposer au client le plus tôt possible une version visible de son projet pour qu’il puisse se projeter et faire au besoin les ajustements nécessaires. 
Le principe est d’éviter l’effet « tunnel », incompatible avec l’atteinte des objectifs (coûts, qualité, délai) du projet.
Enfin, chaque itération est soumise au « time-boxing », c’est à dire qu’elle est limitée dans le temps (de 2 à 4 semaines) pour assurer un excellent respect du planning.