QUESTION: Running Crunz in a Dockerized Environment

[g10-fred]

Hi

We've added Crunz to an app built on the official Docker PHP:7.1-apache image. Crunz is there and I can call the command line and it works well but there's no crontab support in the PHP:7.1-apache container.

I've looked around online and it seems that the way to handle this it to have another container that runs a schedule or crontab and this container calls the required command in the App container.

My question is: Is this a pattern that you recognise and if so do you have a recommended cron image to work with Crunz in this way?

[PabloKowalczyk]

Hello,

interesting question. I'm not a Docker expert, but when i add Crunz first time i just install Cron in php-fpm docker image and then use supervisord to run php-fpm and crond. It works but scaling this container can lead to issues, because not only php-fpm will be scaled but crond also.

I've looked around online and it seems that the way to handle this it to have another container that runs a schedule or crontab and this container calls the required command in the App container.

If I would add Crunz to project again i would go this way, IMO this is the best way. No problem with scaling containers. Only issue can be duplicated App's src, but is it really a issue?

My question is: Is this a pattern that you recognize and if so do you have a recommended cron image to work with Crunz in this way?

There is no recommended image, Crunz should work with every image. IMO you should use your own image anyway. For example if your app uses ext-amqp in php-fpm and also in Crunz you should definitely go for one "base" image like:

FROM php:7.3-alpine3.9

# Install cron

RUN pecl install amqp && docker-php-ext-enable amqp
RUN composer install -a
# Run other common tasks

And then create other image for Cron/Crunz:

FROM base-image:1.0.2

RUN echo "* * * * * cd /app && /usr/local/bin/php vendor/bin/crunz schedule:run > /proc/1/fd/1 2>/proc/1/fd/2" >> /etc/crontabs/root

# Other Cron/Crunz specific tasks

CMD /usr/sbin/crond -f

Really nice bonus with this approch is that php-fpm and Crunz shares whole environment, php runtime especially which is very good.
IMO it is much clearer and easier to maintain, but, as i said, i'm not a Docker expert, maybe there are better ways to archive this, i'm open for suggestions.

[g10-fred]

Thanks for the response and suggestions, I've had to change focus for a while but I'll post my solution here when I get it up and running.

[g10-fred]

OK, so I found this project -> https://hub.docker.com/r/funkyfuture/deck-chores/ which when run will detect running Docker Containers and check their metadata for any deck-chore configuration and if found will run it. I like this solution because all the config is still contained within my project.

I added the following to my apps Dockerfile:

LABEL deck-chores.crunz.command="/var/www/website/vendor/bin/crunz schedule:run" \
      deck-chores.crunz.interval="every minute" \
      deck-chores.crunz.user="www-data"

Built my image, ran it and the deck-chores image. Deck-chores is now successfully running the crunz command in my application container.

[PabloKowalczyk]

Nice, interesting approach.

[macropin]

This project piqued my interest because we're looking at PHP job schedulers for a customer. This is my Friday afternoon opinion (as a Docker "expert"). Take it as you will...

Running cron, supervisord, and php-fpm in one image is an anti-pattern. Docker containers should do one thing, and do it well. Ideally the container runtime/scheduler/orchestration (eg docker swam, Kubernetes etal) is the process manager, so there should not be a need for supervisord (exceptions do exist, especially with legacy service daemons where this is not possible)...

"deck-chores" whilst, a novel solution, is a hack, and has a significant limitation which makes it unsuitable for all but trivial use cases.

Back to crunz: in its current form is not really a contender as a job scheduler for containerised environments. To bring it up to scratch as a container-native app/infrastructure solution it would need to

• run as a persistent daemon process, without cron
• support job locking to allow scale out of worker processes
• probably a few other things, but I haven't really looked too closely

cheers

[g10-fred]

Thanks for your response @macropin, after allot of research and testing I'd pretty much come to conclusion that I couldn't use cron, deck-chores or crunz (I'm no where near a Docker expert).

I haven't found a good solution for PHP job schedulers in a containerised environment. Do you mind me asking if you've had any luck or found anything worth looking at?

Cheers

[PabloKowalczyk]

@DropdeadFredd after some time and some installations I think the best way to add Cron/Crunz is to create another container with Cron. Sample Dockerfile:

FROM php:7.4-cli-alpine

RUN apk add --no-cache su-exec
RUN echo "* * * * * cd /app && su-exec www-data php vendor/bin/crunz schedule:run > /proc/1/fd/1 2>/proc/1/fd/2" > /tmp/crontab && \
    crontab /tmp/crontab && \
    rm /tmp/crontab

CMD ["/usr/sbin/crond", "-f", "-d", "0"]