Outils pour les développeurs d'applications exécutées sur Kubernetes

Outils pour les développeurs d'applications exécutées sur Kubernetes

Une approche moderne des opérations résout de nombreux problèmes commerciaux urgents. Les conteneurs et les orchestrateurs facilitent la mise à l'échelle de projets de toute complexité, simplifient la publication de nouvelles versions, les rendent plus fiables, mais créent en même temps des problèmes supplémentaires pour les développeurs. Le programmeur se soucie avant tout de son code : architecture, qualité, performances, élégance - et non de la façon dont il fonctionnera dans Kubernetes et comment le tester et le déboguer après avoir apporté des modifications, même minimes. Par conséquent, il est également tout à fait naturel que des outils pour Kubernetes soient activement développés, aidant à résoudre les problèmes même des développeurs les plus « archaïques » et leur permettant de se concentrer sur l'essentiel.

Cette revue fournit de brèves informations sur certains des outils qui facilitent la vie d'un programmeur dont le code s'exécute dans le pod'ax d'un cluster Kubernetes.

Aides simples

Kubectl-débogage

  • The bottom line: ajoutez votre conteneur à un Pod et voyez ce qui s'y passe.
  • GitHub.
  • Brèves statistiques GH : 715 étoiles, 54 commits, 9 contributeurs.
  • Langue : Allez.
  • Licence : Licence Apache 2.0.

Ce plugin pour kubectl vous permet de créer un conteneur supplémentaire à l'intérieur du pod qui vous intéresse, qui partagera l'espace de noms du processus avec d'autres conteneurs. Dans celui-ci, vous pouvez déboguer le fonctionnement du pod : vérifier le réseau, écouter le trafic réseau, effectuer une trace du processus qui vous intéresse, etc.

Vous pouvez également basculer vers le conteneur de processus en exécutant chroot /proc/PID/root - cela peut être très pratique lorsque vous avez besoin d'obtenir un shell racine dans un conteneur pour lequel il est défini dans le manifeste securityContext.runAs.

L'outil est simple et efficace, il peut donc être utile à tous les développeurs. Nous en avons écrit davantage dans article séparé.

La téléprésence

  • The bottom line: transférez l’application sur votre ordinateur. Développer et déboguer localement.
  • site Web; GitHub.
  • Brèves statistiques GH : 2131 étoiles, 2712 commits, 33 contributeurs.
  • Langage : Python.
  • Licence : Licence Apache 2.0.

L'idée de ce composant logiciel enfichable est de lancer un conteneur avec l'application sur l'ordinateur de l'utilisateur local et de transmettre par proxy tout le trafic du cluster vers celui-ci et inversement. Cette approche vous permet de développer localement en éditant simplement des fichiers dans votre IDE préféré : les résultats seront disponibles immédiatement.

Les avantages de l'exécution locale sont la commodité des modifications et des résultats instantanés, la possibilité de déboguer l'application de la manière habituelle. L'inconvénient est qu'il est exigeant en vitesse de connexion, ce qui est particulièrement visible lorsque vous devez travailler avec une application avec un RPS et un trafic assez élevés. De plus, Telepresence rencontre des problèmes de montage de volumes sous Windows, ce qui peut constituer une limitation décisive pour les développeurs habitués à cet OS.

Nous avons déjà partagé notre expérience d'utilisation de la téléprésence ici.

Ksync

  • The bottom line: synchronisation quasi instantanée du code avec le conteneur dans le cluster.
  • GitHub.
  • Brèves statistiques GH : 555 étoiles, 362 commits, 11 contributeurs.
  • Langue : Allez.
  • Licence : Licence Apache 2.0.

L'utilitaire vous permet de synchroniser le contenu d'un répertoire local avec le répertoire d'un conteneur exécuté dans le cluster. Un tel outil est parfait pour les développeurs de langages de programmation de script, dont le principal problème est de fournir du code à un conteneur en cours d'exécution. Ksync est conçu pour soulager ce mal de tête.

Lorsqu'il est initialisé une fois par la commande ksync init un DaemonSet est créé dans le cluster, qui est utilisé pour surveiller l'état du système de fichiers du conteneur sélectionné. Sur son ordinateur local, le développeur exécute la commande ksync watch, qui surveille les configurations et exécute syncthing, qui synchronise directement les fichiers avec le cluster.

Il ne reste plus qu'à indiquer à ksync quoi synchroniser avec quoi. Par exemple, cette commande :

ksync create --name=myproject --namespace=test --selector=app=backend --container=php --reload=false /home/user/myproject/ /var/www/myproject/

...créera un observateur nommé myprojectqui recherchera un pod avec une étiquette app=backend et essayez de synchroniser le répertoire local /home/user/myproject/ avec catalogue /var/www/myproject/ au conteneur appelé php.

Problèmes et notes sur ksync d'après notre expérience :

  • Doit être utilisé sur les nœuds du cluster Kubernetes overlay2 en tant que pilote de stockage pour Docker. L'utilitaire ne fonctionnera avec aucun autre.
  • Lorsque vous utilisez Windows comme système d'exploitation client, l'observateur du système de fichiers peut ne pas fonctionner correctement. Ce bug a été remarqué lorsque vous travailliez avec des répertoires volumineux - avec un grand nombre de fichiers et de répertoires imbriqués. Nous avons créé question pertinente dans le projet de synchronisation, mais il n'y a pas encore de progrès (depuis début juillet).
  • Utiliser le fichier .stignore pour spécifier des chemins ou des modèles de fichiers qui n'ont pas besoin d'être synchronisés (par exemple, des répertoires app/cache и .git).
  • Par défaut, ksync redémarrera le conteneur chaque fois que les fichiers changent. Pour Node.js, c'est pratique, mais pour PHP, c'est totalement inutile. Il vaut mieux désactiver opcache et utiliser le drapeau --reload=false.
  • La configuration peut toujours être corrigée dans $HOME/.ksync/ksync.yaml.

Squash

  • The bottom line: déboguer les processus directement dans le cluster.
  • GitHub.
  • Brèves statistiques GH : 1154 étoiles, 279 commits, 23 contributeurs.
  • Langue : Allez.
  • Licence : Licence Apache 2.0.

Cet outil est conçu pour déboguer les processus directement dans les pods. L'utilitaire est simple et vous permet de sélectionner de manière interactive le débogueur souhaité (voir ci-dessous) et espace de noms + pod, au cours desquels vous devez intervenir. Actuellement pris en charge :

  • fouiller - pour les applications Go ;
  • GDB - via la cible distante + redirection de port ;
  • Redirection de port JDWP pour le débogage des applications Java.

Côté IDE, le support n'est disponible que dans VScode (en utilisant élargir le), cependant, les plans pour l'année en cours (2019) incluent Eclipse et Intellij.

Pour déboguer les processus, Squash exécute un conteneur privilégié sur les nœuds du cluster, vous devez donc d'abord vous familiariser avec les fonctionnalités mode sans échec pour éviter les problèmes de sécurité.

Solutions complètes

Passons à l'artillerie lourde - des projets plus « à grande échelle » conçus pour répondre immédiatement à bon nombre des besoins des développeurs.

NB: Dans cette liste, bien sûr, il y a une place pour notre utilitaire Open Source cour (anciennement connu sous le nom de dapp). Cependant, nous en avons déjà écrit et parlé plus d'une fois et avons donc décidé de ne pas l'inclure dans la revue. Pour ceux qui souhaitent se familiariser davantage avec ses capacités, nous recommandons de lire/écouter le rapport «werf est notre outil pour CI/CD dans Kubernetes».

Espace de développement

  • The bottom line: pour ceux qui veulent commencer à travailler dans Kubernetes, mais ne veulent pas s'enfoncer profondément dans sa jungle.
  • GitHub.
  • Brèves statistiques GH : 630 étoiles, 1912 commits, 13 contributeurs.
  • Langue : Allez.
  • Licence : Licence Apache 2.0.

Une solution de la société du même nom, qui met à disposition des clusters managés avec Kubernetes pour le développement en équipe. L'utilitaire a été créé pour les clusters commerciaux, mais fonctionne très bien avec tous les autres.

Lors de l'exécution de la commande devspace init dans le catalogue du projet il vous sera proposé (de manière interactive) :

  • sélectionnez un cluster Kubernetes fonctionnel,
  • utiliser l'existant Dockerfile (ou en générer un nouveau) pour créer un conteneur basé sur celui-ci,
  • sélectionnez un référentiel pour stocker les images de conteneurs, etc.

Après toutes ces étapes préparatoires, vous pouvez démarrer le développement en exécutant la commande devspace dev. Il construira le conteneur, le téléchargera dans le référentiel, déploiera le déploiement sur le cluster et démarrera la redirection de port et la synchronisation du conteneur avec le répertoire local.

Facultativement, vous serez invité à déplacer le terminal vers le conteneur. Vous ne devriez pas refuser, car en réalité le conteneur démarre avec la commande sleep, et pour de vrais tests, l'application doit être lancée manuellement.

Enfin, l'équipe devspace deploy déploie l'application et l'infrastructure associée sur le cluster, après quoi tout commence à fonctionner en mode combat.

Toute la configuration du projet est stockée dans un fichier devspace.yaml. En plus des paramètres de l'environnement de développement, vous pouvez également y trouver une description de l'infrastructure, similaire aux manifestes Kubernetes standard, mais grandement simplifiée.

Outils pour les développeurs d'applications exécutées sur Kubernetes
Architecture et principales étapes de travail avec DevSpace

De plus, il est facile d'ajouter un composant prédéfini (par exemple, un SGBD MySQL) ou un chart Helm au projet. Lire la suite dans documentation - c'est pas compliqué.

Skaffold

  • site Web; GitHub.
  • Brèves statistiques GH : 7423 étoiles, 4173 commits, 136 contributeurs.
  • Langue : Allez.
  • Licence : Licence Apache 2.0.

Cet utilitaire de Google prétend couvrir tous les besoins d'un développeur dont le code s'exécutera d'une manière ou d'une autre sur un cluster Kubernetes. Commencer à l'utiliser n'est pas aussi simple que devspace : pas d'interactivité, de détection de langue et de création automatique Dockerfile ils ne vous le proposeront pas ici.

Cependant, si cela ne vous fait pas peur, voici ce que Skaffold vous permet de faire :

  • Suivez les modifications du code source.
  • Synchronisez-le avec le conteneur pod s'il ne nécessite pas d'assemblage.
  • Collectez des conteneurs avec du code, si le langage est interprété, ou compilez des artefacts et regroupez-les dans des conteneurs.
  • Les images résultantes sont automatiquement vérifiées à l'aide de test de structure de conteneur.
  • Marquage et téléchargement d'images dans le registre Docker.
  • Déployez une application dans un cluster à l'aide de kubectl, Helm ou kustomize.
  • Effectuez la redirection de port.
  • Déboguer des applications écrites en Java, Node.js, Python.

Le flux de travail dans diverses variantes est décrit de manière déclarative dans le fichier skaffold.yaml. Pour un projet, vous pouvez également définir plusieurs profils dans lesquels vous pouvez modifier partiellement ou totalement les étapes d'assemblage et de déploiement. Par exemple, pour le développement, spécifiez une image de base pratique pour le développeur, et pour la préparation et la production - une image minimale (+ utilisation securityContext conteneurs ou redéfinir le cluster dans lequel l'application sera déployée).

Les conteneurs Docker peuvent être construits localement ou à distance : dans Google Cloud Build ou dans un cluster en utilisant Kaniko. Bazel et Jib Maven/Gradle sont également pris en charge. Pour le balisage, Skaffold prend en charge de nombreuses stratégies : par hachage git commit, date/heure, somme sha256 des sources, etc.

Par ailleurs, il convient de noter la possibilité de tester des conteneurs. Le framework de test de structure de conteneur déjà mentionné propose les méthodes de vérification suivantes :

  • Exécuter des commandes dans le contexte d'un conteneur avec suivi des statuts de sortie et vérifier la sortie texte de la commande.
  • Vérification de la présence de fichiers dans le conteneur et correspondance des attributs spécifiés.
  • Contrôle du contenu des fichiers à l'aide d'expressions régulières.
  • Vérification des métadonnées d'image (ENV, ENTRYPOINT, VOLUMES etc).
  • Vérification de la compatibilité des licences.

La synchronisation des fichiers avec le conteneur ne s'effectue pas de la manière la plus optimale : Skaffold crée simplement une archive avec les sources, la copie et la décompresse dans le conteneur (tar doit être installé). Par conséquent, si votre tâche principale est la synchronisation de code, il vaut mieux se tourner vers une solution spécialisée (ksync).

Outils pour les développeurs d'applications exécutées sur Kubernetes
Principales étapes de l'exploitation de Skaffold

De manière générale, l’outil ne permet pas d’abstraire les manifestes Kubernetes et n’a aucune interactivité, il peut donc paraître difficile à maîtriser. Mais c'est aussi son avantage : une plus grande liberté d'action.

Embellissez

  • site Web; GitHub.
  • Brèves statistiques GH : 1063 étoiles, 1927 commits, 17 contributeurs.
  • Langue : TypeScript (il est prévu de diviser le projet en plusieurs composants, dont certains seront en Go, et également de réaliser un SDK pour créer des add-ons en TypeScript/JavaScript et Go).
  • Licence : Licence Apache 2.0.

Comme Skaffold, Garden vise à automatiser les processus de livraison du code d'application au cluster K8s. Pour ce faire, vous devez d'abord décrire la structure du projet dans un fichier YAML, puis exécuter la commande garden dev. Elle fera toute la magie :

  • Récupérez les conteneurs avec différentes parties du projet.
  • Effectue des tests d’intégration et unitaires, le cas échéant.
  • Déploie tous les composants du projet sur le cluster.
  • Si le code source change, l'ensemble du pipeline sera redémarré.

L'objectif principal de l'utilisation de cet outil est de partager un cluster distant avec une équipe de développement. Dans ce cas, si certaines étapes de construction et de test ont déjà été effectuées, cela accélérera considérablement l'ensemble du processus, puisque Garden pourra utiliser les résultats mis en cache.

Un module de projet peut être un conteneur, un conteneur Maven, un chart Helm, un manifeste pour kubectl apply ou encore une fonction OpenFaaS. De plus, n’importe lequel des modules peut être extrait d’un référentiel Git distant. Un module peut ou non définir des services, des tâches et des tests. Les services et les tâches peuvent avoir des dépendances, grâce auxquelles vous pouvez déterminer la séquence de déploiement d'un service particulier et organiser le lancement des tâches et des tests.

Garden fournit à l'utilisateur un magnifique tableau de bord (actuellement en état expérimental), qui affiche le graphique du projet : composants, séquence d'assemblage, exécution des tâches et tests, leurs connexions et dépendances. Directement dans le navigateur, vous pouvez afficher les journaux de tous les composants du projet et vérifier ce qu'un composant particulier génère via HTTP (si, bien sûr, une ressource d'entrée est déclarée pour lui).

Outils pour les développeurs d'applications exécutées sur Kubernetes
Panneau pour jardin

Cet outil dispose également d'un mode de rechargement à chaud, qui synchronise simplement les modifications du script avec le conteneur dans le cluster, accélérant considérablement le processus de débogage de l'application. Le jardin en a un bon documentation et pas mal ensemble d'exemples, vous permettant de vous y habituer rapidement et de commencer à l'utiliser. D'ailleurs, nous avons récemment publié traduction d'articles de ses auteurs.

Conclusion

Bien entendu, cette liste d'outils pour développer et déboguer des applications dans Kubernetes ne se limite pas à. Il existe de nombreux autres utilitaires très utiles et pratiques qui méritent, sinon un article séparé, du moins une mention. Dites-nous ce que vous utilisez, quels problèmes vous avez rencontrés et comment vous les avez résolus !

PS

A lire aussi sur notre blog :

Source: habr.com

Ajouter un commentaire