Aller au contenu principal

Installation

Pour toutes les commandes des sections suivantes lancées sur kdl-spray-1 :

  • les variables

    • ENV
    • KOSMOS_DOMAIN_EXTERNAL
    • KOSMOS_DOMAIN
    • KOSMOS_REGISTRY_ENDPOINT
    • KOSMOS_VALUES_CUSTOM_PATH
    • WORK_DIR

    doivent être définies dans le terminal conformément à la plateforme cible

  • le répertoire WORK_DIR et KOSMOS_VALUES_CUSTOM_PATH doivent exister

  • l'utilisateur utilisé est l'utilisateur sudoers demandé en prérequis

Pour que cela soit fait automatiquement dans tout terminal de kdl-spray-1, lancer les commandes suivantes en modifiant si nécessaire les trois premières lignes conformément à votre plateforme.

export KDL_VERSION="KDL_3.6"
export KOSMOS_DOMAIN=kdl-dev.athea
export KOSMOS_VALUES_CUSTOM_PATH=/data/values-custom
sudo bash -c "cat >> /etc/bash.bashrc <<EOF

# Répertoire dans lequel les fichiers d installation seront mis
export WORK_DIR=/data/$KDL_VERSION
mkdir -p \"\\\$WORK_DIR\"
# Nom du domaine à utiliser pour les url d accès aux services hébergés par le KDL
export KOSMOS_DOMAIN=$KOSMOS_DOMAIN
export KOSMOS_DOMAIN_EXTERNAL=\".$KOSMOS_DOMAIN\"
## Variables pour Helmfile
# Le fichier platform-provisioner/environments/\\\$ENV.yaml sera chargé durant l'installation
export ENV=kdl
# Répertoire qui contiendra les fichiers d'installation spécifiques à la plateforme (modification de sizing, configuration d'accès zot, ...)
export KOSMOS_VALUES_CUSTOM_PATH=$KOSMOS_VALUES_CUSTOM_PATH
mkdir -p \"\\\$KOSMOS_VALUES_CUSTOM_PATH\"
# Registry utilisée par helmfile
export KOSMOS_REGISTRY_ENDPOINT=kosmos-registry.$KOSMOS_DOMAIN/athea/hauler
EOF"

source /etc/bash.bashrc
source ~/.bashrc

Les différents livrables doivent être placés dans le répertoire WORK_DIR sur le noeud kdl-spray-1. Les livrables suivants doivent être disponibles :

  • apt-PF_noble_20260212-offline.tar.gz
  • apt-PF_noble_20260212-offline.tar.gz.sha256
  • kube_v1.32.6_3.6.21.tar.gz
  • kube_v1.32.6_3.6.21.tar.gz.sha256
  • platform-provisioner-core_3.6.21.tar.zst
  • platform-provisioner-core_3.6.21.tar.zst.sha256
  • platform-provisioner_3.6.21.tar.zst
  • platform-provisioner_3.6.21.tar.zst.sha256
  • offline-package-mvn-3-0-0.tar.gz
  • offline-package-mvn-3-0-0.tar.gz.sha256
  • offline-package-npm-3-0-0.tar.gz
  • offline-package-npm-3-0-0.tar.gz.sha256
  • offline-package-pip-3-0-10.tar.gz
  • offline-package-pip-3-0-10.tar.gz.sha256
  • offline-package-r-3-0-0.tar.gz
  • offline-package-r-3-0-0.tar.gz.sha256

Paquets Ubuntu​

Lancer les commandes suivantes pour installer les paquets apt nécessaires pour l'installation sur kdl-spray-1

cd "$WORK_DIR"
tar -zxvf apt-PF_noble_20260212-offline.tar.gz -C /tmp
sudo bash -c "echo \"deb [trusted=yes] file:/tmp/apt-PF_noble_20260212-offline/Packages ./\" > /etc/apt/sources.list.d/offline.list"
# Deactivate "Pending kernel upgrade" message
sudo sed -i "s/#\$nrconf{kernelhints} = -1;/\$nrconf{kernelhints} = -1;/g" /etc/needrestart/needrestart.conf
sudo apt update -o Dir::Etc::SourceList="/etc/apt/sources.list.d/offline.list" -o Dir::Etc::SourceParts=/dev/null -o Acquire::Languages="none"
sudo apt install -y -o Dir::Etc::SourceList="/etc/apt/sources.list.d/offline.list" -o Dir::Etc::SourceParts=/dev/null -o Acquire::Languages="none" ansible apache2-utils bash-completion curl podman git jq less rsync tmux uidmap vim wget yq

Binaires Kubernetes​

Lancer les commandes suivantes pour installer les binaires qui permettront d'interagir avec Kubernetes

cd "$WORK_DIR"
tar -zxvf kube_v1.32.6_3.6.21.tar.gz

# Deploy binaries
sudo cp kube-provisioner/v1.32.6/bin/* /usr/local/bin
sudo chmod +x /usr/local/bin/*

# Set auto completion
echo "" | sudo tee -a /etc/bash.bashrc
echo "source <(cilium completion bash)" | sudo tee -a /etc/bash.bashrc
echo "source <(hauler completion bash)" | sudo tee -a /etc/bash.bashrc
echo "source <(helm completion bash)" | sudo tee -a /etc/bash.bashrc
echo "source <(helmfile completion bash)" | sudo tee -a /etc/bash.bashrc
echo "source <(k9s completion bash)" | sudo tee -a /etc/bash.bashrc
echo "source <(kubectl completion bash)" | sudo tee -a /etc/bash.bashrc

# Installation helm diff plugin
mkdir -p ~/.local/share/helm/plugins/helm-diff/
tar -zxf kube-provisioner/v1.32.6/plugins/helm-diff-linux-amd64.tgz -C ~/.local/share/helm/plugins/helm-diff --strip-components=1

# Source basrc configuration
source /etc/bash.bashrc
source ~/.bashrc

Kubernetes​

Cas des plateformes sans Kubernetes​

La section décrit comment installer Kubernetes sur l'environnement.

Se rendre dans le répertoire d'installation de Kubernetes

cd "$WORK_DIR/kube-provisioner/os-provided"

Editer le fichier inventory_kdl.yaml conformément à votre plateforme :

  • kosmos_domain : le nom de domaine voulu pour les services hébergés par le KDL
  • external_registry : mettre à kosmos-registry.<kosmos_domain>, en remplaçant <kosmos_domain> par la valeur choisie
  • kube_endpoint : l'adresse ip du kdl-master-1
  • Pour chaque noeud :
    • ansible_host : l'adresse ip du noeud
    • node_ip : l'adresse ip du noeud
    • lvm_disk : le nom du disque brut demandé dans les prérequis
info

Kubernetes pour fonctionner aura besoin d'utiliser deux réseaux, un pour les pods l'autre pour les services. Par défaut les réseaux suivants sont utilisés : 10.42.0.0/16 pour le réseau des pods et 10.43.0.0/16 pour le réseau des services.

Il est conseillé de garder ces réseaux par défaut, mais si un changement de réseaux était nécessaire, ajouter dans le fichier inventory_kdl.yaml dans la section all > vars les entrées suivantes avec les réseaux souhaités

pod_network_cidr: 20.42.0.0/16
service_network_cidr: 20.43.0.0/16

Lancer les commandes d'installation de Kubernetes

# Installation de Kubernetes
ansible-playbook -i inventory_kdl.yaml kube.yaml

# Récupération du kubeconfig pour communiquer avec le cluster
mkdir -p ~/.kube
until ssh $(yq -r '.all.vars.kube_endpoint' inventory_kdl.yaml) "sudo cat /etc/rancher/rke2/rke2.yaml" > ~/.kube/config; do
  echo "Le fichier n'est pas encore disponible, nouvelle tentative dans 5 minutes..."
  sleep 300
done
echo "Le fichier config a été récupéré"
chmod 600 ~/.kube/config

# Attente de l'apparition des noeuds kubernetes
until kubectl get nodes; do
  echo "Les noeuds Kubernetes ne sont pas encore visibles, nouvelle tentative dans 1 minute..."
  sleep 60
done
echo "Les noeuds Kubernetes commencent à apparaitre"
info
  • le cluster met plusieurs minutes à démarrer.
  • le démarrage de Kubernetes peut être suivi en allant sur le master et en lançant la commande sudo journalctl -f | grep rke2. Le temps de démarrer plusieurs messages d'erreur sont visibles

Les commandes suivantes peuvent être lancées sur le master pour vérifier le bon chargement des images de base

cd /var/lib/rancher/rke2/data/v1.*/bin
sudo ./ctr -n=k8s.io --address /run/k3s/containerd/containerd.sock images list

Avant de passer aux sections suivantes, attendre que Kubernetes soit démarré en lançant la commande watch -c "kubectl get nodes && kubectl get pods -A". Lorsque Kubernetes est déployé :

  • les différents noeuds du cluster sont visibles et dans l'état "Ready"
  • les pods sont dans l'état "Running" ou "Completed".

Cas des plateformes avec Kubernetes déjà installé​

Récupérer la configuration du cluster Kubernetes sur un noeud master. Mettre à jour la première ligne du script avec le nom du premier master.

# Récupération du kubeconfig pour communiquer avec le cluster
MASTER_NODE=kdl-master-1
mkdir -p ~/.kube
ssh $MASTER_NODE "sudo cat /etc/rancher/rke2/rke2.yaml" > ~/.kube/config
chmod 600 ~/.kube/config

Avant de passer aux sections suivantes, vérifier que Kubernetes est bien accessible et fonctionnel en lançant la commande watch -c "kubectl get nodes && kubectl get pods -A" :

  • les différents noeuds du cluster sont visibles et dans l'état "Ready"
  • les pods sont dans l'état "Running" ou "Completed".

Composants Kubernetes de base​

  • Lancer les commandes suivantes pour préparer Hauler et le déploiement :
cd "$WORK_DIR"
# Variables pour Hauler
export HAULER_STORE_DIR=$WORK_DIR/hauler-store
export HAULER_REGISTRY_DIR=$WORK_DIR/hauler-registry
export HAULER_TEMP_DIR=$WORK_DIR/hauler-tmp
mkdir -p $HAULER_TEMP_DIR

# Récupération du déploiement via Hauler
hauler store load --filename platform-provisioner-core_3.6.21.tar.zst
hauler store extract hauler/platform-provisioner.tar
tar -xvf platform-provisioner.tar

# Lancement de Hauler en tant que registry
nohup hauler store serve registry --directory "$HAULER_REGISTRY_DIR" > /dev/null 2>&1 &

# cd dans le répertoire de déploiement
cd "$WORK_DIR/platform-provisioner"
  • Attendre que la registry Hauler réponde à la requête suivante (des lignes doivent apparaitre)
curl -s http://localhost:5000/v2/_catalog?n=1000 | jq .
Bug interne connu #42772

Pour éviter que le pods zot soit en erreur à cause de l'OIDC, garder une copie du fichier values/zot/values.yaml

cp ./values/zot/values.yaml ./values/zot/values.yaml_ori

Editer le fichier ./values/zot/values.yaml pour modifier le bloc

           "htpasswd": { "path": "/secrets/htpasswd/htpasswd" },
           "openid": {
             "providers": {
               "oidc": {
                 "name": "oidc",
                 "credentialsFile": "/secrets/oidc-creds/oidc-creds.json",
                 "issuer": "https://auth.{{ .Values.domain }}/realms/kosmos",
                 "keypath": "",
                 "scopes": ["openid"]
               }
             }
           }

en

            "htpasswd": { "path": "/secrets/htpasswd/htpasswd" }

Attention à bien supprimer la virgule à la fin de la ligne

  • Lancer l'installation des composants Kubernetes de base (certmanager, topolvm, zot)
KOSMOS_REGISTRY_ENDPOINT=localhost:5000/hauler helmfile -e $ENV sync -l component=core
  • Arrêter le serveur Hauler et supprimer ses données
kill -9 $(ps -eo pid,cmd | grep "[h]auler store serve" | awk '{print $1}')
rm -rf ${HAULER_STORE_DIR}
rm -rf ${HAULER_TEMP_DIR}
rm -rf ${HAULER_REGISTRY_DIR}

Configuration pour accéder à la registry kosmos-registry (zot)​

# Ajout des entrées vers la registry dans `/etc/hosts`
cd "$WORK_DIR/kube-provisioner/os-provided"
NODE_INFO=$(
  kubectl get nodes \
    --selector='!node-role.kubernetes.io/control-plane' \
    -o jsonpath="{.items[0].metadata.name} {.items[0].status.addresses[?(@.type=='InternalIP')].address}" \
  2>/dev/null
)
if [ -z "$NODE_INFO" ]; then
  NODE_INFO=$(kubectl get nodes \
    -o jsonpath="{.items[0].metadata.name} {.items[0].status.addresses[?(@.type=='InternalIP')].address}")
fi
NODE_NAME=$(echo "$NODE_INFO" | awk '{print $1}')
NODE_IP=$(echo "$NODE_INFO" | awk '{print $2}')

echo "Ajout dans /etc/hosts de l'entrée kosmos-registry.$KOSMOS_DOMAIN avec l'ip $NODE_IP ($NODE_NAME)"
ansible localhost -m lineinfile -b -a "path=/etc/hosts line='${NODE_IP} kosmos-registry.$KOSMOS_DOMAIN' state=present"

# Récupération de la CA Kubernetes
kubectl -n kosmos-system-restricted get secrets kosmos-ca-secret -o jsonpath={'.data.tls\.crt'} | base64 -d > /tmp/kube-ca.crt
sudo cp /tmp/kube-ca.crt /usr/local/share/ca-certificates
sudo update-ca-certificates

# Authentification de Hauler et Helm
zot_username=$(kubectl -n kosmos-dev-restricted get secret zot-admin-secret -o jsonpath='{.data.username}' | base64 -d )
zot_password=$(kubectl -n kosmos-dev-restricted get secret zot-admin-secret -o jsonpath='{.data.password}' | base64 -d )
hauler login --username ${zot_username} --password ${zot_password} kosmos-registry.${KOSMOS_DOMAIN}
helm registry login --username ${zot_username} --password ${zot_password} kosmos-registry.${KOSMOS_DOMAIN}
info

Pour éviter les futures alertes dans votre navigateur lors de la connexion aux UI hébergées par Kube, le certificat /tmp/kube-ca.crt peut être importé dans votre navigateur

Chargement des images des conteneurs et du déploiement​

Lancer les commandes suivantes pour charger l'ensemble des images de la livraison dans kosmos-registry (zot).

info
  • Le livrable faisant plusieurs dizaines de Go le store load et store copy prennent plusieurs dizaines de minutes.
  • La commande store load affichera le message INF unarchiving completed successfully mais ne rendra pas la main immédiatement. Le comportement est normal et il est nécessaire d'attendre plusieurs minutes
cd "$WORK_DIR"
# Variables pour Hauler
export HAULER_STORE_DIR=$WORK_DIR/hauler-store
export HAULER_TEMP_DIR=$WORK_DIR/hauler-tmp
mkdir -p $HAULER_TEMP_DIR

# Chargement des artefacts dans la registry
hauler store load --filename platform-provisioner_3.6.21.tar.zst
hauler store copy registry://kosmos-registry.${KOSMOS_DOMAIN}/athea

# Récupération du déploiement via Hauler
hauler store extract hauler/platform-provisioner.tar
tar -xvf platform-provisioner.tar

# Suppression des répertoires Hauler
rm -rf ${HAULER_STORE_DIR}
rm -rf ${HAULER_TEMP_DIR}

Installation des Apps dans Kubernetes​

Configuration de l'installation​

Configurer l'environnement selon la réponse aux questions des sections suivantes.

Un GPU est-il disponible ?​

Par défaut l'installation considère qu'un GPU est disponible. Si ce n'est pas le cas, pour éviter de perdre des ressources inutilement, éditer le fichier $WORK_DIR/platform-provisioner/environments/$ENV.yaml pour ajouter les lignes suivantes

gpuOperator:
  enabled: false

Lancement de l'installation​

Lancer les commandes suivantes pour lancer l'installation du reste des Apps dans Kubernetes

cd "$WORK_DIR/platform-provisioner"
helmfile -e $ENV sync -l component!=core
info

Pour suivre la progression la commande suivante peut être utilisée

watch -c "helm list -aA | grep -v deployed && kubectl get pods -A -o wide | grep -v Running | grep -v Completed"
Bug interne connu #42552

Si à la fin de l'installation dans le namespace kosmos-data des pods scan-pipeline* sont en erreur, lancer la commande helmfile -e $ENV sync -l component=scan. Les pods en erreur vont disparaitre.

Post-installation Gitlab​

Suivre les instructions sur la post installation de Gitlab

Configuration des accès aux IHMs​

Si aucun DNS n'est disponible, lancer la commande suivante pour remplir /etc/hosts. Par défaut les url sont renvoyées vers le premier worker. Si un load balancer est disponible utiliser plutôt son IP que celui du premier worker

FIRST_WORKER_IP=$(kubectl get nodes --selector='!node-role.kubernetes.io/control-plane' -o jsonpath="{.items[0].status.addresses[?(@.type=='InternalIP')].address}")
for host in $(kubectl get ingress -A -o custom-columns="HOSTS:.spec.rules[*].host" --no-headers | sort -u); do
    if ! grep -q " $host" /etc/hosts; then
        echo "$FIRST_WORKER_IP $host" | sudo tee -a /etc/hosts
        echo "Ajouté : $FIRST_WORKER_IP $host"
    else
        echo "Déjà présent : $host"
    fi
done

Si un DNS est disponible, définir des entrées pour les url retournées par la commande suivante en les renvoyant vers le premier worker

kubectl get ingress -A -o custom-columns="HOSTS:.spec.rules[*].host" --no-headers  | sort -u

Configuration de Rancher et accès aux secrets​

Suivre les instructions sur l'activation du SSO dans l'interface Rancher

Suivre les instructions sur l'ajout de la kosmos-registry (zot) à Rancher

Ensuite, pour accéder aux secrets de la plateforme :

  • se connecter avec le compte admin à https://rancher.$KOSMOS_DOMAIN
  • cliquer dans le tableau sur le cluster local
  • cliquer sur la gauche sur Storage
  • cliquer sur la gauche sur Secrets
  • utiliser le champ de recherche en haut à droite pour chercher un secret en particulier

Quelques secrets utiles :

  • argocd-initial-admin-secret : mot de passe de l'utilisateur admin pour argocd
  • gitlab-gitlab-initial-root-password : mot de passe de l'utilisateur root pour gitlab
  • keycloak-cluster-initial-admin : mot de passe de l'utilisateur admin pour keycloak
  • gitea-admin-secret : nom d'utilisateur et password de l'administrateur gitea

Import des librairies​

L'import des librairies consistent à déposer les offline-package-*.tar.gz de la livraison dans le bucket S3 adéquat. Pour cela :

  • récupérer les credentials S3
echo s3_username = $(kubectl -n kosmos-s3 get secret minio-secrets -ojsonpath='{.data.accessKey}'| base64 -d)
echo s3_password = $(kubectl -n kosmos-s3 get secret minio-secrets -ojsonpath='{.data.secretKey}'| base64 -d)
  • se connecter à S3 https://s3-admin.$KOSMOS_DOMAIN en mode Use Credentials avec ces credentials
  • cliquer sur le bucket pkg-python
  • cliquer sur Upload puis Upload File
  • sélectionner le fichier offline-package-pip-*.tar.gz de la livraison puis cliquer sur Open
  • recommencer ce processus avec le bucket pkg-npm et le fichier offline-package-npm-*.tar.gz de la livraison
  • recommencer ce processus avec le bucket pkg-mvn et le fichier offline-package-mvn-*.tar.gz de la livraison
  • recommencer ce processus avec le bucket pkg-r et le fichier offline-package-r-*.tar.gz de la livraison

Plus d'information sont disponibles dans la section Importer un package

Vérification des exemples de code git​

Pour que les exemples de code Git fonctionnent :

info

Pour la configuration du runner :

  • Utiliser l'exemple du runner privilégié car il est nécessaire pour les builds des images avec Buildah
  • Activer la case à cocher Run untagged jobs
  • Mettre 3600 dans le champ Maximum job timeout

Pour la configuration RBAC, pour que les samples fonctionnent, utiliser le fichier agent-rbac-athea-samples.yaml disponible dans la livraison

  • Forker les projets présents dans le groupe Toolbox/Athea/Samples https://gitlab.<KOSMOS_DOMAIN>/toolbox/athea/samples dans le groupe créé pour le tenant fictif
  • Dans le groupe créé pour le tenant fictif, cliquer sur Settings > CI/CD puis General pipelines pour mettre 500 en tant que Maximum artifacts size. La valeur par défaut est de 100, ce qui n'est pas suffisant pour l'exemple java. Le compte administrateur de Gitlab doit être utilisé pour cela, être Owner du groupe n'étant pas suffisant.
  • Lancer les pipelines des projets forkés