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
- 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.
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.
0 comments :
Enregistrer un commentaire