Softwareentwicklung überall: Mein verteilter Remote-Arbeitsplatz

Die Arbeit als Remote-Freiberufler hat viele Vorteile, aber die Einrichtung einer effektiv verteilten Arbeitsumgebung kann eine echte Herausforderung sein. Natürlich gibt es viele Ansätze, die man verfolgen kann, und kein einziger „bester“ Weg ist für jeden geeignet. Die Organisation digitaler Remote-Arbeitsplätze ist in der Tat eine sehr persönliche Sache, und was für einen Entwickler gut funktioniert, funktioniert für einen anderen möglicherweise überhaupt nicht.

In Anbetracht dessen ist das Setup, das ich hier vorstelle, einfach das, was für mich persönlich gut funktioniert, insbesondere bei Remote-Projekten, die sowohl Entwicklung als auch Systemadministration umfassen. Ich glaube, dass dieser Ansatz eine Reihe von Vorteilen hat, aber jeder Leser sollte überlegen, wie er dies auf eine Weise anpassen kann, die für ihn am besten funktioniert, basierend auf einer Kombination aus seinen betrieblichen Anforderungen und persönlichen Vorlieben.

Mein Ansatz basiert weitgehend auf Funktionen, die SSH und verwandte Tools unter Linux bieten. Beachten Sie, dass Benutzer von MacOS und anderen Unix-ähnlichen Systemen die beschriebenen Verfahren ebenfalls nutzen können, sofern ihre Systeme die beschriebenen Tools unterstützen.

Mein eigener persönlicher Mini-Server

Ein wichtiger erster Schritt in meinem Setup ist ein Server mit Raspberry Pi 2 in meinem eigenen Zuhause, auf dem alles gehostet wird, von meinen Quellcode-Repositorys bis hin zu Demoseiten.

Obwohl ich reise, dient meine Wohnung als meine entfernte „feste Basis für Operationen“ mit anständiger Internetverbindung (100 Mbit/s) und fast keiner zusätzlichen Latenz. Das bedeutet, dass ich von meiner Wohnung aus im Grunde nur durch die Geschwindigkeit des Zielnetzes eingeschränkt bin. Das Setup, das ich beschreibe, funktioniert am besten mit dieser Art von Konnektivität, obwohl es keine Voraussetzung ist. Tatsächlich habe ich diesen Ansatz auch verwendet, als ich eine ADSL-Verbindung mit relativ geringer Bandbreite hatte, wobei die meisten Dinge gut funktionierten. Die einzige wirkliche Anforderung ist meiner Erfahrung nach, dass die Bandbreite entweder nicht gemessen oder spottbillig ist.

Als privater Benutzer habe ich den billigsten Heimnetzwerk-Router, den mein ISP kaufen könnte, was einfach nicht genug für das ist, was ich tun muss. Ich habe daher den ISP gebeten, den Router in den „Bridge-Modus“ zu versetzen, in dem er nur als Verbindungsabschluss dient und genau einem angeschlossenen System einen PPPoE-Endpunkt anbietet. Dies bedeutet, dass das Gerät nicht mehr als WLAN-Zugangspunkt oder sogar als gewöhnlicher Heimrouter funktioniert. All diese Aufgaben werden von einem professionellen kleinen Mikrotik-Router RB951G-2HnD erledigt. Es führt den NAT-Dienst für mein lokales Netzwerk aus (das ich mit 10.10.10.0/24 nummeriert habe) und bietet DHCP für kabelgebundene und drahtlose Geräte, die damit verbunden sind. Die Mikrotik und der Raspberry Pi haben statische Adressen, da sie in Kontexten verwendet werden, in denen eine bekannte Adresse erforderlich ist. In meinem Fall sind das 10.10.10.1 bzw. 10.10.10.10.

Mein Heimanschluss hat keine statische IP-Adresse. Für meine Zwecke ist dies nur eine geringfügige Unannehmlichkeit bei der Remote-Arbeit, da das Ziel darin besteht, eine persönliche oder SOHO-Arbeitsumgebung zu schaffen, nicht einen 24/7-Standort. (Für diejenigen, die eine statische IP-Adresse für ihren Server benötigen, ist es erwähnenswert, dass die Kosten für statische IP-Adressen weiter gesunken sind und ziemlich kostengünstige statische VPN-IP-Optionen verfügbar sind.) Der DNS-Broker, den ich verwende, Joker.com , bietet neben all seinen anderen Diensten einen kostenlosen dynamischen DNS-Dienst an, sodass eine Subdomain meiner persönlichen Domain als dynamischer Name existiert. Ich verwende diesen Namen, um mich von außen mit meinem eigenen Netzwerk zu verbinden, und die Mikrotik ist so konfiguriert, dass sie SSH und HTTP über das NAT an den Raspberry Pi weiterleitet. Ich muss einfach das Äquivalent von ssh mydomain.example.com , um mich bei meinem persönlichen Home-Server anzumelden.

Daten überall

Eine wesentliche Sache, die der Raspberry Pi nicht bietet, ist Redundanz. Ich habe es mit einer 32-GB-Karte ausgestattet, und das sind immer noch viele Daten, die verloren gehen können, falls etwas passiert. Um dies zu umgehen und den Zugriff auf meine Daten sicherzustellen, wenn der Internetzugang im Privathaushalt ausfällt, spiegele ich alle meine Daten auf einen externen, Cloud-ähnlichen Server. Da ich in Europa bin, war es für mich sinnvoll, den kleinsten dedizierten Bare-Metal-Server (dh nicht virtualisierten) von Online.net zu kaufen, der mit einer Low-End-VIA-CPU ausgestattet ist und 2 GB RAM und eine 500-GB-SSHD bietet. Wie beim Raspberry Pi Mini-Server benötige ich keine hohe CPU-Leistung oder gar Arbeitsspeicher, also passt das perfekt zusammen. (Nebenbei erinnere ich mich an meinen ersten „großen“ Server, der zwei Pentium 3-CPUs und 1 GB RAM hatte und wahrscheinlich halb so schnell war wie der Raspberry Pi 2, und wie wir großartige Dinge damit gemacht haben, was mich beeinflusst hat Interesse an Optimierung.)

Ich sichere meinen Raspberry Pi mit rdiff-backup auf dem Cloud-ähnlichen Remote-Server. Nach der relativen Größe der Systeme zu urteilen, werden mir diese Backups eine praktisch unbegrenzte Historie verschaffen. Eine andere Sache, die ich auf dem Cloud-ähnlichen Server habe, ist eine Installation von ownCloud, die es mir ermöglicht, einen privaten Dropbox-ähnlichen Dienst zu betreiben. ownCloud als Produkt bewegt sich in Richtung Groupware und Kollaboration, daher wird es noch nützlicher, wenn mehr Leute es verwenden. Seit ich damit angefangen habe, habe ich buchstäblich keine lokalen Daten, die nicht auf dem Raspberry Pi oder dem Cloud-ähnlichen Server gesichert sind, und die meisten davon werden zweimal gesichert. Jede zusätzliche Sicherungsredundanz, die Sie herstellen können, ist immer eine gute Sache, wenn Sie Wert auf Ihre Daten legen.

Die „Magie“ von SSHFS

Der größte Teil meiner Arbeit besteht heutzutage darin, Dinge zu entwickeln, die nicht direkt mit dem Web zu tun haben (schockierend, ich weiß!), daher folgt mein Arbeitsablauf oft einem klassischen Bearbeiten-Kompilieren-Ausführen-Zyklus. Abhängig von den spezifischen Umständen eines Projekts kann ich seine Dateien entweder lokal auf meinem Laptop haben, ich kann sie in das ownCloud-synced-Verzeichnis legen, oder, was noch interessanter ist, ich könnte sie direkt auf dem Raspberry Pi platzieren und sie von dort aus verwenden .

Letztere Option wird dank SSHFS ermöglicht, das es mir ermöglicht, ein Remote-Verzeichnis vom Raspberry Pi lokal zu mounten. Das ist fast wie ein kleines Stück Magie: Sie können ein Remote-Verzeichnis auf jedem Server haben, auf den Sie SSH-Zugriff haben (der unter den Berechtigungen arbeitet, die Ihr Benutzer auf dem Server hat), der als lokales Verzeichnis gemountet ist.

Haben Sie ein Remote-Projektverzeichnis? Mounten Sie es lokal und legen Sie los. Wenn Sie einen leistungsstarken Server für die Entwicklung oder zum Testen benötigen und – aus irgendeinem Grund einfach dorthin gehen und vim in der Konsole verwenden, keine Option ist – mounten Sie diesen Server lokal und tun Sie, was Sie wollen. Dies funktioniert besonders gut, wenn ich eine Internetverbindung mit geringer Bandbreite habe: Selbst wenn ich in einem Konsolen-Texteditor arbeite, ist die Erfahrung viel besser, wenn ich diesen Editor lokal ausführe und die Dateien dann einfach über SSHFS übertrage als über eine Remote-SSH-Sitzung zu arbeiten.

Müssen Sie mehrere /etc -Verzeichnisse auf verschiedenen Remote-Servern vergleichen? Kein Problem. Verwenden Sie einfach SSHFS, um sie lokal zu mounten, und verwenden Sie dann diff (oder ein anderes geeignetes Tool), um sie zu vergleichen.

Oder vielleicht müssen Sie große Protokolldateien verarbeiten, möchten aber das Protokollparsing-Tool nicht auf dem Server installieren (weil es unzählige Abhängigkeiten hat) und aus irgendeinem Grund ist das Kopieren der Protokolle unpraktisch. Wieder einmal kein Problem. Mounten Sie einfach das Remote-Log-Verzeichnis lokal über SSHFS und führen Sie das gewünschte Tool aus – selbst wenn es riesig, schwer und GUI-gesteuert ist. SSH unterstützt On-the-Fly-Komprimierung und SSHFS nutzt sie, sodass die Arbeit mit Textdateien ziemlich bandbreitenschonend ist.

Für meine Zwecke verwende ich die folgenden Optionen in der sshfs -Befehlszeile:

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

Folgendes bewirken diese Befehlszeilenoptionen:

• -o reconnect reconnect - Weist sshfs an, den SSH-Endpunkt erneut zu verbinden, wenn er unterbrochen wird. Dies ist sehr wichtig, da der Einhängepunkt standardmäßig entweder abrupt fehlschlägt oder einfach hängt (was meiner Meinung nach häufiger vorkommt), wenn die Verbindung unterbrochen wird. Scheint mir wirklich, dass dies die Standardoption sein sollte.
• -o idmap=user – Weist sshfs an, den Remote-Benutzer (dh den Benutzer, als der wir uns verbinden) so abzubilden, dass er derselbe wie der lokale Benutzer ist. Da Sie sich über SSH mit einem beliebigen Benutzernamen verbinden könnten, „behebt“ dies Dinge, sodass das lokale System denkt, dass der Benutzer derselbe ist. Zugriffsrechte und Berechtigungen auf dem Remote-System gelten wie gewohnt für den Remote-Benutzer.
• -o follow_symlinks - Während Sie eine beliebige Anzahl von Remote-Dateisystemen gemountet haben können, finde ich es bequemer, nur ein Remote-Verzeichnis, mein Home-Verzeichnis, zu mounten, und darin (in der Remote-SSH-Sitzung) kann ich Symlinks zu wichtigen Verzeichnissen erstellen an anderer Stelle auf dem entfernten System, wie /srv oder /etc oder /var/log . Diese Option bewirkt, dass sshfs entfernte symbolische Links in Dateien und Verzeichnisse auflöst, sodass Sie zu den verknüpften Verzeichnissen gelangen können.
• -C – Aktiviert die SSH-Komprimierung. Dies ist besonders effektiv bei Dateimetadaten und Textdateien, daher scheint es eine andere Sache zu sein, die eine Standardoption sein sollte.
• server.example.com:. - Dies ist der entfernte Endpunkt. Der erste Teil (in diesem Beispiel server.example.com ) ist der Hostname, und der zweite Teil (nach dem Doppelpunkt) ist das Remote-Verzeichnis, das gemountet werden soll. In diesem Fall habe ich „.“ hinzugefügt. um das Standardverzeichnis anzugeben, in dem mein Benutzer nach dem SSH-Login landet, das mein Home-Verzeichnis ist.
• server - Das lokale Verzeichnis, in das das Remote-Dateisystem gemountet wird.

Insbesondere wenn Sie eine niedrige Bandbreite oder eine instabile Internetverbindung verwenden, müssen Sie SSHFS mit öffentlicher/privater SSH-Schlüsselauthentifizierung und einem lokalen SSH-Agenten verwenden. Auf diese Weise werden Sie bei der Verwendung von SSHFS nicht zur Eingabe von Kennwörtern (entweder Systemkennwörter oder SSH-Schlüsselkennwörter) aufgefordert, und die Funktion zum erneuten Verbinden funktioniert wie angekündigt. Beachten Sie, dass die Wiederverbindungsfunktion normalerweise fehlschlägt, wenn Sie den SSH-Agenten nicht so eingerichtet haben, dass er den entsperrten Schlüssel nach Bedarf in Ihrer Sitzung bereitstellt. Das Web ist voll von SSH-Key-Tutorials, und die meisten GTK-basierten Desktop-Umgebungen, die ich ausprobiert habe, starten automatisch ihren eigenen Agenten (oder „Wallet“ oder wie auch immer sie es nennen).

Einige fortgeschrittene SSH-Tricks

Einen festen Punkt im Internet zu haben, auf den von überall auf der Welt aus zugegriffen werden kann und der über eine Verbindung mit hoher Bandbreite verfügt – für mich ist es mein Raspberry Pi-System, und es könnte wirklich jeder generische VPS sein – reduziert Stress und ermöglicht es Ihnen, dies zu tun alle möglichen Dinge mit dem Austausch und dem Tunneln von Daten.

Benötigen Sie schnell eine nmap und sind über ein Mobilfunknetz verbunden? Tun Sie es einfach von diesem Server aus. Müssen Sie schnell einige Daten kopieren und SSHFS ist ein Overkill? Verwenden Sie einfach einfaches SCP.

In einer anderen Situation, in der Sie mit uns konfrontiert werden, haben Sie SSH-Zugriff auf einen Server, aber sein Port 80 (oder ein anderer) ist durch eine Firewall mit dem externen Netzwerk verbunden, von dem aus Sie sich verbinden. Um dies zu umgehen, können Sie diesen Port mit SSH an Ihren lokalen Computer weiterleiten und dann über localhost darauf zugreifen. Ein noch interessanterer Ansatz besteht darin, den Host, mit dem Sie über SSH verbunden sind, zu verwenden, um einen Port auf einem anderen Computer weiterzuleiten, möglicherweise hinter derselben Firewall. Wenn Sie beispielsweise die folgenden Hosts haben:

• 192.168.77.15 – Ein Host im entfernten lokalen Netzwerk hinter einer Firewall, zu dem Sie eine Verbindung zu seinem Port 80 herstellen müssen
• foo.example.com – Ein Host, auf den Sie SSH-Zugriff haben und der sich mit dem obigen Host verbinden kann
• Ihr lokales System, localhost

Ein Befehl zum Weiterleiten des Ports 80 auf 192.168.77.15 an localhost:8080 über den SSH-Server foo.example.com wäre:

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

Das Argument für -L gibt den lokalen Port sowie die Zieladresse und den Port an. Das Argument -C aktiviert die Komprimierung, sodass Sie erneut Bandbreiteneinsparungen erzielen können, und schließlich geben Sie am Ende einfach den SSH-Hostnamen ein. Dieser Befehl öffnet eine einfache SSH-Shell-Sitzung zum Host und überwacht zusätzlich den localhost-Port 8080, zu dem Sie eine Verbindung herstellen können.

Einer der beeindruckendsten Tricks, den SSH in den letzten Jahren entwickelt hat, ist seine Fähigkeit, echte VPN-Tunnel zu erstellen. Diese manifestieren sich als virtuelle Netzwerkgeräte auf beiden Seiten der Verbindung (vorausgesetzt, sie haben entsprechende IP-Adressen eingerichtet) und können Ihnen den Zugriff auf das Remote-Netzwerk ermöglichen, als ob Sie physisch dort wären (unter Umgehung von Firewalls). Sowohl aus technischen als auch aus Sicherheitsgründen erfordert dies Root-Zugriff auf beiden Maschinen, die mit dem Tunnel verbunden sind, also ist es viel weniger bequem, als nur die Portweiterleitung oder SSHFS oder SCP zu verwenden. Dieser ist für die fortgeschrittenen Benutzer da draußen, die leicht Tutorials finden können, wie es geht.

Remote-Büro überall

Ohne die Notwendigkeit, von einem einzigen Standort aus zu arbeiten, können Sie buchstäblich von jedem Ort aus arbeiten, der über eine halbwegs anständige Internetverbindung verfügt, indem Sie die von mir beschriebenen Technologien und Techniken verwenden (einschließlich während Sie beim Mechaniker auf Ihr Auto warten). Mounten Sie fremde Systeme über SSH, leiten Sie Ports weiter, bohren Sie Tunnel, um aus der Ferne auf Ihren privaten Server oder cloudbasierte Daten zuzugreifen, während Sie einen sonnenverwöhnten Strand überblicken oder in einer nebligen Stadt umweltfreundlichen Kaffee in Hipster-Qualität trinken. TU es einfach!