L’avancement cloud natif n’est pas aussi facile qu’il pourrait l’être. Des plates-formes telles que Kubernetes simplifient la procédure d’exécution d’un ensemble évolutif de services, mais vous devez toujours produire 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 déployée n’importe où, n’importe quand.
5 ans plus tôt, Microsoft a acquis le groupe Deis Labs dans le but de lui permettre de continuer à développer des outils Kubernetes open source. C’est l’une des acquisitions les plus réussies. Le groupe 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 Brigade, ainsi que WebAssembly dans Kubernetes avec Krustlets et l’utilisation de pilotes de périphériques Linux pour exposer le matériel de périphérie à Kubernetes à Akri.
La première version post-acquisition était Draft, un ensemble d’outils de ligne de commande destinés à vous aider à construire rapidement des prototypes d’applications conteneurisées, en fournissant l’échafaudage pour développer du code sur votre propre PC avant de le presser sur une instance Kubernetes. C’était une expérience intrigante, mais malheureusement, elle n’a pas obtenu l’adhésion de la communauté nécessaire pour la prendre encore plus que la version préliminaire. Si vous allez dans la liste des projets Deis, c’est marqué comme archivé, sans aucun 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 accepteraient encore plus Draft.
Draft est de retour
Microsoft a certainement vu l’intérêt continu dans le brouillon en tant qu’outil, car la Build 2022 a vu l’équipe Azure lancer une variante mise à niveau, le brouillon 2, à utiliser avec le service Azure Kubernetes (AKS) géré par Azure.
Comme le premier, le brouillon 2 est une commande -line pour développer rapidement une application Kubernetes. Contrairement à l’original, il est prévu de prendre le code existant et de le planifier pour une utilisation dans AKS, en construisant le conteneur et les fichiers manifestes pour exécuter votre application dans Kubernetes ainsi que les scripts et les workflows nécessaires pour le déployer de GitHub vers AKS.
Il y a beaucoup de ressemblances entre les deux variantes de Draft, mais la modification la plus significative est le passage d’un outil de développement régional à un outil basé sur Azure CLI et travaillant directement avec le cloud. C’est un modèle qui correspond à la façon dont Microsoft a réellement développé son environnement AKS, en l’utilisant pour des systèmes sur site au moyen d’Azure Stack HCI ou en utilisant Azure Arc sur vos propres serveurs. 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 une méthode permettant d’offrir une expérience de développeur cloud native totale sur votre bureau, le monde a considérablement changé depuis le lancement du projet d’origine.
L’outil Draft 2 est axé sur Azure, GitHub et AKS, mais il reste un projet open source, vous avez donc la possibilité de développer votre propre fork pour votre environnement Kubernetes sélectionné, qu’il soit auto-hébergé ou en cours d’exécution sur AWS ou GCP. Comme la majorité des outils Kubernetes, il est composé en Go, avec des workflows en YAML. Pour créer votre propre installation 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 de développement et de gestion Cloud Shell. Cela indique qu’il s’exécute au-dessus du BL-Delridge interne basé sur Debian de Microsoft, qui héberge Cloud Shell d’Azure. Cela devrait garantir que le projet 2 fonctionnera sur n’importe quel Linux dérivé de Debian avec un minimum de travail, car la seule distinction entre CBL-Delridge et Debian est que Microsoft compile lui-même tous les plans pour les facteurs de sécurité.
Il n’y a pas t de nombreuses exigences pour utiliser le brouillon 2. Tout ce dont vous avez besoin est Azure CLI, un cluster AKS et une instance de registre Azure Container Computer. Dès que vous avez installé l’extension aks-preview, elle vous donne 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 add-- name aks-preview. Utilisez az extension upgrade-- name aks-preview pour vous assurer que vous disposez de la variante actuelle.
Avec Azure CLI configuré pour utiliser le brouillon 2, vous pouvez prendre une application existante et la transformer dans une application Kubernetes. À partir de votre répertoire d’applications, appelez Azure CLI et brouillon : az aks brouillon produit. Si vous préférez, vous pouvez utiliser le drapeau d’emplacement de Draft pour cibler un répertoire spécifique. Cela produit les fichiers nécessaires à la création de votre application, constitués du Dockerfile nécessaire.
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 de le workflow de mise en œuvre Azure et GitHub. Vous êtes maintenant en mesure de construire 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’enregistre avec votre compte GitHub à l’aide d’OpenID Connect et le lie à votre registre Azure Container Computer System. Lorsque ce lien reste en place, vous êtes prêt à créer votre workflow de publication, à partir de votre clone régional de votre application. Utilisez le az aks prepare generate-workflow pour construire l’action.
Dès qu’une action a été réellement construite, vous aurez besoin de git pour la renvoyer dans votre référentiel d’application dans GitHub, prêt à l’emploi via les outils Actions. Vous pouvez ensuite modifier le code dans votre région à l’aide d’outils tels que Visual Studio Code, en conservant une branche appropriée à l’aide de l’extension Code GitHub au moyen de demandes d’extraction. Si vous avez réellement automatisé votre action, une demande d’extraction déclenchera une construction et livrera votre application à AKS, prête à être examinée.
Microsoft a en fait fourni un raccourci pour utiliser Draft avec une nouvelle application dans une nouvelle référentiel cloné. En utilisant la commande draft up, vous autorisez l’accès et construisez une action en une seule ligne. Si vous avez besoin de personnaliser une action, utilisez à nouveau generate-workflow. Vous pouvez utiliser la commande draft update pour activer le routage des applications Web AKS. Un contrôleur d’entrée basé sur Nginx inclut un accès Web à votre application et prend en charge les outils Open Service Mesh dans AKS pour vous aider à protéger votre code.
C’est formidable de voir Microsoft ramener Draft. Des outils tels que celui-ci sont une action nécessaire pour toute migration cloud native, en prenant du code et en automatisant la procédure de développement 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 méthode qui finira probablement par être plus répandue à l’avenir, car les deux sociétés collaborent de plus en plus sur des tâches.
.
Toute l’actualité en temps réel, est sur L’Entrepreneur
