Stoppen des internen MariaDB Dienstes unter "DB" bei EGW 20.1

[DarkTrinity]

Hallo Zusammen,

Um mir den Zugriff auf die Egroupware Datenbank zu erleichtern habe ich die EGW Instanz dahingehend modifiziert, daß die Datenbank halt auf dem Wirt angesteuert wird. Das hat auch geklappt.

Um keine Systemressourcen zu vergeuden und der Sauberkeit wegen, möchte ich diesen Docker-internen Datenbakdienst nun los werden. Dazu habe ich in der /etc/egroupware-docker/docker-compose.override.yml den entsprechenden Bereich de-kommentiert - immerhin suggeriert der Kommentar ja daß dies wohl das richtige Vorgehen dazu ist:

(#) to use the database on the host, uncomment all the following settings to disable the internal db service
db:
image: busybox
entrypoint: /bin/true
restart: “no”

Danach habe ich das Docker- Image aktualisiert:

cd /etc/egroupware-docker
docker-compose stop
docker-compose rm -f
docker-compose up -d
docker-compose stop nginx
docker-compose rm -f nginx
docker-compose up -d

Leider erhielt ich u,a. folgende Ausgaben vom System:

Zu dem ersten root@webqa1:/etc/egroupware-docker# docker-compose up -d

Pulling db (busybox:latest)…
latest: Pulling from library/busybox
d60bca25ef07: Pull complete
Digest: sha256:49dae530fd5fee674a6b0d3da89a380fc93746095e7eca0f1b70188a95fd5d71
Status: Downloaded newer image for busybox:latest
Creating egroupware-db …
Creating egroupware-watchtower …
Creating egroupware-db
Creating egroupware-db … done

Zu dem zweiten root@webqa1:/etc/egroupware-docker# docker-compose up -d

egroupware-watchtower is up-to-date
Starting egroupware-db …
Starting egroupware-db … done
egroupware is up-to-date
egroupware-push is up-to-date
Creating egroupware-nginx …
Creating egroupware-nginx … done

Aus diesen Ausgaben wüprde ich aber erstmal schließen, daß der Docker-interne DB- Dienst nach wie vor läuft und sich auch irgendetwas neues gepulled hat, nämlich “BusyBox”… Laut Wikipedia ist Busybox aber erstmal kein neuer Datenbankdienst sondern ein kleines Mini-Unix…

Das ist jetzt zwar sehr kosmetisch, aber ich würde gerne sicher gehen, daß kein zusätzlicher und ungenutzter Datenbankdienst aktiv ist.

Kann ich das irgendwie prüfen und beeinflussen ?

Lieben Dank vorab

[DarkTrinity]

Also ich habe jetzt einfach mal versucht auf dem sich in Docker befindlichen Datenbankdienst via EGW-Setup eine neue Datenbank anzulegen. Das hat nicht geklappt. Wenn ich zum Vergleich eine Instanz auf dem Datenbankdienst des Hosts/Wirten anlege funktioniert das ohne Probleme. Daraus könnte man schliessen daß der interne Datenbankdienst nicht mehr aktiv ist.

Docker suggeriert das ebenfalls, den das Listing aller aktiven Container via docker ps ergab:

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e08f87f7cf39 phpswoole/swoole:latest “/entrypoint.sh” 13 hours ago Up 16 minutes egroupware-
cd1aae7cc68e containrrr/watchtower:latest “/watchtower --sched…” 13 hours ago Up 16 minutes 8080/tcp egroupware-
30d2ccde7662 nginx:stable-alpine “/docker-entrypoint.…” 21 hours ago Up 16 minutes 127.0.0.1:8090->80/tcp egroupware-
c3a3f802bda8 egroupware/egroupware:20.1 “/entrypoint.sh php-…” 21 hours ago Up 16 minutes 9000/tcp egroupware
a5f283be09f0 quay.io/egroupware/rocket.chat:stable “docker-entrypoint.s…” 24 hours ago Up 3 minutes 127.0.0.1:3000->3000/tcp rocketchat
5b162c70c4ce mongo:4.0 “docker-entrypoint.s…” 24 hours ago Restarting (139) 54 seconds ago rocketchat-
d42c04f2075e quay.io/egroupware/collabora-key:stable “/bin/sh -c 'bash st…” 47 hours ago Up 16 minutes 127.0.0.1:9980->9980/tcp collabora-k

Da steht schonmal nix von MariaDB.

Wenn ich mir alle, also auch die nicht aktiven Container listen lasse, erhalte ich mit docker ps -a folgendes Ergebnis:>

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e08f87f7cf39 phpswoole/swoole:latest “/entrypoint.sh” 13 hours ago Up 17 minutes egroupware-
cd1aae7cc68e containrrr/watchtower:latest “/watchtower --sched…” 13 hours ago Up 17 minutes 8080/tcp egroupware-
30d2ccde7662 nginx:stable-alpine “/docker-entrypoint.…” 21 hours ago Up 17 minutes 127.0.0.1:8090->80/tcp egroupware-
c3a3f802bda8 egroupware/egroupware:20.1 “/entrypoint.sh php-…” 21 hours ago Up 17 minutes 9000/tcp egroupware
0397ba0402c0 busybox “/bin/true” 21 hours ago Exited (0) 21 hours ago egroupware-
ced80bd06def mongo:4.0 “docker-entrypoint.s…” 24 hours ago Exited (0) 24 hours ago egroupwarer
a5f283be09f0 quay.io/egroupware/rocket.chat:stable “docker-entrypoint.s…” 24 hours ago Up 10 seconds 127.0.0.1:3000->3000/tcp rocketchat
5b162c70c4ce mongo:4.0 “docker-entrypoint.s…” 24 hours ago Restarting (139) 33 seconds ago rocketchat-
9f74f13f3c48 phpmyadmin “/docker-entrypoint.…” 43 hours ago Exited (0) 43 hours ago pedantic_go
d42c04f2075e quay.io/egroupware/collabora-key:stable “/bin/sh -c 'bash st…” 47 hours ago Up 17 minutes 127.0.0.1:9980->9980/tcp collabora-k

Auch da steht nichts mehr von MariaDB, allerdings ist das besagte BusyBox vorhanden, wenn auch nicht aktiv.

Neugierig wie ich bin, würde mich natürlich schon interessieren wieso ich zum Disablen des internen MariaDB denn BusyBox pullen sollte, obwohl es offenbar garnicht aktiv ist… Ich hatte ja zunächst vermutet, daß BusyBox als Miniunix irgendwie gebraucht wird, damit der Docker mit dem DB-System des Hosts/Wirten kommunizieren kann …

However, ich schätze mal das Deaktivieren des internen MariaDB ist mir gelungen

Damit markiere ich den Thread mal als gelöst

[RalfBecker]

Neugierig wie ich bin, würde mich natürlich schon interessieren wieso ich zum Disablen des internen MariaDB denn BusyBox pullen sollte, obwohl es offenbar garnicht aktiv ist

Das docker-compose.override.yml erlaubt nicht einen Service einfach zu deaktivieren, deswegen verwendet mal halt einen Busybox Container mit “entrypoint: /bin/true” und “restart: no” damit er sich einfach direkt wieder beendet. Das ist besser als der Service im docker-compose.yml auszukommentieren, da es dann bei Änderungen zu Konflikten kommen kann.

Ralf