Den Eintrag hatte ich im Oktober 2020 geschrieben
Neulich hatte Single-T wieder Hastebin erwähnt und da habe ich mir das dann mal genauer angesehen. Nach kurzer Durchsicht wurde klar, dass Hastebin als Backend auch Redis verwenden kann. Und das wäre ja eine schöne Verwendung für den Redis Cluster, der immernoch ungenutzt ist.
Da im Repo des Hasteservers ein Dockerfile zu finden war, habe ich mir einfach das Repo geclont und per "docker build ." einen entsprechenden Container erzeugt und in die Registry gepusht:
Netterweise zeigt der in der Registry eingebaute Scanner gleich zwei kritische Fehler an. Der Haste-Container basiert auf node:14.8.0-stretch - für unseren Anwendungsfall sind die Fehler aber irrelevant, weil hier kein Linux zum Einsatz kommt. Damit der Container sich mit dem Redis verbinden kann, wird er im entsprechenden Netzwerk erzeugt:
root@e3b75fc5-3621-cdd8-f9dd-c9acbf4a37e9:~# triton-docker run -d --name hastebin --network=879ae5a2 --env STORAGE_TYPE=redis --env STORAGE_HOST=192.168.5.22 --env STORAGE_PORT=6379 --env STORAGE_PASSWORD=geheim myreg.code-xyz.net/haste/haste:2020101501
Im Log sieht das dann so aus:
root@e3b75fc5-3621-cdd8-f9dd-c9acbf4a37e9:~# docker logs c74f7299cfca
open
> haste@0.1.0 start /usr/src/app
> node server.js
info: configuring redis
info: compressed application.js into application.min.js
info: loading static document name=about, path=./about.md
info: listening on 0.0.0.0:7777
info: connected to redis on 192.168.5.22:6379/2
Natürlich hätte man auch gleich den Hastebin-Container mit dem Parameter "-p 7777:7777" so konfigurieren können, dass er auf Port 7777 von "aussen" erreichbar wäre - aber leider ist der Container nicht für eine Verwendung mit SSL-Zertifikaten oder gar Letsencrypt vorbereitet. Um den Zugriff per SSL abzusichern, ist also noch ein Webserver vorzuschalten. Dazu eignet sich z. B. eine "minimal" SmartOS-Instanz mit 128 MB RAM. Dort wird aus dem pkgsrc Repository nginx 1.19 installiert und als Reverse-Proxy mit SSL-Terminierung konfiguriert. Zusätzlich kommt noch triton-dehydrated zum Einsatz, um immer frische Letsencrypt-Zertifikate vorweisen zu können. Damit der nginx sein Backend - den Hastbin Docker Container - erreichen kann, muß auf diesem noch der Port 7777 für den Zugriff freigeschaltet werden. Damit ist https://haste.code667.net/ schonmal benutzbar.
Nun hatte Single-T immer davon geschwärmt, dass man Hastebin ja auch von der Konsole verwenden könne. Richtig: Es gibt auch einen Haste-Client, der in Ruby geschrieben ist. Nach setzen der Umgebungsvariable "HASTE_SERVER=https://haste.code667.net/" kann mit "cat foo.txt | haste" der Haste-Server auch von der Konsole aus benutzt werden.
Auch Pastebin kann so benutzt werden, wenn man sich den gelisteten Python-Schnipsel installiert. Allerdings werden dort die letzten Pastes (auch von anderen Benutzern) immer noch eine Zeit lang angezeigt. Ausserdem ist die Ausgabe bei Hastebin natürlich schöner.
Und prompt sieht man auch Bewegung im Redis-Dashboard:
Auf der Serverseite stellt sich das ganze dann so dar (angezeigt werden Megabytes):
[root@hh24-gts2-de22 (de-gt-2) ~]# zonememstat -a |grep -i haste
9f9e561f-235e-c7c7-f418-e668394666e7 hasteprox 28 128 0 0 9,66797
c74f7299-cfca-e5ce-b588-dbb0d96c95eb hastebin 41 1024 0 0 0,622559
Man kann hastebin natürlich auch in einer SmartOS-Instanz starten da die Node.js-Version über pkgsrc zur Verfügung steht - mit nginx in der selben Instanz (wobei hastebin dann auf 127.0.0.1:7777 lauscht). Speichertechnisch sieht das dann so aus:
[root@hh24-gts2-de22 (de-gt-2) ~]# zonememstat -a |grep haste
9f9e561f-235e-c7c7-f418-e668394666e7 hasteprox 28 128 0 0 9,96323
c74f7299-cfca-e5ce-b588-dbb0d96c95eb hastebin 41 1024 0 0 0,622559
31eb8ce7-f348-ca90-d26c-a0eef042729c nodehaste 85 128 4 5 16,3689
Um das Ganze dann noch etwas resilienter aufzubauen, ist es sinnvoll das CNS von Triton zu verwenden. Bis jetzt gibt es nur einen nginx-Proxy und einen hastbin Docker-Container. In Triton ist es relativ einfach, einen "Service-Eintrag" im DNS zu machen, mit dem man dann per CNAME auf mehrere Instanzen zugreifen kann, die denselben Service bereitstellen. Dazu gibt man der entsprechenden Instanz einfach über die Metadaten den Key "triton.cns.services" und als Wert den gewünschten Eintrag im DNS mit (hier z. B. "hasteprox"). Damit generiert Triton dann sofort die entsprechenden DNS-Einträge:
toens@wintermute:~$ triton inst get hasteprox |grep hasteprox.svc |grep tgos.xyz
"hasteprox.svc.a5ba23f5-8237-6879-e7e1-ea6f574fbde9.de-gt-2.cns.tgos.xyz",
"hasteprox.svc.a5ba23f5-8237-6879-e7e1-ea6f574fbde9.de-gt-2.snc.tgos.xyz",
"trudesk-default.hasteprox.svc.a5ba23f5-8237-6879-e7e1-ea6f574fbde9.de-gt-2.snc.tgos.xyz"
toens@wintermute:~$ dig +short hasteprox.svc.a5ba23f5-8237-6879-e7e1-ea6f574fbde9.de-gt-2.cns.tgos.xyz
10.65.69.128
10.65.69.106
Genauso kann man auch für die Docker-Container vorgehen - hier sieht die Syntax nur ein wenig anders aus. Weiterhin sollte man per Affinity-Regel auch dafür sorgen, dass die Instanzen/Container auf verschiedenen, physikalischen Hosts landen:
root@e3b75fc5-3621-cdd8-f9dd-c9acbf4a37e9:~# triton-docker run -d --name hastebin1 --network=879ae5a2 --label triton.cns.services=hastebin --env STORAGE_TYPE=redis --env STORAGE_HOST=192.168.5.22 --env STORAGE_PORT=6379 --env STORAGE_PASSWORD=geheim myreg.code-xyz.net/haste/haste:2020101501
fa48d0757a946b40a837bc54887a2cdb7ae74903b1244533b616c2aeca2fc4b7
root@e3b75fc5-3621-cdd8-f9dd-c9acbf4a37e9:~# triton-docker run -d --name hastebin2 --network=879ae5a2 --label triton.cns.services=hastebin --label 'com.docker.swarm.affinities=["container!=~hastebin*"]' --env STORAGE_TYPE=redis --env STORAGE_HOST=192.168.5.22 --env STORAGE_PORT=6379 --env STORAGE_PASSWORD=geheim myreg.code-xyz.net/haste/haste:2020101501
d2502bcc36516a6dfff4ce0c115b19ae6151f3f7612fc9798ececa73c3a8376d
Danach stehen dann zwei Proxies und zwei Docker-Container zur Verfügung, die jeweils über die Service-Einträge verbunden sind. Im Backend arbeitet weiter der Redis-Cluster.