Was ist die Ausgangssituation?

Seit vielen Jahren betreibe ich eine Online Bildagentur welche Fotografen die Möglichkeit bietet Ihren Kunden Fotos (z.B. aus einem Kindergartenshooting) anzubieten. Hierzu laden die Fotografen die Fotos in Originalgröße hoch, der Endkunde kann diese bestellen und ich kümmere mich um die Bereitstellung der Downloads oder die Produktion der Bilder. Hier fallen viele Daten an welche bei mir auf diversen NAS-Systemen gespeichert werden. Gleichzeitig müssen zu diesem Zweck diverse Aufgaben erledigt werden, wofür ich einen eigenen Server in Betrieb haben.

Daneben habe ich natürlich auch noch „private“ Daten. Diese liegen auf einem weiteren NAS-System.

Die für die Bildagentur benötigten NAS-Systeme sind heute schon die meiste Zeit aus. Diese werden vom Server per Wake on Lan aktiviert sofern diese benötigt werden (also z.B. für eine Bestellproduktion). Nach der Produktion werden die NAS-Systeme über einen Shellbefehl heruntergefahren.

Der Server und das eigene NAS-System laufen jedoch aktuell jeden Tag und rund um die Uhr.

Green-IT doch wie?

In der Regel ist es so, dass die Bildagentur sich nachts langweilt. Also muss das System hier eigentlich gar nicht laufen. Einzig die zusätzlichen System wie Jira, Gitlab etc. werden ab und an mal gebraucht, das ist aber auch zu vernachlässigen. Also entschied ich mich, den Server zwischen 22 und 5 Uhr morgens zu deaktivieren. Gleiches soll mit dem NAS für die privaten Daten passieren. Die Frage ist nur, wie stelle ich das an?

Schritt 1: rtcwake für den Debian-Server

Eher durch Zufall bin ich auf ein Systemtool namens ‚rtcwake‘ gestossen. Dieses Standardwerkzeug ermöglicht es einen Debian-Server auzuschalten und, falls gewünscht, nach einer definierten Zeit wieder einzuschalten. Das Tool ‚rtcwake‘ ist ein fester Bestandteil des Standardpaketes ‚util-linux‘ welches eigentlich auf jedem System per Default installiert ist. Durch die Ausführung des folgenden Befehles fährt der Server herunter und startet 2 Minuten (120 Sekunden) nachdem dieser ausgeschaltet ist wieder.

sudo rtcwake -m off -s 120

Der Paramenter ‚-m‘ bestimmt ‚wie Tief‘ der Server in den Schlafmodus gehen soll. In meinem Fall entscheid ich mich für den ‚tiefsten‘ Wert ‚off‘. Eine genaue Aufstellung der einzelnen Optionen ist z.B. im Ubuntu Wiki zu finden.

Ich habe mich für einen Cronjob entschieden welcher jeden Tag um 22 Uhr läuft und den Server per ‚rtcwake‘ für 6,5 Stunden (also 23400 Sekunden) schlafen legt. Das funktioniert sehr zuverlässig.

Schritt 2: NAS-Systeme zeitgesteuert starten und stoppen

Von Natur aus bin ich eher ein Fauler Mensch und mag gewisse Routinen. Dazu gehört auch, dass ich mich mit der eingesetzten Technik auskennen und damit möglichst blind interagieren können möchte. Somit kommt bei den NAS-Systemen bei mir nur 1 Hersteller zum Einsatz was es einfacher macht bei der Suche nach „besonderen“ Lösungen. Bei den NAS-Systemen setze ich voll auf die Systeme von QNAP (TS-219* und TS-231*). Die Oberfläche von QNAP bietet bereits eine Möglichkeit eine Zeitsteuerung umzusetzen.

Im Bereich ‚System > Leistung‘ ist der Energiezeitplan zu finden. Hier kann definiert werden zu welchem Zeitpunkt ein NAS-System herunterfahren und wann es wieder gestartet werden soll. In meinem Fall sieht die Konfiguration wie folgt aus:

In meinem Fall fahre ich das NAS um 22:15 Uhr herunter und starte es um 4:50 Uhr morgens wieder. Gegen 5 Uhr starten die einzelnen Synchronisierungsdienste / Datensicherungen so dass die Systeme zur Verfügung stehen wenn diese benötigt werden und ’schlafen‘ wenn diese nicht benötigt sind.

Green-IT auch kleine Schritte helfen

Das Thema Green-IT ist ein recht umfangreiches Thema und geht weit über das Thema „Energiesparen“ hinaus. Ungenutzte Ressourcen zu betreiben ist absolut unnötig und verbraucht nicht nur Energie sondern belastet hierdurch auch den eigenen Geldbeutel. Ich für meinen Teil bin jetzt erstmal froh, dass Systeme die sich „langweilen“ nicht mehr laufen sondern nur dann Energiefressen wenn diese auch benötigt sind.

Der Beitrag Green-IT auch zuhause – Stromsparen durch Zeitsteuerung erschien zuerst auf Das ist die Welt von Thomas.

Spring Boot Anwendung hinter der FritzBox

Wie so viele setze auch ich zuhause eine FritzBox ein. Das ist an dieser Stelle allerdings eigentlich irrelevant, denn die benötigten Features liefert im Grunde jede Router. Damit der Homeserver hinter dem Router aus dem Internet erreichbar ist sind 2 Dinge notwendig:

Sobald diese Konfiguration vorgenommen ist kann der Server, sofern denn alles richtig läuft, aus dem Internet auf dem freigeschalteten Port erreicht werden.

SSL Zertifikat für DynDNS Eintrag erzeugen

Soweit so gut, doch wie kommen wir nun dazu den Hostname, welchen wir über den DynDNS-Anbieter erhalten haben, über ein SSL Zertifikat zu schützen. Im Idealfall soll das Zertifikat dann auch noch kostenneutral verwaltet werden können. Das Stichwort hierfür lautet LetsEncrypt.

Über Let´s Encrypt ist es möglich SSL-Zertifikate mit sauberer Authentifizierungschain zu erstellen, sofern man denn der „Eigentümer des Servers“ ist, also Administrativen Zugang zu selbigem hat. Das Vorgehen ist recht trivial und hier sehr plakativ beschrieben.

Certbot mit Let´s Encrypt auf Debian 10 einrichten

Die ersten Versuche eine geeignete Lösung zu finden brachten mich ein wenig zur Verzweiflung. Na klar man findet diverse Tutorials im Internet, diese sind jedoch meist für Ubuntu oder für altere Debian Versionen. Ab der Version 10 von Debian ist die auf den meisten Seiten beschriebene Installation des Certbot jedoch nicht mehr möglich da für diese Variante Debian nicht mehr unterstützt wird.

Nach ein wenig Recherche dann doch die Lösung, der Certbot muss lediglich über snap auf Debian installiert werden. Im Grund nur ein kleiner Umweg welcher genau so zum Ziel führt.

Nachdem nun das SSL Zertifikat für die „eigene“ DynDNS-Domain eingerichtet wurde kann dieses in einen Keystore für die Java-Anwendung gelegt werden. Dies geschieht über den folgenden Befehl:

openssl pkcs12 -export -in fullchain.pem -inkey privkey.pem -out keystore.p12 -name <applicationName> -CAfile chain.pem -caname root -passout pass:<keystorePass>

Da der Certbot das SSL-Zertifikat regelmäßig erneuert (min. alle 3 Monate) habe ich das Kommando zur Aktualisierung des Keystores in einen Cronjob gepackt. Somit sorge ich dafür dass der Keystore immer über das aktuellste Zertifikat verfügt.

Spring Boot mit SSL Zertifikat – Konfiguration

In Projekten in welchen ich Spring-Boot einsetze versuche ich, die eigentlichen Anwendungen nicht völlig für die Anwender zu öffnen. Ich habe mir angewöhnt, die einzelnen Microservices hinter einem Gateway „zu verstecken“. Dieses Gateway (Spring Cloud Gateway) nimmt alle Aufrufe entgegen, prüft Berechtigungen und Aufbau der Aufrufe. Somit werden nur gültige Requests an die einzelnen Services weiter geroutet.

Durch diesen Ansatz geht der gesamte Traffic über das Gateway. Dieses ist also die einzige Anwendung die direkt von außen aufgerufen werden kann. Somit genügt es, aus externer Sicht, dieses Gateway mit einem SSL-Zertifikat auszustatten. Um diese Konfiguration durchzuführen passen wir nun noch die application.yaml an und fügen den Bereich der SSL-Konfiguration hinzu:

server:
  port: <portAusForward>
  ssl:
    enabled: true
    key-store-type: PKCS12
    key-store: /home/ssl/keystore/keystore.p12
    key-store-password: <keystorePass>
    key-alias: <applicationName>

Der Beitrag Spring Boot mit SSL Zertifikat von LetsEncrypt unter Debian 10 erschien zuerst auf Das ist die Welt von Thomas.

Fakt ist, dass der aktuell eingesetzte Server nun schon über 4 Jahre alt ist und so langsam an seine Leistungsgrenzen kommt. Diverse Docker-Container treiben das aktuelle System, sowohl im Bereich der CPU also auch des Speichers in den Wahnsinn. Zusätzlich habe ich ein neues Projekt in Planung bei welchem diverse weitere Container zum Leben erweckt werden sollen – es muss also was neues her.

Was soll der neue Homeserver tun?

Die zentrale Aufgabe des Homeservers liegt im Betrieb von diversen Docker-Containern und einer eigenen Docker-Registry. Jeder Container für sich hat seine eigenen klar definierten Aufgaben und stellt die unterschiedlichsten Dienste bereit. In der Hauptsache sollen die folgenden Container betrieben werden:

Schnell ist klar dass der neue Server einiges zu tun hat. Zwar liegen viele der Container oft nur „herum“ und langweilen sich zur Tode, dennoch ist der Speicherbedarf und die Anzahl der parallel laufenden Prozesse nicht zu vernachlässigen.

Wahl der Komponenten – CPU First

Anhand der Anforderungen möglichst viele Prozesse parallel laufen zu lassen war für mich schnell klar, dass die CPU möglichst viele Kerne haben sollte. Nach diversen Vergleichen viel die Wahl auf den AMD Ryzen 9 3900X*, welcher mit seinen 12 Prozessorkernen und 4,6 GHz genügend Power bereithalten sollte. Als Mainboard habe ich mich für das Gigabyte B450M-DS3H* entschieden welches durch seine Bauform schön klein ist aber dennoch für meinen Bedarf genügend Schnittstellen liefert.

Abgerundet wird das ganze durch 128 GB der HyperX FURY 3200 MHz DDR4* untergebracht in einem kleinen mit 3 zusätzlichen Lüftern versehenen ATX Desktopgehäuse von SilverStone*.

Dazu kommt nun noch ein wenig „Kleinkram“ wie eine SSD Festplatte, Netzteil, Grafikkarte oder noch Kabel so dass die Summe der Anschaffungen für den neuen Homeserver an der Grenze zu 1.000 EUR schrammte.

Der Aufbau

Wer mich kennt der weiß, dass ich das Schrauben am Computer definitiv nicht zu meinen Lieblingsaufgaben zähle. Dennoch freute ich mich irgendwie darauf meinen neuen Sklaven zusammen zu schrauben und in Betrieb zu nehmen. Zu meiner großen Freude passte alles direkt ohne Probleme zusammen und keines der gelieferten Bauteile war defekt. Somit war der Zusammenbau der Komponenten recht schnell erledigt und das Betriebssystem konnte nach rund 2 Stunden installiert werden.

Als Betriebssystem habe ich mich, wie fast schon gewohnt, für Debian entschieden.

Erfahrungen nach den ersten Tagen im Betrieb

Mein neuer Homeserver läuft sehr verlässlich und ist absolut mega schnell. Die CPU-Temperatur beträgt recht konstante 37 Grad, der Speicherverbrauch liegt im Maximum aktuell ca. bei 50% und der Serverload übersteigt nur beim Trainieren von Rasa NLU Modellen einmal die 4.

Auch die Geräuschentwicklung ist, trotz der 3 Gehäuselüfter, echt entspannt. Ich bin sehr zufrieden mit der neuen Hardware und hoffe, dass diese lange ihren Dienst verrichtet

Der Beitrag Neuer Homeserver – Ryzen 9 3900X mit 128GB erschien zuerst auf Das ist die Welt von Thomas.