Symfony Messenger

[norkunas]

How to run Symfony Messenger with this setup?

I thought about this in compose.yaml:

  php-worker:
    build:
      context: .
      target: frankenphp_dev
    image: ${IMAGES_PREFIX:-}app-php
    restart: unless-stopped
    command: php bin/console messenger:consume async -v

Does it make sense? What are the options? Would be good to add something about this to README :)

[dunglas]

I use something similar in my projects.

This definitely is worth a documentation section!

[MrSpoocy]

Same here, I'm not sure if I create a second container or maybe frankenphp can handle the consumer in a second thread.

[norkunas]

noticed one thing with this approach, that all the images at startup tries to run database migrations

[MichaelBrauner]

I think that's totally fine.
Every container will try to run migrations.
As long as you have a single source of truth for your migrations (one database server for all containers) you should be fine.

[norkunas]

Yes, the first one to run wins :) but I am thinking for a flag that I'd set on the main container, and on messenger/scheduler containers not setting it then entrypoint could run based on that condition, is that possible?

[MichaelBrauner]

Yes, that is of course possible:

  php-worker:
    build:
      context: .
      target: frankenphp_dev
    image: ${IMAGES_PREFIX:-}app-php
    restart: unless-stopped
    command: php bin/console messenger:consume async -v
    environment:
       - RUN_MIGRATIONS=false

And then react to it inside your entry point script:

if [ "$RUN_MIGRATIONS" = "true" ]; then

But I personally would advise against it.
At the moment you just have a simple php container that is no different from the others, except for the command.
That's simple and easy.

Since migrations cannot be executed twice anyway there is no need for additional logic imho.
But it's up to you.

[norkunas]

Thanks :)

[norkunas]

Since migrations cannot be executed twice anyway there is no need for additional logic imho.

Yes, but it's slows down a little bit container startup time :)

[noximo]

Can I ask why the target is frankenphp_dev and not prod?
Or it should be overridden in compose.prod.yml?

[norkunas]

For the prod I run the build in github actions and then fetch from ghcr registry, but if you want to build on your server then I think the answer is yes, it should be overriden in compose.prod.yaml

[noximo]

Thank you!

[noximo]

The configuration didn't work for me in the end and I had to do some tweaks.

In compose.yml:

services:
    php:
        image: ${IMAGES_PREFIX:-}app-php
        restart: unless-stopped
        environment:
            ...
            RUN_MIGRATIONS: true
        volumes:
            - ...
            - var_log:/app/var/log
    php-worker:
        build:
            context: .
            target: frankenphp_dev
        image: ${IMAGES_PREFIX:-}app-php
        restart: unless-stopped
        command: php bin/console messenger:consume -vvv
        environment:
            DATABASE_URL: postgresql://${POSTGRES_USER:-app}:${POSTGRES_PASSWORD:-!ChangeMe!}@database:5432/${POSTGRES_DB:-app}?serverVersion=${POSTGRES_VERSION:-15}&charset=${POSTGRES_CHARSET:-utf8}
            RUN_MIGRATIONS: false
        volumes:
            - var_log:/app/var/log
        depends_on:
            - php
            - database

in compose.override.yml:

services:
    php:
        ....
    php-worker:
        volumes:
            - ./:/app

and finally compose.prod.yml:

services:
    php:
        build:
            context: .
            target: frankenphp_prod
        environment:
            APP_SECRET: ${APP_SECRET}
        volumes:
            - var_log:/app/var/log
    php-worker-async:
        build:
            context: .
            target: frankenphp_prod
        environment:
            APP_SECRET: ${APP_SECRET}
        volumes:
            - var_log:/app/var/log

Most important is the volume in compose.override.yml. Without it, worker had no access to code and kept trying to install symfony from scratch. (Which wasn't problem when targeting frankenphp_prod as that contains all the linking in Dockerfile directly).
The var_log volume is something I need, without it I wasn't able to access logs from worker within the main app.

I'm not that versed in docker, so this may not the be optimal solution but it works for me so far. Nonetheless, if there's something to improve, I'm all ears.

[noximo]

Another improvement. I need to run several consumers in parallel. I guess that would be a good use case for the supervisor but I was unable to get that running, so I circled back to docker compose, despite some of its drawbacks.

The config is mostly the same as in the above examples, I just specified transport in the command.

Then I've added this to compose.yml:

    php-worker-slow:
        extends:
            service: php-worker
        command: php bin/console messenger:consume scheduler_slow -vvv --time-limit=60 --limit=10 --memory-limit=128M
    php-worker-fast:
        extends:
            service: php-worker
        command: php bin/console messenger:consume scheduler_fast -vvv --time-limit=60 --limit=10 --memory-limit=128M

and this to the other two:

  php-worker-slow:
        extends:
            service: php-worker
    php-worker-fast:
        extends:
            service: php-worker

Running more instances in parallel should be just a matter of duplicating the service under a new name. Sadly, you need to duplicate in all three files