Déployer l'Opérateur de Déploiement SAS Viya Platform

L'Opérateur de Déploiement SAS Viya Platform (SAS Viya Platform Deployment Operator) est un outil puissant qui simplifie et automatise le déploiement et la mise à jour de vos environnements SAS Viya sur Kubernetes. Il surveille activement les ressources personnalisées (Custom Resources ou CRs) de type SASDeployment et s'assure que votre déploiement SAS Viya correspond à l'état désiré défini dans ces CRs.

Cet article vous guidera à travers les étapes nécessaires pour déployer cet opérateur sur votre cluster Kubernetes.

Comprendre les Modes de l'Opérateur

Avant de commencer, il est important de connaître les deux modes de fonctionnement de l'opérateur :

Mode Espace de Noms (Namespace Mode) : L'opérateur est déployé dans le même espace de noms (namespace) que votre déploiement SAS Viya. Il ne gère que les déploiements SAS Viya dans cet espace de noms spécifique.
Mode Cluster-Wide : L'opérateur est déployé dans son propre espace de noms dédié et peut gérer les déploiements SAS Viya dans tous les espaces de noms du cluster.

SAS recommande de n'utiliser qu'un seul mode d'opérateur par cluster pour éviter toute confusion. Même si vous choisissez le mode Espace de Noms, l'opérateur aura besoin de certaines permissions à l'échelle du cluster, comme nous le verrons plus loin.

Prérequis

Accès à un cluster Kubernetes avec kubectl configuré.
Un espace de noms Kubernetes créé :
- Pour le mode Cluster-Wide : Un espace de noms dédié à l'opérateur (ex: sasoperator).
- Pour le mode Espace de Noms : L'espace de noms où vous déploierez SAS Viya (qui hébergera aussi l'opérateur).
(Optionnel) Si vous utilisez un registre miroir : SAS Mirror Manager doit être installé.

Étape 1 : Récupérer les Fichiers Requis

Les fichiers nécessaires (appelés "deployment assets") sont fournis via un fichier TGZ téléchargeable depuis votre portail my.sas.com.

Créez un Répertoire de Travail : Sur votre machine kubectl (ou une machine accessible), créez un répertoire dédié. SAS recommande operator-deploy. Ce répertoire est désigné par $operator-deploy dans la suite. operator-deploy cd operator-deploy Note : Si vous avez un registre miroir et un répertoire $deploy, créez $operator-deploy au même niveau.
Téléchargez les Fichiers :
- Connectez-vous à my.sas.com via le lien "Get Started" de votre email de commande (SOE).
- Vérifiez que vous travaillez avec la bonne commande et la bonne version de SAS Viya. Si vous mettez à jour vers une nouvelle version en adoptant l'opérateur, téléchargez les assets de la version cible.
- Dans l'onglet "Downloads", sélectionnez "Deployment Assets" et téléchargez le fichier TGZ.
- Sauvegardez le fichier TGZ dans le répertoire $operator-deploy.
Extrayez les Fichiers : tar xvfz nom-du-fichier.tgz Cela crée une structure de répertoires sas-bases/.
Copiez et Préparez les Fichiers de l'Opérateur : Copiez les fichiers spécifiques à l'opérateur depuis sas-bases vers la racine de $operator-deploy et rendez les fichiers de configuration modifiables.

Assurez-vous d'être dans $operator-deploy

cd $operator-deploy

Copiez les fichiers de l'exemple de déploiement de l'opérateur

cp -r sas-bases/examples/deployment-operator/deploy/* .

Rendez le fichier transformer.yaml modifiable

chmod +w site-config/transformer.yaml

Si vous déployez en mode Cluster-Wide OU sur un cluster sans support seccomp (ex: OpenShift),

rendez aussi le kustomization.yaml principal modifiable :

chmod +w site-config/transformer.yaml kustomization.yaml

Étape 2 : Modifier le Fichier transformer.yaml (Point Crucial)

Le fichier $operator-deploy/site-config/transformer.yaml est essentiel car il adapte la configuration de l'opérateur à votre environnement spécifique. Vous devez y définir deux informations clés.YAML

Explication Détaillée :

Première Modification (path: /metadata/name) : Le Nom du ClusterRoleBinding
- Qu'est-ce qu'un ClusterRoleBinding ? C'est une ressource Kubernetes qui accorde des permissions (définies dans un ClusterRole) à un utilisateur, un groupe ou un ServiceAccount (l'identité sous laquelle l'opérateur s'exécute) à travers l'ensemble du cluster.
- Pourquoi l'opérateur en a-t-il besoin ? Même si l'opérateur fonctionne en mode "Espace de Noms", le déploiement de SAS Viya lui-même implique la création de ressources qui ont une portée cluster (par exemple, des CustomResourceDefinitions, des ClusterRoles pour certains services SAS, etc.). L'opérateur doit donc avoir les permissions nécessaires pour gérer ces ressources à l'échelle du cluster.
- Pourquoi un nom unique (value: "sasoperator") ? Comme le ClusterRoleBinding est une ressource de niveau cluster, son nom doit être absolument unique au sein de votre cluster Kubernetes. Si vous prévoyez (même si ce n'est pas recommandé) d'avoir plusieurs instances de l'opérateur dans le même cluster (par exemple, gérant différentes versions de Viya ou pour des environnements distincts), chaque instance doit avoir un ClusterRoleBinding avec un nom différent pour éviter les conflits. Choisissez un nom descriptif et unique, comme sas-viya-prod-operator-binding ou operateur-sas-finance. L'exemple utilise sasoperator.
Deuxième Modification (path: /subjects/0/namespace) : L'Espace de Noms de l'Opérateur
- À quoi sert cette valeur ? Elle spécifie l'espace de noms (namespace) dans lequel l'opérateur lui-même sera déployé. C'est aussi là que seront créées les ressources associées à l'opérateur, notamment son ServiceAccount (son identité dans le cluster).
- Quelle valeur mettre (value: "sasoperator") ? Vous devez indiquer ici le nom exact de l'espace de noms que vous avez créé pour l'opérateur. Si vous êtes en mode Cluster-Wide, ce sera l'espace de noms dédié (ex: sasoperator). Si vous êtes en mode Espace de Noms, ce sera l'espace de noms où SAS Viya sera également déployé (ex: viya-prod). L'exemple utilise sasoperator.

La documentation mentionne la nécessité d'un ClusterRoleBinding unique pour chaque instance de l'opérateur SAS Viya Platform Deployment, mais elle se concentre sur la manière de personnaliser son nom et le namespace via des patches kustomize, plutôt que sur sa création initiale ou le ClusterRole sous-jacent.

Voici comment cela fonctionne généralement et comment aborder votre question :

Le ClusterRole est fourni par SAS : Vous n'avez normalement pas besoin de créer le ClusterRole vous-même. SAS fournit la définition du ClusterRole nécessaire dans le cadre des manifestes de déploiement de l'opérateur (souvent dans les répertoires base ou resources utilisés par kustomize). Ce ClusterRole contient toutes les permissions étendues requises par l'opérateur pour gérer les ressources Kubernetes au niveau du cluster (même s'il est déployé dans un namespace spécifique), comme la création de CustomResourceDefinitions (CRDs), de Namespaces (si configuré), de Roles, RoleBindings, etc., nécessaires au déploiement de SAS Viya.
- Nom typique : Le nom de ce ClusterRole est souvent quelque chose comme sas-deployment-operator-role ou un nom similaire défini par SAS dans ses fichiers de déploiement. Vous le trouverez référencé dans la définition de base du ClusterRoleBinding fournie par SAS.
Le ServiceAccount est créé pour l'opérateur : Lorsque vous déployez l'opérateur dans un namespace donné, un ServiceAccount est créé pour lui (par exemple, sas-deployment-operator). C'est cette identité (ServiceAccount) qui a besoin des permissions définies dans le ClusterRole.
Le ClusterRoleBinding lie les deux : Le ClusterRoleBinding est la ressource Kubernetes qui accorde les permissions définies dans le ClusterRole (fourni par SAS) au ServiceAccount de l'opérateur.
- Définition de base : SAS fournit également une définition de base de ce ClusterRoleBinding dans ses manifestes. Cette définition de base spécifie déjà :
  - Quel ClusterRole utiliser (via roleRef).
  - Quel type d'entité (ServiceAccount) cibler (via subjects).
  - Le nom par défaut du ServiceAccount (souvent sas-deployment-operator).

En résumé pour transformer.yaml : Vous fournissez un nom unique à l'échelle du cluster pour les permissions de l'opérateur et vous indiquez dans quel espace de noms l'opérateur doit être installé.

Étape 3 : Modifier kustomization.yaml pour le Mode Cluster-Wide (Si applicable)

Si vous déployez l'opérateur en mode Espace de Noms, sautez cette étape.

Si vous utilisez le mode Cluster-Wide, ouvrez le fichier kustomization.yaml à la racine de $operator-deploy et décommentez la ligne qui inclut site-config/cluster-wide-transformer.yaml :YAML

Étape 4 : Modifier kustomization.yaml pour seccomp (Si applicable)

Si votre cluster Kubernetes ne supporte pas le mode seccomp (Secure Computing Mode), ce qui est souvent le cas pour Red Hat OpenShift, vous devez l'indiquer.

Ouvrez le fichier kustomization.yaml (à la racine de $operator-deploy) et décommentez la ligne qui inclut site-config/remove-seccomp-transformer.yaml :YAML

Étape 5 : Configurer le Registre Miroir (Optionnel)

Si vous n'utilisez pas de registre miroir, sautez cette étape. Je vous invite également à lire mon article Comprendre le Registry Flattened dans SAS Viya

Copiez le Fichier de Configuration Miroir :
- Copiez mirror.yaml (pour la plupart des registres) ou mirror-flattened.yaml (pour OpenShift Container Registry) depuis $deploy/sas-bases/examples/mirror/ vers $operator-deploy/site-config/.
Modifiez le Fichier Copié :
- Pour mirror.yaml: Remplacez chaque {{ MIRROR-HOST }} par l'adresse complète de votre registre miroir, suivie du namespace du registre et de sasdeployment. Format : FQDN/registry-namespace/sasdeployment (ex: monregistre.entreprise.com/sas-images/sasdeployment).
- Pour mirror-flattened.yaml (OpenShift) :
  - Trouvez le nom de service et le port du registre interne : oc get svc -n <namespace-du-registre-openshift> (souvent openshift-image-registry). Notez le nom (ex: image-registry) et le port (ex: 5000).
  - Remplacez chaque {{ MIRROR-HOST }} par la route interne du registre suivie du nom de l'espace de noms où SAS Viya sera déployé. Format : nom-service.namespace-registre.svc:port/namespace-viya (ex: image-registry.openshift-image-registry.svc:5000/viya-prod).
Ajoutez le Fichier à kustomization.yaml : Dans le fichier kustomization.yaml principal ($operator-deploy/kustomization.yaml), ajoutez le chemin vers votre fichier miroir (mirror.yaml ou mirror-flattened.yaml) dans la section transformers.

Étape 6 : Ajouter un imagePullSecret (Optionnel)

Si votre registre miroir nécessite une authentification pour tirer les images SAS, vous devez configurer un imagePullSecret. Sinon, sautez cette étape.

Méthode Générale :
1. Créez un secret de type kubernetes.io/dockerconfigjson contenant vos identifiants pour le registre miroir (voir la documentation Kubernetes "Pull an Image from a Private Registry").
2. Modifiez le fichier $operator-deploy/kustomization.yaml pour générer ce secret et l'ajouter au déploiement de l'opérateur :

Étape 7 : Configurer les Informations Proxy (Optionnel)

Si votre cluster nécessite un proxy sortant (forward proxy) pour accéder à Internet (par exemple, pour télécharger des outils ou contacter SAS), et que vous souhaitez configurer ce proxy globalement pour l'opérateur, modifiez $operator-deploy/operator-base/deployment.yaml.

Repérez la section env: sous containers: et ajoutez les variables d'environnement HTTP_PROXY, HTTPS_PROXY, et NO_PROXY.YAML

Important pour NO_PROXY : Incluez toujours kubernetes.default.svc, l'adresse IP ou le nom d'hôte de l'API Server Kubernetes de votre cluster, ainsi que les domaines internes et les adresses IP qui ne doivent pas passer par le proxy.

Alternative : Vous pouvez configurer le proxy spécifiquement pour chaque déploiement SAS Viya via la ressource personnalisée SASDeployment, plutôt que globalement pour l'opérateur.

Étape 8 : Appliquer les Ressources de l'Opérateur au Cluster

Une fois toutes les configurations effectuées, placez-vous dans le répertoire $operator-deploy et exécutez la commande suivante pour construire la configuration finale avec Kustomize et l'appliquer à votre cluster :

kustomize build . | kubectl -n  apply -f -

Cette commande :

kustomize build . : Lit le kustomization.yaml et tous les fichiers référencés pour générer les manifestes Kubernetes finaux.
| : Envoie (pipe) la sortie (les manifestes YAML) à la commande suivante.
kubectl -n <namespace-operateur> apply -f - : Applique les manifestes reçus (-f -) dans l'espace de noms spécifié (-n <namespace-operateur>) de votre cluster.

Conclusion

Après l'exécution de cette dernière commande, le SAS Viya Platform Deployment Operator sera déployé et commencera à s'exécuter dans l'espace de noms spécifié. Il est maintenant prêt à surveiller et à gérer les ressources personnalisées SASDeployment que vous créerez pour déployer ou mettre à jour vos environnements SAS Viya Platform. N'oubliez pas que la configuration correcte du fichier transformer.yaml, notamment le nom unique du ClusterRoleBinding et l'espace de noms cible, est cruciale pour un déploiement réussi.