Desenvolvimento de software em qualquer lugar: meu local de trabalho remoto distribuído

Trabalhar como freelancer remoto tem muitos benefícios, mas configurar um ambiente de trabalho distribuído eficaz pode ser um verdadeiro desafio. É claro que existem muitas abordagens que se podem adotar, e nenhuma maneira “melhor” servirá para todos. A organização do local de trabalho digital remoto é realmente uma coisa muito pessoal, e o que funciona bem para um desenvolvedor pode não funcionar bem para outra pessoa.

Com isso em mente, a configuração que apresento aqui é simplesmente o que funciona bem para mim pessoalmente, especialmente em projetos remotos que envolvem desenvolvimento e administração de sistemas. Acredito que essa abordagem tenha várias vantagens, mas cada leitor deve considerar como adaptá-la da maneira que funcionar melhor para eles, com base em uma combinação de suas necessidades operacionais e preferências pessoais.

Minha abordagem é amplamente baseada em recursos oferecidos pelo SSH e ferramentas relacionadas no Linux. Observe que os usuários de MacOS e outros sistemas do tipo Unix também podem aproveitar os procedimentos descritos, na medida em que seus sistemas suportam as ferramentas descritas.

Meu Próprio Mini-Servidor Pessoal

Um primeiro passo importante na minha configuração é um servidor com Raspberry Pi 2 em minha própria casa, usado para hospedar tudo, desde meus repositórios de código-fonte até sites de demonstração.

Embora eu viaje, meu apartamento serve como minha “base fixa de operações” remota com conectividade decente à Internet (100 Mbit/s) e quase nenhuma latência adicional. Isso significa que, do meu apartamento, estou basicamente limitado apenas pela velocidade da rede de destino. A configuração que estou descrevendo funciona melhor com esse tipo de conectividade, embora não seja um requisito. Na verdade, também usei essa abordagem enquanto tinha uma conexão ADSL de largura de banda relativamente baixa, com a maioria das coisas funcionando bem. O único requisito real, na minha experiência, é que a largura de banda seja ilimitada ou barata.

Como usuário residencial, tenho o roteador de rede doméstica mais barato que meu ISP pode comprar, o que simplesmente não é suficiente para o que preciso fazer. Por isso, solicitei que o ISP colocasse o roteador em “modo ponte”, onde ele serve apenas como terminador de conexão, oferecendo um ponto final PPPoE para exatamente um sistema conectado. Isso significa que o dispositivo deixa de funcionar como ponto de acesso WiFi ou até mesmo como roteador doméstico comum. Todas essas tarefas são tratadas por um pequeno roteador profissional Mikrotik RB951G-2HnD. Ele executa o serviço NAT para minha rede local (que numerei 10.10.10.0/24) e oferece DHCP para dispositivos com e sem fio conectados a ela. O Mikrotik e o Raspberry Pi possuem endereços estáticos porque são usados ​​em contextos onde é necessário um endereço conhecido. No meu caso, são 10.10.10.1 e 10.10.10.10, respectivamente.

Minha conexão doméstica não tem um endereço IP estático. Para meus propósitos, este é apenas um pequeno inconveniente trabalhar remotamente, pois o objetivo é criar um ambiente de trabalho pessoal ou SOHO, não um local 24 horas por dia, 7 dias por semana. (Para aqueles que exigem um endereço IP estático para seu servidor, vale a pena notar que o custo dos endereços IP estáticos continuou a cair e opções de IP VPN estático bastante baratas estão disponíveis.) O corretor de DNS que eu uso, Joker.com , oferece um serviço de DNS dinâmico gratuito juntamente com todos os seus outros serviços, portanto, um subdomínio do meu domínio pessoal existe como um nome dinâmico. Eu uso esse nome para conectar de fora para minha própria rede, e o Mikrotik está configurado para passar SSH e HTTP através do NAT para o Raspberry Pi. Eu simplesmente preciso digitar o equivalente a ssh mydomain.example.com para fazer login no meu servidor pessoal pessoal.

Dados em qualquer lugar

Uma coisa significativa que o Raspberry Pi não oferece é a redundância. Eu o equipei com um cartão de 32 GB, e ainda há muitos dados a perder caso algo aconteça. Para contornar isso e garantir o acesso aos meus dados se o acesso residencial à Internet falhar, eu espelho todos os meus dados em um servidor externo semelhante à nuvem. Como estou na Europa, fez sentido para mim obter o menor servidor dedicado bare-metal (ou seja, não virtualizado) da Online.net, que vem com uma CPU VIA de baixo custo, oferecendo 2 GB de RAM e um SSHD de 500 GB. Tal como acontece com o mini-servidor Raspberry Pi, não preciso de alto desempenho da CPU ou mesmo memória, então esta é uma combinação perfeita. (Como um aparte, lembro do meu primeiro servidor “grande” que tinha dois processadores Pentium 3 e 1 GB de RAM, e provavelmente tinha metade da velocidade do Raspberry Pi 2, e como fizemos grandes coisas com ele, o que influenciou meu interesse em otimização.)

Eu faço backup do meu Raspberry Pi para o servidor remoto semelhante à nuvem usando o rdiff-backup. A julgar pelos tamanhos relativos dos sistemas, esses backups me darão um histórico praticamente ilimitado. Uma outra coisa que tenho no servidor semelhante à nuvem é uma instalação do ownCloud, que me permite executar um serviço privado semelhante ao Dropbox. O ownCloud como um produto está se movendo em direção ao groupware e à colaboração, por isso se torna ainda mais útil se mais pessoas o estiverem usando. Desde que comecei a usá-lo, literalmente não tenho nenhum dado local que não tenha backup no Raspberry Pi ou no servidor semelhante à nuvem, e a maioria deles é copiada duas vezes. Qualquer redundância de backup adicional que você possa fazer é sempre uma coisa boa, se você valoriza seus dados.

A “mágica” do SSHFS

A maior parte do meu trabalho hoje em dia envolve o desenvolvimento de coisas que não são diretamente relacionadas à web (chocante, eu sei!), então meu fluxo de trabalho geralmente segue um ciclo clássico de edição-compilação-execução. Dependendo das circunstâncias específicas de um projeto, posso ter seus arquivos localmente no meu laptop, posso colocá-los no diretório ownCloud-synced ou, mais interessante, posso colocá-los diretamente no Raspberry Pi e usá-los de lá .

A última opção é possível graças ao SSHFS, que me permite montar um diretório remoto do Raspberry Pi localmente. Isso é quase como uma pequena mágica: você pode ter um diretório remoto em qualquer servidor ao qual tenha acesso SSH (trabalhando sob as permissões que seu usuário tem no servidor) montado como um diretório local.

Tem um diretório de projeto remoto? Monte-o localmente e vá em frente. Se você precisar de um servidor poderoso para desenvolvimento ou teste e – por algum motivo, apenas ir lá e usar o vim no console não é uma opção – monte esse servidor localmente e faça o que quiser. Isso funciona especialmente bem quando estou em uma conexão de baixa largura de banda com a Internet: mesmo se eu trabalhar em um editor de texto de console, a experiência é muito melhor se eu executar esse editor localmente e depois transferir os arquivos via SSHFS, em vez de do que trabalhar em uma sessão SSH remota.

Precisa comparar vários diretórios /etc em diferentes servidores remotos? Sem problemas. Basta usar SSHFS para montar cada um deles localmente e depois usar diff (ou qualquer outra ferramenta aplicável) para compará-los.

Ou talvez você precise processar arquivos de log grandes, mas não queira instalar a ferramenta de análise de log no servidor (porque tem um zilhão de dependências) e, por qualquer motivo, copiar os logs é inconveniente. Mais uma vez, não é um problema. Basta montar o diretório de log remoto localmente via SSHFS e executar qualquer ferramenta que você precisar – mesmo que seja uma ferramenta enorme, pesada e orientada por GUI. O SSH suporta compactação em tempo real e o SSHFS faz uso dele, portanto, trabalhar com arquivos de texto é bastante amigável à largura de banda.

Para meus propósitos, uso as seguintes opções na linha de comando sshfs :

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

Veja o que essas opções de linha de comando fazem:

• -o reconnect - Diz ao sshfs para reconectar o ponto final SSH se ele quebrar. Isso é muito importante, pois, por padrão, quando a conexão é interrompida, o ponto de montagem falhará abruptamente ou simplesmente travará (o que achei mais comum). Realmente me parece que essa deve ser a opção padrão.
• -o idmap=user - Diz ao sshfs para mapear o usuário remoto (ou seja, o usuário com o qual estamos nos conectando) para ser o mesmo que o usuário local. Como você pode se conectar por SSH com um nome de usuário arbitrário, isso “conserta” as coisas para que o sistema local pense que o usuário é o mesmo. Os direitos e permissões de acesso no sistema remoto se aplicam normalmente ao usuário remoto.
• -o follow_symlinks - Embora você possa ter um número arbitrário de sistemas de arquivos remotos montados, acho mais conveniente montar apenas um diretório remoto, meu diretório inicial, e nele (na sessão SSH remota) posso criar links simbólicos para diretórios importantes em outro lugar no sistema remoto, como /srv ou /etc ou /var/log . Esta opção faz com que o sshfs resolva links simbólicos remotos em arquivos e diretórios, permitindo que você siga para os diretórios vinculados.
• -C - Ativa a compactação SSH. Isso é especialmente eficaz com metadados de arquivos e arquivos de texto, então é outra coisa que parece ser uma opção padrão.
• server.example.com:. - Este é o ponto final remoto. A primeira parte ( server.example.com neste exemplo) é o nome do host e a segunda parte (após os dois pontos) é o diretório remoto a ser montado. Neste caso, adicionei “.” para indicar o diretório padrão onde meu usuário termina após o login SSH, que é meu diretório inicial.
• server - O diretório local no qual o sistema de arquivos remoto será montado.

Especialmente se você estiver em uma conexão de Internet de baixa largura de banda ou instável, precisará usar SSHFS com autenticação de chave pública/privada SSH e um agente SSH local. Dessa forma, você não será solicitado a fornecer senhas (senhas do sistema ou senhas de chave SSH) ao usar SSHFS e o recurso de reconexão funcionará conforme anunciado. Observe que, se você não tiver o agente SSH configurado para fornecer a chave desbloqueada conforme necessário em sua sessão, o recurso de reconexão geralmente falhará. A web está cheia de tutoriais de chave SSH, e a maioria dos ambientes de desktop baseados em GTK que eu tentei iniciar seu próprio agente (ou “carteira”, ou o que eles escolherem para chamá-lo) automaticamente.

Alguns truques avançados de SSH

Ter um ponto fixo na Internet que seja acessível remotamente de qualquer lugar do mundo e que esteja em uma conexão de alta largura de banda – para mim é meu sistema Raspberry Pi, e realmente pode ser qualquer VPS genérico – reduz o estresse e permite que você faça todos os tipos de coisas com troca e encapsulamento de dados.

Precisa de um nmap rápido e está conectado por uma rede de telefonia móvel? Basta fazê-lo a partir desse servidor. Precisa copiar rapidamente alguns dados e o SSHFS é um exagero? Basta usar SCP simples.

Outra situação que você pode se deparar conosco, onde você tem acesso SSH a um servidor, mas sua porta 80 (ou qualquer outra) está protegida por firewall para a rede externa da qual você se conecta. Para contornar isso, você pode usar o SSH para encaminhar essa porta para sua máquina local e acessá-la por meio de localhost . Uma abordagem ainda mais interessante é usar o host ao qual você está conectado por SSH para encaminhar uma porta em outra máquina, possivelmente atrás do mesmo firewall. Se, por exemplo, você tiver os seguintes hosts:

• 192.168.77.15 - Um host na rede local remota atrás de um firewall, ao qual você precisa se conectar à sua porta 80
• foo.example.com - Um host ao qual você tem acesso SSH, que pode se conectar ao host acima
• seu sistema local, localhost

Um comando para encaminhar a porta 80 em 192.168.77.15 para localhost:8080 por meio do servidor SSH foo.example.com seria:

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

O argumento para -L especifica a porta local e o endereço de destino e a porta. O argumento -C habilita a compactação, para que você possa obter economia de largura de banda novamente e, finalmente, no final, basta digitar o nome do host SSH. Este comando abrirá uma sessão de shell SSH simples para o host e, além disso, escutará na porta 8080 do host local, à qual você pode se conectar.

Um dos truques mais impressionantes que o SSH desenvolveu nos últimos anos é sua capacidade de criar túneis VPN reais. Eles se manifestam como dispositivos de rede virtual em ambos os lados da conexão (supondo que tenham endereços IP apropriados configurados) e podem permitir o acesso à rede remota como se você estivesse fisicamente lá (ignorando firewalls). Por motivos técnicos e de segurança, isso requer acesso root em ambas as máquinas que estão sendo conectadas ao túnel, portanto, é muito menos conveniente do que apenas usar o encaminhamento de porta ou SSHFS ou SCP. Este é para os usuários avançados por aí, que podem encontrar facilmente tutoriais sobre como fazê-lo.

Escritório remoto em qualquer lugar

Sem a necessidade de trabalhar em um único local, você pode trabalhar literalmente em qualquer lugar que tenha uma conectividade de Internet decente usando as tecnologias e técnicas que descrevi (inclusive enquanto espera seu carro no mecânico). Monte sistemas estrangeiros sobre SSH, portas avançadas, túneis de perfuração, para acessar remotamente seu servidor privado ou dados baseados em nuvem, enquanto observa uma praia ensolarada ou bebe um café ecológico de nível moderno em uma cidade nebulosa. Apenas faça!