Déployer un Red Hat OpenShift Container Platform

Avant de déployer ArcGIS Enterprise on Kubernetes sur RedHat OpenShift (RHOS), vous devez préparer un agrégat RHOS répondant à la configuration système d’ArcGIS Enterprise.

La préparation d’un agrégat RedHat OpenShift comprend des étapes communes à tous les environnements pris en charge (par exemple, la configuration de l’agrégat Kubernetes et des nœuds correspondants), ainsi que des étapes spécifiques à un environnement (par exemple, la création d’une contrainte de contexte de sécurité (SCC) dédiée et la gestion des entrées dans l’application).

Examinez les étapes suivantes et reportez-vous à la documentation RedHat OpenShift pour obtenir des instructions plus détaillées sur la préparation de votre environnement.

1. Créez un agrégat RedHat OpenShift.

   Il existe de nombreuses manières de déployer un agrégat RHOS. Pour les déploiements sur site, reportez-vous à la documentation de RedHat. Pour les déploiements basés sur le Cloud, reportez-vous à la documentation de RedHat OpenShift sur AWS (ROSA) ou d’Azure RedHat OpenShift.

2. Mettez à jour la configuration oc (kubectl).

   Une fois que vous avez créé l’agrégat, vous pouvez utiliser l’interface de ligne de commande OpenShift afin d’insérer les informations de connexion d’utilisateur authentifié dans votre fichier kubeconfig. Vous pouvez effectuer cela à l’aide de la commande suivante :

   oc login https://<serverName>:<serverPort>
   

3. Créez des classes de stockage.

   Pour adapter les propriétés reclaimPolicy et allowVolumeExpansion aux besoins de votre organisation et de vos charges de travail, il est recommandé de créer une classe de stockage référençant l’un des provisionneurs pris en charge, tels que Cinder, Manila ou vSphere Volume. Le fichier YAML approprié doit être appliqué à l’agrégat avec la commande suivante :

   oc apply -f <storageClass.yaml>
   

   Pour plus d’informations, reportez-vous à un exemple de fichier YAML de classe de stockage par défaut et à un exemple de fichier YAML de classe de stockage de sauvegarde.
4. Gérez les contraintes de contexte de sécurité.

   Dans OpenShift, les contraintes de contexte de sécurité agissent comme un contrôleur d’admission personnalisé pour les pods avant la planification. Par défaut, tous les pods sont admis en fonction des contraintes de contexte de sécurité restricted ou restricted-v2 car le groupe autorisé est system:authenticated.

   Selon votre configuration, vous devrez peut-être autoriser des privilèges supplémentaires pour répondre aux exigences d’ArcGIS Enterprise. Examinez ce qui suit :
   1. Autorisez les pods à s’exécuter avec un fsGroup spécifique.

      Les charges de travail ArcGIS Enterprise possèdent une valeur fsGroup précodée pour initialiser les autorisations de volume sur les volumes persistants de stockage de bloc nouvellement provisionnés. Ce fsGroup doit être autorisé par une contrainte de contexte de sécurité car il s’exécute par défaut en tant que plage arbitraire. Pour ce faire, mettez à jour une copie de la contrainte de contexte de sécurité restricted ou restricted-v2 avec la section suivante :

      fsGroup:
         ranges: 
           - max: 117932853
             min: 117932853
         type: MustRunAs
         groups:
            - 'system:serviceaccounts:<deployment-project>'
      

   2. Autorisez la liaison sur les ports privilégiés pour le contrôleur d’entrée.

      Pour les versions d’OpenShift antérieures à la version 4.11, le contexte restreint ne permet pas d’ajouter la fonctionnalité NET_BIND_SERVICE aux pods, ce qui est nécessaire pour le contrôleur d’entrée. Une nouvelle contrainte de contexte de sécurité doit être clonée à partir de la politique restreinte et la section suivante est ajoutée :

      allowedCapabilities: 
         - NET_BIND_SERVICE
      

      Cette contrainte de contexte de sécurité doit permettre au compte de service arcgis-ingress-serviceaccount de laisser le contrôleur d’entrée démarrer correctement.

      oc adm policy add-scc-to-user restricted-esri system:serviceaccount:<deployment-project>:arcgis-ingress-serviceaccount
      

      Pour OpenShift version 4.11 et ultérieure, la fonctionnalité requise est déjà autorisée pour la contrainte de contexte de sécurité restricted-v2.

   3. Augmentez les zones de carte mémoire maximale.

      L’ensemble avec état spatiotemporel nécessite que le nœud sous-jacent possède une valeur augmentée pour vm.max_map_count. Cela est activé par défaut à l’aide d’un conteneur init, mais la commande nécessite un accès privilégié à l’hôte sous-jacent pour s’exécuter :

      sysctl -w vm.max_map_count=262144
      

      Les nœuds d’opérateur peuvent être altérés au démarrage car des modifications sont apportées au fichier de configuration Ignition pour exécuter cette commande pendant l’amorçage. La propriété de ALLOW_PRIVILEGED_CONTAINERS doit être définie sur false dans le script de déploiement.

      Consultez la documentation de RedHat OpenShift pour plus de détails.

      Autrement, vous devez accorder au compte de service arcgis-elastic-serviceaccount l’autorisation d’exécuter un conteneur privilégié afin d’autoriser le conteneur init à exécuter la commande sysctl requise.

      oc adm policy add-scc-to-user privileged-esri system:serviceaccount:<deployment-project>:arcgis-elastic-serviceaccount
      

   Pour plus d’informations, examinez les exemples de fichier YAML SCC.

5. Configurez Red Hat OpenShift Routes.

   OpenShift comprend un contrôleur d’entrée clé en main pouvant être utilisé de pair avec le contrôleur d’entrée expédié avec ArcGIS Enterprise on Kubernetes. Si vous créez un itinéraire OpenShift via la ligne de commande, cet itinéraire peut être créé avec l’exemple de fichier YAML. Pour configurer un itinéraire via la console OpenShift, vous devez d’abord exécuter le script de déploiement, puis vous pouvez créer un itinéraire pour référencer la cible de service interne.

   Si la réponse à la question sur l’itinéraire OpenShift est yes dans le script de déploiement, le service arcgis-ingress-controller ne sera pas exposé en dehors du sous-réseau d’agrégat et sera créé en tant que type ClusterIP.

   Selon que vous préfériez ou non arrêter le SSL client, l’itinéraire sécurisé doit utiliser re-encrypt ou passthrough comme mode d’arrêt. Sélectionner re-encrypt nécessite un certificat TLS comme entrée pour l’itinéraire, tandis que passthrough présentera aux clients externes le certificat TLS défini pendant la phase de déploiement.