Par : Philippe Van De Vreken
Outre la manière traditionnelle de déployer ArcGIS Enterprise via Windows ou Linux, Esri a introduit il y a quelques années une troisième option de déploiement via Kubernetes. Il s'agit d'un tout nouveau développement visant à rendre ArcGIS Enterprise disponible en tant que technologie cloud-native.
Tous les logiciels que vous déployez dans un environnement cloud ne sont pas automatiquement cloud-native. Cloud-native fait référence à un ensemble de pratiques et de principes de conception pour la construction et l'exécution d'applications qui tirent pleinement parti des capacités des environnements informatiques cloud. Les applications natives pour l'informatique cloud sont spécifiquement conçues pour tirer parti de ce qui suit :
La technologie cloud-native est généralement mise en œuvre par le biais de microservices. Il s'agit de diviser le logiciel en petits services indépendants, chacun chargé d'une tâche spécifique. Ces services peuvent être déployés, mis à l'échelle et mis à jour de manière indépendante.
Les applications natives pour l'informatique cloud sont déployées via des conteneurs. Un conteneur est un ensemble compact et autonome qui contient tous les logiciels nécessaires en plus de l'application. Les développeurs poussent ces conteneurs vers un registre basé sur le cloud (tel que Docker Hub), à partir duquel ils peuvent être poussés et déployés.
Kubernetes (souvent abrégé en K8s) est une plateforme open-source permettant d'automatiser le déploiement, la mise à l'échelle et la gestion des applications conteneurisées. Développée à l'origine par Google, cette technologie est responsable de l'orchestration des conteneurs.
Kubernetes assure l'évolutivité en ajoutant ou en supprimant automatiquement des conteneurs en fonction de la charge. Il rend également les applications hautement disponibles en remplaçant automatiquement les conteneurs défaillants et en répartissant les charges de travail sur plusieurs machines (nœuds) au sein d'un cluster.
Une application devient ainsi autoréparable, pour ainsi dire: lorsqu'un conteneur tombe en panne ou devient instable, Kubernetes le redémarre ou le remplace automatiquement. L'équilibrage des charges est également appliqué activement, le trafic réseau étant automatiquement réparti entre les conteneurs sains afin d'éviter les goulets d'étranglement.
En outre, Kubernetes prend en charge les mises à jour et les retours en arrière, ce qui permet aux applications d'être mises à jour sans interruption de service et de revenir en arrière si nécessaire. La configuration s'effectue généralement au moyen de fichiers YAML ou JSON dans lesquels vous définissez l'état souhaité du système. Kubernetes veille ensuite à ce que cet état soit effectivement atteint.
La plus petite unité au sein d'un cluster Kubernetes est un pod. Un pod représente un ou parfois plusieurs conteneurs et dispose d'une adresse IP unique au sein du cluster.
ArcGIS Enterprise sur Kubernetes
Au sein d'ArcGIS Enterprise, Kubernetes représente une troisième option de déploiement aux côtés de Windows et Linux. Alors qu'ArcGIS Enterprise sur Windows ou Linux se compose de quatre éléments distincts (Portal for ArcGIS, ArcGIS Server, ArcGIS Datastore et les Web Adaptors), ArcGIS Enterprise sur Kubernetes est déployé comme un ensemble de microservices orchestrés ensemble au sein d'un cluster Kubernetes.
ArcGIS Enterprise on Kubernetes regroupe ses pods en quatre catégories conceptuelles :
Source : https://enterprise-k8s.arcgis.com/en/latest/deploy/system-architecture.htm
Bien que les utilisateurs finaux ne remarquent pratiquement aucune différence dans l'utilisation d'ArcGIS Enterprise, le backend complètement différent modifie considérablement la gestion pour les administrateurs SIG.
ArcGIS Enterprise on Kubernetes (v. 12.0) est pris en charge dans plusieurs environnements :
Lors du déploiement, vous choisissez parmi trois profils d'architecture : Enhanced, Standard et Development. Ces profils diffèrent par le degré de redondance des pods. Les profils Enhanced et Standard sont destinés à la production, le profil Enhanced offrant la plus grande disponibilité. Le profil Développement est adapté aux environnements de non-production. Chaque profil requiert un nombre minimum de nœuds de travail avec au moins 8 vCPU et 32 Go de RAM par nœud.
Source : https://enterprise-k8s.arcgis.com/en/latest/deploy/system-requirements.htm
L'une des principales différences est le cycle de vie. Il n'y a pas de versions de support à court et à long terme pour ArcGIS Enterprise sur Kubernetes. Dès qu'une nouvelle version est publiée, la précédente passe en support mature et ne reçoit plus de correctif. Une autre version plus tard, cette version devient entièrement retirée. En pratique, cela signifie qu'une version reste prise en charge pendant environ un an. Travailler avec ArcGIS Enterprise sur Kubernetes suppose donc de programmer des mises à jour régulières.
Source : https://support.esri.com/en-us/products/arcgis-enterprise-kubernetes/life-cycle
Le processus de déploiement est également différent. Il se fait toujours en deux étapes. Tout d'abord, vous déployez un nombre limité de pods via un script, y compris le pod Enterprise Manager. Ensuite, vous passez par un assistant dans Enterprise Manager pour créer l'organisation ArcGIS Enterprise.
Source : Capture d'écran de l'environnement de démonstration
Cet assistant permet de choisir le profil d'architecture souhaité, de télécharger un fichier de licence, de créer un compte administrateur et de configurer le stockage. Les autres pods sont ensuite déployés et ArcGIS Enterprise est opérationnel au bout de 35 à 45 minutes.
La troisième différence réside dans ArcGIS Enterprise Manager lui-même. Il s'agit de l'interface de gestion centrale pour les administrateurs SIG. Vous pouvez, entre autres, télécharger des certificats SSL, effectuer des sauvegardes et les restaurer, consulter les journaux, gérer les services SIG et effectuer des mises à jour ou des mises à niveau. Les tâches qui, avec ArcGIS Enterprise sur les déploiements Windows ou Linux, sont dispersées dans différents outils de gestion, sont ici rassemblées dans une seule interface.
Source : Capture d'écran de l'environnement de démonstration
Avec ArcGIS Enterprise sur Kubernetes, vous faites la distinction entre les mises à jour et les mises à niveau. Une mise à jour peut être comparée au déploiement d'un correctif. Les mises à jour ne remplacent que certains microservices et s'effectuent généralement par le biais de rolling updates. Elles peuvent toujours être annulées. Les mises à niveau remplacent tous les microservices et combinent des mises à jour en continu avec des mises à jour "blue-green". Une mise à jour "blue-green" consiste à déployer de nouveaux pods en même temps que les pods existants et à ne les rendre actifs qu'après des tests concluants. Les mises à niveau ne peuvent pas être annulées ; en cas de problème, vous devez restaurer une sauvegarde.
Les mises à jour et les mises à niveau s'effectuent toutes deux en mode lecture seule, mais ArcGIS Enterprise reste disponible. C'est une grande différence avec les mises à niveau sur Windows ou Linux, qui nécessitent souvent des temps d'arrêt. De plus, les mises à niveau sur Kubernetes ont tendance à être plus rapides.
Enfin, un déploiement Kubernetes rend le système beaucoup plus élastique. Grâce à l'autoscaling des clusters, des nœuds supplémentaires sont automatiquement ajoutés lorsque le CPU ou la RAM sont insuffisants, et supprimés à nouveau lorsque la charge diminue. Cela permet d'optimiser les coûts.
Source : https://www.perfectscale.io/blog/kubernetes-cluster-autoscaler
Dans le cas d'un déploiement sous Windows ou Linux, la capacité disponible est fixe et ne peut être adaptée que par l'intervention manuelle d'un administrateur système. Outre l'autoscaling des clusters, il existe également l'autoscaling horizontal des pods (HPA), où le nombre de répliques de pods est automatiquement ajusté lorsque certaines valeurs limites pour l'utilisation du CPU ou de la RAM sont dépassées.
Toutes les organisations disposant d'ArcGIS Enterprise sur Windows ou Linux n'ont pas besoin de passer à la nouvelle version. Pour les déploiements simples et les organisations sans expérience de Kubernetes, Windows et Linux restent souvent le meilleur choix.
En revanche, si vous disposez d'un savoir-faire Kubernetes en interne et que vous gérez aujourd'hui un environnement ArcGIS Enterprise plus complexe (par exemple, avec une configuration haute disponibilité de Portal ou un site ArcGIS Server composé de plusieurs machines), alors ArcGIS Enterprise sur Kubernetes vaut vraiment la peine d'être envisagé. En particulier pour les systèmes d'entreprise critiques, où les temps d'arrêt pendant les mises à niveau sont difficilement justifiables, Kubernetes offre des avantages évidents grâce aux mises à jour glissantes.
Cependant, il est important de le mentionner : aucun outil prêt à l'emploi n'existe aujourd'hui pour migrer simplement les déploiements existants d'ArcGIS Enterprise sur Windows ou Linux vers Kubernetes via lift-and-shift.
ArcGIS Enterprise on Kubernetes est une nouvelle façon de déployer ArcGIS Enterprise et offre des avantages évidents par rapport aux déploiements traditionnels sous Windows ou Linux. Pour les utilisateurs finaux, peu de choses changent, mais pour les administrateurs SIG, cela signifie une façon de travailler fondamentalement différente.
Le travail cloud devient-il de plus en plus important dans votre organisation ? Dans ce cas, gardez ce blog à l'esprit et contactez-nous pour plus d'informations.
Clause de non-responsabilité : Ces articles de blog ont été initialement publiés sous les noms de Geo Solutions et Localyse. Par conséquent, il est possible que des références à Geo Solutions of Localyse apparaissent encore. Dans le cadre de notre rebranding, les deux marques seront regroupées sous le nom de GeoSquare Belgique à partir de février 2026.