Эффективность, которую даёт использование облачных сервисов — один из главных трендов для преобразования многих IT-компаний на сегодняшний день. Автоматизация всех процессов по пути от кода на GIT до развёртывания на Development и/или Production, а также последующий мониторинг, реакция на инциденты и т.д. (что также может и должно быть автоматизировано) — всё это, если не отменяет, то существенно меняет многие общепризнанные ITIL-практики. Взгляд на DevOps-процессы с точки зрения Amazon AWS: как они могут быть реализованы на его сервисах в рамках концепции IaaC (Infrastructure as a Code) — всё это будут даны далее в цикле статей, посвящённых Code-сервисам Amazon AWS: CodeCommit, CodeBuild, CodeDeploy, CodePipeline, CodeStar.
Эта статья первая, обзорная.
Цель данной статьи есть не ликбез по DevOps и не банальное дублирование и так имеющихся у первоисточника материалов. Целью есть представление реализации DevOps на сервисах Amazon AWS в её общем виде, из которой каждый волен выбрать нужный вариант. Целевыми читателями являются знакомые как минимум о существовании Amazon AWS, планирующие задействовать его возможности в своей работе, перенести туда свои процессы частично или полностью. Предоставляемые сервисы Amazon AWS плодятся с большой скоростью, их число уже превысило круглую отметку в 100 штук, потому даже имеющим хороший опыт с AWS может быть полезным узнать — что же появилось нового, такого, которое, может быть, они просто пропустили, а это можно успешно задействовать в их работе.
Не (только) кубики
Немного общих, но для кого-то важных слов, особенно для тех, кто не имеет достаточного опыта работы с Amazon AWS. Изображённые на логотипе кубики логически правильно передают основную идею: Amazon AWS — это конструктор, который даёт набор сервисов и из которого каждый может собрать себе нужное. Однако как раз этот момент «кубико-центричности» может некоторых отталкивать в случае, если нужный кубик (сервис) не удовлетворяет его запросы. В таком случае нужно помнить, что одну и ту же задачу можно решить с помощью разных сервисов, многие сервисы могут во многом дублируют друг друга, а потому не подошедший к вашим запросам сервис Amazon AWS никак не отменяет его использование, а всего лишь даёт повод найти подходящий. Ведь сервисы Amazon AWS появились как результат эксплуатации в первую очередь для собственных нужд. В Amazon AWS работают тысячи небольших команд (они их называют two pizza team), каждая из которых вольна выбирать свой собственный способ работы (язык, ОС, структура, протоколы и т.п.), а значит и сервисы, имеющиеся на Amazon AWS изначально должны поддерживать всё многообразие такого зоопарка их эксплуатирующих уже просто внутри самой компании Amazon AWS.
Особенно это важно для Code-сервисов Amazon AWS, которые как раз предназначены не для того, чтобы указывать вам, что нужно использовать, а для того, чтобы дать вам, с одной стороны, возможность интегрироваться с уже привычными, имеющимися и отлаженными вашими процессами и инструментами, с другой, предложить свою собственную реализацию, которая обычно наиболее эффективна в рамках задействования функционала Amazon AWS.
DevOps конструктор Amazon AWS
Даже хорошо понимая каждый кубик в отдельности, далеко не всегда понятно, какой дом из них можно построить. Потому попробуем собрать эти сервисы в одной картинке, чтобы получить общее представление, что можно собрать из такого конструктора. Если выделить Code-сервисы и соотнести их с привычными процессами, то получится примерно такая конструкция:
Кратко пройдёмся по каждому из Code-сервисов (подробно далее каждому из них будет посвящена отдельная статья):
AWS CodeCommit
Наиболее очевидный и понятный сервис — амазоновская реализация GIT, полностью его повторяющая. Отличий от GIT в плане работы и взаимодействия (команды) нет, нужен по сути для непосредственной интеграции в структуру сервисов AWS, в том числе для организации доступа через сервисы IAM. Сам код хранится на S3.
AWS CodeBuild
Сборочный сервер — для проектов, требующих сборки перед развёртыванием, например, Java. По умолчанию запускает контейнер на базе Ubuntu, но можно указать и свой собственный.
Поддерживает интеграцию с Jenkins через плагин.
Кроме сборки, аналогично могут быть проведены тесты. И хотя это не основное его назначение, он может быть выбран в качестве такового.
Потому AWS CodeBuild также присутствует и на этапе «Test».
AWS CodeDeploy
Сервис для развёртывания кода, который с помощью предустановленного агента и гибких настроек работает в любом окружении. Особенным отличием является то, что агент работает не только с Amazon AWS виртуалками, но и «внешними», что позволяет централизованно разворачивать самое разношерстное ПО, в т.ч. и локально.
AWS CodePipeline
Как было видно из главной диаграммы, взаимодействует с предыдущими тремя сервисами, запуская их в нужной последовательности и, собственно, обеспечивая автоматизацию DevOps-процессов.
Позволяет организовывать ветвления процессов, запускать сторонние сервисы (например, для тестирования), делать параллельные ветки, запрашивать подтверждение (Approval Actions) перед запуском следующего этапа. В общем — это центральный инструмент для организации DevOps на Amazon AWS.
AWS CodeStar
Сервис, по сути дублирующий CodePipeline, но заточенный под простоту запуска и настройки, что решается с помощью широкого набора готовых шаблонов (под связку приложение-язык) и действительно удобного Dashboard с плагинами, имеющими некоторую интеграцию с сервисом мониторинга (CloudWatch) и плагином для интеграции с Jira.
IaaC-сервисы Amazon AWS
Сервисы Amazon AWS, реализующие концепцию «Инфраструктура как код», это:
- Elastic Beanstalk
- OpsWorks
- CloudFormation
Весьма часто возникают вопросы по поводу того, какой из них выбрать и почему три сервиса предназначены для одного и того же (развёртывание инфраструктуры и приложений), располагаясь в главной диаграмме на стадии Deploy. Если кратко, то их использование можно представить как:
То есть для того, чтобы сделать что-то быстро (и это не значит, что плохо), это какой-то стандартный функционал (например, простой сайт) — удобно использовать Elastic Beanstalk. Если это сложный проект с многочисленными вложенными элементами и серьёзными требованиям по сетевым настройкам — без использования CloudFormation не обойтись. Как нечто среднее — представляется использование OpsWorks, базирующегося на Chef.
Однако в реальности (и как раз на сложных проектах обычно используется) комбинация из всех трёх (либо комбинации): CloudFormation поднимает основную инфраструктуру (VPC, подсети, репозитории, создаёт нужные роли в IAM для доступа и т.д.), после запускает OpsWorks-стек, который уже может гибко настроить внутреннюю составляющую запущенных виртуалок. А для удобности процесса разработки CloudFormation может поднять и стек для Elastic Beanstalk компонентов, чтобы разработчики с помощью .ebextensions могли сами менять некоторые параметры работающего приложения (количество и тип используемых виртуалок, использование Load Balancer и т.д.) просто изменяя простой файл конфигурации в папке с кодом, когда применение изменений (в т.ч. в инфраструктуру приложения) происходит автоматически после коммита.
AWS Lambda
Отдельно стоит сказать про сервис Lambda, реализующего концепцию ServerLess-архитектуры, который, с одной стороны, аналогично Elastic Beanstalk, можно вписать в DevOps-процесс с помощью использования AWS Code-сервисов. А с другой стороны AWS Lambda — отличное (читай — обязательное) средство автоматизации всего и вся на Amazon AWS. Все процессы, подразумевающие взаимодействие друг с другом — могут быть связаны с помощью Lambda. Она может обработать и отреагировать на результаты мониторинга CloudWatch, например, перезагрузив сервис (виртуалку, кластер) и послав на почту админу сообщение о проблемах. Она же используется в связи DevOps-процессов, например, для запуска своих способов сборки и тестов с последующей передачей на Deploy в общем порядке. И вообще, с помощью AWS Lambda может быть реализована самая сложная логика, которая пока недоступна с помощью текущего набора сервисов Amazon AWS.
Кроме перечисленных сервисов, в DevOps-процессах могут быть задействованы и другие сервисы. Потому, если попытаться представить общую схему используемых сервисов, то картина может получиться весьма запутанная (ниже просто лишь условный пример).
Не всё может быть передано визуально, т.к. такие глобальные сущности как сервис управления доступом AWS IAM проникает и присутствует практически во всех составляющих. На базе вычислительных мощностей сервиса EC2 работают все другие сервисы. Сервис хранения данных S3 используется для передачи данных между очень многими другими сервисами. А такие высокоуровневые сервисы как AWS Service Catalog могут давать взаимодействие и, в том числе, между разными аккаунтами Amazon AWS.
Далее, по мере более подробного рассмотрения отдельных сервисов, запутанная и непонятная схема будет вырисовываться в понятный набор инструментов, где каждый сможет подобрать себе нужное.
Итого по общей схеме сервисов Amazon AWS, которые могут быть задействованы в DevOps-процессах. Самая популярная связка это что-то типа: CodePipeline/CodeCommit + ElasticBenstalk/OpsWorks в качестве Deploy. А чтобы «быстро просто глянуть» — хорошо подойдёт CodeStar. Правда AWS CodeStar платный, однако фактор стоимости целенаправленно здесь не учитывался, чтобы сначала дать общее представление о выборе, ведь каждую составляющую можно брать по желанию, в том числе задействуя нужное через плагины популярных CI/CD проектов типа Jenkins сотоварищи.
Ссылки:
- Accelerating DevOps Pipelines with AWS: Video, Presentation
Автор: apple_rom
