Työskentely a etäinen freelancer on monia etuja, mutta tehokkaan hajautetun työympäristön luominen voi olla todellinen haaste. Tietenkin on monia lähestymistapoja, joita voidaan käyttää, eikä mikään yksittäinen 'paras' tapa sovi kaikille. Digitaalinen etätyöpaikan organisaatio on todellakin hyvin henkilökohtainen asia, ja se, mikä toimii hyvin yhdelle kehittäjälle, ei välttämättä toimi lainkaan jollekin muulle.

Tässä mielessä tässä esitelty asennus on yksinkertaisesti se, mikä toimii minulle henkilökohtaisesti, erityisesti etäprojekteissa, joihin liittyy sekä kehitystä että järjestelmän hallintaa. Uskon, että tällä lähestymistavalla on useita etuja, mutta jokaisen lukijan tulisi miettiä, kuinka mukauttaa tämä heille parhaiten sopivalla tavalla heidän operatiivisten tarpeidensa ja henkilökohtaisten mieltymystensä perusteella.

Lähestymistapani perustuu pitkälti SSH: n tarjoamiin ominaisuuksiin ja niihin liittyviin Linux-työkaluihin. Huomaa, että MacOS: n ja muiden Unix-tyyppisten järjestelmien käyttäjät voivat hyödyntää myös kuvattuja menettelyjä siltä osin kuin heidän järjestelmänsä tukevat kuvattuja työkaluja.

Oma henkilökohtainen minipalvelin

Tärkeä ensimmäinen askel asetuksessani on a Vadelma Pi 2 virtaa palvelin omassa kodissani , käytetään isännöimään kaikkea lähdekoodivarastoistani demosivustoihin.

Vaikka matkustan, asuntoni toimii etäyhteyksien ”kiinteänä tukiasemana”, jolla on kunnollinen Internet-yhteys (100 Mbit / s) ja melkein ilman ylimääräistä viivettä. Tämä tarkoittaa, että asunnostani olen periaatteessa rajoittanut vain kohdeverkon nopeus. Kuvaamani kokoonpano toimii parhaiten tämäntyyppisen yhteyden kanssa, vaikka se ei ole vaatimus. Itse asiassa olen myös käyttänyt tätä lähestymistapaa, kun minulla oli suhteellisen matalan kaistanleveyden ADSL-yhteys, ja suurin osa asioista toimi hienosti. Ainoa todellinen vaatimus kokemukseni mukaan on, että kaistanleveys on joko mittaamaton tai likaa halpa.

Asuinkäyttäjänä minulla on halvin kotiverkkoreititin, jonka Internet-palveluntarjoajani voisi ostaa, mikä ei yksinkertaisesti riitä siihen, mitä minun pitää tehdä. Siksi olen pyytänyt Internet-palveluntarjoajaa asettamaan reitittimen 'sillatilaan', jossa se toimii vain yhteyden päätelaitteena tarjoten PPPoE päätepiste tarkalleen yhteen liitettyyn järjestelmään. Tämä tarkoittaa, että laite lakkaa toimimasta WiFi-tukiasemana tai jopa yleisenä kotireitittimenä. Kaikki nämä tehtävät hoitaa a ammattimainen pieni Mikrotik-reititin RB951G-2HnD . Se suorittaa YÖ palvelu paikallisverkolleni (jonka olen numeroinut 10.10.10.0/24), ja tarjoaa DHCP siihen kytkettyihin langallisiin ja langattomiin laitteisiin. Mikrotikilla ja Raspberry Pi: llä on staattiset osoitteet, koska niitä käytetään tilanteissa, joissa tarvitaan tunnettua osoitetta. Minun tapauksessani ne ovat vastaavasti 10.10.10.1 ja 10.10.10.10.

Kotiliitännälläni ei ole staattista IP-osoitetta. Minun mielestäni tämä on vain lievää haittaa etätyössä, koska tavoitteena on luoda henkilökohtainen tai SOHO työympäristö, ei 24/7. (Niille, jotka tarvitsevat staattisen IP-osoitteen palvelimelleen, on syytä huomata, että staattisten IP-osoitteiden kustannukset ovat edelleen laskeneet ja melko edulliset staattiset VPN IP -vaihtoehdot ovat käytettävissä.) DNS-välittäjä, jota käytän, Joker.com , tarjoaa ilmaisen dynaamisen DNS-palvelun kaikkien muiden palvelujensa rinnalla, joten yksi henkilökohtaisen verkkotunnuksen aliverkkotunnus on dynaaminen nimi. Käytän tätä nimeä muodostaessani yhteyden ulkopuolelta omaan verkkooni, ja Mikrotik on määritetty välittämään SSH ja HTTP NAT: n kautta Vadelma Pi: lle. Minun on yksinkertaisesti kirjoitettava vastaava ssh mydomain.example.com jotta voin kirjautua sisään henkilökohtaiseen kotipalvelimelleni.

Tiedot missä tahansa

Yksi merkittävä asia, jonka Vadelma Pi tekee ei tarjous on irtisanominen. Olen varustanut sen 32 Gt: n kortilla, ja menetettävää dataa on vielä paljon, jos jotain tapahtuu. Kiertääkseni sen ja varmistaakseni pääsyn tietoihini, jos Internetin Internet-yhteys hikkautuu, peilaan kaikki tietoni ulkoiselle, pilvipalvelimelle. Koska olen Euroopassa, minulla oli järkevää saada pienin erillinen paljaan metallin (eli virtualisoimaton) palvelin Online.net-sivustolta , jonka mukana tulee matalan luokan VIA-suoritin, joka tarjoaa 2 Gt RAM-muistia ja 500 Gt SSHD . Kuten Raspberry Pi -minipalvelimen kohdalla, en tarvitse korkeaa suorittimen suorituskykyä tai edes muistia, joten tämä sopii täydellisesti. (Muistiinpanona muistan ensimmäisen 'suuren' palvelimeni, jolla oli kaksi Pentium 3 -prosessoria ja 1 Gt RAM-muistia, ja joka oli todennäköisesti puolet Raspberry Pi 2 -nopeudesta, ja kuinka teimme sen kanssa hienoja asioita, mikä on vaikuttanut minun kiinnostus optimointiin.)

Varmuuskopioin Raspberry Pi -sovelluksen pilvipalvelimen etäpalvelimeen rdiff-varmuuskopio . Järjestelmien suhteellisen koon perusteella päätellen nämä varmuuskopiot saavat käytännössä rajattoman historian. Yksi muu asia, joka minulla on pilvimaisella palvelimella, on asennus ownCloud , jonka avulla voin suorittaa yksityisen Dropbox-tyyppisen palvelun. ownCloud tuotteena on siirtymässä kohti ryhmäohjelmia ja yhteistyötä, joten siitä tulee vieläkin hyödyllisempi, jos sitä käyttää enemmän ihmisiä. Koska aloin käyttää sitä, minulla ei kirjaimellisesti ole minkä tahansa paikalliset tiedot, joita ei ole varmuuskopioitu joko Raspberry Pi: lle tai pilvimaiselle palvelimelle, ja suurin osa siitä varmuuskopioidaan kahdesti. Mahdollinen ylimääräinen varmuuskopioinnin redundanssi on aina hyvä asia, jos arvostat tietojasi.

SSHFS: n “taikuutta”

Suurin osa työstäni näinä päivinä liittyy sellaisten juttujen kehittämiseen, jotka eivät liity suoraan verkkoon (järkyttävä, tiedän!), Joten työnkulkuni seuraa usein klassista muokkaus-, kääntö- ja aikasykliä. Projektin erityisolosuhteista riippuen minulla voi olla joko sen tiedostot paikallisesti kannettavalla tietokoneellani, voin laittaa ne omanCloud-synkronoituun hakemistoon tai mielenkiintoisemmin, voin sijoittaa ne suoraan Raspberry Pi -kansioon ja käyttää niitä sieltä .

Jälkimmäinen vaihtoehto on mahdollinen SSHFS , jonka avulla voin asentaa etähakemiston Raspberry Pi: stä paikallisesti. Tämä on melkein kuin pieni taikuutta: sinulla voi olla etähakemisto päällä minkä tahansa palvelin, johon sinulla on SSH-yhteys (työskentelet käyttäjän palvelimella olevien oikeuksien alaisena), joka on asennettu paikallishakemistoksi.

Onko sinulla etäprojektihakemisto? Asenna se paikallisesti ja mene siihen. Jos tarvitset tehokkaan palvelimen kehitykseen tai testaukseen ja - jostain syystä vain mennä sinne ja käyttää tulin konsolissa ei ole vaihtoehto - asenna kyseinen palvelin paikallisesti ja tee mitä haluat. Tämä toimii erityisen hyvin, kun olen matalan kaistanleveyden Internet-yhteydessä: vaikka työskentelisin konsolin tekstieditorissa, kokemus on paljon parempi, jos suoritan kyseisen editorin paikallisesti ja siirrän sitten tiedostot vain SSHFS: n kautta, pikemminkin kuin työskennellä SSH-etäistunnon aikana.

Tarve verrata useita /etc hakemistot eri etäpalvelimilla? Ei ongelmaa. Käytä vain SSHFS: ää asentaaksesi kukin niistä paikallisesti ja käytä sitten diff (tai mitä tahansa muuta sovellettavaa työkalua) niiden vertaamiseen.

Tai sinun on ehkä käsiteltävä suuria lokitiedostoja, mutta et halua asentaa lokin jäsentelytyökalua palvelimelle (koska sillä on gazillioniriippuvuuksia) ja jostain syystä lokien kopiointi on hankalaa. Jälleen kerran, ei ole ongelma. Asenna vain etälokihakemisto paikallisesti SSHFS: n kautta ja suorita tarvitsemasi työkalu, vaikka se olisi valtava, raskas ja käyttöliittymävetoinen. SSH tukee pakettia lennossa ja SSHFS käyttää sitä, joten tekstitiedostojen kanssa työskenteleminen on melko kaistanleveysystävällistä.

Käytän tarkoituksiini sshfs -kohdassa seuraavia vaihtoehtoja komentorivi:

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

Näin nämä komentorivivalinnat tekevät:

• -o reconnect - Käskee sshf: itä yhdistämään SSH-päätepiste uudelleen, jos se rikkoutuu. Tämä on erittäin tärkeää, koska oletusarvoisesti, kun yhteys katkeaa, kiinnityskohta joko epäonnistuu äkillisesti tai yksinkertaisesti roikkuu (mikä on mielestäni yleisempää). Minusta tuntuu todella, että tämän pitäisi olla oletusvaihtoehto.
• -o idmap=user - Käskee sshf: itä etäkäyttäjän (ts. Käyttäjän, jona yhdistämme) kartoittamaan olevan sama kuin paikallinen käyttäjä. Koska voit muodostaa yhteyden SSH: n kautta mielivaltaisella käyttäjänimellä, tämä 'korjaa' asiat, joten paikallinen järjestelmä ajattelee käyttäjän olevan sama. Etäjärjestelmän käyttöoikeudet ja käyttöoikeudet koskevat tavallista etäkäyttäjää.
• -o follow_symlinks - Vaikka sinulla voi olla mielivaltainen määrä asennettuja etätiedostojärjestelmiä, minusta on helpompaa asentaa vain yksi etähakemisto, kotihakemisto, ja siinä (SSH-etäistunnossa) voin luoda symboleita tärkeisiin hakemistoihin muualla etäjärjestelmä, kuten /srv tai /etc tai /var/log. Tämä vaihtoehto saa sshf: t ratkaisemaan etäsymbolit tiedostoiksi ja hakemistoiksi, jolloin voit seurata linkitettyjä hakemistoja.
• -C - Kytkee SSH-pakkauksen päälle. Tämä on erityisen tehokasta tiedostojen metatietojen ja tekstitiedostojen kanssa, joten se on toinen asia, joka näyttää olevan oletusasetus.
• server.example.com:. - Tämä on etäpäätepiste. Ensimmäinen osa (server.example.com tässä esimerkissä) on isäntänimi ja toinen osa (kaksoispisteen jälkeen) on asennettava etähakemisto. Tässä tapauksessa olen lisännyt sanan '.' osoittamaan oletushakemisto, johon käyttäjäni pääsee SSH-kirjautumisen jälkeen, joka on kotihakemisto.
• server - Paikallinen hakemisto, johon etätiedostojärjestelmä asennetaan.

Varsinkin jos olet matalalla kaistalla tai epävakaalla Internet-yhteydellä, sinun on käytettävä SSHFS: ää SSH: n julkisen / yksityisen avaimen todennus ja paikallinen SSH-agentti. Tällä tavoin sinua ei pyydetä salasanoja (joko järjestelmän salasanoja tai SSH-avainten salasanoja) käytettäessä SSHFS: ää ja Yhdistä uudelleen -ominaisuus toimii mainostetulla tavalla. Huomaa, että jos SSH-agenttia ei ole määritetty niin, että se tarjoaa avaamattoman avaimen istunnon aikana, yhteyden muodostusominaisuus yleensä epäonnistuu. Verkko on täynnä SSH-avainoppaita, ja suurin osa GTK-pohjaisista työpöytäympäristöistä, jotka olen kokeillut, perustavat automaattisesti oman agenttinsa (tai 'lompakon' tai mitä he haluavat kutsua sille).

Joitakin edistyneitä SSH-temppuja

Internetissä on kiinteä piste, johon on etäkäynti kaikkialta maailmasta ja joka on suurella kaistanleveydellä - minulle se on minun Raspberry Pi -järjestelmäni, ja se voi todella olla mikä tahansa yleinen VPS - vähentää stressiä ja antaa sinun tehdä kaikenlaisia ​​tietoja tietojen vaihdon ja tunneloinnin kanssa.

Tarvitsetko nopeaa nmap ja olet yhteydessä matkapuhelinverkkoon? Tee se vain palvelimelta. Täytyykö kopioida osa tiedoista nopeasti ja SSHFS on ylivoimainen? Käytä vain tavallista SCP .

Toinen tilanne, jossa saatat joutua kohtaamaan kanssamme, jossa sinulla on SSH-yhteys palvelimeen, mutta sen portti 80 (tai mikä tahansa muu) on palomuurittu ulkoiseen verkkoon, josta muodostat yhteyden. Voit kiertää tämän käyttämällä SSH: tä lähettämään tämän portin paikalliselle koneellesi ja käyttämään sitä sitten localhost -palvelun kautta. Vieläkin mielenkiintoisempi tapa on käyttää isäntää, johon olet yhteydessä SSH: n kautta, portin edelleen välittämiseen toinen kone, mahdollisesti saman palomuurin takana. Jos sinulla on esimerkiksi seuraavat isännät:

• 192.168.77.15 - Palomuurin takana sijaitsevan paikallisen etäverkon isäntä, johon sinun on muodostettava yhteys sen porttiin 80
• foo.example.com - Isäntä, johon sinulla on SSH-yhteys, joka voi muodostaa yhteyden yllä olevaan isäntään
• paikallinen järjestelmäsi, localhost

Komento, joka välittää portin 80 192.168.77.15: ssä localhost: 8080: lle foo.example.com SSH -palvelimen kautta, olisi:

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

Argumentti -L määrittää paikallisen portin, määränpään osoitteen ja portin. -C Argumentti sallii pakkaamisen, joten voit jälleen saavuttaa kaistanleveyssäästöjä, ja lopuksi kirjoitat yksinkertaisesti SSH-isäntänimen. Tämä komento avaa tavallisen SSH-kuoren istunnon isännälle ja kuuntele sen lisäksi localhost-portissa 8080, johon voit muodostaa yhteyden.

Yksi vaikuttavimmista temppuista, joita SSH on kehittänyt viime vuosina, on kyky luoda todellisia VPN-tunneleita. Nämä ilmenevät virtuaalisina verkkolaitteina yhteyden molemmilla puolilla (olettaen, että niille on määritetty sopivat IP-osoitteet), ja ne voivat antaa sinulle pääsyn etäverkkoon kuin olisit fyysisesti siellä (ohittaa palomuurit). Sekä teknisistä että turvallisuussyistä tämä edellyttää pääkäyttöoikeuksia molemmille tunneliin liitetyille koneille, joten se on paljon vähemmän kätevää kuin vain porttisiirron tai SSHFS: n tai SCP: n käyttö. Tämä on edistyneille käyttäjille, jotka löytävät helposti oppaat miten se tehdään.

Etätoimisto missä tahansa

Voit jatkaa työskentelyä, vaikka odotat autoa mekaanikon luona. Tweet

Riisuttu tarve työskennellä yhdestä paikasta , voit työskennellä kirjaimellisesti mistä tahansa, jolla on puoliksi kunnollinen Internet-yhteys, käyttämällä hahmottamiani tekniikoita ja tekniikoita (myös odottaessasi autoa mekaanikon luona). Asenna ulkomaisia ​​järjestelmiä SSH: n yli, eteenpäin portteja, poraa tunneleita, jotta pääset yksityiseen palvelimeesi tai pilvipohjaiseen dataan etänä samalla kun avaat näkymät aurinkoiselle rannalle tai juot hipsterilaatuista ympäristöystävällistä kahvia sumuisessa kaupungissa. Anna mennä!