В нашем блоге на Хабре мы много рассказываем о внедрении подходов DevOps и разработанных нами инструментах автоматизации разработки и тестирования. Сегодня речь пойдет о том, как мы решали проблему взаимодействия с VMware vSphere.
Немного истории
В vSphere работают все наши виртуальные машины — как сборочные, так и тестовые серверы.
Пару лет назад до появления нашей собственной системы Continuous Integration большая часть наших сборок была перенесена на инструмент TeamCity. На тот момент у нас не было тестовых и деплойных конфигураций, однако необходимость их развития становилась все более явной.
На середину 2014 года нам было известно два решения для автоматизации работы с виртуальными машинами: использование собственного API VMware для работы с vSphere (библиотека VIX API) и применение библиотеки pysphere. У каждого из этих инструментов были недостатки.
У VIX API был слишком высокий для нас порог вхождения:
- Инструмент представлял собой набор сложных и плохо документированных C-библиотек.
- Всю интеграцию с нашими CI-системами пришлось бы писать самостоятельно на C.
Библиотека pysphere вообще была фактически недокументированной и с рядом проблем:
- инструмент написан под Python 2.7;
- отсутствовал интерфейс командной строки;
- продукт представлял собой набор разрозненных классов, хаотично раскиданных по скриптам пакета;
- проект только развивался и содержал множество багов.
Однако если сравнивать pysphere с VIX API, то у первого были и свои преимущества:
- Он работает гораздо быстрее за счет использования http rest api для доступа к функциям vSphere.
- Экспертиза в Python у нас в компании гораздо выше, так что порог вхождения для использования этого инструмента был ниже.
- Отзывы о нашей самописной библиотеке PT.VIX поверх VIX API не выдерживали никакой критики в плане поддержки и надежности ее работы.
Поэтому было решено использовать эту библиотеку и на ее базе создать собственное решение.
Проект vSphereTools
Прежде чем начать программировать, мы составили требования к набору инструментов автоматизации.
- продукт должен был поддерживать работу из консоли с широким набором команд;
- иметь понятное API для возможности его импорта как обычной python-библиотеки;
- быть встроенным в TeamCity в качестве метараннеров, доступных для выбора в шагах конфигураций.
Концептуальная модель взаимодействия vSphereTools с самой «Сферой» представлена ниже:
Все довольно просто: инициатор, которым может быть пользователь или скрипт, отправляет команды, полученные через командную строку, инструменту vSphereTools, который переправляет данные библиотеке pysphere. Дальше запрос попадает в vSphere, где обрабатывается и отправляется виртуальной машине, которая выдает то, что нам нужно («стейты», атрибуты и т.п.)
Требования к окружению для vSphereTools были минимальны:
- нужен служебный пользователь для доступа к vSphere;
- с машины, на которой запускается vSphereTools, должен быть доступен сервис vcenter, а также ESX, на котором работает целевая виртуальная машина.
- на целевой «виртуалке» должны быть также установлены инструменты VMware Tools;
- на машине, на которой запускаются vSphereTools, должен быть установлен Python 2* версий 2.7 или старше.
Полная документация с примерами доступна в открытом сообществе DevOpsHQ. В итоге скрипты vSphereTools реализуют множество функций от старта и остановки виртуальных машин до копирования локального файла внутрь нужной виртуалки или запуска на ней конкретной программы.
В настоящий момент метараннеры и скрипты vSphereTools используются при разработке и тестировании практических всех крупных продуктов Positive Technologies — например, MaxPatrol SIEM, PT Application Firewall и Application Inspector и во многих других проектах.
Ограничения и возможные доработки
Как у любого инструмента у нашего продукта vSphereTools есть и свои ограничения:
- Последняя доступная в индексе версия pysphere 0.1.8, а именно она лежит в основе vSphereTools.
- Новые методы для vSphereTools приходится реализовывать только силами DevOps-отдела компании.
- Новые версии VMware vSphere возможно не будут поддерживать старый API.
- В настоящий момент наши скрипты работают только с Python 2* (2.7 и выше).
Поэтому мы планируем и ряд доработок. Например, хотим переписать vSphereTools на VMware vCloud Suite SDK for Python for vSphere 6.0. Документация этого инструмента уже доступна, также есть и python-api для него — библиотека pyvmomi.
P. S. Рассказ о проекте vSphereTools был представлен в рамках DevOps-митапа, который состоялся осенью в Москве.
По ссылке представлены презентации 16 докладов, представленных в ходе мероприятия. Все презентации и видео выступлений будут добавлены в таблицу в конце этого топика-анонса.
Автор: Тимур Гильмуллин
P. P. S. Напоминаем, что совсем скоро при поддержке Positive Technologies в Москве пройдет курс по asyncio+aiohttp от Core-разработчика Python Андрея Светлова.
Мы хотим предложить один бесплатный билет на семинар автору лучшего вопроса для Андрея — вопрос выберет он сам и ответит на него в ходе занятия. Присылайте свои вопросы по адресу: asyncio2016@ptsecurity.com.
Поделиться с друзьями
Комментарии (7)
irony_iron
08.12.2016 17:15Похоже что 2014 год был годом pysphere в devops сообществе разработчиков системного ПО, те же самые технологии параллельно были применены в сходных проектах:
Acronis Автоматизация тестирования: «беспилотник» Acronis Kernel
Cezurity Как тестируют антивирусное ПО
Подозреваю что орекстратор имел или порог вхождения заоблачный или был сырой в 2014, а людям надо было ехать.
athacker
16.12.2016 14:48А в чём профит по сравнению с PowerCLI? Который существует минимум с 2008 года:
vSphere PowerCLI 1.0.1
Released 4 SEP 2008
Соответственно, к 2014-му уже был вполне себе функционален, чтобы делать все те прекрасные штуки, которые перечислены в статье.
alexplex
16.12.2016 14:48Позвольте вопрос — а вы рассмотрели варианты, перед тем как изобретать велосипед? Если вам нужен был commandline-интерфейс, достаточно было скачать PowerCLI, существующую минимум с 2010 года.
На середину 2014 года нам было известно два решения для автоматизации работы с виртуальными машинами: использование собственного API VMware для работы с vSphere (библиотека VIX API) и применение библиотеки pysphere. У каждого из этих инструментов были недостатки.
vSphere SDK существовало на тот момент на куче разных языков + ряд альтернативных способов работы с VMware (PowerCLI, MOB, vim-cmd, etc). Все они работают одинаково и через один и тот же SOAP API и функциональной разницы нет никакой. Более того, vSphere Client, Web Client работают по нему же.
Окей, выбрали python. Но pysphere — зачем??:
В 2013 я читал статью от 2012 года о сравнении 3х питоновских транспортов для работы с vSphere https://dunniganp.wordpress.com/2012/09/10/comparison-of-python-vmware-vsphere-client-libraries/
Скачал, потестил. pyvissdk только коннектилась к гипервизору 10 секунд, psphere содержала древние wsdl, pysphere — кривая до жути. По поводу скорости работы psphere в статье некорректное сравнение, т.к. она выкачивает сразу все свойства всего ServiceInstance при коннекте, впоследствии работая только с полями, не используя методы. Это очень быстрая библиотека. Показатели сразу изменяются в её пользу, если проверить тот же скрипт не на 2 виртуалках, а например при выводе какого-нибудь свойства на экран для сотни машин.
Выбор оказался простым — pysphere + свежие wsdl с сайта VMware + 5 минут на доработку файла managedobjects.py под новую схему. И получил шикарный транспорт, которым активно пользуюсь более 3х лет.
Новые версии VMware vSphere возможно не будут поддерживать старый API
По поводу свойств — будут, поверьте. У VMware обратная совместимость, как у Microsoft. Вы без проблем можете использовать SDK хоть от ESX 3.0 для работы с vSphere 6.5. В этом случае будут недоступны новые свойства, но стоит поменять параметр apiVersion в заголовке XML — и гипервизор все данные, которые есть. Аналогично и в обратную сторону — можно работать с древним ESXi, указав самую актуальную версию API в заголовке и он нормально это прожует
Поэтому мы планируем и ряд доработок. Например, хотим переписать vSphereTools на
Возьмите PowerCLI и не мучайтесь. В целом, он идеален для задач DevOps и работы (вызовы методов) с сущностями vSphere удобней всего PowerCLI. Для получения свойств, статистики, автоматизации проверок комплайнса — psphere.
640509-040147
> Библиотека pysphere вообще была фактически недокументированной и с рядом проблем:
Тогда почему не выбрали pyvmomi? Он исключительно хорош