Vous poussez un soupir de soulagement, car le QA a approuvé une fonctionnalité tant attendue pour le déploiement sur Prod. Cependant, dans le cadre du processus, il est d'abord déployé sur l'environnement UAT, où il existe des comptes de test qui peuvent être utilisés pour certifier que la fonctionnalité fonctionne en dehors du développeur local et des systèmes de test d'assurance qualité.
Mais... l'exécution de la suite de tests entraîne de nombreux échecs !
Répondez avec le toujours pertinent "Mais ça marche sur ma machine !"
Que fais-tu ? Vous êtes sûr que le code fonctionne. Certainement bien sûr. Peut-être que le problème vient alors de l’environnement UAT ? Mais quel pourrait être le problème avec l’environnement ? Peut-être que les comptes de test nouvellement créés sont mal configurés ? Probablement oui, pensez-vous. Vous avez accès aux journaux de l'environnement, mais le scénario pour lequel il échoue ne comporte aucun journal pour identifier le problème. Vous maudissez intérieurement vos développeurs ancestraux.
Une autre option ? Débogage à distance ! Bien que ce soit une bonne idée, elle est rarement pratique dans les environnements où les applications sont constamment utilisées. Si votre code se trouve dans le « chemin chaud », bonne chance pour déterminer quelles sont vos demandes. Cela peut également ralentir considérablement l'application.
Essentiellement, ce que vous voulez, c'est déboguer l'application, comme si elle était déployée sur votre machine locale, mais sur la base de données du serveur UAT. Mais comme le serveur UAT n'est pas directement accessible à votre application locale, vous n'avez pas de chance.
Ou l'êtes-vous ? Ne vous inquiétez pas, car un tunnel SSH est là à votre secours.
Qu'est-ce qu'un tunnel SSH ? Et comment l'utiliser ?
Réponse courte :
Le tunneling SSH permettra à votre application de se comporter comme si elle était déployée sur un système distant, via lequel la base de données UAT est accessible.
Réponse longue :
La commande Linux ssh fournit une fonctionnalité permettant de « transférer le port ». Certes, le terme « transfert de port » est plutôt non descriptif. Par conséquent, je vais laisser StackOverflow vous fournir une explication détaillée et beaucoup plus simple du tunneling SSH que ce que je peux ici. Vous pouvez le lire ici : https://unix.stackexchange.com/a/115906. Je vous recommande de lire la réponse car elle contient des diagrammes beaucoup plus faciles à comprendre que les réponses textuelles.
Cependant, je copierai quand même les sections pertinentes ici.
ssh -L 123:farawayhost:456 remotehostCopier après la connexionlocal : -L Spécifie que le port donné sur l'hôte local (client) doit être transféré vers l'hôte et le port donnés du côté distant.
ssh -L sourcePort:forwardToHost:onPort connectToHost signifie : connectez-vous avec ssh pour connectToHost et transférez toutes les tentatives de connexion au local sourcePort vers le port onPort sur la machine appelée forwardToHost, qui peut être atteint depuis la machine connectToHost.
Pour notre cas d'utilisation, notre exemple de commande sera :
ssh -L <Local Port>:<UAT Database IP>:<UAT Database Port> <JumpHost IP>
Remarque, ici, le JumpHost est un système qui peut se connecter à
Une fois que nous avons compris cela, tout le reste est du gâteau !
Vous pouvez simplement exécuter la commande et vous pourrez accéder à la base de données UAT sur votre hôte local :
Si vous devez vous connecter à plusieurs bases de données, vous devrez exécuter cette commande plusieurs fois. Ou vous pouvez écrire un script bash capable de lire dynamiquement un fichier de configuration pour ouvrir plusieurs tunnels SSH.
En tant que programmeur Java, je préfère m'occuper du code Java compilé statiquement plutôt que de m'inquiéter d'un langage typé dynamiquement comme bash. J'ai donc utilisé la bibliothèque jsch pour créer un projet extensible, qui crée et gère plusieurs tunnels SSH. Vous pouvez le consulter ici : https://github.com/darshitpp/java-ssh-tunnel
java-ssh-tunnel └── src └── main ├── java │ └── dev │ └── darshit │ └── java_ssh_tunnel │ ├── Main.java │ ├── MultiTunneler.java │ ├── Tunneler.java │ └── ssh │ ├── TunnelDetails.java │ └── UserDetails.java └── resources
Si tout se passe bien, vous verrez la sortie suivante sur votre sortie standard
Starting tunneling... <remoteHost>:<remotePort> is available on localhost:<localPort> Press Enter to terminate the tunnels...
Bien que ce qui précède soit très pratique, NE L'UTILISEZ PAS POUR VOUS CONNECTER À PROD. Oui, cela devait être écrit en gras avec emphase. Dois-je également imprimer le message sur stderr ? Commentez ci-dessous.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!