Deploy Syntho using Helm

Pour déployer l'application Syntho, nous utiliserons la carte Helm dans le même référentiel que mentioned before. Le tableau se trouve dans les communiqués de presse de la Commission européenne. deployment-tools ou il peut être cloné directement à partir du repo Github, ce qui rendra le chemin vers le graphique helm/syntho-ui

Pour configurer l'interface utilisateur, les values.yaml dans le fichier helm/syntho-ui peuvent être utilisés. Les sections suivantes décrivent les différents champs qui peuvent être définis.

Configuration de l'interface utilisateur

Pour l'interface utilisateur, nous devons d'abord définir le référentiel d'images et le tag:

image:
  dépôt: synthoregistry.azurecr.io/syntho-core-frontend
  tag: le plus récent

Nous devrons également définir le nom de domaine de l'interface utilisateur.

frontend_url: <hostname-or-ip>
frontend_protocol: https # http ou https en fonction de la disponibilité d'un certificat SSL

Une entrée est nécessaire pour l'interface utilisateur et fait partie de la carte Helm., nous pouvons définir la configuration de l'entrée comme suit pour l'interface utilisateur:

entrée:
    activée: vrai
    nom: frontend-ingress
    nom de la classe: nginx # Définir le nom de classe du contrôleur d'entrée que vous utilisez
    annotations: {
      cert-manager.io/cluster-issuer: "", # Dans le cas où cert-manager est utilisé pour SSL
      nginx.ingress.kubernetes.io/proxy-buffer-size: "32k",
      nginx.ingress.kubernetes.io/affinity: "cookie",
      nginx.ingress.kubernetes.io/use-regex: "true" (vrai),
      nginx.ingress.kubernetes.io/proxy-connect-timeout: "600",
      nginx.ingress.kubernetes.io/proxy-read-timeout: "600",
      nginx.ingress.kubernetes.io/proxy-send-timeout: "600",
      nginx.ingress.kubernetes.io/proxy-body-size: "512m",
    }
    hôtes:
      - hôte: <hostname>
        chemins:
          - chemin: /
            type de chemin: Préfixe
    
    tls:  # Dans le cas où SSL n'est pas utilisé, la section tls peut être supprimée
      - hôtes:
        - <hostname>
        NomSecret: frontend-tls # Définir le secret existant ou si l'on utilise cert-manager pour gérer les certificats

Cela créera une définition d'entrée pour l'interface utilisateur et l'application dorsale. Une partie du trafic sera acheminée vers l'application dorsale., afin de pouvoir desservir tout le trafic provenant du même nom de domaine.

Note: dans le cas où le certificat SSL est un certificat auto-signé ou un certificat qui ne peut pas être vérifié dans le conteneur, nous devons définir des variables supplémentaires si l'instance n'est pas en mesure de vérifier le certificat.

Voir le bloc de code suivant:

frontend:
  env:
    _JAVA_OPTIONS: "-Dio.swagger.parser.util.RemoteUrl.trustAll=true -Dio.swagger.v3.parser.util.RemoteUrl.trustAll=true"

Configuration du backend

Le backend est responsable de la gestion des utilisateurs et de l'espace de travail. Nous devons configurer quelques variables correctement. Pour commencer, nous devons définir l'image:

backend:
  image:
    dépôt: synthoregistry.azurecr.io/syntho-core-backend
    tag: le plus récent

Base de données dorsale et Redis dorsale

Nous devons ensuite définir les informations d'identification de la base de données et de Redis. Si les instances définies dans le diagramme Helm sont utilisées, aucune modification n'est nécessaire. Dans le cas contraire, les éléments suivants doivent être modifiés:

backend:
  db:
    hôte: <hostname>
    port: <port>
    utilisateur: <username>
    mot de passe: <password>
    nom: <database>
  redis:
    hôte: redis-svc
    port: 6379
    db: 0

La section Redis peut être définie comme indiqué ci-dessus si l'instance Redis est utilisée à partir de la carte Helm. Le comportement par défaut déploie l'instance Redis définie dans le tableau. Si une instance Redis différente est utilisée, host, port et db pourrait devoir être modifié.

La section relative à la base de données doit être modifiée si une base de données différente est utilisée. Le comportement par défaut consiste à déployer l'instance de base de données définie dans le graphique. Si une base de données différente de celle du graphique Helm est utilisée, l'hôte, port, utilisateur, mot de passe, et le nom de la base de données doivent être modifiés. Pour désactiver l'utilisation et le déploiement de l'instance de base de données définie dans le graphique, les éléments suivants peuvent être définis:

backend:
  activé_base_de_données: faux

Si la base de données est utilisée à partir de la carte Helm, la valeur host peut être réglé sur database et port à 5432. Les autres valeurs peuvent être modifiées au cas où un nom d'utilisateur différent serait utilisé., mot de passe, ou le nom de la base de données est préférable. Cela ajustera automatiquement l'instance de la base de données définie dans le diagramme Helm.

Backend Ingress

L'entrée du backend est mise en œuvre dans le cadre de l'entrée définie pour l'interface utilisateur. Nous utilisons le routage basé sur le chemin dans l'entrée afin d'acheminer une partie du trafic vers le backend (en particulier tout ce qui va à /api/* ). Aucune entrée supplémentaire n'est nécessaire pour le backend.

Admin user credentials

Il est également nécessaire de définir les informations d'identification du premier utilisateur administratif. Nous pouvons définir cet utilisateur de la manière suivante:

backend:
  utilisateur:
    nom d'utilisateur: administrateur
    mot de passe: mot de passe
    courriel: [e-mail]

Cet utilisateur peut être utilisé pour se connecter à l'interface utilisateur et créer d'autres utilisateurs.

Clé secrète

Enfin, nous devons définir une variable supplémentaire, tel que défini dans le bloc ci-dessous:

clé_secrète: (^ky&f)l&$3sqf2tctv-(pgzvh!+9$j%b5xe2y@&%p2ay*h$$a # Chaîne aléatoire à utiliser comme clé secrète

Configuration de l'API de base

Pour configurer l'API de base, nous devons d'abord définir l'image correcte. Pour définir l'image, nous utiliserons la fonction image dans le champ core section.

image:
  dépôt: synthoregistry.azurecr.io/syntho-core-api
  tag: le plus récent

En outre, les, nous devons définir le nom d'hôte de la base de données et les informations d'identification:

noyau:
  db:
    nom d'utilisateur: <database-username>
    mot de passe: <database-password>
    nom: <database-name>
    hôte: <database-host>
    port: <database-port>

Le déploiement peut éventuellement créer lui-même l'instance de la base de données. Dans ce cas, les database_enabled doit être fixé à true:

noyau:
  activé_base_de_données: vrai

Ceci créera une base de données avec le nom d'utilisateur spécifié, mot de passe, et le nom de la base de données. L'hôte de cette base de données est backend et le port sera 5432 car il s'agit d'une base de données Postgres.

Enfin, les, nous devons définir une clé secrète à des fins de cryptage, les informations d'identification d'une instance Redis et l'IP ou le nom d'hôte de la tête de rayon à laquelle se connecter. Le nom d'hôte de la tête de lecture est celui mentionné dans la section Deploy Ray using Helm.

clé_secrète: UNIbrRR0CnhPEB0BXKQSDASaNzT1IYgQWWaLyQ1W1iPg= # Fernet Key: générer en exécutant python -c "from cryptography.fernet import Fernet ; print(Fernet.generate_key().decode())"
redis:
    hôte: redis-svc
    port: 6379
    db: 1
adresse_du_rayon: <ray-head-ip-or-hostname>

La clé fernet peut être générée à l'aide de la commande cryptography en Python. En exécutant la commande suivante, vous obtiendrez une clé fernet générée aléatoirement dans votre CLI:

python -c "from cryptography.fernet import Fernet ; print(Fernet.generate_key().decode())"

L'instance Redis peut être définie en ajustant le paramètre redis: section. Les valeurs par défaut le dirigeront vers l'instance Redis déployée dans le cadre du diagramme Helm.

Déployer

Pour déployer l'application Syntho, nous utiliserons le tableau Helm fourni par l'équipe Syntho. Ce tableau se trouve dans la section helm/syntho dossier.

helm install syntho-ui ./helm/syntho-ui --values values values.yaml --namespace syntho