hello
I use DockerCompose but could not set DockerCompose to keep cron active after restart.
my Dockerfile
FROM php:7.3-fpm
RUN apt-get update && \
apt-get install -y \
zlib1g-dev libzip-dev
RUN docker-php-ext-install mysqli pdo pdo_mysql
RUN rm /etc/apt/preferences.d/no-debian-php
RUN apt-get update && apt-get install -y libxml2-dev \
&& pear install -a SOAP-0.13.0 \
&& docker-php-ext-install soap;
RUN docker-php-ext-install zip
RUN docker-php-ext-install exif
RUN apt-get update && apt-get install -y \
cron wget nano \
libfreetype6-dev \
libjpeg62-turbo-dev \
libpng-dev \
&& docker-php-ext-configure gd --with-jpeg-dir --with-freetype-dir \
&& docker-php-ext-install -j$(nproc) gd
RUN rm -rf /var/lib/apt/lists/*
RUN php -r "readfile('https://getcomposer.org/installer');" | php -- --install-dir=/usr/bin/ --filename=composer
COPY crontab/crontab /etc/cron.d/crontab
RUN chmod 0644 /etc/cron.d/crontab
RUN crontab /etc/cron.d/crontab
RUN touch /var/log/cron.log
RUN chown -R www-data:www-data /var/www
CMD cron
EXPOSE 9000
my docker-compose.yml
version: '3'
services:
php:
container_name: ${APP_NAME}_php
build:
context: ./docker/php
dockerfile: Dockerfile
volumes:
- ./:/var/www/app
- ./docker/php/crontab:/etc/cron.d/
networks:
- proxy
networks:
proxy:
driver: bridge
Where is my mistake?
Do you have a sample?
Use supervisord. ;)
I usually run crond in a separate sidecar container for this use case.
However, I'd suggest posting this to a dedicated support forum, such as the Docker Community Forums, the Docker Community Slack, or Stack Overflow.
Agreed. It's not an issue.
Supervisord and crond did not solve my problem
Personally I agree that it would be better to follow the micro-service architecture that Docker aspires to and run Cron in its own container, ideally you have one daemon per container. Attempting to run both the Cron daemon and PHP FPM daemon in the same container wouldn't really be following that principle. Splitting them up also means that in a scenario where if either the Cron or FPM process failed and so causing the container to shutdown, one failing wouldn't interrupt the other, but having them in the same container if one of those fails it takes them both down with it. (Hopefully that makes sense.)
Going to close since this seems answered pretty thoroughly