Development Guides

Comment packager son application ?

Livraison boite noire :

Contenu de l'application :

1 ou N repo git contenant:
- les chartes Helms de déploiements
- le descriptif de l'application (kosmos.yaml)
- les briques (fichiers yaml des briques)
- les scripts de création des espaces de stockages nécessaires au fonctionnement ou au tests :
  - s3 : nom des buckets
  - PG / Es : scripts d'initialisation

L'installation consiste à :

créer les espaces de stockage
kosmos import
kosmos create
kosmos deploy

Livraison boite blanche :

Idem ci dessus :

repo git de code source
chaine de CI pour produire l'application (et éventuellement la déployer, mais ce n'est pas obligatoire, sinon produire le package du mode boite noire + utilisation de l'IHM pour déployer)
tous les conteneurs / librairies nécessaires à la production de l'application (compilation + packaging) qui ne sont pas dans le KDL

L'installation consiste à :

créer les espaces de stockage
kosmos import (des repos gits de sources + packages nécessaires au dev) => la CI s'exécute et produit les livrables et éventuellement les install
create/deploy de l'appli avec l'IHM si la CI ne le fait pas

Packaging de la livraison d'une application

La livraison d'une application destinée à l'infostructure doit être faite via la production d'une archive qui contient les différents éléments qui composent l'application (code source et artéfacts).

A ce jour, seules les topologies des traitements du datapipeline ne sont pas traitées avec l'archive de l'application : les topologies sont exportées et importées via l'IHM du datapipeline au format d'un fichier .json. Par contre, les UDF (briques spécifiques) doivent être fournies via une archive en suivant le process ci-dessous.

Qu'est-ce qu'une archive ?

Une archive correspond à tout ou partie d'une application packagée et disponible pour être importée dans une infostructure. Toute livraison d'une application passe par ce format standard pour l'import sur l'infostructure cible. Ce format est obligatoirement un format fichier.

Plusieurs applications peuvent être packagées dans une même archive.

Une archive se compose principalement de ressources issues de Git, de Containers et sa structure est définie dans un descripteur.

Lorsque le développeur s'appuie sur le KDL, il doit créer manuellement le descripteur, puis utiliser une fonction d'export qui est fournie par le service applicatif pour générer l'archive.

Lorsque le développeur n'utilise pas le KDL, il doit créer manuellement le descripteur et l'archive.

Ce chapitre décrit le format du descripteur et comment mettre en place l'archive manuellement.

Contenu d'une application

Une application est composée de ressources de différents types :

Dépôts GIT
Images de containers
Fichiers de format quelconque (JAR, script python, ...) accessibles par HTTP ou par S3technique

Les ressources d'une application doivent être rangées dans un package de format ZIP ou TAR.

Elles sont décrites dans un fichier descripteur de format YAML se trouvant à la racine du package ZIP ou TAR.

Descripteur d'une application

Le descripteur d'une application décrit les ressources qui la composent.

Le descripteur comprend une liste d'items ayant les champs suivants :

type: type de la ressource (container, git, http, s3technique)
name: nom de la ressource dans le package (optionnel, par défaut le nom de la ressource est utilisé)
resource: URL relative de la ressource (cf ci-après)
ressource git seulement:
- branch: branche GIT
- tag: tag GIT (optionnel)
ressource container seulement:
- tag: tag à positionner sur l'image (optionnel)
ressource s3technique seulement:
- bucket: nom du bucket S3 contenant la ressource

Le développeur doit demander à l'administrateur de la plateforme la base du champ resource s'il doit la connaitre car elle est définie dans le fichier de configuration de l'outil d'import et d'export.

Dans le cas d'une ressource de type HTTP hébergée par un serveur Gitea, la ressource doit être de la forme suivante :

/api/packages/compte ou organisation/generic/nom de paquet/version/fichier

Seul le dépôt de type generic est accessible par le SAp. Les autres types pypi, npm, ... ne le sont pas.

exemple: /api/packages/athea/generic/package1/0.0.1/monfichier.zip

Exemple

Ci-dessous figure un exemple d'un fichier descripteur d'une application.

items:
   - type: container
     resource: /domaine/infostructure/socle/service-applicatif/demo/demo-app:0.0.1
   - type: http
     resource: /api/packages/athea/generic/pilo0/1.0.0/bson-4.0.5.jar
   - type: http
     resource: /api/packages/athea/generic/lid-model/1.0.1/lid-model-1.0.1.py
   - type: http
     resource: /api/packages/athea/generic/pymongo/3.11.2/pymongo-3.11.2-cp27-cp27m-win_amd64.whl
   - type: git
     branch: develop
     tag: v7
     resource: /infostructure/socle/service-applicatif/gitops-lab/demo/demo-app-chart
   - type: s3technique
     bucket: streamui
     resource: /definitions/icons/mylogoudf.svg
   - type: s3technique
     bucket: pkg-python
     resource: /offline-package-pip-3-0-7.tar.gz

Export via le service applicatif

La fonction kosmos export du service applicatif permet de générer l'archive à partir du descripteur : voir la procédure associée dans le DTU.

Package manuel d'une application

Si le package n'est pas fait via la fonction d'export, il doit être fait comme décrit ci-dessous.

Les ressources doivent être rangées dans un package ZIP ou TAR selon la structure suivante :

Il doit y avoir à la racine du package le descripteur de l'application
Il doit y avoir également à la racine du package un sous-répertoire par type de ressource (container, http, git, s3technique)
Le sous-répertoire container doit contenir un fichier TAR par image container, nommé selon le nom de l'item. Le nom du fichier correspond soit au champ name suffixé par .tar si ce champ est fourni, soit sinon au champ resource sans le chemin, dans lequel on a remplacé le caractère : par un tiret (-), et suffixé par .tar.
Le sous-répertoire git doit contenir un sous-répertoire par projet GIT, nommé selon le nom de l'item figurant dans le descripteur. Le nom du répertoire correspond soit au champ name si ce champ est fourni, soit sinon au champ resource sans le chemin.
Les sous-répertoires http, s3technique doivent contenir un fichier par item, nommé selon le nom de l'item figurant dans le descripteur (extension comprise). Le nom du fichier correspond soit au champ name si ce champ est fourni, soit sinon au champ resource sans le chemin.

Ci-dessous la structure du package correspondant au descripteur de l'application présenté dans le chapitre Descripteur d'une application.

| descripteur_demo-app.yml
|-container
| |- demo-app-0.0.1.tar
|- http
| |- bson-4.0.5.jar
| |- lid-model-1.0.1.py
| |- pymongo-3.11.2-cp27-cp27m-win_amd64.whl
|- git
  |- demo-app-chart
    |- Chart.yaml
    |- values.yaml
    |- < autres fichiers >
    |- templates
      |- deployment.yaml
      |- service.yaml
|- s3technique
| |- mylogoudf.svg
| |- offline-package-pip-3-0-7.tar.gz

Comment extraire / préparer ses projets Git ?

Une bonne pratique est de s'attacher à garantir que seules les versions stables (tag branche master) font l'objet d'une livraison.

Modèle de commande à lancer pour obtenir l'extraction depuis Git (à contextualiser avec l'environnement de développement) :

git clone git@<path-cible>

Exemple:

git clone git@gitlab.artemis.public:infostructure/socle/service-applicatif/gitops-lab/kosmos-sap/-/tree/develop/doc/labs/02-VerySimpleSApDeployment

attention

Il est recommandé de ne pas inclure des fichiers programmes (binaires) dans le projet git d'une application pour en réduire sa taille et éviter que la création de ladite application au moyen de l'IHM SAp n'échoue sur une erreur de Timeout.

Comment extraire / préparer ses images Docker ?

L'image doit être taguée suivant la convention ARTEMIS.

$ docker pull <mon-image>
$ docker tag <mon-image> <path-cible>/<image-cible>:<tag-cible>
$ docker save <path-cible>/<image-cible>:<tag-cible> > <local-path>/<image-cible>-<version-cible>.tar

Exemple:

$ docker pull ApacheSimpleSurLeNet:1.0.0
$ docker tag ApacheSimpleSurLeNet:1.0.0 cu-registry.technique.artemis/projet/global/athea/labs/composants/ApacheSimple/labs_ApacheSimple:1.0.1
$ docker save cu-registry.technique.artemis/projet/global/athea/labs/composants/ApacheSimple/labs_ApacheSimple:1.0.1 > /preparation-archive/ApacheSimple-1.0.0.tar

Persistance du descripteur

Lors de l'import, le fichier descripteur qui est à la racine de l'archive ZIP ou TAR n'est pas persisté. Il convient donc, si on souhaite le conserver, de l'inclure dans une ressource git livrée.

Ce descripteur peut être utile pour générer facilement un export d'un projet.

Signature des ressources

Les ressources exportées ou importées peuvent être signées.

La signature s'effectue grâce à l'outil Cosign.

Les ressources devant être signées (export) ou signées dans l'archive (import) sont indiquées dans le descripteur, à l'aide d'un champ supplémentaire: signed, valant true, à indiquer pour chaque ressource.

Exemple:

  ...
   - type: container
     resource: /domaine/infostructure/socle/service-applicatif/demo/demo-app:0.0.1
     signed: true
  ...

Les ressources signées sont présentes dans l'archive sous forme de répertoires (avec des règles de nommage identiques au cas non-signé), contenant le résultat de la sauvegarde par cosign de la ressource signée.

La clé publique utilisée pour générer l'archive doit être copiée dans le bucket contenant toutes les clés publiques cosign de la plateforme cible (celle qui va importer l'archive). Ce bucket est le bucket cosign-public-keys du s3 technique de la plateforme. La clé publique de la plateforme locale est elle-même dans ce bucket, elle est nommée local.pub.

Génération manuelle des signatures

Il faut d'abord être connecté à la registry, par exemple avec la commande cosign login:

cosign login <registry> -u <user> -p <password>

Il faut ensuite générer une paire de clés avec la commande cosign generate-key-pair:

$ cosign generate-key-pair
Enter password for private key:
Enter again:
Private key written to cosign.key
Public key written to cosign.pub

Cas d'un container

Générer la signature en utilisant la commande suivante :

cosign sign --key cosign.key <référence du hash de l'image> --tlog-upload=false

La référence de l'image est de la forme registry/chemin@sha256:hash. La valeur du hash est indiquée sur la page de détail de la registry correspondant à l'image du container.

Sauvegarder la ressoure signée en utilisant la commande suivante :

cosign save <référence du hash de l'image> --dir=<répertoire>

La référence est la même que celle fournie pour la commande cosign save. La ressource signée est sauvegardée dans le répertoire indiqué. Le contenu de ce répertoire doit être entièrement placé dans le réperoire correspondant à la ressource dans l'archive (nom du répertoire=nom de la ressource-version)

Exemple:

| ...
|-container
| |- demo-app-0.0.1
| |  |- index.json
| |  |- oci-layout
| |  |- blobs
| |  |  |- sha256
| |  |  |  |- 0c55ca25590c1f5bd2b053cb8be2f004b73d446cb888bdc4392167a1df341d1b
| ...

Cas d'un autre type de ressource

Dans le cas d'une ressource de type git commencer par générer un fichier ZIP contenant le répertoire du dépôt Git (les fichiers du dépôt étant directement à la racine du fichier ZIP).
Charger le fichier dans la registry (soit le fichier ZIP soit le fichier correspondant à la ressource) avec la commande suivante :

cosign upload blob -f <fichier ressource> <référence de l'image>

La référence de l'image est de la forme registry/chemin:version où chemin et version correspondent à un emplacement dans la registry qui ne sera utilisé que pour générer la signature.

Cette commande fournit en réponse une référence de hash. Procéder ensuite comme pour le cas d'un container, en utilisant cette référence de hash, avec le chemin d'image choisi pour l'upload.

Le contenu du répertoire généré par la commande cosign save doit être placé dans l'archive, dans un répertoire dont le nom est le nom du projet GIT dans le cas de ressource GIT, ou le nom du fichier, extension comprise, dans le cas de ressource HTTP.

Exemple :

| ...
|- git
| |- demo-app-chart
| |  |- index.json
| |  |- oci-layout
| |  |- blobs
| |  |  |- sha256
| |  |  |  |- fc43254ce4cc5e58bada8d27e12cf35e3aa9c0fc9c1bc75a13059b65fc90d367
| ...
|- http
| |- bson-4.0.5.jar
| |  |- index.json
| |  |- oci-layout
| |  |- blobs
| |  |  |- sha256
| |  |  |  |- df9bd768a29dcdd1cd669055adc9c3af003b9c22d95bb24bfe580933c38788ab

Modelisation des Values de la Chart

Ce document explique comment personnaliser les Values d'une Chart avec la modélisation Go Template.

GO Template

La modélisation Go Template doit être écrite dans des fichiers values.tpl.

La syntaxe Go Template est semblable à celle utilisée par Helm.

La plupart des fonctions apportées par Helm sont disponibles.

la documentation des fonctions standards peut être consultée à l'URL suivante : http://masterminds.github.io/sprig/

Des fonctions additionnelles ont été développées spécifiquement pour SAp.

Il s'agit de :

KvReq : permet de récupérer des valeurs dans les propriétés d'une KosmosInterface
KvGet : permet de récupérer des valeurs dans un inventaire de type KV (KeyValue)
toYaml : permet de présenter les valeurs récupérées selon une syntaxe Yaml
select : permet de sélectionner une valeur d'une clef d'inventaire ou d'une propriété KosmosInterface spécifique

Un outil de test de la modélisation est proposé à l'URL suivante : https://repeatit.io/

Exemple 1

Une application exemple1 a comme prérequis une interface de type postgre qui matche sur l'interface déployée ns-example/pg0.

Son prérequis est défini dans son fichier kosmos.yaml de la façon suivante.

name: exemple1
prerequisities:
  postgrePre1:
    type: RDBMS
    tags:
    - name: zone
      value: zone1
    - ...
  ...

L'interface déployée ns-example/pg0 est définie par sa KosmosInterface de la façon suivante.

apiVersion: sap.kosmos.tech/v1
kind: KosmosInterface
metadata:
  name: pg0
  namespace: ns-example
spec:
  type: RDBMS
  description: Une interface exemple de type postgreSQL
  tags:
    - name: zone
      value: zone1
  ...
  properties:
    username: john.doe
    password: p4ssWord

Le fichier values.tpl permet de modéliser la valeur de l'interface postgrePre1 de la façon suivante.

{{- $r1 := KvReq "postgrePre1" }}
mypostgre: {{- $r1 | toYaml |nindent 2}}

La fonction KvReq récupère la définition de postgrePre1 dans kosmos.yaml.

Puis elle retourne les informations figurant dans le champ properties de la KosmosInterface

Exemple 2

Une instance de JanusGraph est déployée et les propriétés de sa KosmosInterface contiennent le champ hostlist pour définir la liste des noeuds du cluster JanusGraph.

La modélisation suivante permet de transformer le champ hostlist en une string "host1,host2,...,hostN".

Définition de la fonction "jghostlist" :

{{- define "jghostlist" }}
{{- $outputList := list -}}
{{- range $i, $e := .}}
{{- $outputList = append $outputList (print .) -}}
{{ end -}}
{{- join "," $outputList -}}
{{- end }}

Utilisation de la fonction "jghostlist" :

host: {{ template "jghostlist" ( KvReq "jgKnowledge" | select "hostlist" ) }}

Exposition de l'application

Introduction

Pour accéder à une IHM (via le navigateur, dans le portail métier) le développeur doit avoir (dans le chart de son application) un ingress, un service et un (ou plusieurs) pods. Le schéma ci-dessous montre le cheminement d'une requête depuis la page web d'une application déployée dans Artemis.IA. Pour simplifier le schéma, le service n'a pas été représenté (il s'intercale entre l'ingress et le pod) ni l'ingress class (qui apporte peu à la compréhension).

L'objet de cette documentation est d'expliquer les spécificités du chart de l'application pour que lorsqu'elle se déploie, les ressources créés par le SAp (encadré rouge en pointillé dans le schéma) soient correctement créées. L'objectif est aussi de préciser au développeur quelles contraintes cela implique dans le développement de son application.

Il existe également un mode de fonctionnement dans lequel la gestion de l'authentification est laissée à la charge de l'application (voir ci-dessous les annotations sur le service exposé).

info

La partie SSO n'est pas traité ici mais dans la procédure Utilisation du SSO.

Configurer la Chart

Pour exposer un (ou plusieurs) service(s), le développeur doit créer un Ingress Kubernetes et annoter le (ou les) service(s) concerné(s). Le plugin d'exposition des interfaces modifie cet ingress et (optionnellement) ajoute des ressources oauth2.

Ceci étant, un Chart qui expose des services par Ingress fonctionne de la même manière si le plugin d'exposition des services est actif ou pas.

attention

Le plugin d'exposition des services ne supporte que des Ingress ayant le format de l'exemple ci-dessous. Donc un Ingress qui expose un service qui n'a pas de champ spec.rules[i].paths[i].backend n'est pas traité par le plugin.

Exemple d'Ingress supporté par le plugin d'exposition des services :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-example
spec:
rules:
- host: "foo.bar.test"
    http:
    paths:
    - pathType: Prefix
        path: "/bar"
        backend:
        service:
            name: service1
            port:
            number: 80

URL exposée de l'ingress

Tous les champs host des spec.rules des ingress sont réécris pour correspondre au format attendu de la plateforme (par exemple, une application de la zone technique a tous ses hosts en *.technique.artemis).

La réécriture suit les règles suivantes :

Si l'Ingress possède l'annotation service.sap.kosmos.tech/forced-host-prefix alors ce préfixe sera utilisé pour tous les hosts de l'ingress.

Dans l'exemple donné ci-dessus, si l'application est exposée en zone technique (le suffixe est .technique.artemis) et que l'Ingress possède le champ suivant :

metadata:
  annotations:
    service.sap.kosmos.tech/forced-host-prefix: test-prefix

Alors l'url exposée sera test-prefix.technique.artemis.

Si l'Ingress ne possède pas l'annotation.

Dans ce cas là, l'url est construite à partir du champ spec.rules[i].host ET du nom de l'application. En effet, l'objectif est d'éviter des FQDN en double sur la plateforme (deux Ingress qui déclarent le même FQDN). Le champ spec.rules[i].host est traité : seule la partie avant le premier point de la chaîne de caractères est utilisée. Le préfixe de l'url est alors cette première partie de la chaîne liée au nom de l'application par un tiret.

Dans l'exemple ci-dessus, on a spec.rules[0].host: "foo.bar.test", si notre application s'appelle exampleapp et qu'elle est déployée en zone technique, alors l'url exposée sera foo-exampleapp.technique.artemis.

Si l'Ingress ne possède pas l'annotation mais que la première partie de spec.rules[i].host est égale au nom de l'application.

Supposons que dans notre exemple (toujours en zone technique, toujours avec l'application exampleapp) précédent nous ayons spec.rules[0].host: "exampleapp.bar.test". Si nous suivons la logique du point 2 nous devrions avoir l'url exposée exampleapp-exampleapp.technique.artemis. Pour éviter cette répétition inutile, dans le cas ou la première partie de spec.rules[i].host est égale au nom de l'application, alors nous n'avons pas le -<appname> dans l'url.

Dans ce cas, l'url exposée sera alors exampleapp.technique.artemis.

Autres éléments importants de l'Ingress

Le champ path est conservé : il garde le même fonctionnement que pour un Ingress kubernetes classique. Avec l'exemple d'Ingress donné ci-dessus, une requête allant sur foo-exampleapp.technique.artemis/bar est redirigée vers le service1.

Si l'ingress expose au moins une ihm (voir plus loin) alors le plugin SAp d'exposition des interfaces lui ajoutera les annotations nécessaires et les paramètres pour que le composant cert-manager lui génère un certificat par host de l'ingress (si cert-manager est utilisé sur la plateforme).

attention

Pour être correctement traité, l'Ingress doit avoir un pathType de valeur Prefix (quitte à mettre path: /) et le backend doit être un service (ne pas utiliser un backend resource).

Cas des IHM

Si le service renseigné concerne une IHM à exposer dans le portail, les annotations à ajouter sur le service sont les suivantes :

## Obligatoire
service.sap.kosmos.tech/type: <ihm ou ihm-no-oauth2>

## Optionnel
service.sap.kosmos.tech/icon-name: <nom de l'icône a utiliser>
service.sap.kosmos.tech/portal-tags: <value1>,<value2>,...,<valueN>
service.sap.kosmos.tech/portal-tilename: <value>
service.sap.kosmos.tech/client-roles: <value1>,<value2>,...,<valueN>
service.sap.kosmos.tech/description: <value>
service.sap.kosmos.tech/default-path: <value>

Les valeurs de ces annotations peuvent provenir du fichier values de la Chart Helm.

Quand l'application est installée l'administrateur système doit réaliser les actions manuelles suivantes :

Récupération du certificat associé au nom DNS externe de l'application. Cette opération dépend de la configuration de la plateforme et le certificat est fourni par l'hébergeur.
Mise en place de ce certificat dans le WAF.
Configuration du nom DNS externe de l'application dans le DNS externe. Cette opération dépend de la configuration de la plateforme et l'opération est réalisée par l'hébergeur.
Attribution aux utilisateurs autorisés du droit d'accès à l'application.

Ces actions manuelles sont détaillées dans le DTU administration dans les chapitres suivants :

Attribution du droit d'accès : IAM / Keycloak / Administration Guides / Ajouter les permissions / Ajouter l'accès à une tuile.
Mise en place du certificat : Security / WAF / Administration Guides / Importer un certificat.

service.sap.kosmos.tech/type

Si la valeur de l'annotation est ihm alors le plugin SAp d'exposition des interfaces gère le SSO et la création de la tuile.

Si la valeur de l'annotation est ihm-no-oauth2 alors le plugin SAp d'exposition des interfaces gère seulement la création de la tuile, et laisse la gestion du SSO à la charge de l'application.

Si l'annotation est absente (ou vaut api) alors le plugin SAp d'exposition des interfaces ne gère ni le SSO ni la création de la tuile.

service.sap.kosmos.tech/icon-name

Cette annotation (optionnelle) permet de renseigner l'image a afficher dans le portail. Par exemple, si dans le dossier du chart on a :

icons/
  app.png
  monicone.png

Si l'on souhaite que la tuile du portail affiche l'image monicone.png alors il faut renseigner service.sap.kosmos.tech/icon-name: monicone.png. Si l'annotation n'est pas présente alors ce sera l'image app.png qui sera utilisée. Si icons/app.png n'existe pas et que l'annotation n'est pas présente, alors une image par défaut de la plateforme sera affichée sur la tuile.

Convention de nommage (sans parler de l'extension) : les majuscules et charactères spéciaux (sauf le tiret en milieu de mot) sont interdits. Une erreur sera retournée et l'application ne sera pas déployée si cette convention n'est pas respectée.

service.sap.kosmos.tech/portal-tags

Cette annotation (optionnelle) permet de définir une liste de tags qui pourront servir de filtres dans le portail. Par défaut la liste est vide.

service.sap.kosmos.tech/portal-tilename

Cette annotation (optionnelle) permet de définir le nom de la tuile du service exposé dans le portail.

Par défaut, la valeur du champ KAppName_ServiceName est utilisée.

service.sap.kosmos.tech/client-roles

Cette annotation (optionnelle) permet de définir la liste séparée par des virgules des rôles client spécifiques que l'utilisateur souhaite ajouter dans Keycloak.

Cette option n'est utile que si l'application possède une gestion fine de ses actions et qu'elle utilise donc le sso. Les rôles sont ceux utilisés par l'application.

Par défaut, elle est vide.

service.sap.kosmos.tech/description

Cette annotation (optionnelle) permet de définir la description du service que l'utilisateur souhaite voir sur la tuile du service exposé dans le portail.

Il faut mettre des guillemets autour de <value> car la chaîne de caractères peut comporter des espaces.

Par défaut, elle est vide.

service.sap.kosmos.tech/default-path

Cette annotation (optionnelle) permet de définir le path par défaut sur lequel l'utilisateur arrivera lorsqu'il clique sur la tuile dans le portail. Par exemple, un application qui a son menu principal sous /menu, peut renseigner ici service.sap.kosmos.tech/default-path="/menu". La valeur par défaut est /.

attention

A ne pas confondre avec les champs de l'Ingress ci-dessous.

pathType: Prefix
path: "/bar"

En effet, ce champ réécrit toutes les requêtes de / vers /bar, alors que service.sap.kosmos.tech/default-path="/bar" va juste rajouter /bar lors de la redirection quand on clique sur la tuile dans le portail.

Il faut mettre des guillemets autour de <value> car la chaîne de caractères comporte un ou plusieurs /.

Cas des API

Aucune annotation (pour le plugin d'exposition) n'est nécessaire pour les api car la valeur par défaut de service.sap.kosmos.tech/type est api et que pour toute annotation service.sap.kosmos.tech/type dont la valeur diffère d'ihm ou ihm-no-oauth2 le plugin d'exposition ne fait rien.

Une api est contactée seulement en interne au cluster kubernetes, pour qu'une autre application puisse la contacter (filtration par network policies), il faut ajouter au chart une KosmosInterface qui décrit l'accès à l'API. Toute KosmosApplication qui consomme cette API devra avoir celle-ci dans ses pré-requis. Si l'api n'est vouée à être contactée que en interne d'une même KosmosApplication alors il n'y a rien de plus à faire (les pods au sein d'une même KA peuvent communiquer entre eux librement).

attention

Une API exposée (avec KosmosInterface) depuis la zone métier n'est requêtable que depuis la zone métier. Une API exposée depuis la zone technique est requêtable depuis toutes les zones. Le plugin SAp des NetworkPolicies se charge de les créer en accord avec ce principe.

Connecter une application au SSO de la plateforme

Par défaut, une application qui expose une IHM et qui est déployée par le SAp a un contrôle d'accès "basique" : seuls les utilisateurs (dans keycloak) dont le rôle correspondant à cette IHM leur est affecté peuvent accéder à l'url de l'IHM (et voir sa tuile correspondante dans le portail).

Certaines applications intègrent une logique de gestion des utilisateurs, elles ont besoin d'accéder au token jwt qui contient les informations de connexion de l'utilisateur. Les applications concernées ne doivent pas se connecter directement à keycloak, c'est le reverse proxy oauth2 qui transmet le token d'authentification. Ce qui signifie que toutes les applications qui utilisent un client keycloak pour d'elles-mêmes rediriger l'utilisateur sur la mire de connexion ne sont pas conformes : en effet, une application qui fait du SSO recevra dans les headers de son (ou ses) pod(s) le token jwt via le reverse proxy.

attention

Le reverse proxy oauth2 ajoute le token aux headers de la requête qui va vers le pod. Ce header n'est donc jamais visible dans le navigateur. Si le développeur souhaite que les informations de connexion soient remontées au navigateur, le pod de l'application doit les ajouter lui-même à la requête. La bonne pratique est d'avoir un path de requête qui retourne les informations souhaitées de l'utilisateur connecté.

Utilisation du token jwt

Pour qu'il soit transmis à l'application, il faut ajouter à l'Ingress l'annotation service.sap.kosmos.tech/require-jwt: "true". Le token arrivera dans le pod via le header X-Auth-Request-Access-Token.

Se déconnecter

Si l'application fait du SSO et qu'elle comporte un bouton de déconnexion, l'url de déconnexion est la suivante :

/oauth2/sign_out?=rd<url de déconnexion encodée>%3Fredirect_uri%3D<url externe de l'application encodée >%2Foauth2%2Fstart

L'url de déconnexion peut être obtenue avec un KvGet : KvGet("keycloak-logout-url") elle n'est pas encodée. L'url externe de l'application correspond à l'url que l'utilisateur met dans son navigateur pour accéder à l'application.

Toutes les endpoints disponibles sont décrits dans la documentation officielle de keycloak.

Exemple en Java

Exemple de parsing du token pour une application en java avec la librairie java-jwt :

import java.util.Base64;
import org.apache.tomcat.util.json.JSONParser;
import org.apache.tomcat.util.json.ParseException;
import java.util.LinkedHashMap;
import java.util.List;
import java.util.Map;
import com.auth0.jwt.JWT;

String jwtEncoded = (String)req.getHeader("X-Auth-Request-Access-Token").trim();

DecodedJWT jwt = JWT.decode(jwtEncoded);
String jwtPayload = jwt.getPayload();
String jwtDecodedString = new String(Base64.getDecoder().decode(jwtPayload.getBytes()));
JSONParser jwtJson = new JSONParser(jwtDecodedString);
LinkedHashMap<String, Object> jwtMap = new LinkedHashMap<String, Object>() ;

// Récupérer l'id d'utilisateur keycloak qui a effectué la requête via l'IHM
try {
  jwtMap = jwtJson.object();
  // Récupérer le matricule utilisateur
  String userBec = (String)jwtMap.get("preferred_username");
} catch (ParseException e) {e.printStackTrace();}

// Récupérer les roles de l'utilisateur qui a effectué la requête via l'IHM
Map<String, Object> mso = (Map<String, Object>)jwtMap.get("resource_access");
String clientID = (String)jwtMap.get("azp");
List<String> roles = ((List<String>) ((Map<String, Object>) mso.get(clientID)).get("roles"));

Dépendances Maven pour le build

<dependency>
  <groupId>com.auth0</groupId>
  <artifactId>java-jwt</artifactId>
  <version>3.16.0</version>
</dependency>
<dependency>
  <groupId>commons-codec</groupId>
  <artifactId>commons-codec</artifactId>
  <version>1.15</version>
</dependency>

Pour savoir tous les champs (payload) que contient le JWT, allez dans keycloak : onglet Clients -> client public de l'application pilo0-app-np ici -> Client Scopes -> Evaluate -> sélectionner le user pour lequel on veut voir le token met adm -> Generated access token. texte

On obtient :

{
  "exp": 1684856891,
  "iat": 1684855991,
  "jti": "9ef9ad07-7efa-4857-b467-fb4b56a526f4",
  "iss": "https://auth.technique.artemis/auth/realms/kosmos",
  "sub": "26168357-aa9b-459b-8247-ca935d3a6250",
  "typ": "Bearer",
  "azp": "pilo0-app-np",
  "session_state": "cb353812-334d-4cf1-aacd-bfb73ae7f037",
  "acr": "1",
  "resource_access": {
    "pilo0-app-np": {
      "roles": [
        "reporter",
        "developer",
        "maintener"
      ]
    }
  },
  "scope": "openid email profile",
  "sid": "cb353812-334d-4cf1-aacd-bfb73ae7f037",
  "email_verified": true,
  "name": "met adm",
  "preferred_username": "admmet",
  "given_name": "met",
  "family_name": "adm",
  "email": "admmet@kosmos.fr"
}

Exemple en Python

Exemple de parsing du token pour une application en python

import jwt
from flask import request
encoded_jwt = request.headers.get('X-Auth-Request-Access-Token')
decoded_jwt = jwt.decode(encoded_jwt, options={"verify_signature":False})
username = decoded_jwt['preferred_username']

Guide des bonnes pratiques de SAp

Ce document apporte quelques conseils pour développer une application qui doit être installée par SAp.

Chart Helm

Une application doit être décrite dans une Chart Helm.

Se référer à la documentation Helm et ses bonnes pratiques.

Chart Autoporteuse

La Chart doit fonctionner par elle-même, c'est à dire que les pods instanciés doivent démarrer sans rien attendre d’autre.

Chart sans lookup

La Chart ne doit pas utiliser de Lookup ni d'URL vers des services externes en dur.

Les dépendances sont gérées par SAp.

Chart avec subcharts

La modularité de la Chart doit être gérée par des Subcharts.

Chaque subchart doit suivre les mêmes règles que la Chart qui l’appelle.

Hook Helm

Si la Chart utilise un Hook Helm celui-ci doit être Idempotent, c'est à dire qu'il donne le même résultat à chaque exécution.

Chart avec variables

Tout ce qui peut changer entre deux instances d'une même application (spécificité d’une plateforme, informations de paramétrage, ...) doit être variabilisé dans un fichier values.yaml.

Schéma de validation des valeurs de configuration

Le fichier values.schema.json est un composant qui permet de définir un schéma de validation pour les valeurs de configuration, garantissant ainsi la cohérence et la robustesse des déploiements. Ce document explique comment utiliser ce mécanisme en prenant comme exemple l'application pkafe.

Qu'est-ce que values.schema.json ?

values.schema.json est un fichier de schéma JSON qui définit la structure, les types et les contraintes des valeurs acceptables dans un chart Helm. Il utilise la spécification JSON Schema pour valider le fichier values.yaml lors de l'installation ou de la mise à jour d'un chart.

Avantages de values.schema.json

Validation automatique des valeurs avant déploiement
Documentation implicite des paramètres attendus
Prévention des erreurs de configuration
Standardisation des déploiements
Amélioration de l'expérience utilisateur avec des messages d'erreur explicites

Exemple concret avec pkafe

Structure du projet pkafe

L'application pkafe est composée de plusieurs charts Helm :

pkafe_chart : Chart principal (parent)
pkafe_api_chart : Chart pour le backend API
pkafe_ihm_chart : Chart pour le frontend IHM

Chacun de ces charts contient un fichier values.schema.json qui définit les contraintes pour son propre fichier values.yaml.

Exemple de values.schema.json dans pkafe_ihm_chart

{
    "$schema": "http://json-schema.org/schema#",
    "type": "object",
    "required": ["Nom_tuile", "Description", "Registry"],
    "properties": {
      "Nom_tuile": {
        "type": "string",
        "pattern": "^[a-zA-Z0-9-_]+$"
      },
      "Description": {
        "type": "string"
      },
      "Registry": {
        "type": "string"
      }
    }
}

Correspondance avec values.yaml

Nom_tuile: "pkafe-ihm"
Description: "Version par défaut de pkafe IHM"
Registry: "gitea.kosmos-int.athea"

ul_pilote_mono_ihm:
  # Partie deploiements & services
  repository: ""
  image: /athea/cas-usage/global/athea/pkafe/pkafe-ihm
  deployment_name: du-ulpmihm
  # ... autres valeurs

Comment fonctionne la validation ?

Lorsque vous exécutez une commande Helm comme helm install ou helm upgrade, Helm effectue automatiquement les étapes suivantes :

Charge le fichier values.yaml par défaut du chart
Fusionne avec les valeurs personnalisées fournies par l'utilisateur
Valide le résultat contre le schéma défini dans values.schema.json
Si la validation échoue, affiche un message d'erreur et interrompt l'opération
Si la validation réussit, poursuit le déploiement

Par exemple, si vous essayez d'installer pkafe avec un nom de tuile contenant des caractères spéciaux :

# values-custom.yaml
Nom_tuile: "pkafe@ihm"  # Caractère @ non autorisé

helm install pkafe ./pkafe_chart -f values-custom.yaml

Helm affichera une erreur indiquant que la valeur ne respecte pas le pattern défini.

Comment mettre en place values.schema.json dans son propre chart ?

Étape 1 : Créer le fichier values.schema.json

Créez un fichier values.schema.json à la racine de votre chart Helm avec la structure suivante :

{
  "$schema": "http://json-schema.org/schema#",
  "type": "object",
  "required": ["champ1", "champ2"],
  "properties": {
    "champ1": {
      "type": "string",
      "description": "Description du champ1"
    },
    "champ2": {
      "type": "integer",
      "minimum": 1,
      "maximum": 65535,
      "description": "Description du champ2"
    }
  }
}

Étape 2 : Définir les propriétés requises

Identifiez les champs qui doivent être obligatoirement présents dans votre values.yaml et ajoutez-les à la liste required.

Étape 3 : Spécifier les contraintes pour chaque propriété

Pour chaque propriété, définissez :

Le type de données (string, integer, boolean, object, array)
Les contraintes spécifiques (min/max pour les nombres, pattern pour les chaînes, etc.)
Une description pour documenter l'usage

Étape 4 : Tester la validation

Testez votre schéma en exécutant :

helm install --dry-run --debug mon-chart ./mon-chart

Si votre values.yaml ne respecte pas le schéma, Helm affichera une erreur explicite.

Exemples de validations avancées

Validation de format avec expressions régulières

Dans pkafe, le champ Nom_tuile est validé avec une expression régulière :

"Nom_tuile": {
  "type": "string",
  "pattern": "^[a-zA-Z0-9-_]+$"
}

Cela garantit que le nom de tuile ne contient que des lettres, des chiffres, des tirets et des underscores.

Validation de champs imbriqués

Vous pouvez également valider des structures imbriquées :

"ul_pilote_mono_ihm": {
  "type": "object",
  "properties": {
    "port_name": {
      "type": "string",
      "pattern": "^http-[a-z]+$"
    },
    "se_port": {
      "type": "integer",
      "minimum": 1,
      "maximum": 65535
    }
  }
}

Validation de tableaux

Pour valider des tableaux, vous pouvez définir :

"replicas": {
  "type": "array",
  "items": {
    "type": "string"
  },
  "minItems": 1,
  "uniqueItems": true
}

Validation conditionnelle

Vous pouvez définir des validations conditionnelles avec dependencies :

"properties": {
  "useCustomConfig": {
    "type": "boolean"
  },
  "customConfigPath": {
    "type": "string"
  }
},
"dependencies": {
  "useCustomConfig": {
    "oneOf": [
      {
        "properties": {
          "useCustomConfig": { "enum": [false] }
        }
      },
      {
        "properties": {
          "useCustomConfig": { "enum": [true] },
          "customConfigPath": { "type": "string", "minLength": 1 }
        },
        "required": ["customConfigPath"]
      }
    ]
  }
}

Bonnes pratiques

Commencez simple : Ne validez d'abord que les champs critiques
Documentez : Utilisez le champ description pour expliquer l'usage de chaque propriété
Soyez précis : Définissez des contraintes spécifiques pour éviter les erreurs
Testez régulièrement : Vérifiez que votre schéma fonctionne comme prévu
Évoluez progressivement : Enrichissez votre schéma au fur et à mesure que votre chart évolue
Utilisez des messages personnalisés : Ajoutez des messages d'erreur explicites avec errorMessage

Cas d'usage typiques

Validation des plages de ports

"port": {
  "type": "integer",
  "minimum": 1024,
  "maximum": 65535,
  "description": "Port du service (doit être > 1023)"
}

Validation des noms DNS

"hostname": {
  "type": "string",
  "pattern": "^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$",
  "maxLength": 253,
  "description": "Nom d'hôte conforme aux règles DNS"
}

Validation des URLs

"apiUrl": {
  "type": "string",
  "format": "uri",
  "pattern": "^https?://",
  "description": "URL de l'API (doit commencer par http:// ou https://)"
}

Intégration avec CI/CD

Vous pouvez intégrer la validation du schéma dans votre pipeline CI/CD :

validate-helm-chart:
  stage: validate
  script:
    - helm lint ./mon-chart
    - helm template ./mon-chart | kubeval
    - helm install --dry-run --debug mon-chart ./mon-chart

Conclusion

Le mécanisme values.schema.json est un outil puissant pour garantir la qualité et la cohérence des déploiements Helm. En suivant l'exemple de pkafe, vous pouvez facilement mettre en place cette validation dans vos propres charts et ainsi améliorer la robustesse de vos déploiements.

L'utilisation de ce mécanisme s'inscrit dans une démarche de qualité logicielle, en permettant de détecter les erreurs de configuration le plus tôt possible dans le cycle de déploiement.

Références

L'organisation du Chart pour une application

Le dossier qui contient le chart de l'application doit être organisé comme suit :

icons/
templates/
Chart.yaml
kosmos.yaml
values.yaml
values.tpl

Les fichiers values.yaml et Chart.yaml ainsi que le dossier templates sont des standards helm.

Le fichier kosmos.yaml est obligatoire pour que le Chart puisse être installé en tant que KosmosApplication. Il a le format suivant :

name: <nom utilisé dans le catalogue d'applications>

prerequisities: {} #Prérequis de l'application

Il contient le nom de l'application ainsi que la liste des services qui sont nécessaires à l'application, comme par exemple un ou plusieurs Espaces De Stockage. Les services nécessaires sont décrits dans la section prerequisities et font référence à des ressources de type KosmosInterface. Ces mécanismes sont expliqués dans le document sur les KI des EdS.

L'utilisation du fichier values.tpl est expliquée dans la page Modelisation des Values de la Chart.

Le dossier icons (facultatif) contient les icônes qui seront utilisées dans les IHM pour représenter l'application et les éventuelles IHM qu'elle déploie. Si le dossier icons n'est pas présent, une icône par défaut de la plateforme sera utilisée.

Dans le dossier icons, placer une image app.png (ou app.svg, app.jpeg, app.gif) qui est l'image par défaut de l'application. C'est cette image qui sera utilisée dans l'IHM SAp pour représenter l'application mais aussi celle qui sera affichée dans le catalogue d'applications instanciables. Vous pouvez aussi y placer d'autres fichiers au format png, svg, jpeg ou gif si vous souhaitez un affichage différent pour les IHM qu'exposent votre application (voir la documentation Exposition de l'application).

Espaces de Stockage, KosmosInterface et kosmos.yaml

Ce document explique comment un projet doit exposer les Espaces de Stockage qu'il apporte en plus de ceux qui sont standards sur la plateforme et comment une application du projet doit définir les Espaces de Stockage (standards ou autres) dont elle a besoin.

Définitions

Les Moyens de Stockage (MdS) sont les applications qui contiennent des Espaces de Stockage (EdS).

Les MDS et leurs contrôleurs d'accès (IAD) sont installés dans la zone technique de la plateforme.

Les EdS représentent les bases, les tables ou autres index qui sont manipulés au sein des MDS.

Les CR KosmosInterface (KI) décrivent les interfaces exposées par les EdS.

Les fichiers kosmos.yaml présents dans les Charts des applications décrivent les interfaces requises par les applications.

Les CR KosmosApplication (KA) décrivent les applications installées.

Outil EdS

L'outil EdS permet de créer les EdS standards de la plateforme et les KI de ces EdS dans Kubernetes.

KosmosInterface

Une KI contient les tags qui permettent de la retrouver via une recherche sur filtre et les propriétés qui permettent d'accéder à ses services.

apiVersion: sap.kosmos.tech/v1
kind: KosmosInterface
[...]
spec:
  type: RDBMS
  description: UNE base de données postgreSQL
  tags:
    - name: datastore
      value: <id artemis datastore_cu>
  properties:
    qualifiedName: <database>@<instance>
    database: <nom de la base PostgreSQL>
    uri: <host>:<port>
    port: <port>
    protocol:  tcp
    hostname: <host>
    username: <user>
    password: <password>

Les types de KosmosInterface générés par l'outil EdS sont les suivants.

Type de KI	Champ nom dans les Properties
ObjectsBucket	bucketname
KafkaTopic	topic
OpenSearchIndices	indexBasename
RDBMS	database
CH	database
VstoreNamespace	namespace

Les tags filtrables sont les suivants : datastore, datasetname, version, cluster, environment_app.

Les propriétés contiennent les informations suivantes :

nom de l'espace de stockage
uri, port, protocol
hostname s'il y a un seul host
hostlist s'il y a plusieurs hosts
qualifiedName : de la forme <name>@<cluster> ou <name>@<instance>
username
password

Le plugin Vault de SAp déplace toutes les propriétés dans le coffre fort et les supprime de la KI.

kosmos.yaml

Un kosmos.yaml contient dans la section prerequisites le type d'interface attendu et le ou les tag(s) qui permettent de sélectionner la bonne interface parmi toutes celles de même type qui sont installées.

# Nom de l'application
name: <nom-application>

# Prerequis
prerequisites:
  <nom-prerequis1>:
    type: <type-prerequis1>
    tags:
      <nom-tag1-prerequis1>: <valeur-tag1-prerequis1>
  <nom-prerequis2>:
    type: <type-prerequis2>
    tags:
      <nom-tag1-prerequis2>: <valeur-tag1-prerequis2>

Les KI des EdS

S3

apiVersion: sap.kosmos.tech/v1
kind: KosmosInterface
[...]
spec:
  type: ObjectsBucket
  description: UN bucket S3
  tags:
    - name: datastore
      value: <id artemis datastore_cu>
  properties:
    qualifiedName: <nom du bucket s3>@<host>
    bucketName: <nom du bucket S3>
    region: <région S3>
    uri: <host>:<port>
    port: <port>
    protocol:  s3
    hostname: <host>
    username: <user>
    password: <password>
    urn: <identifiant datahub de la ressource>
    version: <version de la ki>

Kafka

apiVersion: sap.kosmos.tech/v1
kind: KosmosInterface
[...]
spec:
  type: KafkaTopic
  description: UN topic kafka
  tags:
    - name: datastore
      value: <id artemis datastore_cu>
  properties:
    qualifiedName: <nom du topic>@<cluster>
    topic: <nom du topic>
    group: <nom du groupe kafka> (valeur par défaut : <nom EdS>-group)
    uri: <host1:port>,...
    port: <port>
    protocol: tcp
    hostlist:
    - <host1>
    - ...
    username: <user>
    password: <password>
    urn: <identifiant datahub de la ressource>
    version: <version de la ki>

OpenSearch

apiVersion: sap.kosmos.tech/v1
kind: KosmosInterface
[...]
spec:
  type: OpenSearchIndices
  description: UN PREFIXE d'index opensearch
  tags:
    - name: datastore
      value: <id artemis datastore_cu>
  properties:
    qualifiedName: <index prefix>@<cluster>
    indexBasename: <index prefix>
    uri: <host>:<port>
    port: <port>
    protocol:  http
    hostname: <host>
    username: <user>
    password: <password>
    urn: <identifiant datahub de la ressource>
    version: <version de la ki>

S'il y a le besoin de connexion à plusieurs index, il est préférable d'avoir un préfixe commun entre tous ces indexes pour ne se connecter qu'à une interface. Si ce n'est pas possible, il est conseillé de mettre plusieurs pré-requis dans le kosmos.yaml.

PostgreSQL

apiVersion: sap.kosmos.tech/v1
kind: KosmosInterface
[...]
spec:
  type: RDBMS
  description: UNE base de données postgreSQL
  tags:
    - name: datastore
      value: <id artemis datastore_cu>
  properties:
    qualifiedName: <database>@<instance>
    database: <nom de la base PostgreSQL>
    uri: <host>:<port>
    port: <port>
    protocol:  tcp
    hostname: <host>
    username: <user>
    password: <password>
    urn: <identifiant datahub de la ressource>
    version: <version de la ki>

ClickHouse

apiVersion: sap.kosmos.tech/v1
kind: KosmosInterface
[...]
spec:
  type: CH
  description: UNE base de données ClickHouse
  tags:
    - name: datastore
      value: <id artemis datastore_cu>
  properties:
    qualifiedName: <database>@<instance>
    database: <nom de la base ClickHouse>
    uri: <host>:<port>
    port: <port>
    protocol:  tcp
    username: <user>
    password: <password>
    urn: <identifiant datahub de la ressource>
    version: <version de la ki>

vStore

apiVersion: sap.kosmos.tech/v1
kind: KosmosInterface
[...]
spec:
  type: VstoreNamespace
  description: UN namespace vStore
  tags:
    - name: datastore
      value: <id artemis datastore_cu>
  properties:
    qualifiedName: <namespace>@<instance>
    namespace: <nom du namespace vStore>
    uri: <host>:<port>
    port: <port>
    urn: <identifiant datahub de la ressource>

Utilisation de Volumes Persistants

Les PersistentVolumes (PV) dans une application sont créés par les StorageClass (SC) de la plateforme.

Une application qui a besoin d'utiliser un PV doit avoir dans son Chart une PersitentVolumeClaim (PVC) qui va définir les ressources nécessaires.

C'est le SAp qui renseigne sur cette PVC la StorageClass a utiliser en connaissance des StorageClass de la plateforme.

info

Seuls les PVC avec un accessMode en ReadWriteOnce sont supportés.

Variables mises à disposition

SAp met à disposition les variables suivantes accessibles via la fonction KvGet:

Variable	Contenu
keycloak-internal-url	URL interne de Keycloak (URL du service Kubernetes)
keycloak-external-url	URL Externe de Keycloak
keycloak-clientId	identifiant du client public KeyCloak
keycloak-jwks-uri	URL permettant d'obtenir les clés publiques et certificats de KeyCloak
keycloak-logout-url	URL de déconnexion Keycloak
keycloak-realm	Royaume Keycloak
host-suffix	Suffixe DNS externe du nom de host
host-suffix-external	Suffixe DNS externe du nom de host
host-suffix-internal	Suffixe DNS interne du nom de host
oauth2-clientId	identifiant du client privé KeyCloak
oauth2-clientSecret	secret du client privé KeyCloak
oauth2-logoutUrl	URL de déconnexion OAuth2
tenant	Identifiant de la zone dans laquelle l'application est déployée

Comment packager son application ?​

Packaging de la livraison d'une application​

Qu'est-ce qu'une archive ?​

Contenu d'une application​

Descripteur d'une application​

Exemple​

Export via le service applicatif​

Package manuel d'une application​

Comment extraire / préparer ses projets Git ?​

Comment extraire / préparer ses images Docker ?​

Persistance du descripteur​

Signature des ressources​

Génération manuelle des signatures​

Cas d'un container​

Cas d'un autre type de ressource​

Modelisation des Values de la Chart​

GO Template​

Exemple 1​

Exemple 2​

Exposition de l'application​

Introduction​

Configurer la Chart​

URL exposée de l'ingress​

Autres éléments importants de l'Ingress​

Cas des IHM​

service.sap.kosmos.tech/type​

service.sap.kosmos.tech/icon-name​

service.sap.kosmos.tech/portal-tags​

service.sap.kosmos.tech/portal-tilename​

service.sap.kosmos.tech/client-roles​

service.sap.kosmos.tech/description​

service.sap.kosmos.tech/default-path​

Cas des API​

Connecter une application au SSO de la plateforme​

Utilisation du token jwt​

Se déconnecter​

Exemple en Java​

Exemple en Python​

Guide des bonnes pratiques de SAp​

Chart Helm​

Chart Autoporteuse​

Chart sans lookup​

Chart avec subcharts​

Hook Helm​

Chart avec variables​

Schéma de validation des valeurs de configuration​

Qu'est-ce que values.schema.json ?​

Avantages de values.schema.json​

Exemple concret avec pkafe​

Structure du projet pkafe​

Exemple de values.schema.json dans pkafe_ihm_chart​

Correspondance avec values.yaml​

Comment fonctionne la validation ?​

Comment mettre en place values.schema.json dans son propre chart ?​

Étape 1 : Créer le fichier values.schema.json​

Étape 2 : Définir les propriétés requises​

Étape 3 : Spécifier les contraintes pour chaque propriété​

Étape 4 : Tester la validation​

Exemples de validations avancées​

Validation de format avec expressions régulières​

Validation de champs imbriqués​

Validation de tableaux​

Validation conditionnelle​

Bonnes pratiques​

Cas d'usage typiques​

Validation des plages de ports​

Validation des noms DNS​

Validation des URLs​

Intégration avec CI/CD​

Conclusion​

Références​

L'organisation du Chart pour une application​

Espaces de Stockage, KosmosInterface et kosmos.yaml​

Définitions​

Outil EdS​

KosmosInterface​

kosmos.yaml​

Les KI des EdS​

S3​

Kafka​

Comment packager son application ?

Packaging de la livraison d'une application

Qu'est-ce qu'une archive ?

Contenu d'une application

Descripteur d'une application

Exemple

Export via le service applicatif

Package manuel d'une application

Comment extraire / préparer ses projets Git ?

Comment extraire / préparer ses images Docker ?

Persistance du descripteur

Signature des ressources

Génération manuelle des signatures

Cas d'un container

Cas d'un autre type de ressource

Modelisation des Values de la Chart

GO Template

Exemple 1

Exemple 2

Exposition de l'application

Introduction

Configurer la Chart

URL exposée de l'ingress

Autres éléments importants de l'Ingress

Cas des IHM

service.sap.kosmos.tech/type

service.sap.kosmos.tech/icon-name

service.sap.kosmos.tech/portal-tags

service.sap.kosmos.tech/portal-tilename

service.sap.kosmos.tech/client-roles

service.sap.kosmos.tech/description

service.sap.kosmos.tech/default-path

Cas des API

Connecter une application au SSO de la plateforme

Utilisation du token jwt

Se déconnecter

Exemple en Java

Exemple en Python

Guide des bonnes pratiques de SAp

Chart Helm

Chart Autoporteuse

Chart sans lookup

Chart avec subcharts

Hook Helm

Chart avec variables

Schéma de validation des valeurs de configuration

Qu'est-ce que values.schema.json ?

Avantages de values.schema.json

Exemple concret avec pkafe

Structure du projet pkafe

Exemple de values.schema.json dans pkafe_ihm_chart

Correspondance avec values.yaml

Comment fonctionne la validation ?

Comment mettre en place values.schema.json dans son propre chart ?

Étape 1 : Créer le fichier values.schema.json

Étape 2 : Définir les propriétés requises

Étape 3 : Spécifier les contraintes pour chaque propriété

Étape 4 : Tester la validation

Exemples de validations avancées

Validation de format avec expressions régulières

Validation de champs imbriqués

Validation de tableaux

Validation conditionnelle

Bonnes pratiques

Cas d'usage typiques

Validation des plages de ports

Validation des noms DNS

Validation des URLs

Intégration avec CI/CD

Conclusion

Références

L'organisation du Chart pour une application

Espaces de Stockage, KosmosInterface et kosmos.yaml

Définitions

Outil EdS

KosmosInterface

kosmos.yaml

Les KI des EdS

S3

Kafka