Эффективность, обеспечиваемая использованием облачных сервисов, сегодня является одним из основных трендов трансформации многих ИТ-компаний.
Автоматизация всех процессов на пути от кода на GIT до деплоя на Разработка и/или Производство , а также последующий мониторинг, реагирование на инциденты и т.п.
(что тоже можно и нужно автоматизировать) - все это если не отменяет, то существенно меняет многие общепринятые Практики ITIL .
Посмотри на Процессы DevOps с точки зрения Amazon AWS : как их можно реализовать на своих сервисах в рамках концепции IaaC ( Инфраструктура как код ) - все это будет дано далее в серии статей, посвященных Код -Сервисы Amazon AWS: КодКоммит , Сборка кода , КодДеплой , КодПайплайн , КодСтар .
Это первая статья, обзор.
Цель данной статьи — не ликбез по DevOps и не банальное дублирование существующих первоисточник материалы.
Цель — представить реализацию DevOps на сервисах Amazon AWS в общем виде, из которого каждый волен выбрать нужный вариант. Целевыми читателями являются те, кто как минимум знаком с существованием Amazon AWS и планирует использовать его возможности в своей работе и частично или полностью перенести туда свои процессы.
Предоставляемые сервисы Amazon AWS множатся с большой скоростью, их количество уже превысило отметку в 100 раундов, поэтому даже тем, кто имеет хороший опыт работы с AWS, возможно, будет полезно узнать, что нового, то, что они, возможно, просто пропустили, и это можно успешно привлечь к своей работе.
Не (просто) кубики
Несколько общих, но важных для некоторых слов, особенно для тех, кто не имеет достаточного опыта работы с Amazon AWS. Кубики, изображенные в логотипе, логически правильно передают основную идею: Amazon AWS — это конструктор, предоставляющий набор сервисов и из которого каждый может собрать то, что ему нужно.
Однако именно этот момент «кубоцентричности» может оттолкнуть некоторых людей, если желаемый куб (услуга) не удовлетворяет их потребностям.
При этом нужно помнить, что одну и ту же задачу можно решить с помощью разных сервисов, многие сервисы могут во многом дублировать друг друга, и поэтому сервис Amazon AWS, не подходящий вашим запросам, никоим образом не отменяет его использования, а лишь дает повод найти подходящее.
Ведь сервисы Amazon AWS появились в результате эксплуатации прежде всего для собственных нужд. В Amazon AWS работают тысячи небольших команд (их называют две команды пиццы ), каждый из которых волен выбирать свой способ работы (язык, ОС, структуру, протоколы и т. д.), а это значит, что сервисы, доступные на Amazon AWS, изначально должны поддерживать всё разнообразие такого зоопарка эксплуатирующих их.
просто внутри самого Amazon AWS. Это особенно важно для Код - Сервисы Amazon AWS, которые призваны не указывать вам, что использовать, а давать вам, с одной стороны, возможность интегрироваться с уже знакомыми, существующими и устоявшимися процессами и инструментами, с другой — предлагать собственную реализацию.
, что обычно является наиболее эффективным с точки зрения использования функций Amazon AWS.
DevOps-дизайнер Amazon AWS
Даже при хорошем понимании каждого кубика в отдельности не всегда понятно, какой дом из них можно построить.Поэтому попробуем собрать эти сервисы в одной картинке, чтобы получить общее представление о том, что можно собрать из такого конструктора.
Если вы выберете Код -services и соотнесите их со знакомыми процессами, вы получите примерно следующее: 
Давайте кратко пройдемся по каждому из них.
Код -услуги (каждая из них будет подробно рассмотрена в отдельной статье):
AWS CodeCommit
На что это похоже
Самый очевидный и понятный сервис — реализация GIT от Amazon, которая полностью его копирует. Отличий от GIT по работе и взаимодействию (команде) нет, по сути он нужен для прямой интеграции в структуру сервисов AWS, в том числе для организации доступа через сервисы.
Я.
.
Сам код хранится на S3 .
Сборка кода AWS
На что это похоже
Сервер сборки — для проектов, требующих сборки перед развертыванием, например Java. По умолчанию он запускает контейнер на базе Ubuntu, но вы можете указать свой собственный.
Укажите образ Docker 
Поддерживает интеграцию с Jenkins через плагин .
Помимо сборки, аналогичным образом можно проводить испытания.
И хотя это не основное его предназначение, его можно выбрать и таковым.
AWS CodeBuild в качестве поставщика тестов 
Потому что АВС Сборка кода также присутствует на этапе «Тест».
AWS CodeDeploy
Сервис для развертывания кода, который с помощью предустановленного агента и гибких настроек работает в любой среде.Особым отличием является то, что агент работает не только с виртуальными машинами Amazon AWS, но и с «внешними», что позволяет централизованно развертывать самое разнообразное программное обеспечение, в т.ч.
и локально.
Кодовый конвейер AWS
На что это похоже
Как видно из основной схемы, он взаимодействует с тремя предыдущими сервисами, запуская их в необходимой последовательности и, по сути, обеспечивая автоматизацию процессов DevOps. Позволяет организовывать ветки процессов, запускать сторонние сервисы (например, для тестирования), делать параллельные ветки, запрашивать подтверждение ( Действия по утверждению ) перед началом следующего этапа.
В целом это центральный инструмент для организации DevOps на Amazon AWS.
AWS CodeStar
На что это похоже
Сервис, по сути дублирующий КодПайплайн , но рассчитан на простоту запуска и настройки, что решается с помощью широкого набора готовых шаблонов (для совмещения приложения-языка) и действительно удобного Дашборда с плагинами, имеющими некоторую интеграцию с сервисом мониторинга ( CloudWatch ) и плагин для интеграции с Jira. Шаблоны AWS CodeStar
Сервисы Amazon AWS IaaC
Сервисы Amazon AWS, реализующие концепцию «Инфраструктура как код»:- Эластичный бобовый стебель
- ОпсВоркс
- ОблакоФормирование
Вкратце их использование можно представить так: 
То есть, чтобы сделать что-то быстро (и это не значит плохо), это какой-то стандартный функционал (например, простой сайт) - им удобно пользоваться.
Эластичный бобовый стебель .
Если это сложный проект с многочисленными вложенными элементами и серьезными требованиями к настройкам сети — не используйте ОблакоФормирование недостаточно.
Как что-то среднее - вроде бы используется ОпсВоркс на основе Шеф-повар .
Однако в действительности (а в сложных проектах обычно используется) комбинация всех трёх: ОблакоФормирование поднимает базовую инфраструктуру ( ВКК , подсети, репозитории, создает необходимые роли в Я.
для доступа и т. д.), затем запускает ОпсВоркс -стек, который уже умеет гибко настраивать внутренние компоненты запущенных виртуальных машин.
И для удобства процесса разработки ОблакоФормирование можно поднять и сложить для Эластичный бобовый стебель компоненты, чтобы разработчики могли использовать .
ebextensions могли сами менять некоторые параметры работающего приложения (количество и тип используемых виртуальных машин, использование Балансировщик нагрузки и т.д.), просто изменив простой файл конфигурации в папке с кодом, когда изменения применяются (в том числе и к инфраструктуре приложения) автоматически после коммита.
AWS Лямбда
Отдельно стоит сказать о сервисе.
Лямбда , реализуя концепцию Без сервера -архитектура, которая с одной стороны похожа Эластичный бобовый стебель , можно интегрировать в процесс DevOps с помощью AWS. Код -услуги.
С другой стороны, AWS Лямбда — отличный (читай: обязательный) инструмент для автоматизации всего и вся на Amazon AWS. Все процессы, предполагающие взаимодействие друг с другом, можно соединить с помощью Лямбда .
Он может обрабатывать и реагировать на результаты мониторинга.
CloudWatch , например, перезагрузив сервис (виртуальную машину, кластер) и отправив письмо администратору о проблемах.
Также используется в связи с DevOps-процессами, например, для запуска собственных методов сборки и тестов с последующим переносом в Развертывать в общем порядок.
И вообще, используя AWS Лямбда С помощью текущего набора сервисов Amazon AWS можно реализовать самую сложную логику, которая пока недоступна.
Помимо перечисленных сервисов, в процессах DevOps могут участвовать и другие сервисы.
Поэтому если попытаться представить общую схему используемых сервисов, то картина может оказаться весьма запутанной (ниже лишь условный пример).
Не все можно передать визуально, потому что.
глобальные сущности, такие как сервис контроля доступа AWS. Я.
проникает и присутствует практически во всех компонентах.
В зависимости от вычислительной мощности сервиса ЕС2 все остальные службы работают. Служба хранения данных S3 используется для передачи данных между многими другими службами.
И такие сервисы высокого уровня, как AWS Каталог услуг может обеспечить взаимодействие, в том числе между разными учетными записями Amazon AWS. Далее, когда мы рассмотрим отдельные сервисы более детально, запутанная и непонятная схема вырастет в четкий набор инструментов, где каждый сможет выбрать то, что ему нужно.
Итого для общей схемы сервисов Amazon AWS, которые можно задействовать в процессах DevOps. Самая популярная комбинация выглядит примерно так: КодПайплайн / КодКоммит + Эластичный Бенсталк / ОпсВоркс как Развертывать .
А для "просто беглого взгляда" - хорошо КодСтар .
Это правда AWS CodeStar платный, однако фактор стоимости здесь намеренно не учтен, чтобы сначала дать общее представление о выборе, ведь каждый компонент можно брать по своему желанию, в том числе используя то, что нужно, через популярные плагины CI/CD проекты вроде товарищей Дженкинса.
Ссылки:
- Ускорение конвейеров DevOps с помощью AWS: Видео , Презентация
-
Бонд, Уильям Кренч
19 Oct, 24 -
Apple «Участвовала» Во Взломе Iphone?
19 Oct, 24 -
Хватит Изобретать Велосипед
19 Oct, 24 -
Поддельный Айфон
19 Oct, 24
