Я хотел бы знать, есть ли способ настроить задание / задачу cron для выполнения каждую минуту. В настоящее время любой из моих экземпляров может выполнять эту задачу.

Вот что я безуспешно пытался сделать в файлах конфигурации:

container_commands:
  01cronjobs:
    command: echo "*/1 * * * * root php /etc/httpd/myscript.php"

Я не совсем уверен, что это правильный способ сделать это

Любые идеи?

Вот как я добавил задание cron в Elastic Beanstalk:

Создайте папку в корне вашего приложения с именем .ebextensions, если она еще не существует. Затем создайте файл конфигурации в папке .ebextensions. Я буду использовать example.config в целях иллюстрации. Затем добавьте это в example.config

container_commands:
  01_some_cron_job:
    command: "cat .ebextensions/some_cron_job.txt > /etc/cron.d/some_cron_job && chmod 644 /etc/cron.d/some_cron_job"
    leader_only: true

Это файл конфигурации YAML для Elastic Beanstalk. При копировании в текстовый редактор убедитесь, что в текстовом редакторе используются пробелы вместо табуляции. В противном случае вы получите ошибку YAML, когда нажмете это на EB.

Это создает команду 01_some_cron_job. Команды запускаются в алфавитном порядке, поэтому 01 гарантирует, что он будет запущен как первая команда.

Затем команда берет содержимое файла с именем some_cron_job.txt и добавляет его в файл с именем some_cron_job в /etc/cron.d.

Затем команда изменяет разрешения для файла /etc/cron.d/some_cron_job.

Ключ leader_only гарантирует, что команда будет запущена только на экземпляре ec2, который считается лидером. Вместо того, чтобы запускать каждый экземпляр ec2, который у вас может быть.

Затем создайте файл с именем some_cron_job.txt внутри папки .ebextensions. Вы разместите свои задания cron в этом файле.

Так например:

# The newline at the end of this file is extremely important.  Cron won't run without it.
* * * * * root /usr/bin/php some-php-script-here > /dev/null

Таким образом, это задание cron будет запускаться каждую минуту каждого часа каждого дня от имени пользователя root и сбрасывать вывод в / dev / null. / usr / bin / php - это путь к php. Затем замените some-php-script-here на путь к вашему файлу php. Это, очевидно, предполагает, что ваше задание cron должно запускать файл PHP.

Также убедитесь, что файл some_cron_job.txt имеет новую строку в конце файла, как сказано в комментарии. В противном случае cron не запустится.

Обновление: существует проблема с этим решением, когда Elastic Beanstalk масштабирует ваши экземпляры. Например, допустим, у вас есть один экземпляр с запущенным заданием cron. Вы получаете увеличение трафика, поэтому Elastic Beanstalk масштабирует вас до двух экземпляров. Leader_only гарантирует, что между двумя экземплярами будет выполняться только одно задание cron. Ваш трафик уменьшается, а Elastic Beanstalk сокращает вас до одного экземпляра. Но вместо завершения второго экземпляра Elastic Beanstalk завершает работу первого экземпляра, который был лидером. Теперь у вас нет запущенных заданий cron, поскольку они выполнялись только на первом прерванном экземпляре. См. Комментарии ниже.

Обновление 2: просто поясняю это из комментариев ниже: теперь AWS имеет защиту от автоматического завершения инстанса. Просто включите его на своем экземпляре лидера, и все готово. - Николас Аревало 28 окт.

Это официальный способ сделать это сейчас (2015+). Пожалуйста, сначала попробуйте этот способ, это, безусловно, самый простой из доступных в настоящее время и самый надежный метод.

Согласно текущим документам, можно запускать периодические задачи на так называемом рабочем уровне .

Ссылаясь на документацию:

AWS Elastic Beanstalk поддерживает периодические задачи для уровней рабочей среды в средах с заранее определенной конфигурацией со стеком решений, содержащим «v1.2.0» в имени контейнера. Вы должны создать новую среду.

Также интересна часть о cron.yaml :

Чтобы вызывать периодические задачи, исходный пакет приложения должен включать файл cron.yaml на корневом уровне. Файл должен содержать информацию о периодических задачах, которые вы хотите запланировать. Укажите эту информацию, используя стандартный синтаксис crontab.

Обновление: мы смогли получить эту работу. Вот несколько важных ошибок из нашего опыта (платформа Node.js):

• При использовании файла cron.yaml убедитесь, что у вас установлена ​​последняя версия awsebcli , поскольку более старые версии не будут работать должным образом.
• Также жизненно важно создать новую среду (по крайней мере, в нашем случае это было), а не просто клонировать старую.
• Если вы хотите убедиться, что CRON поддерживается в вашем экземпляре EC2 Worker Tier, введите ssh в него ( eb ssh) и запустите cat /var/log/aws-sqsd/default.log. Он должен сообщать как aws-sqsd 2.0 (2015-02-18). Если у вас нет версии 2.0, при создании среды что-то пошло не так, и вам нужно создать новую, как указано выше.

Что касается ответа jamieb, и, как упоминает alrdinleal, вы можете использовать свойство leader_only, чтобы гарантировать, что только один экземпляр EC2 выполняет задание cron.

Цитата взята из http://docs.amazonwebservices.com/elasticbeanstalk/latest/dg/customize-containers-ec2.html :

вы можете использовать leader_only. Один экземпляр выбирается лидером в группе автоматического масштабирования. Если для параметра leader_only установлено значение true, команда запускается только на экземпляре, помеченном как лидер.

Я пытаюсь добиться того же на моем eb, поэтому обновлю свой пост, если я его решу.

ОБНОВИТЬ:

Хорошо, теперь у меня есть рабочие cronjobs со следующей конфигурацией eb:

files:
  "/tmp/cronjob" :
    mode: "000777"
    owner: ec2-user
    group: ec2-user
    content: |
      # clear expired baskets
      */10 * * * * /usr/bin/wget -o /dev/null http://blah.elasticbeanstalk.com/basket/purge > $HOME/basket_purge.log 2>&1
      # clean up files created by above cronjob
      30 23 * * * rm $HOME/purge*
    encoding: plain 
container_commands:
  purge_basket: 
    command: crontab /tmp/cronjob
    leader_only: true
commands:
  delete_cronjob_file: 
    command: rm /tmp/cronjob

По сути, я создаю временный файл с заданиями cron, а затем устанавливаю crontab для чтения из временного файла, а затем удаляю временный файл. Надеюсь это поможет.

Как упоминалось выше, основной недостаток установки любой конфигурации crontab заключается в том, что это происходит только при развертывании. Поскольку кластер автоматически масштабируется вверх, а затем обратно, предпочтительно, чтобы он также был первым выключенным сервером. Вдобавок не будет переключения при отказе, что для меня было критично.

Я провел небольшое исследование, а затем поговорил с нашим специалистом по аккаунтам AWS, чтобы обсудить идеи и проверить решение, которое я придумал. Вы можете добиться этого с помощью OpsWorks , хотя это немного похоже на использование дома, чтобы убить муху. Также можно использовать Data Pipeline с Task Runner , но это имеет ограниченные возможности в сценариях, которые он может выполнять, и мне нужно было иметь возможность запускать сценарии PHP с доступом ко всей базе кода. Вы также можете выделить экземпляр EC2 вне кластера ElasticBeanstalk, но тогда у вас не будет повторного переключения при отказе.

Итак, вот что я придумал, что, по-видимому, нетрадиционно (как прокомментировал представитель AWS) и может считаться взломом, но он работает и надежен с отказом. Я выбрал решение для кодирования с использованием SDK, которое я покажу на PHP, хотя вы можете использовать тот же метод на любом языке, который вам больше нравится.

// contains the values for variables used (key, secret, env)
require_once('cron_config.inc'); 

// Load the AWS PHP SDK to connection to ElasticBeanstalk
use Aws\ElasticBeanstalk\ElasticBeanstalkClient;

$client = ElasticBeanstalkClient::factory(array(
    'key' => AWS_KEY,
    'secret' => AWS_SECRET,
    'profile' => 'your_profile',
    'region'  => 'us-east-1'
));

$result = $client->describeEnvironmentResources(array(
    'EnvironmentName' => AWS_ENV
));

if (php_uname('n') != $result['EnvironmentResources']['Instances'][0]['Id']) {
    die("Not the primary EC2 instance\n");
}

Итак, рассмотрим это и то, как это работает ... Вы вызываете скрипты из crontab, как обычно, на каждом экземпляре EC2. Каждый скрипт включает это в начале (или включает по одному файлу для каждого, как я его использую), который устанавливает объект ElasticBeanstalk и извлекает список всех экземпляров. Он использует только первый сервер в списке и проверяет, совпадает ли он с самим собой, что, если он это делает, продолжает, в противном случае он умирает и закрывается. Я проверил, и возвращенный список кажется согласованным, что технически должно быть согласованным только в течение минуты или около того, поскольку каждый экземпляр выполняет запланированный cron. Если это действительно изменится, это не имеет значения, поскольку опять же, это актуально только для этого маленького окна.

Это ни в коем случае не изящно, но соответствовало нашим конкретным потребностям, которые заключались не в увеличении стоимости за счет дополнительной услуги или необходимости иметь выделенный экземпляр EC2, а также в случае отказа в случае отказа. Наши сценарии cron запускают сценарии обслуживания, которые помещаются в SQS, и каждый сервер в кластере помогает выполнять. По крайней мере, это может дать вам альтернативный вариант, если он соответствует вашим потребностям.

-Дэйви

Я поговорил с агентом службы поддержки AWS, и вот как мы заставили меня работать. Решение 2015 года:

Создайте файл в каталоге .ebextensions с именем your_file_name.config. В ввод файла конфигурации:

файлы:
  "/etc/cron.d/cron_example":
    режим: «000644»
    владелец: root
    группа: корень
    содержание: |
      * * * * * корень /usr/local/bin/cron_example.sh

  "/usr/local/bin/cron_example.sh":
    режим: «000755»
    владелец: root
    группа: корень
    содержание: |
      #! / bin / bash

      /usr/local/bin/test_cron.sh || Выход
      echo "Cron работает в" `date` >> /tmp/cron_example.log
      # Теперь выполняем задачи, которые должны выполняться только на 1 экземпляре ...

  "/usr/local/bin/test_cron.sh":
    режим: «000755»
    владелец: root
    группа: корень
    содержание: |
      #! / bin / bash

      МЕТАДАННЫЕ = / opt / aws / bin / ec2-metadata
      INSTANCE_ID = `$ METADATA -i | awk '{print $ 2}' `
      REGION = `$ METADATA -z | awk '{print substr ($ 2, 0, длина ($ 2) -1)}' '

      # Найдите название нашей группы автоматического масштабирования.
      ASG = `aws ec2 describe-tags --filters" Name = resource-id, Values ​​= $ INSTANCE_ID "\
        --region $ REGION --выходной текст | awk '/ aws: autoscaling: groupName / {print $ 5}' '

      # Находим первый экземпляр в группе
      FIRST = `aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names $ ASG \
        --region $ REGION --выходной текст | awk '/ InService $ / {print $ 4}' | сортировать | голова -1`

      # Проверьте, одинаковы ли они.
      ["$ FIRST" = "$ INSTANCE_ID"]

команды:
  rm_old_cron:
    команда: "rm * .bak"
    cwd: "/etc/cron.d"
    ignoreErrors: true

У этого решения есть 2 недостатка:

1. При последующих развертываниях Beanstalk переименовывает существующий сценарий cron в .bak, но cron все равно будет его запускать. Ваш Cron теперь выполняется дважды на одной машине.
2. Если ваша среда масштабируется, вы получите несколько экземпляров, все из которых будут запускать ваш cron-скрипт. Это означает, что ваши почтовые снимки повторяются или архивы вашей базы данных дублируются.

Обходной путь:

1. Убедитесь, что любой сценарий .ebextensions, создающий cron, также удаляет файлы .bak при последующих развертываниях.
2. Имейте вспомогательный сценарий, который выполняет следующие действия: - Получает текущий идентификатор экземпляра из метаданных - Получает текущее имя группы автоматического масштабирования из тегов EC2 - Получает список экземпляров EC2 в этой группе, отсортированный в алфавитном порядке. - Берет первый экземпляр из этого списка. - Сравнивает идентификатор экземпляра из шага 1 с первым идентификатором экземпляра из шага 4. Затем ваши скрипты cron могут использовать этот вспомогательный скрипт, чтобы определить, должны ли они выполняться.

Предостережение:

• Роль IAM, используемая для экземпляров Beanstalk, требует разрешения ec2: DescribeTags и автомасштабирования: DescribeAutoScalingGroups.
• Выбранные из них экземпляры показаны как InService при автоматическом масштабировании. Это не обязательно означает, что они полностью загружены и готовы к запуску вашего cron.

Вам не нужно будет устанавливать роли IAM, если вы используете роль beanstalk по умолчанию.

Если вы используете Rails, вы можете использовать гем when-elasticbeanstalk . Он позволяет запускать задания cron на всех экземплярах или только на одном. Он ежеминутно проверяет наличие только одного экземпляра «лидера» и автоматически повышает один сервер до «лидера», если его нет. Это необходимо, поскольку Elastic Beanstalk имеет понятие лидера только во время развертывания и может закрыть любой экземпляр в любое время при масштабировании.

ОБНОВЛЕНИЕ Я перешел на использование AWS OpsWorks и больше не обслуживаю этот драгоценный камень. Если вам нужно больше функциональных возможностей, чем доступно в основах Elastic Beanstalk, я настоятельно рекомендую перейти на OpsWorks.

Вы действительно не хотите запускать задания cron на Elastic Beanstalk. Поскольку у вас будет несколько экземпляров приложения, это может вызвать состояния гонки и другие странные проблемы. Я на самом деле недавно писал об этом в блоге (4-я или 5-я подсказка на странице). Короткая версия: В зависимости от приложения, использовать очереди заданий как SQS или решение третьей стороны , как iron.io .

2017: Если вы используете Laravel5 +

На его настройку потребуется всего 2 минуты:

• создать рабочий уровень

• установить laravel-aws-worker

  composer require dusterio/laravel-aws-worker

• добавьте cron.yaml в корневую папку:

Добавьте cron.yaml в корневую папку вашего приложения (он может быть частью вашего репо или вы можете добавить этот файл прямо перед развертыванием в EB - важно, чтобы этот файл присутствовал во время развертывания):

version: 1
cron:
 - name: "schedule"
   url: "/worker/schedule"
   schedule: "* * * * *"

Это оно!

Вся ваша задача App\Console\Kernelтеперь будет выполнена

Подробные инструкции и объяснения: https://github.com/dusterio/laravel-aws-worker

Как писать задачи внутри Laravel: https://laravel.com/docs/5.4/scheduling

Более читаемое решение, использующее filesвместо container_commands:

файлы:
  "/etc/cron.d/my_cron":
    режим: «000644»
    владелец: root
    группа: корень
    содержание: |
      # переопределить адрес электронной почты по умолчанию
      MAILTO = "example@gmail.com"
      # запускать команду Symfony каждые пять минут (как пользователь ec2)
      * / 10 * * * * ec2-user / usr / bin / php / var / app / current / app / console do: something
    кодировка: обычная
команды:
  # удалить файл резервной копии, созданный Elastic Beanstalk
  clear_cron_backup:
    команда: rm -f /etc/cron.d/watson.bak

Обратите внимание, что формат отличается от обычного формата crontab тем, что в нем указывается, от имени какого пользователя следует запускать команду.

Мой 1 цент взноса за 2018 год

Вот это правильный способ сделать это (используя django/pythonи django_crontabприложение):

внутри .ebextensionsпапки создайте такой файл 98_cron.config:

files:
  "/tmp/98_create_cron.sh":
    mode: "000755"
    owner: root
    group: root
    content: |
      #!/bin/sh
      cd /
      sudo /opt/python/run/venv/bin/python /opt/python/current/app/manage.py crontab remove > /home/ec2-user/remove11.txt
      sudo /opt/python/run/venv/bin/python /opt/python/current/app/manage.py crontab add > /home/ec2-user/add11.txt 

container_commands:
    98crontab:
        command: "mv /tmp/98_create_cron.sh /opt/elasticbeanstalk/hooks/appdeploy/post && chmod 774 /opt/elasticbeanstalk/hooks/appdeploy/post/98_create_cron.sh"
        leader_only: true

Это должно быть container_commandsвместоcommands

Кто-то задумывался о проблемах автоматического масштабирования leader_only при появлении новых лидеров. Кажется, я не могу понять, как ответить на их комментарии, но посмотрите эту ссылку: http://blog.paulopoiati.com/2013/08/25/running-cron-in-elastic-beanstalk-auto-scaling- Окружающая среда/

Последний пример от Amazon - самый простой и эффективный (периодические задачи):

https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features-managing-env-tiers.html

где вы создаете отдельный рабочий уровень для выполнения любых ваших заданий cron. Создайте файл cron.yaml и поместите его в корневую папку. Одна из моих проблем (после того, как казалось, что cron не запускается) заключалась в том, что у моего CodePipeline не было полномочий для выполнения модификации Dynamodb. Исходя из этого, после добавления доступа к FullDynamoDB в разделе IAM -> роли -> yourpipeline и повторного развертывания (эластичный beanstalk) он работал отлично.

Вот полное объяснение решения:

http://blog.paulopoiati.com/2013/08/25/running-cron-in-elastic-beanstalk-auto-scaling-environment/

Итак, мы долго боролись с этим, и после некоторого обсуждения с представителем AWS я, наконец, пришел к тому, что я считаю лучшим решением.

Использование рабочего уровня с cron.yaml - определенно самое простое решение. Однако документация не разъясняет, что это поместит задание в конец очереди SQS, которую вы используете для фактического выполнения своих заданий. Если ваши задания cron чувствительны ко времени (как и многие из них), это неприемлемо, так как это будет зависеть от размера очереди. Один из вариантов - использовать полностью отдельную среду только для запуска заданий cron, но я думаю, что это излишне.

Некоторые из других вариантов, например проверка, являетесь ли вы первым в списке, также не идеальны. Что, если текущий первый экземпляр находится в процессе отключения?

Защита экземпляра также может иметь проблемы - что, если этот экземпляр заблокируется / заморожен?

Важно понимать, как сама AWS управляет функциональностью cron.yaml. Существует демон SQS, который использует таблицу Dynamo для обработки «выбора лидера». Он часто записывает в эту таблицу, и если текущий лидер не записал в течение короткого времени, следующий экземпляр станет лидером. Таким образом демон решает, какой экземпляр запустить задание в очередь SQS.

Мы можем перепрофилировать существующую функциональность, а не пытаться переписать нашу собственную. Вы можете увидеть полное решение здесь: https://gist.github.com/dorner/4517fe2b8c79ccb3971084ec28267f27

Это в Ruby, но вы можете легко адаптировать его к любому другому языку, на котором есть AWS SDK. По сути, он проверяет текущего лидера, а затем проверяет состояние, чтобы убедиться, что оно в хорошем состоянии. Он будет зацикливаться до тех пор, пока текущий лидер не будет в хорошем состоянии, и если текущий экземпляр является лидером, выполнить задание.

Чтобы контролировать, может ли автоматическое масштабирование завершать работу определенного экземпляра при масштабировании, используйте защиту экземпляра. Вы можете включить параметр защиты экземпляра для группы Auto Scaling или для отдельного экземпляра Auto Scaling. Когда Auto Scaling запускает экземпляр, он наследует настройку защиты экземпляра из группы Auto Scaling. Вы можете изменить настройку защиты экземпляра для группы Auto Scaling или Auto Scaling в любое время.

http://docs.aws.amazon.com/autoscaling/latest/userguide/as-instance-termination.html#instance-protection

У меня было другое решение для этого, если файл php необходимо запустить через cron, и если вы установили какие-либо экземпляры NAT, вы можете поместить cronjob в экземпляр NAT и запустить файл php через wget.

вот исправление, если вы хотите сделать это в PHP. Вам просто нужен cronjob.config в папке .ebextensions, чтобы он работал так.

files:
  "/etc/cron.d/my_cron":
    mode: "000644"
    owner: root
    group: root
    content: |
        empty stuff
    encoding: plain
commands:
  01_clear_cron_backup:
    command: "rm -f /etc/cron.d/*.bak"
  02_remove_content:
    command: "sudo sed -i 's/empty stuff//g' /etc/cron.d/my_cron"
container_commands:
  adding_cron:
    command: "echo '* * * * * ec2-user . /opt/elasticbeanstalk/support/envvars && /usr/bin/php /var/app/current/index.php cron sendemail > /tmp/sendemail.log 2>&1' > /etc/cron.d/my_cron"
    leader_only: true

envvars получает переменные среды для файлов. Вы можете отлаживать вывод в tmp / sendemail.log, как указано выше.

Надеюсь, это кому-то поможет, ведь это, безусловно, помогло нам!

На основе принципов ответа от пользователя 1599237 , где вы позволяете заданиям cron запускаться во всех экземплярах, но вместо этого в начале заданий определяете, следует ли им разрешить запуск, я сделал другое решение.

Вместо того, чтобы смотреть на запущенные экземпляры (и хранить ваш ключ и секрет AWS), я использую базу данных MySQL, к которой я уже подключаюсь со всех экземпляров.

Минусов нет, только положительные:

• без лишних трат или расходов
• твердый раствор породы - нет шансов на двойное исполнение
• масштабируемость - работает автоматически при масштабировании ваших экземпляров вверх и вниз
• аварийное переключение - автоматически работает в случае отказа экземпляра

В качестве альтернативы вы также можете использовать общую файловую систему (например, AWS EFS по протоколу NFS) вместо базы данных.

Следующее решение создано в PHP-фреймворке Yii, но вы можете легко адаптировать его для другого фреймворка и языка. Также обработчик исключенийYii::$app->system - это мой собственный модуль. Замените его тем, что вы используете.

/**
 * Obtain an exclusive lock to ensure only one instance or worker executes a job
 *
 * Examples:
 *
 * `php /var/app/current/yii process/lock 60 empty-trash php /var/app/current/yii maintenance/empty-trash`
 * `php /var/app/current/yii process/lock 60 empty-trash php /var/app/current/yii maintenance/empty-trash StdOUT./test.log`
 * `php /var/app/current/yii process/lock 60 "empty trash" php /var/app/current/yii maintenance/empty-trash StdOUT./test.log StdERR.ditto`
 * `php /var/app/current/yii process/lock 60 "empty trash" php /var/app/current/yii maintenance/empty-trash StdOUT./output.log StdERR./error.log`
 *
 * Arguments are understood as follows:
 * - First: Duration of the lock in minutes
 * - Second: Job name (surround with quotes if it contains spaces)
 * - The rest: Command to execute. Instead of writing `>` and `2>` for redirecting output you need to write `StdOUT` and `StdERR` respectively. To redirect stderr to stdout write `StdERR.ditto`.
 *
 * Command will be executed in the background. If determined that it should not be executed the script will terminate silently.
 */
public function actionLock() {
    $argsAll = $args = func_get_args();
    if (!is_numeric($args[0])) {
        \Yii::$app->system->error('Duration for obtaining process lock is not numeric.', ['Args' => $argsAll]);
    }
    if (!$args[1]) {
        \Yii::$app->system->error('Job name for obtaining process lock is missing.', ['Args' => $argsAll]);
    }

    $durationMins = $args[0];
    $jobName = $args[1];
    $instanceID = null;
    unset($args[0], $args[1]);

    $command = trim(implode(' ', $args));
    if (!$command) {
        \Yii::$app->system->error('Command to execute after obtaining process lock is missing.', ['Args' => $argsAll]);
    }

    // If using AWS Elastic Beanstalk retrieve the instance ID
    if (file_exists('/etc/elasticbeanstalk/.aws-eb-system-initialized')) {
        if ($awsEb = file_get_contents('/etc/elasticbeanstalk/.aws-eb-system-initialized')) {
            $awsEb = json_decode($awsEb);
            if (is_object($awsEb) && $awsEb->instance_id) {
                $instanceID = $awsEb->instance_id;
            }
        }
    }

    // Obtain lock
    $updateColumns = false;  //do nothing if record already exists
    $affectedRows = \Yii::$app->db->createCommand()->upsert('system_job_locks', [
        'job_name' => $jobName,
        'locked' => gmdate('Y-m-d H:i:s'),
        'duration' => $durationMins,
        'source' => $instanceID,
    ], $updateColumns)->execute();
    // The SQL generated: INSERT INTO system_job_locks (job_name, locked, duration, source) VALUES ('some-name', '2019-04-22 17:24:39', 60, 'i-HmkDAZ9S5G5G') ON DUPLICATE KEY UPDATE job_name = job_name

    if ($affectedRows == 0) {
        // record already exists, check if lock has expired
        $affectedRows = \Yii::$app->db->createCommand()->update('system_job_locks', [
                'locked' => gmdate('Y-m-d H:i:s'),
                'duration' => $durationMins,
                'source' => $instanceID,
            ],
            'job_name = :jobName AND DATE_ADD(locked, INTERVAL duration MINUTE) < NOW()', ['jobName' => $jobName]
        )->execute();
        // The SQL generated: UPDATE system_job_locks SET locked = '2019-04-22 17:24:39', duration = 60, source = 'i-HmkDAZ9S5G5G' WHERE job_name = 'clean-trash' AND DATE_ADD(locked, INTERVAL duration MINUTE) < NOW()

        if ($affectedRows == 0) {
            // We could not obtain a lock (since another process already has it) so do not execute the command
            exit;
        }
    }

    // Handle redirection of stdout and stderr
    $command = str_replace('StdOUT', '>', $command);
    $command = str_replace('StdERR.ditto', '2>&1', $command);
    $command = str_replace('StdERR', '2>', $command);

    // Execute the command as a background process so we can exit the current process
    $command .= ' &';

    $output = []; $exitcode = null;
    exec($command, $output, $exitcode);
    exit($exitcode);
}

Вот схема базы данных, которую я использую:

CREATE TABLE `system_job_locks` (
    `job_name` VARCHAR(50) NOT NULL,
    `locked` DATETIME NOT NULL COMMENT 'UTC',
    `duration` SMALLINT(5) UNSIGNED NOT NULL COMMENT 'Minutes',
    `source` VARCHAR(255) NULL DEFAULT NULL,
    PRIMARY KEY (`job_name`)
)