Автоматизация задач администрирования API VMware vSphere с использованием Ansible

    image

    В предыдущей статье мы рассмотрели взаимодействие с VMware с помощью Python. В этой же обсудим взаимодействие с VMware с помощью Ansible.


    Ansible — система управления конфигурациями, написанная на языке программирования Python с использованием декларативного языка разметки для описания конфигураций. Про Ansible на Хабре уже есть множество статей, но стоит еще раз упомянуть, что одним из ключевых свойств playbook'a является идемпотентность. Это значит, что сколько бы раз подряд вы не запускали свой playbook, результат будет один и тот же.


    Ansible модули используют библиотеку pyVmomi и чаще всего требуют Python версии выше 2.6.


    Вы можете установить pyVmomi, используя pip:


    pip install pyvmomi

    Использование плагина динамической инвентаризации VMware


    Согласно документации лучший способ взаимодействия с существующими хостами — это использование плагина динамической инвентаризации VMware.


    Для использования данного плагина необходимо внести в файл ansible.cfg следующие правки:


    [inventory]
    enable_plugins = vmware_vm_inventory

    Затем создать файл в рабочей папке, имя которого заканчивается на .vmware.yml или .vmware.yaml. Например:


    plugin: vmware_vm_inventory
    strict: False
    hostname: 10.10.10.10
    username: admin@vsphere.local
    password: AdminSecur3P@ssw0rd
    validate_certs: False
    with_tags: True

    После чего выполнить:


    ansible-inventory --list -i <filename>.vmware.yml

    Модули


    vmware_guest

    Этот модуль используется для:


    • создания новых виртуальных машин из шаблонов или других виртуальных машин
    • управления состоянием питания виртуальной машины
    • изменением различных компонентов виртуальной машины
    • переименование виртуальной машины
    • удаление виртуальной машины со связанными компонентами
    • и многого другого

    Основные параметры:


    hostname
    DNS-имя или IP-адрес хоста ESXI-сервера
    username
    логин пользователя для подключения
    password
    пароль пользователя для подключения
    validate_certs
    проверка валидации сертификата
    datacenter
    datacenter виртуальной машины
    cluster
    кластер виртуальной машины
    name
    имя целевой виртуальной машины
    template
    имя виртуальной машины или шаблона, который будет клонирован
    folder
    целевое расположение виртуальной машины
    annotation
    описание или примечание для виртуальной машины
    datastore
    целевой datastore
    networks
    настройки сети для новой машины
    customization
    параметр, позволяющий кастомизировать гостевую ОС
    hardware
    кастомизация hardware машины

    Следующий пример клонирует машину, применит сетевые настройки и дождется момента, когда на ней будет доступна сеть:


    - name: Клонирование машины из шаблона
      vmware_guest:
        hostname: "{{ vcenter_server }}"
        username: "{{ vcenter_user }}"
        password: "{{ vcenter_pass }}"
        validate_certs: False
        datacenter: datacenter1
        cluster: cluster1
        name: VMNAME
        template: TemplateName
        folder: /dc1/vm/targetFolder
        annotation: "Моя машина, клонированная из TemplateName"
        datastore: DATASTORE1
        networks:
          - name: VM Network
            ip: '10.10.100.100'
            netmask: '255.255.252.0'
            gateway: '10.10.100.10'
            dns_servers: [1.1.1.1, 8.8.8.8]
            type: static
        customization:
          hostname: "VMNAME.domain.ru"
          dns_servers: [1.1.1.1, 8.8.8.8]
        wait_for_ip_address: yes

    Подробная документация и дополнительные примеры доступны по ссылке.


    Для возможности кастомизации операционной системы есть несколько условий:


    1. Операционная система должна быть в списке поддерживаемых. Ознакомиться с матрицей поддержки операционных систем можно по ссылке
    2. Установленные VMware Tools
    3. На Linux-base дистрибутивах должен быть установлен Perl
    4. Установлена соответствующая версии ОС Microsoft System Preparation (Sysprep) для Windows-дистрибутивов

    vmware_guest_info

    Данный модуль позволяет получить данные о виртуальной машине, что дает возможность комбинировать его с предыдущим.


    Например, так выглядит переименование виртуальной машины:


    - name: Получаем uuid машины по имени
      vmware_guest_facts:
        hostname: "{{ vcenter_server }}"
        username: "{{ vcenter_user }}"
        password: "{{ vcenter_pass }}"
        validate_certs: False
        datacenter: datacenter1
        folder: /dc1/vm/targetFolder
        name: VMNAME
      register: vm_facts
    - name: Переименование машины
      vmware_guest:
        hostname: "{{ vcenter_server }}"
        username: "{{ vcenter_user }}"
        password: "{{ vcenter_pass }}"
        validate_certs: False
        cluster: cluster1
        uuid: "{{ vm_facts.instance.hw_product_uuid }}"
        name: NEW_VM_NAME

    Подробная документация.


    Главным плюсом является то, что после клонирования машины имеется возможность продолжить настройку уже операционной системы, например установить rabbitmq, настроить правила firewall и др. В случае необходимости есть возможность написать свой модуль для Ansible на Python. Взаимодействие Python c VMware было рассмотрено в предыдущей статье.


    Объединим все примеры выше и поставим себе такую задачу:


    • Развернуть виртуальную машину с ОС Windows из шаблона
    • Задать атрибут owner виртуальной машины
    • Установить на нее 7-zip с помощью модуля win_get_url
    • Установить на нее postgresql с помощью модуля win_chocolatey

    - name: Клонирование VM из шаблона
      vmware_guest:
        hostname: "{{ vcenter_server }}"
        username: "{{ vcenter_user }}"
        password: "{{ vcenter_pass }}"
        validate_certs: False
        datacenter: datacenter1
        cluster: cluster1
        name: VMNAME
        template: TemplateName
        folder: /dc1/vm/targetFolder
        annotation: "Моя машина, клонированная из TemplateName"
        datastore: DATASTORE1
        networks:
          - name: VM Network
            ip: '10.10.100.100'
            netmask: '255.255.252.0'
            gateway: '10.10.100.10'
            dns_servers: [1.1.1.1, 8.8.8.8]
            type: static
        customization:
          hostname: "VMNAME.domain.ru"
          dns_servers: [1.1.1.1, 8.8.8.8]
        wait_for_ip_address: yes
      register: vm_facts
    
    - name: Установка аттрибута owner
      vmware_guest_custom_attributes:
        hostname: "{{ vcenter_server }}"
        username: "{{ vcenter_user }}"
        password: "{{ vcenter_pass }}"
        validate_certs: False
        name: VMNAME
        uuid: "{{ vm_facts.instance.hw_product_uuid }}"
        state: present
        attributes:
          - name: "Owner"
            value: IIvanov
    
    # Добавление нового ansible-хоста
    - name: Add new host
      add_host:
        name: '10.10.100.100'
        ansible_host: '10.10.100.100'
        ansible_user: "{{ login }}"
        ansible_password: "{{ password }}"
        ansible_connection: winrm
        ansible_winrm_transport: basic
    
    # Ожидание загрузки машины и ответа от нее
    - name: Ansible ping
      win_ping:
      delegate_to: '10.10.100.100'
      register: result
      until: result.ping == "pong"
      retries: 20
      delay: 6
    
    # Установка 7-Zip с помощью win_package
    - name: Скачивание 7-zip
      win_get_url:
        url: https://www.7-zip.org/a/7z1701-x64.msi
        dest: C:\temp\7z.msi
      delegate_to: '10.10.100.100'
    
    - name: Установка 7-zip
      win_package:
        path: C:\temp\7z.msi
        state: present
      delegate_to: '10.10.100.100'
    
    - name: Установка postgresql с помощью chocolatey
      win_chocolatey:
        name: postgresql
        state: present
      delegate_to: '10.10.100.100'

    Данный подход хорошо ложится на модель «Инфраструктура как код (IaC)», согласно которой в процессе развертывания и настройки инфраструктуры используются те же практики и методологии, что и в разработке ПО. Playbook'и удобно хранить в системах контроля версий, что позволяет отслеживать изменения требований к инфраструктуре хронологически. Можно так же использовать методологию code-review для обеспечения качественного написания скриптов.


    Результатом может служить быстрое, документированное и воспроизводимое развертывание тестовых, staging, production машин и сред.

    Avanpost
    Безопасность начинается с управления доступом

    Комментарии 12

      0

      Я бы такой код на code review завернул. Почему у вас delegate_to для кода, который должен исполняться на другом хосте? Почему вы play не назначили на этот хост напрямую?


      Второе — у вас шути что с IP'шниками. Все хардкоженные, причём не в инвентори (у вас же нет инвентори, да?), а в тасках, а во-вторых с нулём логики. Network numbering plan отсутствует (кто проверяет, что шлюз и адрес в одной сети?).

        0
        Данный пример показывает возможность выполнить playbook фактически на хосте, которого еще нет. Очевидно, что описание машины «Моя машина, клонированная из TemplateName» в production среде неприемлимо. Это упрощенный пример.
          0

          Я прекрасно вижу что вы хотели сказать, но сказали вы это криво. Вообще, паттерн работы с провизом виртуальных машин подразумевает обратное: что вы делегируете создание виртуальной машины на гипервизор. Такой подход позволяет ограничить делегацию (только провиз/старт), и позволяет работать с VM как с любым хостом инвентори.


          Вы хотели показать как работать с vmware и ansible? Я не могу сказать насколько идиоматически у вас сделана работа с виртуалками в vmware, но вы точно делаете странное в примерах для ansible.

        0

        есть ряд вопросов:


        1. почему ansible, а не например vRealize или terraform?
        2. а создавать вм из content library чем не понравилось?
        3. каким образом получен эталонный шаблон ВМ?
        4. а какой 'gui' для заказа виртуалок? awx? foreman?
        5. как проверяете что в ваших плэйбуках нет бяки, которая сломает весь прод?
          0
          1. 4. У нас используется свой сервис, написанный на python.
          2. content library, если мне не изменяет память, появилась в VMware vSphere 6, когда данный способ работает для 5.5.
          3. в данном примере не имеет значения, как. Это может быть даже виртуальная машина
          5. тестирование с помощью molecule, линтеры, code review
            0

            3. а не в рамках данного примера? как шаблоны получаются? packer?
            5. пачка подвопросов:


            • только линтеры? т.е. Unit/integration тестов нет и фактически только после запуска узнаешь рабочий плэйбук или нет?
            • а как построен code review? встроенные средства gitlab/bitbucket для того что бы нельзя было мерджнуть в мастер (аля green build master) или коммитим в мастер и просим коллегу отревьюить по факту?

            6. сколько человек(1,2,10,100) активно модифицируют плэйбуки? какой порядок SLOC?

            0

            Content Library ужасно неэффективна — она копирует шаблон через ovf вместо быстрого клона vmxt.

            0
            3. Очень разнится в зависимости от команды и отделов.
            5.1 molecule — molecule.readthedocs.io/en/latest
            5.2 реализовано средствами gitlab и ревью merge request.
            6. 10-15
              0

              3. а можно примеры конкретные?
              5.1. спрашиваю т.к. агрегирую походу к тестированию кода описывающего инфраструктуру https://github.com/ultral/awesome-iac-testing и в частности практикую тестирование ansible, тут можно глянуть видео How to test Ansible and don't go nut с деталями какие подходы использовал или на хабре почитать про Что я узнал, протестировав 200 000 строк инфраструктурного кода. Если кратко то пропогандирую пирамиду тестирования инфрастуктуры image и мне крайне интересно посмотреть/послушать про тестирование ваших плэйбуков, которые находятся крайне близко к точке с высокой стоимостью ошибки. можно чуть подрбней рассказать что кроме линтеров используется для проверки плэйбуков? какой драйвер? какой верифаер? как набирает тест кейсы? как реализуете тест кейсы? сколько это работает по времени?
              5.2. а сколько примерное время от создания таски на изменение кода, до попадания на прод? час? день? месяц?

                0
                Шаблоны создаются разными способами от ручного редактирования до модификации шаблонов теми же плэйбуками. В зависимости от объема правок, запросы принимаются в течение рабочего дня-двух. Плэйбуки у нас в основном используются всего для создания и модификации тестовых сред.
              +1
              1. А где разбор как готовить эталонный плейбук?
              2. Windows 2019 вышла уже давно, там есть встроенный ssh server — зачем эти муки с winrm?
              3. Как вы обходите вопрос что сетевуха может не подключаться при раскатке машины?
              4. А что делаете когда катиться больше 2 машин?
              5. А зачем ставить 7zip отдельно, когда можно поставить его и постгрю через шоколад циклом?
              6. У вас в название шагов ошибка в наименовании сервиса Chocolatey
              7. Про то, как написан сам плейбук уже молчу — тут вам уже напихали.

              По итогу тема хорошая, но исполнение крайне низкого качества. Убрали бы в черновики, допили бы и был бы вам профит.

                0
                1. Как было написано в начале статьи, на хабре множество статей про то как писать плейбуки
                2. Windows 2019 установлена не на многих машинах. Показанный способ работает и с более старыми версиями
                3. 4. Этим занимается отдельный сервис, написанный на python.
                5. Чтобы как раз показать разные способы установки приложений
                6.7. Спасибо за отзыв, учтем.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое