Загрузка CRON Laravel Flysystem & Rackspace завершается неудачно с 401, в то время как загрузка по требованию работает
Наша система генерирует различные счета каждый час и загружает их в облако. Также можно создать счет по требованию, нажав кнопку на нашем веб-интерфейсе.
При ручном запросе на создание указанного счета-фактуры его никогда не удается загрузить. Что касается сгенерированных cron счетов-фактур, то через некоторое время все загрузки завершатся неудачно:
Client error response
[status code] 401
[reason phrase] Unauthorized
[url] https://storage101.dfw1.clouddrive.com/v1/MossoCloudFS_930575/ <...> .pdf" @ Guzzle\Http\Exception\BadResponseException->factory
Что должно означать, что токен истек, что, вероятно, и есть. Токены Rackspace сохраняются в течение 24 часов, но хранилище Laravel должно автоматически обновить токен.
Теперь несколько интересных фактов:
1) Каждый раз, когда наш код развертывается с Capistrano, токен, кажется, обновляется, и загрузка cron снова работает в течение некоторого времени. Здесь важно отметить, что при каждом развертывании создается новая папка, похожая на эту /releases/201605190925 извлекает код, устанавливает зависимости с нуля, и, если все пойдет хорошо, создайте символическую ссылку на эту папку с тем, что показывает Apache.
2) Задания Laravel обрабатываются не так, как www-data.
3) Трудно отследить, если после развертывания загрузка работает более 24 часов или нет. Я подозреваю, что иногда это работает больше, чем это. Но это трудно отследить, так как не каждый час есть счета, которые необходимо сгенерировать. Есть больше разработчиков, которые развертывают, чем я
4) Когда происходит сбой cron и я получаю уведомление о сбое, я могу сразу же перейти и успешно сгенерировать счет. После этого cron по-прежнему не работает. Таким образом, кажется, что эти два экземпляра хранят где-то разные токены.
5) Очистка кеша с php artisan cache:clear кажется, не имеет никакого влияния
6) Возможно, попытался перезапустить службу Apache, но безрезультатно
Так как это продолжалось в течение некоторого времени, я протестировал разные вещи и даже связался с Rackspace в один момент, но они не смогли найти ничего странного с их конца... Напомнил мне просто поймать ошибку 401, обновить токен и попробовать снова. Но Laravel и Flysystem должны справиться с этим где-то сами
Поскольку больше ни у кого, похоже, нет подобных проблем ни с Flysystem, ни с Laravel, ни с Rackspace, я подозреваю, что это какая-то уникальная проблема с процессом cron. Я просто надеялся, что скоро у нас будет готовая версия нашей системы с рефакторингом, и проблема просто исчезнет. На данный момент он все еще находится в разработке и может занять еще один месяц.
Не думаю, что это связано с кодом, но в любом случае вот строка загрузки:
Storage::put($folder . '/' . $filename, file_get_contents($filePath));
Вот наш конфиг:
'default' => 'rackspace',
'disks' => [
'rackspace' => [
'driver' => 'rackspace',
'username' => ' ... ',
'key' => ' ... ',
'container' => ' ... ',
'endpoint' => 'https://identity.api.rackspacecloud.com/v2.0/',
'region' => 'DFW',
]
]
Любые мысли по этому вопросу приветствуются.
2 ответа
Здесь я снова пытался найти решение проблемы почти через 2,5 месяца. И я думаю, что на этот раз действительно щелкнуло, когда я перечитал обновление @Tommmm.
Итак, вы перезапустили рабочую очередь, и я начал думать о том, как я управлял моим руководителем / работниками.
php artisan queue:work database --daemon --sleep=10 tries=3
--Demon (как это было действительно хорошо объяснено в этом посте Stackru @ the-shift-exchange)
В Laravel >=4.2 был --daemon Команда добавлена. Как это работает, просто продолжает работать с очередями напрямую, а не перезагружать всю инфраструктуру после обработки каждой очереди. Это необязательная команда, которая значительно снижает требования к памяти и процессорам вашей очереди.
Важный момент с --daemon Команда заключается в том, что при обновлении приложения вам необходимо специально перезапустить свою очередь с помощью queue: restart, иначе вы можете потенциально получить всевозможные странные ошибки, поскольку в вашей очереди все еще будет старый код в памяти.
Поскольку приложение никогда не загружается снова, я чувствую, что токен также никогда не обновляется. Что касается остальной части приложения, все еще обновляет токен и использует новый. Это объясняет, почему все действия, выполняемые по нажатию кнопки, работали, и только фоновые задачи не выполнялись. Что касается того, почему развертывание временно исправило нашу проблему, было то, что у нас было queue:restart там после каждого развертывания.
Я совершенно уверен, что это так, и теперь есть две возможности для начала. Либо вы перезапускаете своих рабочих через некоторое время (<24 часа для Rackspace), либо вы не запускаете рабочих вместе с --daemon,
Редактировать:
Подтвердил, что добавление follow в Kernel.php перезапускает рабочих демонов через каждые 6 часов.
$schedule->command('queue:restart')->cron('0 */6 * * *')
У меня была похожая проблема. Документация и частота ошибок кажутся довольно низкими для этой проблемы. Читая здесь ( https://github.com/rackspace/php-opencloud/issues/427), похоже, что токен с истекшим сроком действия является основной причиной.
Рекомендация по приведенной выше ссылке заключается в повторной аутентификации клиента через
$client->authenticate();
Но клиент похоронен под горсткой команд. Вы должны иметь возможность получить доступ к базовому клиенту через
Storage::disk('my-disk')->getDriver()->getAdapter()->getContainer()->getClient()->authenticate();
К сожалению, я получаю ошибку 35 curl при попытке этого (SSL_CONNECT_ERROR).
E сть
hasExpired()
метод также доступен. Если вы столкнетесь с той же ошибкой, вы сможете объединить эту проверку с каким-то механизмом для перезапуска задания или рабочего cron. Хотя это, безусловно, далеко от идеального решения, оно должно заставить вас работать. Вы могли бы подумать, что это поведение будет поймано и обработано автоматически.
5/25 Обновление: потратив еще пару часов, пытаясь найти решение, я бросил полотенце и просто создал задание cron, чтобы перезапускать соответствующих работников каждые 12 часов. Предположительно токен действителен в течение 24 часов (согласно HTTP 401 Fog:: Storage:: Rackspace:: ServiceError), поэтому 12-часовое окно должно безопасно предотвращать возникновение ошибки. Несмотря на то, что он супер хакерский, он поддерживает работу сайта.