laradockは定時タスクをworkspaceコンテナで実行しているため、ログを確認しますdocker-compose logs -f workspace
Jul 2 12:26:59 9b6ec4d18dd1 syslog-ng[12]: syslog-ng starting up; version='3.13.2'
workspace_1 | *** Booting runit daemon...
workspace_1 | *** Runit started as PID 20
workspace_1 | Jul 2 12:27:00 9b6ec4d18dd1 cron[23]: (CRON) INFO (pidfile fd = 3)
workspace_1 | Jul 2 12:27:00 9b6ec4d18dd1 cron[23]: (CRON) INFO (Skipping @reboot jobs -- not system startup)
workspace_1 | Jul 2 12:28:01 9b6ec4d18dd1 CRON[26]: (laradock) CMD (/usr/bin/php /var/www/artisan schedule:run >> /dev/null 2>&1)
workspace_1 | Jul 2 12:29:01 9b6ec4d18dd1 CRON[60]: (laradock) CMD (/usr/bin/php /var/www/artisan schedule:run >> /dev/null 2>&1)
workspace_1 | Jul 2 12:30:01 9b6ec4d18dd1 CRON[84]: (laradock) CMD (/usr/bin/php /var/www/artisan schedule:run >> /dev/null 2>&1)
workspace_1 | Jul 2 12:31:01 9b6ec4d18dd1 CRON[102]: (laradock) CMD (/usr/bin/php /var/www/artisan schedule:run >> /dev/null 2>&1)
workspace_1 | Jul 2 12:32:01 9b6ec4d18dd1 CRON[120]: (laradock) CMD (/usr/bin/php /var/www/artisan schedule:run >> /dev/null 2>&1)
workspace_1 | Jul 2 12:33:01 9b6ec4d18dd1 CRON[157]: (laradock) CMD (/usr/bin/php /var/www/artisan schedule:run >> /dev/null 2>&1)
workspace_1 | Jul 2 12:34:01 9b6ec4d18dd1 CRON[178]: (laradock) CMD (/usr/bin/php /var/www/artisan schedule:run >> /dev/null 2>&1)
workspace_1 | Jul 2 12:35:01 9b6ec4d18dd1 CRON[198]: (laradock) CMD (/usr/bin/php /var/www/artisan schedule:run >> /dev/null 2>&1)
workspace_1 | Jul 2 12:36:01 9b6ec4d18dd1 CRON[218]: (laradock) CMD (/usr/bin/php /var/www/artisan schedule:run >> /dev/null 2>&1)
- ログを確認した結果、タスクは正常に実行され、コンテナに入ります
docker-compose exec workspace bash
- タスクを実行しますが、出力を抑制しないでください
/usr/bin/php /var/www/artisan schedule:run
# タイミングがちょうど合えば、スケジュールされたタスクが実行されます
# xxxx => xxx
- タスクが正常に実行され、ログの書き込みも正常です。
- コンテナから退出し、ログ
/storage/logsを確認すると、問題が見つかります。 - コンテナに直接入ると、デフォルトで
rootの身分になり、タスクの実行時にログのパーミッションが変更され、ディレクトリの作成も問題を引き起こします。 - ただし、
workspaceコンテナではlaradockユーザーが実行しているため、正常に実行できません
**** * * laradock /usr/bin/php /var/www/artisan schedule:run >> /dev/null 2>&1
- まず、すべてのディレクトリのパーミッションを正常に設定します
chmod -R 0777 storage
- 身分を使用してコンテナに入ります
docker-compose exec --user=laradock workspace bash
2021-07-02 11:19:56 金曜日 更新#
- 定時タスクが実行されないことがわかりました。上記のファイルのパーミッションの問題を除外し、
laradockユーザーでコンテナに入ると、コマンドが正常に実行されます。 workspaceコンテナのログ出力を確認します。docker-compose logs -f --tail 100 workspace- 出力から問題の原因が見つかりました（定時タスクの後に
^Mが追加されている）
workspace_1 | Jul 2 03:19:01 fac0b255876a CRON[344]: (CRON) info (No MTA installed, discarding output)
workspace_1 | Jul 2 03:20:01 fac0b255876a CRON[350]: (laradock) CMD (/usr/bin/php /var/www/artisan schedule:run >> /de
v/null 2>&1^M)
workspace_1 | Jul 2 03:20:01 fac0b255876a CRON[348]: (CRON) info (No MTA installed, discarding output)
workspace_1 | Jul 2 03:21:01 fac0b255876a CRON[354]: (laradock) CMD (/usr/bin/php /var/www/artisan schedule:run >> /de
v/null 2>&1^M)
- データを調べた結果、これは
WindowsとLinuxの改行の違いによるもので、Linuxが正常に認識できなくなり、定時タスクがトリガーされなくなる可能性があります。 - 余分な文字を削除し、コンテナを再構築すると、タスクが正常に動作します
複数のマシンでのworkspaceデプロイメント、定時タスクの重複を防ぐために#
laradock/workspace/crontab/laradockファイルからlaravelのスケジュールタスクを削除します- コンテナを再構築し、古いコンテナを停止して新しいコンテナを起動します。直接再起動しないでください
docker-compose build workspacedocker-compose stop workspace && docker-compose up -d workspacephp-workerコンテナを使用して定時タスクを管理しますlaravel-scheduler.conf.exampleファイルをコピーしてlaravel-scheduler.confという名前に変更します- 次に、
php-workerコンテナを再起動するだけで新しいタスクがロードされます docker-compose restart php-worker- コンテナ内部に入ってタスクの状態を確認します
docker-compose exec php-worker sh
/etc/supervisor/conf.d # supervisorctl status
laravel-scheduler:laravel-scheduler_00 RUNNING pid 9, uptime 2:14:33
- 上記の出力は、定時タスクが正常に実行されていることを示しています