Tworzenie oprogramowania w dowolnym miejscu: moje rozproszone zdalne miejsce pracy

Praca jako zdalny freelancer ma wiele zalet, ale stworzenie efektywnego rozproszonego środowiska pracy może być prawdziwym wyzwaniem. Oczywiście istnieje wiele podejść, które można zastosować i żaden „najlepszy” sposób nie będzie pasował każdemu. Zdalna organizacja cyfrowego miejsca pracy jest rzeczywiście bardzo osobistą sprawą, a to, co działa dobrze dla jednego programisty, może wcale nie działać dobrze dla kogoś innego.

Mając to na uwadze, konfiguracja, którą tutaj przedstawiam, jest po prostu tym, co działa dobrze dla mnie osobiście, szczególnie w projektach zdalnych, które obejmują zarówno rozwój, jak i administrację systemem. Uważam, że takie podejście ma wiele zalet, ale każdy czytelnik powinien zastanowić się, jak dostosować je w sposób, który będzie dla niego najlepszy, w oparciu o połączenie jego potrzeb operacyjnych i osobistych preferencji.

Moje podejście opiera się w dużej mierze na funkcjach oferowanych przez SSH i powiązanych narzędziach w systemie Linux. Należy zauważyć, że użytkownicy MacOS i innych systemów uniksopodobnych mogą również skorzystać z opisanych procedur, o ile ich systemy obsługują opisane narzędzia.

Mój własny mini-serwer

Ważnym pierwszym krokiem w mojej konfiguracji jest serwer oparty na Raspberry Pi 2 w moim własnym domu, używany do hostowania wszystkiego, od moich repozytoriów kodu źródłowego po witryny demonstracyjne.

Chociaż podróżuję, moje mieszkanie służy jako moja zdalna „stała baza operacyjna” z przyzwoitą łącznością z Internetem (100 Mbit/s) i prawie bez dodatkowych opóźnień. Oznacza to, że z mojego mieszkania ogranicza mnie w zasadzie tylko prędkość sieci docelowej. Konfiguracja, którą opisuję, działa najlepiej z tego typu łącznością, chociaż nie jest to wymagane. W rzeczywistości użyłem tego podejścia, gdy miałem stosunkowo niską przepustowość połączenia ADSL, a większość rzeczy działała dobrze. Z mojego doświadczenia wynika, że ​​jedynym prawdziwym wymogiem jest to, aby przepustowość była niezmierzona lub tania.

Jako użytkownik domowy mam najtańszy router sieci domowej, jaki mógłby kupić mój dostawca usług internetowych, co po prostu nie wystarcza do tego, co muszę zrobić. Dlatego poprosiłem dostawcę usług internetowych, aby przestawił router w „tryb mostu”, w którym służy on tylko jako terminator połączenia, oferując punkt końcowy PPPoE dokładnie jednemu podłączonemu systemowi. Oznacza to, że urządzenie przestaje działać jako punkt dostępu Wi-Fi, a nawet jako zwykły router domowy. Wszystkie te zadania są obsługiwane przez profesjonalny mały router Mikrotik RB951G-2HnD. Wykonuje usługę NAT dla mojej sieci lokalnej (którą nazwałem 10.10.10.0/24) i oferuje DHCP podłączonym do niej urządzeniom przewodowym i bezprzewodowym. Mikrotik i Raspberry Pi mają adresy statyczne, ponieważ są używane w kontekstach, w których wymagany jest dobrze znany adres. W moim przypadku są to odpowiednio 10.10.10.1 i 10.10.10.10.

Moje połączenie domowe nie ma statycznego adresu IP. Dla moich celów jest to tylko niewielka niedogodność podczas pracy zdalnej, ponieważ celem jest stworzenie osobistego środowiska pracy lub SOHO, a nie witryny 24/7. (Dla tych, którzy wymagają statycznego adresu IP dla swojego serwera, warto zauważyć, że koszt statycznych adresów IP nadal spada i dostępne są dość niedrogie opcje statycznego adresu IP VPN.) Broker DNS, którego używam, Joker.com , oferuje bezpłatną usługę dynamicznego DNS wraz ze wszystkimi innymi usługami, więc jedna subdomena mojej osobistej domeny istnieje jako nazwa dynamiczna. Używam tej nazwy do łączenia się z zewnątrz do własnej sieci, a Mikrotik jest skonfigurowany do przekazywania SSH i HTTP przez NAT do Raspberry Pi. Po prostu muszę wpisać odpowiednik ssh mydomain.example.com , aby zalogować się do mojego osobistego serwera domowego.

Dane w dowolnym miejscu

Jedną istotną rzeczą, której Raspberry Pi nie oferuje, jest redundancja. Wyposażyłem go w kartę 32 GB, a to wciąż sporo danych do stracenia, gdyby coś się stało. Aby obejść ten problem i zapewnić dostęp do moich danych w przypadku problemów z dostępem do Internetu w domu, kopiuję wszystkie moje dane na zewnętrzny serwer podobny do chmury. Ponieważ jestem w Europie, sensowne było kupienie najmniejszego dedykowanego serwera bare-metal (tj. niezwirtualizowanego) od Online.net, który jest wyposażony w tani procesor VIA, oferujący 2 GB RAM i 500 GB SSHD. Podobnie jak w przypadku miniserwera Raspberry Pi, nie potrzebuję wysokiej wydajności procesora ani nawet pamięci, więc jest to idealne dopasowanie. (Nawiasem mówiąc, pamiętam mój pierwszy „duży” serwer, który miał dwa procesory Pentium 3 i 1 GB pamięci RAM, i był prawdopodobnie o połowę szybszy od Raspberry Pi 2, i jak zrobiliśmy z nim wspaniałe rzeczy, co wpłynęło na mój zainteresowanie optymalizacją.)

Tworzę kopię zapasową mojego Raspberry Pi na zdalnym serwerze w chmurze za pomocą rdiff-backup. Sądząc po względnych rozmiarach systemów, te kopie zapasowe zapewnią mi praktycznie nieograniczoną historię. Kolejną rzeczą, którą mam na serwerze podobnym do chmury, jest instalacja ownCloud, która umożliwia mi uruchamianie prywatnej usługi podobnej do Dropbox. ownCloud jako produkt zmierza w kierunku oprogramowania do pracy grupowej i współpracy, więc staje się jeszcze bardziej użyteczny, gdy korzysta z niego więcej osób. Odkąd zacząłem go używać, dosłownie nie mam żadnych lokalnych danych, których kopia zapasowa nie zostałaby utworzona ani na Raspberry Pi, ani na serwerze podobnym do chmury, a większość z nich jest kopiowana dwukrotnie. Każda dodatkowa nadmiarowość kopii zapasowej, którą możesz wykonać, jest zawsze dobrą rzeczą, jeśli cenisz swoje dane.

„Magia” SSHFS

Większość mojej pracy w dzisiejszych czasach polega na tworzeniu rzeczy, które nie są bezpośrednio związane z siecią (szokujące, wiem!), więc mój przepływ pracy często przebiega zgodnie z klasycznym cyklem edycja-kompilacja. W zależności od konkretnych okoliczności projektu mogę mieć jego pliki lokalnie na swoim laptopie, mogę je umieścić w katalogu synchronizowanym z ownCloud lub, co ciekawsze, mogę je umieścić bezpośrednio na Raspberry Pi i stamtąd ich używać .

Ta ostatnia opcja jest możliwa dzięki SSHFS, który umożliwia mi zamontowanie zdalnego katalogu z Raspberry Pi lokalnie. To prawie jak mały kawałek magii: możesz mieć zdalny katalog na dowolnym serwerze, do którego masz dostęp SSH (działający z uprawnieniami, które posiada twój użytkownik na serwerze) zamontowany jako katalog lokalny.

Masz zdalny katalog projektów? Zamontuj go lokalnie i idź po to. Jeśli potrzebujesz potężnego serwera do tworzenia lub testowania i – z jakiegoś powodu po prostu tam i używanie vima w konsoli nie wchodzi w grę – zamontuj ten serwer lokalnie i rób, co chcesz. Działa to szczególnie dobrze, gdy mam połączenie z Internetem o niskiej przepustowości: nawet jeśli pracuję w edytorze tekstu konsoli, doświadczenie jest znacznie lepsze, jeśli uruchomię ten edytor lokalnie, a następnie po prostu przeniosę pliki przez SSHFS, a raczej niż praca nad zdalną sesją SSH.

Chcesz porównać kilka katalogów /etc na różnych zdalnych serwerach? Nie ma problemu. Po prostu użyj SSHFS, aby zamontować każdy z nich lokalnie, a następnie użyj diff (lub innego narzędzia, które ma zastosowanie), aby je porównać.

A może potrzebujesz przetwarzać duże pliki dzienników, ale nie chcesz instalować narzędzia do analizowania dzienników na serwerze (ponieważ ma ono wiele zależności) iz jakiegoś powodu kopiowanie dzienników jest niewygodne. Po raz kolejny nie ma problemu. Po prostu podłącz zdalny katalog dzienników lokalnie przez SSHFS i uruchom dowolne narzędzie, którego potrzebujesz — nawet jeśli jest to ogromny, ciężki i oparty na GUI. SSH obsługuje kompresję w locie, a SSHFS z niej korzysta, więc praca z plikami tekstowymi jest dość przyjazna dla przepustowości.

Do moich celów używam następujących opcji w wierszu poleceń sshfs :

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

Oto, co robią te opcje wiersza poleceń:

• -o reconnect — nakazuje sshfs ponowne połączenie z punktem końcowym SSH, jeśli się zepsuje. Jest to bardzo ważne, ponieważ domyślnie, gdy połączenie zostanie zerwane, punkt montowania nagle zawiedzie lub po prostu zawiesi się (co uważam za bardziej powszechne). Naprawdę wydaje mi się, że powinna to być opcja domyślna.
• -o idmap=user — nakazuje sshfs mapowanie zdalnego użytkownika (tj. użytkownika, z którym się łączymy), aby był taki sam jak użytkownik lokalny. Ponieważ możesz połączyć się przez SSH z dowolną nazwą użytkownika, to „naprawia” rzeczy, dzięki czemu system lokalny myśli, że użytkownik jest tym samym. Prawa dostępu i uprawnienia w systemie zdalnym mają zastosowanie jak zwykle do użytkownika zdalnego.
• -o follow_symlinks - Chociaż możesz mieć dowolną liczbę zamontowanych zdalnych systemów plików, uważam, że wygodniej jest zamontować tylko jeden zdalny katalog, mój katalog domowy, i w nim (w zdalnej sesji SSH) mogę tworzyć dowiązania symboliczne do ważnych katalogów gdzie indziej w systemie zdalnym, na przykład /srv lub /etc lub /var/log . Ta opcja powoduje, że sshfs rozwiązuje zdalne dowiązania symboliczne do plików i katalogów, pozwalając ci przejść do połączonych katalogów.
• -C — Włącza kompresję SSH. Jest to szczególnie skuteczne w przypadku metadanych plików i plików tekstowych, więc wydaje się, że to kolejna rzecz, która powinna być domyślną opcją.
• server.example.com:. - To jest zdalny punkt końcowy. Pierwsza część (w tym przykładzie server.example.com ) to nazwa hosta, a druga część (po dwukropku) to zdalny katalog do zamontowania. W tym przypadku dodałem „.” aby wskazać domyślny katalog, do którego mój użytkownik trafia po zalogowaniu SSH, czyli mój katalog domowy.
• server — katalog lokalny, do którego zostanie podłączony zdalny system plików.

Zwłaszcza jeśli korzystasz z niskiej przepustowości lub niestabilnego połączenia internetowego, musisz użyć SSHFS z uwierzytelnianiem klucza publicznego/prywatnego SSH i lokalnego agenta SSH. W ten sposób podczas korzystania z protokołu SSHFS nie zostanie wyświetlony monit o podanie haseł (albo haseł systemowych, ani haseł klucza SSH), a funkcja ponownego połączenia będzie działać zgodnie z planem. Pamiętaj, że jeśli nie masz skonfigurowanego agenta SSH, który zapewnia odblokowany klucz w ramach sesji, funkcja ponownego połączenia zwykle kończy się niepowodzeniem. Sieć jest pełna samouczków dotyczących kluczy SSH, a większość środowisk graficznych opartych na GTK, które próbowałem, automatycznie uruchamia własnego agenta (lub „portfel” lub jakkolwiek to nazywają).

Niektóre zaawansowane sztuczki SSH

Posiadanie stałego punktu w Internecie, który jest zdalnie dostępny z dowolnego miejsca na świecie i który jest na połączeniu o dużej przepustowości – dla mnie to mój system Raspberry Pi i naprawdę może to być dowolny ogólny VPS – zmniejsza stres i pozwala na wszelkiego rodzaju rzeczy z wymianą i tunelowaniem danych.

Potrzebujesz szybkiego nmapa i masz połączenie przez sieć telefonii komórkowej? Po prostu zrób to z tego serwera. Chcesz szybko skopiować niektóre dane, a SSHFS to przesada? Po prostu użyj zwykłego SCP.

Inna sytuacja, z którą możesz się spotkać, polega na tym, że masz dostęp SSH do serwera, ale jego port 80 (lub inny) jest odcięty od sieci zewnętrznej, z której się łączysz. Aby obejść ten problem, możesz użyć SSH, aby przekazać ten port do komputera lokalnego, a następnie uzyskać do niego dostęp przez localhost . Jeszcze ciekawszym podejściem jest użycie hosta, z którym jesteś połączony przez SSH, do przekazania portu na innej maszynie, prawdopodobnie za tą samą zaporą ogniową. Jeśli na przykład masz następujące hosty:

• 192.168.77.15 — Host w zdalnej sieci lokalnej za zaporą sieciową, z którym należy połączyć się z jego portem 80
• foo.example.com - Host, do którego masz dostęp SSH, który może połączyć się z powyższym hostem
• twój system lokalny, localhost

Polecenie przekazania portu 80 na 192.168.77.15 do localhost:8080 za pośrednictwem serwera SSH foo.example.com będzie wyglądać tak:

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

Argument do -L określa port lokalny oraz adres docelowy i port. Argument -C włącza kompresję, więc ponownie możesz osiągnąć oszczędność przepustowości, a na końcu po prostu wpisujesz nazwę hosta SSH. To polecenie otworzy zwykłą sesję powłoki SSH na hoście, a ponadto nasłuchuje na porcie localhost 8080, z którym możesz się połączyć.

Jedną z najbardziej imponujących sztuczek opracowanych przez SSH w ostatnich latach jest możliwość tworzenia prawdziwych tuneli VPN. Przejawiają się one jako wirtualne urządzenia sieciowe po obu stronach połączenia (zakładając, że mają skonfigurowane odpowiednie adresy IP) i umożliwiają dostęp do sieci zdalnej tak, jakbyś był tam fizycznie (omijając zapory). Zarówno ze względów technicznych, jak i bezpieczeństwa, wymaga to dostępu roota na obu maszynach, które są połączone z tunelem, więc jest to znacznie mniej wygodne niż używanie przekierowania portów lub SSHFS lub SCP. Ten jest przeznaczony dla zaawansowanych użytkowników, którzy mogą łatwo znaleźć samouczki, jak to zrobić.

Zdalne biuro w dowolnym miejscu

Pozbawiony potrzeby pracy z jednego miejsca, możesz pracować dosłownie z dowolnego miejsca, które ma w połowie przyzwoitą łączność z Internetem, korzystając z technologii i technik, które nakreśliłem (w tym podczas oczekiwania na samochód u mechanika). Montuj obce systemy przez SSH, przekieruj porty, drąż tunele, aby uzyskać zdalny dostęp do swojego prywatnego serwera lub danych w chmurze, z widokiem na skąpaną w słońcu plażę lub pijąc ekologiczną kawę hipsterskiej jakości w mglistym mieście. Po prostu to zrób!