Hauptmenü

Externer SQL Server

Begonnen von Fritz-EDV, 12.10.2020 11:41:45

⏪ vorheriges - nächstes ⏩

Fritz-EDV

Guten Tag an alle!

Bin gerade am evaluieren von KIX 18 für unser Unternehmen. Ich möchte die Datenbank für Sicherungszwecke außerhalb irgendwelcher Docker Geschichten halten.

Habe hierzu unter Debian 10 einen MariaSQL Server aufgesetzt und die Verbindungsdaten sowie die Credentials des DB Users in die environments Datei geschrieben.

Im Prinzip erwarte ich nun, dass KIX die dort angegebene Datenbank nun eigenständig befüllt, sobald es gestartet wird. Es tut sich aber leider nichts dergleichen. KIX verwendet weiterhin die integrierte Datenbank.

environments:
# --------------------------------------------------
# basic configuration
# --------------------------------------------------

# the docker registry to use
REGISTRY=docker-registry.kixdesk.com/public

# the image tag to use for all application images
IMAGE_TAG=stable

# name of the application stack (you need to change this if you want to deploy multiple KIX applications, each one has to have it's own name)
NAME=kix

# --------------------------------------------------
# backend service configuration
# --------------------------------------------------

# the initial password of the 'admin' account (if empty, the default password is "Passw0rd")
INITIAL_ADMIN_PW=

# the port on the docker host system where the backend service is listening
BACKEND_PORT=20000
BACKEND_PORT_SSL=20443

# database connection (see below)
# only change this if you are connecting to an external DBMS
KIXDB_HOST=192.168.1.2

# change this to "mysql" if you are connecting to a mysql/mariadb/percona server
KIXDB_DBMS=mysql

KIXDB_DATABASE=fritz_kix
KIXDB_USER=fritz_kix
KIXDB_PASSWORD=secret

# --------------------------------------------------
# frontend service configuration
# --------------------------------------------------

# the port on the docker host system where the frontend service is listening
FRONTEND_PORT=20001
FRONTEND_PORT_SSL=20444

# frontend logging (0=ERROR, 1=WARNING, 2=INFO, 3=DEBUG)
LOG_LEVEL=2

# --------------------------------------------------------
# Self Service Portal service configuration (if available)
# --------------------------------------------------------

# the port on the docker host system where the ssp service is listening
SSP_PORT=20002
SSP_PORT_SSL=20445

# --------------------------------------------------
# DB service configuration
# --------------------------------------------------

# this initializes a database and user for the application
# if you change this you need to change the connection configuration of the backend (see above) as well
POSTGRES_DB=kix
POSTGRES_USER=kix
POSTGRES_PASSWORD=kix



Eine entsprechende Datenbank und der dazugehörige User wurden angelegt. Der User hat ebenfalls alle Rechte auf diese Datenbank bekommen. Wo liegt hier der Fehler?

Torsten Thau

Hi Fritz,


die Verwendung von MariaDB (oder MySQL) ist für on-premise nicht vorgesehen bzw. wird nicht weiter ausgebaut. Wir setzen es in Percona-Flavor aktuell in Cloud-Umgebungen ein. PostgreSQL baut seine Vorteile gegenüber MySQL/MariaDB immer weiter aus, weshalb auch wir überlegen komplett auf PostgreSQL zu schwenken. Es gibt dort zahlreiche bessere Funktionen und Optimierungsmöglichkeiten (z.B. Indizes für LIKE "%something%"-Suchen) die für schnelle Suchen auch nicht unbedingt Elastic Search o.ä. erfordern und dann den Gesamtsetup einfacher halten.


Eine Sicherung der DB kannst Du auch mittels pg_dump (https://www.postgresql.org/docs/12/app-pgdump.html) durchführen.


viele Grüße, Torsten

Fritz-EDV

Danke für die Infos. Dem entnehme ich mal, dass ich bei on-premise Verwendung auf einen PostgreSQL Server setzen sollte.

Dies wirft folgende Fragen auf:

- Welche Abhängigkeiten / Zusatzmodule benötigt dieser für KIX?
- Wie muss ich die environment Datei für die Verwendung des externen Servers anpassen?

Torsten Thau

#3
Hi Fritz,

als DBMS kommt on-premises ein PostgreSQL 12, bislang ohne Zusatzmodule, zum Einsatz. Die PG-Einstellungen findest Du in kix-on-premise/blob/master/linux/db/postgresql.conf (siehe auch [1]). Das Verwenden eines externen DB-Servers ist mit den Images aktuell n.n. möglich.

UPDATE (2020/10/12 17:00): je mehr ich darüber nachdenke, sollte es doch schon möglich sein eine externe PostgreSQL-DB anzuklemmen. Dazu muss natürlich der DB-Server vorhanden sein (PostgreSQL v12). Die DB <kixdbname> muss (leer, utf-8) angelegt und für den Nutzer <kixdbuser> über PW-Auth mittels <kixdbuserpw> voll bearbeitbar sein (role "superuser"). Natürlich muss der Zugriff vom Backend-Service erlaubt sein (pg_hba.conf). Die Verbindungsdaten sind im environment-File zu hinterlegen:


KIXDB_DBMS=postgresql
KIXDB_USER=<kixdbuser>
KIXDB_DATABASE=<kixdbname>
KIXDB_PASSWORD=<kixdbuserpw>
KIXDB_HOST=<dbhost>


Dieser Setup muss erfolgen bevor die Container das erste mal gestartet werden (!). Dann sollte bei Start das Backend nicht den "hauseigenen" DB-Service benutzen sondern sich mit der angegebenen DB verbinden.

Ich habe das n.n. ausprobiert - aber so sollte es funktionieren... let us know :-)


viele Grüße, Torsten

[1] https://github.com/cape-it/kix-on-premise/blob/master/linux/db/postgresql.conf

Fritz-EDV

#4
Der Trick mit dem "Setup vor dem ersten Start des Containers anpassen" war dann die Lösung. Musste die bestehenden Container erst via 'docker rmi' löschen. Die einzelnen Optionen in der environment Datei sollten auf jeden fall nochmal besser Dokumentiert werden. Hätte ohne deine Hilfe jetzt nicht gewusst, welchen Parameter ich bei 'KIXDB_DBMS=' hätte korrekterweise angeben müssen.



So gefällt mir das KIX 18 schon etwas besser. Werde dann wohl noch den SQL Server auf V12 updaten müssen - fürs Erste scheint es jetzt aber auch mit dem 11.9.0 zu laufen.


Jetzt fehlt eigentlich nur noch, dass sich Version 18 auch nativ in ein Linuxhost installieren lässt, ohne dieses ganze Containerkram ... Noch eine zusätzliche Virualisierungsebene neben VMWare / HyperV erscheint mir nicht wirklich optimal.

Torsten Thau

Hej Fritz,

Danke für's Ausprobieren, das Feedback ...und dahin zu gehen wo noch nie ein KIX18-Nutzer gewesen ist ;-)

Die Sache ist, dass wir im Moment den Fokus darauf legen eine Anwendung zu liefern die gute Funktionalität liefert und die auf möglichst vielen Umgebungen (auch Windows) möglichst einfach an den Start zu bringen ist. Die Art der Installation ist da, zugegeben, nicht so im Fokus und Containerisierung der beste Weg das zu erreichen. Ich werde aber mal versuchen einen Abschnitt in die Dokumentation zur Verwendung eines externen DBMS einzufügen.


Die native Installation ist mit allerhand Versionsabhängigkeiten versehen, allein davon ausgehend dass es dass dann für diverse Linux-Installationen bedarf. Dafür fehlen uns leider die Möglichkeiten bzw. ist das Thema nicht so hoch priorisiert.

viele Grüße, Torsten

ostaehr

Hallo zusammen,
habe das auch mal mit Postgres 13 ausprobiert, wenn man es richtig macht, funktioniert es auch. Habe ein paar Anläufe gebraucht.
Zu beachten, für die nächsten Tester, die Docker auch so lieben wie ich - nicht :-)


Als KIXDB_HOST muss die LAN-IP des DB-Hosts gesetzt werden, localhost oder 127er Adressen liegen innerhalb des Docker Containers.
Der Postgres-Host muss auf der IP auch lauschen und Zugriff von der IP des Containers erlaubt sein
Also z.B. (ggf. nach Bedarf einschränken):

/etc/postgresql/13/main/postgresql.conf --> listen_addresses = '*'
/etc/postgresql/13/main/pg_hba.conf --> host    all             all             0.0.0.0/0               md5


Datenbank muss angelegt und leer sein, der User volle Rechte darauf haben, also z.B.
sudo su - postgres

createuser kixdbuser --password
createdb kixdb -O kixdbuser


Ansonsten ... love it!


VG Olli


Torsten Thau

Hej Olli,


Danke für das Feedback und die Hinweise für andere!


Wir haben die Dokumentation zur Verwendung eines alternativen DB-Servers ein wenig ergänzt:


https://github.com/cape-it/kix-on-premise/blob/master/deploy/linux/README.md


..wenn Du da noch einen Tipp zur allgemein-tauglichen Verbesserung hast... die Hinweise zu Anlegen der DB werde ich mal aufnehmen :+1 :-)


CU, Torsten