Développement de logiciels n'importe où : mon lieu de travail distant distribué

Travailler en tant qu'indépendant à distance présente de nombreux avantages, mais mettre en place un environnement de travail distribué efficace peut être un véritable défi. Bien sûr, il existe de nombreuses approches que l'on peut adopter, et aucune «meilleure» ne conviendra à tout le monde. L'organisation du travail numérique à distance est en effet une chose très personnelle, et ce qui fonctionne bien pour un développeur peut ne pas fonctionner du tout pour quelqu'un d'autre.

Dans cet esprit, la configuration que je présente ici est simplement ce qui fonctionne bien pour moi personnellement, en particulier sur les projets distants impliquant à la fois le développement et l'administration système. Je pense que cette approche présente un certain nombre d'avantages, mais chaque lecteur doit réfléchir à la manière de l'adapter de la manière qui lui convient le mieux, en fonction d'une combinaison de ses besoins opérationnels et de ses préférences personnelles.

Mon approche est largement basée sur les fonctionnalités offertes par SSH et les outils associés sous Linux. Notez que les utilisateurs de MacOS et d'autres systèmes de type Unix peuvent également tirer parti des procédures décrites, dans la mesure où leurs systèmes prennent en charge les outils décrits.

Mon propre mini-serveur personnel

Une première étape importante dans ma configuration est un serveur alimenté par Raspberry Pi 2 dans ma propre maison, utilisé pour tout héberger, de mes référentiels de code source aux sites de démonstration.

Bien que je voyage, mon appartement me sert de «base d'opérations fixe» à distance avec une connectivité Internet décente (100 Mbit / s) et presque aucune latence supplémentaire. Cela signifie que, depuis mon appartement, je ne suis essentiellement contraint que par la vitesse du réseau de destination. La configuration que je décris fonctionne mieux avec ce type de connectivité, bien que ce ne soit pas une exigence. En fait, j'ai également utilisé cette approche alors que j'avais une connexion ADSL à bande passante relativement faible, la plupart des choses fonctionnant très bien. La seule véritable exigence, d'après mon expérience, est que la bande passante soit illimitée ou très bon marché.

En tant qu'utilisateur résidentiel, j'ai le routeur de réseau domestique le moins cher que mon FAI pourrait acheter, ce qui n'est tout simplement pas suffisant pour ce que je dois faire. J'ai donc demandé au FAI de mettre le routeur en "mode pont", où il ne sert que de terminateur de connexion, offrant un point de terminaison PPPoE à exactement un système connecté. Cela signifie que l'appareil cesse de fonctionner comme un point d'accès WiFi ou même comme un routeur domestique commun. Toutes ces tâches sont gérées par un petit routeur professionnel Mikrotik RB951G-2HnD. Il exécute le service NAT pour mon réseau local (que j'ai numéroté 10.10.10.0/24) et offre DHCP aux appareils câblés et sans fil qui y sont connectés. Le Mikrotik et le Raspberry Pi ont des adresses statiques car ils sont utilisés dans des contextes où une adresse bien connue est requise. Dans mon cas, ce sont respectivement 10.10.10.1 et 10.10.10.10.

Ma connexion domestique n'a pas d'adresse IP statique. Pour mes besoins, il ne s'agit que d'un léger inconvénient de travailler à distance puisque l'objectif est de créer un environnement de travail personnel ou SOHO, et non un site 24h/24 et 7j/7. (Pour ceux qui ont besoin d'une adresse IP statique pour leur serveur, il convient de noter que le coût des adresses IP statiques a continué de baisser et que des options IP VPN statiques relativement peu coûteuses sont disponibles.) Le courtier DNS que j'utilise, Joker.com , propose un service DNS dynamique gratuit en plus de tous ses autres services, de sorte qu'un sous-domaine de mon domaine personnel existe en tant que nom dynamique. J'utilise ce nom pour me connecter de l'extérieur à mon propre réseau, et le Mikrotik est configuré pour transmettre SSH et HTTP via le NAT au Raspberry Pi. J'ai simplement besoin de taper l'équivalent de ssh mydomain.example.com pour me connecter à mon serveur personnel.

Des données partout

Une chose importante que le Raspberry Pi n'offre pas est la redondance. Je l'ai équipé d'une carte de 32 Go, et c'est encore beaucoup de données à perdre en cas d'incident. Pour contourner ce problème et garantir l'accès à mes données en cas de panne de l'accès Internet résidentiel, je mets en miroir toutes mes données sur un serveur externe de type cloud. Depuis que je suis en Europe, il était logique pour moi d'obtenir le plus petit serveur bare-metal dédié (c'est-à-dire non virtualisé) d'Online.net, qui est livré avec un processeur VIA bas de gamme, offrant 2 Go de RAM et un SSHD de 500 Go. Comme avec le mini-serveur Raspberry Pi, je n'ai pas besoin de performances CPU élevées ni même de mémoire, c'est donc un match parfait. (En passant, je me souviens de mon premier "gros" serveur qui avait deux processeurs Pentium 3 et 1 Go de RAM, et était probablement la moitié de la vitesse du Raspberry Pi 2, et comment nous avons fait de grandes choses avec, ce qui a influencé mon intérêt pour l'optimisation.)

Je sauvegarde mon Raspberry Pi sur le serveur distant de type cloud à l'aide de rdiff-backup. À en juger par la taille relative des systèmes, ces sauvegardes me procureront un historique pratiquement illimité. Une autre chose que j'ai sur le serveur de type cloud est une installation de ownCloud, qui me permet d'exécuter un service privé de type Dropbox. ownCloud en tant que produit évolue vers le groupware et la collaboration, il devient donc encore plus utile si plus de personnes l'utilisent. Depuis que j'ai commencé à l'utiliser, je n'ai littéralement aucune donnée locale qui ne soit sauvegardée ni sur le Raspberry Pi ni sur le serveur de type cloud, et la plupart d'entre elles sont sauvegardées deux fois. Toute redondance de sauvegarde supplémentaire que vous pouvez effectuer est toujours une bonne chose, si vous tenez à vos données.

La "Magie" de SSHFS

La plupart de mon travail ces jours-ci consiste à développer des choses qui ne sont pas directement liées au Web (choquant, je sais !), donc mon flux de travail suit souvent un cycle classique d'édition-compilation-exécution. Selon les circonstances spécifiques d'un projet, je peux soit avoir ses fichiers localement sur mon ordinateur portable, je peux les mettre dans le répertoire synchronisé d'ownCloud, ou, plus intéressant, je peux les placer directement sur le Raspberry Pi et les utiliser à partir de là .

Cette dernière option est rendue possible grâce à SSHFS, qui me permet de monter un répertoire distant depuis le Raspberry Pi en local. C'est presque comme un petit morceau de magie : vous pouvez avoir un répertoire distant sur n'importe quel serveur auquel vous avez un accès SSH (fonctionnant avec les permissions dont votre utilisateur dispose sur le serveur) monté en tant que répertoire local.

Vous avez un répertoire de projet distant ? Montez-le localement et allez-y. Si vous avez besoin d'un serveur puissant pour le développement ou les tests et - pour une raison quelconque, y aller et utiliser vim dans la console n'est pas une option - montez ce serveur localement et faites ce que vous voulez. Cela fonctionne particulièrement bien lorsque je suis sur une connexion Internet à faible bande passante : même si je travaille dans un éditeur de texte de console, l'expérience est bien meilleure si j'exécute cet éditeur localement, puis que je transfère simplement les fichiers via SSHFS, plutôt que de travailler sur une session SSH distante.

Besoin de comparer plusieurs répertoires /etc sur différents serveurs distants ? Aucun problème. Utilisez simplement SSHFS pour monter chacun d'eux localement, puis utilisez diff (ou tout autre outil applicable) pour les comparer.

Ou peut-être avez-vous besoin de traiter des fichiers journaux volumineux mais vous ne souhaitez pas installer l'outil d'analyse de journaux sur le serveur (car il a des millions de dépendances) et pour une raison quelconque, la copie des journaux n'est pas pratique. Encore une fois, pas de problème. Montez simplement le répertoire des journaux distants localement via SSHFS et exécutez l'outil dont vous avez besoin, même s'il s'agit d'un outil énorme, lourd et piloté par une interface graphique. SSH prend en charge la compression à la volée et SSHFS l'utilise, donc travailler avec des fichiers texte est assez respectueux de la bande passante.

Pour mes besoins, j'utilise les options suivantes sur la ligne de commande sshfs :

sshfs -o reconnect -o idmap=user -o follow_symlinks -C server.example.com:. server

Voici ce que font ces options de ligne de commande :

• -o reconnect - Indique à sshfs de reconnecter le point de terminaison SSH en cas de panne. Ceci est très important car par défaut, lorsque la connexion est interrompue, le point de montage échouera brusquement ou se bloquera simplement (ce que j'ai trouvé plus courant). Il me semble vraiment que cela devrait être l'option par défaut.
• -o idmap=user - Indique à sshfs de mapper l'utilisateur distant (c'est-à-dire l'utilisateur avec lequel nous nous connectons) pour qu'il soit le même que l'utilisateur local. Comme vous pouvez vous connecter via SSH avec un nom d'utilisateur arbitraire, cela "corrige" les choses afin que le système local pense que l'utilisateur est le même. Les droits d'accès et les autorisations sur le système distant s'appliquent comme d'habitude pour l'utilisateur distant.
• -o follow_symlinks - Bien que vous puissiez avoir un nombre arbitraire de systèmes de fichiers distants montés, je trouve plus pratique de monter un seul répertoire distant, mon répertoire personnel, et dans celui-ci (dans la session SSH distante), je peux créer des liens symboliques vers des répertoires importants ailleurs sur le système distant, comme /srv ou /etc ou /var/log . Cette option permet à sshfs de résoudre les liens symboliques distants en fichiers et répertoires, vous permettant de suivre les répertoires liés.
• -C - Active la compression SSH. Ceci est particulièrement efficace avec les métadonnées de fichiers et les fichiers texte, c'est donc une autre chose qui semble être une option par défaut.
• server.example.com:. - Il s'agit du terminal distant. La première partie ( server.example.com dans cet exemple) est le nom d'hôte et la seconde partie (après les deux-points) est le répertoire distant à monter. Dans ce cas, j'ai ajouté "." pour indiquer le répertoire par défaut où mon utilisateur se retrouve après la connexion SSH, qui est mon répertoire personnel.
• server - Le répertoire local dans lequel le système de fichiers distant sera monté.

Surtout si vous êtes sur une connexion Internet à faible bande passante ou instable, vous devez utiliser SSHFS avec une authentification par clé publique/privée SSH et un agent SSH local. De cette façon, vous ne serez pas invité à entrer des mots de passe (soit des mots de passe système, soit des mots de passe de clé SSH) lors de l'utilisation de SSHFS et la fonction de reconnexion fonctionnera comme annoncé. Notez que si vous n'avez pas configuré l'agent SSH pour qu'il fournisse la clé déverrouillée selon les besoins de votre session, la fonction de reconnexion échouera généralement. Le Web regorge de didacticiels clés SSH, et la plupart des environnements de bureau basés sur GTK que j'ai essayés démarrent automatiquement leur propre agent (ou "portefeuille", ou tout ce qu'ils choisissent de l'appeler).

Quelques astuces SSH avancées

Avoir un point fixe sur Internet qui est accessible à distance de n'importe où dans le monde, et qui est sur une connexion à haut débit - pour moi, c'est mon système Raspberry Pi, et ça pourrait vraiment être n'importe quel VPS générique - réduit le stress et vous permet de faire toutes sortes de choses avec l'échange et la tunnellisation des données.

Besoin d'un nmap rapide et vous êtes connecté via un réseau de téléphonie mobile ? Faites-le simplement à partir de ce serveur. Vous avez besoin de copier rapidement des données et SSHFS est exagéré ? Utilisez simplement SCP.

Une autre situation dans laquelle vous pouvez vous retrouver face à nous est que vous avez un accès SSH à un serveur mais que son port 80 (ou tout autre) est protégé par un pare-feu vers le réseau extérieur à partir duquel vous vous connectez. Pour contourner ce problème, vous pouvez utiliser SSH pour transférer ce port vers votre ordinateur local, puis y accéder via localhost . Une approche encore plus intéressante consiste à utiliser l'hôte auquel vous êtes connecté via SSH pour rediriger un port sur une autre machine, éventuellement derrière le même pare-feu. Si, par exemple, vous avez les hébergeurs suivants :

• 192.168.77.15 - Un hôte du réseau local distant derrière un pare-feu, auquel vous devez vous connecter sur son port 80
• foo.example.com - Un hôte auquel vous avez un accès SSH, qui peut se connecter à l'hôte ci-dessus
• votre système local, localhost

Une commande pour transférer le port 80 sur 192.168.77.15 vers localhost:8080 via le serveur SSH foo.example.com serait :

ssh -L 8080:192.168.77.15:80 -C foo.example.com

L'argument de -L spécifie le port local, ainsi que l'adresse et le port de destination. L'argument -C active la compression, de sorte que vous pouvez à nouveau réaliser des économies de bande passante, et enfin à la fin, vous tapez simplement le nom d'hôte SSH. Cette commande ouvrira une session shell SSH simple sur l'hôte, et en plus de cela, écoutera sur le port localhost 8080, auquel vous pouvez vous connecter.

L'une des astuces les plus impressionnantes que SSH a développées ces dernières années est sa capacité à créer de véritables tunnels VPN. Ceux-ci se manifestent comme des périphériques réseau virtuels des deux côtés de la connexion (en supposant qu'ils disposent des adresses IP appropriées) et peuvent vous permettre d'accéder au réseau distant comme si vous y étiez physiquement (en contournant les pare-feu). Pour des raisons techniques et de sécurité, cela nécessite un accès root sur les deux machines connectées au tunnel, c'est donc beaucoup moins pratique que d'utiliser simplement la redirection de port ou SSHFS ou SCP. Celui-ci est destiné aux utilisateurs avancés, qui peuvent facilement trouver des tutoriels sur la façon de le faire.

Bureau à distance n'importe où

Débarrassé de la nécessité de travailler à partir d'un seul endroit, vous pouvez travailler littéralement à partir de n'importe quel endroit disposant d'une connectivité Internet à moitié décente en utilisant les technologies et les techniques que j'ai décrites (y compris en attendant votre voiture chez le mécanicien). Montez des systèmes étrangers sur SSH, transférez des ports, percez des tunnels pour accéder à distance à votre serveur privé ou à vos données basées sur le cloud, tout en surplombant une plage ensoleillée ou en buvant un café écologique de qualité hipster dans une ville brumeuse. Fais-le!