Sviluppo software ovunque: il mio posto di lavoro remoto distribuito

Lavorare come libero professionista a distanza ha molti vantaggi, ma creare un ambiente di lavoro distribuito efficace può essere una vera sfida. Naturalmente, ci sono molti approcci che si possono adottare e nessun singolo modo "migliore" si adatta a tutti. L'organizzazione del posto di lavoro digitale in remoto è davvero una cosa molto personale e ciò che funziona bene per uno sviluppatore potrebbe non funzionare affatto per qualcun altro.

Con questo in mente, l'impostazione che presento qui è semplicemente ciò che funziona bene per me personalmente, specialmente su progetti remoti che coinvolgono sia lo sviluppo che l'amministrazione del sistema. Credo che questo approccio abbia una serie di vantaggi, ma ogni lettore dovrebbe considerare come adattarlo in un modo che funzioni meglio per loro, in base a una combinazione delle loro esigenze operative e preferenze personali.

Il mio approccio si basa in gran parte sulle funzionalità offerte da SSH e sui relativi strumenti su Linux. Si noti che anche gli utenti di MacOS e altri sistemi simili a Unix possono trarre vantaggio dalle procedure descritte, nella misura in cui i loro sistemi supportano gli strumenti descritti.

Il mio mini-server personale

Un primo passo importante nella mia configurazione è un server basato su Raspberry Pi 2 a casa mia, utilizzato per ospitare qualsiasi cosa, dai miei repository di codice sorgente ai siti demo.

Anche se viaggio, il mio appartamento funge da "base operativa fissa" remota con connettività Internet decente (100 Mbit/sec) e quasi nessuna latenza aggiuntiva. Ciò significa che, dal mio appartamento, sono sostanzialmente vincolato solo dalla velocità della rete di destinazione. La configurazione che sto descrivendo funziona meglio con questo tipo di connettività, sebbene non sia un requisito. In effetti, ho utilizzato questo approccio anche mentre avevo una connessione ADSL a larghezza di banda relativamente bassa, con la maggior parte delle cose che funzionavano bene. L'unico vero requisito, secondo la mia esperienza, è che la larghezza di banda sia illimitata o poco costosa.

Come utente residenziale, ho il router di rete domestica più economico che il mio ISP potrebbe acquistare, il che semplicemente non è abbastanza per quello che devo fare. Ho quindi chiesto all'ISP di mettere il router in "modalità bridge", dove funge solo da terminatore di connessione, offrendo un endpoint PPPoE esattamente a un sistema connesso. Ciò significa che il dispositivo smette di funzionare come punto di accesso WiFi o addirittura come un comune router domestico. Tutte queste attività sono gestite da un piccolo router Mikrotik professionale RB951G-2HnD. Esegue il servizio NAT per la mia rete locale (che ho numerato 10.10.10.0/24) e offre DHCP ai dispositivi cablati e wireless ad essa collegati. Il Mikrotik e il Raspberry Pi hanno indirizzi statici perché vengono utilizzati in contesti in cui è richiesto un indirizzo noto. Nel mio caso, quelli sono rispettivamente 10.10.10.1 e 10.10.10.10.

La mia connessione domestica non ha un indirizzo IP statico. Per i miei scopi, questo è solo un lieve inconveniente lavorare in remoto poiché l'obiettivo è creare un ambiente di lavoro personale o SOHO, non un sito 24 ore su 24, 7 giorni su 7. (Per coloro che richiedono un indirizzo IP statico per il proprio server, vale la pena notare che il costo degli indirizzi IP statici ha continuato a diminuire e sono disponibili opzioni IP VPN statiche abbastanza economiche.) Il broker DNS che utilizzo, Joker.com , offre un servizio DNS dinamico gratuito insieme a tutti gli altri suoi servizi, quindi un sottodominio del mio dominio personale esiste come nome dinamico. Uso questo nome per connettermi dall'esterno alla mia rete e Mikrotik è configurato per passare SSH e HTTP attraverso il NAT al Raspberry Pi. Devo semplicemente digitare l'equivalente di ssh mydomain.example.com per accedere al mio server di casa personale.

Dati ovunque

Una cosa significativa che il Raspberry Pi non offre è la ridondanza. L'ho dotato di una scheda da 32 GB e ci sono ancora molti dati da perdere nel caso succeda qualcosa. Per aggirare questo problema e per garantire l'accesso ai miei dati in caso di singhiozzo dell'accesso a Internet residenziale, rispecchio tutti i miei dati su un server esterno simile a un cloud. Dato che sono in Europa, per me aveva senso ottenere il più piccolo server dedicato bare-metal (cioè non virtualizzato) da Online.net, che viene fornito con una CPU VIA di fascia bassa, che offre 2 GB di RAM e un SSHD da 500 GB. Come con il mini-server Raspberry Pi, non ho bisogno di elevate prestazioni della CPU o persino di memoria, quindi questa è una combinazione perfetta. (Per inciso, ricordo il mio primo server "grande" che aveva due CPU Pentium 3 e 1 GB di RAM, ed era probabilmente la metà della velocità del Raspberry Pi 2, e come abbiamo fatto grandi cose con esso, il che ha influenzato il mio interesse per l'ottimizzazione.)

Eseguo il backup del mio Raspberry Pi sul server remoto simile a un cloud utilizzando rdiff-backup. A giudicare dalle dimensioni relative dei sistemi, questi backup mi daranno una cronologia praticamente illimitata. Un'altra cosa che ho sul server simile al cloud è un'installazione di ownCloud, che mi consente di eseguire un servizio privato simile a Dropbox. ownCloud come prodotto si sta spostando verso il groupware e la collaborazione, quindi diventa ancora più utile se più persone lo utilizzano. Da quando ho iniziato a usarlo, non ho letteralmente alcun dato locale di cui non sia stato eseguito il backup né sul Raspberry Pi né sul server simile al cloud e la maggior parte di essi viene sottoposta a backup due volte. Qualsiasi ulteriore ridondanza di backup che puoi fare è sempre una buona cosa, se dai valore ai tuoi dati.

La "Magia" di SSHFS

La maggior parte del mio lavoro in questi giorni riguarda lo sviluppo di materiale che non è direttamente correlato al Web (scioccante, lo so!), quindi il mio flusso di lavoro segue spesso un classico ciclo di modifica-compilazione-esecuzione. A seconda delle circostanze specifiche di un progetto, potrei avere i suoi file localmente sul mio laptop, potrei metterli nella directory sincronizzata con il cloud o, cosa più interessante, potrei posizionarli direttamente sul Raspberry Pi e usarli da lì .

Quest'ultima opzione è resa possibile grazie a SSHFS, che mi consente di montare una directory remota dal Raspberry Pi localmente. Questo è quasi come un piccolo pezzo di magia: puoi avere una directory remota su qualsiasi server a cui hai accesso SSH (lavorando con i permessi che il tuo utente ha sul server) montata come directory locale.

Hai una directory di progetto remota? Montalo localmente e provalo. Se hai bisogno di un server potente per lo sviluppo o il test e, per qualche ragione, andare lì e usare vim nella console non è un'opzione, monta quel server localmente e fai quello che vuoi. Funziona particolarmente bene quando sono su una connessione a Internet con larghezza di banda ridotta: anche se lavoro in un editor di testo per console, l'esperienza è molto migliore se eseguo quell'editor localmente e poi trasferisco i file tramite SSHFS, piuttosto piuttosto che lavorare su una sessione SSH remota.

Hai bisogno di confrontare diverse directory /etc su diversi server remoti? Nessun problema. Basta usare SSHFS per montarli localmente e quindi utilizzare diff (o qualsiasi altro strumento applicabile) per confrontarli.

O forse è necessario elaborare file di registro di grandi dimensioni ma non si desidera installare lo strumento di analisi dei registri sul server (perché ha un miliardo di dipendenze) e per qualsiasi motivo copiare i registri è scomodo. Ancora una volta, nessun problema. Basta montare la directory di registro remota localmente tramite SSHFS ed eseguire qualsiasi strumento di cui hai bisogno, anche se è un enorme, pesante e guidato dalla GUI. SSH supporta la compressione al volo e SSHFS ne fa uso, quindi lavorare con i file di testo è abbastanza favorevole alla larghezza di banda.

Per i miei scopi, utilizzo le seguenti opzioni sulla riga di comando sshfs :

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

Ecco cosa fanno queste opzioni della riga di comando:

• -o reconnect - Dice a sshfs di riconnettere l'end-point SSH se si interrompe. Questo è molto importante poiché per impostazione predefinita, quando la connessione si interrompe, il punto di montaggio fallirà improvvisamente o semplicemente si bloccherà (cosa che ho trovato più comune). Mi sembra davvero che questa dovrebbe essere l'opzione predefinita.
• -o idmap=user - Dice a sshfs di mappare l'utente remoto (cioè l'utente con cui ci stiamo connettendo) in modo che sia lo stesso dell'utente locale. Dal momento che potresti connetterti tramite SSH con un nome utente arbitrario, questo "ripara" le cose in modo che il sistema locale pensi che l'utente sia lo stesso. I diritti di accesso e le autorizzazioni sul sistema remoto si applicano come di consueto per l'utente remoto.
• -o follow_symlinks - Sebbene tu possa avere un numero arbitrario di file system remoti montati, trovo più conveniente montare solo una directory remota, la mia home directory, e in essa (nella sessione SSH remota) posso creare collegamenti simbolici a directory importanti altrove sul sistema remoto, come /srv o /etc o /var/log . Questa opzione fa in modo che sshfs risolva i collegamenti simbolici remoti in file e directory, consentendoti di seguire le directory collegate.
• -C - Attiva la compressione SSH. Ciò è particolarmente efficace con i metadati dei file e i file di testo, quindi è un'altra cosa che sembra dovrebbe essere un'opzione predefinita.
• server.example.com:. - Questo è l'end-point remoto. La prima parte ( server.example.com in questo esempio) è il nome host e la seconda parte (dopo i due punti) è la directory remota da montare. In questo caso, ho aggiunto "." per indicare la directory predefinita in cui finisce il mio utente dopo l'accesso SSH, che è la mia home directory.
• server - La directory locale in cui verrà montato il file system remoto.

Soprattutto se si dispone di una larghezza di banda ridotta o di una connessione Internet instabile, è necessario utilizzare SSHFS con l'autenticazione con chiave pubblica/privata SSH e un agente SSH locale. In questo modo, non ti verranno richieste le password (password di sistema o password della chiave SSH) quando utilizzi SSHFS e la funzione di riconnessione funzionerà come pubblicizzato. Tieni presente che se l'agente SSH non è configurato in modo che fornisca la chiave sbloccata secondo necessità all'interno della sessione, la funzione di riconnessione di solito non riesce. Il Web è pieno di tutorial sulle chiavi SSH e la maggior parte degli ambienti desktop basati su GTK che ho provato avviano automaticamente il proprio agente (o "portafoglio", o qualunque cosa scelgano di chiamarlo).

Alcuni trucchi SSH avanzati

Avere un punto fisso su Internet che è accessibile in remoto da qualsiasi parte del mondo e che è su una connessione a banda larga – per me è il mio sistema Raspberry Pi, e potrebbe davvero essere qualsiasi VPS generico – riduce lo stress e ti permette di fare ogni genere di cose con lo scambio e il tunneling dei dati.

Hai bisogno di una rapida nmap e sei connesso tramite una rete di telefonia mobile? Basta farlo da quel server. Hai bisogno di copiare rapidamente alcuni dati in giro e SSHFS è eccessivo? Usa semplicemente SCP.

Un'altra situazione che potresti trovarti di fronte a noi in cui hai accesso SSH a un server ma la sua porta 80 (o qualsiasi altra) è protetta da un firewall sulla rete esterna da cui ti connetti. Per aggirare questo problema, puoi utilizzare SSH per inoltrare questa porta al tuo computer locale e quindi accedervi tramite localhost . Un approccio ancora più interessante consiste nell'utilizzare l'host a cui si è connessi tramite SSH per inoltrare una porta su un'altra macchina, possibilmente dietro lo stesso firewall. Se, ad esempio, hai i seguenti host:

• 192.168.77.15 - Un host nella rete locale remota dietro un firewall, a cui è necessario connettersi alla sua porta 80
• foo.example.com - Un host a cui hai accesso SSH, che può connettersi all'host sopra
• il tuo sistema locale, localhost

Un comando per inoltrare la porta 80 su 192.168.77.15 a localhost:8080 tramite il server SSH foo.example.com sarebbe:

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

L'argomento in -L specifica la porta locale e l'indirizzo e la porta di destinazione. L'argomento -C abilita la compressione, quindi puoi di nuovo ottenere un risparmio di larghezza di banda e, infine, alla fine devi semplicemente digitare il nome host SSH. Questo comando aprirà una semplice sessione di shell SSH per l'host e, in aggiunta, ascolterà sulla porta 8080 di localhost, a cui puoi connetterti.

Uno dei trucchi più impressionanti che SSH ha sviluppato negli ultimi anni è la sua capacità di creare veri e propri tunnel VPN. Questi si manifestano come dispositivi di rete virtuale su entrambi i lati della connessione (supponendo che dispongano di indirizzi IP impostati) e possono consentire l'accesso alla rete remota come se ci si trovasse fisicamente (bypassando i firewall). Per ragioni sia tecniche che di sicurezza, ciò richiede l'accesso come root su entrambe le macchine che sono collegate al tunnel, quindi è molto meno conveniente che usare semplicemente il port forwarding o SSHFS o SCP. Questo è per gli utenti avanzati là fuori, che possono trovare facilmente tutorial su come farlo.

Ufficio remoto ovunque

Privato della necessità di lavorare da un'unica posizione, puoi lavorare letteralmente da qualsiasi luogo che abbia una connettività Internet decente utilizzando le tecnologie e le tecniche che ho delineato (anche mentre aspetti la tua auto dal meccanico). Installa sistemi stranieri su SSH, inoltra porte, perfora tunnel, per accedere in remoto al tuo server privato o ai dati basati su cloud, mentre guardi una spiaggia baciata dal sole o bevi un caffè ecologico di qualità hipster in una città nebbiosa. Fallo e basta!