VIYA 4 – Les méthodes de déploiement

Il existe plusieurs méthodes de déploiement de SAS Viya. Le logiciel est distribué sous forme d'images de conteneurs qui peuvent être déployées sur un cluster Kubernetes en utilisant la commande kubectl apply. Toutefois, SAS propose également des méthodes alternatives pour automatiser les mises à jour et répondre aux besoins spécifiques de chaque environnement.

Les quatre méthodes disponibles  

1. Commandes Manuelles (kubectl apply):
   • Description: Cette approche consiste à générer le manifeste Kubernetes complet pour SAS Viya (souvent un fichier volumineux nommé site.yaml ) en utilisant l'outil Kustomize (kustomize build), puis à appliquer ce manifeste directement au cluster Kubernetes à l'aide de commandes kubectl apply. Il peut être nécessaire d'appliquer les ressources en plusieurs étapes basées sur les niveaux de privilèges requis (cluster vs namespace).  
   • Avantages: Offre le contrôle le plus granulaire sur le processus de déploiement. Utile pour le dépannage détaillé et l'intégration dans des scripts d'automatisation personnalisés existants. Sert souvent de point de départ pour développer des méthodes de déploiement personnalisées.  
   • Inconvénients: C'est la méthode la moins automatisée fournie par SAS. Elle ne bénéficie pas des mécanismes de validation de politique ou d'orchestration intégrés des autres méthodes. Elle est complexe, fastidieuse et très sujette aux erreurs humaines, en particulier pour les déploiements à grande échelle ou les mises à jour fréquentes. Elle nécessite des privilèges élevés (souvent cluster-admin) pour appliquer l'ensemble des ressources.  
   • Pertinence CI/CD: Faible pour un déploiement complet et automatisé. Cependant, la commande kubectl apply reste l'action fondamentale exécutée par les autres méthodes et peut être intégrée dans des scripts, bien que cela nécessite de réimplémenter une grande partie de la logique d'orchestration.
2. SAS Viya Deployment Operator:
   • Description: Cette méthode s'appuie sur le pattern des Opérateurs Kubernetes. Un opérateur spécifique à SAS Viya est d'abord déployé dans le cluster (soit dans le même namespace que Viya, soit en mode cluster-wide pour gérer plusieurs déploiements). Cet opérateur surveille ensuite des ressources personnalisées (Custom Resources - CRs) de type SASDeployment. Lorsqu'une CR SASDeployment est créée ou modifiée, l'opérateur déclenche le processus de déploiement ou de mise à jour : il récupère les assets de déploiement SAS nécessaires, exécute kustomize build pour générer le manifeste, puis applique ce manifeste via kubectl apply.  
   • Avantages: C'est la méthode recommandée par SAS pour le déploiement et les mises à jour. Elle automatise entièrement les étapes de déploiement et de mise à jour, y compris la récupération des nouveaux assets. Elle intègre la validation de la conformité avec les politiques de support SAS (par exemple, contrôle des chemins de mise à jour). Un seul opérateur peut gérer plusieurs instances de SAS Viya dans le même cluster. Son approche basée sur les CRD s'intègre nativement avec les outils et les principes GitOps (voir Section 5) , permettant une gestion déclarative via Git.  
   • Inconvénients: L'opérateur lui-même nécessite des permissions RBAC étendues au niveau du cluster (cluster-wide, via un ClusterRoleBinding unique) pour fonctionner, même s'il ne gère qu'un seul namespace. La création initiale de la CR SASDeployment nécessite l'utilisation de l'outil sas-orchestration (voir ci-dessous) dans un conteneur Docker sur un hôte externe (jump host). L'opérateur SAS n'est pas (ou n'était pas au moment de certaines sources) un opérateur certifié disponible via OperatorHub ou Red Hat Marketplace.  
   • Pertinence CI/CD: Très élevée. L'approche déclarative via CRD est idéale pour l'automatisation via CI/CD et l'intégration GitOps. Le pipeline CI/CD se concentre sur la gestion et l'application de la CR SASDeployment.
3. Commandes sas-orchestration:
   • Description: Introduite avec la version Stable 2022.12 , cette méthode utilise la même image Docker sas-orchestration que l'opérateur, mais invoque la commande deploy directement depuis un hôte externe (jump host ou agent CI/CD) au lieu de déployer un opérateur permanent dans le cluster. La commande sas-orchestration deploy prend en charge la récupération des assets, l'exécution de kustomize build et l'application du manifeste via kubectl apply.  
   • Avantages: Fournit un niveau d'automatisation similaire à l'opérateur pour les étapes de déploiement et de mise à jour. Évite la nécessité de déployer et de maintenir un opérateur avec des privilèges élevés dans le cluster. L'image Docker inclut des versions supportées de kubectl et Kustomize, garantissant la compatibilité. Intègre également la validation des politiques Viya. Peut être facilement intégrée dans des scripts et des pipelines CI/CD.  
   • Inconvénients: Nécessite l'installation et l'accès à Docker sur l'hôte qui exécute la commande. La commande elle-même requiert des privilèges élevés sur le cluster Kubernetes cible (similaires à cluster-admin) pendant son exécution. Contrairement à l'approche manuelle fine, elle n'offre pas la capacité intrinsèque d'appliquer les ressources Kubernetes par niveau de permission distinct (elle applique tout le manifeste généré). L'intégration GitOps est moins directe qu'avec l'opérateur, car il n'y a pas de CRD à surveiller ; l'outil doit être déclenché de manière impérative par le pipeline.  
   • Pertinence CI/CD: Élevée. C'est une alternative viable à l'opérateur pour l'automatisation via CI/CD, particulièrement si la présence d'un opérateur permanent avec des privilèges élevés est une préoccupation ou si une approche basée sur des commandes externes est préférée.
4. Projet GitHub viya4-deployment (Ansible / Deployment as Code - DaC):
   • Description: Ce projet, hébergé sur le GitHub de SAS , utilise des playbooks Ansible pour automatiser un spectre plus large du processus. Il peut préparer le cluster Kubernetes en déployant les prérequis (ingress-nginx, NFS provisioner, cert-manager, etc.), générer le manifeste Kustomize pour une commande SAS Viya (en appliquant des personnalisations communes via des variables Ansible), puis déployer Viya en utilisant soit la méthode de l'Operator, soit la méthode sas-orchestration. Il peut également déployer les outils de monitoring Viya.  
   • Avantages: Offre le plus haut niveau d'automatisation "out-of-the-box", couvrant l'infrastructure de base K8s, les prérequis Viya, et le déploiement Viya lui-même. Permet de gérer la configuration et les personnalisations de manière structurée via des variables Ansible et des overlays Kustomize placés dans site-config. Le code source Ansible est ouvert et peut être adapté aux besoins spécifiques. S'intègre avec les projets SAS IaC (Terraform) en lisant le fichier d'état tfstate pour découvrir automatiquement la configuration du cluster.  
   • Inconvénients: Cette méthode n'est pas conçue pour gérer les mises à jour de version de SAS Viya. Elle n'est pas supportée pour les déploiements sur Red Hat OpenShift. Elle introduit une dépendance à l'outil Ansible et à ses concepts.  
   • Pertinence CI/CD: Très élevée pour le déploiement initial complet (Infrastructure + Prérequis + Viya). Cependant, en raison de sa limitation sur les mises à jour, une stratégie CI/CD complète nécessitera de basculer vers l'utilisation directe de l'Operator ou de sas-orchestration pour les étapes ultérieures du cycle de vie (mises à jour).

Aller plus loin ?

Viya 4 - Les grandes étapes pour bien commencer