Как обеспечить, чтобы CodeDeploy содержал все экземпляры группы автоматического масштабирования в процессе обслуживания при очистке кэша? - PullRequest
Новая
       34

Как обеспечить, чтобы CodeDeploy содержал все экземпляры группы автоматического масштабирования в процессе обслуживания при очистке кэша?

0 голосов
/ 18 сентября 2018

Я работаю над процессом развертывания, включающим следующее:

  • Бегун Gitlab помещает приложение Magento 1.9 в корзину S3
  • Бегун Gitlab развертывает приложение с помощью CodeDeploy
  • CodeDeploy развертывает приложение на всех экземплярах, которые находятся в группе автоматического масштабирования

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

Наше приложение должно очищать кэш только тогда, когда все активные экземпляры находятся в обслуживании, чтобы избежать получения новых http-запросов (в противном случае оно может выдать «Фронт-контроллер достиг 100 итераций сопоставления маршрутизатора»).исключение).

Мы думали об использовании файлов блокировки в общей папке во всех экземплярах, но это звучит очень старомодно.

Любая идея о том, как обеспечить обслуживание всех экземпляров для очисткикэш будет очень признателен!

1 Ответ

0 голосов
/ 28 декабря 2018

Я мало что знаю о Magento, но, похоже, есть несколько вещей, которые должны произойти:

1.Переведите экземпляры в режим обслуживания

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

2.Дождитесь, когда все экземпляры перейдут в режим обслуживания, и очистите кэш

Если вы переведите хосты в режим обслуживания в ApplicationStop, вы можете использовать другой ловушку жизненного цикла для ожидания всехэкземпляры для перехода в режим обслуживания.Например, у вас может быть сценарий в BeforeInstall, который проверяет, все ли экземпляры прошли ApplicationStop, и запускает очистку, если они это сделали (т. Е. Последний).

Вот некоторый псевдокод: 

# BeforeInstall or something other hook script

# 1. Get the instance details from CodeDeploy
instances = listDeploymentInstances().map(instanceId -> getDeploymentInstance(instanceId))

# 2. Check if all of the instances have completed ApplicationStop
for instance in instances {
  applicationStopStatus = instance.instanceSummary.lifecycleEvents
    .findFirst(event -> event.lifecycleEventName == "ApplicationStop")
    .status

  # If it's succeeded, we're good to go
  if status == "Succeeded
    purgeCache()
  # If it's failed, you'll have to decide what should be done
  else if status == "Failed"
    # Abort the deployment or handle some other way
  # If it's not completed, ignore it and let another instance kick off the purge
  else
    return
}

3.Дождитесь завершения продувки и выйдите из режима обслуживания

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

Если бы вы хотели сделать это через CodeDeploy, я бы сделал что-то подобное вышеописанному.Конечно, вы можете управлять этим вне развертывания и иметь некоторый код, работающий на ваших экземплярах, который управляет всем этим.

...