Trabalhando como um freelancer remoto tem muitos benefícios, mas a criação de um ambiente de trabalho distribuído eficaz pode ser um verdadeiro desafio. Claro, existem muitas abordagens que podem ser adotadas, e nenhuma das “melhores” formas se ajustará a todos. A organização do local de trabalho digital remoto é de fato algo 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 a que funciona bem para mim, especialmente em projetos remotos que envolvem desenvolvimento e administração de sistema. Eu acredito que essa abordagem tem uma série de vantagens, mas cada leitor deve considerar como adaptá-la da forma que funcione melhor para eles, com base em uma combinação de suas necessidades operacionais e preferências pessoais.

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

Meu próprio minisservidor pessoal

Uma primeira etapa importante na minha configuração é um Raspberry Pi 2 -powered servidor na minha própria casa , costumava 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, sou 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 perfeitamente. O único requisito real, em minha experiência, é que a largura de banda seja ilimitada ou muito barata.

Como um usuário residencial, tenho o roteador de rede doméstica mais barato que meu ISP poderia comprar, o que simplesmente não é suficiente para o que preciso fazer. Portanto, solicitei que o ISP colocasse o roteador em 'modo ponte', onde ele serve apenas como um terminador de conexão, oferecendo um PPPoE ponto final para exatamente um sistema conectado. Isso significa que o dispositivo para de funcionar como um ponto de acesso WiFi ou até mesmo como um roteador doméstico comum. Todas essas tarefas são realizadas por um roteador Mikrotik pequeno profissional RB951G-2HnD . Ele realiza o NOITE serviço para minha rede local (que eu numerei 10.10.10.0/24) e ofertas DHCP para dispositivos com fio e sem fio conectados a ele. O Mikrotik e o Raspberry Pi possuem endereços estáticos porque são usados ​​em contextos onde um endereço conhecido é necessário. No meu caso, esses 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, já que o objetivo é criar um SOHO ambiente de trabalho, não um local 24/7. (Para aqueles que exigem um endereço IP estático para seu servidor, é importante notar que o custo dos endereços IP estáticos continuou a cair e opções de IP VPN estático razoavelmente baratas estão disponíveis.) O corretor DNS que uso, Joker.com , oferece um serviço DNS dinâmico gratuito junto com todos os seus outros serviços, portanto, um subdomínio do meu domínio pessoal existe como um nome dinâmico. Eu uso este nome para conectar de fora a 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 doméstico pessoal.

Dados em qualquer lugar

Uma coisa significativa que o Raspberry Pi faz não oferta é redundância. Eu o equipei com um cartão de 32 GB e ainda são muitos dados a perder caso algo aconteça. Para contornar isso e garantir o acesso aos meus dados se houver problemas no acesso residencial à Internet, espelhei todos os meus dados em um servidor externo em nuvem. Como estou na Europa, faz sentido para mim obter o menor servidor bare-metal dedicado (ou seja, não virtualizado) de Online.net , que vem com uma CPU VIA de baixo custo, oferecendo 2 GB de RAM e 500 GB SSHD . Tal como acontece com o minisservidor Raspberry Pi, não preciso de alto desempenho de CPU ou mesmo de memória, então é uma combinação perfeita. (À parte, lembro-me do meu primeiro servidor “grande” que tinha duas CPUs 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 a minha interesse na otimização.)

Eu faço backup do meu Raspberry Pi para o servidor remoto em nuvem usando rdiff-backup . A julgar pelos tamanhos relativos dos sistemas, esses backups me proporcionarão um histórico virtualmente ilimitado. Outra coisa que tenho no servidor em nuvem é a instalação de ownCloud , que me permite executar um serviço particular do tipo Dropbox. O ownCloud como um produto está se movendo em direção a groupware e colaboração, então se torna ainda mais útil se mais pessoas o estiverem usando. Desde que comecei a usá-lo, literalmente não tenho qualquer dados locais cujo backup não foi feito no Raspberry Pi ou no servidor em nuvem, e a maioria deles tem backup duas vezes. Qualquer redundância de backup adicional que você possa fazer é sempre uma boa coisa, 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 estã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 próprio sincronizado com o Cloud ou, mais interessante, posso colocá-los diretamente no Raspberry Pi e usá-los de lá .

A última opção é possível graças a 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 qualquer servidor ao qual você tem acesso SSH (trabalhando com 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ê precisa de um servidor poderoso para desenvolvimento ou teste e - por algum motivo, basta ir lá e usar 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 apenas transferir os arquivos via SSHFS, em vez do que trabalhar em uma sessão SSH remota.

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

Ou talvez você precise processar arquivos de log grandes, mas não deseja 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 de que você precisa - mesmo que seja um enorme, pesado e orientado por GUI. O SSH oferece suporte à compactação em tempo real e o SSHFS faz uso dele, portanto, trabalhar com arquivos de texto é bastante favorável à largura de banda.

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

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 de extremidade SSH se ele quebrar. Isso é muito importante porque, por padrão, quando a conexão é interrompida, o ponto de montagem pode falhar abruptamente ou simplesmente travar (o que eu descobri ser mais comum). Realmente me parece que esta 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. Já que você pode se conectar por SSH com um nome de usuário arbitrário, isso “corrige” as coisas para que o sistema local pense que o usuário é o mesmo. Os direitos e permissões de acesso no sistema remoto aplicam-se normalmente para o 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 outros lugares 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 até os diretórios vinculados.
• -C - Ativa a compressão SSH. Isso é especialmente eficaz com metadados de arquivo e arquivos de texto, então é outra coisa que parece que deveria 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 largura de banda baixa ou uma conexão de Internet instável, você precisa 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 de 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 chaves SSH, e a maioria dos ambientes de desktop baseados em GTK que tentei iniciar seu próprio agente (ou “carteira”, ou como eles escolherem chamá-lo) automaticamente.

Alguns truques SSH avançados

Ter um ponto fixo na Internet que pode ser acessado remotamente de qualquer lugar do mundo, e que está em uma conexão de alta largura de banda - para mim é o meu sistema Raspberry Pi, e realmente poderia ser qualquer VPS genérico - reduz o estresse e permite que você faça todo tipo de coisa com troca e tunelamento de dados.

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

Outra situação que você pode enfrentar é a de ter acesso SSH a um servidor, mas sua porta 80 (ou qualquer outra) está protegida por firewall para a rede externa a partir da qual você se conecta. Para contornar isso, você pode usar SSH para encaminhar essa porta para sua máquina local e, em seguida, 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 outro 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 e a porta de destino. O -C O argumento permite a compactação, para que você possa obter novamente economia de largura de banda 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, ouvirá na porta 8080 do localhost, à 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 (assumindo que eles tenham endereços IP apropriados configurados) e podem permitir que você acesse a rede remota como se você estivesse fisicamente lá (contornando firewalls). Por razões técnicas e de segurança, isso requer acesso root em ambas as máquinas que estão sendo conectadas ao túnel, por isso é muito menos conveniente do que apenas usar o encaminhamento de porta ou SSHFS ou SCP. Este é para usuários avançados, que podem facilmente encontrar tutoriais sobre como fazer isso.

Escritório remoto em qualquer lugar

Você pode continuar a trabalhar mesmo enquanto espera seu carro no mecânico. Tweet

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