Bonjour,

Je voulais partager avec vous une méthode pratique qui m'a été utile lors de mes développements sur Health Connect Cloud avec VS Code et GitBash. Lors de ces développements, si des modifications sont effectuées directement sur le serveur, comme des règles de routage ou des déploiements de composants, elles ne sont pas automatiquement incluses dans le contrôle de code source. Vous devez donc exporter les modifications depuis le serveur vers vos fichiers locaux et les envoyer vers votre dépôt distant. Je suis sûr qu'il existe des méthodes plus simples pour gérer ce problème, que je suis en train de tester, mais pour une solution rapide, j'ai pensé qu'il serait utile d'utiliser une méthode de pré-validation qui déclenche un rappel dans GitBash – voir ci-dessous.

Table des matières

1. Objectif de l'article
2. Les conteneurs : définition et pertinence dans le cadre d'IRIS
    2.1 Les conteneurs et les images en quelques mots
    2.2 Avantages des conteneurs pour les développeurs
    2.3 Pourquoi IRIS fonctionne bien avec Docker
3. Conditions préalables
4. Installation de l'image InterSystems IRIS
    4.1 Utilisation de Docker Hub
    4.2 Extraction de l'image
5. Exécution de l'image InterSystems IRIS
    5.1 Démarrage d'un conteneur IRIS
    5.2 Vérification de l'état des conteneurs
    5.3 Exécution de code dans le terminal conteneur
    5.4 Accès au portail de gestion IRIS
    5.5 Connexion du conteneur à VS Code
    5.6 Arrêt ou suppression du conteneur
    5.7 Configuration d'un mot de passe spécifique avec un montage de type bind
    5.8 Utilisation de volumes %SYS durables
     5.8.1 Contenu stocké sous %SYS durable
     5.8.2 Comment activer %SYS durable
6. Utilisation de Docker Compose
    6.1 Exemple d'utilisation de l'outil Docker Compose
    6.2 Exécution de Docker Compose
7. Utilisation d'un fichier Dockerfile pour l'exécution d'un code source personnalisé
    7.1 Exemple de fichier Dockerfile
    7.2 Exemple de Docker Compose
    7.3 Compréhension des couches, du balisage des images et de la différence entre le temps de compilation et le temps d'exécution
    7.4 Code source et script d'initialisation
    7.5 Création de l'image avec le fichier Dockerfile
    7.6 Exécution d'instructions dans le terminal IRIS conteneurisé
8. Conclusion et suite

1. Objectif de l'article

La communauté de développeurs InterSystems propose déjà de nombreux articles intéressants qui expliquent le fonctionnement de Docker, les commandes les plus importantes et plusieurs cas d'utilisation d'InterSystems IRIS dans un environnement conteneurisé.

Les articles de cette série ont un objectif quelque peu différent. Je suis un grand fan des guides étape par étape, c'est pourquoi je souhaite créer un guide complet sur la configuration et l'utilisation de Docker avec InterSystems IRIS, en commençant par les bases pour ensuite passer progressivement à des scénarios plus avancés tels que les instances à espaces de noms multiples, les conteneurs interconnectés, les intégrations avec des systèmes externes et les applications comprenant une interface utilisateur.

2. Les conteneurs : définition et pertinence dans le cadre d'IRIS

2.1 Les conteneurs et les images en quelques mots

Traditionnellement, pour exécuter une application, il fallait faire correspondre sa version à celle de votre système d'exploitation et la packager pour cette cible spécifique. Dans le même temps, chaque application doit être conçue pour fonctionner spécifiquement avec un système cible. Si vous vouliez qu'une application fonctionne sous macOS et Windows, vous deviez modifier sa conception et la packager pour ces différents systèmes. Les images et conteneurs Docker constituent des technologies de déploiement d'applications qui résolvent ces problèmes en permettant aux développeurs de packager un logiciel une seule fois et de l'exécuter n'importe où. 

Docker est une plateforme logicielle qui regroupe des logiciels dans des conteneurs. Une image Docker, ou image de conteneur, est un fichier exécutable autonome contenant toutes les instructions (bibliothèques, dépendances et fichiers) nécessaires pour créer et exécuter un conteneur. Une image Docker est partageable et portable, ce qui vous permet de déployer la même image à plusieurs endroits à la fois. Un conteneur Docker est un environnement d'exécution qui contient tous les composants nécessaires pour exécuter le code de l'application sans utiliser les dépendances de la machine hôte.  

Contrairement aux machines virtuelles, les conteneurs sont légers. Ils n'ont pas besoin d'un système d'exploitation complet et fonctionnent directement sur le système d'exploitation hôte via le moteur Docker Engine en utilisant uniquement les binaires et les bibliothèques nécessaires à l'application spécifique, ce qui les rend plus efficaces. Plusieurs conteneurs isolés peuvent être lancés en même temps sur la même machine sans interférer les uns avec les autres.

2.2 Avantages des conteneurs pour les développeurs

• Isolation: exécution dans un environnement propre et reproductible sans affecter le système hôte.
• Reproductibilité: assurance que la configuration fonctionne de la même manière sur différentes machines.
• Configuration facile: lancement d'une instance IRIS en quelques secondes à l'aide d'une seule commande, sans installation manuelle.

2.3 Pourquoi IRIS fonctionne bien avec Docker

L'exécution d'InterSystems IRIS dans Docker présente plusieurs avantages:

• L'application peut être exécutée et testée dans des conteneurs isolés,
• Il est possible d'utiliser des systèmes de contrôle de version partagés (tels que Git) au lieu de travailler directement sur le serveur
• L'environnement conteneurisé peut être répliqué à n'importe quelle étape, ce qui garantit la cohérence tout au long du cycle de vie du logiciel.
• Votre application peut facilement être exécutée sur n'importe quel ordinateur.

3. Conditions préalables

Pour exécuter InterSystems IRIS dans un conteneur Docker, il faut que vous ayez:

• Le moteurDocker Engine installé et en cours d'exécution:
  • Installer le moteur Docker Engine sous Linux.
  • Le moteur Docker Engine est également disponible pour Windows, macOS et Linux, via Docker Desktop.
• Gitpour permettre l'utilisation de référentiels de contrôle de source partagés.
• Le code "Visual Studio Code" pour afficher et modifier le code source.

4. Installation de l'image InterSystems IRIS

4.1 Utilisation de Docker Hub

Docker Hub est le registre central des images Docker. Il fournit une vaste bibliothèque d'images pré-construites que vous pouvez utiliser comme point de départ. InterSystems y publie les images officielles IRIS Community Edition que vous pouvez télécharger pour exécuter IRIS localement dans votre conteneur. Vous pouvez également utiliser Docker Hub pour pousser vos propres images personnalisées afin de les partager au sein de votre équipe ou de les distribuer à la communauté. Docker Hub est disponible en ligne et intégré à Docker Desktop.

4.2 Extraction de l'image

Voici quelques commandes courantes pour les images Docker :

Vous trouverez la commande pull exacte directement sur la page Docker Hub de l'image:

Pour l'image InterSystems IRIS, la commande est comme suit:

docker pull intersystems/iris-community:latest-cd

Vous pouvez également rechercher iris-community dans la barre de recherche de Docker Desktop et cliquer sur Pull:

Une fois l'installation terminée, l'image InterSystems IRIS devrait apparaître dans la liste de vos images locales:

5. Exécution de l'image InterSystems IRIS

Une fois l'image InterSystems IRIS extraite de Docker Hub, vous pouvez l'exécuter dans un conteneur. 

Voici les principales commandes pour les conteneurs Docker:

5.1 Démarrage d'un conteneur IRIS

Vous pouvez démarrer un conteneur InterSystems IRIS Community Edition nommé "my-iris" via l'interface utilisateur Docker Desktop en cliquant simplement sur le bouton Run de l'image que vous souhaitez exécuter dans le panneau Images. Pour l'image InterSystems, il est possible de spécifier quelques paramètres facultatifs, tels que les ports à exposer sur votre machine hôte pour communiquer avec les services exécutés dans le conteneur.

Cela peut être fait via le menu ci-dessus, en considérant que:

• côté gauche → port sur la machine hôte
• côté droit → port à l'intérieur du conteneur

Ports IRIS courants (à l'intérieur du conteneur)

• 1972 → Port Superserver : utilisé par IRIS pour les protocoles réseau (ObjectScript, JDBC, etc.).
• 52773 → Port du serveur Web : utilisé par IRIS pour le portail de gestion (interface Web).

Si vous ne mappez pas explicitement les ports, Docker attribuera des ports aléatoires sur l'hôte.

Vous pouvez également exécuter le conteneur à l'aide du terminal:

docker run --name my-iris -d --publish 9091:1972 --publish 9092:52773 intersystems/iris-community:latest-cd

Dans cet exemple:

• 9091 sur l'hôte est mappé à 1972à l'intérieur du conteneur (Superserver).
• 9092 sur l'hôte est mappé à 52773 à l'intérieur du conteneur (Portail de gestion).

5.2 Vérification de l'état des conteneurs

Après avoir exécuté cette commande, exécutez docker ps pour vérifier si le conteneur fonctionne correctement.

> docker ps
CONTAINER ID   IMAGE                                   COMMAND                 CREATED         STATUS                            PORTS                                                                                        NAMES
907d4c2b4ab5   intersystems/iris-community:latest-cd   "/tini -- /iris-main"   3 seconds ago   Up 2 seconds (health: starting)   0.0.0.0:9091->1972/tcp, [::]:9091->1972/tcp, 0.0.0.0:9092->52773/tcp, [::]:9092->52773/tcp   my-iris

Les conteneurs en cours d'exécution sont également répertoriés dans le panneau Containers de Docker Desktop:

L'état des images associées sera "In Use" (En cours d'utilisation), comme indiqué dans le panneau Images :

5.3 Exécution de code dans le terminal conteneur

Une fois que le statut du conteneur indique Running (exécution), tout fonctionne correctement. 

Vous pouvez le tester en ouvrant le terminal du conteneur (cliquez sur le nom du conteneur dans le panneau de conteneurs (Containers) de Docker Desktop et accédez à Exec) et en saisissant:

iris session IRIS

Cela ouvre un terminal IRIS à l'intérieur du conteneur Docker, où vous pouvez utiliser la syntaxe ObjectScript standard pour exécuter des commandes et des scripts.

5.4 Accès au portail de gestion IRIS de l'instance conteneurisée

Ensuite, ouvrez votre navigateur et accédez à:

http://localhost:9092/csp/sys/UtilHome.csp

Par défaut, les conteneurs IRIS se servent de l'utilisateur _SYSTEM avec le mot de passe SYS. Il est nécessaire de changer le mot de passe après la connexion.

Cela vous donne un accès complet au portail de gestion IRIS, vous permettant de gérer les espaces de noms, les bases de données et d'autres fonctionnalités IRIS directement depuis l'interface web.

5.5 Connexion du conteneur VSCode

Vous pouvez connecter votre IDE préféré (tel que VS Code ou Studio) au conteneur IRIS à l'aide du port Superserver mappé (par défaut 1972 à l'intérieur du conteneur, par exemple, 9091 sur l'hôte) et du port du serveur Web (par défaut 52773 à l'intérieur du conteneur, par exemple, 9092 sur l'hôte). Cela vous permet de développer et de tester du code ObjectScript directement sur le conteneur en cours d'exécution.

Pour connecter le conteneur à VSCode:

• Installez la solution InterSystems ObjectScript Extension Pack
• Ouvrez l'extension InterSystems Server
• Cliquez sur les trois points et sélectionnez "Edit server" (Modifier le serveur)
•  
• Cliquez sur "Modifier dans settings.json"
• Ajoutez cet élément au fichier json "intersystems.servers":

"docker_iris": {
    "webServer": {
         "scheme": "http",
         "host": "localhost",
         "port": 9092
    },
    "description": "Connection to Docker container."
}

• Maintenant le serveur est connecté. Vous pouvez vous connecter avec l'utilisateur _SYSTEM.
• Comme vous pouvez le constater, l'espace de noms USER (UTILISATEUR) est le seul disponible:

5.6 Arrêt ou suppression du conteneur

Pour arrêter un conteneur en cours d'exécution, utilisez la commande:

docker stop my-iris

Redémarrage du conteneur

Pour redémarrer le conteneur, utilisez la commande

docker start my-iris

Suppression (effacement) du conteneur

Pour supprimer l'instance du conteneur, mais pas l'image, utilisez la commande: 

docker rm my-iris

La totalité des données contenues dans le conteneur sera perdue, sauf si vous avez monté des volumes (nous en parlerons dans les paragraphes suivants).

5.7 Configuration d'un mot de passe spécifique avec un montage de type bind

Il est possible de configurer un mot de passe personnalisé lors du démarrage d'un conteneur à l'aide d'un fichier de mots de passe. Le fichier sera enregistré sur notre hôte et copié dans le conteneur à l'aide du mécanisme bind mount .

Lorsque vous utilisez un bind mount, un fichier ou un répertoire sur la machine hôte est monté depuis l'hôte dans un conteneur, ce qui permet de partager le code source ou les artefacts de compilation entre un environnement de développement sur l'hôte Docker et un conteneur. 

• Créez un fichier nommé password.txt contenant uniquement votre mot de passe sous forme de chaîne (attention! Notez votre mot de passe, vous en aurez besoin plus tard). 
• Copiez le chemin d'accès, dans cet exemple ce sera C:\InterSystems\DockerTest\password\password.txt
• Exécutez la commande suivante:

docker run --name my-iris -d --publish 9091:1972 --publish 9092:52773 --volume "C:\InterSystems\DockerTest:/durable" intersystems/iris-community:latest-cd --password-file /durable/password/password.txt 

Une fois le conteneur lancé, vous pouvez vous connecter avec l'utilisateur _SYSTEM et le mot de passe que vous avez enregistré dans votre fichier de mots de passe. 

À l'intérieur du conteneur Docker, vous verrez un fichier password.txt.done . Le même fichier se trouvera dans votre dossier hôte.

L'extension du fichier est remplacée par .done afin d'éviter la présence du mot de passe dans le texte brut. Il s'agit du comportement standard d'InterSystems IRIS avec les fichiers de mots de passe. Par conséquent, une fois le mot de passe lu à partir du fichier password.txt et l'utilisateur IRIS par défaut (_SYSTEM) mis à jour avec ce mot de passe, le fichier est mis à jour en ajoutant .done et en supprimant le mot de passe pour des raisons de sécurité.

Vous pouvez vous connecter au Portail de gestion à l'aide de votre mot de passe personnalisé (je vous avais dit de le noter :D). InterSystems IRIS ne vous obligera pas à changer le mot de passe après votre connexion.

Veuillez noter que si le conteneur est supprimé puis redémarré sans aucun volume durable monté (pour plus d'informations, voir le paragraphe suivant), le mot de passe ne sera pas relu à partir du fichier password.txt , car il a été remplacé par le fichier password.txt.done. Dans ce cas, le mot de passe standard "SYS" sera utilisé. 

5.8 Démarrage du conteneur avec un volume durable spécifique. Utilisation de volumes %SYS durables

Par défaut, tout ce que vous enregistrez dans un conteneur Docker en cours d'exécution disparaît lorsque vous le supprimez à l'aide de la commande docker rm <container's name> . 

Pour éviter de perdre vos données, InterSystems IRIS fournit la fonctionnalité durable %SYS. Cette fonctionnalité permet à l'instance de stocker tous les fichiers importants sur votre machine hôte, afin qu'ils survivent aux redémarrages du conteneur et de l'instance.

5.8.1 Contenu stocké sous %SYS durable

Voici quelques exemples:

• Fichiers de configuration (iris.cpf, httpd.conf)
• Configurations et journaux de la passerelle Web (/csp)
• Bases de données système (IRIS, USER, IRISSECURITY, IRISTEMP, etc.)
• Journaux, fichiers image d'écriture (WIJ) et fichiers temporaires
• Fichiers journaux (messages.log, SystemMonitor.log, etc.)
• Clé de licence (iris.key)
• Toute autre base de données que vous avez créée

5.8.2 Comment activer %SYS durable

La première chose à faire est de choisir un dossier sur votre hôte, tel que C:\InterSystems\DockerTest

• Sous Linux, assurez-vous qu'IRIS peut y écrire en créant l'utilisateur irisowner et en lui attribuant la propriété du répertoire:

adduser irisowner
chown -R irisowner:irisowner /InterSystems/DockerTest

• Sous Windows, vous pouvez ignorer cette étape, car Docker Desktop will montera le dossier avec vos autorisations utilisateur Windows actuelles.

Ensuite, montez votre dossier hôte et indiquez à IRIS où écrire ses données durables à l'aide de la variable ISC_DATA_DIRECTORY:

  --volume "C:\InterSystems\DockerTest:/durable" --env ISC_DATA_DIRECTORY=/durable/iris

L'instruction complète à exécuter sur le terminal est la suivante:

docker run --name my-iris -d --publish 9091:1972 --publish 9092:52773 --volume "C:\InterSystems\DockerTest:/durable" --env ISC_DATA_DIRECTORY=/durable/iris intersystems/iris-community:latest-cd --password-file /durable/password/password.txt

À ce stade, vous pouvez inspecter votre conteneur et observer qu'un dossier durable est monté et contient les répertoires iris/ (pour le %SYS durable) et password/. Sur votre hôte, vous pouvez également voir les deux répertoires:

Si le conteneur est arrêté et supprimé, lorsque vous recréez le conteneur avec la même commande de Docker Compose IRIS restaurera son état précédent (utilisateurs, configuration, journaux, bases de données, etc.) à l'aide des données du dossier iris/, de sorte que rien ne soit perdu. Vous pouvez tester cette méthode en créant une application web, en arrêtant et en supprimant le conteneur, puis en le recréant une deuxième fois. Sans utiliser la fonctionnalité durable %SYS, toutes les modifications apportées à %SYS sont perdues lorsque le conteneur est supprimé et l'instance est lancée à chaque fois comme une nouvelle instance. 

Veuillez noter que si vous supprimez le dossier iris/, la prochaine fois que vous lancerez le conteneur IRIS, il sera initialisé comme lors d'une nouvelle installation, car il ne trouvera pas les données %SYS précédentes. Un tout nouveau dossier iris/ sera créé.

6. Utilisation de Docker Compose 

Jusqu'à présent, vous avez démarré InterSystems IRIS à l'aide d'une seule commande longue docker run. Cela fonctionne, mais il devient rapidement difficile de tout gérer avec des commandes shell simples.

Docker Compose est un fichier de configuration YAML qui permet de définir comment exécuter un ou plusieurs conteneurs. Cela simplifie le contrôle de l'ensemble de votre pile d'applications, facilitant la gestion des services, des réseaux et des volumes. Une seule commande vous permet de créer et de démarrer tous les services à partir de votre fichier de configuration.

Voici les commandes courantes pour Docker Compose:

6.1 Exemple d'utilisation de l'outil Docker Compose

Pour utiliser Docker Compose, il est nécessaire de créer un fichier docker-compose.yml contenant toutes les configurations du conteneur que l'on souhaite créer et démarrer.

Ainsi la commande suivante:

docker run --name my-iris -d --publish 9091:1972 --publish 9092:52773 --volume "C:\InterSystems\DockerTest:/durable" --env ISC_DATA_DIRECTORY=/durable/iris intersystems/iris-community:latest-cd --password-file /durable/password/password.txt

peut être remplacé par la suivante docker-compose.yml:

# docker-compose.yml     
services:
  iris:
    container_name: my-iris
    image: intersystems/iris-community:latest-cd
    init: true
    volumes:
      # Données système/persistantes (installation IRIS, bases de données, etc.)# Sous Windows, vous pouvez utiliser les deux options: "C:\\InterSystems\\DockerTest:/durable"
      - C:/InterSystems/DockerTest:/durable
      ports:
      - "9092:52773"# Portail de gestion / API REST
      - "9091:1972"# Port SuperServer
      environment:
      - ISC_DATA_DIRECTORY=/durable/iris
      # Utilisation du fichier de mots de passe pour se connecter au conteneur
      command: --password-file /durable/password/password.txt

6.2 Exécution de Docker Compose 

Ouvrez un terminal dans le répertoire où le fichier Docker Compose est enregistré (ou utilisez l'option -f) et exécutez la commande suivante:

docker compose up -d

Votre conteneur IRIS démarrera dans la configuration exacte spécifiée dans le fichier Docker Compose

Dans Docker Desktop, vous pouvez désormais voir qu'une pile composée appelée "dockertest" (elle prend le nom du dossier dans lequel Docker Compose est enregistré) a été créée et associée au conteneur "my-iris":

7. Utilisation d'un fichier Dockerfile pour l'exécution d'un code source personnalisé

Jusqu'à présent, vous avez exécuté InterSystems IRIS directement à partir de l'image Docker officielle. Cependant, nous aurons peut-être besoin de télécharger automatiquement des classes ObjectScript ou d'autres codes personnalisés dans l'image lors de sa création. 

Un fichier Dockerfileest un fichier texte contenant des instructions pour créer une image à partir d'une image de base (comme intersystems/iris-community:latest-cd). Grâce à un fichier Dockerfile, nous pouvons ajouter du code source personnalisé dans le conteneur et exécuter des commandes personnalisées lors de la création de l'image. 

7.1 Exemple de fichier Dockerfile

Le prochain exemple fournit un fichier Dockerfile qui effectue les opérations suivantes:

• Démarrez l' image à partir de l'image officielle InterSystems IRIS.
• Copiez le code de votre application depuis le dossier src/ vers le conteneur.
• Exécutez un script pour importer les classes et initialiser l'application conteneurisée, puis enregistrez les journaux dans un fichier journal.
• Exposez les ports InterSystems IRIS par défaut.

7.2 Exemple d'utilisation de l'outil Docker Compose

Vous devez également modifier Docker Compose afin de spécifier la création de l'image à partir du fichier Dockerfile situé dans le dossier courant:

# docker-compose.yml     
services:
  iris:
    container_name: my-iris
    build: # Cela indique à Docker de créer une nouvelle image basée sur celle spécifiée dans le fichier Dockerfile
      context: .        # Construction de l'image à partir du fichier Dockerfile local
      dockerfile: Dockerfile
    image: my-modified-iris-image:latest   # attribution d'une nouvelle balise à la nouvelle image afin d'éviter de remplacer l'image de base
    init: true
    volumes:
      # Données système/persistantes (installation IRIS, bases de données, etc.)# Sous Windows, vous pouvez utiliser les deux options: "C:\\InterSystems\\DockerTest:/durable"
      - C:/InterSystems/DockerTest:/durable
ports:
      - "9092:52773"# Portail de gestion / API REST
      - "9091:1972"# Port SuperServer
environment:
      - ISC_DATA_DIRECTORY=/durable/iris
    # Utilisation du fichier de mots de passe pour se connecter au conteneur
    command: --password-file /durable/password/password.txt

7.3 Compréhension des couches, du balisage des images et de la différence entre le temps de compilation et le temps d'exécution

Dans Docker, comme expliqué ici: Qu'est-ce qu'une image?, il y a deux principes importants à garder à l'esprit:

1. Les images sont immuables: une fois qu'une image est créée, elle ne peut plus être modifiée. Vous pouvez uniquement créer une nouvelle image ou y ajouter des modifications.
2. Les images de conteneur sont composées de couches: chaque couche représente un ensemble de modifications du système de fichiers qui ajoutent, suppriment ou modifient des fichiers.

De nouvelles couches sont ajoutées à une image lorsque les instructions spécifiées dans un fichier Dockerfile sont exécutées. Ces couches apparaîtront également dans les informations relatives à l'image.

Dans cette optique, il est très important de distinguer ce que fait Docker au temps de compilation (lorsqu'il crée une image à partir d'un fichier Dockerfile) et au temps d' exécution (lorsqu'il démarre un conteneur à partir de cette image).

Chacune de ces instructions Dockerfile est exécutée au temps de compilation: 

• COPY: les fichiers sont copiés dans l'image
• RUN: exécute des commandes et enregistre les résultats sous forme de nouvelles couches d'image
• ENTRYPOINT: ne modifie pas le système de fichiers, mais définit le processus par défaut qui sera lancé au moment de l'exécution
• EXPOSE: définit les métadonnées relatives aux ports que l'image prévoit d'utiliser

Au temps d'exécution, Docker ne reconstruit pas l'image, mais ajoute une couche de conteneur par-dessus. Toutes les modifications apportées pendant l'exécution du conteneur (comme les nouveaux fichiers, les modifications, les journaux) sont enregistrées dans cette couche temporaire.

D'après le dernier exemple fourni par Docker Compose:

build: # cela indique à Docker de créer une nouvelle image basée sur celle spécifiée dans le fichier Dockerfile
context: .        # Construction de l'image à partir du fichier Dockerfile local
dockerfile: Dockerfile
image: my-modified-iris-image:latest   # attribution d'une nouvelle balise à la nouvelle image afin d'éviter de remplacer l'image de base

Ces instructions indiquent à Docker de créer une nouvelle image appelée "my-modified-iris-image:latest" (ceci s'appelle un tag) en récupérant l'image de base et en la modifiant comme décrit dans le fichier Dockerfile. Il est très important de marquer la nouvelle image avec un nom distinct. Si nous évitons d'apposer une balise sur l'image nouvellement créée, l'image de base sera remplacée par la nouvelle. L'image officielle sera toujours disponible sur Docker Hub, mais cette version locale la masquera et tous les projets faisant référence à cette balise utiliseront désormais, sans le savoir, l'image personnalisée, contenant plusieurs nouvelles couches.

Pour éviter cela, utilisez toujours une balise distincte pour créer une nouvelle image distincte tout en conservant l'image de base officielle propre et réutilisable. 

7.4 Code source et script d'initialisation

À ce stade, nous devons créer au moins une classe et la placer dans le src/ dossier. La classe sera copiée dans le conteneur et importée via le iris.script fichier, qui contient toutes les instructions nécessaires pour importer les classes et initialiser l'application lors de la création de l'image.

Créez un nouveau répertoire appelé src/DockerStepByStep dans le dossier de votre projet et créez le fichier de classe suivant:

Class DockerStepByStep.cheers Extends%RegisteredObject
{
ClassMethod sayHi() As%Status
{
Set sc = $$$OKw"Hi mom!",!
Return sc
}
}

Dans la racine de votre projet, créez un fichier portant le nom iris.script:

// Non-expiration des mots de passe pour le mode devzn"%SYS"Do##class(Security.Users).UnExpireUserPasswords("*")
// Téléchargement des cours à partir d'une source fiablezn"USER"// Les classes à importerset importPath = "/opt/irisapp/src"write"Loading classes at '", importPath, "' ...", !
set errors = ""do$System.OBJ.Import(importPath,"cuk",,.errors)
if errors = 0 { write"Classes loaded successfully", ! } else { write errors, " errors occurred while loading classes!", ! }
halt

7.5 Création de l'image avec le fichier Dockerfile

Pour la première exécution, vous pouvez utiliser la commande suivante pour créer l'image à partir du fichier Dockerfile (le drapeau --build force Docker à recréer l'image à partir de votre fichier Dockerfile):

docker-compose up --build

Pour les autres exécutions, si le fichier Dockerfile n'a pas été modifié, vous pouvez simplement exécuter ce qui suit: 

docker-compose up -d

Une fois la création de l'image lancée, vous verrez apparaître les journaux suivants dans le terminal:

PS C:\InterSystems\DockerTest> docker-compose up --build
[+] Building 21.5s (13/13) FINISHED
 => [internal] load local bake definitions                                                                     0.0s
 => => reading from stdin 530B                                                                                 0.0s
 => [internal] load build definition from Dockerfile                                                           0.0s
 => => transferring dockerfile: 1.73kB                                                                         0.0s
 => [internal] load metadata for docker.io/intersystems/iris-community:latest-cd                              10.0s
 => [internal] load .dockerignore                                                                              0.0s
 => => transferring context: 2B                                                                                0.0s
 => [1/6] FROM docker.io/intersystems/iris-community:latest-cd@sha256:93488df381f5868649e7bfc33a9083a3e86a22d  0.9s
 => => resolve docker.io/intersystems/iris-community:latest-cd@sha256:93488df381f5868649e7bfc33a9083a3e86a22d  0.0s
 => [internal] load build context                                                                              0.0s
 => => transferring context: 147B                                                                              0.0s
 => [2/6] WORKDIR /opt/irisapp                                                                                 0.0s
 => [3/6] COPY src src                                                                                         0.1s
 => [4/6] COPY iris.script .                                                                                   0.1s
 => [5/6] RUN mkdir -p /opt/irisapp/logs                                                                       0.3s
 => [6/6] RUN iris start IRIS &&     iris session IRIS < iris.script > /opt/irisapp/logs/build.log 2>&1 &&     4.5s
 => exporting to image                                                                                         4.5s
 => => exporting layers                                                                                        3.3s
 => => exporting manifest sha256:3ce316cefa21a3707251c4287005a15b02e6dc0151b24baf2a82f76064792250              0.0s
 => => exporting config sha256:00238e19edef86b29149d2eb89ff75f4d1465ba0d9a2ac4494a14d3bd3746a94                0.0s
 => => exporting attestation manifest sha256:3579cab5c8accc7958090276deb60bd7dbbc2ecbf13af8e7fa8c4ff2dfe91028  0.0s
 => => exporting manifest list sha256:17b969c340f57d611cc7603287cc6db50cffd696258a72b5648ece0a919676ac         0.0s
 => => naming to docker.io/intersystems/iris-community:latest-cd                                               0.0s
 => => unpacking to docker.io/intersystems/iris-community:latest-cd                                            0.9s
 => resolving provenance for metadata file                                                                     0.0s
[+] Running 3/3
 ✔ intersystems/iris-community:latest-cd  Built                                                                0.0s
 ✔ Network dockertest_default             Created                                                              0.1s
 ✔ Container my-iris                      Created                                                              0.2s 

À l'étape 6/6, le fichier iris.script est exécuté dans l'instance IRIS conteneurisée et les journaux sont enregistrés dans le chemin /opt/irisapp/logs/build.log.

Pour afficher les journaux, vous pouvez exécuter l'instruction suivante:

docker exec -it my-iris cat /opt/irisapp/logs/build.log

Vous devriez voir les enregistrements suivants qui vous informent du résultat de la compilation de la classe:

Node: buildkitsandbox, Instance: IRIS
USER>
USER>
%SYS>
%SYS>
%SYS>
%SYS>
USER>
USER>
USER>
USER>
Loading classes at '/opt/irisapp/src' ...
USER>
USER>
Load of directory started on 09/16/202507:46:28
Loading file /opt/irisapp/src/DockerStepByStep/cheers.cls as udl
Compilation started on 09/16/202507:46:28 with qualifiers 'cuk'
Class DockerStepByStep.cheers is up-to-date.
Compilation finished successfully in 0.005s.
Load finished successfully.
USER>
Classes loaded successfully
USER>
USER>

Sur Docker Desktop, vous pouvez voir qu'une nouvelle image appelée "my-modified-iris-image" a été créée et s'exécute parallèlement à l'image officielle de base.

Si vous examinez les images, vous constaterez que la version personnalisée est composée de 31 couches, contre 25 couches pour l'originale. Les nouvelles couches correspondent aux instructions exécutées au moment de la compilation par le fichier Dockerfile:

7.6 Exécution d'instructions dans le terminal IRIS conteneurisé

Pour tester les classes, vous pouvez activer le terminal Iris dans l'instance IRIS conteneurisée. Pour ce faire, exécutez l'instruction suivante:

docker exec -it my-iris iris session IRIS

À ce stade, vous pouvez invoquer la méthode de classe à partir de l'espace de noms USER à l'aide de la commande suivante:

do##class(DockerStepByStep.cheers).sayHi()

Finalement, vous devriez obtenir le résultat suivant:

PS C:\InterSystems\DockerTest> docker exec -it my-iris iris session IRIS
Node: 41c3c7a9f2e4, Instance: IRIS
USER>do##class(DockerStepByStep.cheers).sayHi()
Hi mom!

8. Conclusion et suite

Nous avons parcouru l'ensemble du cycle de mise en œuvre d'InterSystems IRIS dans Docker:

• extraction de l'image
• démarrage et configuration des conteneurs
• persistance des données avec %SYS durable
• création d'images personnalisées avec votre propre code et vos propres scripts

Cela suffit pour commencer à expérimenter IRIS dans un environnement conteneurisé et l'utiliser pour le développement.

Un référentiel GitHub contenant tous les fichiers mentionnés dans la dernière partie (Docker Compose, Dockerfile, iris.script, etc.) est disponible.

Ne manquez pas le prochain article!

Cet article présente une introduction à la programmation Python dans le contexte d'IRIS.

Avant toute chose, je vais aborder un sujet important : Fonctionnement de Python. Cela vous aidera à comprendre certains problèmes et certaines limites que vous pourriez rencontrer lorsque vous utilisez Python dans IRIS.

Tous les articles et exemples sont disponibles dans ce dépôt git: iris-python-article

Fonctionnement de Python

Langage interprété

Python est un langage interprété, ce qui signifie que le code est exécuté ligne par ligne lors de l'exécution, même lorsque vous importez un script.

Qu'est-ce que cela veut dire? Examinons le code suivant:

# introduction.py

def my_function():
    print("Hello, World!")

my_function()

Lorsque vous exécutez ce script, l'interpréteur Python lit le code ligne par ligne. Il définit d'abord la fonction my_function, puis appelle cette fonction, qui affiche "Hello, World!" à la console.

Exemple d'exécution directe du script:

python3 /irisdev/app/src/python/article/introduction.py 

Cela donnera le résultat suivant:

Hello, World!

Dans un contexte IRIS, que se passera-t-il si nous importons ce script ?

Class Article.Introduction Extends %RegisteredObject
{
    ClassMethod Run()
    {
        Set sys = ##class(%SYS.Python).Import("sys")
        do sys.path.append("/irisdev/app/src/python/article")

        do ##class(%SYS.Python).Import("introduction")
    }
}

Lançons-le:

iris session iris -U IRISAPP '##class(Article.Introduction).Run()'

Cela donnera le résultat suivant:

Hello, World!

En effet, l'interpréteur Python importe le code en l'interprétant, il définit d'abord la fonction, puis l'appelle, exactement comme si vous exécutiez le script directement mais vous ne l'exécutez pas, vous l'importez.

⚠️ Remarque importante : si vous importez le script sans appeler la fonction, rien ne se passera. La fonction est définie, mais elle ne s'exécutera pas jusqu'à ce que vous l'appeliez explicitement.

Compris? L'interpréteur Python exécute le code dans le fichier, et si vous n'appelez pas la fonction, elle ne s'exécutera pas.

Exemple d'importation sans appel:

# introduction1.py
def my_function():
    print("Hello, World!")

Lançons-le dans un interpréteur Python:

python3 /irisdev/app/src/python/article/introduction1.py 

Résultat:

# Aucun résultat, puisque la fonction est définie mais n'est pas appelée

Dans un contexte IRIS, si vous importez ce script:

Class Article.Introduction1 Extends %RegisteredObject
{
    ClassMethod Run()
    {
        Set sys = ##class(%SYS.Python).Import("sys")
        do sys.path.append("/irisdev/app/src/python/article")
        do ##class(%SYS.Python).Import("introduction1")
    }
}

Lançons-le:

iris session iris -U IRISAPP '##class(Article.Introduction1).Run()'

Vous ne verrez aucun résultat,puisque la fonction est définie mais n'est pas appelée.

🤯 Pourquoi cette nuance est-elle importante?

• Lorsque vous importez un script Python, celui-ci exécute le code contenu dedans.
  • Vous ne souhaitez peut-être pas que cela se produise
• Vous pouvez être dérouté en pensant que l'importation d'un script revient à l'exécuter, mais ce n'est pas le cas.

Mise en cache des importations

Lorsque vous importez un script Python, l'interpréteur Python met en cache le script importé. Cela signifie que si vous importez à nouveau le même script, il ne réexécutera pas le code de ce script, mais utilisera la version mise en cache.

Exemple:

Réutilisons le script introduction.py:

# introduction.py
def my_function():
    print("Hello, World!")

my_function()

Maintenant, faisons la même chose en réutilisant la classe Article.Introduction:

Class Article.Introduction Extends %RegisteredObject
{
    ClassMethod Run()
    {
        Set sys = ##class(%SYS.Python).Import("sys")
        do sys.path.append("/irisdev/app/src/python/article")
        do ##class(%SYS.Python).Import("introduction")
    }
}

Mais maintenant, nous allons l'exécuter deux fois de suite dans la même session IRIS:

iris session iris -U IRISAPP 

IRISAPP>do ##class(Article.Introduction).Run()
Hello, World!

IRISAPP>do ##class(Article.Introduction).Run()

IRISAPP>

🤯 Mais qu'est-ce que c'est que ça ?

Oui, Hello, World! n'est imprimé qu'une seule fois !

⚠️ Votre script importé est mis en cache. Cela signifie que si vous modifiez le script après l'avoir importé, les modifications ne seront pas prises en compte tant que vous n'aurez pas modifié la session IRIS.

Cela vaut également si vous utilisez la balise de langage python language tag dans IRIS:

Class Article.Introduction2 Extends %RegisteredObject
{

ClassMethod Run() [ Language = python ]
{
    import os

    if not hasattr(os, 'foo'):
        os.foo = "bar"
    else:
        print("os.foo already exists:", os.foo)
}

}

Lançons-le:

iris session iris -U IRISAPP

IRISAPP>do ##class(Article.Introduction2).Run()

IRISAPP>do ##class(Article.Introduction2).Run()
os.foo already exists: bar

Oh non, le module os est mis en cache et l'attribut foo n'est pas redéfini comme inexistant.

Conclusion

J'espère que cette introduction sera utile pour comprendre pourquoi, lorsque vous travaillez avec Python dans IRIS, vous pouvez rencontrer des comportements inattendus, notamment lors de l'importation de scripts et de la mise en cache.

À retenir lorsque vous travaillez avec Python dans IRIS:

• Changez à chaque fois de session IRIS pour voir les modifications apportées à vos scripts Python.
  • Il ne s'agit pas d'un bug, c'est le fonctionnement normal de Python.
• N'oubliez pas que l'importation d'un script exécute son code.

Bonus

Attendez! C'est illogique, si vous dites que lorsque vous importez un script, il est mis en cache. Pourquoi, lorsque je travaille avec la balise language tag = python, lorsque je modifie le script, cela fonctionne sans changer la session IRIS?

Bonne question, cela est dû au fait que la balise language tag est conçue pour que, chaque fois que vous l'exécutez, elle relise le script et l'exécute ligne par ligne comme s'il s'agissait de nouvelles lignes dans un interpréteur Python natif. La balise language tag n'importe pas le script, elle l'exécute simplement comme si vous l'exécutiez directement dans un interpréteur Python sans le relancer.

Exemple:

Class Article.Introduction2 Extends %RegisteredObject
{
ClassMethod Run() [ Language = python ]
{
    import os

    if not hasattr(os, 'foo'):
        os.foo = "bar"
    else:
        print("os.foo already exists:", os.foo)
}
}

Lançons-le:

iris session iris -U IRISAPP
IRISAPP>do ##class(Article.Introduction2).Run()

IRISAPP>do ##class(Article.Introduction2).Run()
os.foo already exists: bar  

Dans un interpréteur Python, cela se présentera comme suit:

import os

if not hasattr(os, 'foo'):
    os.foo = "bar"
else:
    print("os.foo already exists:", os.foo)

import os
if not hasattr(os, 'foo'):
    os.foo = "bar"
else:
    print("os.foo already exists:", os.foo)

Résultat:

os.foo already exists: bar # only printed once

Maintenant, c'est clair?

Suite:

• Pep8
• Modules
• Méthodes Dunder
• Utilisation de Python dans IRIS
• ...

Je sais que ceux qui découvrent VS Code, Git, Docker, FHIR et d'autres outils peuvent parfois avoir des difficultés à configurer l'environnement. J'ai donc décidé de rédiger un article qui explique étape par étape l'ensemble du processus de configuration afin de faciliter les premiers pas.

Je vous serais très reconnaissant de bien vouloir laisser un commentaire à la fin de cet article pour me faire savoir si les instructions étaient claires, s'il manquait quelque chose ou si vous avez d'autres suggestions qui pourraient être utiles.

La configuration comprend:

✅ VS Code – Éditeur de code
✅ Git – Système de contrôle de version
✅ Docker – Lancement d'une instance de la communauté IRIS for Health
✅ Extension VS Code REST Client – Pour l'exécution de requêtes API FHIR
✅ Python – Pour l'écriture de scripts basés sur FHIR
✅ Jupyter Notebooks – Pour les tâches liées à l'IA et au FHIR

Avant de commencer: Vérifiez que vous disposiez des privilèges d'administrateur sur votre système.

Outre la lecture du guide, vous pouvez également suivre les étapes décrites dans les vidéos:

Pour Windows

<iframe allowfullscreen="" frameborder="0" height="360" src="https://www.youtube.com/embed/IyvuHbxCwCY" width="640"></iframe>

Pour macOS

<iframe allowfullscreen="" frameborder="0" height="360" src="https://www.youtube.com/embed/Ss7vU0l3JNU" width="640"></iframe>

Vous trouverez un sondage à la fin de l'article, merci de partager vos progrès. Vos commentaires sont très appréciés.

Alors, c'est parti!

1. Installation de Visual Studio Code (VS Code)

VS Code sera l'éditeur principal pour le développement.

Windows et amp; macOS

1. Accédez à la page de téléchargement de VS Code: https://code.visualstudio.com/
2. Téléchargez le programme d'installation pour votre système d'exploitation:
   • Windows: .exe file
   • macOS: .dmg file
3. Exécutez le programme d'installation et suivez les instructions.
4. (Windows uniquement) : pendant l'installation, cochez la case Add to PATH" (Ajouter au PATH).
5. Vérifiez l'installation:

• ouvrez un terminal (Command Prompt, , PowerShell ou Terminal macOS)
• Exécutez:

code --version

• Vous devriez voir le numéro de version.

2. Installation de Git

Git est nécessaire pour le contrôle de version, le clonage et la gestion des référentiels de code.

Windows

1. Téléchargez la dernière version à partir de: https://git-scm.com/downloads
2. Exécutez le programme d'installation:
   • Choisissez "Use Git from the Windows Command Prompt" (Utiliser Git à partir de l'invite de commande Windows).
   • Conservez les paramètres par défaut et terminez l'installation.
3. Vérifiez l'installation:

git --version

macOS

1. Ouvrez le terminal et exécutez:

git --version

Si Git n'est pas installé, macOS vous demandera d'installer les outils de ligne de commande Suivez les instructions.

3. Installation de Docker

Docker est indispensable pour exécuter InterSystems IRIS for Health Community.

Windows

1.    Téléchargez Docker Desktop à partir de: https://www.docker.com/products/docker-desktop
2.    Exécutez le programme d'installation et suivez les instructions.
3.    Redémarrez votre ordinateur après l'installation.
4.    Activez WSL 2 Backend (si cela vous est demandé).
5.    Verifiez l'installation

À remarquer: L'installation de Docker nécessite des privilèges d'administrateur sur votre machine et au moins un redémarrage.

macOS

1.    Téléchargez Docker Desktop pour Mac à partir de: https://www.docker.com/products/docker-desktop
2.    Installez-le en glissant Docker.app dans le dossier Applications.
3.    Ouvrez Docker à partir du menu Applications.

Pour vous assurer que le moteur Docker Desktop fonctionne sous Windows ou macOS, procédez comme suit:

Démarrez Docker Desktop

Windows: Ouvrez Docker Desktop à partir du menu Start. L'icône Docker en forme de baleine devrait apparaître dans votre barre d'état système.

Mac: Lancez Docker Desktop à partir du dossier Applications. Une fois l'application lancée, l'icône Docker en forme de baleine apparaîtra dans la barre de menu.

Attendez l'initialisation

Une fois que vous avez lancé Docker Desktop, le moteur peut prendre un certain temps à démarrer. Recherchez un message d'état indiquant que Docker est "running" (en cours d'exécution) ou "started" (démarré).

Vérifiez via le terminal/Command Prompt:

Ouvrez le terminal (ou Command Prompt/PowerShell pour Windows) et exécutez:

docker --version

ou

docker info

Dépannage

Si le moteur ne fonctionne pas, essayez de redémarrer Docker Desktop ou vérifiez s'il y a des messages d'erreur dans l'interface utilisateur de Docker Desktop. Assurez-vous également que votre système répond aux exigences de Docker Desktop. Vous pouvez voir des messages d'erreur confus faisant référence à des pipes si vous essayez de créer une image Docker sans que Docker Desktop soit en cours d'exécution.

4. Création de l'image IRIS for Health et son exécution à l'aide de Docker

Avant de pouvoir démarrer un conteneur Docker exécutant IRIS for Health Community (qui comprend notre serveur FHIR), nous devons le créer.

1. Clonez le référentiel FHIR dans un répertoire approprié de votre système de fichiers. Ouvrez un terminal dans VS Code et clonez ce référentiel à l'aide de la commande suivante:

   git clone https://github.com/pjamiesointersystems/Dockerfhir.git

    
2. Accédez à ce répertoire et ouvrez le dossier dans VS Code. Suivez les instructions du fichier readme pour créer et exécuter le conteneur. Une étape essentielle consiste à vous assurer que le référentiel de base est disponible dans votre magasin Docker. Vous pouvez le faire à l'aide de la commande dans le terminal VS Code:

   docker pull containers.intersystems.com/intersystems/irishealth-community:latest-em

   Vous devriez recevoir une confirmation après quelques minutes.
3. Accédez au répertoire dans VS Code où se trouve le fichier docker-compose.yaml, puis exécutez la commande suivante:

   docker-compose build 

   Cela lancera le processus de compilation, qui peut prendre jusqu'à 10 minutes, au cours desquelles un référentiel FHIR complet sera créé et chargé avec un échantillon de patients. 
4. Une fois le processus de compilation terminé, lancez le conteneur à l'aide de la commande suivante:

   docker-compose up -d

   suivi par

   docker ps

   Vous devriez voir un conteneur nommé **iris-fhir** en cours d'exécution. Si le conteneur ne démarre pas, vérifiez les journaux:

   docker logs iris-fhir

    

5. Installation de l'extension VS Code REST Client

Cette extension vous permet d'envoyer des requêtes API FHIR depuis VS Code.

1. Ouvrez VS Code.
2. Accédez aux extensions (Ctrl + Shift + X or Cmd + Shift + X on macOS).
3. Recherchez "REST Client". Il existe plusieurs clients REST, veuillez installer celui-ci:
4. Clickez le bouton "Install".

6. Installation de Python

Python est indispensable pour les tâches de programmation liées à FHIR.

Windows

1.    Télécharger Python à partir de: https://www.python.org/downloads/
2.    Exécutez le programme d'installation et cochez la case "Add to PATH" (Ajouter au chemin). Vous aurez besoin d'informations d'identification administratives pour apporter des modifications au chemin d'accès
3.    Terminez l'installation.
4.    Verifiez l'installation:

python --version

macOS

1. Ouvrez le Terminal et installez Python via Homebrew:

   Brew install python

   Si vous n'avez pas d'Homebrew, installez-le d'abord:

   /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

    
2. Verifiez l'installation:

python3 --version

7. Installation des blocs-notes Jupyter

Les notebooks Jupyter sont utilisés pour l'IA et le FHIR, ainsi que pour les tâches  FHIR SQL.

Windows & macOS

1. Ouvrez le terminal (Command Prompt, PowerShell, ou macOS Terminal).
2. Installez Jupyter à l'aide de pip:

   pip install jupyter
   jupyter --version

    
3. Exécutez le bloc-note Jupyter:

jupyter notebook

Jupyter s'ouvrira alors dans votre navigateur web.

8.  Validation

Exécutez votre conteneur en accédant à votre fichier Docker Compose dans le shell. Exécutez la commande 

docker compose up -d
docker ps

Accédez au Portail de gestion d'IRIS:

• Ouvrez votre navigateur et accédez à: http://localhost:8080/csp/sys/UtilHome.csp
• Informations d'identification par défaut:

Nom d'utilisateur: _SYSTEM
Mot de passe: ISCDEMO

Accédez à l'API FHIR

• Ouvrez votre navigateur et accédez à: http://localhost:8080/csp/healthshare/demo/fhir/r4/metadata

Dernières vérifications

Exécutez les commandes suivantes pour vérifier toutes les installations:

code --version       # VS Code
git --version        # Git
docker --version     # Docker
python --version     # Python
jupyter --version    # Jupyter

Si tout fonctionne, vous avez installé correctement tous les logiciels ci-dessus.

Dépannage

Merci de votre aide. J'attends vos commentaires avec impatience!

Cela fait un moment que je n'ai pas publié d'article sur Embedded Git sur la Communauté des développeurs, et j'aimerais faire le point sur l'énorme quantité de travail que nous avons accompli cette année et sur la direction que nous allons prendre ensuite.

Contexte

Si vous créez des solutions sur IRIS et que vous souhaitez utiliser Git, c'est parfait ! Utilisez simplement VSCode avec un dépôt git local et transmettez vos modifications sur le serveur : c'est aussi simple que cela.

Mais que se passe-t-il si :

L'équipe de développement d'extensions VS Code recherche des bêta-testeurs pour fournir des commentaires sur une refonte proposée du flux de travail d'édition côté client. La liste complète des modifications se trouve dans la description de la GitHub pull request. Voici les points saillants :

Bienvenue dans le prochain chapitre de ma série CI/CD, où nous discutons des approches possibles vers le développement de logiciels avec les technologies InterSystems et GitLab. Aujourd'hui, nous reprenons la discussion sur l'interopérabilité, et plus particulièrement sur le suivi de vos déploiements d'interopérabilité. Si vous ne l'avez pas encore fait, configurez Alerte pour toutes vos productions d'interopérabilité afin de recevoir des alertes sur les erreurs et l'état de la production dans son ensemble.

Le paramètre de délais d'inactivité Inactivity Timeout est commun pour tous les hôtes métier d'interopérabilité (Interoperability Business Hosts). Un hôte métier possède le statut Inactif lorsqu'il n'a reçu aucun message pendant le nombre de secondes spécifié dans le champ de délai d'inactivité " Inactivity Timeout ". La fonction de surveillance de la production " Monitor Service " examine périodiquement l'état des services et des opérations métier au sein de la production et marque les éléments comme étant inactifs s'ils n'ont rien fait pendant le délai d'inactivité. La valeur par défaut est 0 (zéro). Si ce paramètre est 0, l'hôte métier ne sera jamais marqué comme Inactif, quelle que soit la durée de son inactivité.

Ce paramètre est extrêmement utile, car il génère des alertes qui, associées aux alertes configurées, permettent de signaler les problèmes de production en temps réel. Le fait que l'élément "Business Host" soit inactif signifie qu'il peut y avoir des problèmes de production, d'intégration ou de connectivité réseau qui nécessitent d'être examinés. Cependant, le Business Host ne peut avoir qu'un seul paramètre constant pour le délai d'inactivité, ce qui peut générer des alertes inutiles pendant les périodes connues de faible trafic : nuits, week-ends, vacances, etc. Dans cet article, je décrirai plusieurs approches pour la mise en œuvre dynamique des délais d'inactivité (Inactivity Timeout). Bien que je fournisse un exemple fonctionnel (qui fonctionne actuellement en production pour l'un de nos clients), cet article est plutôt un guide pour votre propre mise en œuvre dynamique des délais d'inactivité, donc ne considérez pas la solution proposée comme la seule alternative.

Idée

Le moteur d'interopérabilité maintient une globale spéciale HostMonitor, qui contient chaque Business Host sous forme d'indice, et l'horodatage de la dernière activité sous forme de valeur. Au lieu d'utiliser le délai d'inactivité, nous allons surveiller nous-mêmes cette globale et générer des alertes en fonction de l'état de HostMonitor. HostMonitor est maintenue que soit la valeur du délai d'inactivité définie - elle est toujours activée.

Mise en œuvre

Pour commencer, voyons comment nous pouvons itérer la globale HostMonitor :

Set tHost=""
For {
Set tHost=$$$OrderHostMonitor(tHost)
Quit:""=tHost
Set lastActivity = $$$GetHostMonitor(tHost,$$$eMonitorLastActivity)
}

Pour créer notre Monitor Service, il nous faut effectuer les vérifications suivantes pour chaque Business Host :

1. Décidez si le Business Host est concerné par notre configuration dynamique des délais d'inactivité (par exemple, les interfaces hl7 à fort trafic peuvent fonctionner avec le délai d'inactivité habituel).
2. Si le Business Host se trouve dans le champ d'action, nous devons calculer le temps écoulé depuis la dernière activité.
3. En fonction du temps d'inactivité et d'un certain nombre de conditions (heure du jour/de la nuit, jour de la semaine), nous devons décider si nous voulons envoyer une alerte.
4. Si nous voulons envoyer un enregistrement d'alerte, nous devons enregistrer l'heure de la Dernière activité (Last Activity) afin de ne pas envoyer la même alerte deux fois.

Notre code se présente comme suit :

Set tHost=""
For { 
  Set tHost=$$$OrderHostMonitor(tHost) 
  Quit:""=tHost
  Continue:'..InScope(tHost)
  Set lastActivity = $$$GetHostMonitor(tHost,$$$eMonitorLastActivity)
  Set tDiff = $$$timeDiff($$$timeUTC, lastActivity)
  Set tTimeout = ..GetTimeout(tDayTimeout)
  If (tDiff > tTimeout) && ((lastActivityReported="") || ($system.SQL.DATEDIFF("s",lastActivityReported,lastActivity)>0)) {
    Set tText = $$$FormatText("InactivityTimeoutAlert: Inactivity timeout of '%1' seconds exceeded for host '%2'", +$fn(tDiff,,0), tHost)
    Do ..SendAlert(##class(Ens.AlertRequest).%New($LB(tHost, tText)))
    Set $$$EnsJobLocal("LastActivity", tHost) = lastActivity
  } 
}

Vous devez implémenter les méthodes InScope et GetTimeout contenant votre logique personnalisée, et vous êtes prêt à démarrer. Dans mon exemple, il y a des délais de jour (Day Timeouts, qui peuvent être différents pour chaque Business Host, mais avec une valeur par défaut) et des délais de nuit (Night Timeouts, qui sont les mêmes pour tous les Business Hosts enregistrés), de sorte que l'utilisateur doit fournir les paramètres suivants :

• Champs d'application : Liste des noms (ou parties de noms) de Business Host associés à leur valeur DayTimeout personnalisée, une par ligne. Seuls les Business Hosts qui se trouve dans le champ d'action (qui remplissent la condition $find(host, scope) pour au moins un champ d'action) seront suivis. Laisser ce champ vide pour surveiller tous les Business Hosts. Exemple: OperationA=120
• DayStart : Nombre de secondes depuis 00:00:00, point de départ d'une journée. Il doit être inférieur à DayEnd. Par exemple, 06:00:00 AM est 6*3600 = 21600
• DayEnd: Nombre de secondes depuis 00:00:00, point de fin d'une journée. Il doit être supérieur à DayStart. Par exemple 08:00:00 du soir est (12+8)*3600 = 72000
• DayTimeout : Valeur du délai d'attente par défaut en secondes pour le déclenchement d'alertes pendant la journée.
• NightTimeout : Valeur du délai d'attente par défaut en secondes pour le déclenchement d'alertes pendant la nuit.
• WeekendDays: Jours de la semaine considérés comme week-end. Séparés par des virgules. Pour le week-end, NightTimeout s'applique 24 heures par jour. Exemple : 1,7 Vérifiez la valeur DayOfWeek de la date en exécutant : $SYSTEM.SQL.Functions.DAYOFWEEK(date-expression). Par défaut, les valeurs renvoyées représentent les jours suivants : 1 - dimanche, 2 - lundi, 3 - mardi, 4 - mercredi, 5 - jeudi, 6 - vendredi, 7 - samedi.

Voici le code complet, mais je ne pense pas qu'il y ait quelque chose d'intéressant là-dedans. Il implémente simplement les méthodes InScope et GetTimeout. Vous pouvez utiliser d'autres critères et adapter les méthodes InScope et GetTimeout si nécessaire.

Problèmes

Il y a deux problèmes à aborder:

• Pas d'icône jaune pour les Business Hosts inactifs (puisque la valeur du paramètre InactivityTimeout de l'hôte est nulle).
• Paramètres hors hôte - les développeurs doivent se rappeler de mettre à jour ce service de surveillance personnalisé chaque fois qu'ils ajoutent un nouvel Business Host et qu'ils souhaitent utiliser une implémentation dynamique de délais d'inactivité.

Alternatives

J'ai exploré toutes ces approches avant de mettre en œuvre la solution ci-dessus :

1. Créer le Business Service qui modifie les paramètres InactivityTimeout lorsque le jour ou la nuit commence. Au départ, j'ai essayé de suivre cette voie mais j'ai rencontré un certain nombre de problèmes, principalement l'obligation de redémarrer tous les Business Hosts concernés à chaque fois que nous modifions le paramètre InactivityTimeout.
2. Ajouter de règles dans le processeur d'alertes personnalisé (Custom Alert Processor) qui, au lieu d'envoyer l'alerte, la suppriment si c'est le délai nocturne InactivityTimeout. Mais une alerte d'inactivité provenant de Ens.MonitorServoce met à jour la valeur LastActivity, donc je ne vois pas de moyen, à partir d'un Custom Alert Processor, d'obtenir un "vrai" horodatage de dernière activité (à part interroger Ens.MessageHeader, je suppose ?). Et si c'est " nuit " - retourner l'état de l'hôte à OK, si ce n'est pas encore " InactivityTimeout " nocturne, et supprimer l'alerte.
3. L'extension de Ens.MonitorService ne semble pas possible sauf pour le callback OnMonitor, mais cela sert un autre but.

Conclusion

Toujours configurer [alerte] https://docs.intersystems.com/iris20233/csp/docbook/Doc.View.cls?KEY=ECONFIG_alerts) pour toutes vos productions d'interopérabilité afin de recevoir des alertes sur les erreurs et l'état de la production dans son ensemble. Si une configuration statique de délai d'inactivité n'est pas suffisante, vous pouvez facilement créer une implémentation dynamique.

Liens

• Inactivity Timeout
• Alerting
• Sample code

Bienvenue dans le prochain chapitre de ma série CI/CD, où nous discutons des approches possibles vers le développement de logiciels avec les technologies InterSystems et GitLab.

Aujourd'hui, parlons d'interopérabilité.

Problème

Lorsque vous avez une production d'interopérabilité active, vous avez deux flux de processus distincts : une production active qui traite les messages et un flux de processus CI/CD qui met à jour le code, la configuration de la production et les paramètres par défaut du système.

De toute évidence, le processus CI/CD affecte l'interopérabilité. Mais il y a des questions :

• Que se passe-t-il exactement lors d'une mise à jour ?
• Que devons-nous faire pour minimiser ou éliminer les temps d'arrêt de la production lors d'une mise à jour ?

Terminologie

• Business Host (BH) - un élément configurable de la production d'interopérabilité : Service métier (BS), Processus métier (BP, BPL) ou Opération métier (BO).
• Business Host Job (Job) - Tâche InterSystems IRIS qui exécute le code du Business Host et qui est gérée par la production d'interopérabilité.
• Production : ensemble interconnecté de serveurs d'entreprise (Hôte métier).
• System Default Settings (Paramètres par défaut du système) (SDS) - valeurs spécifiques à l'environnement dans lequel InterSystems IRIS est installé.
• Message actif - demande en cours de traitement par une tâche Business Host Job. Une tâche Business Host Job peut avoir un maximum d'un Message actif. Une tâche Business Host Job qui n'a pas de message actif est inactif.

Qu'est-ce qui se passe?

Commençons par le cycle de vie de la production.

Démarrage de la production

Tout d'abord, la production peut être démarrée. Une seule production par espace de noms peut être lancée simultanément, et en général (à moins que vous ne sachiez vraiment ce que vous faites et pourquoi vous le faites), vous ne devrez lancer qu'une seule production par espace de noms, jamais. Il n'est pas recommandé de passer d'un espace de noms à l'autre entre deux ou plusieurs productions différentes. Le démarrage de la production démarre tous les Business Hosts activés définis dans la production. Le fait que certains Business Hosts ne démarrent pas n'affecte pas le démarrage de la production.

Conseils:

• Démarrez la production à partir du portail de gestion du système ou en appelant : ##class(Ens.Director).StartProduction("ProductionName")
• Exécutez un code arbitraire au démarrage de la production (avant qu'un Job Business Host ne soit démarré) en implémentant une méthode OnStart.
• Le démarrage de la production est un événement contrôlable. Vous pouvez toujours voir qui et quand a fait cela dans le journal d'audit.

Mise à Jour de la production

Après le démarrage de la production, l'outil Ens.Director surveille en permanence la production en cours. Il existe deux états de production : état cible, défini dans la classe de production et les paramètres par défaut du système ; et état en cours d'exécution - les tâches en cours d'exécution avec les paramètres appliqués lors de la création des tâches. Si l'état souhaité et l'état actuel sont identiques, tout va bien, mais la production peut (et doit) être mise à jour s'il y a une différence. Habituellement, vous voyez cela sous la forme d'un bouton rouge "Mettre à jour" sur la page Configuration de la production dans le Portail de gestion du système.

La mise à jour de la production signifie une tentative pour que l'état de production actuel corresponde à l'état de production cible.

Lorsque vous exécutez ##class(Ens.Director).UpdateProduction(timeout=10, force=0) pour mettre à jour la production, il effectue les opérations suivantes pour chaque Business Host :

1. Comparez les réglages actifs aux réglages de production/SDS/classe.
2. Uniquement si (1) révèle une incohérence, le Business Host est marqué comme étant obsolète et nécessitant une mise à jour.

Après avoir exécuté cette opération pour chaque Business Host, UpdateProduction construit l'ensemble des changements :

• Business Hosts à arrêter
• Business Hosts à démarrer
• Paramètres de production à mettre à jour

Ensuite, il les applique.

De cette manière, la "mise à jour" des paramètres sans rien changer n'entraîne aucune interruption de la production.

Conseils:

• Mettre à jour la production à partir du portail de gestion du système ou en appelant : ##class(Ens.Director).UpdateProduction(timeout=10, force=0)
• Le délai de mise à jour par défaut du portail de gestion du système est de 10 secondes. Si vous savez que le traitement de vos messages prend plus de temps, appelez Ens.Director:UpdateProduction avec un délai plus long.
• Le délai de mise à jour est un paramètre de production, et vous pouvez le modifier pour une valeur plus importante. Ce paramètre s'applique au portail de gestion du système.

Mise à jour du code

UpdateProduction NE MET PAS A JOUR les BHs dont le code est obsolète. C'est un comportement orienté vers la sécurité, mais si vous voulez mettre à jour automatiquement tous les BHs en cours d'exécution lorsque le code sous-jacent change, suivez les étapes suivantes :

First, load and compile like this:

do $system.OBJ.LoadDir(dir, "", .err, 1, .load)
do $system.OBJ.CompileList(load, "curk", .errCompile, .listCompiled)

Maintenant, listCompiled contiendrait tous les éléments qui ont été compilés (utilisez git diffs pour minimiser l'ensemble des éléments importés) à cause du marqueur u. Utilisez cette listCompiled pour obtenir un $lb de toutes les classes qui ont été compilées :

set classList = ""
set class = $o(listCompiled(""))
while class'="" { 
  set classList = classList _ $lb($p(class, ".", 1, *-1))
  set class=$o(listCompiled(class))
}

Et ensuite, calculer une liste de BHs qui nécessitent un redémarrage :

SELECT %DLIST(Name) bhList
FROM Ens_Config.Item 
WHERE 1=1
  AND Enabled = 1
  AND Production = :production
  AND ClassName %INLIST :classList

Enfin, après avoir obtenu bhList, arrêtez et démarrez les hôtes affectés :

for stop = 1, 0 {
  for i=1:1:$ll(bhList) {
    set host = $lg(bhList, i)
    set sc = ##class(Ens.Director).TempStopConfigItem(host, stop, 0)
  }
  set sc = ##class(Ens.Director).UpdateProduction()
}

Arrêt de production

Les productions peuvent être arrêtées, ce qui implique d'envoyer une demande à tous les Jobs Business Host pour qu'ils s'arrêtent (en toute sécurité, une fois qu'ils ont terminé leurs messages actifs, le cas échéant).

Conseils:

• Arrêtez la production à partir du portail de gestion du système ou en appelant : ##class(Ens.Director).StopProduction(timeout=10, force=0)
• Le délai d'arrêt par défaut du portail de gestion du système est de 120 secondes. Si vous savez que le traitement de vos messages prend plus de temps que cela, appelez Ens.Director:StopProduction avec un délai plus long.
• Le délai d'arrêt est un paramètre de production. Vous pouvez le modifier pour une valeur plus importante. Ce paramètre s'applique au portail de gestion du système.
• Exécuter un code arbitraire lors d'un arrêt de production en implémentant une méthode OnStop.
• L'arrêt de la production est un événement contrôlable, vous pouvez toujours voir qui et quand a fait cela dans le journal d'audit.

Ce qui est important ici, c'est que la production est la somme totale des Business Hosts :

• Le démarrage de la production signifie le démarrage de tous les Business Hosts activés.
• L'arrêt de la production signifie l'arrêt de tous les Business Hosts en cours d'exécution.
• La mise à jour de la production consiste à calculer un sous-ensemble de Business Hosts qui sont obsolètes, de sorte qu'ils sont d'abord arrêtés, puis redémarrés immédiatement après. En outre, un Business Host nouvellement ajouté est seulement démarré, et un Business Host supprimé de la production est seulement arrêté.

Cela nous amène au cycle de vie des Business Hosts.

Démarrage du Business Host

Les Business Hosts sont composés de Business Hosts Jobs identiques (en fonction de la valeur du paramètre Pool Size). Le démarrage d'un Business Host implique le démarrage de tous les Business Hosts Jobs. Ils sont démarrés en parallèle.

Business Host Job individuel commence comme ceci :

1. Interopérabilité de JOBs est un nouveau processus qui deviendrait un Business Host Job.
2. Le nouveau processus s'enregistre en tant que job d'interopérabilité.
3. Le code du Business Host et le code de l'adaptateur (Adapter) sont chargés dans la mémoire du processus.
4. Les paramètres relatifs à un Business Host et à un adaptateur sont chargés dans la mémoire. L'ordre de priorité est le suivant a. Paramètres de production (remplacent les paramètres par défaut du système et les paramètres de classe). b. Paramètres par défaut du système (prévalent sur les paramètres de classe). c. Paramètres de classe.
5. Le travail est prêt et commence à accepter des messages.

Une fois le point (4) effectué, la tâche ne peut plus modifier les paramètres ou le code. Ainsi, lorsque vous importez un nouveau code et de nouveaux paramètres par défaut, cela n'affecte pas les tâches d'interopérabilité en cours d'exécution.

Arrêt de Business Host

L'arrêt du Business Host Job signifie le suivant :

1. L'interopérabilité ordonne à Job d'arrêter toute acceptation de messages/entrées.
2. S'il y a un message actif, le Business Host Job dispose d'un délai de quelques secondes pour le traiter (en le complétant - en complétant la méthode OnMessage pour BO, OnProcessInput pour BS, la méthode d'état S<int> pour les BP BPL, et la méthode On* pour les BP).
3. Si un message actif n'a pas été traité avant le timeout et force=0, la mise à jour de la production échoue pour ce Business Host (et vous verrez un bouton rouge Update dans le SMP).
4. L'arrêt réussit si l'un des éléments de cette liste est vrai :
   • Pas de message actif
   • Le message actif a été traité avant le timeout.
   • Le message actif n'a pas été traité avant le timeout MAIS force=1.
5. Le travail est désenregistré auprès de l'interopérabilité et s'arrête.

Mise à jour de Business Host

La mise à jour du Business Host signifie l'arrêt des tâches en cours d'exécution pour le Business Host et le démarrage de nouvelles tâches.

Les régles métier "Business Rules", les régles de routage "Routing Rules" et les DTL

Tous les Business Hosts commencent immédiatement à utiliser les nouvelles versions des régles Business Rules, Routing Rules et des DTL dès qu'elles sont disponibles. Le redémarrage d'un Business Host n'est pas nécessaire pour cela.

Mises à jour hors ligne

Il arrive cependant que les mises à jour de la production nécessitent l'arrêt de certains Business Hosts.

Les régles dépendent du nouveau code

Considérons la situation. Vous disposez d'une règle de routage Routing Rule X qui achemine les messages vers le processus Business Process A ou B en fonction de critères arbitraires. Dans un nouveau commit, vous ajoutez simultanément:

• le processus Business Process C
• Une nouvelle version de Routing Rule X, qui achemine les messages vers A, B ou C.

Dans ce scénario, vous ne pouvez pas charger la règle d'abord et mettre à jour la production ensuite. En effet, la règle nouvellement compilée commencerait immédiatement à router les messages vers le Business Process C, qu'InterSystems IRIS n'a peut-être pas encore compilé, ou que l'interopérabilité n'a pas encore mis à jour pour l'utiliser. Dans ce cas, vous devez désactiver le Business Host avec une règle de routage, mettre à jour le code, mettre à jour la production et réactiver le Business Host.

Remarques:

• Si vous mettez à jour une production à l'aide du fichier de déploiement de la production, tous les BH concernés seront automatiquement désactivés/activés.
• Pour les hôtes invoqués par InProc, la compilation invalide le cache de l'hôte particulier détenu par l'appelant.

Dépendances entre Business Hosts

Les dépendances entre les Business Hosts sont essentielles. Imaginons que vous ayez des processus Business Hosts A et B, dans lesquels A envoie des messages à B. Dans un nouveau commit, vous ajoutez simultanément :

• Une nouvelle version du Processus A, qui définit une nouvelle propriété X dans une demande adressée à B
• Une nouvelle version du Processus B qui peut traiter une nouvelle propriété X

Dans ce scénario, nous DEVONS mettre à jour le Processus B d'abord et le Processus A ensuite. Vous pouvez procéder de deux manières :

• Désactiver les Business Hosts pendant la durée de la mise à jour.
• Diviser la mise à jour en deux parties : d'abord, mettre à jour le Processus B uniquement, et ensuite, dans une mise à jour séparée, commencer à lui envoyer des messages à partir du Processus A.

Une variante plus difficile de ce thème, où les nouvelles versions des Processus A et B sont incompatibles avec les anciennes versions, nécessite un arrêt des Business Hosts.

Files d'attente

Si vous savez qu'après la mise à jour, un Business Host ne pourra plus traiter les anciens messages, vous devez vous assurer que la file d'attente du Business Host est vide avant la mise à jour. Pour ce faire, désactivez tous les Business Hosts qui envoient des messages au Business Host et attendez que sa file d'attente soit vide.

Changement d'état dans les BPL Business Processes

Tout d'abord, une petite introduction sur le fonctionnement des BPL BP. Après avoir compilé un BPL BP, deux classes sont créées dans le paquet, avec le même nom qu'une classe BPL complète :

• La classe Thread1 contient les méthodes S1, S2, .... SN, qui correspondent à des activités au sein de BPL
• La classe Context contient toutes les variables de contexte ainsi que le prochain état que BPL exécutera (c'est-à-dire S5).

La classe BPL est également persistante et stocke les demandes en cours de traitement.

BPL fonctionne en exécutant des méthodes S dans une classe Thread et en mettant à jour la table de la classe BPL, la table Context et la table Thread1, où un message "en cours de traitement" est une ligne dans un tableau BPL. Une fois la requête traitée, BPL supprime les entrées BPL, Context et Thread. Puisque les BPL BP sont asynchrones, une tâche BPL peut traiter simultanément de nombreuses requêtes en sauvegardant des informations entre les appels S et en passant d'une requête à l'autre. Par exemple, BPL traite une requête jusqu'à ce qu'il arrive à une activité sync - en attendant une réponse de BO. Il sauvegarde le contexte actuel sur le disque, avec la propriété %NextState (dans la classe Thread1) fixée à la méthode S de l'activité de réponse, et travaille sur d'autres requêtes jusqu'à ce que BO réponde. Après la réponse de BO, BPL charge le contexte en mémoire et exécute la méthode correspondant à un état sauvegardé dans la propriété %NextState.

Maintenant, que se passe-t-il lorsque nous mettons à jour le BPL ? Tout d'abord, nous devons vérifier qu'au moins une des deux conditions est remplie :

• Pendant la mise à jour, le tableau Contexte est vide, ce qui signifie qu'aucun message actif n'est en cours de traitement.
• Les nouveaux états (New States) sont les mêmes que les anciens (Old States), ou de nouveaux états sont ajoutés à la suite des anciens .

Si au moins une condition est remplie, nous sommes prêts à démarrer. Soit il n'y a pas de demandes de pré-mise à jour à traiter par BPL après la mise à jour, soit les états sont ajoutés à la fin, ce qui signifie que les anciennes demandes peuvent également être traitées (en supposant que les demandes de pré-mise à jour sont compatibles avec les activités et le traitement de BPL après la mise à jour).

Mais que se passe-t-il si vous avez des demandes actives en cours de traitement et que BPL change l'ordre des états ? Idéalement, si vous pouvez attendre, désactivez les appelants BPL et attendez que la file d'attente soit vide. Vérifiez que le tableau Contexte est également vide. N'oubliez pas que la file d'attente n'affiche que les demandes non traitées, et que le tableau Contexte stocke les demandes en cours de traitement, de sorte qu'il peut arriver qu'un BPL très occupé affiche une file d'attente nulle, et c'est normal. Ensuite, désactivez le BPL, effectuez la mise à jour et activez tous les Business Hosts précédemment désactivés.

Si ce n'est pas possible (généralement dans le cas où le BPL est très long, par exemple, je me souviens avoir mis à jour un BPL qui prenait environ une semaine pour traiter une demande, ou si la fenêtre de mise à jour est trop courte), utilisez l'outil BPL versioning.

Vous pouvez également écrire un script de mise à jour. Dans ce script de mise à jour, associez les anciens next states aux nouveaux next states et exécutez-le sur le tableau Thread1 afin que le BPL mis à jour puisse traiter les anciennes requêtes. BPL, bien sûr, doit être désactivé pendant la durée de la mise à jour. Ceci dit, il s'agit d'une situation extrêmement rare, et généralement, vous n'avez pas besoin de faire cela, mais si jamais vous devez le faire, voici comment procéder.

Conclusion

L'interopérabilité met en œuvre un algorithme sophistiqué pour minimiser le nombre d'actions nécessaires pour actualiser la production après la modification du code sous-jacent. Appelez UpdateProduction avec un délai d'attente sûr à chaque mise à jour de SDS. Pour chaque mise à jour de code, vous devez décider d'une stratégie de mise à jour.

La réduction de la quantité de code compilé à l'aide de git diffs permet de réduire le temps de compilation, mais la "mise à jour" du code en lui-même et sa recompilation ou la "mise à jour" des paramètres avec les mêmes valeurs ne déclenchent pas ou ne requièrent pas de mise à jour de la production.

La mise à jour et la compilation des règles de gestion "Business Rule", des règles de routage "Routing Rules" et des DTL les rendent immédiatement accessibles sans mise à jour de la production.

Enfin, la mise à jour de la production est une opération sûre qui ne nécessite généralement pas de temps d'arrêt.

Liens

• Ens.Director
• Construction de git diffs
• Paramètres par défaut du système

L'auteur tient à remercier @James MacKeith, @Dmitry Zasypkin et @Regilo Regilio Guedes de Souza pour leur aide précieuse dans la rédaction de cet article.

Dans cette série d'articles, j'aimerais présenter et discuter de plusieurs approches possibles pour le développement de logiciels avec les technologies d'InterSystems et GitLab. J'aborderai des sujets tels que:

• Git 101
• Flux Git (processus de développement)
• Installation de GitLab
• Flux de travail GitLab
• Diffusion continue
• Installation et configuration de GitLab
• GitLab CI/CD
• Pourquoi des conteneurs?
• Infrastructure de conteneurs
• CD utilisant des conteneurs

Dans le premier article, nous avons évoqué les notions de base de Git, les raisons pour lesquelles une compréhension approfondie des concepts de Git est importante pour le développement de logiciels modernes et la manière dont Git peut être utilisé pour développer des logiciels.

Dans le deuxième article, nous avons évoqué le flux de travail GitLab - un processus complet du cycle de vie du logiciel ainsi que Diffusion continue.

Dans le troisième article, nous avons évoqué l'installation et la configuration de GitLab et la connexion de vos environnements à GitLab

Dans le quatrième article, nous avons écrit une configuration de CD.

Dans le cinquième article, nous avons parlé des conteneurs et de la manière dont ils peuvent être utilisés (et pour quelles raisons).

Dans le sixème article nous abordons des principaux composants dont vous aurez besoin pour exécuter un pipeline de diffusion continue avec des conteneurs et de la façon dont ils fonctionnent tous ensemble.

Dans cet article, nous allons créer une configuration de diffusion continue décrite dans les articles précédents.

Dans cette série d'articles, j'aimerais présenter et discuter de plusieurs approches possibles pour le développement de logiciels avec les technologies d'InterSystems et GitLab. J'aborderai des sujets tels que:

• Git 101
• Flux Git (processus de développement)
• Installation de GitLab
• Flux de travail GitLab
• Diffusion continue
• Installation et configuration de GitLab
• GitLab CI/CD

Dans cette série d'articles, j'aimerais présenter et discuter de plusieurs approches possibles pour le développement de logiciels avec les technologies d'InterSystems et GitLab. J'aborderai des sujets tels que:

• Git 101
• Flux Git (processus de développement)
• Installation de GitLab
• Flux de travail GitLab
• Diffusion continue
• Installation et configuration de GitLab
• GitLab CI/CD

Dans le premier article, nous avons évoqué les notions de base de Git, les raisons pour lesquelles une compréhension approfondie des concepts de Git est importante pour le développement de logiciels modernes et la manière dont Git peut être utilisé pour développer des logiciels.

Dans le deuxième article, nous avons évoqué le flux de travail GitLab - un processus complet du cycle de vie du logiciel ainsi que Diffusion continue.

Dans cet article, nous allons examiner:

• Installation et configuration de GitLab
• Connexion de vos environnements à GitLab

Dans cette série d'articles, j'aimerais présenter et discuter de plusieurs approches possibles pour le développement de logiciels avec les technologies d'InterSystems et GitLab. J'aborderai des sujets tels que:

• Git 101
• Le flux Git (processus de développement)
• Installation de GitLab
• Flux de travail GitLab
• Diffusion continue
• Installation et configuration de GitLab
• GitLab CI/CD

Dans l'article précédent, nous avons évoqué les notions de base de Git, les raisons pour lesquelles une compréhension approfondie des concepts de Git est importante pour le développement de logiciels modernes et la manière dont Git peut être utilisé pour développer des logiciels. Et bien que nous nous soyons concentrés sur la partie mise en œuvre du développement de logiciels, cette partie présente :

• Le flux de travail GitLab est un processus complet du cycle de vie d'un logiciel, allant de l'idée au retour utilisateur
• Diffusion continue est une approche d'ingénierie logicielle dans laquelle les équipes produisent des logiciels en cycles courts, garantissant que le logiciel peut être diffusé de manière fiable à tout moment. Elle vise à créer, tester et publier des logiciels plus rapidement et plus fréquemment.

Tout le monde dispose d'un environnement de test.

Certains ont la chance de disposer d'un environnement totalement séparé pour la production.

-- Inconnu

.

Dans cette série d'articles, j'aimerais présenter et discuter de plusieurs approches possibles pour le développement de logiciels avec les technologies d'InterSystems et GitLab. J'aborderai des sujets tels que:

• Git 101
• Git flow (processus de développement)
• Installation de GitLab
• Flux de travail GitLab WorkFlow
• GitLab CI/CD
• CI/CD avec des conteneurs

Cette première partie traite de la pierre angulaire du développement logiciel moderne - le système de contrôle de version Git et divers flux Git.

Bonjour à la communauté,
Dans cet article, je vais présenter mon application iris-mlm-explainer

Cette application web se connecte au service SQL d'InterSystems Cloud pour créer, entraîner, valider et prédire des modèles d'apprentissage automatique, faire des Prédictions et afficher un tableau de bord de tous les modèles entraînés avec une explication du fonctionnement d'un modèle d'apprentissage automatique ajusté. Le tableau de bord fournit des graphiques interactifs sur les performances du modèle, les importances des caractéristiques, les contributions des caractéristiques aux prédictions individuelles, les graphiques de dépendance partielle, les valeurs SHAP (interaction), la visualisation des arbres de décision individuels, etc.

Conditions préalables

• Vous devez avoir un compte à SQL d'InterSystems Cloud
• Vous devez avoir <a book="" fr="" getting-started-installing-git="" git-scm.com="" https:="" v2="">Git</a> installé localement.
• Vous devez avoir <a downloads="" https:="" www.python.org="">Python3</a> installé localement.  

Démarrage

Nous allons suivre les étapes suivantes pour créer et afficher le tableau de bord explicatif d'un modèle :

• Etape 1 : Fermeture/git pull du référentiel

• Étape 2 : Connexion au portail de service SQL d'InterSystems Cloud

  • Étape 2.1 : Ajout et gestion de fichiers
  • Étape 2.2 : Importation des fichiers DDL et des fichiers de données
  • Étape 2.3 : Création du modèle
  • Étape 2.4 : Entraînement du modèle
  • Étape 2.5 : Validation du modèle
  • Étape 3 : Activation de l'environnement virtuel Python

• Étape 4 : Exécution de l'application Web pour la prédiction

• Étape 5 : Exploration du tableau de bord explicatif

Etape 1 : Fermeture/git Extraction du référentiel

Commençons donc par la première étape

Créer un dossier et Cloner/utiliser le git pull pour le référentiel dans n'importe quel répertoire local.

git clone https://github.com/mwaseem75/iris-mlm-explainer.git

Étape 2 : Connexion au portail de service SQL d'InterSystems Cloud

Connectez-vous au portail InterSystems Cloud Service Portal

Sélectionner le déploiement en cours

Étape 2.1 : Ajout et gestion des fichiers

Cliquez sur Ajout et gestion de fichiers (Add and Manage Files)

Le référentiel contient les fichiers USA_Housing_tables_DDL.sql(DDL pour créer les tables), USA_Housing_train.csv(données d'entraînement), et USA_Housing_validate.csv(pour la validation) dans le dossier datasets. Sélectionnez le bouton de téléchargement pour ajouter ces fichiers.

Étape 2.2 : Importation des fichiers DDL et des fichiers de données

Cliquez sur Importation de fichiers, puis sur le bouton radio Instruction(s) DDL ou DML, puis sur le bouton suivant.

Cliquez sur le bouton radio Intersystems IRIS et cliquez ensuite sur le bouton suivant

Sélectionnez le fichier USA_Housing_tables_DDL.sql et appuyez sur le bouton d'importation de fichiers.

Cliquez sur le bouton d'importation "Import" dans la boîte de dialogue de confirmation pour créer le tableau.

###

Cliquez sur le bouton des outils de requête SQL (SQL Query tools) pour vérifier que les tableaux sont créés.

###

Importez des fichiers de données

Cliquez sur Importation de fichiers (Import files), puis sur le bouton radio Données CSV (CSV data), et enfin sur le bouton suivant.

Selectionnez le fichier USA_Housing_train.csv et cliquez sur le bouton suivant

###

Sélectionnez le fichier USA_Housing_train.csv dans la liste déroulante, cochez les cases d'importation de lignes en tant que ligne d'en-tête et de noms de champs dans la ligne d'en-tête correspondant aux noms de colonnes dans le tableau sélectionné, puis cliquez sur Importation de fichiers.

cliquer sur "importation" dans la boîte de dialogue de confirmation

Assurez-vous que 4000 lignes sont mises à jour

Procédez de la même manière pour importer le fichier USA_Housing_validate.csv qui contient 1500 enregistrements.

Étape 2.3 : Création du modèle

Cliquez sur les outils IntegratedM et sélectionnez Créer un panneau (Create Panel).

Saisissez USAHousingPriceModel dans le champ de nom du modèle (Model Name), sélectionnez le tableau usa_housing_train et Prix dans la liste déroulante des champs à prédire (Field to predict). Cliquez sur le bouton "Création du modèle" pour créer le modèle.

Étape 2.4 : Entraînement du modèle

sélectionnez le panneau d'entraînement (Train Panel), sélectionnez USAHousingPriceModel dans la liste déroulante du modèle à entraîner et saisissez USAHousingPriceModel_t1 dans le champ du nom du modèle d'entraînement (Train Model Name)

###

Le modèle sera entraîné une fois l'état de fonctionnement (Run Status) achevé

###

Étape 2.5 : Validation du modèle

Sélectionnez le panneau de validation (Validate Panel), sélectionnez USAHousingPriceModel_t1 dans le modèle entraîné pour valider la liste déroulante, sélectionnez usa_houseing_validate dans le tableau pour valider le modèle à partir de la liste déroulante et cliquez sur le bouton de validation du modèle.

###

Cliquez sur affichage des mesures de validation pour visualiser les mesures.

Cliquez sur l'icône graphique pour afficher le graphique Prédiction VS Réalité.

Étape 3 : Activation de l'environnement virtuel Python

Le référentiel contient déjà un dossier d'environnement virtuel python (venv) avec toutes les bibliothèques nécessaires.

Il suffit d'activer l'environnement
Pour Unix ou MacOS :

<span class="hljs-meta">$</span><span class="bash"> <span class="hljs-built_in">source</span> venv/bin/activate</span>

Pour Windows:

venv\scripts\activate

Étape 4 : Définir les paramètres de connexion à InterSystems SQL Cloud

Le référentiel contient le fichier config.py. Il suffit de l'ouvrir et de le paramétrer

Mettez les mêmes valeurs que celles utilisées dans InterSystems SQL Cloud

Étape 4 : Exécution de l'application Web pour la prédiction

Exécutez la commande suivante dans l'environnement virtuel pour démarrer notre application principale

python app.py

###

Pour démarrer l'application, naviguez jusqu'à http://127.0.0.1:5000/

Entrez l'âge de la maison, le nombre de pièces, le nombre de chambres et la population de la région pour obtenir la prédiction

Étape 5 : Exploration du tableau de bord explicatif

Enfin, exécutez la commande suivante dans l'environnement virtuel pour démarrer notre application principale

python expdash.py

Pour démarrer l'application, naviguez jusqu'à http://localhost:8050/

L'application répertorie tous les modèles entraînés ainsi que notre modèle USAHousingPriceModel. Cliquez sur "aller au panneau de bord" ("go to dashboard") pour voir l'explication du modèle.

Importance des fonctionnalités. Quelles sont les fonctionnalités ayant eu l'impact le plus important ?

Mesures quantitatives de la performance des modèles : dans quelle mesure la valeur prédite est-elle proche de la valeur observée ?

Prédiction et Comment chaque fonctionnalité a-t-elle contribué à la prédiction ?

Ajustez les valeurs des fonctionnalités pour modifier la prédiction

Sommaire des SHAPs, Classement des caractéristiques par valeurs de SHAPs

Sommaire des interactions, classement des fonctionnalités par valeur d'interaction de SHAP

Arbres de décision, affichage des arbres de décision individuels dans la forêt aléatoire

Merci

Il s'agit d'un modèle de base pour un environnement de développement permettant de travailler avec ObjectScript dans InterSystems IRIS. Il vous aide à éditer, compiler, commettre/pousser, déboguer et tester votre code ObjectScript. Il aide également à conditionner votre application en tant que module installable avec IPM. Le modèle est compatible avec Embedded Python.

Description

Ce référentiel fournit un environnement de développement prêt à l'emploi pour coder de manière productive avec ObjectScript d'InterSystems. Ce modèle: