Ressources

Comment nous utilisons Docker dans nos projets IoT clients

Depuis 2016, nous utilisons la technologie Docker dans nos projets d’IoT. Simon, Expert Big Data, partage son retour d’expérience sur la construction de notre première plateforme IoT, sur l’utilité de Docker pour le déploiement et la flexibilité de cette plateforme.

admin ven 26/11/2021 - 11:20

Qu’est-ce que la plateforme Digora IoT Hub  ?

La fonction principale de la première plateforme pour les objets connectés développée par Digora était le Device Management (application permettant la gestion d'une flotte d'appareils mobiles, ici, des objets connectés).

Toutefois, nous nous sommes efforcés de lui donner une ligne directrice fondamentale : être toujours plus modulaire et exploitable facilement pour répondre aux besoins métiers de notre client. L’objectif est clair, être en capacité d’y ajouter rapidement et efficacement des nouvelles fonctionnalités, sur demande ou par nécessité. Nous l’avons imaginé en “briques” facilement identifiables :

• Les objets communiquent leurs données vers une machine virtuelle dédiée, à travers le protocole MQTT. Basé sur des technologies éprouvées, il permet la transmission des données et leur potentielle mise en mémoire tampon. Il est possible d’y ajouter une couche de sécurité - ce qui est notre cas.
• Un script vient chercher l’information sur le serveur MQTT, appelé broker, et la stocke dans notre base de données.
• La base de données s’interface sur une API - interface de programmation - sécurisée à laquelle seuls les sites autorisés peuvent accéder.

L’idée est de pouvoir déployer l’IoT Hub sur toutes les distributions Linux, rapidement et sans avoir à modifier fondamentalement la structure de notre plateforme. Concrètement, cela signifie la mise en place et la configuration d’un serveur MQTT, de scripts, d’une base de données et d’un serveur HTTP - a minima - sur chaque machine virtuelle contenant la plateforme, et ce sur une distribution Linux potentiellement complètement différente de notre distribution de développement.

Docker : quoi et pour quoi ?

Créer une plateforme modulaire et facilement exploitable dans les SI de nos clients était un vrai challenge. Il fallait trouver une solution pour déployer rapidement la plateforme pour l’IoT, dans le cloud ou On-premise. C’est ainsi que nous avons décidé d’utiliser Docker.

Docker est un logiciel libre qui automatise le déploiement d’applications dans des enveloppes logicielles. Il entre dans les démarches “DevOps”, ensemble de pratiques et d’outils améliorant les processus de développement logiciel et de gestion d’infrastructure de la conception à l’exploitation, en passant par le test et le déploiement.

Docker : les concepts du container et de l’image

Pour une meilleure compréhension, nous devons vous expliquer les 2 concepts essentiels à Docker : le container et l’image.

Un container est un package léger, autonome et exécutable d’un logiciel qui inclut tout ce qui est nécessaire pour l’exécuter : code, runtime, outils systèmes, bibliothèques et paramètres.

On crée un container à partir d’une image. L’image est un template contenant les librairies, les paramètres systèmes, les programmes (code source et exécutable), compilateur et interpréteur dans leurs versions validées nécessaires au fonctionnement de  l’application.

Le container ainsi créé va permettre de s’implanter sur n’importe quelle distribution Linux équipée d’un serveur Docker. Le serveur Docker fait donc l’interface entre l’OS et les containers.

Pour le pôle innovation de Digora, le résultat est simple : avec quelques changements mineurs de fichiers de configuration, le déploiement est fait rapidement et sur n’importe quelle distribution Linux. Pour nos clients, cela signifie un déploiement plus rapide, une plus grande facilité de développements ultérieurs ou particuliers, mais également de la flexibilité sur la localisation (On-premise / cloud). C’est ainsi que l’utilisation de Docker, nous a notamment permis de déployer facilement notre plateforme pour l’IoT chez Sorepol.

Pour nos équipes de services managés, cela permettra également de déployer des environnements de productions pour nos clients en cas d’incident de l’environnement d’origine. Il en sera de même en cas de déploiement en cas de changement de Cloud Provider.

PostgreSQL 14 est disponible. Quelles nouvelles fonctionnalités ?

Le mois d’octobre a démarré avec la sortie de la dernière version pour sa base PostgreSQL Open Source, la version 14.0. Découvrons les évolutions principales de cette version qui apporte à la fois des nouveautés pour les développeurs et pour les administrateurs.
 

antoine.mercie… mar 19/10/2021 - 12:23

Types de données et SQL : une nouvelle syntaxe

Bien qu’il soit possible de manipuler des données depuis la version 9.2, la version 14 introduit, à travers le subscript, une syntaxe plus naturelle, plus conviviale et certainement plus standard à la syntaxe couramment utilisée dans les requêtes. Cette syntaxe peut être étendue aux autres données structurées.

Cette version va également inclure :

• Un nouveau type multirange permettant de spécifier des listes ordonnées de plages non contiguës ;
• Dans les requêtes avec des tables récursives (requête WITH), Postgresql ajoute la syntaxe SEARCH et CYCLE ;
• La prise en charge des paramètres OUT dans les procédures stockées et ajoute à la clause GROUP BY la possibilité d’utiliser le mot-clé DISTINCT ;
• Introduction de la compression LZ4 pour les colonnes TOAST tout en maintenant le support de la compression PGLZ.

De nouvelles fonctionnalités d'administration

PostgreSQL 14 améliore les performances de la fonction VACUUM avec des optimisations orientées vers les index ainsi que la prise en charge des tables partitionnées.
Des améliorations pour les informations pouvant être surveillées, donnant la possibilité de suivre la progression de COPY, de suivre l’activité WAL ainsi que les statistiques des slots de réplication.

D’autres améliorations apparaissent également pour aider à gérer les connexions (ex : idle_session_timeout et client_connection_check_interval).

Amélioration de la réplication et de la récupération

PostgreSQL 14 apporte son lot d’améliorations, au niveau de la performance lors des réplication logique pour des bases de données distribuées. Par exemple, en permettant aux Foreign data wrappers d’utiliser le parallélisme des requêtes.

Il y a des améliorations de performances dans PostgreSQL 14 sur la façon dont PostgreSQL démarre lors d'une récupération après incident, et vous pouvez maintenant utiliser pg_rewind sur une instance PostgreSQL qui est en mode veille.

Pour en savoir plus, revisionnez notre webinar sur la sauvegarde des bases PostgreSQL.

Performance : requêtes en rafale et parallélisme

PostgreSQL 14 introduit la possibilité d’effectuer des requêtes en rafale (pipeline mode) vers la base de données. Cette fonctionnalité étant liée au client PostgreSQLl 14, le mode en rafale peut être utilisé sur des versions plus anciennes de PostgreSQL.

Le parallélisme des requêtes a été globalement amélioré pour :

• Les lectures séquentielles ;
• L’utilisation des requêtes parallélisées dans la commande RETURN QUERY dans du code PL/pgSQL ;
• Les requêtes parallèles pour le REFRESH MATERIALIZD VIEW ;

Pour finir, les requêtes incluant des jointures à boucles imbriquées amélioreront leurs meilleures performances grâce au système de cache additionnel.

La sécurité, jamais oubliée

PostgreSQL 14 ajoute la possibilité de donner aux utilisateurs des privilèges universels "lecture seule" et "écriture seule" sur les tables / vues / séquences grâce à l'utilisation des rôles prédéfinis pg_read_all_data et pg_write_all_data.

La sécurité des mots de passe pour les nouvelles instances a été améliorée par l’utilisation par défaut SCRAM-SHA-256. Le paramètre clientcert dans pg_hba.conf a également évoluer en imposant l’utilisation des valeurs de verify-ca ou verify-full.

Cette version permet d’utiliser le "nom distinctif" (DN) d'un certificat pour l'authentification basée sur un certificat avec un paramètre clientname=DN dans le fichier pg_hba.conf.
 
De nombreuses autres nouvelles fonctionnalités et améliorations ont été ajoutées à PostgreSQL 14, il est impossible de les lister toutes dans cet article et d’autres améliorations sont plus pertinentes en fonction de votre contexte. Pour retrouver la liste de toutes les nouvelles fonctionnalités ou des modifications de celles-ci, veuillez consulter la release note de version.    

Vous avez un projet d’upgrade de vos bases PostgreSQL, nous pouvons vous accompagner dans la préparation et la réalisation de cet upgrade, n’hésitez pas à nous contacter.

Je contacte un expert

Comment réaliser une migration parfaite d’un SI sensible (AIX vers Linux) ?

Comment migrer un système d’information sensible (dossier patient) tout en limitant les interruptions de services ? Etudions le projet du CHU de Bordeaux qui désirait migrer d’AIX vers Linux.

matthieu.kieny… lun 28/06/2021 - 16:11

Migrer un système d’exploitation et ses bases de données est toujours un peu stressant. Quand en plus, il faut garantir la disponibilité du service pour 9000 utilisateurs, ça rajoute du piquant. Mais par-dessus tout, s’il s’agit des dossiers patients d’un hôpital, vous devez être parfaitement préparé. Décortiquons ce projet réalisé pour le CHU de Bordeaux.

Migrer d’AIX vers Linux pour profiter d’un cluster actif/actif

Le Centre Hospitalier Universitaire de Bordeaux utilise depuis toujours des bases Oracle sur le système d’exploitation AIX d’IBM. Leur volumétrie est très conséquente. Le logiciel principal utilisé est Dxcare de la société Dédalus. Il sert à gérer le dossier patient informatisé (ou Dossier Médical Partagé), dont les données sont stockées sur une base Oracle. Cette base de données principale occupe actuellement plus de 19 terra-octets. Un grand nombre d’autres bases de données Oracle sont aussi utilisées pour des applications annexes.

Le CHU de Bordeaux désirait se désengager du système d’exploitation AIX et de sa gestion du cluster en mode actif/passif (par le biais de Veritas Cluster Manager) afin de basculer sur le système d’exploitation Oracle Linux en mode cluster mais en actif/actif.

Migrer un système d’informations et des données sensibles présente différents enjeux et complexités. Il fallait en outre :

• Minimiser au maximum les temps d’interruptions de service ;
• Garantir le retour des accès aux applications aux 9000 utilisateurs potentiels du CHU ;
• Assurer une stabilité de l’application dans ce passage actif/passif vers actif/actif ;
• Faire monter en compétence l’équipe des DBAs du CHU de Bordeaux afin de garantir l’exploitation de la solution.

5 phases clés pour préparer la migration

Ce projet, qui a duré plus de deux ans, a été effectué en plusieurs phases :

• Définir la nouvelle infrastructure en fonction des consommations actuelles sur les serveurs AIX afin que le CHU puisse acquérir des serveurs Linux/Intel suffisamment calibrés en termes de nombre de cœurs de CPU et de mémoire
• Installer et configurer un nouveau cluster de test et formation, et effectuer des transferts de compétences avec l’équipe DBA
• Faire des premiers tests de migration en basculant les bases de test sur ce cluster et valider l’exploitabilité de la solution, notamment avec les outils de supervision utilisés par le CHU
• Installer et configurer les nouveaux clusters de production
• Migrer les bases de production

Oracle 19c au cœur du projet

Bien sûr, l’aspect technologique d’un tel projet de migration est essentiel. Dans ce cas, les bases de données tournaient principalement sur Oracle Database 19c.

Les nouveaux serveurs en cluster Oracle Linux ont été installés en utilisant le logiciel Grid Infrastructure en version 19C qui permet de gérer la couche cluster et le stockage partagé sous ASM (Automatic Storage Management).

Les moteurs bases de données (RDBMS) ont été installés en version 12CR1 et 19C.

Certaines bases de données Oracle Database, les moins volumineuses et critiques, ont été migrées en version 19C par le biais d’export et d’import. Bien évidemment les progiciels utilisant ces bases ont été validés par les éditeurs en version 19C.

La base la plus critique utilisée pour le dossier patient informatisé ne pouvait pas être migrée par export/import. En effet, il aurait fallu plus de 24h d’export et plus de 48h d’import… Le choix s’est donc porté sur la possibilité de convertir les fichiers de la base de données d’origine en utilisant RMAN (Oracle Recovery Manager) et les sauvegardes de la base source AIX. En effet, la même version Oracle (12.1.0.2) doit être utilisée sur les deux environnements.

Pourquoi cette conversion ? Les données sous AIX utilisent des caractères en mode Big Endian alors que Linux lui utilise le mode Little Endian. Rman est donc capable d’effectuer cette conversion (changement dans l’ordre des octets, poids fort/poids faible).

Les étapes clés pour effectuer la migration

Le support Oracle est très fourni et propose la note 2471245.1 qui détaille les différentes étapes à effectuer lors d’une migration de type Transportable Tablespace/Database. La note met notamment à disposition un script shell permettant de faciliter les actions à mener :

• Restauration avec conversion des fichiers de la base de données en utilisant les sauvegardes en mode Transportable Tablespace. Cette étape a été effectuée deux semaines avant la date de migration ;
• Application des sauvegardes incrémentales converties de la base AIX sur la base Linux. Cette étape a été renouvelée plusieurs fois avant la date de migration. Le but étant de minimiser les écarts entre les deux bases afin de minimiser le temps d’interruption final ;
• Le jour J de la migration, les étapes suivantes ont été réalisées en se relayant avec l’équipe des DBA du CHU de Bordeaux  :
• A 1h du matin l’ensemble des applications utilisant la base de données ont été arrêtées ;
• A 1h20 du matin, la base de secours gérée par Dataguard est passée en mode « cliché », les droits applicatifs sont modifiés en Lecture Seule. Dxcare est accessible en lecture aux utilisateurs pendant la coupure ;
• A 2h du matin, la dernière sauvegarde incrémentale a été effectuée. Les tablespaces de la base source AIX ont été placés en mode lecture seule. Un export des métadonnées a été effectué ;
• A 2h10 du matin, la dernière sauvegarde a été appliquée sur la base Linux, et les métadonnées ont été importées ;
• A 2h30 l’export des tablespaces à transporter est fini ;
• A 3h05 l’import des transportables tablespaces est fini ;
• A 4h15 du matin, l’ensemble des objets procéduraux et autres objets non transportés (fonction, procédure, package, travaux, db_links, public synonym, tables temporaires, ACL, droits des users…)  ont été recréés ;
• A 5h du matin, l’ensemble des actions ont été terminées avec succès ( passage tablespaces en Lecture Ecriture, passage de la base en mode archivage, mise en place des sauvegardes, modification alias SQLNet dans le LDAP, récupération des profiles et des Baselines  SQL, paramétrage serveurs applicatifs et redémarrage) ;
• A 5h du matin, les tests fonctionnels ont été réalisés par les chefs de projet des différentes applications ;
• A 6h15 du matin, l’accès complet aux utilisateurs a été ouvert ;
• A 7h, début de la création de la base de secours et disponibilité de celle-ci à 14h pour les accès en mode lecture seule pour les analystes (infocentre).

Grâce à une préparation minutieuse en collaboration avec les DBA du CHU, le temps d’indisponibilité a été réduit à 6h (entre 1h et 7h du matin).

Après la migration, s’assurer que tout fonctionne

Un suivi des performances et de comportement a eu lieu avec l’aide de Digora pendant les 3 jours suivants. Aucun dysfonctionnement n’a été détecté, le ressenti des utilisateurs a été très bon, l’application se comportant bien mieux sur cette nouvelle infrastructure que sur les anciens serveur AIX.

Ce projet est donc une réussite pour le CHU de Bordeaux qui possède dorénavant une infrastructure très évolutive et robuste pour faire tourner son Dossier Patient Informatisé et les différentes données sensibles qu’il renferme.

Nous remercions le CHU de Bordeaux pour leur accord de principe sur la diffusion de cet article, et notamment M. Olivier Jecker, Responsable Département d'Ingénierie technique et production du CHU de Bordeaux.

 

Source image : Illustration de Owen Beard sur Unsplash