search

LibrePhotos / librephotos-docker

You can find here the Dockerfiles for the automated build process of LibrePhotos.
MIT License
157 stars 101 forks source link

feat: docker house keeping #46

Closed polaroidkidd closed 2 years ago

polaroidkidd commented 2 years ago
polaroidkidd commented 2 years ago

I'm noticing some differences between the docker-compose raw files and the docker-compose files. Which one servers as the "master"?

polaroidkidd commented 2 years ago

and why are we using different DBs in development vs Production? Currently the home for pgadmin is set to $HOME. Is this on purpose?

derneuere commented 2 years ago

The raw files are used, when you want to change the service names with the make command. The only difference should be in the nginx.raw file, as it does need to account for the different names. The missing /ws endpoint was an oversight. Thanks for fixing this 👍

pgadmin is just a tool to look at the database. It's not really a database itself. Not really on purpose, but there is also no reason to save the data on the host system, I think.

If you ask why the db and redis container is not in the docker-compose dev files, we use the docker-compose file in combination like specified here: https://docs.librephotos.com/1/dev_install/

derneuere commented 2 years ago

I am not sure which use case you are trying to solve by allowing for subnet and gateway configuration in production? Usually this just works ™️ 😄

As I understand this, you need this for your dev environment, but I don't really understand why a user who just wants to use it has to configure both subnet and gateway and why he would care to set this.

polaroidkidd commented 2 years ago

subnet and gateway configuration in production

You're right, this is more of a dev thing, although there's no harm in having it in production mode (I ... think? :sweat_smile: ) In development mode it solves the problem of having to manually set the proxy in the package.json file for the frontend. If I currently want to develop for the frontend I have two options

1) Develop from inside the docker container using the VS Code extension. This means that I have to either keep the locally built images or rebuild them every time I head into development mode. 2) If I'm not in vscode, I start up the docker-compose.yaml file and use the dev tag for proxy & backend, then checkout which ip docker assigned to the proxy container, enter ~that IP~ http://localhost and the port of choice into the package.json's proxy configuration and exec npm run start

This PR would enable me to get up and running with frontend development easier and I'm not forced to build the dev containers. 1) Checkout librephotos-docker 2) Start up docker-compose.yaml (in it's current form with the gateway defined) 3) Checkout librephotos-frontend 4) exec npm install & npm run start

Ideally the proxy would automatically configure itself to the docker container's external port.

I appreciate the ease with which I can develop within vs-code, but if I'm not in that cosmos, getting up and running isn't as straight-forward (to me al least). Maybe it would be possible to support both modes of development? When you open librephotos-docker within vscode, you build the local images etc., but when you're using some other tool you can either use the locally built docker containers or develop against the existing dev tags.

pgAdmin

Ah, ok. Currently the path for pgAdmin is set in the user's home directory ($Home). This mounts it to a local volume, but could be a docker-volme as well. I'm not sure how persistent this should be since I have no contact with it. I just know that I got curious when docker added a pgAdmin folder to my home directory. Took me a while to figure out it was coming from this project.

naming The naming changes just expand on 20b774176779e95a76addadde2aa98733d213427. Changing the service names in the docker-compose configuration isn't enough to have those names pop up when using docker ps (They're still called something like librephotos-docker_proxy_1 when they should be following the supplied names)

I guess ths PR is more opinionated than I wanted it to be in the end and as such I'd totally get it if you're not 100% on board with the proposed changes :smile:

Edit:

I just figured out that I don't have to enter the specific docker ip for the proxy container into the proxy configuration for the frontend repo, but can just use localhost. Should I scratch the gateway and subnet docker compose changes?

derneuere commented 2 years ago

Okay, thanks for the explanation 👍

I am fine with the subnet and gateway variables in dev, but I will just get a lot of support questions from regular people if we add this also to prod. And please move the env variables to the dev part of the file 😄

Naming and adding an explicit folder for pgAdmin is also good with me.

polaroidkidd commented 2 years ago

I thought about it and it occured to me that in all my time of selfhosting I've never actually had much use for defining a network :sweat_smile: I removed that part.

What remains is

derneuere commented 2 years ago

Only small stuff, but then I can merge it 👍

polaroidkidd commented 2 years ago

Is there something else I should do here?

derneuere commented 2 years ago

Only the removing of the non used stuff. But I will do it, doesn't take too long :)