Dezvoltare software oriunde: locul meu de lucru la distanță distribuit

Lucrul ca freelancer la distanță are multe beneficii, dar crearea unui mediu de lucru distribuit eficient poate fi o adevărată provocare. Desigur, există multe abordări pe care cineva le poate adopta și nicio modalitate „cea mai bună” nu se va potrivi tuturor. Organizarea la distanță la locul de muncă digital este într-adevăr un lucru foarte personal, iar ceea ce funcționează bine pentru un dezvoltator poate să nu funcționeze deloc bine pentru altcineva.

Având în vedere asta, configurația pe care o prezint aici este pur și simplu ceea ce funcționează bine pentru mine personal, în special în proiectele de la distanță care implică atât dezvoltarea, cât și administrarea sistemului. Cred că această abordare are o serie de avantaje, dar fiecare cititor ar trebui să ia în considerare cum să adapteze acest lucru într-un mod care funcționează cel mai bine pentru el, pe baza unei combinații a nevoilor sale operaționale și a preferințelor personale.

Abordarea mea se bazează în mare parte pe caracteristicile oferite de SSH și instrumentele conexe pe Linux. Rețineți că utilizatorii MacOS și alte sisteme asemănătoare Unix pot profita și de procedurile descrise, în măsura în care sistemele lor acceptă instrumentele descrise.

Propriul meu mini-server personal

Un prim pas important în configurarea mea este un server alimentat cu Raspberry Pi 2 în propria mea casă, folosit pentru a găzdui totul, de la depozitele mele de cod sursă la site-uri demonstrative.

Deși călătoresc, apartamentul meu servește drept „bază fixă ​​de operațiuni” la distanță, cu conexiune decentă la internet (100 Mbit/sec) și aproape fără latență suplimentară. Asta înseamnă că, din apartamentul meu, sunt practic constrâns doar de viteza rețelei de destinație. Configurația pe care o descriu funcționează cel mai bine cu acest tip de conectivitate, deși nu este o cerință. De fapt, am folosit și această abordare în timp ce aveam o conexiune ADSL cu lățime de bandă relativ mică, majoritatea lucrurilor funcționând bine. Singura cerință reală, din experiența mea, este ca lățimea de bandă să fie fie necontorizată, fie foarte ieftină.

Ca utilizator rezidențial, am cel mai ieftin router de rețea de acasă pe care ISP-ul meu l-ar putea cumpăra, ceea ce pur și simplu nu este suficient pentru ceea ce trebuie să fac. Prin urmare, am cerut ca ISP să pună routerul în „modul pod”, unde servește doar ca un terminator de conexiune, oferind un punct final PPPoE exact unui sistem conectat. Aceasta înseamnă că dispozitivul nu mai funcționează ca punct de acces WiFi sau chiar ca router de acasă obișnuit. Toate aceste sarcini sunt gestionate de un mic router profesional Mikrotik RB951G-2HnD. Efectuează serviciul NAT pentru rețeaua mea locală (pe care am numerotat-o ​​10.10.10.0/24) și oferă DHCP dispozitivelor cu fir și fără fir conectate la aceasta. Mikrotik și Raspberry Pi au adrese statice deoarece sunt folosite în contexte în care este necesară o adresă binecunoscută. În cazul meu, acestea sunt 10.10.10.1 și, respectiv, 10.10.10.10.

Conexiunea mea de acasă nu are o adresă IP statică. Pentru scopurile mele, acesta este doar un inconvenient ușor de lucru de la distanță, deoarece scopul este de a crea un mediu de lucru personal sau SOHO, nu un site 24/7. (Pentru cei care au nevoie de o adresă IP statică pentru serverul lor, merită remarcat faptul că costul adreselor IP statice a continuat să scadă și sunt disponibile opțiuni IP VPN statice destul de ieftine.) Brokerul DNS pe care îl folosesc, Joker.com , oferă un serviciu DNS dinamic gratuit alături de toate celelalte servicii, astfel încât un subdomeniu al domeniului meu personal există ca nume dinamic. Folosesc acest nume pentru conectarea din exterior la propria mea rețea, iar Mikrotik este configurat să treacă SSH și HTTP prin NAT către Raspberry Pi. Trebuie doar să introduc echivalentul ssh mydomain.example.com pentru a mă conecta la serverul meu personal de acasă.

Date oriunde

Un lucru semnificativ pe care Raspberry Pi nu îl oferă este redundanța. L-am echipat cu un card de 32 GB și mai sunt multe date de pierdut în cazul în care se întâmplă ceva. Pentru a ocoli acest lucru și pentru a asigura accesul la datele mele în cazul în care accesul rezidențial la Internet se încurcă, îmi oglindesc toate datele pe un server extern, asemănător cloud. Din moment ce sunt în Europa, a avut sens pentru mine să obțin cel mai mic server dedicat bare-metal (adică nevirtualizat) de la Online.net, care vine cu un procesor VIA low-end, care oferă 2 GB RAM și un SSHD de 500 GB. Ca și în cazul mini-serverului Raspberry Pi, nu am nevoie de performanță ridicată a procesorului sau chiar de memorie, așa că aceasta este o potrivire perfectă. (Ca o parte, îmi amintesc primul meu server „mare” care avea două procesoare Pentium 3 și 1 GB RAM și probabil că avea jumătate din viteza Raspberry Pi 2 și cum am făcut lucruri grozave cu el, ceea ce mi-a influențat interes pentru optimizare.)

Îmi fac copii de rezervă pentru Raspberry Pi pe serverul de la distanță asemănător cloud folosind rdiff-backup. Judecând după dimensiunile relative ale sistemelor, aceste copii de rezervă îmi vor aduce un istoric practic nelimitat. Un alt lucru pe care îl am pe serverul de tip cloud este o instalare a ownCloud, care îmi permite să rulez un serviciu privat asemănător Dropbox. ownCloud ca produs se îndreaptă către groupware și colaborare, așa că devine și mai util dacă mai mulți oameni îl folosesc. De când am început să-l folosesc, literalmente nu am date locale care să nu fie copiate de rezervă nici pe Raspberry Pi, nici pe serverul similar, iar cea mai mare parte a acestora este copiată de două ori. Orice redundanță suplimentară de rezervă pe care o puteți face este întotdeauna un lucru bun, dacă prețuiți datele dvs.

„Magia” SSHFS

Majoritatea muncii mele din zilele noastre implică dezvoltarea de lucruri care nu sunt direct legate de web (șocant, știu!), așa că fluxul meu de lucru urmează adesea un ciclu clasic de editare-compilare-rulare. În funcție de circumstanțele specifice ale unui proiect, fie pot avea fișierele sale local pe laptop, le pot pune în directorul ownCloud-synced sau, mai interesant, le pot plasa direct pe Raspberry Pi și le pot folosi de acolo .

Ultima opțiune este posibilă datorită SSHFS, care îmi permite să montez un director la distanță din Raspberry Pi local. Aceasta este aproape ca o mică bucată de magie: puteți avea un director la distanță pe orice server la care aveți acces SSH (lucrund sub permisiunile pe care utilizatorul dvs. le are pe server) montat ca director local.

Aveți un director de proiect la distanță? Montați-l local și mergeți la el. Dacă aveți nevoie de un server puternic pentru dezvoltare sau testare și – dintr-un motiv oarecare, doar să mergeți acolo și să folosiți vim în consolă nu este o opțiune – montați acel server local și faceți ce doriți. Acest lucru funcționează mai ales bine atunci când sunt pe o conexiune cu lățime de bandă redusă la Internet: chiar dacă lucrez într-un editor de text consolă, experiența este mult mai bună dacă rulez acel editor local și apoi transfer doar fișierele prin SSHFS, mai degrabă decât să lucrezi la o sesiune SSH la distanță.

Trebuie să comparați mai multe directoare /etc pe diferite servere la distanță? Nici o problemă. Folosiți doar SSHFS pentru a monta fiecare dintre ele local și apoi utilizați diff (sau orice alt instrument aplicabil) pentru a le compara.

Sau poate că trebuie să procesați fișiere jurnal mari, dar nu doriți să instalați instrumentul de analiză a jurnalelor pe server (pentru că are o mulțime de dependențe) și, din orice motiv, copiarea jurnalelor este incomod. Încă o dată, nicio problemă. Doar montați directorul de jurnal de la distanță la nivel local prin SSHFS și rulați orice instrument de care aveți nevoie - chiar dacă este un uriaș, greu și bazat pe GUI. SSH acceptă compresia din mers și SSHFS o folosește, astfel încât lucrul cu fișiere text este destul de ușor de utilizat pentru lățimea de bandă.

Pentru scopurile mele, folosesc următoarele opțiuni pe linia de comandă sshfs :

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

Iată ce fac aceste opțiuni de linie de comandă:

• -o reconnect - Spune sshfs să reconnecteze punctul final SSH dacă se întrerupe. Acest lucru este foarte important, deoarece în mod implicit, atunci când conexiunea se întrerupe, punctul de montare fie va eșua brusc, fie pur și simplu se va bloca (ceea ce am considerat că este mai comun). Chiar mi se pare că aceasta ar trebui să fie opțiunea implicită.
• -o idmap=user - Spune sshfs să mapeze utilizatorul de la distanță (adică utilizatorul cu care ne conectăm) să fie același cu utilizatorul local. Deoarece vă puteți conecta prin SSH cu un nume de utilizator arbitrar, acest lucru „repară” lucrurile, astfel încât sistemul local să creadă că utilizatorul este același. Drepturile de acces și permisiunile pe sistemul de la distanță se aplică ca de obicei pentru utilizatorul de la distanță.
• -o follow_symlinks - Deși puteți avea un număr arbitrar de sisteme de fișiere la distanță montate, mi se pare mai convenabil să montez doar un director la distanță, directorul meu de acasă, și în el (în sesiunea SSH la distanță) pot crea legături simbolice către directoare importante în altă parte a sistemului de la distanță, cum ar fi /srv sau /etc sau /var/log . Această opțiune face ca sshfs să rezolve legăturile simbolice de la distanță în fișiere și directoare, permițându-vă să urmăriți directoarele legate.
• -C - Activează compresia SSH. Acest lucru este eficient în special cu metadatele fișierelor și fișierele text, așa că este un alt lucru care pare că ar trebui să fie o opțiune implicită.
• server.example.com:. - Acesta este punctul final la distanță. Prima parte ( server.example.com în acest exemplu) este numele gazdei, iar a doua parte (după două puncte) este directorul de la distanță de montat. În acest caz, am adăugat „.” pentru a indica directorul implicit în care ajunge utilizatorul meu după autentificarea SSH, care este directorul meu de acasă.
• server - Directorul local în care va fi montat sistemul de fișiere la distanță.

Mai ales dacă aveți o lățime de bandă redusă sau o conexiune la internet instabilă, trebuie să utilizați SSHFS cu autentificare cu cheie publică/privată SSH și un agent SSH local. În acest fel, nu vi se vor solicita parole (fie parole de sistem, fie parole de cheie SSH) atunci când utilizați SSHFS , iar caracteristica de reconectare va funcționa așa cum este anunțat. Rețineți că, dacă nu aveți agentul SSH configurat, astfel încât să ofere cheia deblocată după cum este necesar în cadrul sesiunii dvs., caracteristica de reconectare va eșua de obicei. Web-ul este plin de tutoriale cheie SSH și cele mai multe dintre mediile desktop bazate pe GTK pe care le-am încercat își pornesc automat propriul agent (sau „portofel”, sau cum aleg ei să-l numească).

Câteva trucuri SSH avansate

Având un punct fix pe Internet care este accesibil de la distanță de oriunde în lume și care se află pe o conexiune cu lățime de bandă mare – pentru mine este sistemul meu Raspberry Pi și chiar ar putea fi orice VPS generic – reduce stresul și îți permite să faci tot felul de lucruri cu schimbul și tunelul de date.

Aveți nevoie de un nmap rapid și sunteți conectat printr-o rețea de telefonie mobilă? Fă-o de pe acel server. Trebuie să copiați rapid unele date și SSHFS este exagerat? Folosește SCP simplu.

O altă situație cu care vă puteți confrunta cu noi, în care aveți acces SSH la un server, dar portul său 80 (sau oricare altul) este protejat de firewall-ul la rețeaua exterioară de la care vă conectați. Pentru a ocoli acest lucru, puteți utiliza SSH pentru a redirecționa acest port către mașina dvs. locală și apoi să îl accesați prin localhost . O abordare și mai interesantă este să folosiți gazda la care sunteți conectat prin SSH pentru a redirecționa un port pe o altă mașină, eventual în spatele aceluiași firewall. Dacă, de exemplu, aveți următoarele gazde:

• 192.168.77.15 - O gazdă în rețeaua locală la distanță din spatele unui firewall, la care trebuie să vă conectați la portul său 80
• foo.example.com - O gazdă la care aveți acces SSH, care se poate conecta la gazda de mai sus
• sistemul dvs. local, localhost

O comandă pentru a redirecționa portul 80 pe 192.168.77.15 către localhost:8080 prin serverul SSH foo.example.com ar fi:

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

Argumentul pentru -L specifică portul local și adresa și portul de destinație. Argumentul -C permite compresia, astfel încât să puteți realiza din nou economii de lățime de bandă și, în sfârșit, introduceți pur și simplu numele de gazdă SSH. Această comandă va deschide o sesiune shell SSH simplă pentru gazdă și, în plus, va asculta pe portul localhost 8080, la care vă puteți conecta.

Unul dintre cele mai impresionante trucuri pe care SSH le-a dezvoltat în ultimii ani este capacitatea sa de a crea tuneluri VPN reale. Acestea se manifestă ca dispozitive de rețea virtuală de ambele părți ale conexiunii (presupunând că au adrese IP adecvate configurate) și vă pot permite accesul la rețeaua de la distanță ca și cum ați fi acolo fizic (ocolind firewall-urile). Atât din motive tehnice, cât și din motive de securitate, acest lucru necesită acces root pe ambele mașini care sunt conectate la tunel, deci este mult mai puțin convenabil decât utilizarea redirecționării portului sau SSHFS sau SCP. Acesta este pentru utilizatorii avansați, care pot găsi cu ușurință tutoriale despre cum să o facă.

Birou la distanță oriunde

Dezlipit de nevoia de a lucra dintr-o singură locație, puteți lucra literalmente de oriunde care are conexiune la internet pe jumătate decentă, folosind tehnologiile și tehnicile pe care le-am subliniat (inclusiv în timp ce vă așteptați mașina la mecanic). Montați sisteme străine peste SSH, porturi de înaintare, forați tuneluri, pentru a vă accesa serverul privat sau datele bazate pe cloud de la distanță, în timp ce aveți vedere la o plajă scăldată de soare sau beți cafea ecologică de calitate hipster într-un oraș cu ceață. Doar fă-o!