Le développement cloud natif n’est pas aussi simple qu’il pourrait l’être. Des plates-formes telles que Kubernetes rationalisent la procédure d’exécution d’un ensemble évolutif de services, mais vous devez toujours créer l’application que vous exécutez dans le cloud. Il ne s’agit pas de mettre votre code dans un conteneur et de composer une configuration YAML ; vous avez besoin de bien plus pour avoir une version qui peut être publiée n’importe où, n’importe quand.
Il y a 5 ans, Microsoft a acquis l’équipe Deis Labs dans le but de lui permettre de continuer à construire des outils Kubernetes open source. C’est l’une des acquisitions les plus efficaces. L’équipe a fourni des mises à niveau majeures des outils de packaging de produits Helm Kubernetes et du système de flux de travail piloté par les événements de Brigade, ainsi que WebAssembly dans Kubernetes avec Krustlets et l’utilisation de pilotes de périphériques Linux pour exposer le matériel de pointe à Kubernetes à Akri.
La toute première version post-acquisition était Draft, un ensemble d’outils de ligne de commande destinés à vous aider à créer rapidement des modèles d’applications conteneurisées, fournissant l’échafaudage pour établir le code sur votre propre PC avant de le pousser vers une situation Kubernetes. Ce fut une expérience fascinante, mais malheureusement, elle n’a pas obtenu l’adhésion locale nécessaire pour la prendre encore plus que la version préliminaire. Si vous allez à la liste des tâches Deis, c’est important car archivé, sans travail préparé. Même ainsi, il a clairement laissé sa marque sur ceux qui l’ont utilisé, Deis leur demandant régulièrement s’ils prendraient encore plus de brouillon.
Le brouillon est de retour
Microsoft a définitivement observé l’intérêt continu dans le brouillon en tant qu’outil, car la Build 2022 a vu le groupe Azure lancer une version mise à jour, le brouillon 2, à utiliser avec le service Azure Kubernetes (AKS) géré par Azure.
Comme le premier, le brouillon 2 est une commande -line outil pour construire rapidement une application Kubernetes. Contrairement à l’original, il est destiné à prendre le code existant et à le regrouper pour l’utiliser dans AKS, en construisant le conteneur et les fichiers manifestes pour exécuter votre application dans Kubernetes avec les scripts et les workflows nécessaires pour la déployer de GitHub vers AKS.
Il existe de nombreuses similitudes entre les deux variantes de Draft, mais la modification la plus importante est le passage d’un outil de développement local à un outil basé sur Azure CLI et fonctionnant directement avec le cloud. C’est un modèle qui correspond à la façon dont Microsoft a développé son environnement AKS, en le fournissant pour des systèmes sur site via Azure Stack HCI ou en utilisant des serveurs Azure Arc par vous-même. Avec Visual Studio Code fournissant des outils de développement à distance pour Azure, comprenant l’interface de ligne de commande Azure, et avec GitHub CodeSpaces étant un moyen de fournir une expérience de développeur cloud native complète sur votre bureau, le monde a considérablement changé depuis le lancement du projet original.
L’outil Draft 2 est axé sur Azure, GitHub et AKS, mais il reste une tâche open source, vous avez donc la possibilité de créer votre propre fork pour l’environnement Kubernetes de votre choix, qu’il soit auto-hébergé ou qu’il fonctionne sur AWS ou GCP. Comme beaucoup d’outils Kubernetes, il est écrit en Go, avec des workflows en YAML. Pour créer votre propre configuration Draft 2, clonez son référentiel GitHub. Avec Go 1.118 ou une configuration supérieure, utilisez le make familier pour créer le fichier binaire Draft avant de l’inclure dans votre cours système.
Utilisation de Draft 2 avec Azure
La version préliminaire de Draft 2 fait partie de l’extension aks-preview d’Azure CLI. Vous pouvez exécuter Azure CLI dans votre région ou dans Azure dans le cadre de l’environnement d’avancement et de gestion Cloud Shell. Cela suggère qu’il fonctionne au-dessus du BL-Delridge interne basé sur Debian de Microsoft, qui héberge Cloud Shell d’Azure. Cela doit garantir que le projet 2 fonctionnera sur n’importe quel Linux dérivé de Debian avec un minimum de travail, car la seule différence entre CBL-Delridge et Debian est que Microsoft rassemble tous les packages lui-même pour des raisons de sécurité.
Il Il n’y a pas beaucoup de prérequis pour utiliser le brouillon 2. Tout ce dont vous avez besoin est Azure CLI, un cluster AKS et une instance de registre Azure Container Pc. Lorsque vous avez réellement installé l’extension aks-preview, elle vous offre les outils dont vous avez besoin et un endroit pour acheter et exécuter vos conteneurs d’applications. L’installation de l’extension est assez simple en utilisant la commande suivante : az extension include-- name aks-preview. Utilisez az extension update-- name aks-preview pour vous assurer que vous disposez de la version la plus récente.
Avec Azure CLI configuré pour utiliser le brouillon 2, vous pouvez prendre une application existante et transformez-le en une application Kubernetes. À partir de votre répertoire d’applications, appelez Azure CLI et brouillon : az aks prepare develop. Si vous le souhaitez, vous pouvez utiliser l’indicateur d’emplacement de Draft pour cibler un répertoire particulier. Cela crée les fichiers nécessaires à la construction de votre application, y compris l’essentiel Dockerfile.
Automatisation du brouillon avec les actions GitHub
Là où le brouillon 2 diffère de la version initiale, c’est sa combinaison avec des éléments clés du Workflow de publication Azure et GitHub. Vous êtes maintenant en mesure de développer rapidement une action GitHub qui automatise la procédure de pressage des artefacts de code de GitHub vers AKS. Le brouillon a maintenant une commande draft setup-gh qui s’inscrit avec votre compte GitHub en utilisant OpenID Connect et le connecte à votre Azure Container Pc Registry. Une fois ce lien en place, vous êtes prêt à créer votre flux de travail de mise en œuvre, en commençant par votre clone régional de votre application. Utilisez le az aks prepare generate-workflow pour créer l’action.
Dès qu’une action a été construite, vous aurez besoin de git pour la renvoyer dans votre référentiel d’application dans GitHub, prêt à être utilisé via les outils Actions. Vous pouvez ensuite modifier le code localement à l’aide d’outils tels que Visual Studio Code, en le réenregistrant dans une branche appropriée à l’aide de l’extension Code GitHub via des demandes d’extraction. Si vous avez réellement automatisé votre action, une demande d’extraction déclenchera un développement et fournira votre application à AKS, prête à être testée.
Microsoft a en fait proposé un raccourci pour utiliser Draft avec une nouvelle application dans une marque -nouveau référentiel cloné. En utilisant la commande draft up, vous obtiendrez sous licence l’accès et la construction d’une action sur une seule ligne. Si vous avez besoin de personnaliser une action, utilisez à nouveau generate-workflow. Vous pouvez utiliser la commande draft upgrade pour activer le routage des applications Web AKS. Un contrôleur d’entrée basé sur Nginx ajoute un accès Web à votre application et prend en charge les outils Open Service Mesh dans AKS pour aider à protéger votre code.
C’est excellent de voir Microsoft ramener Draft. Des outils comme celui-ci sont une action importante pour toute migration cloud native, prenant du code et automatisant la procédure de construction des scripts et des manifestes nécessaires pour l’exécuter sur Kubernetes. Il est également intéressant de voir un autre outil Azure s’appuyer sur une fonction GitHub, une approche qui finira probablement par devenir plus courante à l’avenir à mesure que les deux sociétés interagissent progressivement sur les tâches.
.
Toute l’actualité en temps réel, est sur L’Entrepreneur
