Dans ce nouvel article 100% orienté pratique, nous allons nous concentrer sur une étape fondamentale du déploiement de SAS Viya via l'Opérateur : la génération de la ressource personnalisée (Custom Resource) SASDeployment.
Si vos prérequis sont prêts, voyons en détail comment formuler et exécuter la commande create sas-deployment-cr pour générer votre fichier de configuration de manière optimale.
1. Avant de lancer la commande : Les points d'attention
Pour exécuter cette commande, vous devez être un administrateur disposant de permissionsRègles d'accès définissant les actions autorisées (Lire, Écrire, Supprimer, etc.) d'un utilisateur ou groupe sur un objet ou une donnée via le service d'autorisation de SAS Viya. locales sur le clusterEnsemble de nœuds (machines) interconnectés, gérés par Kubernetes, qui collaborent pour exécuter les microservices et le moteur CAS de SAS Viya, assurant haute disponibilité et passage à l'échelle..
⚠️ Attention aux permissionsRègles d'accès définissant les actions autorisées (Lire, Écrire, Supprimer, etc.) d'un utilisateur ou groupe sur un objet ou une donnée via le service d'autorisation de SAS Viya. : Le conteneur qui crée la ressource personnalisée s'exécute sous l'ID et le groupesas. Assurez-vous impérativement que le répertoire courant$(pwd)depuis lequel vous lancez la commande possède des permissionsRègles d'accès définissant les actions autorisées (Lire, Écrire, Supprimer, etc.) d'un utilisateur ou groupe sur un objet ou une donnée via le service d'autorisation de SAS Viya. permettant à cet ID/groupe d'y accéder.
Bonne pratique : Lancez toujours cette commande depuis le répertoire parent qui contient vos dossiers de licence ($license) et de déploiement ($deploy).
2. Format de base de la commande
La création de la ressource s'effectue via une commande Docker qui fait appel à l'image sas-orchestration. Le résultat est redirigé (via >) pour créer un fichier YAML. Par convention, on préfixe ce fichier avec le nom du répertoire de déploiement (par exemple, si votre dossier est viya1, le fichier sera viya1-sasdeployment.yaml).
Voici le format de base :
2
3
4
5
6
7
8
9
10
11
12
13
-v $(pwd):chemin-de-montage-dans-le-conteneur \
sas-orchestration \
create sas-deployment-cr \
--deployment-data infos-certificats \
--license infos-licence \
--user-content chemin-fichiers-deploiement \
--cadence-name stable-ou-lts \
--cadence-version numero-version-cadence \
--cadence-release numero-release-cadence \
[--image-registry url-registre-miroir \]
[--repository-warehouse url-warehouse \]
> $deploy-sasdeployment.yaml
(Astuce : Vous pouvez utiliser la commande docker run --rm sas-orchestration create sas-deployment-cr --help pour lister tous les flags disponibles).
3. Décryptage des paramètres
Pour que votre fichier généré soit correct, voici comment renseigner chaque paramètre :
-v $(pwd):chemin...: Définit le point de montage du répertoire de travail courant à l'intérieur du conteneur.--deployment-data: L'emplacement de votre fichier*-certs.zip. Vous pouvez cibler un fichier local ou une URL HTTP.--license: L'emplacement de votre licence JWT (fichier local ou URL HTTP).--user-content: L'emplacement de votre répertoire$deploy.- Si vous utilisez Git, l'URL doit suivre le protocole go-getter :
git::http(s). - Dépôt privé :
git::https://utilisateur:token-acces@chemin-projet-git//nom-dossier - Dépôt public :
git::https://chemin-projet-git//nom-dossier - Note : N'utilisez pas de format go-getter pour cibler des fichiers locaux.
--cadence-name: Indiquezstable(pour la cadence Stable) oults(pour Long-Term Support).--cadence-version: La version logicielle ciblée (ex:2021.1).--cadence-release: La release de la cadence.- Important : Si vous mettez la valeur
""(chaîne vide), l'opérateur utilisera toujours la dernière release disponible pour cette version. Revers de la médaille : une action bénigne comme renouveler une licence pourrait déclencher une mise à jour logicielle non désirée. - Fixer une release précise permet de modifier la configuration sans introduire de mises à jour.
--image-registry(Optionnel) : L'URL de votre registre Docker (ex:registry.example.com). Requis si vous déployez avec un miroir. (Note OpenShiftOpenShift est la plateforme Kubernetes d'entreprise de Red Hat conçue pour orchestrer, sécuriser et gérer le cycle de vie des applications conteneurisées.
Pour SAS Viya 4, OpenShift agit comme la fondation "Cloud Native" indispensable : il automatise le déploiement des microservices SAS, garantit la haute disponibilité des calculs analytiques et permet une portabilité totale entre le cloud public (Azure, AWS, GCP) et les infrastructures sur site. : format attendunom-service.nom-namespace-registre.svc:port/namespace-plateforme).--repository-warehouse(Optionnel) : Utilisé si vous gérez un environnement "dark" (isolé d'Internet).
Cohérence des données : Vérifiez le fichier$deploy/sas-bases/.orchestration/cadence.yaml. Les valeurs entrées pourcadence-name,versionetreleasedoivent correspondre exactement aux champsname,versionetreleasede ce fichier.
4. Exemples Pratiques
Cas n°1 : Déploiement classique avec fichiers locaux
Ici, nous montons notre répertoire courant dans /cwd/ et pointons vers des fichiers locaux pour une version LTS 2021.1, en forçant la dernière release avec "".
La commande :
2
3
4
5
6
7
8
9
10
11
-v $(pwd):/cwd/ \
sas-orchestration \
create sas-deployment-cr \
--deployment-data /cwd/license/SASViyaV4_69SWC4_certs.zip \
--license /cwd/license/SASViyaV4_69SWC4_lts_2021_license_2020-09-08T105930.jwt \
--user-content /cwd/viya1 \
--cadence-name lts \
--cadence-version 2021.1 \
--cadence-release "" \
> viya1-sasdeployment.yaml
Extrait du YAML généré : Notez que le contenu de votre fichier kustomization.yaml de base est directement retranscrit dans la ressource :
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
kind: SASDeployment
metadata:
name: sas-viya
spec:
cadenceName: lts
cadenceVersion: "2021.1"
cadenceRelease: "20200415.1748670418526"
license:
secretKeyRef:
name: sas-viya
key: license
# [...] Certificats omis
userContent:
files:
kustomization.yaml: |
resources:
- sas-bases/base
- sas-bases/overlays/cert-manager-issuer
Cas n°2 : Utilisation d'URL HTTPS et d'un dépôt Git
Dans cet exemple, la licence et les certificats sont hébergés sur un serveur, et le contenu utilisateur est sur un Git privé.
Annotation Git Requise : Lors d'un "fetch" depuis Git, le contenu doit être cloné localement par l'opérateur. La ressource générée doit donc inclure l'annotation environment.orchestration.sas.com/readOnlyRootFilesystem: "false" (généralement gérée automatiquement).La commande :
2
3
4
5
6
7
8
9
10
11
-v $(pwd):/cwd/deploy \
sas-orchestration \
create sas-deployment-cr \
--deployment-data https://example.com/SASViyaV4_69SWC4_certs.zip \
--license https://example.com/SASViyaV4_69SWC4_lts_2021_license_2020-09-08T105930.jwt \
--user-content git::https://user:token@git.example.com/repository.git//viya1 \
--cadence-name lts \
--cadence-version 2020.1 \
--cadence-release "" \
> viya1-sasdeployment.yaml
Extrait du YAML généré : Cette fois, la ressource utilise la syntaxe url plutôt que secretKeyRef ou files :
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
kind: SASDeployment
metadata:
annotations:
environment.orchestration.sas.com/readOnlyRootFilesystem: "false"
creationTimestamp: null
name: sas-viya
spec:
caCertificate:
url: https://example.com/SAS_CA_Certificate.pem
cadenceName: lts
cadenceVersion: "2020.1"
cadenceRelease: "20200415.1748670418526"
clientCertificate:
url: https://example.com/entitlement_certificate.pem
license:
url: https://example.com/SASViyaV4_69SWC4_lts_2021_license_2020-09-08T105930.jwt
repositoryWarehouse: {}
userContent:
url: git::https://user:token@git.example.com/repository.git//viya1
Il ne vous reste plus qu'à appliquer (kubectl apply -f) cette ressource fraîchement créée dans votre clusterEnsemble de nœuds (machines) interconnectés, gérés par Kubernetes, qui collaborent pour exécuter les microservices et le moteur CAS de SAS Viya, assurant haute disponibilité et passage à l'échelle. pour que l'Opérateur SAS Viya prenne le relais !
