Comprendre Azure Arc

L'une des annonces les plus intéressantes de la conférence Ignite 2019 de Microsoft était Azure Arc, un nouvel outil de gestion pour les infrastructures d'applications cloud hybrides. S'appuyant sur les concepts Azure, Arc est conçu pour vous permettre de gérer des ressources sur site à partir du portail Azure, en déployant des stratégies et des services sur des machines virtuelles et Kubernetes. Il comprend également des versions conteneurisées de la base de données SQL Azure et de PostgreSQL Hyperscale pour offrir à vos applications hybrides basées sur Kubernetes des options de données cohérentes avec Azure.

Azure Arc étend le modèle Azure Resource Manager aux serveurs et aux clusters Kubernetes. Il est conçu pour gérer les ressources de manière cloud où qu'elles se trouvent, en traitant les outils de ressources Azure comme votre plan de contrôle. Cela le place à un niveau beaucoup plus élevé que la plupart des outils de gestion. Par exemple, si vous l'utilisez avec des machines virtuelles exécutées sur un réseau Windows Server, vous gérez les machines virtuelles avec les outils de gestion Hyper-V, ainsi que la configuration du serveur et les applications qui s'exécutent sur celles-ci avec Azure Arc.

Utilisation d'Azure Arc avec des serveurs

«Où qu'ils soient» est un principe clé derrière Azure Arc. Avec son objectif de gestion des applications, il est indépendant de l'infrastructure. Les machines virtuelles qu'il gère peuvent s'exécuter dans votre centre de données, dans une installation d'hébergement ou en tant que serveurs virtuels dans un environnement géré et partagé.

La gestion des serveurs avec Azure Arc est maintenant en préversion publique, avec un agent de machine connecté pour Windows et pour Linux pour gérer la connexion au service Azure Arc. Une fois connecté au cloud, vous pouvez commencer à le gérer comme s'il s'agissait d'une ressource Azure faisant partie d'un groupe de ressources. Cela vous permet de déployer des stratégies basées sur PowerShell sur des serveurs connectés, en tirant parti du travail qui a été effectué pour fournir une gestion juste à temps et la configuration d'état souhaitée. Les serveurs gérés auront besoin d'une connectivité à Azure Arc, via SSL.

Les serveurs gérés par Azure Arc n'ont pas besoin d'être des serveurs physiques; ce peuvent être des machines virtuelles. Cela vous permet de précharger l'agent dans des images de base de VM avant leur déploiement. Dans le cadre de la configuration du service, Azure Arc génère un script personnalisé qui s'exécutera sur des serveurs non connectés, en téléchargeant et en installant l'agent, avant de se connecter à Azure et d'ajouter le serveur en tant que ressource.

Gestion des applications Kubernetes dans Azure Arc

Microsoft n'a pas encore rendu la prise en charge de Kubernetes d'Azure Arc disponible dans l'aperçu public; il est toujours limité à l'aperçu de l'accès privé du service. Cependant, Gabe Monroy, directeur produit pour Azure Application Platform, en a fait une brève démonstration à Ignite.

À l'aide du portail Azure, Monroy a d'abord montré un cluster Kubernetes en cours d'exécution qui était géré à l'aide de stratégies basées sur Azure ARM. La politique initiale qu'il a utilisée contrôlait les ports réseau utilisés par le cluster, verrouillant les ports inutiles pour réduire la surface d'attaque du cluster. La même politique pourrait être utilisée pour gérer tous les clusters dans l'infrastructure globale d'une entreprise. La rédaction de politiques une seule fois et leur utilisation plusieurs fois de cette manière minimise le risque d'erreurs; en testant toutes vos politiques à l'avance, vous pouvez être sûr qu'elles fonctionneront une fois déployées à l'échelle mondiale.

L'autre avantage d'une approche basée sur des stratégies est que vous pouvez verrouiller les clusters s'ils ne sont pas conformes. Jusqu'à ce qu'un cluster signale qu'il est conforme à toutes vos stratégies, votre équipe de développement d'applications ne peut pas déployer de code. Avec l'agent Azure Arc déployé sur tous les clusters Kubernetes de votre réseau, vous disposez d'un panneau de verre pour gérer toutes les stratégies et tous les déploiements.

Il est important de noter que vous ne disposez pas d'un moyen de gérer directement les serveurs physiques et l'installation de Kubernetes. Tout ce que le portail Azure vous donne sont les stratégies et le code en cours d'exécution sur le cluster. Vous pouvez utiliser des stratégies pour définir le comportement d'un cluster, mais vous ne pouvez pas déployer de nouveaux nœuds à moins que l'environnement d'exécution Kubernetes et l'agent Azure Arc ne soient installés. Dès qu'un nouveau cluster est déployé et connecté à Azure Arc, les politiques sont automatiquement appliquées, garantissant que vos politiques de sécurité sont en place sans tout configurer manuellement.

Un aspect intéressant de la démonstration était une stratégie qui connectait Azure Arc à GitHub, ciblant soit les espaces de noms Kubernetes ou les clusters et gérant les déploiements à partir d'un référentiel spécifique. En utilisant cette stratégie, toute demande d'extraction vers le référentiel déclencherait le déploiement d'une application mise à jour. La même stratégie pourrait être utilisée pour charger votre code sur un nouveau cluster dès qu'il a été configuré. Toute future mise à jour du code se déploierait automatiquement, gardant tous vos sites exécutant les dernières versions.

Il est facile d'imaginer un nouvel ensemble de serveurs, préchargés avec Kubernetes et l'agent Azure Arc, livrés à un nouveau site périphérique. Une fois connectés à un WAN et sous tension, ils chargeraient automatiquement les dernières politiques et, une fois en conformité, téléchargeraient leurs applications et commenceraient à fonctionner avec une interaction humaine minimale.

Présentation d'un nouveau modèle de gestion axé sur le cloud et axé sur l'application

Il est peut-être préférable de considérer Azure Arc comme le premier d'une nouvelle génération d'outils de gestion d'applications basés sur des règles, en particulier lorsqu'il est utilisé pour automatiser les déploiements d'applications sur un réseau mondial. L'intégrer dans votre flux gitops est logique, utiliser Arc pour déclencher les déploiements d'applications lorsqu'une pull request est fusionnée et garantir que les politiques de sécurité appropriées sont appliquées au cluster hôte Kubernetes ou aux machines virtuelles.

Le point de vue de Microsoft sur le cloud est que les systèmes sur site ne disparaissent pas, et avec l'importance croissante des déploiements de périphérie, la définition du sur site ne fera que croître, cela ne signifie pas que ces systèmes sur site ne devraient pas ne bénéficiez pas des technologies cloud et des méthodes de travail informées sur le cloud. Azure Arc se concentre sur l'automatisation de l'infrastructure d'une application, en utilisant une stratégie pour garantir la conformité de la sécurité.

Quand vous y réfléchissez, il s'agit d'une extension logique de devops et d'une partie du mouvement vers un troisième niveau de gestion dans un environnement cloud. En mettant l'accent sur les infrastructures virtuelles d'applications, qu'elles soient basées sur des VM ou des conteneurs, Azure Arc sépare les opérations d'application des opérations d'infrastructure.

Dans un environnement de cloud hybride, l'équipe des applications n'a pas besoin de savoir quoi que ce soit sur l'infrastructure physique sous-jacente. Au lieu de cela, une équipe distincte sera responsable des serveurs physiques, des systèmes d'exploitation hôtes, des hyperviseurs et de l'installation de Kubernetes, avec des outils comme Azure Arc utilisés par l'équipe d'application pour gérer leurs applications à la périphérie, dans les systèmes hyperconvergés, dans les centres de données traditionnels et dans le cloud, le tout depuis la même console hébergée sur le cloud.

Nous avons changé la façon dont nous gérons l'infrastructure avec des conteneurs et la virtualisation, ainsi que la façon dont nous créons et gérons les applications avec devops. Pourquoi ne pas fournir des outils pour rapprocher les deux approches? Avec Azure Arc, le côté opérationnel de l'équation devops obtient une plate-forme pour séparer les applications de l'infrastructure, avec la possibilité de gérer et de contrôler ces applications à partir d'un nouveau plan de contrôle hébergé dans le cloud. C'est une vision attrayante et il sera intéressant de voir comment Microsoft la propose.