Desarrollo de software en cualquier lugar: mi lugar de trabajo remoto distribuido

Trabajar como autónomo remoto tiene muchos beneficios, pero configurar un entorno de trabajo distribuido efectivo puede ser un verdadero desafío. Por supuesto, hay muchos enfoques que uno puede tomar, y ninguna "mejor" forma se adaptará a todos. La organización del lugar de trabajo digital remoto es, de hecho, algo muy personal, y lo que funciona bien para un desarrollador puede no funcionar bien para otro.

Con eso en mente, la configuración que presento aquí es simplemente lo que funciona bien para mí personalmente, especialmente en proyectos remotos que involucran tanto el desarrollo como la administración del sistema. Creo que este enfoque tiene una serie de ventajas, pero cada lector debe considerar cómo adaptarlo de la manera que mejor funcione para ellos, en función de una combinación de sus necesidades operativas y preferencias personales.

Mi enfoque se basa en gran medida en las funciones que ofrece SSH y las herramientas relacionadas en Linux. Tenga en cuenta que los usuarios de MacOS y otros sistemas similares a Unix también pueden aprovechar los procedimientos descritos, en la medida en que sus sistemas admitan las herramientas descritas.

Mi Propio Mini-Servidor Personal

Un primer paso importante en mi configuración es un servidor alimentado por Raspberry Pi 2 en mi propia casa, utilizado para alojar todo, desde mis repositorios de código fuente hasta sitios de demostración.

Aunque viajo, mi apartamento sirve como mi "base de operaciones fija" remota con una conectividad a Internet decente (100 Mbit/seg) y casi sin latencia adicional. Esto significa que, desde mi apartamento, básicamente estoy limitado solo por la velocidad de la red de destino. La configuración que describo funciona mejor con este tipo de conectividad, aunque no es un requisito. De hecho, también he usado este enfoque cuando tenía una conexión ADSL de ancho de banda relativamente bajo, y la mayoría de las cosas funcionaban bien. El único requisito real, según mi experiencia, es que el ancho de banda no sea medido o sea muy barato.

Como usuario residencial, tengo el enrutador de red doméstica más barato que podría comprar mi ISP, que simplemente no es suficiente para lo que necesito hacer. Por lo tanto, solicité que el ISP coloque el enrutador en "modo puente", donde solo sirve como un terminador de conexión, ofreciendo un punto final PPPoE a exactamente un sistema conectado. Esto significa que el dispositivo deja de funcionar como un punto de acceso WiFi o incluso como un enrutador doméstico común. Todas estas tareas están a cargo de un pequeño enrutador profesional Mikrotik RB951G-2HnD. Realiza el servicio NAT para mi red local (que he numerado 10.10.10.0/24) y ofrece DHCP a los dispositivos cableados e inalámbricos conectados a ella. Mikrotik y Raspberry Pi tienen direcciones estáticas porque se usan en contextos donde se requiere una dirección conocida. En mi caso, esos son 10.10.10.1 y 10.10.10.10, respectivamente.

La conexión de mi casa no tiene una dirección IP estática. Para mis propósitos, esto es solo un inconveniente leve para trabajar de forma remota, ya que el objetivo es crear un entorno de trabajo personal o SOHO, no un sitio 24/7. (Para aquellos que requieren una dirección IP estática para su servidor, vale la pena señalar que el costo de las direcciones IP estáticas ha seguido bajando y hay opciones de IP VPN estáticas bastante económicas disponibles). El corredor de DNS que uso, Joker.com , ofrece un servicio DNS dinámico gratuito junto con todos sus otros servicios, por lo que existe un subdominio de mi dominio personal como nombre dinámico. Uso este nombre para conectarme desde el exterior a mi propia red, y Mikrotik está configurado para pasar SSH y HTTP a través de NAT a Raspberry Pi. Simplemente necesito escribir el equivalente de ssh mydomain.example.com para iniciar sesión en mi servidor doméstico personal.

Datos en cualquier lugar

Una cosa importante que Raspberry Pi no ofrece es la redundancia. Lo equipé con una tarjeta de 32 GB, y todavía hay muchos datos que perder en caso de que suceda algo. Para evitar eso, y para garantizar el acceso a mis datos si el acceso residencial a Internet falla, espejo todos mis datos en un servidor externo similar a una nube. Como estoy en Europa, tenía sentido para mí obtener el servidor bare-metal dedicado (es decir, no virtualizado) más pequeño de Online.net, que viene con una CPU VIA de gama baja, que ofrece 2 GB de RAM y un SSHD de 500 GB. Al igual que con el miniservidor Raspberry Pi, no necesito un alto rendimiento de la CPU ni memoria, por lo que esta es una combinación perfecta. (Aparte, recuerdo mi primer servidor "grande" que tenía dos CPU Pentium 3 y 1 GB de RAM, y probablemente tenía la mitad de la velocidad de la Raspberry Pi 2, y cómo hicimos grandes cosas con él, lo que ha influido en mi interés en la optimización.)

Hago una copia de seguridad de mi Raspberry Pi en el servidor remoto tipo nube usando rdiff-backup. A juzgar por los tamaños relativos de los sistemas, estas copias de seguridad me proporcionarán un historial prácticamente ilimitado. Otra cosa que tengo en el servidor similar a la nube es una instalación de ownCloud, que me permite ejecutar un servicio privado similar a Dropbox. ownCloud como producto se está moviendo hacia el trabajo en grupo y la colaboración, por lo que se vuelve aún más útil si más personas lo usan. Desde que comencé a usarlo, literalmente no tengo ningún dato local que no esté respaldado en la Raspberry Pi o en el servidor similar a la nube, y la mayor parte se respalda dos veces. Cualquier redundancia de respaldo adicional que pueda hacer siempre es algo bueno, si valora sus datos.

La “Magia” de SSHFS

La mayor parte de mi trabajo en estos días consiste en desarrollar cosas que no están directamente relacionadas con la web (¡es impactante, lo sé!), por lo que mi flujo de trabajo a menudo sigue un ciclo clásico de edición, compilación y ejecución. Dependiendo de las circunstancias específicas de un proyecto, puedo tener sus archivos localmente en mi computadora portátil, puedo colocarlos en el directorio sincronizado con ownCloud o, lo que es más interesante, puedo colocarlos directamente en la Raspberry Pi y usarlos desde allí. .

La última opción es posible gracias a SSHFS, que me permite montar un directorio remoto desde Raspberry Pi localmente. Esto es casi como una pequeña pieza de magia: puede tener un directorio remoto en cualquier servidor al que tenga acceso SSH (trabajando bajo los permisos que tiene su usuario en el servidor) montado como un directorio local.

¿Tiene un directorio de proyecto remoto? Móntelo localmente y hágalo. Si necesita un servidor potente para desarrollo o pruebas y, por alguna razón, simplemente ir allí y usar vim en la consola no es una opción, monte ese servidor localmente y haga lo que quiera. Esto funciona especialmente bien cuando estoy en una conexión a Internet con poco ancho de banda: incluso si trabajo en un editor de texto de consola, la experiencia es mucho mejor si ejecuto ese editor localmente y luego solo transfiero los archivos a través de SSHFS, en lugar de que trabajar en una sesión SSH remota.

¿Necesita comparar varios directorios /etc en diferentes servidores remotos? No hay problema. Simplemente use SSHFS para montar cada uno de ellos localmente y luego use diff (o cualquier otra herramienta aplicable) para compararlos.

O tal vez necesite procesar archivos de registro grandes, pero no desea instalar la herramienta de análisis de registros en el servidor (porque tiene miles de millones de dependencias) y, por alguna razón, copiar los registros es un inconveniente. Una vez más, no hay problema. Simplemente monte el directorio de registro remoto localmente a través de SSHFS y ejecute cualquier herramienta que necesite, incluso si es enorme, pesada y manejada por GUI. SSH admite la compresión sobre la marcha y SSHFS la utiliza, por lo que trabajar con archivos de texto es bastante amigable con el ancho de banda.

Para mis propósitos, utilizo las siguientes opciones en la línea de comando sshfs :

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

Esto es lo que hacen estas opciones de línea de comando:

• -o reconnect reconnect: le dice a sshfs que vuelva a conectar el punto final SSH si se rompe. Esto es muy importante ya que, de forma predeterminada, cuando se interrumpe la conexión, el punto de montaje fallará abruptamente o simplemente se bloqueará (lo que me pareció más común). Realmente me parece que esta debería ser la opción predeterminada.
• -o idmap=user - Le dice a sshfs que mapee el usuario remoto (es decir, el usuario con el que nos estamos conectando) para que sea el mismo que el usuario local. Dado que podría conectarse a través de SSH con un nombre de usuario arbitrario, esto "arregla" las cosas para que el sistema local piense que el usuario es el mismo. Los derechos de acceso y los permisos en el sistema remoto se aplican como de costumbre para el usuario remoto.
• -o follow_symlinks : si bien puede tener un número arbitrario de sistemas de archivos remotos montados, me parece más conveniente montar solo un directorio remoto, mi directorio de inicio, y en él (en la sesión SSH remota) puedo crear enlaces simbólicos a directorios importantes en otro lugar del sistema remoto, como /srv o /etc o /var/log . Esta opción hace que sshfs resuelva los enlaces simbólicos remotos en archivos y directorios, lo que le permite seguir hasta los directorios vinculados.
• -C - Activa la compresión SSH. Esto es especialmente efectivo con metadatos de archivos y archivos de texto, por lo que es otra cosa que parece que debería ser una opción predeterminada.
• server.example.com:. - Este es el punto final remoto. La primera parte ( server.example.com en este ejemplo) es el nombre del host y la segunda parte (después de los dos puntos) es el directorio remoto que se va a montar. En este caso, he añadido "." para indicar el directorio predeterminado donde termina mi usuario después del inicio de sesión SSH, que es mi directorio de inicio.
• server : el directorio local en el que se montará el sistema de archivos remoto.

Especialmente si tiene un ancho de banda bajo o una conexión a Internet inestable, necesita usar SSHFS con autenticación de clave pública/privada SSH y un agente SSH local. De esta manera, no se le solicitarán contraseñas (ya sea contraseñas del sistema o contraseñas de clave SSH) cuando use SSHFS y la función de reconexión funcionará como se anuncia. Tenga en cuenta que si no tiene configurado el agente SSH para que proporcione la clave desbloqueada según sea necesario dentro de su sesión, la función de reconexión generalmente fallará. La web está llena de tutoriales de claves SSH, y la mayoría de los entornos de escritorio basados ​​en GTK que he probado inician su propio agente (o "billetera", o como quieran llamarlo) automáticamente.

Algunos trucos avanzados de SSH

Tener un punto fijo en Internet al que se puede acceder de forma remota desde cualquier parte del mundo y que está en una conexión de gran ancho de banda (para mí es mi sistema Raspberry Pi, y realmente podría ser cualquier VPS genérico) reduce el estrés y te permite hacer todo tipo de cosas con el intercambio y tunelización de datos.

¿Necesita un nmap rápido y está conectado a través de una red de telefonía móvil? Solo hazlo desde ese servidor. ¿Necesita copiar rápidamente algunos datos y SSHFS es una exageración? Solo usa SCP simple.

Es posible que se enfrente a otra situación con nosotros en la que tiene acceso SSH a un servidor pero su puerto 80 (o cualquier otro) tiene un cortafuegos hacia la red externa desde la que se conecta. Para evitar esto, puede usar SSH para reenviar este puerto a su máquina local y luego acceder a él a través de localhost . Un enfoque aún más interesante es usar el host al que está conectado a través de SSH para reenviar un puerto en otra máquina, posiblemente detrás del mismo firewall. Si, por ejemplo, tiene los siguientes hosts:

• 192.168.77.15: un host en la red local remota detrás de un firewall, al que debe conectarse a su puerto 80
• foo.example.com: un host al que tiene acceso SSH, que puede conectarse al host anterior
• su sistema local, localhost

Un comando para reenviar el puerto 80 en 192.168.77.15 a localhost:8080 a través del servidor SSH foo.example.com sería:

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

El argumento de -L especifica el puerto local y la dirección y el puerto de destino. El argumento -C habilita la compresión, por lo que nuevamente puede lograr ahorros de ancho de banda y, finalmente, al final simplemente escribe el nombre del host SSH. Este comando abrirá una sesión de shell SSH simple en el host y, además, escuchará en el puerto localhost 8080, al que puede conectarse.

Uno de los trucos más impresionantes que ha desarrollado SSH en los últimos años es su capacidad para crear túneles VPN reales. Estos se manifiestan como dispositivos de red virtual en ambos lados de la conexión (suponiendo que tengan configuradas las direcciones IP adecuadas) y pueden permitirle acceder a la red remota como si estuviera físicamente allí (sin pasar por los cortafuegos). Tanto por razones técnicas como de seguridad, esto requiere acceso de raíz en ambas máquinas que se conectan con el túnel, por lo que es mucho menos conveniente que simplemente usar el reenvío de puertos o SSHFS o SCP. Este es para los usuarios avanzados, que pueden encontrar fácilmente tutoriales sobre cómo hacerlo.

Oficina remota en cualquier lugar

Despojado de la necesidad de trabajar desde una sola ubicación, puede trabajar literalmente desde cualquier lugar que tenga una conexión a Internet medio decente utilizando las tecnologías y técnicas que he descrito (incluso mientras espera su automóvil en el mecánico). Monte sistemas extranjeros a través de SSH, reenvíe puertos, perfore túneles para acceder a su servidor privado o datos basados ​​en la nube de forma remota, mientras observa una playa bañada por el sol o bebe un café ecológico de grado hipster en una ciudad con niebla. ¡Solo hazlo!