Mein neues Server-Setup

Dieses Thema beschäftigt mich also schon seit längerem. Und in den letzten zwei Wochen ist es mir endlich klar geworden. Dieser Blogbeitrag ist nicht als Leitfaden gedacht, sondern als Möglichkeit für mein zukünftiges Ich, die Entscheidungsprozesse meines jetzigen Ichs zu verstehen.

Mein Plan ist es, die Leitfäden später als separate Beiträge zu veröffentlichen:

🔗 Proxying lokaler Server mit Tinc

☕+🛸=♥ Einrichten eines Gitea-Servers mit Drone.io CI/ CD

Nginx+SFTP+Traefik einrichten

Svelte-Elemente in eine Hugo-Site einbinden

Anforderungen

Bevor wir uns jedoch mit den technischen Details meines neuen Setups befassen, möchte ich über meine Anforderungen sprechen:

Git

Dieser ist relativ einfach; Ich programmiere, also brauche ich Git. Vorzugsweise öffentlich gehostet, damit ich Code mit anderen Leuten teilen kann, und vorzugsweise mit angeschlossener CI/CD-Pipeline, um die Vorteile von CI/CD nutzen zu können.

PAAS

Ich mag es nicht wirklich, mich um die Infrastruktur zu kümmern, (ich weiß, ironisch, oder?). Zumindest, wenn ich an einem Projekt arbeite und die Infrastruktur nicht der Hauptfokus ist, brauche ich eine Möglichkeit, jede Anwendung, die ich habe, einfach in die Cloud zu deployen.

Static Hosting

Weil ich viele kleine statische HTML+CSS+Javascript-Websites und -Experimente programmiere, möchte ich eine Möglichkeit haben, sie schnell irgendwo zu hosten. Auch dieser Blog muss irgendwo gehostet werden.

Blogging

Ich schreibe nicht viele Blogbeiträge, aber ich möchte trotzdem eine zentrale Plattform haben, um meine Gedanken festzuhalten.

Filesharing

Die meiste Zeit halte ich meine Projektdatei sowohl auf meinem Laptop als auch auf meinem Haupt-PC. Wenn ich an einem Codierungsprojekt arbeite, kann ich diese mit Git synchronisieren, aber dafür muss ich jedes Mal, wenn ich meinen PC wechsle, committen und pushen. Für 3D/Media ist dieser Workflow nicht sehr praktikabel. Um einen besseren Workflow zu erreichen, benötige ich eine Filesharing-Plattform, die ich definitiv selbst hosten möchte, zum einen, weil das Speichern einer großen Datenmenge bei einem Drittanbieter teuer ist, und zum anderen, weil ich die Kontrolle über meine eigenen Daten haben möchte.

Mein vorheriges Setup

In meinem vorherigen Setup habe ich eine Mischung aus externen Diensten verwendet. Für Git-Hosting habe ich Erfahrung mit Github, Gitlab und Bitbucket. Ich habe Erfahrung mit einigen PaaS-Anbietern, IBM Cloud, Google Cloud, aber hauptsächlich Heroku, weil es sehr einfach zu bedienen ist. Meine statische Website wurde mit one.com gehostet, wiederum, weil es sehr einfach zu bedienen war. Ich habe ein paar verschiedene Filesharing-Lösungen ausprobiert, von Google Drive, Dropbox und Mega und einigen selbst gehosteten Lösungen wie Koken.me, Syncthing und Nextcloud. Aber im letzten Jahr habe ich überhaupt kein Filesharing genutzt.

My new Setup

Eine Frage, die man sich jetzt stellen könnte wäre: „Warum benutzt du Cloud und lokale Server?“ Beide haben einige Nachteile und einige Vorteile. Cloud-Server bieten schnelle Netzwerkgeschwindigkeiten und statische öffentliche IPs, aber die Speicherung großer Datenmengen ist recht teuer. Der Festplattenspeicher ist bei lokalen Servern vergleichsweise günstig. Ich habe etwa 60 € für meine 1-TB-Festplatte bezahlt, die speziell für NAS-Situationen entwickelt wurde, bei denen die Laufwerke rund um die Uhr laufen. Außerdem gefällt mir die Idee sehr gut, physischen Zugriff auf meine eigenen Daten zu haben und diese nicht einem Dritten anvertrauen zu müssen. Ein weiterer Vorteil des physischen Zugriffs auf meinen eigenen Server besteht darin, dass ich an Hardwareaspekten wie Netzwerk, Laufwerken und Kühlung herumbasteln und physische Messungen wie Raumtemperatur und Luftfeuchtigkeit vornehmen kann.

Um ganz ehrlich zu sein, der Hauptgrund für mich, einen Cloud-Server zu verwenden, ist, dass ich auf meinem lokalen Netzwerk kein Port-Forwarding verwenden kann, weil wir (meine Mitbewohner und ich) das Passwort zu unserem Router nicht kennen 🤦. Die Lösung dafür ist, ein VPN-Netzwerk mit meinem Cloud-Server zu erstellen und alle Anfragen darüber zu proxyen.

Die Idee ist also, dass ich meinen lokalen Server als Hauptserver verwende und den Cloud-Server als Proxy verwende, um auf meinen lokalen Server zuzugreifen. Der Cloud-Server wird auch als Backup-Server für meine Dateien verwendet, falls mein lokaler Server ausfällt.

Git

Ich wollte definitiv einen Git-Server auf meinem lokalen Raspberry Pi einrichten, weil ich meinen eigenen Code besitzen wollte, wenn das Sinn macht. Mein erster Instinkt war, Gitlab zu verwenden, weil ich die integrierte CI/CD-Pipeline wirklich mag, also habe ich die entsprechende docker-compose.yml heruntergeladen, gestartet und meinen Pi sofort unbrauchbar gemacht, weil es so leistungsintensiv war. Also war Gitlab definitiv nicht die richtige Wahl für mich.

Danach habe ich Gogs ausprobiert, das ist ein leichtgewichtiger Git-Server, der mit Go erstellt wurde. Mir gefiel die Einfachheit des Setups und der Konfiguration wirklich gut, aber die Integration mit meinem CI/CD-Server der Wahl, drone.io, war nicht sehr einfach.

Also landete ich schließlich bei meinem aktuellen Setup, das einen Gitea- und einen Drone.io-Server auf meinem Pi mit einem in der Cloud laufenden Drone.io CI/CD-Runner umfasst. Ich habe den Drone.io-Runner in der Cloud gestartet, weil der Pi arm-basiert ist und das bei bestimmten Docker-Images Probleme verursacht hat.

PAAS

Meine erste Idee war, Dokku zu verwenden, aber aus irgendeinem Grund hatte ich viele Probleme, Dokku als Docker-Image einzurichten. Dann habe ich Caprover ausprobiert, das eine Neubrandung eines Projekts namens CaptainDuckDuck ist, was meiner Meinung nach ein viel besserer Name ist. Caprover war super einfach einzurichten und es ist super einfach zu deployen.

Static Hosting

Ich habe mich für Nginx entschieden. Dies war eine sehr einfache Entscheidung, da ich bereits einige gute Erfahrungen mit nginx und einige nicht so gute Erfahrungen mit der Konfiguration von Apache hatte. Auf meinem Cloud-Server habe ich eine Festplatte mit einem Ordner bereitgestellt, der in ein Nginx-Docker-Image und ein SFTP-Docker-Image eingebunden ist.

Blogging

Aufgrund einiger Erfahrung in der Entwicklung von WordPress-Sites wollte ich meine alte WordPress-Site definitiv nicht behalten. Ehrlich gesagt habe ich nicht viele verschiedene Lösungen ausprobiert, da Hugo einfach zu mir passte, von der rasend schnellen Site-Generierung über den sehr minimalen Overhead bis hin zu den unglaublich flexiblen Asset-Pipelines.

Filesharing

Ich habe mich für Nextcloud entschieden, weil ich es einfach mag und es keine Konkurrenz mit der gleichen Funktionalität zu geben scheint.

Abschluss

Alles in allem bin ich sehr zufrieden mit meinem neuen Setup. Ich habe viel gelernt und es hat mir viel Spaß gemacht. Meine zukünftigen Pläne sind, mein lokales Server-Setup zu einem Cluster-Build aus Pies zu erweitern und auch vielleicht Wireguard anstelle von Tinc auszuprobieren, weil es anscheinend viel schneller ist.

Cheers,

Max