Update docker + docker compose for dev and prod

[ghost]

First of all, I apologize for the size of the PR 🙏, but I think it would've been difficult to break it down.

This is a PR to rework the docker setup for dev and prod. The highlights are below, but basically the setup was not working well for development (not clear how to set it up, which files were necessary to be where, which env vars were important, updating code locally didn't reflect in the docker environment, etc.).

Now, developers should be able to spin up a development environment with minimal effort with docker installed, see their changes show up on reloads, and even use a debugger (XDebug).

The changes in the dev setup led to changes in production setup as well, though they should be minimal. Most importantly caddy was pulled out of the image to break the tight coupling and allow any reverse proxy with fast CGI to sit in front of mbin.

Highlights

Features

• Create a dev env using docker usable by noobs like me

ln -s compose.dev.yml compose.override.yml
docker compose up

• Support XDebug call from docker on linux with host.docker.internal

Details

host.docker.internal doesn't exist on linux because it's not running docker in a VM. Add following block to php service.

   extra_hosts:
      - "host.docker.internal:host-gateway"

• Support for arbitrary reverse proxy
• Smaller docker image (only necessary stuff is copied into image)
• Documentation for dev docker setup

Bug fixes

• get rid of FATAL: role "root" does not exist in db service created by its healthcheck

TODO

• update docker prod documentation
• mention that resetting means sudo rm -rf docker/storage
  • move .gitignore out of storage otherwise resetting still creates a commit by deleting .gitignore
• docker/storage needs to be writable to mbin user!
  • sudo chmod 777 docker/storage/*

Abandoned tasks for later PRs

• Use whitelist approach in .dockerignore instead of blacklist
• MESSENGER_TRANSPORT_DSN=doctrine://default as documented doesn't work

[CocoPoops]

just a thought but maybe we should use 1 compose file with profiles instead of multiple compose files for prod and dev as i think being able to keep the compose.override file separate for admins to make changes to the compose.yml instead of editing it directly while also being able to keep up with git changes

https://docs.docker.com/compose/profiles/

[ghost]

@CocoPoops that doesn't seem like the right feature to use, unfortunately.

Services can be assigned to one or more profiles; unassigned services start by default, while assigned ones only start when their profile is active

Additionally, if you look at compose.dev.yml and compose.prod.yml, you'll see that the services apply different overrides. For example in compose.dev.yml the php and messenger services mount the CWD under /var/www/mbin so that local changes will be visible upon reloading the page in the browser. That isn't necessary in production because the image will have the source and build files within the image.

We could use a justfile to have a dev and prod target which execute docker compose -f compose.yml -f compose.$env.yml, but that's out of scope for this PR.

[CocoPoops]

@LoveIsGrief hopefully this explains what i meant better

For example, It would allow us to create php-prod and php-dev services in one compose.yml, along with services, and then assign them to corresponding profiles or both if no changes are between prod and dev.

This would allow administrators to override settings for either production or development services independently through the compose.override.yml file.

This flexibility is particularly useful in scenarios like mine, where I use Traefik as a reverse proxy configured via Docker labels. By organizing the Compose files this way, it would be much easier to switch between production and development environments for debugging purposes without the risk of exposing sensitive debug secrets.

[CocoPoops]

I think it would also be easier that way if for some reason we need to change the compose file down the line as we should be recommending admins only change things via the compose.override file

[ghost]

@LoveIsGrief Could you fork my branch and make an example?

For your scenario, you could use include (see doc).

compose.override.yml

include:
  - compose.prod.yml

services:
  traefik: ...

[CocoPoops]

For your scenario, you could use include (see doc).

compose.override.yml

include:
  - compose.prod.yml

services:
  traefik: ...

ill just do this as i just tested using the compose profiles and it doesnt really seem worth it as it kinda makes it a pain to maintain

if anyone wants do that include method for overriding
i had to do this way as you cant override included compose files from the same file they are included in

compose.override.yml

include:
  - compose.prod.yml
  - compose.prod.override.yml 

compose.prod.override.yml

services:
  www:
   labels:
     - add docker labels
  other-services: ...

[CocoPoops]

also just tried switching my instance over to test the image is working and im getting 404's on some images but not others

tried clearing php cache and flushing the redis db but that didnt help

is there anything i would have to change in my .env to get working?

[ghost]

Thank you for testing! I think I know where the issue lies.  When making the image compatible with other reverse proxies, I copy the public/ folder to a volume shared between the php service and the reverse proxy. Uploads probably happen in the php service and end up in the php container but not on the shared volume. I think that's the issue and I'll try to find a solution to that this weekend. Again, thanks for testing!

[melroy89]

Press "Ready for review" (and remove "WIP" from the title) if you think we should review.

[ghost]

@melroy89 I finally have it in a state where the code should be reviewable. I don't know if you guys squash-merge or not. If not, once the reviews are in, I can rebase and rework the commits to get rid of the wip: ... and other commits.

@CocoPoops I think I fixed the issue you were facing with missing media. Please see the migration guide section in the installation/docker.md docs.

[melroy89]

Yes, we normally squash merge the commits. Especially in this PR that is a must haha.

[melroy89]

PHP, DB & Redis can definitely be an internal network (internal: true). Yes, you can have multiple networks in Docker. And in Compose you can also add multiple networks to a single service (eg. messenger can both have internal and external docker networks).

[ghost]

🤔 I'm not sure what advantage that would have for the php and messenger services. If I'm not mistaken those require outgoing access to external networks in order to download stuff and communicate with other instances. The php service should probably be able to access direct incoming traffic. Dunno about the messenger.

The DB and redis could probably be purely internal as I don't believe they'll ever need to access external resources.

Should this be done in another PR? I feel like it could expand the scope of this PR and it might be good to have a separate PR with one concern (docker compose networking) for posterity.

[melroy89]

As fair as I know only the www service (and maybe also the rabbitmq if you enabled the management interface) needs access to the external network, the rest of all the services can do internal communication between the services.

Sure, this can also be done in a follow-up PR.

[ghost]

Created a ticket so it won't be forgotten.

[melroy89]

I now get:

Error response from daemon: driver failed programming external connectivity on endpoint mbin-db (c1c3e1b40be94b691d7a32acbdcde8723b9a7402b68bbb64598c5533e354b1e5): failed to bind port 127.0.0.1:5432/tcp: Error starting userland proxy: listen tcp4 127.0.0.1:5432: bind: address already in use

So this external network will interfere with any host ports that run for example PostgreSQL. Therefore, I reopened this conversation.

[TheVillageGuy]

As Bentigerolich asked for this PR and Average Dude is waiting for approval I am approving this

[melroy89]

I stopped postgresql locally, so it now starts the docker images. Going to http://localhost:8080 gives me:

An exception has been thrown during the rendering of a template ("Asset manifest file "/var/www/mbin/public/build/manifest.json" does not exist. Did you forget to build the assets with npm or yarn?").