… aber das sind ja gleich zwei Dinge auf einmal. Richtig. Denn hier versuche ich, etwas nützliches (Kanboard) mit der Möglichkeit, etwas zu lernen (Container), zu kombinieren.
Inspiriert durch Dirks Artikel und einem darauf folgenden, regen E-Mail-Verkehr, widme ich mich mal wieder dem Thema Linux-Container. Zuletzt hatte ich mich ca. 2016/2017 damit befasst und es mit der Erkenntnis zu den Akten gelegt, dass es noch ein Hype und für den produktiven Einsatz wenig geeignet war. Mittlerweile hat sich die Lage etwas geändert. Einige Unternehmen haben sich des Themas angenommen und arbeiten daran, Linux-Container Enterprise-Ready zu gestalten. So nehme ich wahr, dass in meinem beruflichen Netzwerk seit ca. Anfang 2019 OpenShift-Cluster wie Pilze aus dem Boden schießen. Man könnte den Eindruck gewinnen, dass Red Hat diese Subskriptionen wie geschnitten Brot verkauft. Andere Hersteller scheinen den relativ jungen Markt nicht allein den roten Hüten überlassen zu wollen. So hat VMware mit vSphere 7 und Tanzu hier ebenfalls eine Lösung im Portfolio und auch SUSE scheint sich mit dem Kauf von Rancher in diesem Segment stärker zu engagieren.
Ich selbst möchte mein Wissen rund um dieses Thema auffrischen und habe mir daher folgendes Wochenendprojekt überlegt. Um Projekte, Aufgaben oder schlicht den Alltag besser zu organisieren, möchte ich zukünftig die Anwendung Kanboard nutzen. Diese Anwendung unterstützt die Aufgaben- bzw. Projekt-Organisation nach der Kanban-Methode. Sie macht einen minimalistischen Eindruck, kommt ohne viel Schnick-Schnack daher und scheint daher gut zu mir zu passen. Um gleichzeitig praktische Erfahrungen im Umgang mit Linux-Containern zu sammeln, werde ich Kanboard mit einer Postgresql-Datenbank mit Hilfe von zwei Containern betreiben.
In meinen Augen wird Docker in den nächsten Jahren sowohl als Firma wie auch als Werkzeug stetig an Bedeutung verlieren. Daher setze ich bei der Umsetzung meines Wochenend-Projekts auf die Werkzeuge podman
, skopeo
und buildah
.
Ich gehe in diesem Text nicht auf die Konzepte, die Architektur, sowie die Vor- und Nachteile von Linux-Containern ein. Hierzu wurde in den letzten Jahren bereits genug an anderer Stelle geschrieben. Informationen zu diesen Themen finden sich in der — im Aufbau befindlichen — Linksammlung und am Ende dieses Artikels.
Umfeld
Als Basis für dieses Projekt dient mir eine virtuelle Maschine in meinem heimischen Labor. Als Betriebssystem nutze ich ein aktuelles RHEL 8 mit der kostenlosen Developer-Subskription. Diese VM dient mir als Host zum Ausführen diverser Linux-Container. Um die Container aus dem Netzwerk erreichbar zu machen, installiere ich NGINX aus den Paketquellen von RHEL 8. Dieser kümmert sich als Reverse-Proxy um die Portweiterleitung zu den Containern.
Ziele
Mit diesem Wochenendprojekt möchte ich folgende Ziele erreichen:
- Bereitstellung der Anwendung Kanboard mittels Linux-Container
- Nutzung von Postgresql mittels Container als Kanboard-Datenbank-Backend
- Persistente Speicherung der Kanboard-Inhalte im Dateisystem des Hosts
- Erreichbarkeit und Nutzbarkeit von Kanboard über den NGINX-Reverse-Proxy
- Einrichtung Backup und Restore
- Updates
Schritt 1: rootless-Container-Umgebung einrichten
Während Entwickler viel Schweiß und Tränen investiert haben, damit Dienste wie Apache oder NGINX nach ihrem Start die root-Rechte ablegen können, liefen die ersten Linux-Container durchgängig mit root-Rechten. Dies ist aus Sicht der IT-Sicherheit nicht wünschenswert. Daher ist es in meinen Augen erfreulich, dass es mittlerweile auch ohne root-Rechte geht; Kernel User Namespaces sei Dank.
Ich folge der Red Hat Dokumentation (Kapitel 1.4, [1]), um den User Alice für die Nutzung von rootless-Containern einzurichten.
# echo "alice:165537:65536" >> /etc/subuid
[root@podhost-r8-1 ~]# echo "alice:165537:65536" >> /etc/subgid
[root@podhost-r8-1 ~]# echo "user.max_user_namespaces=65636" > /etc/sysctl.d/userns.conf
[root@podhost-r8-1 ~]# sysctl -p /etc/sysctl.d/userns.conf
user.max_user_namespaces = 65636
Anschließend installiere ich wie in Kap. 1.3 [1] beschrieben die Container-Tools.
# yum module install -y container-tools
$ podman --version
podman version 2.0.5
Der Werkzeugkasten ist bestückt. Weiter zu Schritt 2.
Schritt 2: Container-Images suchen, inspizieren und herunterladen
Mit dem Kommando podman
mache ich mich auf die Suche nach Containern für Kanboard.
$ podman search kanboard
INDEX NAME DESCRIPTION STARS OFFICIAL AUTOMATED
docker.io docker.io/kanboard/kanboard Official Docker image for Kanboard 34
docker.io docker.io/webhippie/kanboard Docker images for Kanboard 2 [OK]
docker.io docker.io/larueli/kanboard-nonroot Safe image for Kanboard as Non Root / Suitab... 0
docker.io docker.io/masker/kanboard use alpine linux build kanboard server 0
docker.io docker.io/xoxys/kanboard Deprecated 0
docker.io docker.io/dotriver/kanboard Kanboard on Alpine Linux + S6 Overlay 0
docker.io docker.io/thegeeklab/kanboard Custom image for Kanboard Kanban project man... 0
docker.io docker.io/jonats/kanboard-pi Raspberry Pi image for Kanboard 0
docker.io docker.io/bastilian/kanboard 0
docker.io docker.io/oriaks/kanboard Kanboard 0 [OK]
docker.io docker.io/kanboard/tests 0
docker.io docker.io/blufor/kanboard Kanboard with Postgres, SMTP and GitLab inte... 0 [OK]
docker.io docker.io/boomer/kanboard Kanboard is a simple visual task board web a... 0
docker.io docker.io/joshuacox/kanboard-redmine kanboard redmine importer 0 [OK]
docker.io docker.io/janost/kanboard-unit Kanboard + nginx unit, running rootless with... 0
docker.io docker.io/benoit/kanboard 0 [OK]
docker.io docker.io/lidstah/kanboard Kanboard armv71 debian (nginx/php7-fpm) base... 0
docker.io docker.io/doc75/kanboard 0
docker.io docker.io/witsec/kanboard Kanboard, with the option to filter (hide) s... 0 [OK]
docker.io docker.io/ionutalexandru97/kanboard-openshift Kanboard ready to be deployed on OpenShift 0
docker.io docker.io/hihouhou/kanboard simple kanboard 0 [OK]
docker.io docker.io/alxsdhm/kanboard kanboard image 0
docker.io docker.io/papango/kanboard 0
docker.io docker.io/mrtheduke/kanboard kanboard 0
docker.io docker.io/kvorobyev/kanboard_app
Herzlichen Glückwunsch. Die Trefferliste stellt für mich als SysAdmin einen Alptraum dar. Sämtliche Treffer stammen vom Docker-Hub, einem riesigen Misthaufen für Software (welcher durchaus ein paar Perlen enthalten kann). Von den 26 Treffern ist keiner als OFFICIAL markiert, lediglich die Anzahl STARS bietet einen Anhaltspunkt, welcher Container den meisten Zuspruch findet. In einer Produktiv-Umgebung sollte man sich jedoch nicht allein auf diese Sterne verlassen. Ich inspiziere das Container-Image mit den meisten Sternen mit skopeo
:
$ skopeo inspect docker://docker.io/kanboard/kanboard | less
Die vollständige Ausgabe spare ich hier aus. Sie ist wenig hilfreich. Mit ein wenig Internet-Recherche ([2], [3] und [4]) bin ich hinreichend sicher, das „offizielle“ Container-Image des Projekts gefunden zu haben.
Als nächstes mache ich mich auf die Suche nach Postgresql:
$ podman search postgresql | wc -l
64
Naja, zumindest an Auswahl scheint es auch diesmal nicht zu mangeln. Hier komme ich so jedoch nicht weiter. Also nehme ich einen Webbrowser zur Hand und recherchiere ein geeignetes Container-Image unter der URL: https://catalog.redhat.com/software/containers/explore
Da ich Red Hat bereits zutraue, eine stabile und hinreichend sichere Enterprise Linux Distribution zu bauen, traue ich ihnen auch zu, ordentliche Container-Images für Postgresql zu bauen. Daher fasse ich folgende drei Kandidaten ins Auge:
Zu diesem Zeitpunkt (2020-12-27) fehlt Nr. 3 eine ordentliche Beschreibung. Dafür kommt dieses Image mit 6 offenen Sicherheitslücken daher. Nr. 2 besitzt nur 3 Schwachstellen und eine deutliche bessere Dokumentation zu dessen Verwendung. Und Nr. 1 ist zwar das Älteste, jedoch auch das mit einer guten Dokumentation und ohne Schwachstellen.
Kanboard erfordert Postgresql >= 9.4. Damit ist Nummer 1 mein Gewinner. Mit den beiden folgenden Kommandos hole ich mir die Kanboard- und Postgresql-Container-Images auf meinen Host.
$ podman pull docker.io/kanboard/kanboard
Trying to pull docker.io/kanboard/kanboard...
Getting image source signatures
Copying blob df20fa9351a1 done
Copying blob 3108c8300796 done
Copying blob b190b4dd9bb5 done
Copying blob bb1f52abd628 done
Copying blob e37ffd2cbe7b done
Copying config c355188e0c done
Writing manifest to image destination
Storing signatures
c355188e0c187bc891826d282cc850cbe0907ccd7df28d4487d024d831c4f9af
$ podman login --username=Joerg-Dev registry.redhat.io
Password:
Login Succeeded!
$ podman pull registry.redhat.io/rhel8/postgresql-96
Trying to pull registry.redhat.io/rhel8/postgresql-96...
Getting image source signatures
Copying blob cca21acb641a done
Copying blob 620696f92fec done
Copying blob fca753c96be9 done
Copying blob d9e72d058dc5 done
Copying config f7266b012d done
Writing manifest to image destination
Storing signatures
f7266b012db03478b858eba6af4264829b99ce9ac67d6bc8a7c273b5fc5c8e9a
Damit ist dieser Schritt abgeschlossen. In Schritt drei erstelle ich sogenannte Volumes, um Daten außerhalb der Container persistent im Dateisystem des Hosts speichern zu können.
Schritt 3: Persistenten Speicher für Container erzeugen
Nach dem Container-Mantra haben diese zustandslos zu sein. Dies bedeutet, dass in ihnen gespeicherte Daten verloren gehen, wenn der Container entfernt wird. Nun hat es die Elektronische Datenverarbeitung (EDV) so an sich, dass das Ergebnis der Verarbeitung häufig persistent zu speichern ist. Dies kann im Container-Universum mit sogenannten Volumes erledigt werden. Hierbei wird ein Verzeichnis vom Host in den Container eingehängt.
Für mein Projekt erstelle ich nach Kapitel 3.4 [1] folgende Volumes:
- kanboard_data
- kanboard_plugins
- kanboard_ssl
- pgsql_db
$ podman volume create VOLUMENAME
Um im Folgenden etwas leichter mit diesen Volumes arbeiten zu können, speichere ich den Einhängepfad in Variablen à la:
$ mntPoint=$(podman volume inspect VOLUMENAME --format {{.Mountpoint}})
Die obige Streichung erfolgte, da dieser Schritt nicht notwendig ist und im weiteren Artikel nicht mit entsprechenden Variablen gearbeitet wird.
Schritt 4: Kanboard konfigurieren
Um eine angepasste, persistente config.php-Datei für den Kanboard-Container zu schreiben, ist etwas Vorarbeit notwendig. Der Kanboard-Container wird gestartet und das Volume „kanboard_data“ wird dabei in den Pfad /var/www/app/data gemountet. Anschließend starte ich eine Shell im Container und kopiere die Datei /var/www/app/config.default.php
nach /var/www/app/data/config.php
.
$ podman run -d --name kanboard -v kanboard_data:/var/www/app/data:Z kanboard/kanboard
93e6d7e3847fb94639b8fce89ddb93a3879a80522f95ed13dff91f6558594ac6
$ podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
93e6d7e3847f docker.io/kanboard/kanboard:latest 5 seconds ago Up 5 seconds ago kanboard
$ podman exec -it 93e6d7e3847f /bin/bash
bash-5.0# cp /var/www/app/config.default.php /var/www/app/data/config.php
bash-5.0# exit
exit
$ podman stop 93e6d7e3847f && podman rm 93e6d7e3847f
$ vi $kanboard_data/config.php
Um Postgresql als Datenbank-Backend zu nutzen, werden folgende Werte in der config.php
gesetzt:
// Run automatically database migrations
// If set to false, you will have to run manually the SQL migrations from the CLI during the next Kanboard upgrade
// Do not run the migrations from multiple processes at the same time (example: web page + background worker)
define('DB_RUN_MIGRATIONS', true);
// Database driver: sqlite, mysql or postgres (sqlite by default)
define('DB_DRIVER', 'postgres');
// Mysql/Postgres username
define('DB_USERNAME', 'root');
// Mysql/Postgres password
define('DB_PASSWORD', 'SuperSicheresPasswort');
// Mysql/Postgres hostname
define('DB_HOSTNAME', 'localhost');
// Mysql/Postgres database name
define('DB_NAME', 'kanboard');
// Mysql/Postgres custom port (null = default port)
define('DB_PORT', null);
Normalerweise würde man eine Anwendung niemals mit dem Datenbank-Root-User auf eine Datenbank zugreifen lassen. In dieser Umgebung ist es hingegen verschmerzbar, da nur die Daten des Kanboards in diesem Postgresql-Container gespeichert werden. Im Falle einer Kompromittierung verliere ich nur die zur Anwendung gehörende Datenbank.
Schritt 5: Pod erstellen und Container hinzufügen
Mit diesem Schritt habe ich etwas Mühe. Zuerst wollte ich einen Pod erstellen, den Kanboard- und Postgresql-Container zu diesem hinzufügen, um sie stets gemeinsam starten und stoppen zu können. Dies ist laut [1] und [7] der einfachste Weg. Allerdings habe ich dann in [5] und [7] gelesen, dass sich die Container eines Pods dessen IP, MAC und Port-Bindings teilen. Dies bedeutet, dass Portfreigaben für Kanboard (80 und 443 TCP) auch für den Postgresql-Container gültig sind. Dies möchte ich eigentlich nicht. Doch ist mir bisher nichts besseres eingefallen. Falls ihr Anregungen oder konkrete Beschreibungen habt, wie ich dies besser umsetzen kann, immer her damit.
Frickelpit hat mich in seinem Kommentar darauf hingewiesen, dass man den Zugriff auf den Port des Pods noch weiter beschränken kann, indem man diesen an 127.0.0.1 bindet. Ich habe unten stehenden Code-Block entsprechend aktualisiert.
Ich erstelle nun gemäß [7] einen neuen Pod, welcher den Kanboard-Container beinhaltet und für diesen Port-Bindings besitzt:
$ podman run -d --pod new:kanboardpod --name kanboard -p 127.0.0.1:8080:80 -v kanboard_data:/var/www/app/data:Z -v kanboard_plugins:/var/www/app/plugins:Z kanboard/kanboard
e62c7fa2ecf771f4085e788e9f0f7d24b7f87d487e9951a403847d8a7a2a6471
$ podman pod ps
POD ID NAME STATUS CREATED # OF CONTAINERS INFRA ID
d7afa6821382 kanboardpod Running 8 seconds ago 2 6b065fe7ecc7
$ podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
6b065fe7ecc7 k8s.gcr.io/pause:3.2 10 seconds ago Up 10 seconds ago 0.0.0.0:8080->80/tcp d7afa6821382-infra
e62c7fa2ecf7 docker.io/kanboard/kanboard:latest 10 seconds ago Up 10 seconds ago 0.0.0.0:8080->80/tcp kanboard
Im zweiten Schritt füge ich den Postgresql-Container hinzu:
$ podman run -d --pod kanboardpod --name pgsql_db -e POSTGRESQL_USER=root -e POSTGRESQL_PASSWORD=SuperGeheimesPasswort -e POSTGRESQL_DATABASE=kanboard -v pgsql_data:/var/lib/pgsql/data:Z rhel8/postgresql-96
c242a4b9b57d53a822585c9eb83d081d5abbd40cb2b5952aee4457fee041e128
$ podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
6b065fe7ecc7 k8s.gcr.io/pause:3.2 2 minutes ago Up 2 minutes ago 0.0.0.0:8080->80/tcp d7afa6821382-infra
c242a4b9b57d registry.redhat.io/rhel8/postgresql-96:latest run-postgresql 3 seconds ago Up 3 seconds ago 0.0.0.0:8080->80/tcp pgsql_db
e62c7fa2ecf7 docker.io/kanboard/kanboard:latest 2 minutes ago Up 2 minutes ago 0.0.0.0:8080->80/tcp kanboard
Nun läuft ein Pod mit drei Containern (Infra-, Kanboard- und Postgresql-Container). Rufe ich http://IP-DES-HOSTS:8080
in einem Webbrowser auf, begrüßt mich bereits die Kanboard-Anmeldemaske (Bild 1).

Schritt 6: Nacharbeiten
Zwar konnte ich mich bereits an der Kanboard-Anwendung anmelden, neue Nutzer erstellen und Profileinstellungen verwalten, doch beim Dateiupload klemmte es noch. Hier musste ich in der config.php
-Datei des Kanboard-Containers den folgenen Standardwert, wie im Codeblock gezeigt, angepassen:
// Folder for uploaded files (must be writeable by the web server user)
// Folgende Zeilen wurden auskommentiert
// define('FILES_DIR', DATA_DIR.DIRECTORY_SEPARATOR.'files');
// Folgender Eintrag wurde hinzugefuegt
define('FILES_DIR', 'data/files');
Abschließend habe ich den Kanboard-Container mittels podman restart kanboard
neugestartet.
Fazit
Bei der Internet-Recherche nach guter Dokumentation und der Arbeit mit einigen Container-Registries erinnere ich mich an ein Zitat:
Das Internet ist ein großer Misthaufen, in dem man allerdings auch kleine Schätze und Perlen finden kann.
Joseph Weizenbaum, Vortrag in Hamburg am 2. Mai 2001, heise.de
Bisher wurden die Ziele 1-3 erreicht. Die dabei verwendeten Befehlszeilen besitzen eine beachtliche Länge. Hier bietet es sich an, die Befehle in kurze Shell-Wrapper zu verpacken.
Die Ziele 4 und 5 werde ich in einem Folgeartikel, an einem anderen Wochenende, in Angriff nehmen. Und auch der Frage, wie man diesen Verhau am besten aktualisiert und Updates implementiert, werde ich noch nachgehen.
Ihr habt bis hierhin durchgehalten? Dann danke ich euch für euer Interesse. Was haltet ihr von diesem Wochend-Projekt? Wieviel Sinn bzw. Unsinn steckt darin? Bitte lasst es mich in den Kommentaren oder auch gern per E-Mail wissen.
Quellen und weiterführende Links
- Building, running, and managing Linux containers on Red Hat Enterprise Linux 8
- Kanban Project Management Software — Kanboard
- Running Kanboard with Docker
- Kaboard Releases
- https://podman.io/getting-started/network
- Podman: Managing pods and containers in a local container runtime; Brent Baude; January 15, 2019
Schöner Artikel, Jörg!
In der Firma setzen wir Kanboard auch als Container ein.
Privat habe ich zwei Container-Lösungen laufen:
The Lounge – https://thelounge.chat/
Umami – https://umami.is/
Danke, Dirk! :-)
Schöner Artikel zu podman, seit ein paar Wochen nutz ich es auch und habe Docker in den Ruhestand geschickt bei mir.
bzgl. der Portfreigaben hab ich weniger Bedenken. Du erstellst für Deinen Pod ja nur die Freigabe für den Port 8080 auf den Containerport 80. Da in Deinem psgl nichts auf 80 lauschen sollte, find ich das weniger kritisch. Wenn Du aber eh einen nginx davor schnallst, kannst Du ja den Port an localhost binden (127.0.0.1:8080:80), damit kann man nur über 80/443 durch den nginx an den Container.
Danke, zu dem Hinweis mache ich mir gleich noch einen Knoten ins Taschentuch, damit ich die Option nicht vergesse. :-)
Moin,
schöner Erfahrungsbericht über die ersten Schritte :)
Was dein Problem mit den container ports angeht, wäre die kanonische Lösung wohl eher, zwei Pods zu verwenden. Dadurch werden die Dienste und ihre Ressourcenbeschränkungen entkoppelt und können bei Bedarf ausgetauscht / upgraded / woanders gestartet, etc. werden. Allerdings macht das das handling wie o.g. etwas komplexer.
Im Docker Umfeld verwendet man dafür container networks (für die interaktion zwischen pods) und docker compose (https://docs.docker.com/compose/), bei podman gibt es wohl jemanden der etwas analoges dazu gebaut hat: https://github.com/containers/podman-compose
Der Vorteil dabei ist, dass du auch kein frickeliges shellscript basteln musst, um deine o.g. Reise reproduzierbar zu machen. Ein YAML File und ein podman-compose up reichen aus. Ggf. mag man das YAML file sogar in ein git o.ä. stopfen und bekommt dann sowas wie einfache Rollbacks etc. geschenkt.
Alternativ schau dir mal das podman play command an, das arbeitet mit kubernetes pod definitionen (die man mit podman generate kube $podname generieren kann)
Upgrades sind dann btw. meist nur ein Anpassen der Versionen im YAML file und ein Neustart des betreffenden Pods (Nachdem man das Changelog aufmerksam gelesen hat ;)
Noch ein Hinweis, wenn du das ganze produktiv einsetzen möchtest, rate ich von der Verwendung von container images ohne explizites version tag ab. Manch einer mag das schick finden wenn man sich dadurch implizit „lastet“, also die letze aktuelle Version zieht. Man weiß dann aber leider auch nicht mehr sofort welche Version da gerade rennt und updated sich ggf. unbewusst die Software. Alternativ hat man ja „latest“ auf der Platte liegen, updated also nie mehr…
Viel Freude noch bei deiner Reise
Hallo Bernd,
vielen Dank für deinen ausführlichen Kommentar. Ich werde sicherlich etlichen deiner Hinweise noch im Detail nachgehen.
Bzgl. {docker,podman}-compose habe ich mir gedacht, diese Variante zu überspringen und mich direkt mit den Kubernetes-Pod-Definitionen zu beschäftigen. Aber hier ist der letzte Gedanke noch nicht zu gedacht.
Über die Handhabung der Tags habe ich inzwischen auch an anderer Stelle gelesen. Hier werde ich zukünftig stärker mit explizieten Versionen arbeiten.
Die Reise bleibt sicher noch eine Weile spannend. Und um Erfahrungen zu sammeln, werde ich sicher auch noch die ein oder andere Anwendung in Container sperren, für die das Konzept nicht unbedingt ideal ist. Aber einmal so richtig schön zu scheitern, gehört für mich zum Lernprozess dazu. ;-)
Pingback: Backup und Restore im Kanboard-Container-Land | My-IT-Brain
Pingback: Reverse-Proxy für Kanboard im Container | My-IT-Brain
Pingback: Mit Dokumentation zum Datenverlust | My-IT-Brain
Pingback: Podman kann auch Systemd-Service-Units generieren | My-IT-Brain
Pingback: Aktualisierung eines Kanboard-Pods | My-IT-Brain
Pingback: Kommentar: Linux-Container — Spreu und Weizen | My-IT-Brain
Pingback: Rootless-Podman mit Debian Bullseye | My-IT-Brain
Pingback: Der My-IT-Brain Jahresrückblick 2021 | My-IT-Brain
Pingback: Migration auf ein neueres PostgreSQL-Image im Containerland | My-IT-Brain
Pingback: Nextcloud im Container – Teil 1: Der Plan | My-IT-Brain
Pingback: https://site128620615.fo.team/
Pingback: https://625a9a98d5fa7.site123.me/blog/age-dependence-of-healthcare-interventions-for-covid-19-in-ontario-canada
Pingback: canadian prescriptions online
Pingback: canadian pharmacies
Tolle Dokumentation, vielen Dank für’s Teilen :)
Mir stellt sich jedoch die Frage, weshalb ein Reverse-Proxy eingesetzt wird. Ich kann doch von jedem im gleichen Netzwerksegment befindlichen Rechner über die IP-Adresse der VM die Anwendung im Browser oder mittels curl per http://ipadresse:8080 aufrufen. So wirklich benötigt wird hierfür doch kein Proxy, oder liege ich da falsch, bzw. bedenke ich irgendetwas nicht?
Viele Grüße
Thomas
Hallo Thomas,
schön, dass dir mein Wochenend-Projekt gefällt.
Zu deiner Frage bzgl. des Reverse-Proxy. Dieser ist in der Tat optional und kann im heimischen LAN auch entfallen. Ich nutze diesen, um darüber eine TLS-Verbindung auf dem Standartport anbieten zu können. Der Pod selbst ist bei mir nur von localhost aus erreichbar. Wenn du Kanboard im Internet verfügbar machst, empfehle ich dringend die Nutzung eines Reverse-Proxy.
Beantwortet das deine Frage? Sonst frag gerne nochmal nach.
Viele Grüße
Jörg