OpenStack Kilo: первый реальный опыт инфраструктуры-как-кода для ВМ

В апреле вышел Kilo - тринадцатый релиз OpenStack. Мы не торопились: с Icehouse работали примерно год, Neutron наконец-то перестал быть источником ежедневных сюрпризов, и обновляться без веской причины не хотелось. Веской причиной оказался Heat: в Kilo его переработали достаточно серьёзно чтобы возникло желание попробовать то, что откладывали с прошлого года.

Что обновлялось и как

Тестовый кластер - те же три узла что и в пилоте на Icehouse: контроллер, сетевой узел, один compute. CentOS 7, RDO-пакеты. Решили не обновлять поверх Icehouse, а поднять рядом чистую установку - у нас не было ВМ которые нельзя было бы воспроизвести, а чистая установка снимает вопросы про мигрировавшие артефакты конфигурации.

Через packstack за пару часов получили рабочий кластер. Neutron с OVS, Nova на KVM, Cinder на LVM - стандартная конфигурация которую мы уже знаем наизусть. Horizon поднялся, ВМ из образа создаётся, floating IP назначается - база работает.

Из заметных изменений в самом OpenStack: Keystone v3 по умолчанию вместо v2, некоторые nova CLI-команды изменили ключи. Пришлось поправить пару скриптов. Ничего критичного, но полчаса потратили.

Heat: от «пощупали и закрыли» до «это работает»

В Icehouse мы написали один тестовый шаблон, убедились что Heat stack-create запускается, и на этом остановились - практической задачи не было. В Kilo появилась задача: клиент на сопровождении периодически просит поднять тестовую копию своего окружения. До этого делали руками: создать ВМ, подключить тома, настроить сеть, записать что куда - час работы инженера при хорошем раскладе.

Написали Heat-шаблон для типового стека: одна ВМ под приложение, одна под базу данных, виртуальная сеть, роутер с floating IP, Cinder-том к ВМ с базой. Шаблон занял около 150 строк YAML. Выглядит примерно так:

heat_template_version: 2015-04-30

parameters:
  image_id:
    type: string
    default: centos-7-base
  flavor:
    type: string
    default: m1.small

resources:
  app_network:
    type: OS::Neutron::Net

  app_subnet:
    type: OS::Neutron::Subnet
    properties:
      network_id: { get_resource: app_network }
      cidr: 192.168.100.0/24
      dns_nameservers: [77.88.8.8]

  app_server:
    type: OS::Nova::Server
    properties:
      image: { get_param: image_id }
      flavor: { get_param: flavor }
      networks:
        - network: { get_resource: app_network }

heat stack-create -f stack.yaml test-env - через минуту среда готова. heat stack-delete test-env - через минуту убрана. Это меняет то как вообще воспринимаешь тестовую инфраструктуру: она перестаёт быть чем-то что «поднял и оставил висеть», потому что возиться с удалением лень.

Что реально помогло в Kilo

В Kilo Heat получил OS::Heat::AutoScalingGroup и улучшенную поддержку зависимостей между ресурсами. Но практически нас больше порадовало другое: ошибки в шаблонах стали читаемыми. В старых версиях Heat если шаблон падал с ошибкой - получали что-то невразумительное из стека Python. Теперь heat stack-show выдаёт конкретно какой ресурс не создался и почему. Это мелкая деталь, но она прямо влияет на то сколько времени уходит на отладку шаблона.

Ceilometer тоже немного улучшился по нагрузке - по крайней мере на нашем масштабе он больше не занимает треть CPU compute-узла при опросе пяти ВМ. Включили, оставили работать. MongoDB растёт, но терпимо.

Чего пока не хватает

Heat-шаблоны описывают инфраструктуру, но не конфигурацию внутри ВМ. Можно передать cloud-init скрипт через user_data - мы так и делаем для базовой установки пакетов и SSH-ключей. Но для полноценной настройки приложения всё равно нужен Ansible: после того как Heat поднял ВМ, Ansible-плейбук доводит её до рабочего состояния. Два инструмента, два уровня абстракции - немного неудобно, но логично: Heat отвечает за «какая инфраструктура», Ansible - за «что на ней запущено».

Второй момент: идемпотентность. Ansible можно запустить повторно на уже настроенном хосте - он проверит что всё на месте и ничего не сломает. Heat stack-update работает иначе: он вычисляет diff между старым и новым шаблоном и применяет изменения, но если что-то пошло не так - может оставить стек в промежуточном состоянии. Мы один раз словили такое при изменении параметров сети: стек завис в статусе UPDATE_IN_PROGRESS, пришлось разбираться вручную.

Где стоим сейчас

Тестовый кластер работает. Heat-шаблон для типового клиентского окружения написан и проверен - подъём занимает около трёх минут против часа вручную. Это не значит что всё идеально: шаблон покрывает только сетевую инфраструктуру и ВМ, дальше подхватывает Ansible.

На production для клиентских нагрузок OpenStack не переехал - клиентская инфраструктура пока живёт на VMware, и менять это без серьёзного обоснования никто не будет. Но тестовый кластер перестал быть «лабораторией для экспериментов» и стал инструментом для реальной задачи. Это уже что-то.