Configuration requise du chart Helm pour HCL Commerce Version 9.1
La référence suivante fournit un aperçu plus détaillé de la charte Helm hcl-commerce-helmchart fournie, ainsi que des différentes options et considérations de configuration qui sont essentielles pour un déploiement personnalisé de HCL Commerce Version 9.1 sur Kubernetes.
Il est fortement recommandé de ne pas modifier le fichier de configuration values.yaml par défaut pour votre déploiement. Créez plutôt une copie à utiliser comme fichier de valeurs personnalisées, par exemple my-values.yaml. Cela vous permettra de conserver vos valeurs personnalisées pour les futurs déploiements et mises à niveau.
- Configurations courantes
- Valeurs de configuration communes. Modifications requises pour tous les déploiements.
Configuration du travail d'index de recherche
Configuration d'Ingress
Volume persistant pour l'outil Ressources
Déploiement avec approbations
Déploiement avec le Nextjs Ruby store- Configuration de l'image Docker
- Allocation de ressources Kubernetes
- Données de recherche persistantes
- Configurations de Platform
- Configurations de journalisation et de surveillance
- Configurations d'intégration
- Configurations de migration et de mise à niveau
Valeurs de configuration communes
Les valeurs suivantes doivent être modifiées dans votre fichier my-values.yaml pour correspondre à l'environnement et à la configuration du cluster souhaités :
| Paramètre | Description |
|---|---|
| Licence | Vous devez accepter la licence avant de pouvoir déployer HCL Commerce. Pour afficher la licence, parcourez tous les fichiers sous le répertoire LICENSES. Pour accepter la licence, définissez license sur accept. |
|
|
| common.vaultTokenSecret | Nom de l'objet secret qui contient le jeton Vault. Se référer à Déploiement d'un Vault de développement pour HCL Commerce sur Kubernetes et Conditions préalables au déploiement HCL Commerce sur un cluster Kubernetes pour comprendre comment le jeton Vault est transmis à HCL Commerce. |
| common.dbType | Type de base de données utilisé par l'environnement. Les valeurs admises sont db2 et oracle. |
| common.imageRepo | Le référentiel Docker Registry au format docker_registry_domain:port. |
| common.spiUserName | Nom d'utilisateur SPI utilisé pour l'authentification de base avec la communication de serveur à serveur. spiuser est la valeur par défaut utilisée pour HCL Commerce. |
| common.spiUserPwdAes | Mot de passe de l'utilisateur spiuser, chiffré avec AES par l'utilitaire wc_encrypt . Le mot de passe en texte en clair par défaut est : Vous pouvez utiliser la clé par défaut pour correspondre à l'exemple de conteneur Docker de base de données db2.
Pour plus d'informations, voir Définition du mot de passe spiuser dans vos images Docker. |
| common.spiUserPwdBase64 | Valeur codée Base64 pour spiuser:password. Le mot de passe en texte en clair par défaut est :
Cette valeur peut être obtenue en canalisant les valeurs par l'intermédiaire de l'utilitaire système Base64 : |
| common.vaultUrl | URL de l'API Vault V1. La valeur par défaut est Note:
Cette valeur suppose que cela hcl-commerce-vaultconsul-helmchart a été utilisé pour déployer Vault dans l'espace de noms vault.
|
| common.externalDomain | Domaine externe utilisé pour Ingress et l'URL d'aperçu du magasin. Dans le nom d'hôte |
| common.configureMode | HCL Commerce prend en charge les modes de configuration Vault et EnvVariables. La valeur par défaut est Vault, qui est également le mode de configuration recommandé. |
| common.imagePullSecrets | Nom du nom secret qui contient les informations d'identification pour tirer des images de votre Docker Registry. Laissez cette valeur vide si le Docker Registry utilisé ne nécessite pas d'authentification. |
| common.imagePullPolicy | La stratégie pour contrôler quand extraire des images Docker. Les valeurs admises sont IfNotPresent et Always. |
| common.serviceAccountName | Le nom de compte de service qui se lie aux rôles nécessaires pour déployer HCL Commerce. Par défaut, cette valeur est default. |
| common.dataIngressEnabled |
Deprecated: Ce paramètre a été rendu obsolète et supprimé dans la version 9.1.7.0. |
| common.localStoreEnabled | Lors de la migration à partir de IBM Websphere Commerce Version 7 ou IBM Websphere Commerce Version 8, il est possible de déployer et d'héberger un magasin reposant sur la solution basée sur Aurora à partir de l'intérieur de Transaction server. Dans ce cas, définissez localStoreEnabled sur true pour permettre à Elasticsearch et Ingress d'être configuré correctement. Cela n'est pas activé par défaut, car la solution de magasin basée sur Aurora qui est incluse avec HCL Commerce Version 9 est distante par défaut. |
logging.jsonLogging.enabled
|
Paramètre permettant d'activer la journalisation JSON. Lorsque la valeur de ce paramètre est true, celui-ci active la journalisation JSON pour tous les serveurs d'applications. Les valeurs acceptées sont true, pour activer la journalisation et false pour désactiver la journalisation JSON. |
|
common.ipv6Enabled
|
Paramètre permettant d'activer IPV6. Lorsqu'elles sont désactivées, les applications HCL Commerce ajoutent le paramètre JVM |
|
common.timezone
|
Fuseau horaire au format ICANN TZ. Par exemple, America/Toronto.Ce paramètre peut également être défini dans tous les conteneurs HCL Commerce en tant que variable d'environnement, TZ. Si cette valeur n'est pas définie ou vide, Warning: La modification du fuseau horaire aura un impact sur la logique métier HCL Commerce, telle que les activités Web marketing et les dates et heures de début et de fin de promotion. Les valeurs définies pour ces comportements de site ne s'ajusteront pas automatiquement en fonction de ce paramètre de fuseau horaire. Il est recommandé de conserver cette valeur vide si votre site est déjà utilisé dans un environnement de production opérationnel. |
| vaultCA.enabled |
Paramètre permettant à Vault en tant qu'autorité de certification de délivrer des certificats. La valeur par défaut est true. |
|
IngressSecret est utilisé pour spécifier s'il faut générer automatiquement et remplacer le secret pour Ingress. La valeur par défaut de ces paramètres est true. |
HCL Cache et valeurs de configuration des métriques et du moniteur de service
| Paramètre | Description |
|---|---|
| metrics.enabled | Paramètre permettant d'activer les métriques pour HCL Commerce. La valeur par défaut de ce paramètre est true. |
| metrics.serviceMonitor.enabled | Paramètre permettant la surveillance du service avec Prometheus. La valeur par défaut de ce paramètre est false. |
Configuration du travail d'index de recherche
search-nifi et search-ingest, soient prêts, puis déclenche l'index de génération pour vos magasins spécifiés. Le travail surveille également le statut de la génération et attend qu'il se termine.| Paramètre | Description |
|---|---|
|
searchIndexCreation
|
Paramètre permettant d'activer une construction d'index de solution de recherche basée sur Elasticsearch lors du déploiement. Les valeurs acceptées sont true pour activer le travail de génération d'index ou false pour désactiver le travail de génération d'index. |
|
searchIndexCreation.pushToLiveEnabled
|
Paramètre permettant d'activer la partie du connecteur d'index push-to-live dans le travail de génération d'index. Les valeurs acceptées sont true pour activer le connecteur d'index push-to-live ou false pour désactiver le connecteur d'index push-to-live. |
|
searchIndexCreation.overalMaxDuration
|
Durée maximale, en secondes, pour que le travail se termine avant d'être annulé en raison du délai d'expiration. Cette valeur doit prendre en compte le nombre de magasins indexés, la taille du jeu de données et la complexité de la génération d'index de chaque magasin. Si la valeur n'est pas suffisamment définie avec une marge généreuse, le travail peut être involontairement annulé avant qu'il ne se soit correctement terminé. |
|
searchIndexCreation.indexMaxDuration
|
Durée maximale, en secondes, pendant laquelle chaque exécution d'index individuelle doit être annulée avant l'expiration du délai. |
|
searchIndexCreation.interval
|
Intervalle, en secondes, entre chaque vérification de préparation de chaque composant de recherche requis pour le travail de génération d'index. |
|
searchIndexCreation.txnMaxDuration
|
Durée maximale d'attente en secondes pour que le Transaction server soit prêt. |
|
searchIndexCreation.nifiMaxDuration
|
Durée maximale d'attente en secondes pour que l'application NiFi soit prête. |
|
searchIndexCreation.ingestMaxDuration
|
Durée maximale d'attente en secondes pour que l'application Ingest soit prête. |
|
searchIndexCreation.maxRetry
|
Nombre maximal de tentatives pour chaque exécution de génération d'index, en cas d'échec du travail de génération d'index. |
|
searchIndexCreation.storeIds
|
Liste d'ID de magasin, séparés par des virgules, par rapport à laquelle les générations d'index seront exécutées. |
|
searchIndexCreation.calculatePriceEnabled
|
Paramètre permettant d'activer le calcul des prix pour les magasins B2B. Les valeurs acceptées sont true pour activer le calcul des prix et false pour désactiver le calcul des prix. |
|
searchIndexCreation.calculatePriceStoreIds
|
Liste d'ID de magasin, séparés par des virgules, par rapport à laquelle le calcul des prix sera exécutée. |
Configuration de la journalisation
Par défaut, les applications HCL Commerce ne proposent pas de journalisation au format JSON, mais au format spécifié individuellement sur chaque serveur. Lors de l'agrégation de ces données dans un système de journalisation centralisé, tel qu'EFK, il est nécessaire d'activer le format de journalisation JSON.
| Paramètre | Description |
|---|---|
|
logging.jsonLogging.enabled
|
Paramètre permettant d'activer la journalisation JSON. Lorsque la valeur de ce paramètre est true, celui-ci active la journalisation JSON pour tous les serveurs d'applications. Les valeurs acceptées sont true, pour activer la journalisation et false pour désactiver la journalisation JSON. |
Configuration d'Ingress
Ingress est utilisé pour permettre un accès externe aux applications déployées dans un cluster Kubernetes. La charte Helm HCL Commerce définit Ingress, pour permettre l'accès aux services les plus couramment utilisés dans HCL Commerce, tels que Management Center for HCL Commerce et la vitrine. Pour chacun de ces services, vous pouvez configurer le domaine, ingressClass et tlsSecret pour les environnements de création et opérationnels. Vous pouvez utiliser les paramètres Ingress définis par la charte Helm HCL Commerce, ou les utiliser comme référence et définir votre propre Ingress personnalisé en fonction de vos besoins.
| Paramètre | Description |
|---|---|
|
ingress.enabled
|
Activez la création Ingress. Les valeurs acceptées sont true, pour activer Ingress et false pour désactiver Ingress. |
|
ingress.ingressController
|
Type de contrôleur Ingress. Valeurs admises :
Note:
|
|
ingress.emissaryIdsList
|
La liste d'ID Ambassador pour le programme d'écoute Emissary qui écoute sur les ports HTTP et HTTPS. Laissez cette valeur vide si vous utilisez uniquement l'ID Ambassador par défaut. Si vous utilisez différents ID Ambassador définis dans la configuration Ingress pour différents composants, vous devez les ajouter ici afin de créer des programmes d'écoute pour différents émissaires. |
|
ingress.apiVersion
|
Version d'API à utiliser pour Ingress.
|
|
ingress.enableToolingForReactStore
|
Paramètre permettant de spécifier si le service Ingress pour l'approbation de la place de marché est activé ou désactivé. |
|
OpenshiftDeployment.destinationCACertificate
|
Dans un déploiement de conteneur OpenShift, les ressources de routes seront créées directement au lieu d'Ingress. Spécifiez le certificat d'AC pour permettre au proxy HAProxy de faire confiance au certificat des serveurs HCL Commerce. Le certificat d'AC est celui que vous avez spécifié dans le déploiement de Vault. |
| ingressSecret.autoCreate | Le paramètre spécifie si vous avez besoin de la pré-installation Helm pour générer un secret de certification du contrôleur Ingress. C'est un moyen pratique de générer le certificat autosigné pour un environnement de test. |
| ingressSecret.replaceExist | Paramètre à spécifier si le secret de certification du contrôleur Ingress existant doit être remplacé lors du déploiement. |
|
ingress.enableManageApprovalPage
|
Paramètre permettant de spécifier si Ingress est activé pour la page Gérer l'approbation utilisée pour le service d'approbation de la place de marché. Valeurs admises : Il est désactivé (false) par défaut.
|
Volume persistant pour l'outil Ressources
L'outil Ressources a été réintroduit dans HCL Commerce version 9.1.8.0. Un volume persistant avec accès ReadWriteMany peut être créé pour stocker les actifs ajoutés et gérés via cet outil Management Center.
Pour plus d'informations sur l'outil Ressources, voir Assets tool.
Pour plus d'informations sur les volumes persistants dans Kubernetes, voir Volumes persistants dans la documentation de Kubernetes.
| Paramètre | Description |
|---|---|
|
assetsPVC.enabled
|
Créez un PersistentVolumeClaim (PVC) pour l'outil Ressources.
|
|
assetsPVC.storageClass
|
Nom de classe de stockage utilisé par le PVC pour l'outil Ressources. Ce fournisseur de ressources doit prendre en charge le mode d'accès ReadWriteMany. |
|
assetsPVC.storage
|
Taille de stockage affectée au volume persistant. |
|
assetsPVC.accessMode
|
Mode d'accès du PVC. Cette valeur doit être |
|
assetsPVC.existingClaim.auth
|
S'il existe déjà un PVC pour l'outil Ressources dans l'environnement de création, vous pouvez l'affecter avec ce paramètre. |
|
assetsPVC.existingClaim.live
|
S'il existe déjà un PVC pour l'outil Ressources dans l'environnement opérationnel, vous pouvez l'affecter avec ce paramètre. |
Intégration à HCL Digital Experience
auth et liveHCL Digital Experience (DX) existants qui sont déployés dans le même cluster que HCL Commerce.- L'entrée Nginx doit être utilisée pour déployer HCL Commerce. L'entrée GKE n'est pas prise en charge.
- Avec cette configuration, DX devient accessible avec le même nom de domaine que HCL Commerce.
| Paramètre | Description |
|---|---|
| dx.enabled | Paramètre permettant d'activer ou de désactiver les configurations DX. La valeur par défaut de ce paramètre est false. Cette configuration est ignorée si dx.namespace.auth et dx.namespace.live n'ont pas de valeurs. |
| dx.namespace.auth | L'espace de nom de l'environnement auth DX. Il doit se trouver dans le même cluster que Commerce. |
| dx.namespace.live | L'espace de nom de l'environnement live DX. Il doit se trouver dans le même cluster que Commerce. |
|
dx.serviceName.auth
|
Nom du service de routage DX auth (équilibreur de charge). Les valeurs acceptées sont haproxy ou ambassador selon la version de DX. Vous pouvez obtenir le nom du service avec kubectl get service. |
|
dx.serviceName.live
|
Nom du service de routage DX live (équilibreur de charge). Les valeurs acceptées sont haproxy ou ambassador selon la version de DX. Vous pouvez obtenir le nom du service avec kubectl get service. |
Intégration avec LDAP
A compter de HCL Commerce version 9.1.9.0, HCL Commerce peut être intégré à un certain nombre de services LDAP (Lightweight Directory Access Protocol) populaires ou à une implémentation LDAP personnalisée.
Les valeurs ici décrivent si l'intégration LDAP est activée, pour quel environnement, ainsi que la manière dont les détails de configuration LDAP sont fournis au déploiement pour chaque environnement. Les détails de configuration réels sont fournis séparément en fonction du mode de configuration sélectionné.
Pour plus d'informations, voir Intégration de déploiements Kubernetes HCL Commerce à LDAP.
| Paramètre | Description |
|---|---|
|
ldap.auth.enabled
|
Indique si LDAP est activé pour l'environnement de création. Valeurs admises :
Note: Par défaut, Vault est la méthode de configuration par défaut. Aucun paramètre n'est requis pour spécifier cette méthode de configuration LDAP. |
|
ldap.auth.useVmmPropertiesFile
|
Vous pouvez utiliser le fichier vmm.properties pour définir la configuration LDAP pour un déploiement Kubernetes en incluant une copie de celui-ci dans un Transaction server Docker container personnalisé. Pour utiliser cette méthode de configuration, définissez cette valeur sur true, puis suivez les instructions pour Intégration de déploiements Kubernetes HCL Commerce à LDAP. Valeurs admises :
|
|
ldap.auth.useConfigMapForVmmPropertiesFile
|
Vous pouvez utiliser le fichier de configuration ldap-vmm-auth.properties pour définir la configuration LDAP pour un déploiement Kubernetes. Pour utiliser cette méthode de configuration, définissez cette valeur sur true, puis suivez les instructions pour Intégration de déploiements Kubernetes HCL Commerce à LDAP. Valeurs admises :
|
|
ldap.live.enabled
|
Indique si LDAP est activé pour l'environnement opérationnel. Valeurs admises :
Note: Par défaut, Vault est la méthode de configuration par défaut. Aucun paramètre n'est requis pour spécifier cette méthode de configuration LDAP. |
|
ldap.live.useVmmPropertiesFile
|
Vous pouvez utiliser le fichier vmm.properties pour définir la configuration LDAP pour un déploiement Kubernetes en incluant une copie de celui-ci dans un Transaction server Docker container personnalisé. Pour utiliser cette méthode de configuration, définissez cette valeur sur true, puis suivez les instructions pour Intégration de déploiements Kubernetes HCL Commerce à LDAP. Valeurs admises :
|
|
ldap.live.useConfigMapForVmmPropertiesFile
|
Vous pouvez utiliser le fichier de configuration ldap-vmm-auth.properties pour définir la configuration LDAP pour un déploiement Kubernetes. Pour utiliser cette méthode de configuration, définissez cette valeur sur true, puis suivez les instructions pour Intégration de déploiements Kubernetes HCL Commerce à LDAP. Valeurs admises :
|
Déploiement sur Red Hat OpenShift
Le déploiement sur Red Hat OpenShift est possible avec les paramètres spécifiés dans cette section.
- Red Hat Plinux OpenShiftRestriction: La mise à niveau d"environnements basés sur Power vers des conteneurs non root n'est actuellement pas prise en charge. Les nouveaux déploiements sont pris en charge.
Red Hat Xlinux OpenShift
Par défaut, OpenshiftDeployment.enabled est réglé sur false.
| Paramètre | Description |
|---|---|
|
OpenshiftDeployment.enabled
|
Activez le déploiement sur Red Hat OpenShift. Les valeurs acceptées sont true et false. |
|
OpenshiftDeployment.SccName
|
Contraintes de contexte de sécurité (SCC) auxquelles vous souhaitez accorder l'accès pour le déploiement. |
|
OpenshiftDeployment.destinationCACertificate
|
Dans un déploiement de conteneur OpenShift, les ressources de routes seront créées directement au lieu d'Ingress. Spécifiez le certificat d'AC pour permettre au proxy HAProxy de faire confiance au certificat des serveurs HCL Commerce. Le certificat d'AC est celui que vous avez spécifié dans le déploiement de Vault. |
Déploiement avec Google Anthos
Le déploiement avec Google Anthos est possible avec les paramètres spécifiés dans cette section. Vous pouvez toujours utiliser HCL Commerce avec Google Anthos en mettant à jour manuellement la charte Helm.
Par défaut, AnthosDeployment.enabled est défini sur false.
| Paramètre | Description |
|---|---|
|
AnthosDeployment.enabled
|
Introduit dans HCL Commerce 9.1.11.0, Google Anthos est pris en charge par le chart Helm HCL Commerce. Activez cette fonctionnalité pour le déploiement lorsque Google Anthos est utilisé. Cela a pour effet de désactiver l'injection sidecar istio pour pre-install, pre-delete, create-index, nifi et ingest en vue d'éviter les échecs.
Note: Vous pouvez toujours utiliser des versions antérieures de HCL Commerce avec Google Anthos en mettant à jour manuellement la charte Helm HCL Commerce.
|
Déploiement avec approbations sur la place de marché
Le déploiement avec Approbations dans la place de marché est possible avec les paramètres spécifiés dans cette section.
| Paramètre | Description |
|---|---|
|
approvalApp.enabled
|
Introduit dans HCL Commerce 9.1.12.0, le service d'approbation est utilisé pour les approbations au sein d'un marché. L'application du service d'approbation nécessite un PostgresSQL déployé séparément qui doit être exécuté avant le démarrage du service. L'URL de la base de données PostgreSQL est transmise au service d'approbation à l'aide du chart Helm dans lequel figure une section bootConfig sous approvedApp.
|
Déploiement avec le Nextjs Ruby store
Le déploiement avec Ruby est possible avec les paramètres spécifiés dans cette section.
| Paramètre | Description |
|---|---|
|
nextjsApp.enabled
|
Introduit dans HCL Commerce version 9.1.13.0, le Nextjs Ruby store est un magasin type basé sur le framework Next.js qui active les applications Web basées sur React avec le rendu côté serveur et la génération de sites Web statiques. Pour plus d'informations, voir Magasin type Next.js.
|
Configuration de l'image Docker
Sous chaque définition d'application (c'est-à-dire les définitions de tsApp, tsWeb, etc.), le chemin de l'image est le chemin d'accès à l'image relativement à common.imageRepo, et la balise définit la balise d'image. Assurez-vous que chaque application dispose du chemin d'accès et de la balise d'image adéquats en fonction des images réelles stockées dans votre registre Docker.
Allocation de ressources Kubernetes
Sous chaque définition d'application (c'est-à-dire les définitions de tsApp, tsWeb, etc.), la valeur replica est définie sur 1 par défaut. Cela signifie qu'un seul Pod est déployé par application définie. Pour améliorer les performances et la puissance de traitement de votre déploiement, vous pouvez augmenter la valeur de la réplique pour certaines applications telles que tsApp. Vous pouvez également personnaliser l'allocation des ressources en modifiant la définition des ressources pour chaque application.
Données de recherche persistantes
Il est recommandé de monter des volumes de stockage persistants dans vos conteneurs de recherche pour permettre aux applications HCL Commerce de conserver des données. Si vous ne configurez pas de stockage persistant, l'index de recherche stocké dans le conteneur Docker sera perdu si le conteneur est arrêté ou redémarré pour une raison quelconque.
- Solution de recherche basée sur Solr :
searchAppMastersearchAppRepeater
- Solution de recherche basée sur Elasticsearch :
nifiAppelasticsearch
Pour monter un volume de stockage, créez un appel de volume persistant dans Kubernetes et faites-le correspondre à l'application correspondante. Répétez ce processus de création pour chaque application qui nécessite un stockage persistant.
- Créez un fichier yaml avec les définitions suivantes.
Aux fins de cet exemple, ce fichier s'appellera pvc.yaml.
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: <pvc name, e.g demoqa-nifi-pvc> namespace: <namespace, e.g commerce> spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi storageClassName: <storage class name, e.g standard for gke> - Créez l'appel de volume persistant basé sur la définition de votre fichier yaml.
Exécutez la commande suivante pour charger le fichier du groupe d'utilisateurs :
kubectl apply -f pvc.yaml.L'appel du volume persistant est créé.
- Faites correspondre l'application à son appel de volume persistant.
Configurez la valeur du paramètre de déploiement persistentVolumeClaim pour l'application et l'appariement persistant des appels de volume.
Migration de HCL Commerce de la version 9.0.x vers les versions 9.1+
- app (WCSV9)
- charte ({{ .Chart.Name }}, par exemple, ibm-websphere-commerce)
- version ({{ .Release.Name }}, par exemple, demo-qa-auth)
- héritage ({{ .Release.Service }}, par exemple, Helm)
- composant ({{ .Values.common.tenant }}{{ .Values.common.environmentName}}{{ .Values.common.environmentType }}{{.Values.xxApp.name}}, par exemple, demoqaauthcrs-app)
- groupe ({{ .Values.common.tenant }}{{ .Values.common.environmentName }}{{ .Values.common.environmentType }}, par exemple, demoqaauth )
Dans cet exemple de charte Helm, les valeurs de l'application et de la charte sont mises à jour. Cela entraînerait l'échec de la mise à niveau de Helm car le LabelSelector est immuable. Pour mettre à niveau un déploiement d'une version 9.0.x.x vers une version 9.1.x.x à l'aide de cette charte sans temps d'arrêt, spécifiez le sélecteur backwardCompatibility.selector pour correspondre au déploiement existant.
backwardCompatibility: selector: ## In the Version 9.0.x.x Helm Chart, app is specified as WCSV9 by default app: WCSV9 ## In the Version 9.0.x.x Helm Chart, chart is specified as ibm-websphere-commerce by default chart: ibm-websphere-commerce backwardCompatibility: selector: {} 
Mise à niveau de HCL Commerce des images root vers des images non root
Lors de la mise à niveau, pour la toute première fois, d'un déploiement existant de l'utilisateur root vers l'utilisateur non root comuser, vous devez passer en revue et prendre soigneusement en compte les paramètres de chart Helm suivants.
| Paramètre | Description |
|---|---|
|
Common.runAsNonRoot.enabled
|
Ce paramètre démarre tous les conteneurs en tant qu'utilisateur non root, comuser, pour améliorer la sécurité globale du déploiement.Valeurs admises :
Par défaut, cette valeur est définie sur Il est uniquement recommandé de désactiver cette fonctionnalité pour continuer d'utiliser un déploiement existant avant de pouvoir le tester et le mettre à jour pour une utilisation avec l'utilisateur non root. Pour plus d'informations, voir HCL Commerce utilisateurs et privilèges liés aux conteneurs. |
|
Common.runAsNonRoot.migrateAssetsPvcFromRootToNonroot
|
Ce paramètre déclenche une tâche de pré-mise à niveau pour mettre à jour les autorisations des fichiers dans le Persistent Volume Container (PVC) de votre Assets Tool readWriteMany, si vous en utilisez un dans votre déploiement existant.Il doit être utilisé dans des circonstances spécifiques lorsque vous mettez à niveau votre déploiement pour qu'il fonctionne correctement avec l'utilisateur non root. Pour plus d'informations, voir Mise à jour des autorisations de fichiers PVC pour la mise à niveau d'un déploiement Kubernetes des images d'utilisateur root vers les images utilisateur non root. |