Écrit par

Guillaume Rongier

Sales Engineer at InterSystems

STAFF

Article Guillaume Rongier · Sept 18, 2023 22m read

Open Exchange

Déploiement local d'un serveur FHIR sur K8s

#InterSystems IRIS for Health #FHIR

k8s

Voici un exemple de déploiement de iris-oauth-fhir sur k3d avec IKO.

iris-oauth-fhir est un exemple de déploiement d'un serveur FHIR avec authentification OAuth2 en utilisant InterSystems IRIS for Health comme serveur de ressources et Google OpenId comme serveur d'autorisation.
k3d est un wrapper léger pour exécuter k3s (la distribution Kubernetes minimale de Rancher Lab) dans docker.
IKO est un outil permettant de déployer InterSystems IRIS for Health sur Kubernetes.

2. Table des matières

1. K3D + iris-operator + iris-oauth-fhir
2. Table des matières

2.1. Les conditions préalables

2.2. Installation

2.2.1. Avertissement

Ce sera un long parcours, mais il en vaudra la peine. Vous apprendrez beaucoup de choses sur Kubernetes et InterSystems IRIS for Health.

2.2.2. Création de l'image iris-oauth-fhir

Commencez par cloner le dépôt :

git clone https://github.com/grongierisc/iris-oauth-fhir

Et construisez l'image iris-oauth-fhir comme il est expliqué dans README.md

Ensuite, nous installerons k3d.

2.2.3. Téléchargement de k3d

curl -s https://raw.githubusercontent.com/rancher/k3d/main/install.sh | bash

2.2.4. Création d'un registre

Il est nécessaire de créer un registre car pour l'instant Docker Desktop ne sert pas son registre interne comme un registre containerd. Une fonctionnalité expérimentale est disponible pour exploiter le registre de Docker Desktop en tant que registre containerd, mais elle n'est pas encore stable. Donc nous allons utiliser k3d pour créer un registre.

k3d registry create registry.localhost --port 5000

Cette commande permettra de créer un registre sur le port 5000. Nous l'utiliserons pour envoyer nos images. C'est la seule façon d'utiliser nos images avec k3d.

Maintenant, nous ajouterons le registre à notre fichier d'hôtes. Ainsi, nous pourrons l'utiliser comme un nom DNS. C'est important car nous l'utiliserons dans notre déploiement. Ce nom DNS sera le même pour notre hôte et pour Kubernetes.

2.2.4.1. ajout d'un registre aux hôtes

2.2.4.1.1. mac

sudo sh -c 'echo "127.0.0.1 k3d-registry.localhost" >> /etc/hosts'

2.2.4.1.2. windows

Ouvrez le Notepad en tant qu'administrateur.
Ouvrez le fichier C:\Windows\System32\Drivers\etc\hosts.
Ajoutez la ligne suivante à la fin du fichier : 127.0.0.1 k3d-registry.localhost.
Sauvegardez le fichier et fermez le Notepad.

2.3. Lancement du culster

Nous lancerons maintenant le cluster à l'aide de la ligne de commande suivante :

k3d cluster create demo --servers 1 --agents 2 --volume $(pwd)/k8s/data:/var/lib/rancher/k3s/storage@all --registry-use k3d-registry.localhost:5000 -p "8081:80@loadbalancer" -p "4443:443@loadbalancer" --api-port 6550 --volume "$(pwd)/k8s/config/traefik-config.yaml:/var/lib/rancher/k3s/server/manifests/traefik-config.yaml"

Les options possibles sont :

--servers 1 créera un noeud serveur, les noeuds serveurs sont les noeuds maîtres.
-agents 2 créera deux noeuds agents, les noeuds agents sont les noeuds de travail.
--volume $(pwd)/k8s/data:/var/lib/rancher/k3s/storage@all montera le dossier k8s/data sur le cluster. C'est là que nous stockerons nos données.
--registry-use k3d-registry.localhost:5000 utilisera le registre que nous avons créé précédemment.
-p "8081:80@loadbalancer" -p "4443:443@loadbalancer" exposera les ports 8081 et 4443 à l'hôte. C'est là que nous accéderons à notre cluster.
--api-port 6550 exposera le port 6550 à l'hôte. C'est là que nous accéderons à l'API Kubernetes.
--volume "$(pwd)/k8s/config/traefik-config.yaml:/var/lib/rancher/k3s/server/manifests/traefik-config.yaml" montera le fichier k8s/config/traefik-config.yaml sur le cluster. Il s'agit du fichier de configuration du contrôleur ingress. Il configure le contrôleur ingress pour permettre à traefik de router les données sur le port sécurisé sans vérification du certificat.

# k8s/config/traefik-config.yaml
apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: traefik
  namespace: kube-system
spec:
  valuesContent: |-
    globalArguments:
    - "--serversTransport.insecureSkipVerify=true"

2.3.1. Vérification du cluster

Voici un diagramme pour vous donner une idée de la forme d'un cluster Kubernetes :

k8s

kubectl get nodes

Vous obtenez alors quelque chose comme ça :

NOM                       STATUT   RÔLES                  ÂGE   VERSION
k3d-demo-server-0          Prêt    plan de commande,maître   10m   v1.21.2+k3s1
k3d-demo-agent-0           Prêt    <nul>                 10m   v1.21.2+k3s1
k3d-demo-agent-1           Prêt    <nul>                 10m   v1.21.2+k3s1

Cela signifie que le cluster est prêt. Vous avez maintenant un cluster Kubernetes avec un nœud maître et deux nœuds de travail. 🥳

2.3.2. Installation d'iris-operator

Nous installerons maintenant iris-operator. iris-operator est un opérateur Kubernetes qui permet de déployer InterSystems IRIS for Health sur Kubernetes. Il est disponible sur le WRC ou sur le registre InterSystems Container Registry. Nous utiliserons la version 3.6.6.100.

Par exemple, si vous disposez d'IKO pour le registre de conteneurs, vous pouvez utiliser la ligne de commande suivante :

docker pull containers.intersystems.com/intersystems/iris-operator-amd:3.6.6.100

Nous marquerons maintenant l'image pour l'envoyer dans notre registre :

docker tag intersystems/iris-operator-amd:3.6.6.100 k3d-registry.localhost:5000/intersystems/iris-operator-amd:3.6.6.100

Et nous l'enverrons :

docker push k3d-registry.localhost:5000/intersystems/iris-operator-amd:3.6.6.100

Pour installer l'opérateur Iko, nous devons utiliser helm. Helm est un gestionnaire de paquets pour Kubernetes. Il est disponible [ici] (https://helm.sh/).

2.3.2.1. installation de helm

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh

2.3.2.2. installation d'iris-operator

helm install intersystems k8s/iris_operator_amd-3.6.6.100/chart/iris-operator

Pour vérifier si l'opérateur fonctionne, vous pouvez utiliser la ligne de commande suivante :

kubectl --namespace=default get deployments -l "release=intersystems, app=iris-operator-amd"

Vous verrez alors quelque chose comme ça :

NOM                        PRÊT   MISE À JOUR   DISPONIBLE   ÂGE
intersystems-iris-operator  1/1     1            1           2m

2.3.3. Installation d'iriscluster

2.3.3.1. Que va-t-on déployer ?

L'architecture suivante sera déployée :

Un nœud de données
Un nœud de passerelle web

C'est exactement ce que nous avons dans le fichier docker-compose suivant :

# docker-compose.yaml
version: '3.6'
services:
  iris:
    image: iris-oauth-fhir-iris:latest
    build:
      context: .
      dockerfile: Dockerfile
    restart: always
    ports:
      - 1972
      - 8083:52773
      - 53773
    volumes:
      - ./:/irisdev/app/
      - ./data:/data
    environment:
      - ISC_CPF_MERGE_FILE=/irisdev/app/common.cpf
      - ISC_OAUTH_SECRET_PATH=/irisdev/app/misc/auth/secret.json
      - ISC_DATA_DIRECTORY=/data/iris

  webgateway:
    build:
      context: ./webgateway
      args:
        link: 'iris'
        port: '52773'
    image: proxyiris:latest
    ports:
    - "8080:80"
    - "4443:443"
    volumes:
    - ./webgateway/CSP.ini:/opt/webgateway/bin/CSP.ini
    - ./webgateway/httpd-csp.conf:/usr/local/apache2/conf/extra/httpd-csp.conf

Quelques remarques :

Nous utilisons l'image iris-oauth-fhir-iris:latest pour le noeud de données.
- Cette image utilise trois variables d'environnement :
  - ISC_CPF_MERGE_FILE pour fusionner le fichier common.cpf.
  - ISC_OAUTH_SECRET_PATH pour définir le chemin vers le fichier secret.
  - ISC_DATA_DIRECTORY pour définir le répertoire de données.
Nous utilisons l'image proxyiris:latest pour le noeud de passerelle web.
- Cette image utilise deux volumes : * CSP.ini pour configurer l'application CSP. * httpd-csp.conf pour configurer le serveur Apache.

Ainsi, nous devrons faire la même chose dans notre déploiement Kubernetes.

C'est à dire que nous devrons :

Pour le nœud de données :
- Fournir le fichier common.cpf au nœud de données.
- Pareil pour le fichier secret.json pour configurer l'authentification OAuth2.
- Le répertoire de données sera monté comme un volume.
Pour le nœud de passerelle web :
- Fournir le fichier CSP.ini au noeud de passerelle web.
- Même chose pour le fichier httpd-csp.conf pour configurer le serveur Apache.

2.3.3.2. Préparation du déploiement du nœud de données

Pour fournir le fichier common.cpf au nœud de données, nous allons utiliser une configuration de carte (config map). Celle-ci est un objet Kubernetes qui permet de stocker des fichiers de configuration. Nous utiliserons le fichier common.cpf que nous avons dans ce référentiel.

Voici une représentation schématique pour une config map :

configmap

Nous utiliserons la ligne de commande suivante pour créer une config map :

kubectl create cm iriscluster-config --from-file common.cpf

Nous utiliserons un secret afin de fournir le fichier secret.json au nœud de données. Un secret est un objet Kubernetes permettant de stocker des données sensibles. Nous utiliserons le fichier secret.json présent dans ce référentiel.

Nous utiliserons la ligne de commande suivante pour créer un secret :

kubectl create secret generic iriscluster-secret --from-file misc/auth/secret.json

Le montage du répertoire de données en tant que volume est automatique. Nous utiliserons le champ storage dans la section topology de la définition d'IrisCluster comme valeur par défaut.

Nous devons encore envoyer l'image iris-oauth-fhir-iris:latest dans notre registre. Nous utiliserons la même ligne de commande que précédemment :

docker tag iris-oauth-fhir-iris:latest k3d-registry.localhost:5000/iris-oauth-fhir-iris:latest

docker push k3d-registry.localhost:5000/iris-oauth-fhir-iris:latest

2.3.3.3. Préparation du déploiement du nœud de la passerelle web

Le nœud de la passerelle web est un peu différent car nous n'utiliserons pas l'image proxyiris:latest. Nous utiliserons l'image intersystems/webgateway:2023.1.1.380.0-linux-amd64. Cette image est disponible sur le registre de conteneurs InterSystems Container Registry. Cette image est l'image raw (brute) de la passerelle web.

Quelle est la différence entre l'image raw de la passerelle web et l'image proxyiris ?

le proxyiris dispose de https préconfiguré avec un certificat auto-signé.

Nous devons donc configurer la passerelle web de manière à ce qu'elle utilise https. Pour cela, nous allons utiliser un secret. Un secret est un objet Kubernetes qui permet le stockage de données sensibles. Nous utiliserons les fichiers tls.crt et tls.key présents dans ce référentiel.

Nous utiliserons la ligne de commande suivante pour créer le secret :

kubectl create secret tls tls-secret --key k8s/tls/tls.key --cert k8s/tls/tls.crt

La bonne nouvelle est que nous ne devrons pas configurer l'application CSP et le serveur Apache. Nous utiliserons les champs applicationPaths et alternativeServers dans la section topology de la définition d'IrisCluster et les utiliserons par défaut.

Dans le fichier docker-compose.yaml nous avons dû configurer le fichier CSP.ini et le fichier httpd-csp.conf. Nous ne devrons pas le faire dans le déploiement Kubernetes car l'adresse IP du nœud de données n'est pas connue d'avance. Mais nous devons quand même indiquer à IKO quels seront le login et le mot de passe pour se connecter au nœud de données. À cette fin, nous utiliserons un secret. Un secret est un objet Kubernetes qui permet le stockage de données sensibles. Nous utiliserons le fichier iris-webgateway-secret que nous avons dans ce dépôt.

Nous utiliserons la ligne de commande suivante pour créer le secret :

kubectl create secret generic iris-webgateway-secret --from-literal='username=CSPSystem' --from-literal='password=]]]U1lT'

Nous avons encore besoin d'envoyer l'image intersystems/webgateway:2023.1.1.380.0-linux-amd64 dans notre registre. Nous utiliserons la même ligne de commande que précédemment :

docker tag containers.intersystems.com/intersystems/webgateway:2023.1.1.380.0-linux-amd64 k3d-registry.localhost:5000/intersystems/webgateway:2023.1.1.380.0-linux-amd64

docker push k3d-registry.localhost:5000/intersystems/webgateway:2023.1.1.380.0-linux-amd64

2.3.4. Déploiement d'iriscluster

Nous installerons maintenant IrisCluster. IrisCluster est une ressource personnalisée de Kubernetes pour déployer InterSystems IRIS for Health sur Kubernetes. Elle est définie dans le fichier k8s/config/iris-sample.yaml.

# k8s/config/iris-sample.yaml
## champs décommentés déploient un serveur de données InterSystems IRIS

## AVERTISSEMENT : le mot de passe par défaut n'est pas réinitialisé, pour le réinitialiser, il faut inclure
## configSource ci-dessous

## inclure des champs commentés aux fins décrites ; voir la documentation à l'adresse suivante
## https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=AIKO_clusterdef_sample

## mettre à jour les balises des images (à partir de ":tag") avant de les utiliser ; voir la liste des images disponibles à l'adresse suivante
## https://docs.intersystems.com/components/csp/docbook/Doc.View.cls?KEY=PAGE_containerregistry

apiVersion: intersystems.com/v1alpha1
kind: IrisCluster
metadata:
  name: sample
spec:

## fournir la clé de licence d'InterSystems IRIS si nécessaire
#     licenseKeySecret:
#       name: iris-key-secret

## spécifier les fichiers utilisés pour personnaliser les configurations  
## des nœuds InterSystems IRIS, y compris le paramètre passwordHash
## pour configurer le mot de passe par défaut, sécurisant ainsi les nœuds InterSystems IRIS
  configSource:
    name: iriscluster-config

## fournir les identifiants du référentiel si nécessaire pour extraire les images
#     imagePullSecrets:
#       - name: iris-pull-secret

## fournir des spécifications VolumeSource pour les certificats pour chaque fonctionnalité TLS requise
## "common" permet d'activer toutes les fonctionnalités TLS, mais la propriété de chaque fonctionnalité particulière est prioritaire sur "common"
  tls:
#       common:
#         secret:
#           secretName: tls-certs
#       mirror:
#         csi:
#           driver: secrets-store.csi.k8s.io
#           readOnly: true
#           volumeAttributes:
#             secretProviderClass: "my-provider"
    webgateway:
      secret:
        secretName: tls-secret



## spécifier la classe de stockage spécifique à la plate-forme utilisée pour allouer de l'espace de stockage
## volumes (par défaut : utilisation de la classe définie par la plate-forme)
#     storageClassName: iris-ssd-storageclass

## sélectionner la stratégie de mise à jour (par défaut : RollingUpdate)
#     updateStrategy:
#       type: RollingUpdate

## créer des adresses IP externes pour le cluster
## ("type: LoadBalancer" et "externalTrafficPolicy: Local" sont nécessaire)
#     serviceTemplate:
#       spec:
#         type: LoadBalancer
#         externalTrafficPolicy: Local

## définir les volumes persistants (à monter par "volumeMounts :" dans les définitions de nœuds)
#  volumeClaimTemplates:
#    - metadata:
#        name: extra-disk
#      spec:
#        accessModes:
#          - ReadWriteOnce
#        resources:
#          requests:
#            storage: 2Gi

## définir des volumes éphémères (à monter par "volumeMounts :" dans les définitions de nœuds)
  volumes:
    - name: auth-config
      secret:
        secretName: iriscluster-secret

## topologie : définit les types de nœuds à déployer ; uniquement "data :" est nécessaire

  topology:
    data:
      image: k3d-registry.localhost:5000/iris-oauth-fhir-iris:latest
      ## établir une variable d'environnement pour le conteneur
      podTemplate:
        spec:
          env:
            - name: ISC_OAUTH_SECRET_PATH
              value: /auth/secret.json


## déployer un cluster de nœuds de données et (éventuellement) de nœuds de calcul;
## s'il n'est pas inclus, la définition "data :" dans "topology :" déploie
## un seul serveur de données, "compute :" ajoute des serveurs d'application
#         shards: 2

## déployer des nœuds de données ou des serveurs de données en miroir (par défaut : sans miroir)
#         mirrored: true

## remplacer la taille par défaut et d'autres attributs des volumes de stockage prédéfinis
## pour les nœuds de données (noms de volumes supplémentaires : storageWIJ,
## storageJournal1, storageJournal2) ; il peut également être inclus
## dans la définition "compute :"
#         storageDB:
#           resources:
#             requests:
#               storage: 10Gi
#           storageClassName: my-storageclass

## contraindre les nœuds à des zones de disponibilité spécifiques à la plate-forme
## (peut être inclus dans d'autres définitions de nœuds)
#         preferredZones:
#           - us-east1-a
#           - us-east1-b

## monter les volumes définis dans "volumeClaimTemplates :" (persistant) et "volumes :" (éphémère)
      volumeMounts:
        - mountPath: "/auth"
          name: auth-config

## déployer les nœuds webgateway (serveur web)
    webgateway:
      image: k3d-registry.localhost:5000/intersystems/webgateway:2023.1.1.380.0-linux-amd64
      type: apache
      replicas: 1
      applicationPaths:
        - /csp/sys
        - /fhir/r4
      alternativeServers: LoadBalancing
      loginSecret:
        name: iris-webgateway-secret

## déployer le Système d'Alerte et de Surveillance (SAM) avec InterSystems IRIS
#      sam:
#        image: containers.intersystems.com/intersystems/sam:tag

## déployer le Gestionnaire d'API d'InterSystems (IAM) avec IRIS d'InterSystems
#      iam:
#        image: containers.intersystems.com/intersystems/iam:tag

Ouah, c'est beaucoup ! Mais ne vous inquiétez pas, nous allons tout vous expliquer.

Commençons donc avec la section configSource :

## spécifier les fichiers utilisés pour personnaliser les configurations
## des nœuds InterSystems IRIS, y compris le paramètre passwordHash
## pour établir le mot de passe par défaut, sécurisant les nœuds InterSystems IRIS
  configSource:
    name: iriscluster-config

C'est la carte de configuration "config map" que nous avons créée précédemment. C'est là que nous trouverons le fichier common.cpf.

Ensuite, nous avons la section tls :

## fournir des spécifications VolumeSource pour les certificats pour chaque fonctionnalité TLS requise
## "common" permet d'activer toutes les fonctionnalités TLS, mais la propriété de chaque fonctionnalité particulière est prioritaire sur "common"
  tls:
    webgateway:
      secret:
        secretName: tls-secret

C'est le secret que nous avons créé précédemment. C'est là que nous trouverons les fichiers tls.crt et tls.key.

Ensuite, nous avons la section volumes :

## définir des volumes éphémères (à monter par "volumeMounts :" dans les définitions de nœuds)
  volumes:
    - name: auth-config
      secret:
        secretName: iriscluster-secret

C'est le secret que nous avons créé précédemment. C'est là que nous trouverons le fichier secret.json.

Un IrisCluster définit comment déployer InterSystems IRIS for Health sur Kubernetes. La partie importante est la section topologie. Cette section définit les nœuds à déployer. Dans cet exemple, nous déploierons un nœud de données et un nœud de passerelle web.

Examinons la définition du nœud de données :

## topologie : définit les types de nœuds à déployer ; uniquement "data :" est nécessaire

  topology:
    data:
      image: k3d-registry.localhost:5000/iris-oauth-fhir-iris:latest
      ## établir une variable d'environnement pour le conteneur
      podTemplate:
        spec:
          env:
            - name: ISC_OAUTH_SECRET_PATH
              value: /auth/secret.json
      volumeMounts:
        - mountPath: "/auth"
          name: auth-config

Le champ image définit l'image à utiliser. Nous utiliserons l'image que nous avons construite précédemment. Le champ podTemplate définit le modèle de pod Kubernetes. Le champ env définit les variables d'environnement à définir dans le conteneur. Nous utiliserons cette variable d'environnement pour définir le chemin vers le fichier secret que nous allons créer. podTemplate c'est en quelque sorte ce que vous pouvez trouver dans un fichier docker-compose.yaml. Le champ volumeMounts définit les volumes à monter dans le conteneur. Nous monterons le secret que nous avons créé précédemment.

Examinons maintenant la définition du nœud de passerelle web :

## déployer les nœuds de passerelle web (webgateway) (serveur web)
    webgateway:
      image: k3d-registry.localhost:5000/intersystems/webgateway:2023.1.1.380.0-linux-amd64
      type: apache
      replicas: 1
      applicationPaths:
        - /csp/sys
        - /fhir/r4
      alternativeServers: LoadBalancing
      loginSecret:
        name: iris-webgateway-secret

Le champ image définit l'image à utiliser. Le champ type définit le type de passerelle web à déployer. Nous utiliserons apache. Le champ replicas définit le nombre de passerelles web à déployer. Nous n'en déploierons qu'une. Le champ applicationPaths définit les chemins d'application à router vers la passerelle web. Nous allons router /csp/sys et /fhir/r4 vers la passerelle web. Le champ alternativeServers définit les serveurs alternatifs à utiliser. Nous utiliserons LoadBalancing. Le champ loginSecret définit le login et le mot de passe pour lier la passerelle au noeud de données.

Nous utiliserons la ligne de commande suivante pour déployer IrisCluster :

kubectl apply -f k8s/config/iris-sample.yaml

Vous pouvez utiliser la ligne de commande suivante pour vérifier si IrisCluster est en cours d'exécution :

kubectl get iriscluster

Quelques minutes plus tard, vous devriez voir apparaître quelque chose comme ceci :

NOM     SEGMENTS   MIROITÉ   STATUT                 ÂGE
échantillon                  En cours d'exécution   2m16s

Vous pouvez utiliser cette ligne de commande afin d'obtenir des détails sur l'IrisCluster :

kubectl describe iriscluster sample

Vous pouvez utiliser la ligne de commande suivante pour vérifier si les pods sont en cours d'exécution :

kubectl get pods

Quelques minutes plus tard, vous devriez voir apparaître quelque chose comme ceci :

NOM                                             PRÊT   STATUT              RESTARTS   ÂGE
intersystems-iris-operator-amd-87c955c9c-4zmrj   1/1   En cours d'exécution   0          44m
sample-data-0                                    1/1   En cours d'exécution   0          4m19s
sample-webgateway-0                              0/1   ContainerCreating      0          17s

Vous pouvez utiliser la ligne de commande suivante pour obtenir des informations détaillées sur les pods :

kubectl describe pod sample-data-0

2.3.5. Déploiement d'Ingress'

ingress

Nous déployons maintenant un ingress. Un ingress est un objet Kubernetes qui permet de router le trafic vers le bon pod. Nous allons utiliser le fichier k8s/config/ingress.yaml.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress
  namespace: default
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: sample-webgateway
            port:
              number: 443

Cet ingress va router le trafic vers le service sample-webgateway sur le port 443.

Vous pouvez utiliser la ligne de commande suivante pour déployer l' ingress :

kubectl apply -f k8s/config/ingress.yaml

Vous pouvez utiliser la ligne de commande suivante pour vérifier si l'ingress est en cours d'exécution :

kubectl get ingress

Vous pouvez utiliser la ligne de commande suivante pour tester l'ensemble:

curl -k https://localhost:4443/fhir/r4/metadata

Félicitations, vous avez déployé iris-oauth-fhir sur Kubernetes. 🥳

2.4. Évolution facile

Si vous voulez créer un nouveau client, vous pouvez utiliser le fichier iris-demo.yaml.

En gros, c'est le même fichier que iris-sample.yaml, mais simplement le nom du client est changé.

Vous pouvez le déployer avec la ligne de commande suivante :

kubectl apply -f k8s/config/iris-demo.yaml

Vous pouvez utiliser un nouveau ingress pour acheminer le trafic vers le nouveau client.

apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: strip-prefix
  namespace: default
spec:
  stripPrefix:
    prefixes:
      - /sample
      - /demo
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress
  namespace: default
  annotations:
    traefik.ingress.kubernetes.io/router.middlewares: default-strip-prefix@kubernetescrd
spec:
  rules:
  - http:
      paths:
      - path: /sample
        pathType: Prefix
        backend:
          service:
            name: sample-webgateway
            port:
              number: 443
      - path: /demo
        pathType: Prefix
        backend:
          service:
            name: demo-webgateway
            port:
              number: 443

Deux nouveaux chemins sont ajoutés :

/sample pour router le trafic vers le service sample-webgateway.
/demo pour router le trafic vers le service demo-webgateway.

Vous pouvez dimensionner le nœud de compte et ainsi de suite, mais pour cela vous aurez besoin d'une clé de licence.

2.5. Initiation rapide

Images à étiquettes

docker tag iris-oauth-fhir-iris:latest k3d-registry.localhost:5000/iris-oauth-fhir-iris:latest
docker tag containers.intersystems.com/intersystems/webgateway:2023.1.1.380.0-linux-amd64 k3d-registry.localhost:5000/intersystems/webgateway:2023.1.1.380.0-linux-amd64
docker tag intersystems/iris-operator-amd:3.6.6.100 k3d-registry.localhost:5000/intersystems/iris-operator-amd:3.6.6.100

Images en mode push

docker push k3d-registry.localhost:5000/iris-oauth-fhir-iris:latest
docker push k3d-registry.localhost:5000/intersystems/webgateway:2023.1.1.380.0-linux-amd64
docker push k3d-registry.localhost:5000/intersystems/iris-operator-amd:3.6.6.100

2.6. Déploiement rapide

Supprimer un cluster:

k3d cluster delete demo

Créer un cluster:

k3d cluster create demo --servers 1 --agents 2 --volume $(pwd)/k8s/data:/var/lib/rancher/k3s/storage@all --registry-use k3d-registry.localhost:5000 -p "8081:80@loadbalancer" -p "4443:443@loadbalancer" --api-port 6550 --volume "$(pwd)/k8s/config/traefik-config.yaml:/var/lib/rancher/k3s/server/manifests/traefik-config.yaml"

Installer iris-operator:

helm install intersystems k8s/iris_operator_amd-3.6.6.100/chart/iris-operator

Créer Config et Secret

kubectl create cm iriscluster-config --from-file common.cpf
kubectl create secret generic iriscluster-secret --from-file misc/auth/secret.json
kubectl create secret tls tls-secret --key k8s/tls/tls.key --cert k8s/tls/tls.crt
kubectl create secret generic iris-webgateway-secret --from-literal='username=CSPSystem' --from-literal='password=]]]U1lT'

Déployer IrisCluster:

kubectl apply -f k8s/config/iris-sample.yaml

Déployer Ingress:

kubectl apply -f k8s/config/ingress.yaml

Discussion (0)0

Connectez-vous ou inscrivez-vous pour continuer

Ajouter une réponse