Carnet d'un développeur

les pérégrinations d'un developpeur sur le Web

Infrastructure :
Un load balancer, un varnish et 4 frontaux dont un dédié au backoffice (le reste n’a pas grande importance).
L’accès à la plateforme se fait via un serveur cli qui sert aussi de worker. Le tout est géré par un prestataire. Donc pour aller voir ce qu’il se passe sur le frontal 1, il faut se connecter à la cli puis de là se connecter au frontal 1.

Le Problème :
Un beau jour on se rend compte que Google Analytics signale un grand nombre de 404. Surprenant, d’autant plus que en allant voir les adresses en question, elles répondent parfaitement bien. Enfin … en apparence :).
Evidemment tant qu’elles étaient servies par Varnish, pas de problèmes. Par contre quand le cache varnish expire et qu’il interroge un frontal, ben sur les 3, il y en avait un qui était moisi.
Là ou c’est vicieux, c’est que du coup varnish ne met pas en cache la page en question et à force on finit par tomber sur un frontal correct et la page finie par être correcte.
(Ce problème était présent depuis 6 mois et a bien pourri le référencement avant que quelqu’un ne signale une anomalie menant à une investigation …).

La solution :
Je me suis aperçu bien vite que le problème était isolé sur un frontal. A partir du moment ou on sait que c’est un frontal sur 3 qui provoque l’erreur, la solution rapide consiste à le retirer de la boucle de varnish le temps de voir ce qui se passe.
Et pour voir ce qui se passe, il faut pouvoir accéder au frontal comme si il était encore en prod.

Facile :
Un petit tour dans le fichier host de Windows (c:\windows\system32\drivers\etc\hosts) et on ajoute le nom de notre site avec une redirection sur localhost :  127.0.0.1   www.lenomdemonsite.com
Après on utilise putty pour se connecter à la cli en ajoutant un petit détail :puttyconftunnelIl faut donc aller dans Connection > SSH > Tunnels et ajouter un tunnel.
Globalement, on lui donne :

  • Source Port local : 80 (port http classique)
  • Destination : c’est l’ip interne du frontal sur lequel on veut taper. Ici j’ai mis au hasard 10.50.60.1:80 (il faut spécifier le port à mapper car on peut utiliser exactement le même principe pour se connecter à MySQL (3306), solr (8983), autre …).
  • On clique sur Add (faut pas oublier sinon il ne le fait pas tout seul).

L’idée c’est que le frontal n’est pas directement accessible publiquement, mais est accessible en passant par la cli, on va donc se servir du flux entre notre PC et la cli pour atteindre le frontal.
L’énorme avantage évidemment c’est que du coup il devient possible d’appeler des pages du serveur, de passer les settings en debug et de rechercher d’où vient le problème sans perturber le reste de la prod.
Et j’avoue que le deuxième avantage c’est de ne pas perdre un temps fou à tenter d’expliquer au presta infra le besoin qu’on peut avoir à accéder directement à un frontal en particulier et de faire des allers/retours pour trouver une entente.

 

février 22nd, 2015

Posted In: Developpement Web

Laisser un commentaire

Pour rester motivé à écrire des choses pouvant potentiellement être utiles à d’autres et aussi à moi même (c’est chouette finalement mon blog est aussi un peu mon wiki perso), je m’en vais écrire des billets sur les commandes systèmes qui me sont utiles dans ma petite vie de développeur.
Aujourd’hui j’ai voulu faire un petit test de nodejs mais comme je suis pauvre je n’ai qu’un serveur avec une debian sur laquelle je mets tout et n’importe quoi.
J’ai donc suivi la procédure d’install de nodejs pour debian (2 lignes de commandes trouvées ici https://github.com/joyent/node/wiki/Installing-Node.js-via-package-manager#debian-and-ubuntu-based-linux-distributions pour les curieux).
Et puis j’ai voulu lancer un script server.js. Et là c’est le drame, erreur, le script ne démarre pas. Je devais pouvoir y accéder via le port 8080.

Bon évidemment il suffit de changer le port et le tour est joué mais j’ai voulu savoir qui l’utilisait car je pensais n’avoir qu’un apache sur le port 80.

J’ai donc utilisé cette magnifique commande :

netstat -tulpn| grep :8080

Qui m’a permis de déterminer que j’avais gitlab qui utilisait ce port :)

 

 

février 18th, 2015

Posted In: Infrastructure et Système

Mots-clés : , ,

Laisser un commentaire

mysql_copy_local_database
Pour moi qui aime bien tester tout un tas de chose sur des bases de données assez volumineuses et qui suis assez allergique à la ligne de commande, j’ai tendance à utiliser HeidiSQL (pour la plupart des opérations).

C’est un excellent client MySQL, très confortable avec plein de possibilités. C’est pratique aussi pour se connecter à des bases SQL server bien que rien ne soit prévu pour SQL server (il suffit d’essayer de créer une table pour s’en convaincre :)).

Quoiqu’il en soit, un besoin récurrent est de dupliquer une base histoire de faire un test, de potentiellement défoncer la base et de revenir à la base précédente. Je pars du principe que la base est déjà créé (via Heidi :)) :

la commande sera donc en shell sur le serveur MySQL :

mysqldump -u user -ppassword databasesource | mysql -u user -ppassword databasecible

précision : -ppassword n’est pas une faute de frappe, le password est bien attaché à l’option p :) Si votre password est 12345 et votre user « toto » il faudra écrire mysqldump -u toto -p12345.
Il faut bien sur s’assurer que toto/12345 ait les droits pour localhost.

février 4th, 2015

Posted In: MySQL

Page suivante »