Terraform с AWS и стратегией развертывания исправлений - PullRequest
Новая
       32

Terraform с AWS и стратегией развертывания исправлений

0 голосов
/ 03 мая 2018

В двух словах, у нас есть платформа, которая включает в себя несколько приложений / серверов. Terraform используется для управления как развертыванием инфраструктуры AWS (VPC, Subnet, IGW, Security Groups, ...), так и приложений (используя Ansible в качестве поставщика от Terraform). Для каждого развертывания Packer будет собирать все AMI, пометьте их соответствующим именем, чтобы из Terraform были получены последние AMI.

Процесс в целом работает, но мы сталкиваемся с дилеммой, когда мы хотим развернуть небольшие исправления, которые могут происходить довольно часто, так как после каждого развертывания и тестирования из QA могут возникнуть некоторые регрессии. Таким образом, для каждого приложения, которое должно быть исправлено (может быть, не все приложения должны быть исправлены), мы создаем ветку исправлений, создаем артефакт (может быть jar или deb pkg) - тогда есть 2 случая:

  • Либо активируйте Packer для создания нового образа, отметьте его соответствующим исправлением и примените terraform.
  • Или, запустите задание Ansible для горячего развертывания пакета приложения, перезапустите службу / приложение, если это необходимо.

При первом подходе мы обеспечиваем реализацию идеи Immutable Infra, к сожалению, это также вызвало некоторые недостатки, поскольку любые небольшие изменения в конфигурации Terraform или Infra могут привести к изменению плана terraform, например, у нас могут быть некоторые изменения в группе безопасности который находится вне состояния terraform (то есть: это может быть из некоторых функций, касающихся внесения в белый список некоторых IP-адресов), и применение tf отменит все изменения. Весь процесс построения AMI и запуска Terraform также довольно тяжелый.

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

1 Ответ

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

Для изменений кода, я рекомендую использовать упаковщик для создания AMI как части вашего конвейера CI, это может быть довольно сложно управлять изменениями конфигурации запуска с помощью Terraform и ASG, учитывая, насколько это может быть глючно, но я думаю, что результат намного чище и безопаснее, чем обновлять код с помощью Ansible. Технически у вас есть «запись» изменений, учитывая, что вы знаете свои доступные книги и в каком состоянии они находятся, но я думаю, что для создания неизменяемых артефактов его следует использовать из конвейера CI.

Если вы действительно хотели придерживаться только Ansible, вы всегда можете просто вставить в свои пользовательские данные Playsbook Ansible, который всегда получает последний код от Мастера (или чего-то еще). Это гарантирует, что новые хосты получат последний код, и вы можете вручную вызывать Ansible против уже существующих хостов. Или вы можете просто вращать экземпляры ec2, чтобы обновить код, удвоив желаемую емкость и уменьшив его, когда новые исправны. Все это может быть в высокой степени автоматизировано и даст вам псевдо-канарское развертывание. Опять же, хотя я бы рекомендовал придерживаться неизменных сборок.

Из любопытства по какой причине вы не используете докер? Я уверен, что у вас есть веская деловая причина, но переход на докер также многое упрощает, поскольку гораздо проще создать контейнер докера и обновить определение задачи ECS, чем развернуть совершенно новый экземпляр AMI / EC2.

...