Ich hatte vor einiger Zeit das zweifelhafte Vergnügen eine Cloud ohne Cloud zu bauen und da keine automatisch angebundenen LoadBalander vorhanden waren, musste mans ich überlegen wie man das ISITO so zum laufen bekommt, dass es sich anfühlt wie ein echter (Web)Server.
Nun könnte man sage: Hey Jörg, aber XYZ macht einfach einen Ingress und leitet dann nach intern weiter.
Aber ich eben nicht!
Im Grunde wollte ich nur erreichen, dass der olle (web) port nicht auf 12345 rennt (NodePort) sonder ihn einfach auf dem ausgewählten Knoten per Hostort frei gibt.
Ist auch total einfach. Als erstes suchen wir uns feste Server aus, aus denen dann der Istio-Ingress laufen wird
Label
kubectl label nodes ingress1 istiohost=yes
kubectl label nodes ingress2 istiohost=yes
kubectl label nodes ingress3 istiohost=yesDa wir ISTIO sicherlich mit helm instalieren (in meinem Fall habe ich es via Rancher eingerichtet), können wir die Values oder eben die templates so anpassen, dass wir das Istio-Ingress-gateway so anpassen, dass es unter dem Pfad spec.template.spec.containers.[name:istio-proxy].ports einfach
...
- containerPort: 8443
hostPort: 443
protocol: TCP
...nutzt.
Tada - Istio nativ auf Port 443.
ich kam letztens in die Gelegenheit einen nativ betriebenen Mattermost Dienst zu dockerisieren. Dabei sollten natürlich auch die Daten erhalten bleiben.
Wie das geht, zeige ich nachfolgend:
Zunächst einmal müssen wir natürlich ein Backup der Datenbank und der Daten erstellen. Auf meinem System wurde postgresql genutzt und die Daten lagen gemäßg der Dokumentation auch brav unter /opt
su postgres -c "pg_dumpall > /tmp/mattermostbackup_all.psql"
cd /opt
tar -czvf /tmp/mattermostbackup.tgz mattermostNachdem nun die Daten schön geordnet gesichert sind, müssen sie natürich auf den neuen (Docker) Host.
scp /tmp/mattermostbackup_all.psql root@neuer-docker-host:/root
scp /tmp/mattermostbackup.tgz root@neuer-docker-host:/rootMattermost ist so freundlich und stellt gleich ein paar Docker-Compose Files etc zur Verfügung. Sehr löblich. Diese wollen wir nutzen
git clone https://github.com/mattermost/mattermost-docker.git
cd mattermost-docker
docker-compose buildDamit haben wir schon mal unser image gebaut. Nun brauchen wir noch ein paar Volumes. Die Daten vom früheren /opt müssen natürlich anschließend auch dahin kopiert werden. Das die Ordnerstruktur beachtet werden muss ist obligatorisch.
mkdir -pv ./volumes/app/mattermost/{data,logs,config,plugins,client-plugins}
sudo chown -R 2000:2000 ./volumes/app/mattermost/Jetzt kann es losgehen: wir starten die Maschinen
docker-compose up -dSelbstverständlich nutzen wir SSL. Wer will das denn schon nicht machen? Dazu kopieren wir unser super, duper Zertifikat einfach in das Volume und starten das deployment neu.
cp /etc/ssl/mein-tolles-ssl-cert.pem ./volumes/web/cert/cert.pem
cp /etc/ssl/mein-tolles-ssl-key.pem ./volumes/web/cert/key-no-password.pem
docker-compose restartWenn wir schon grade dabei sind, können wir auch unsere Datenbank importieren und so zumindest den Großteil der releanten Datenk rekonstruieren.
docker stop mattermost-docker_app_1
docker stop mattermost-docker_web_1
docker-compose exec db dropdb mattermost -U postgres
docker-compose exec db createdb mattermost -U postgres
cat /root/mattermostbackup_all.psql | docker-compose exec -T db psql -d mattermost -U postgres
docker start mattermost-docker_app_1
docker start mattermost-docker_web_1Quellen und Links
Die Zeit ist wunderbar. Alles ist easy - alles ist einfach. Ein "klick" und schon läuft jegliche Anwendung. Rubust, stabil und ohne jegliche Ahnung von dem was man dafür machen müsste um es selbst zu installieren.
So zumindest erlebe ich die aktuelle Wahrnehmung dank der Angebote von Bezahldiensten wie AWS, Azure und Co.
Ich nutze ja auch gern die Abstraktionebenen - will aber wissen was da los ist. So wäre ich sonst vermutlich aufgeschmissen gewesen, als ich versuchte ein Graylog innerhalb von Rancher mit Hilfe der Helm-Cataloge zu installieren und die WebUI hinter dem nginx-Ingress zu verstecken.
Denn zunächst sieht es ja wunderbar einfach aus: Katalog auswählen, Graylog suchen, ein bisschen anpassen und deployen. Ging auch soweit. nur wollte die WebUI nicht so recht.
Zuerst hatte ich mixed content, dann "We are experiencing problems connecting to the Graylog server running on http://XXXXX". Das Internet sagt einem dann, das man irgendie den Port nach aussen öffnen müsste - was natürlich vollkommender quatsch ist. Zumal ich ja eine SSL-Terminierung haben will.
Lange Rede, kurzer Sinn: Das Graylog Helm-Chart ist kaputt. Dort steht nämlich geschrieben, das man einfach einen Wert für 'graylog.externalUri' setzen muss und schon ist alles super. Leider generiert das Chart nur quatsch, sodass man den Wert manuell überschreiben muss mit
graylog:
config: "http_external_uri = https://mein-super-duper.server/"Damit wird der vom Chart generierte Wert in der Configmap überschrieben (weil einfach zuletzt angefügt) und schon klappt es mit dem ingress.
Komplett sieht das dann so aus:
---
graylog:
config: "http_external_uri = https://mein-super-duper.server/"
replicas: 2
rootUsername: admin
rootPassword: ABSOLUT-GEHEIMES-KENNWORT
input:
udp:
service:
type: ClusterIP
ports:
- name: syslog
port: 514
nodeSelector:
node-role.kubernetes.io/worker: "true"
persistence:
accessMode: "ReadWriteOnce"
enabled: "true"
size: "50"
storageClass: "longhorn"
ingress:
extraPaths[0]:
backend:
serviceName: ssl-redirect
servicePort: use-annotation
path: "/*"
enabled: true
hosts:
- mein-super-duper.serverDeshalb hab ich auch gern Ahnung von den Tools und klicke zu allerletzt auf irgendwelche Buttons... die Lösungen sind viel logischer.