Ceci est la dernière partie de la série de débogage. Pour apprendre le reste, vous devrez vous procurer le livre « Practical Debugging at Scale: Cloud Native Debugging in Kubernetes and Production » ou le cours. L’une des questions les plus fréquemment posées que je reçois est : pouvons-nous faire ces choses dans VS Code ?
La réponse est malheureusement non. Mais je développe les capacités de débogage de VS Code dans cette vidéo : « 16 fonctionnalités manquantes dans le débogueur de VS Code » sur YouTube. Je ferai un article de blog qui couvrira cela la semaine prochaine.
Ci-dessous la dernière vidéo de la série :
Transcription
Bienvenue dans la neuvième partie du débogage à grande échelle, où nous connaissons vraiment la qualité de votre code. Le débogage à distance ne concerne pas toujours une machine distante. Nous en avons souvent besoin lors du débogage dans Kubernetes ou Docker.
Nous approfondirons cela plus tard, mais pour l’instant, nous discuterons des mécanismes de base. Comment se connecter, comment le rendre légèrement moins vulnérable aux attaques de sécurité, puis nous aborderons les problèmes de débogage à distance.
La connexion et la ligne de commande
Nous allons commencer par une discussion autour de la connexion. Nous devons d’abord exécuter le processus auquel nous nous connecterons à distance. Pour ce faire, nous devons exécuter une commande similaire à celle-ci. Notez qu’il s’agit d’une version simplifiée. Dans de nombreux cas, l’argument doit être intégré dans les fichiers de configuration. Lorsque vous inspectez vos fichiers maven ou gradle, vous pouvez voir de nombreux arguments répertoriés ici. C’est ainsi que ces choses fonctionnent sous le capot. Passons en revue la commande et décomposons-la pièce par pièce pour voir si nous la comprenons correctement.
La première partie est le lancement de la ligne de commande Java. C’est assez évident. Nous avons besoin de guillemets dans bash car il y a une étoile à la fin de la ligne et bash veut l’étendre. Sans cette citation, la commande ne fonctionnera pas correctement.
Agent lib est le système qui charge le câblage de la bibliothèque native directement dans la machine virtuelle, et JDWP est le protocole Java Debug Wire. Il s’agit du protocole réseau sous-jacent utilisé pour communiquer entre le débogueur et le processus en cours d’exécution. C’est un protocole de haut niveau, ce qui signifie qu’il peut être implémenté sur divers transports. En règle générale, il est implémenté sur des sockets TCP, mais c’est le même protocole que nous avons utilisé pour déboguer directement les périphériques. Vous n’avez pas besoin d’en savoir trop sur JDWP, mais le concept est simple. Vous envoyez des commandes et pouvez interroger le système. C’est ce que l’IDE fait pour vous. Lorsque vous ajoutez un point d’arrêt, l’IDE envoie une commande JDWP pour ajouter un point d’arrêt à l’emplacement donné. Lorsque le point d’arrêt est atteint, JDWP renvoie un événement à l’IDE, indiquant que l’IDE peut alors interroger les détails sur l’environnement actuel, la pile, les variables, etc.
Dans ce cas, nous transférons les détails via un socket serveur. On peut utiliser dt_shmem, qui signifie mémoire partagée, en tant que protocole filaire. Ceci est plus rapide et utile pour les processus qui ont accès à une zone de mémoire partagée. Ceci est en fait enfichable et vous pouvez créer votre propre transport JDWP. Ce n’est généralement pas utile, mais cela témoigne de la puissance et de la flexibilité de l’API.
Nous pouvons éventuellement suspendre la machine virtuelle au lancement si vous souhaitez déboguer quelque chose dès le début. Je l’ai défini sur non, ce qui signifie que la machine virtuelle commencera à fonctionner immédiatement. Si vous le réglez sur oui avec la lettre « y », la machine virtuelle s’arrêtera au lancement et attendra la connexion JDWP. C’est l’adresse et le port sur lesquels nous écoutons. Dans ce cas, j’autorise n’importe qui à se connecter sur le port 5005. Je peux limiter cela à localhost uniquement en changeant le caractère étoile. C’est probablement la meilleure approche. Cependant, cela ne rendra pas le protocole entièrement sécurisé.
C’est le reste de la commande, la classe que nous exécutons. Typiquement, vous auriez quelque chose de plus substantiel ici. Dans ce cas, j’exécute simplement le PrimeMain classer. Pour commencer le débogage, nous devons modifier la configuration d’exécution dans intellij.
Connexion depuis IntelliJ/IDEA
Ensuite, nous devons localiser une configuration pour le débogage à distance. Une fois que j’ai sélectionné cela, nous pouvons l’ajouter. Notez qu’il est préconfiguré avec les valeurs par défaut, telles que le port 5005. Je donne un nom à la nouvelle configuration d’exécution et nous sommes prêts à déboguer l’application. Notez qu’il existe de nombreuses options à régler ici, mais nous n’en avons besoin d’aucune. Aussi, consultez cette zone ici. Cela vous semble familier ? C’est la ligne exacte dont nous avons discuté auparavant. L’IDE nous montre comment configurer la ligne de commande pour le processus distant. Cela nous permet de vérifier que nous avons tout saisi correctement.
Nous avons maintenant une nouvelle configuration d’exécution à distance de débogage. Nous pouvons passer à une configuration différente à partir du même emplacement. Mais lorsque nous voulons effectuer un débogage à distance, nous devons le basculer ici. Ensuite, nous devons appuyer sur le bouton de débogage pour exécuter cette commande.
Nous sommes maintenant instantanément connectés au processus en cours. Une fois cela fait, cela se sent et agit comme n’importe quelle instance de débogueur lancée depuis l’IDE. Je peux définir un point d’arrêt, passer par-dessus, inspecter des variables, etc., alors pourquoi le faire ?
Dans certains cas, exécuter le serveur localement dans l’IDE n’est pas pratique. Un bon exemple serait de déboguer un conteneur sur votre propre machine. Ce n’est peut-être pas anodin.
Implications de sécurité de JDWP
Appeler JDWP non sécurisé est inexact. Ce serait comme mettre les clés de votre maison et l’adresse de votre domicile dans un joli emballage cadeau avec une liste détaillée de vos objets de valeur triés par valeur devant votre maison. C’est une porte ouverte. Une porte ouverte n’est pas une faille de sécurité. C’est une porte ouverte !
JDWP est très peu sûr lorsqu’il est utilisé à distance. Localement, sur votre propre machine, ce n’est pas un problème, mais il n’a presque aucune protection de sécurité. Il n’y a pas de solution pour ça. Mais il existe une solution de contournement très partielle consistant à le tunneliser via SSH. C’est relativement banal. Utilisez simplement cette commande pour ouvrir un tunnel entre la machine distante et votre machine locale. Pour les deux côtés, cela ressemblera à un débogage local. Ainsi, l’exemple que j’ai montré précédemment (de la connexion à un serveur hôte local) fonctionnerait parfaitement avec cet hôte distant car SSH déplacera tous les paquets d’avant en arrière en toute sécurité.
Nous ne pouvons pas SSH dans un conteneur Kubernetes, mais nous pouvons transférer un port, ce qui est presque identique. Nous pouvons faire quelque chose de similaire à cette commande pour transférer le port du pod donné vers la machine locale et vice versa. Même idée que le tunneling SSH mais adapté au monde Kubernetes.
Dangers du débogage à distance
Dans cette dernière section, je veux parler des dangers du débogage à distance en production. Breakpoints pause, semble évident. C’est ce qu’ils sont ici pour faire. Mais si nous courons sur un serveur, nous le bloquons complètement par erreur. Nous pouvons utiliser des points de trace. Comme je l’ai dit, ils sont super. Mais ils ne remplacent pas les points d’arrêt, et un clic accidentel dans la gouttière peut littéralement arrêter votre serveur dans son élan.
JDWP permet effectivement l’exécution de code à distance. Vous permet d’accéder à tout le bytecode de l’application, ce qui revient en fait à donner accès au code source complet de votre serveur. Il permet aux attaquants de faire presque n’importe quoi car il n’a pas été conçu dans un souci de sécurité. Nous devons relancer l’application avec le débogage activé. Cela signifie tuer le processus en cours et le recommencer. Déconnecter les utilisateurs existants, etc. Ce n’est pas génial.
Certaines opérations dans le débogueur nécessitent plus d’une étape en termes de protocole. Par conséquent, vous pourriez envoyer une demande au débogueur, perdre votre connexion et le débogueur pourrait être bloqué dans un état problématique. Il s’agit d’une limitation inhérente au protocole JDWP et ne peut pas être contournée dans un débogueur standard. Le problème est que même des actions involontaires peuvent démolir un serveur. Un simple point d’arrêt conditionnel qui appelle une méthode dans le cadre de la condition peut démolir les performances du serveur et le faire planter.
JDWP permet effectivement l’exécution de code à distance. Vous permet d’accéder à tout le bytecode de l’application, ce qui revient en fait à donner accès à votre code source complet. Il permet aux attaquants de faire presque n’importe quoi car il n’a pas été conçu dans un souci de sécurité.
Imaginez placer un point d’arrêt où le mot de passe de l’utilisateur est transmis à l’authentification. Si JDWP est ouvert pour votre serveur, un membre de votre équipe pourrait l’utiliser, et vous ne le saurez jamais. Il n’y a aucun suivi du tout ! 60% des piratages de sécurité se produisent au sein de l’organisation. Si votre entreprise effectue un débogage à distance, elle n’a aucun moyen de savoir si un employé l’a utilisé pour manipuler l’état de l’application ou siphonner les détails de l’utilisateur. Il n’y a pas de suivi ou quoi que ce soit. Cela peut constituer une violation de diverses règles et réglementations, car cela pourrait exposer les données personnelles des utilisateurs. Le débogage à distance en production peut entraîner des risques de responsabilité.
Je discute de certaines des solutions à ces problèmes à la fois dans l’outillage de bas niveau et dans les solutions d’observabilité de niveau supérieur. Ceci est couvert dans le livre et dans le cours complet.
Dernier mot
Avec cela, nous avons terminé la première partie du cours. Si vous souhaitez consulter le cours complet; rendez-vous sur « debugagent.com » pour en savoir plus. La vidéo suivante couvre les stratégies de débogage et la science du débogage. Si vous avez des questions, veuillez utiliser la section des commentaires ci-dessous. Merci!