Don’t build postgres conatiner, use external postgres db on other server
Actual behavior:
All needed data on one server
Hi all,
our old zammad is working in a dmz with a reverse proxy in front and a 90GB Database. We would like to migrate to docker, but the databse shouldn’t be on the same server. Is that possible?
I mapped a postgres database.yml in the container rails-server but the system is not starting after the creation of all containers.
Is that possible, perhaps with the docker-compose-override.yml?
Hi all,
does nobody know if this is an option or is this not a planned feature?
A webservice is normaly active in the dmz zone while the data db is located in the internal LAN.
I like the docker-compose package very much as it is but this is IMHO an important feature. I can change the options by myself if this will never be part of the release but I’d like to use the easy update functions in the future. So I would like to use the yml files as near as they are officialy released.
Yes, thank you MrGeneration, I know the document. However, there are numerous interconnections and dependencies between the containers, so it is not enough to set these Env variables. The Rails server is waiting for the init container, which is waiting for the Postgres container, which shouldn’t be built with an external DB.
This construct can be rebuilt manually, but this excludes you from the upcoming updates.
For this reason, the question of whether this, in my opinion, sensible extension will be built in via a global switch or whether this is not planned. I don’t want to follow a parallel path if it isn’t necessary.
Or am I wrong in assuming that a database shouldn’t be run in a DMZ?
Hi MrGeneration,
sorry for the late reply because my holidays…
OK, my train of thought is as follows. In a small environments with internal access via LAN, the Docker version is a perfect solution. In larger companies that process customer data and thus personal data via Zammad, these must be adequately protected according to the GDPR (DSGVO). This applies in particular the external access to customer data, as is usually the case with ticket systems. Not installing the database in the DMZ here corresponds to the state of the art and the specifications of the BSI.
Installing the Zammad in larger environments via Docker makes perfect sense. So here I can extensively rebuild the existing Docker variant and thus make upcoming updates more difficult or there is a switch (env variable) that creates the Docker container without Postgres container and accesses an external database via env variables.
Your hint was to manipulate the env variables, but I didn’t find a way to build the docker container with an external database just by env. Or didn’t I just not find it?
Hi,
yes, thank you, we already spoke about that solution on the 20.June (see above)… But that is not working. Did you try once?
I surely can use the “postgres_*” env parameters to connect to a foreign database somewhere else. But I can’t use the docker-compose version because it is not enough to change these to create running containers.
The rails container will not start because it waits for the init container. The init container will not find the database because it doesn’t care for the env parameters in the “database.yml”.
Three of the ten containers have a
depends_on:
- zammad-postgresql
line. The container which shouldn’t be created. And so on…
Hi MrGeneration,
yes, I agree, but this leads to my inital question if it is planned in the future to add this option in any way to the docker version…
I can change all the files by myself to get this up and running but after that this will be necessary again and again whenever an update is released. That’s my point…
The Docker support for Zammad is community-driven. You could do everything on your own and create a pull request in GitHub for it. Maybe it will be accepted, I don’t know.
