Is your enhancement request related to a problem? Please describe.
I wanted to have a simple Docker setup for local use that wasn't intended for development but for using DejaCode. Therefore I had no need for building a Docker container or having a build environment. I was looking for a simple Docker Compose file with the necessary containers that exist.
I was surprised by the explicit volume mount of the Postgresql database seed:
|
- ./data/postgresql:/docker-entrypoint-initdb.d/ |
In this way the Docker compose files have a dependency on this git repository. This mount is present in all Docker compose files in this repository.
In the setup I came up with, I finally added the database seed to get it running. https://codeberg.org/nicorikken/aboutcode-locally
I'm surprised of the additional complexity of managing this database seed in a container-based setup. I would have expected a more implicit setup.
What are the benefits of the requested enhancement?
If the database seed would have been managed from within the built containers, the docker-compose setup would be simpler and would need nothing more than a docker-compose.yml file or maybe an nginx config and environment file if they aren't embedded into the compose file.
Describe the solution you would like
I would expect Dejacode to manage the database seed. I see a few options:
- Ship the database seed within the container. This risks the database seed having become outdated.
- Download the database seed at boot. This risks the download being blocked by the network. A manual install could be documented.
Additional notes
None
Is your enhancement request related to a problem? Please describe.
I wanted to have a simple Docker setup for local use that wasn't intended for development but for using DejaCode. Therefore I had no need for building a Docker container or having a build environment. I was looking for a simple Docker Compose file with the necessary containers that exist.
I was surprised by the explicit volume mount of the Postgresql database seed:
dejacode/compose.yml
Line 12 in c3399c8
In this way the Docker compose files have a dependency on this git repository. This mount is present in all Docker compose files in this repository.
In the setup I came up with, I finally added the database seed to get it running. https://codeberg.org/nicorikken/aboutcode-locally
I'm surprised of the additional complexity of managing this database seed in a container-based setup. I would have expected a more implicit setup.
What are the benefits of the requested enhancement?
If the database seed would have been managed from within the built containers, the docker-compose setup would be simpler and would need nothing more than a
docker-compose.ymlfile or maybe an nginx config and environment file if they aren't embedded into the compose file.Describe the solution you would like
I would expect Dejacode to manage the database seed. I see a few options:
Additional notes
None