Как обновить файл конфигурации Nginx на многих идентичных серверах одновременно?

У нас есть парк серверов Nginx на Amazon EC2, где нам иногда приходится обновлять файлы конфигурации для реализации новых настроек.

В настоящее время у нас есть конфигурации в пользовательском AMI, и если нам нужно обновить, мы должны перестроить экземпляры AMI и EC2. У нас есть несколько вспомогательных сценариев, но мы все еще пытаемся это сделать. Есть какой-то лучший способ?

Есть ряд концепций, которые вы можете использовать.

Ключ к успеху - автоматизация

Первый вариант - продолжать делать то, что вы делаете сейчас, т.е. перестраивать EC2 при каждом изменении конфигурации . Просто полностью автоматизированным способом.

Сейчас, когда вы выполняете обновления конфигурации через AMI, вы делаете еще один шаг и создаете конвейер, который после изменения файла конфигурации в каком-либо хранилище будет:

1. Автоматически создавать новый AMI - один из самых популярных инструментов для этого - Packer
2. Автоматически перестраивайте свой парк Nginx - у вас уже должны быть все серверы Nginx в группе автоматического масштабирования с балансировщиком нагрузки приложений впереди. Если вы этого не сделаете, то это сделает обновление таким же простым, как обновление конфигурации запуска ASG и ожидание восстановления экземпляров из нового AMI.

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

• AWS Elastic Beanstalk, который использует Chef для внутреннего использования, и вы можете таким образом записывать свои обновления Nginx.
• AWS Code Deploy, который является полностью развертываемым инструментом развертывания, который хорошо интегрируется с другими частями AWS Code Suite :
  • Code Commit, где вы можете хранить свои файлы конфигурации Nginx в Git.
  • Code Pipeline который может автоматически запускать развертывание всякий раз, когда файл конфигурации обновляется в Code Commit.
• Ansible или Puppet - популярные инструменты не-AWS, которые могут помочь вам настроить все серверы одинаково.

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

Есть отличная статья AWS обзор вариантов развертывания , который даст вам хороший обзор.

Надеюсь, это поможет :)

Сохраните свои конфигурации в EFS и смонтируйте EFS в том месте, где ожидаются конфигурации Nginx. Поочередно поместите их в Amazon S3 и время от времени запускайте синхронизацию, либо используйте s3fs (будьте осторожны, s3fs может оказаться недостаточно для производственного использования).

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

Другой вариант - просто отправить новые конфигурации на сервер с помощью базового средства автоматизации, такого как развертывание кода AWS.

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

Команда запуска AWS https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html

Или вы можете использовать Opsworks https://aws.amazon.com/opsworks/

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