[Облачные вычисления, Серверное администрирование, Управление разработкой, Облачные сервисы] CloudMaster — это про самообслуживание разработчиков в корпоративном ЦОДе и облачных сервисах
Автор
Сообщение
news_bot ®
Стаж: 6 лет 4 месяца
Сообщений: 27286
Здравствуйте! Я Игорь Гальцев, с 2010 технический руководитель различных направления разработок Softline в области автоматизации управления и продаж облачных (подписочных) сервисов.
Сегодня хочу рассказать об инструменте, который переводит процедуры согласования и выдачи виртуальных машин на полное самообслуживание, сохраняя логику квот и добавляя возможность прогнозирования утилизации ресурсов.
![Клик для увеличения](https://linkme.ufanet.ru/box/200x100/adc2a2c547259f8f295f6b627b573be7.jpg)
Как некогда бывший инфраструктурный инженер, знаю, во что превращается использование нескольких частных или публичных облаков в большой команде. Обычно тут два пути. Либо процесс выделения ресурсов слишком бюрократизируется — команды начинают ждать виртуальные машины неделю и сохранять их «живыми» максимально долго, лишь бы не повторять этот путь. Либо наступает настоящий хаос, когда никто не знает, какая команда и сколько ресурсов потребляет и на что уходят сотни и тысячи долларов ежемесячно на том же 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.
![Клик для увеличения](https://linkme.ufanet.ru/box/200x100/125bd490bd3391493d83621d45c3b885.png)
Разрабатывался инструмент с 2012 года, а с 2014-го применяется у крупного разработчика софта.
Логика CloudMaster
С точки зрения разработчика, CloudMaster — единое окно для быстрого запуска виртуальных машин во всех доступных облаках и регионах. Инструмент позволяет не ждать согласований, а получить ресурс здесь и сейчас.
Для доступа к этому «единому окну» достаточно регистрации на портале. А при наличии интеграции CloudMaster с корпоративным AD роли сотрудников в компании и в проекте будут загружены в этот инструмент, автоматически определяя доступные проекты и ресурсы.
![Клик для увеличения](https://linkme.ufanet.ru/box/200x100/80ed2c1a04a53c1b22e8a53d05d8ca16.png)
Окно запуска виртуальной машины
При наличии соответствующих прав одной командой можно запустить до 10 виртуальных машин типовых «форм». В терминах CloudMaster — это стандартные конфигурации, которые сопоставляются с типовыми предложениями ресурсов каждого из облаков (и настраиваются под задачу).
![Клик для увеличения](https://linkme.ufanet.ru/box/200x100/79aa254d48cfa7886615e790ae11a92a.png)
Типовые «шаблоны» для разных облаков
Можно создавать образы из существующих машин, пользоваться готовыми шаблонами «инфраструктура как код» или загружать свои (Terraform и CloudFormation).
![Клик для увеличения](https://linkme.ufanet.ru/box/200x100/8b23b146786c96072adbc6fb809f23aa.png)
Шаблоны
При этом ВМ могут создаваться бессрочно или работать по заданному расписанию. Это дает определенную свободу в использовании ресурсов. К примеру, компания может разрешить разработчикам использовать корпоративное облако для личных экспериментов и сравнений, но только на один день. Так, кстати, поступил клиент этой платформы, занимающийся заказной разработкой. Все созданные таким образом виртуальные машины удаляются сами в установленный срок.
С точки зрения менеджеров самое полезное в CloudMaster — то, что учитывается каждая запущенная виртуальная машина. Для них предусмотрены разделы с полной информацией о ВМ в выбранном облаке/регионе, в том числе созданных по конкретным шаблонам, с биллингом от облачных провайдеров, метриками по потреблению ресурсов отдельными проектами, где можно выявить неиспользуемые или малоиспользуемые мощности.
![Клик для увеличения](https://linkme.ufanet.ru/box/200x100/dca2fd199f1356e0b45585097a587589.png)
Список ресурсов
![Клик для увеличения](https://linkme.ufanet.ru/box/200x100/43d682c5332de38d78371da11ed9e139.png)
Список виртуальных машин
Помимо отображения информации в интерфейсе, CloudMaster генерирует порядка 60 типов уведомлений, в том числе касающиеся финансов.
![Клик для увеличения](https://linkme.ufanet.ru/box/200x100/1656170ae640285982ba7e493be99ab1.png)
Пришедшие уведомления
![Клик для увеличения](https://linkme.ufanet.ru/box/200x100/31455b08cbffa05459b3a4617d2f4e54.png)
И текст одного из уведомлений
Логика сервиса такова, что у каждой ВМ есть владелец — человек, создавший эту виртуальную машину, или тот, кому эти функции были переданы. Владелец получает все уведомления об утилизации ресурсов или изменениях состояния ВМ, а также несет ответственность за затраты. В этом смысле CloudMaster помогает привить культуру контроля используемых мощностей и ответственности за оставленные машины-«зомби».
Ограничения на создание новых ВМ регулируются правами доступа и квотами. И тут возможна настройка любых рабочих процессов, вплоть до допуска в облако представителей клиента. Можно прописать квоты для команд и предусмотреть различные действия при их достижении или приближении к некому пороговому значению (допустим, 70% от квоты).
![Клик для увеличения](https://linkme.ufanet.ru/box/200x100/9449cf332c6b89ca5bb0084ba120b505.png)
Биллинг от облачных провайдеров
![Клик для увеличения](https://linkme.ufanet.ru/box/200x100/ff590615e57e8d35d54500525829e1c5.png)
Окно управления квотами
Для частных облаков (OpenStack и VMware) CloudMaster поддерживает своего рода биржу — оценку стоимости запуска виртуальных машин, с помощью которых можно выбирать более выгодную схему утилизации ресурсов. Коллеги говорят, что в будущем такая функция может появиться и для публичных облаков.
В этой системе мне ближе всего роль инфраструктурного инженера, поэтому ее оставил напоследок. Для DevOps это, конечно, новый инструмент, но зато появляется возможность контролировать, что происходит с облачными ресурсами, используя только его. Можно быстрее и проще разворачивать популярные инструменты конфигурирования, мониторинга и разработки вроде Chef и Ansible.
При необходимости для администраторов и разработчиков есть Java SDK.
Самое главное, что CloudMaster, как и другие CMP, позволяет перейти от ручного рутинного выделения ресурсов к более интересным задачам: проработке автоматизаций на базе «инфраструктура как код» и т.п.
По моему опыту, появление подобных инструментов оправдано, если в компании задействовано как минимум полсотни виртуальных машин и есть не менее полутора десятков активных пользователей разных облаков. С одной стороны, это некоторое усложнение инфраструктуры, но с другой — приведение разнородных облаков, каждое из которых имеет собственные инструменты управления, к общему знаменателю с гарантией, что при этом не нарушаются внутренние корпоративные стандарты. При этом инструмент «спускает» ответственность за утилизацию ресурсов и планирование бюджета на уровень проектных менеджеров, что идеологически правильнее.
===========
Источник:
habr.com
===========
Похожие новости:
- [Высокая производительность, IT-инфраструктура, Облачные сервисы, Компьютерное железо] Ускоряемся: апгрейд инфраструктуры в ЦОДе
- [Облачные сервисы, Статистика в IT] Россия вышла на третье место в мире по числу камер видеонаблюдения
- [Python, Управление разработкой, Управление проектами, Управление персоналом, Карьера в IT-индустрии] Я единственный из 1400, или самый крутой рекрутинг, что я проходил
- [Хостинг, Серверное администрирование, Облачные сервисы] Новый дата-центр RUVDS с Росгвардией на защите
- [Алгоритмы, Облачные вычисления, Интернет-маркетинг, Управление e-commerce, Искусственный интеллект] Розничная цена: с головы или довериться алгоритмам
- [Управление разработкой] На пути к Canary
- [Управление разработкой, Развитие стартапа, Управление продуктом, Управление продажами, Управление персоналом] Как перестать впаривать и начать развивать продукт, привлекая новых клиентов
- [Разработка веб-сайтов, Программирование, Исследования и прогнозы в IT, Облачные сервисы] Самые популярные языки программирования для бэкенда: для чего они подходят лучше всего и какие компании их используют (перевод)
- [Аналитика мобильных приложений, Статистика в IT, Социальные сети и сообщества, IT-компании] 2020 – год всемирной мобильности (как бы иронично это ни звучало) (перевод)
- [Программирование, IT-инфраструктура, Виртуализация, Промышленное программирование, Управление разработкой] Цифровая индустрия: непрерывная оптимизация процессов
Теги для поиска: #_oblachnye_vychislenija (Облачные вычисления), #_servernoe_administrirovanie (Серверное администрирование), #_upravlenie_razrabotkoj (Управление разработкой), #_oblachnye_servisy (Облачные сервисы), #_cloudmaster, #_cloud, #_softline, #_softlajn (Софтлайн), #_blog_kompanii_softline (
Блог компании Softline
), #_oblachnye_vychislenija (
Облачные вычисления
), #_servernoe_administrirovanie (
Серверное администрирование
), #_upravlenie_razrabotkoj (
Управление разработкой
), #_oblachnye_servisy (
Облачные сервисы
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 04-Июл 21:13
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 4 месяца |
|
Здравствуйте! Я Игорь Гальцев, с 2010 технический руководитель различных направления разработок Softline в области автоматизации управления и продаж облачных (подписочных) сервисов. Сегодня хочу рассказать об инструменте, который переводит процедуры согласования и выдачи виртуальных машин на полное самообслуживание, сохраняя логику квот и добавляя возможность прогнозирования утилизации ресурсов. ![]() Как некогда бывший инфраструктурный инженер, знаю, во что превращается использование нескольких частных или публичных облаков в большой команде. Обычно тут два пути. Либо процесс выделения ресурсов слишком бюрократизируется — команды начинают ждать виртуальные машины неделю и сохранять их «живыми» максимально долго, лишь бы не повторять этот путь. Либо наступает настоящий хаос, когда никто не знает, какая команда и сколько ресурсов потребляет и на что уходят сотни и тысячи долларов ежемесячно на том же 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, позволяет перейти от ручного рутинного выделения ресурсов к более интересным задачам: проработке автоматизаций на базе «инфраструктура как код» и т.п. По моему опыту, появление подобных инструментов оправдано, если в компании задействовано как минимум полсотни виртуальных машин и есть не менее полутора десятков активных пользователей разных облаков. С одной стороны, это некоторое усложнение инфраструктуры, но с другой — приведение разнородных облаков, каждое из которых имеет собственные инструменты управления, к общему знаменателю с гарантией, что при этом не нарушаются внутренние корпоративные стандарты. При этом инструмент «спускает» ответственность за утилизацию ресурсов и планирование бюджета на уровень проектных менеджеров, что идеологически правильнее. =========== Источник: habr.com =========== Похожие новости:
Блог компании Softline ), #_oblachnye_vychislenija ( Облачные вычисления ), #_servernoe_administrirovanie ( Серверное администрирование ), #_upravlenie_razrabotkoj ( Управление разработкой ), #_oblachnye_servisy ( Облачные сервисы ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 04-Июл 21:13
Часовой пояс: UTC + 5