Le blog francophone consacré
aux technologies Esri

Esri annonce ArcGIS Enterprise on Kubernetes


En avril dernier, lors de la conférence Esri Developer Summit, l'équipe d'ArcGIS Enterprise a annoncé la sortie d'une nouvelle option de déploiement d'ArcGIS Enterprise pour l'environnement Kubernetes. En complément des déploiements classiques sous Windows et Linux, cette implémentation entièrement nouvelle nommée "ArcGIS Enterprise on Kubernetes" a été conçue pour les nouvelles architectures basées sur la containérisation et les microservices.

Disponible depuis la version 10.9, ArcGIS Enterprise on Kubernetes est basé sur l'idée de continuer à offrir le serveur géospatial complet que vous connaissez actuellement (avec les mêmes capacités et les mêmes APIs), tout en étant plus scalable, plus résilient et plus facile à maintenir.


Premier éditeur de solutions SIG à packager, à supporter et à maintenir un serveur SIG complet sur ces nouvelles architectures, Esri propose une véritable avancée dans le monde du Géospatial. Celle-ci est à la fois le fruit de l'expérience acquise depuis 2012 avec la plus grande plateforme géospatiale du monde (ArcGIS Online) mais aussi des besoins exprimés par les équipes DevOps opérant dans des contextes industriels nécessitant une plus grande agilité et adaptabilité sur les capacités et la maintenance de leur SIG déployé "On-Premise".

Cette nouvelle option de déploiement, qui ne change pas les fonctionnalités ni les APIs d'ArcGIS Enterprise, ne concerne cependant pas toutes les organisations. Elle s'adresse, en premier lieu, à celles qui ont déjà une stratégie et une expérience dans la virtualisation et la containérisation de leur SI avec les technologies Docker et Kubernetes.

Je partage avec vous quelques ressources qui vous permettrons de découvrir plus en détails ce qu'est ArcGIS Enterprise.


Déployer, configurer et utiliser...

Tout au long du cycle de conception et de développement de cette nouvelle architecture ArcGIS Enterprise on Kubernetes, Esri s'est placé dans la position de l'administrateur IT chargé de déployer et de maintenir ArcGIS Enterprise dans un environnement Kubernetes. L'objectif d'ArcGIS Enterprise on Kubernetes est véritablement de simplifier les tâches de déploiement, de configuration et d'utilisation.

Dans la démo ci-dessous, mon collègue Markus Walker montre le processus de déploiement et de configuration d'ArcGIS Enterprise on Kubernetes dans un environnement de production en haute disponibilité.


Dans cette démonstration, vous aurez constaté qu'avant de commencer, Markus avait déjà provisionné son cluster Kubernetes, une condition préalable au déploiement.

Bien qu'Esri ai soigneusement conçu cette nouvelle option de déploiement pour être agnostique d'un fournisseur Kubernetes spécifique, les équipes d'ArcGIS on Kubernetes se sont assurées de pouvoir offrir une expérience optimum sur certains environnements Kubernetes cibles pour pouvoir assurer les tests et le supports adéquat. Pour cette première version,  ArcGIS Enterprise on Kubernetes est supporté pour trois fournisseurs de cluster Kubernetes, mais cette liste va croître au fil du temps:   

Data Center gérés On-premises
  • Plateformes de conteneurs opérées avec Red Hat OpenShift
Services Kubernetes gérés sur le cloud
  • Service Microsoft Azure Kubernetes (AKS) 
  • Service Amazon Elastic Kubernetes (EKS)

Une fois que vous avez provisionné un cluster dans l'un de ces environnements, vous êtes prêt à déployer.

Lorsque vous utilisez le script de déploiement (./deploy.sh) fourni par Esri, vous pouvez lancer le script en mode interactif (recommandé pour la première fois) ou en mode silencieux en utilisant une configuration basée sur des fichiers. Ceci est recommandé pour les déploiements ultérieurs lors de la création de réplicas sur lesquels vous souhaitez, par exemple, contrôler les versions.

Lorsque le script s'exécute, il communique avec le cluster et crée un ensemble initial de Pods de base (dans un namespace de votre choix) comprenant un contrôleur d'entrée (Ingress), une API d'administration d'ArcGIS Enterprise, l'ArcGIS Enterprise Manager, la documentation et l'aide en ligne.


Une fois le script de déploiement terminé et cet ensemble initial de Pods en place, l'étape suivante consiste à configurer votre organisation. Dans cette étape,  l'API d'administration d'ArcGIS Enterprise va vous permettre d'orchestrer la création des autres Pods notamment les magasins de données (Datastores) hébergés d'ArcGIS et les applications (Portal, Map Viewers, Dashboards, Field Maps, Instant Apps, StoryMaps, ...) 

Vous lancez ensuite le script de configuration (./configure.sh) ou l'assistant de configuration si vous préférez utiliser l'interface web pour cette étape. Cette étape enchaîne différentes étapes de configuration qui sont asynchrones et l'API renvoie des messages d'état jusqu'à ce que la configuration soit terminée. Le portail de l'organisation est alors prêt à être utilisé et l'administrateur peut commencer à l'utiliser en créant des membres et des contenus.

Les étapes de déploiement et de configuration nécessitent un nombre minime de paramètres en entrée et fournissent les paramètres système par défaut recommandés. Vous pouvez fournir ces paramètres aux différentes étapes à l'aide d'un fichier de propriétés qui peut ensuite être contrôlé par version et facilement répliqué. 

Ces scripts shell fonctionneront sur n'importe quel poste client prenant en charge l'exécution de scripts Bash. Une attention particulière a bien entendu été accordée aux informations d'identification nécessaires pour faire fonctionner ArcGIS Enterprise sur Kubernetes en utilisant le contrôle d'accès basé sur les rôles (RBAC) de Kubernetes avec l'ensemble des privilèges adaptés.
 
 
Appliquer des patchs ou réaliser des montées de version

Dans cette courte démonstration, mon collègue Shreyas Shinde nous montre le processus d' une mise à jour dans ArcGIS Enterprise sur Kubernetes. Les mises à jour consistent en des mises à niveau (une nouvelle version du logiciel) et des mises à jour (un nouveau patch). L'objectif est de permettre aux administrateurs d'acquérir de nouvelles fonctionnalités et d'améliorer la qualité de la plateforme dès qu'ils sont disponibles.


Au cours du développement d'ArcGIS on Kubernetes, un des principaux objectifs a été de réduire considérablement le temps et la charge imposées aux administrateurs IT pour maintenir et améliorer leur serveur géospatial ArcGIS.  

Ainsi, ArcGIS Enterprise on Kubernetes est délivré sous la forme d'un ensemble de conteneurs et un processus de mise à jour piloté par logiciel rationalise ces étapes de mise à jour et permet véritablement de gagner du temps. Ce processus est en même pensé pour pouvoir, dans de prochaines versions, être automatisé. 


Dans ArcGIS Enterprise sur Kubernetes, tous les logiciels, y compris les mises à jour et les mises à niveau, sont basés sur des conteneurs et fournis via un registre de conteneurs. À chaque nouvelle mise à jour ou version logicielle, les pipelines CI/CD d'Esri créeront de nouvelles images de conteneur et les transmettront au registre de conteneurs. Associé à ces images de conteneur, un manifeste hébergé par Esri décrit la mise à jour et inclut une liste des conteneurs requis pour la mise à jour.

L'API Admin se connecte au manifeste hébergé par Esri pour déterminer quand de nouvelles mises à jour et versions sont disponibles. Un administrateur peut interroger l'API Admin par script/programme pour détecter de nouvelles mises à jour.

Les administrateurs qui utilisent ArcGIS Enterprise Manager sont également alertés des nouvelles mises à jour directement à partir de l'application. Le processus d'application d'une mise à jour est aussi simple que d'appuyer sur un bouton dans ArcGIS Enterprise Manager ou d'appeler l'API Admin.
 

Un moteur de mise à jour est intégré aux outils d'administration. Une fois qu'une mise à jour est disponible, l'API Admin lit le manifeste pour déterminer quels pods doivent être mis à jour. Selon le type de pod, une stratégie de mise à jour appropriée est appliquée. Par exemple:

  • Stratégie de déploiement par "Propagation" (Rollling): cette stratégie est utilisée pour les objets de déploiement Kubernetes avec état, tels que les services SIG. Au fur et à mesure que de nouveaux pods alimentés par de nouvelles images de conteneurs sont déployés, les anciens pods sont arrêtés de manière continue. Cette approche vise à minimiser les temps d'arrêt pour vos mises à jour.
  • Stratégie de déploiement "Bleu/Vert:" cette stratégie est appliquée aux StatefulSets, comme ceux mis en œuvre par les magasins de données hébergés. Le cas échéant, de nouveaux déploiements Kubernetes sont lancés à l'aide des nouvelles images de conteneur pour mettre à niveau et migrer les données sous-jacentes. Des instances de magasin de données secondaires ou d'autres réplicas sont ensuite ajoutés au magasin de données. Une fois que le nouveau magasin de données est considéré comme sain, l'ancien magasin de données est arrêté, ne laissant qu'une instance saine du nouveau magasin de données.


Scalabilité des services

Les services SIG et leurs données sont la base d'une plateforme géospatiale d'entreprise. Ils alimentent les applications et les flux de travail critiques et permettent aux décideurs de planifier efficacement le meilleur plan d'action.

Chaque appel à un service est important et il est impératif que les administrateurs sachent quand les systèmes sont opérationnels et fonctionnent selon les niveaux de service (SLA) attendus, et peut-être plus important encore, quand ils ne le sont pas.

Ci-dessous, une vidéo de mon collègue Shreyas Shinde montre comment les administrateurs peuvent surveiller et gérer les services dans leurs organisations à l'aide d'ArcGIS Enterprise on Kubernetes.


Pour fournir des outils de monitoring prêts à l'emploi, ArcGIS Enterprise sur Kubernetes inclut le composant "Prometheus", un outil populaire permettant de collecter des métriques et le composant "Grafana", un outils de visualisation des métriques collectées.

Au fur et à mesure que les demandes arrivent et circulent dans le système ArcGIS, des métriques clés sont collectées à partir des différents pods et récupérées par Prometheus. Les métriques peuvent être interrogées à l'aide du langage de requête Prometheus (PromQL).

Bien que l'usage des données brutes soient très puissant, vous pouvez utiliser "Grafana" et construire des tableaux de bord sophistiqués qui vous permettrons de mieux comprendre la santé de votre système et des services.

Comme avec les modes de déploiement classiques (Windows et Linux), les services SIG d'ArcGIS Enterprise on Kubernetes peuvent être configurés pour fonctionner dans deux modes: 

  • Partagé: Le service  s'exécute en utilisant des ressources partagées avec d' autres services qui sont dans ce même mode.
  • Dédié: Le service s'exécute en utilisant ses propres ressources (CPU et mémoire) dédiées .

En 10.9, les services de cartes (Map Services) et les services d'entités hébergés peuvent être configurés pour fonctionner en mode "partagé". Le mode "dédié" est pris en charge pour les services de cartes dynamique (Dynamic Map Services), les services d'entités et les services de géotraitement. Ce dernier est idéal pour les services qui nécessitent une limite de commande de ressources spécifiques à l'individu ou ceux avec des SLA. 

Les administrateurs peuvent  utiliser ArcGIS Enterprise Manager ou l'API Admin pour  contrôler le nombre de pods de  service ainsi que le processeur et la mémoire associés à chacun.  

Notre objectif est que cette gestion "fine-grained" des ressources permettra aux administrateurs un meilleur contrôle de leur ensemble du système et de la santé des services.

En combinant les capacités des métriques d'utilisation des services avec un contrôle fin des ressources sur les pods, les administrateurs peuvent déployer des workflows de mise à l'échelle automatique très puissants pour s'assurer qu'un service est capable de respecter son SLA et de s'adapter instantanément aux workflows.

Alors que la précédente vidéo de Shreyas décrit un workflow manuel, elle peut nécessiter de l'automatisation. Vous pouvez utiliser des scripts pour  interroger les temps de réponse moyens du  service et saisir ces valeurs dans des routines simples qui peuvent ensuite déterminer les tendances.

Si les temps de réponse moyens augmentent,  cela signifie que le service est incapable de gérer la charge entrante sur une certaine période, un déclencheur peut alors être créé pour ajuster l'échelle des pods à l'aide de l'API Admin.

De cette façon, en utilisant l'automatisation et les capacités intégrées des métriques d'utilisation des services, les administrateurs peuvent faire évoluer leurs services SIG (à la hausse ou à la baisse) pour respecter leurs SLA.
 
 
Les capacités de cette version 10.9 d'ArcGIS Enterprise on Kubernetes

Pour atteindre aux objectifs d'évolutivité, de résilience et de maintenabilité, et surtout pour répondre aux normes de qualité internes chez Esri, les équipes de développement d'ArcGIS Enterprise ont dû faire des compromis sur la portée fonctionnelle de cette première mouture d'ArcGIS Enterprise on Kubernetes. La version 10.9 contient les workflows et les fonctionnalités d'un déploiement de base. Esri continuera à hiérarchiser les capacités en fonction des commentaires des utilisateurs et des partenaires dans les mois à venir. Bien qu'Esri ai dû différer la réarchitecture ou la prise en charge des éléments disponibles dans les déploiement classiques d'ArcGIS Enterprise sous Windows ou Linux, Esri a un plan ambitieux pour parvenir à une parité totale entre les trois options de déploiement. Le tableau suivant présente les capacités disponibles en 10.9 et les éléments qui sont programmés pour une version ultérieure. Vous pouvez consulter la documentation pour plus d'informations sur l'utilisation d'ArcGIS Enterprise sur Kubernetes.


Dispo Différé
Déploiement et mise à niveau
Déployer une organisation ArcGIS Enterprise en mode interactif ou silencieux
Configurer une organisation ArcGIS Enterprise à l'aide d'un assistant de configuration ou d'un script
Mettre à niveau ou mettre à jour le déploiement à l'aide d'ArcGIS Enterprise Manager ou de l'API administrateur
Choisissez parmi plusieurs profils d'architecture pour optimiser les ressources pour une haute disponibilité
Prise en charge de plusieurs déploiements dans le même cluster
Prise en charge des environnements totalement déconnectés
Dispo Différé
Administration
Surveiller les messages du journal
Vérifier la santé des magasins gérés par le système
Surveiller l'état du système et du module de services utilitaires
Mettre à l'échelle les déploiements de services et de systèmes à l'aide d'ArcGIS Enterprise Manager ou de l'API Admin
Créer et administrer des crochets Web
Obtenir des statistiques d'utilisation des services
Sauvegarder et restaurer l'organisation ArcGIS Enterprise
Dispo Différé
Sécurité
Configurer SAML et OpenID Connect
Configurer LDAP et Windows Active Directory
Configurer les groupes d'entreprise et les utilisateurs
Configurer l'authentification au niveau Web, y compris IWA+PKI
Gestion de données
Enregistrer SQL Server et PostgreSQL en tant que bases de données
Enregistrez vos propres sources de données, y compris les dossiers et les géodatabases d'entreprise
Prise en charge de la publication en masse avec une Géodatabase d'entreprise
Prise en charge de la collaboration distribuée
Prise en charge de l'édition bidirectionnelle avec collaboration distribuée
Prise en charge d'Oracle, SAP Hana, autres
Dispo Différé
Création et partage de contenu
Publier des services de carte, d'entité et de géocodage
Publier des packages de cartes, de tuiles et de tuiles de scène
Publier des couches d'entités hébergées
Effectuer une analyse spatiale
Capacités de routage lors de l'utilisation d'un serveur fédéré
Publier à partir d'ArcGIS Pro 2.8 et versions ultérieures
Consommer des services à partir d'ArcGIS Pro 2.7 et versions ultérieures
Publier des services de scène avec des couches d'entités associées
Prise en charge de l'extension de type d'utilisateur ArcGIS Utility Network
Prise en charge de l'extension de type d'utilisateur ArcGIS Parcel Fabric
Prise en charge de l'extension de type d'utilisateur ArcGIS Workflow Manager
Dispo Différé
Capacités de fédération de serveurs
Fédérer un serveur SIG ArcGIS
Fédérer un serveur d'images ArcGIS (remarque : les capacités d'analyse raster sont différées)
Fédérer un serveur ArcGIS GeoAnalytics
Fédérer un serveur ArcGIS GeoEvent
Fédérer un serveur ArcGIS Notebook
Fédérer un serveur ArcGIS Workflow Manager
Dispo Différé
Applications
Visionneuse Web ArcGIS CityEngine
ArcGIS Dashboards
Sites ArcGIS Enterprise
ArcGIS Experience Builder
ArcGIS Field Map
ArcGIS quickCapture
ArcGIS StoryMaps
ArcGIS Web AppBuilder
ArcGIS Workforce
ArcGIS Business Analyst Entreprise
ArcGIS Indoors et Space Planner
ArcGIS Insights
ArcGIS Living Atlas of The World
ArcGIS Mission
ArcGIS Ortho Maker
ArcGIS Tracker
ArcGIS Workflow Manager

Conclusion

Depuis 17 ans, Esri continue à mettre en oeuvre des moyens considérables pour innover autour d'ArcGIS Enterprise (ArcGIS Server en 2004) pour offrir les fonctionnalités les plus puissantes pour les utilisateurs du socle serveur SIG mais aussi pour proposer les outils d'administration et les options de déploiement de ce socle serveur pour simplifier les workflows de DevOps. Avec ArcGIS Entreprise on Kubernetes, les organisations exploitant déjà ces nouveaux types d'architecture de containers et de microservices peuvent désormais envisager cette nouvelle option de déploiement proposée depuis la version 10.9.

Partager cet article:

Rejoindre la discussion

    Les commentaires à propos de cet article: