Conditions préalables au déploiement HCL Commerce sur un cluster Kubernetes

Il existe, en termes de configuration des logiciels, de l'environnement et du déploiement, plusieurs conditions préalables au déploiement de HCL Commerce sur Kubernetes. HCL Commerce offre une grande flexibilité et chaque option disponible devrait être prise en compte pour sa viabilité dans le déploiement de production qui en résulte.

Le mode de configuration par défaut utilisé par la charte Helm fournie est le mode de configuration Vault. Vault est également le mode de configuration recommandé pour HCL Commerce, car il est conçu pour stocker les données de configuration en toute sécurité. HCL Commerce utilise également Vault comme autorité de certification pour délivrer des certificats à chaque application pour leur permettre de communiquer les unes avec les autres en toute sécurité.

Pour les environnements hors production, vous pouvez envisager l'utilisation de la charte Helm hcl-commerce-vaultconsul-helmchart pour déployer et initialiser Vault pour HCL Commerce. Toutefois, cette charte exécute Vault en mode développement, et non en mode haute disponibilité (HA). Elle ne gère pas non plus le jeton Vault de manière sécurisée. Par conséquent, elle ne doit pas être utilisée pour les environnements de production. Voir concepts Vault dans la documentation Vault pour accéder à davantage de considérations à prendre en compte pour exécuter Vault dans un cadre de production.

Procedure

Procurez-vous les chartes Helm HCL Commerce.

A partir de HCL Commerce 9.1.7.0, une version Power Linux du Chart Helm est incluse pour une utilisation sur cette plateforme. Assurez-vous que vous utilisez la bonne version du Chart Helm pour la plateforme vers laquelle vous effectuez le déploiement.
1. Examinez Téléchargement du logiciel HCL Commerce et la liste des derniers packages de téléchargement disponibles pour vous assurer que vous obtenez la version la plus récente du logiciel HCL Commerce.
2. Téléchargez et extrayez la dernière version du groupement Git de la charte HCL Commerce Helm (HCL_Commerce_Helm_Charts_9.1.x.x.bundle).
3. Clonez le référentiel.
```
git clone bundleNameprojectName
```
  Où :
  bundleName
  Nom de fichier du groupement que vous clonez.
  projectName
  Nom du projet git que vous créez.
  Par exemple :
```
git clone HCL_Commerce_Helm_Charts_9.1.x.x.bundleHCL_Commerce_Helm_charts
```
Vault est un composant obligatoire utilisé par défaut en tant qu'agent de certification aux fins de l'émission automatique de certificats.
Il est également utilisé comme centre de configuration pour le déploiement afin de stocker des données liées à l'environnement. Pour plus d'informations et d'instructions sur le déploiement de Vault pour une utilisation avec HCL Commerce, voirDéploiement d'un Vault de développement pour HCL Commerce sur Kubernetes.
Note: Consul et toutes les configurations associées ont été supprimés de HCL Commerce versions 9.1.9.0 et ultérieures. Toutefois, le nom de fichier de la charte Helm de Vault fournie reste le même.

Vous avez besoin d'un cluster Kubernetes pour déployer HCL Commerce.

Il est recommandé d'utiliser Kubernetes 1.25 à 1.27 .

Il peut être sur un cloud privé ou public, ou même sur un cluster Kubernetes configuré avec kubeadm. Pour plus d'informations sur l'utilisation de kubeadm, voir Création d'un cluster maître unique avec kubeadm.

Par défaut, lorsque vous utilisez la charte Helm fournie pour déployer HCL Commerce Version 9, vous commencez par le nombre de pods et les ressources requises :


Component	Réplique	CPU requête	CPU limite	Mémoire requête	Mémoire limite
ts-app	1	500m	2	4096Mi	5120Mi
ts-db	1	2000m	2	4096Mi	6144Mi
ts-web	1	500m	2	2048Mi	4096Mi
search-app-master	1	500m	2	2048Mi	4096Mi
search-app-repeater (live)	1	500m	2	2048Mi	4096Mi
search-app-slave (live)	1	500m	2	2048Mi	4096Mi
crs-app	1	500m	2	2048Mi	4096Mi
xc-app	1	500m	2	2048Mi	4096Mi
tooling-web	1	500m	2	1024Mi	2048Mi
store-web	1	500m	2	1024Mi	2048Mi
nifi-app	1	500m	2	6144Mi	10240Mi
registry-app	1	500m	2	1024Mi	2048Mi
ingest-app	1	500m	2	2048Mi	4096Mi
query-app	1	500m	2	2048Mi	4096Mi
mustgather-app	1	500m	1	2048Mi	4096Mi
ts-utils	1	500m	2	2048Mi	4096Mi
graphql-app	1	500m	2	2048Mi	2048Mi
approval-app	1	500m	2	2048Mi	2048Mi
nextjs-app	1	500m	2	2048Mi	2048Mi

Assurez-vous que votre cluster dispose de ressources suffisantes pour votre déploiement. Les exigences décrites ci-dessous ne sont qu'une estimation. Elles sont basées sur un déploiement complet de l'environnement (groupes auth, live et shared) avec une seule instance (jeu de répliques) pour chaque application. Ces chiffres incluent également les 10 VCPU et 12 Go d'exigence de temps d'utilisation de la mémoire utilisés dans un scénario de mise à niveau continue. Lors d'une mise à niveau, plusieurs instances d'une application peuvent être actives en même temps.

Les ressources attendues requises sont basées sur la solution de recherche utilisée dans le déploiement :


Solution de recherche	vCPU	Mémoire
Solution de recherche basée sur Solr	40	68 Go
Solution de recherche basée sur Elasticsearch	49	84 Go

Note:

La fonction NLP (Natural Language Processing) Elasticsearch peut consommer de grandes quantités de mémoire dans NiFi avec plusieurs langues activées. Par exemple, avec deux langues activées, Nifi peut utiliser jusqu'à 10 Go de mémoire. Assurez-vous que la mémoire adéquate est allouée à Nifi pour vos besoins de déploiement.
Pour une répartition détaillée des exigences de ressources Kubernetes minimales suggérées pour diverses topologies de déploiement, HCL Commerce Planification des ressources de déploiement Kubernetes voir.

Vous avez besoin d'un contrôleur d'accès pour accéder à HCL Commerce après son déploiement sur Kubernetes.
La charte Helm HCL Commerce prend principalement en charge l'utilisation du contrôleur Nginx Ingress. Pour configurer le contrôleur Ingress Nginx sur votre cluster Kubernetes, voir le guide d'installation dans la documentation Nginx Ingress.
Une prise en charge supplémentaire du contrôleur Ingress est disponible dans la charte Helm HCL Commerce, avec des restrictions en fonction de votre déploiement et de la version de HCL Commerce utilisée :
- La prise en charge de l'utilisation de GCE Ingress lors du déploiement de HCL Commerce sur Google Kubernetes Engine (GKE) est disponible.
- Ambassador Edge Stack Ingress est pris en charge avec une version de Kubernetes inférieure à la 1.22.
  Restriction: Avec Kubernetes 1.22 ou version ultérieure, Ambassador Ingress n'est pas pris en charge. Au lieu de cela, Emissary est requis. Le contrôleur Emissary Ingress requiert également une version de HCL Commerce 9.1.12.0 ou supérieure.
- Prise en charge des routes Red Hat OpenShift.
- Prise en charge de Emissary 2.x (Emissary-ingress).
Helm est nécessaire pour gérer l'application sur Kubernetes.
Il est recommandé d'utiliser Helm version 3.10 ou supérieure. Pour télécharger et configurer Helm, rendez-vous sur https://github.com/helm/helm/releases.
Un jeton Vault doit être stocké en tant qu'objet secret.
Cette valeur est également placée dans vos valeurs de charte Helm pour permettre à l'application HCL Commerce de consommer la valeur de jeton Vault. Si vous utilisez hcl-commerce-vaultconsul-helmchart pour déployer le coffre pour le développement ou une utilisation hors production, un secret nommé vault-token-secret aurait dû être créé déjà dans l'espace de noms commerce à l'étape 2.d de Déploiement d'un Vault de développement pour HCL Commerce sur Kubernetes. Sinon, effectuez les étapes suivantes pour créer un nouveau secret et l'importer dans votre environnement.
1. Obtenez la chaîne codée base64 de votre jeton de coffre en le transmettant via l'utilitaire système base64. Dans une invite de commande, exécutez echo -n vault_token | base64 :
2. Créez un fichier nommé vault-secret.yaml avec le contenu suivant. Remplacez <VAULT_TOKEN> par la valeur obtenue et <NAME_SPACE> par commerce. Sauvegardez le fichier.
```
apiVersion: v1 kind: Secret metadata: name: vault-token-secret namespace: <NAME_SPACE> type: Opaque data: VAULT_TOKEN: <VAULT_TOKEN>
```
3. Exécutez kubectl apply -f vault-secret.yaml pour créer le secret dans l'espace de nom commerce.
Toutes les images Docker requises pour le déploiement HCL Commerce doivent être chargées dans un registre Docker auquel votre cluster Kubernetes peut accéder.

Vous pouvez obtenir HCL Commerce à partir de HCL License and Delivery portal. Pour obtenir des informations à jour sur les versions, voir HCL Commerce eAssemblies.

Les balises utilisées dans votre registre Docker doivent être identiques à celles utilisées dans vos chartes Helm.
Une ou plusieurs bases de données sont requises.
A des fins de test rapide ou exploratoires, vous pouvez utiliser l'exemple d'image Docker de base de données DB2 HCL Commerce, dans laquelle le schéma par défaut et l'exemple de données d'amorçage sont chargés, pour explorer les fonctionnalités HCL Commerce. Toutefois, il est fortement recommandé de configurer votre base de données sur son propre serveur dédié afin que vous puissiez persister les données et régler les performances. Les exigences de taille de base de données varient en fonction du fournisseur et de la configuration. Pour plus d'informations sur les exigences d'un environnement de production Conditions préalables à l'installation d'un environnement de production HCL Commerce, voir HCL Commerce.
Avec l'introduction du service d'approbation pour une utilisation dans une place de marché, une base de données PostgreSQL doit également être déployée.
Le contrôle d'accès basé sur les rôles (RBAC) doit être créé à l'avance et une seule fois sur l'espace de noms cible.
Les étapes restantes de ce déploiement supposent que HCL Commerce est déployé sur l'espace de noms commerce. Effectuez les étapes suivantes en tant qu'administrateur de cluster.
1. Si vous n'avez pas déjà créé l'espace de noms commerce, par exemple dans les prérequis de Déploiement d'un Vault de développement pour HCL Commerce sur Kubernetes, créez-le maintenant en exécutant la commande suivante : kubectl create namespace commerce.
  Note: Les étapes suivantes, 9.b et 9.c, peuvent être ignorées à partir de HCL Commerce 9.1.7.0. En effet, à partir de ce point, la charte Helm HCL Commerce crée automatiquement les règles RBAC lors du déploiement.
2. Modifiez le fichier rbac.yaml en remplaçant <namespace> par commerce.
3. Exécutez la commande suivante pour appliquer le RBAC : kubectl apply -f rbac.yaml.
Important: Certaines plates-formes Cloud, telles qu'IBM Cloud, nécessitent une PodSecurityPolicy (PSP) pour être liée à l'espace de noms cible avant l'installation. Choisissez une PSP prédéfinie ou faites configurer une PSP personnalisée par votre administrateur de clusters. Pour IBM Cloud, choisissez ibm-privileged-psp pour la stratégie la moins restrictive, ou reportez-vous aux définitions de politique PodSecurityPolicy IBM Cloud Pak pour en savoir plus.
L'administrateur de cluster peut utiliser les définitions PSP et ClusterRole ci-dessus dans l'écran de création de ressources de l'interface utilisateur, ou exécuter les deux commandes suivantes :
- kubectl create -f <PSP_yaml_file>
- kubectl create clusterrole commerce-psp-clusterrole --verb=use --resource=podsecuritypolicy --resource-name=commerce-psp
Dans IBM Cloud Private 3.1, vous devez créer la commande RoleBinding en exécutant la commande suivante :
- kubectl create rolebinding commerce-psp-rolebinding --clusterrole=commerce-psp-clusterrole --serviceaccount=commerce:default --namespace=commerce
Dans IBM Cloud Private 3.1.1+, vous devez créer la commande RoleBinding en exécutant la commande suivante :
- kubectl create rolebinding ibm-psp-rolebinding --clusterrole=ibm-privileged-clusterrole --serviceaccount=commerce:default --namespace=commerce
Optional: Activez Assets tool.

Si vous souhaitez que l'outil Ressources soit utilisé dans votre déploiement, vous devez implémenter un stockage persistant accessible.

Pour implémenter un stockage persistant, voir Configuration de volumes de stockage persistants pour un déploiement Kubernetes.

Pour plus d'informations sur l'outil Ressources, voir Assets tool.
Optional: Désactivez l'analyse d'outils.
Management Center for HCL Commerce 9.1.12.0 et toutes les versions supérieures établissent désormais des rapports sur les données d'analyse des utilisateurs professionnels et les transmettent à HCL. Ces informations aident HCL à développer de nouvelles fonctionnalités et à améliorer les outils existants à usage des utilisateurs professionnels.
Pour désactiver l'analyse d'outils :
- Si vous utilisez Vault dans votre déploiement, définissez la valeur de clé allowTelemetry Vault sur no avant le déploiement.
- Définissez la variable d'environnement de conteneur Tooling Web Docker containerALLOW_TELEMETRY sur no lors du déploiement.

Results

Votre environnement est maintenant préparé. Vous pouvez à présent déployer HCL Commerce. Poursuivez avec Déploiement de HCL Commerce sur un cluster Kubernetes.