Комплексная автоматизация с Ansible и OpenStack

Решения Ansible гарантируют максимальную гибкость. Это позволяет сообществу находить все новые способы использования модулей Ansible для автоматизации часто выполняемых операций на многих уровнях, в том числе в сочетании с технологиями OpenStack.

В этом блоге мы будем обсуждать многочисленные варианты использования Ansible, самого популярного программного обеспечения (ПО) для автоматизации, совместно с OpenStack, самым популярным ПО для облачной инфраструктуры. Мы поможем вам понять, как и почему вам следует использовать Ansible, чтобы сделать свою жизнь проще с помощью комплексной автоматизации (Full-Stack Automation), как мы любим ее называть.

Для начала обсудим уровни комплексной автоматизации, показанные на диаграмме выше. Внизу у нас оборудование (серверы, системы хранения данных и сетевое оборудование). Далее идет операционная система (Linux или Windows). На Linux вы можете установить OpenStack, чтобы абстрагироваться от физических ресурсов центра обработки данных и развернуть программную версию вычислительных ресурсов, сети и хранилища. Поверх OpenStack развертываются определенные арендатором службы, необходимые для создания виртуальных машин, на которых будут запускаться приложения. Наконец, вы должны обеспечить управление операционной системой (Linux или Windows), чтобы развертывать приложения и рабочие нагрузки, которые вам действительно нужны (базы данных, веб-серверы, серверы мобильных приложений и т. д.). Если вы используете контейнеры (например, Docker или Rkt), вы будете упаковывать эти приложения в образы, которые будут затем развернуты поверх гостевой ОС. Кроме того, в некоторых языках появилась концепция серверов приложений, которая добавляет еще один уровень (например, J2EE).

Возможности для управления, предоставляемые решениями Ansible

Ansible предоставляет модули для управления каждым слоем. Даже для сетевого оборудования, точнее, если подходить к этому с технической точки зрения, для сетевой операционной системы, такой как IOS или NXOS (см. полный список сетевых модулей Ansible).

1. Стандартное взаимодействие с операционной системой: установка пакетов, изменение или принудительное применение содержимого или прав доступа к файлам, управление службами, создание и удаление пользователей и групп пользователей и т. д.

• Linux и BSD через SSH (первый и самый популярный вариант использования).
• Windows через PowerShell (начиная с версии 1.7).

2. Программное обеспечение для реализации концепции «инфраструктура как услуга» (IaaS): установите программное обеспечение IaaS и сопутствующие компоненты (базы данных, балансировщики нагрузки, файлы конфигурации, службы и другие вспомогательные инструменты).

• Установщик OpenStack-ansible, используемый в некоторых сборках OpenStack от других поставщиков. Не забывайте о том, что платформа Red Hat OpenStack использует не Ansible, а Heat и Puppet. В следующих релизах Ansible будет использоваться для выполнения определенных проверок и оказания операторам помощи в процессе установки обновлений и новых версий.
• Установщик CloudStack — это также проект на основе Ansible.

3. Виртуальные ресурсы: настраивайте ресурсы, например виртуальную машину или экземпляр, определяя размер, права доступа, контент, профиль безопасности, параметры сетевого подключения и т. д.

• Модули OpenStack Ansible (начиная с Ansible 2.0), например Nova или Neutron. Они основаны на библиотеке OpenStack Shade, которая используется всеми инструментами CLI в OpenStack.
• Эти модули также могут управлять не такими уж и виртуальными сетевыми ресурсами через netconf (начиная с версии 2.2).
• Модули VMware vSphere Ansible.
• RHV, или oVirt, или Libvirt только для KVM.
• Также есть модули для поставщиков облачных услуг, таких как Amazon, Google Cloud, Azure и Digital Ocean.

4. Гостевая ОС: компоненты аналогичны таковым у ОС хоста. Но как вы узнаете, сколько у вас гостевых систем?

• Инструмент Ansible Dynamic Inventory будет динамически опрашивать уровень IaaS и ВМ в целях обнаружения доступных в настоящее время экземпляров. При этом определяется имя узла, IP-адреса и настройки безопасности, то есть управление активами становится динамичным. Такая возможность будет особенно полезна для тех, кто использует группы автомасштабирования (Auto Scaling Groups) в своей облачной инфраструктуре, поскольку список экземпляров кардинально меняется с течением времени.

5. Модуль управления контейнерами (опционально).

• Docker: обратите внимание, что старый модуль Docker в версии Ansible 2.1 будет заменен на новый собственный компонент.
• Kubernetes.
• Atomic Host.

6. Арендованное ПО: базы данных, веб-серверы, балансировщики нагрузки, модули обработки данных и т. д.

• Ansible Galaxy — репозиторий рецептов (playbook) для развертывания самого популярного ПО, и это результат совместной работы тысяч членов сообщества.
• Вы также можете управлять веб-инфраструктурой наподобие JBoss, позволяя Ansible определять, как приложение будет развертываться на сервере приложений.

Рекомендации по установке последней версии Ansible в виртуальной среде Python

Как вы уже поняли, некоторые функции доступны только в новейших версиях Ansible, например 2.2. Тем не менее в вашей версии ОС может быть более старая версия. К примеру, в RHEL 7 или CentOS 7 вы найдете только Ansible 1.9.

Учитывая, что Ansible — это инструмент командной строки, написанный на языке Python, который не запрещает наличия нескольких версий в системе, вам, возможно, не понадобится усиление безопасности в Ansible, которое предлагает ваша сборка, и вы захотите опробовать последнюю версию.

Однако, как и в случае с любым другим программным обеспечением Python, существует много зависимостей, поэтому не рекомендуется использовать непроверенные новые библиотеки вместе с системными. Библиотеки могут совместно использоваться другими компонентами вашей системы, и непроверенные более новые версии способны нарушить работу других приложений. Проще всего установить последнюю версию Ansible со всеми зависимостями в изолированную папку под вашей непривилегированной учетной записью. Это будет виртуальная среда Python (Python Virtual Environment, virtualenv), и если вы все сделаете правильно, то сможете безопасно опробовать последние модули Ansible для комплексной оркестровки. Разумеется, не рекомендуется применять такую практику в производственной среде. Это не более чем упражнение, помогающее вам улучшить свои навыки в области DevOps.

1. Установите обязательные компоненты (pip, virtualenv)

В данном случае нам понадобится только одна «общесистемная» библиотека Python — virtualenvwrapper. Кроме этого, вам не следует выполнять команду sudo pip install, поскольку это заменит системные библиотеки Python на более новые непроверенные версии. Доверять в данном случае мы можем только библиотеке virtualenvwrapper. Виртуальная среда — эффективный механизм установки и тестирования новых модулей Python в вашей непривилегированной учетной записи пользователя.

$ sudo yum install python-pip
$ sudo pip install virtualenvwrapper
$ sudo yum install python-heatclient python-openstackclient python2-shade

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

wget https://bootstrap.pypa.io/get-pip.py
python get-pip.py --user
 .local/bin/pip install virtualenvwrapper --user
export PATH=$PATH:~/.local/bin #Remember to include this in your .bashrc

2. Установите новую виртуальную среду, где мы будет развертывать последнюю версию Ansible

Для начала создайте каталог для хранения виртуальных сред.

$ mkdir $HOME/.virtualenvs

Затем добавьте следующие строки в ваш файл .bashrc:

export WORKON_HOME=$HOME/.virtualenvs
source /usr/bin/virtualenvwrapper.sh

Теперь выполните команду source для этого файла.

$ source ~/.bashrc

На этом этапе создаются ссылки-оболочки, но только при первом запуске. Выполните команду workon, чтобы просмотреть список сред, он не должен быть пустым. Далее мы создадим новую среду virtualenv с именем ansible2, она будет активирована автоматически и получит доступ к пакетам, установленным по умолчанию с помощью RPM.

$ mkvirtualenv ansible2 --system-site-packages

Для выхода из среды virtualenv введите deactivate, а для повторного входа — workon.

$ deactivate
$ workon ansible2

3. Войдите в новую среду virtualenv и установите Ansible2 через PIP (как обычный пользователь, без root-прав)

Вы увидите, что запрос на ввод команды в оболочке изменился и в скобках указано имя virtualenv.

(ansible2) $ pip install ansible 

Эта команда установит только зависимости для Ansible 2, используя ваши общесистемные пакеты Python, доступные в RPM (благодаря флагу system-site-packages, который мы использовали ранее). Альтернативный вариант, если вы хотите опробовать ветвь разработки.

(ansible2) $ pip install git+git://github.com/ansible/ansible.git@devel

(ansible2) $ ansible --version

Если вам нужно будет удалить среду virtualenv и все ее зависимости, просто введите команду rmvirtualenv ansible2.

ПРИМЕЧАНИЕ. Если приведенные выше команды не сработали, убедитесь, что в ваших системах установлены библиотеки GCC и OpenSSL, поскольку некоторые зависимости Python используют последние криптографические модули.

4. Установите зависимости клиента OpenStack

Первая команда из приведенного ниже фрагмента кода гарантирует, что у вас будут последние стабильные версии OpenStack API, тем не менее вы также можете воспользоваться командой pip install, чтобы получить последнюю версию инструмента командной строки (CLI). Вторая команда предоставляет последнюю версию библиотеки Python Shade для подключения к последним версиям OpenStack API с помощью ansible, независимо от конкретного инструмента CLI.

(ansible2) $ yum install python-openstackclient python-heatclient

(ansible2) $ pip install shade --upgrade

5. Протестируйте свое развертывание

(ansible2) $ ansible -m ping localhost

localhost | SUCCESS => {

"changed": false,

"ping": "pong"

}

ПРИМЕЧАНИЕ. Вы не можете запускать эту версию ansible за пределами виртуальной среды virtualenv, поэтому всегда выполняйте команду workon ansible2 перед usi.

Оркестровка OpenStack с использованием Ansible

Внимательные читатели заметят, что, используя Ansible для оркестровки OpenStack, мы, похоже, игнорируем тот факт, что официальным модулем оркестровки для этой платформы все же является Heat. Фактически Ansible Playbook предоставляет практически те же возможности, что и шаблон HOT (HOT — это синтаксис на основе YAML для Heat, реинкарнации AWS CloudFormation). Тем не менее многие профессионалы в области DevOps предпочитают не тратить время на изучение нового синтаксиса, и они уже консолидируют весь процесс для своей гибридной инфраструктуры.

Команда Ansible понимает это, поэтому использует Shade, официальную библиотеку из проекта OpenStack, для создания интерфейсов для вызова OpenStack API. На момент написания этой статьи версия Ansible 2.2 включала модули для вызова следующих API.

• Keystone: пользователи, группы, роли, проекты.
• Nova: серверы, пары ключей, группы и флаги безопасности.
• Neutron: порты, сеть, подсети, маршрутизаторы, плавающие IP-адреса.
• Ironic: узлы, интроспектива.
• Объекты Swift.
• Тома Cinder.
• Образы Glance.

С точки зрения Ansible необходимо организовать взаимодействие с сервером, где система сможет загружать учетные данные OpenStack и создавать HTTP-соединения с различными OpenStack API. Если этот сервер — ваша машина (localhost), то Ansible будет работать локально, загружать учетные данные Keystone и инициировать взаимодействие с OpenStack.
Давайте рассмотрим пример. Мы будем использовать модули Ansible OpenStack для подключения к Nova и запуска небольшого экземпляра с образом Cirros. Для начала мы загрузим последний образ Cirros, если вы не сделали этого ранее. Мы воспользуемся существующим ключом SSH текущего пользователя. Вы можете скачать этот playbook по этой ссылке на Github.

---
# Setup according to Blogpost "Full Stack automation with Ansible and OpenStack". Execute with "ansible-playbook ansible-openstack-blogpost.yml  -c local -vv"
# #
# #
# #
- name: Execute the Blogpost demo tasks
  hosts: localhost
  tasks:
  - name: Download cirros image
    get_url:
      url: http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img
      dest: /tmp/cirros-0.3.4-x86_64-disk.img
  - name: Upload cirros image to openstack
    os_image:
      name: cirros
      container_format: bare
      disk_format: qcow2
      state: present
      filename: /tmp/cirros-0.3.4-x86_64-disk.img

  - name: Create new keypair from current user's default SSH key
    os_keypair:
      state: present
      name: ansible_key
      public_key_file: "{{ '~' | expanduser }}/.ssh/id_rsa.pub"

  - name: Create the test network
    os_network:
      state: present
      name: testnet
      external: False
      shared: False
      #provider_network_type: vlan
      #provider_physical_network: datacentre
    register: testnet_network

  - name: Create the test subnet
    os_subnet:
      state: present
      network_name: "{{ testnet_network.id }}"
      name: testnet_sub
      ip_version: 4
      cidr: 192.168.0.0/24
      gateway_ip: 192.168.0.1
      enable_dhcp: yes
      dns_nameservers:
        - 8.8.8.8
    register: testnet_sub

  - name: Create the test router
    ignore_errors: yes #for some reasons, re-running this task gives errors
    os_router:
      state: present
      name: testnet_router
      network: nova
      external_fixed_ips:
        - subnet: nova
      interfaces:
        - testnet_sub

  - name: Create a new security group
    os_security_group:
      state: present
      name: secgr
  - name: Create a new security group allowing any ICMP
    os_security_group_rule:
      security_group: secgr
      protocol: icmp
      remote_ip_prefix: 0.0.0.0/0
  - name: Create a new security group allowing any SSH connection
    os_security_group_rule:
      security_group: secgr
      protocol: tcp
      port_range_min: 22
      port_range_max: 22
      remote_ip_prefix: 0.0.0.0/0
     
  - name: Create server instance
    os_server:
      state: present
      name: testServer
      image: cirros
      flavor: m1.small
      security_groups: secgr
      key_name: ansible_key
      nics:
        - net-id: "{{ testnet_network.id }}"
    register: testServer

  - name: Show Server's IP
    debug: var=testServer.openstack.public_v4

После запуска мы видим IP-адрес экземпляра. Запишем его. Теперь можно использовать Ansible для подключения к этому экземпляру через SSH. Предполагается, что используемая по умолчанию сеть Nova поддерживает подключения с нашей рабочей станции (в нашем случае через сеть поставщика услуг).

Сравнение с OpenStack Heat

Применение Ansible вместо Heat имеет свои преимущества и недостатки. Например, работая с Ansible, вы должны отслеживать создаваемые вами ресурсы и вручную удалять их (в обратном порядке), когда они больше не нужны. Особенно сложно вам придется с портами Neutron, плавающими IP-адресами и маршрутизаторами. Но если это Heat, то вы просто удаляете стек, и все созданные ресурсы будут удалены автоматически.
Сравните приведенный выше пример с похожим (но не аналогичным) шаблоном Heat Template, который можно скачать из следующего репозитория Github gist.

heat_template_version: 2015-04-30

description: >
  Node template. Launch with "openstack stack create   --parameter public_network=nova --parameter ctrl_network=default --parameter secgroups=default --parameter image=cirros --parameter key=ansible_key --parameter flavor=m1.small --parameter name=myserver -t openstack-blogpost-heat.yaml testStack"

parameters:
  name:
    type: string
    description: Name of node
  key:
    type: string
    description: Name of keypair to assign to server
  secgroups:
    type: comma_delimited_list
    description: List of security group to assign to server
  image:
    type: string
    description: Name of image to use for servers
  flavor:
    type: string
    description: Flavor to use for server
  availability_zone:
    type: string
    description: Availability zone for server
    default: nova
  ctrl_network:
    type: string
    label: Private network name or ID
    description: Network to attach instance to.
  public_network:
    type: string
    label: Public network name or ID
    description: Network to attach instance to.

resources:

  ctrl_port:
    type: OS::Neutron::Port
    properties:
      network: { get_param: ctrl_network }
      security_groups: { get_param: secgroups }

  floating_ip:
    type: OS::Neutron::FloatingIP
    properties:
      floating_network: { get_param: public_network }
      port_id: { get_resource: ctrl_port }

  instance:
    type: OS::Nova::Server
    properties:
      name: { get_param: name }
      image: { get_param: image }
      flavor: { get_param: flavor }
      availability_zone: { get_param: availability_zone }
      key_name: { get_param: key }
      networks:
       - port: { get_resource: ctrl_port }

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

Теперь давайте посмотрим, что произойдет, если мы создадим много экземпляров, но забудем записать их IP-адреса. Отличным примером использования инструмента Dynamic Inventory для OpenStack является анализ текущего состояния наших арендованных виртуализированных ресурсов и получение всех IP-адресов серверов, чтобы мы могли, например, проверить версию их ядра. Например, это прозрачно делается с помощью решения Ansible Tower, которое будет периодически проводить инвентаризацию и формировать обновленный список серверов OpenStack, подлежащих управлению.

Прежде чем выполнять эти операции, убедитесь, что у вас нет устаревших файлов cloud.yaml в каталоге ~/.config/openstack, /etc/openstack или /etc/ansible. Скрипт Dynamic Inventory сначала будет искать переменные среды (OS_*), а затем — перечисленные файлы.

#ensure you are using latest ansible version

$ workon ansible2
$ wget https://raw.githubusercontent.com/ansible/ansible/devel/contrib/inventory/openstack.py

$ chmod +x openstack.py

$ ansible -i openstack.py all -m ping

bdef428a-10fe-4af7-ae70-c78a0aba7a42 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}
343c6e76-b3f6-4e78-ae59-a7cf31f8cc44 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

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

$ ./openstack.py –list

{
 "": [
    "777a3e02-a7e1-4bec-86b7-47ae7679d214",
    "bdef428a-10fe-4af7-ae70-c78a0aba7a42",
    "0a0c2f0e-4ac6-422d-8d9b-12b7a87daa72",
    "9d4ee5c0-b53d-4cdb-be0f-c77fece0a8b9",
    "343c6e76-b3f6-4e78-ae59-a7cf31f8cc44"
 ],
 "_meta": {
    "hostvars": {
     "0a0c2f0e-4ac6-422d-8d9b-12b7a87daa72": {
       "ansible_ssh_host": "172.31.1.42",
       "openstack": {
         "HUMAN_ID": true,
         "NAME_ATTR": "name",
         "OS-DCF:diskConfig": "MANUAL",
         "OS-EXT-AZ:availability_zone": "nova",
         "OS-EXT-SRV-ATTR:host": "compute-0.localdomain",
         "OS-EXT-SRV-ATTR:hypervisor_hostname": "compute-0.localdomain",
         "OS-EXT-SRV-ATTR:instance_name": "instance-000003e7",
         "OS-EXT-STS:power_state": 1,
         "OS-EXT-STS:task_state": null,
         "OS-EXT-STS:vm_state": "active",
         "OS-SRV-USG:launched_at": "2016-10-10T21:13:24.000000",
         "OS-SRV-USG:terminated_at": null,
         "accessIPv4": "172.31.1.42",
         "accessIPv6": "",
(....)

Заключение

Несмотря на то что Heat очень полезен, некоторые могут предпочесть изучить Ansible, чтобы применять это решение для оркестровки, поскольку оно предлагает использовать единый язык для определения и автоматизации всего набора ИТ-ресурсов. Надеюсь, эта статья была полезна вам с практической точки зрения. Мы рассмотрели базовые варианты использования Ansible для запуска ресурсов OpenStack. Если вы заинтересовались и хотите оценить возможности Ansible и Ansible Tower, посетите ресурс. Хорошей отправной точкой было бы реализовать взаимодействие Heat с Ansible Tower через обратные вызовы, как описано в другом сообщении в блоге.

Кроме того, если вы хотите узнать больше о платформе Red Hat OpenStack, то на нашем сайте найдете множество ценных ресурсов (включая видеоролики и официальные документы).

Автор: ICL Services

Источник