Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Здравствуйте! Я Игорь Гальцев, с 2010 технический руководитель различных направления разработок Softline в области автоматизации управления и продаж облачных (подписочных) сервисов.
Сегодня хочу рассказать об инструменте, который переводит процедуры согласования и выдачи виртуальных машин на полное самообслуживание, сохраняя логику квот и добавляя возможность прогнозирования утилизации ресурсов.
Как некогда бывший инфраструктурный инженер, знаю, во что превращается использование нескольких частных или публичных облаков в большой команде. Обычно тут два пути. Либо процесс выделения ресурсов слишком бюрократизируется — команды начинают ждать виртуальные машины неделю и сохранять их «живыми» максимально долго, лишь бы не повторять этот путь. Либо наступает настоящий хаос, когда никто не знает, какая команда и сколько ресурсов потребляет и на что уходят сотни и тысячи долларов ежемесячно на том же AWS. Один из возможных вариантов упрощения этой ситуации — перевод разработчиков на самообслуживание в облаке с помощью продукта наших партнеров — CloudMaster.
Когда в компании работают сотни разработчиков и DevOps, у каждой команды — собственный проект и потребности в экспериментах, на ответственность каждого отдельного человека за выделенные компанией мощности уже положиться нельзя. Чтобы понимать масштабы проблемы, вот статистика одного из клиентов CloudMaster, который использует публичные облака и собственная виртуализация на OpenStack.
Разрабатывая параллельно несколько сотен проектов, суммарно ресурсов AWS, Azure и GCP клиент потребляет ежемесячно на полмиллиона долларов. А за год создает и удаляет порядка 350 тыс. виртуальных машин.
Если в таких масштабах пустить процесс на самотек, наступит настоящая анархия. Сотни виртуальных машин будут «подвисать» неиспользуемыми. Не понимая, кто и зачем запустил конкретную ВМ, разобраться, нужна ли она в работе и потребуется ли в будущем, будет крайне сложно. Это тянет за собой лишние расходы на аренду облачных ресурсов, причем провести какой-то анализ происходящего или спрогнозировать загрузку в этих условиях в принципе невозможно.
Логичный способ этого избежать — прописать бизнес-процесс согласования ресурсов. Конечно, это усложняет путь разработчика к получению виртуальной машины: надо заполнить заявку, отправить ее ответственному. Но, если правильно собирать отчетность, перед глазами менеджера будет полная картина: кто, когда и какие мощности запросил. С определенной задержкой он даже сможет анализировать потребности команд в виртуальных мощностях. Но и это не панацея. При достаточном объеме запросов команды со своими проектами «подвисают» в ожидании, пока ответственный посмотрит и оценит очередную заявку. И чем крупнее компания, тем длительнее это ожидание.
При этом все созданные виртуальные машины не имеют «срока годности», т.е. потом кому-то необходимо будет контролировать, что все выделенные ресурсы в заявленное время свернули и это не отразилось на проектах.
Навести порядок в нескольких используемых облаках, частных или публичных, помогают решения класса Cloud Management Platform. Я хочу рассказать о российской альтернативе от наших партнеров — платформе CloudMaster, ориентированной на подключение к Azure, AWS и Google Cloud, а также приватным регионам под vCloud Director, vSphere и OpenStack.
С точки зрения разработчика, CloudMaster — это портал самообслуживания, где через единый интерфейс и без бюрократии (через UI в браузере, мобильном приложении и консольных командах (Python-скрипты)) можно получать ресурсы в корпоративном облаке или ЦОД. А для инфраструктуры это дополнительный уровень абстракции между облачными платформами и конечными пользователями, на котором сохраняется избирательный общий доступ к ресурсам, политики безопасности, стандартные конфигурации и прочие необходимые инструменты вроде образов машин и Terraform-шаблонов.
Основная часть CloudMaster сделана на Java и базируется на основе фреймворков Spring на «сервер-сайде» и Dagger в Android-приложении.
Архитектурно CloudMaster заточен на работу с большими командами и значительными объемами отправляемых сообщений: для обработки очередей использован RabbitMQ, для хранения данных — MonogoDB, для балансировки — Nginx.
Разрабатывался инструмент с 2012 года, а с 2014-го применяется у крупного разработчика софта.
С точки зрения разработчика, CloudMaster — единое окно для быстрого запуска виртуальных машин во всех доступных облаках и регионах. Инструмент позволяет не ждать согласований, а получить ресурс здесь и сейчас.
Для доступа к этому «единому окну» достаточно регистрации на портале. А при наличии интеграции CloudMaster с корпоративным AD роли сотрудников в компании и в проекте будут загружены в этот инструмент, автоматически определяя доступные проекты и ресурсы.
Окно запуска виртуальной машины
При наличии соответствующих прав одной командой можно запустить до 10 виртуальных машин типовых «форм». В терминах CloudMaster — это стандартные конфигурации, которые сопоставляются с типовыми предложениями ресурсов каждого из облаков (и настраиваются под задачу).
Типовые «шаблоны» для разных облаков
Можно создавать образы из существующих машин, пользоваться готовыми шаблонами «инфраструктура как код» или загружать свои (Terraform и CloudFormation).
Шаблоны
При этом ВМ могут создаваться бессрочно или работать по заданному расписанию. Это дает определенную свободу в использовании ресурсов. К примеру, компания может разрешить разработчикам использовать корпоративное облако для личных экспериментов и сравнений, но только на один день. Так, кстати, поступил клиент этой платформы, занимающийся заказной разработкой. Все созданные таким образом виртуальные машины удаляются сами в установленный срок.
С точки зрения менеджеров самое полезное в CloudMaster — то, что учитывается каждая запущенная виртуальная машина. Для них предусмотрены разделы с полной информацией о ВМ в выбранном облаке/регионе, в том числе созданных по конкретным шаблонам, с биллингом от облачных провайдеров, метриками по потреблению ресурсов отдельными проектами, где можно выявить неиспользуемые или малоиспользуемые мощности.
Список ресурсов
Список виртуальных машин
Помимо отображения информации в интерфейсе, CloudMaster генерирует порядка 60 типов уведомлений, в том числе касающиеся финансов.
Пришедшие уведомления
И текст одного из уведомлений
Логика сервиса такова, что у каждой ВМ есть владелец — человек, создавший эту виртуальную машину, или тот, кому эти функции были переданы. Владелец получает все уведомления об утилизации ресурсов или изменениях состояния ВМ, а также несет ответственность за затраты. В этом смысле CloudMaster помогает привить культуру контроля используемых мощностей и ответственности за оставленные машины-«зомби».
Ограничения на создание новых ВМ регулируются правами доступа и квотами. И тут возможна настройка любых рабочих процессов, вплоть до допуска в облако представителей клиента. Можно прописать квоты для команд и предусмотреть различные действия при их достижении или приближении к некому пороговому значению (допустим, 70% от квоты).
Биллинг от облачных провайдеров
Окно управления квотами
Для частных облаков (OpenStack и VMware) CloudMaster поддерживает своего рода биржу — оценку стоимости запуска виртуальных машин, с помощью которых можно выбирать более выгодную схему утилизации ресурсов. Коллеги говорят, что в будущем такая функция может появиться и для публичных облаков.
В этой системе мне ближе всего роль инфраструктурного инженера, поэтому ее оставил напоследок. Для DevOps это, конечно, новый инструмент, но зато появляется возможность контролировать, что происходит с облачными ресурсами, используя только его. Можно быстрее и проще разворачивать популярные инструменты конфигурирования, мониторинга и разработки вроде Chef и Ansible.
При необходимости для администраторов и разработчиков есть Java SDK.
Самое главное, что CloudMaster, как и другие CMP, позволяет перейти от ручного рутинного выделения ресурсов к более интересным задачам: проработке автоматизаций на базе «инфраструктура как код» и т.п.
По моему опыту, появление подобных инструментов оправдано, если в компании задействовано как минимум полсотни виртуальных машин и есть не менее полутора десятков активных пользователей разных облаков. С одной стороны, это некоторое усложнение инфраструктуры, но с другой — приведение разнородных облаков, каждое из которых имеет собственные инструменты управления, к общему знаменателю с гарантией, что при этом не нарушаются внутренние корпоративные стандарты. При этом инструмент «спускает» ответственность за утилизацию ресурсов и планирование бюджета на уровень проектных менеджеров, что идеологически правильнее.
Сегодня хочу рассказать об инструменте, который переводит процедуры согласования и выдачи виртуальных машин на полное самообслуживание, сохраняя логику квот и добавляя возможность прогнозирования утилизации ресурсов.
Как некогда бывший инфраструктурный инженер, знаю, во что превращается использование нескольких частных или публичных облаков в большой команде. Обычно тут два пути. Либо процесс выделения ресурсов слишком бюрократизируется — команды начинают ждать виртуальные машины неделю и сохранять их «живыми» максимально долго, лишь бы не повторять этот путь. Либо наступает настоящий хаос, когда никто не знает, какая команда и сколько ресурсов потребляет и на что уходят сотни и тысячи долларов ежемесячно на том же AWS. Один из возможных вариантов упрощения этой ситуации — перевод разработчиков на самообслуживание в облаке с помощью продукта наших партнеров — CloudMaster.
В чем проблема
Когда в компании работают сотни разработчиков и DevOps, у каждой команды — собственный проект и потребности в экспериментах, на ответственность каждого отдельного человека за выделенные компанией мощности уже положиться нельзя. Чтобы понимать масштабы проблемы, вот статистика одного из клиентов CloudMaster, который использует публичные облака и собственная виртуализация на OpenStack.
Разрабатывая параллельно несколько сотен проектов, суммарно ресурсов AWS, Azure и GCP клиент потребляет ежемесячно на полмиллиона долларов. А за год создает и удаляет порядка 350 тыс. виртуальных машин.
Если в таких масштабах пустить процесс на самотек, наступит настоящая анархия. Сотни виртуальных машин будут «подвисать» неиспользуемыми. Не понимая, кто и зачем запустил конкретную ВМ, разобраться, нужна ли она в работе и потребуется ли в будущем, будет крайне сложно. Это тянет за собой лишние расходы на аренду облачных ресурсов, причем провести какой-то анализ происходящего или спрогнозировать загрузку в этих условиях в принципе невозможно.
Логичный способ этого избежать — прописать бизнес-процесс согласования ресурсов. Конечно, это усложняет путь разработчика к получению виртуальной машины: надо заполнить заявку, отправить ее ответственному. Но, если правильно собирать отчетность, перед глазами менеджера будет полная картина: кто, когда и какие мощности запросил. С определенной задержкой он даже сможет анализировать потребности команд в виртуальных мощностях. Но и это не панацея. При достаточном объеме запросов команды со своими проектами «подвисают» в ожидании, пока ответственный посмотрит и оценит очередную заявку. И чем крупнее компания, тем длительнее это ожидание.
При этом все созданные виртуальные машины не имеют «срока годности», т.е. потом кому-то необходимо будет контролировать, что все выделенные ресурсы в заявленное время свернули и это не отразилось на проектах.
Самообслуживание через платформы управления облаками (CMP)
Навести порядок в нескольких используемых облаках, частных или публичных, помогают решения класса Cloud Management Platform. Я хочу рассказать о российской альтернативе от наших партнеров — платформе CloudMaster, ориентированной на подключение к Azure, AWS и Google Cloud, а также приватным регионам под vCloud Director, vSphere и OpenStack.
С точки зрения разработчика, CloudMaster — это портал самообслуживания, где через единый интерфейс и без бюрократии (через UI в браузере, мобильном приложении и консольных командах (Python-скрипты)) можно получать ресурсы в корпоративном облаке или ЦОД. А для инфраструктуры это дополнительный уровень абстракции между облачными платформами и конечными пользователями, на котором сохраняется избирательный общий доступ к ресурсам, политики безопасности, стандартные конфигурации и прочие необходимые инструменты вроде образов машин и Terraform-шаблонов.
Основная часть CloudMaster сделана на Java и базируется на основе фреймворков Spring на «сервер-сайде» и Dagger в Android-приложении.
Архитектурно CloudMaster заточен на работу с большими командами и значительными объемами отправляемых сообщений: для обработки очередей использован RabbitMQ, для хранения данных — MonogoDB, для балансировки — Nginx.
Разрабатывался инструмент с 2012 года, а с 2014-го применяется у крупного разработчика софта.
Логика CloudMaster
С точки зрения разработчика, CloudMaster — единое окно для быстрого запуска виртуальных машин во всех доступных облаках и регионах. Инструмент позволяет не ждать согласований, а получить ресурс здесь и сейчас.
Для доступа к этому «единому окну» достаточно регистрации на портале. А при наличии интеграции CloudMaster с корпоративным AD роли сотрудников в компании и в проекте будут загружены в этот инструмент, автоматически определяя доступные проекты и ресурсы.
Окно запуска виртуальной машины
При наличии соответствующих прав одной командой можно запустить до 10 виртуальных машин типовых «форм». В терминах CloudMaster — это стандартные конфигурации, которые сопоставляются с типовыми предложениями ресурсов каждого из облаков (и настраиваются под задачу).
Типовые «шаблоны» для разных облаков
Можно создавать образы из существующих машин, пользоваться готовыми шаблонами «инфраструктура как код» или загружать свои (Terraform и CloudFormation).
Шаблоны
При этом ВМ могут создаваться бессрочно или работать по заданному расписанию. Это дает определенную свободу в использовании ресурсов. К примеру, компания может разрешить разработчикам использовать корпоративное облако для личных экспериментов и сравнений, но только на один день. Так, кстати, поступил клиент этой платформы, занимающийся заказной разработкой. Все созданные таким образом виртуальные машины удаляются сами в установленный срок.
С точки зрения менеджеров самое полезное в CloudMaster — то, что учитывается каждая запущенная виртуальная машина. Для них предусмотрены разделы с полной информацией о ВМ в выбранном облаке/регионе, в том числе созданных по конкретным шаблонам, с биллингом от облачных провайдеров, метриками по потреблению ресурсов отдельными проектами, где можно выявить неиспользуемые или малоиспользуемые мощности.
Список ресурсов
Список виртуальных машин
Помимо отображения информации в интерфейсе, CloudMaster генерирует порядка 60 типов уведомлений, в том числе касающиеся финансов.
Пришедшие уведомления
И текст одного из уведомлений
Логика сервиса такова, что у каждой ВМ есть владелец — человек, создавший эту виртуальную машину, или тот, кому эти функции были переданы. Владелец получает все уведомления об утилизации ресурсов или изменениях состояния ВМ, а также несет ответственность за затраты. В этом смысле CloudMaster помогает привить культуру контроля используемых мощностей и ответственности за оставленные машины-«зомби».
Ограничения на создание новых ВМ регулируются правами доступа и квотами. И тут возможна настройка любых рабочих процессов, вплоть до допуска в облако представителей клиента. Можно прописать квоты для команд и предусмотреть различные действия при их достижении или приближении к некому пороговому значению (допустим, 70% от квоты).
Биллинг от облачных провайдеров
Окно управления квотами
Для частных облаков (OpenStack и VMware) CloudMaster поддерживает своего рода биржу — оценку стоимости запуска виртуальных машин, с помощью которых можно выбирать более выгодную схему утилизации ресурсов. Коллеги говорят, что в будущем такая функция может появиться и для публичных облаков.
В этой системе мне ближе всего роль инфраструктурного инженера, поэтому ее оставил напоследок. Для DevOps это, конечно, новый инструмент, но зато появляется возможность контролировать, что происходит с облачными ресурсами, используя только его. Можно быстрее и проще разворачивать популярные инструменты конфигурирования, мониторинга и разработки вроде Chef и Ansible.
При необходимости для администраторов и разработчиков есть Java SDK.
Самое главное, что CloudMaster, как и другие CMP, позволяет перейти от ручного рутинного выделения ресурсов к более интересным задачам: проработке автоматизаций на базе «инфраструктура как код» и т.п.
По моему опыту, появление подобных инструментов оправдано, если в компании задействовано как минимум полсотни виртуальных машин и есть не менее полутора десятков активных пользователей разных облаков. С одной стороны, это некоторое усложнение инфраструктуры, но с другой — приведение разнородных облаков, каждое из которых имеет собственные инструменты управления, к общему знаменателю с гарантией, что при этом не нарушаются внутренние корпоративные стандарты. При этом инструмент «спускает» ответственность за утилизацию ресурсов и планирование бюджета на уровень проектных менеджеров, что идеологически правильнее.
![[По докам] Flutter. Часть 3. Для разработчиков React Native](/upload/resize_cache/iblock/cfb/105_70_0/cfb0fb5af05ed163a44f31c8d1d4fde3.jpeg "[По докам] Flutter. Часть 3. Для разработчиков React Native")
