6.7 Автоматическое конфигурирование ОС и оркестрация¶

User-data – блок данных, который пользователь может указать при запуске ВМ. ВМ может получить доступ к этим данным через службу метаданных или диск конфигурации. Обычно user-data используется для передачи сценария оболочки, запускаемого экземпляром при загрузке.

Например, одним из приложений, использующих пользовательские данные, является cloud-init – пакет с открытым исходным кодом, доступный в различных дистрибутивах Linux и других ОС. Он обеспечивает раннюю инициализацию ВМ в облачной платформе.

Примечание.

Ознакомиться со списком доступных модулей cloud-init можно по ссылке.

Детальное описание API сервиса оркестрации (OpenStack Heat) можно посмотреть по ссылке.

6.7.1 Использование user-data при ручном создании ВМ¶

ВАЖНО.

Должны использоваться только подготовленные облачные образы с установленным cloud-init. Информацию и подготовке облачных образов можно получить из документа Руководство по миграции инфраструктуры или перейдите по ссылке.

Примечание.

Файл формата YAML критичен к отступам текста при описании параметров.

Рекомендуется использовать отступ в 4 пробела относительно объявления группы.

Доступно несколько вариантов передачи user-data ВМ:

Помещение user-data в локальный файл и передача через параметр „-user-data <user-data-file>“, при создании ВМ с помощью CLI:
```
openstack server create --image cloudimage --flavor flavor-1 \
--key-name key1 --nic net-id=external --user-data user-data.yaml VM_INSTANCE
```

где:

cloudimage – наименование образа системы;

flavor-1 – тип инстанса;

user-data.yaml – файл с user-data в формате YAML;

VM_INSTANCE – наименование создаваемой ВМ;

net-id=external – наименование подключаемой сети;

key1 – наименование ключевой пары.

При использовании Dashboard можно передать user-data через поле «Сценарий настройки», поместив содержание файла с user-data в формате YAML (Рис. 6.47).

Рис. 6.47 Передача user-data через поле «Сценарий настройки»

6.7.1.1 Использование скриптов в user-data¶

С помощью user-data также можно передавать скрипты для выполнения в ВМ. Перед началом скрипта введите директиву, определяющую оболочку выполнения, руководствуясь данными таблицы, см.(Таблица 6.5).

Таблица 6.5 Описание скриптов¶
Оболочка выполнения	Директива	Описание
CMD	rem cmd	Будет выполнен cmd.exe скрипт
PowerShell	#ps1 или #ps1_sysnative	Будет выполнен powershell скрипт для Windows 64bit
	#ps1_x86	Будет выполнен powershell скрипт для Windows 32bit
Bash	#!/bin/bash	Будет выполнен bash скрипт
Python	#!/usr/bin/env python	Будет выполнен python скрипт

Пример для скрипта Bash:

#!/bin/bash
hostnamectl set-hostname control1
timedatectl set-timezone Europe/Moscow
echo "nameserver 8.8.8.8" > /etc/resolv.conf
apt-get update
apt-get upgrade

6.7.1.2 Установка пароля пользователю¶

Пример установки пароля пользователю для Linux:

#cloud-config
groups:
    - cloud-group
users:
    - default
    - name: cloud-user
      primary_group: cloud-user
      groups: wheel
      lock_passwd: false
      plain_text_passwd: 45697845

где:

45697845 – пароль; cloud-user – имя пользователя.

Пример установки пароля пользователю для Windows:

#ps1_sysnative
$password=convertto-securestring "45697845" -asplaintext -force
New-LocalUser "cloud-user" -Password $password
Add-LocalGroupMember -SID "S-1-5-32-544" -Member "cloud-user"
Restart-Computer

6.7.1.2.1 Примеры часто используемых операций¶

Настройка временной зоны в системе:

#cloud-config
timezone: Europe/Moscow

Просмотр списка доступных временных зон из консоли:

timedatectl list-timezones

Установка пакета ansible:

#cloud-config
packages:
    - ansible

Установка пакета chronyd, запуск сервиса и добавление в автозагрузку:

#cloud-config
packages:
  - chronyd
runcmd:
  - [ systemctl, daemon-reload ]
  - [ systemctl, enable, chronyd.service ]
  - [ systemctl, start, chronyd.service ]

6.7.2 Использование встроенного оркестратора Heat¶

Heat – сервис оркестрации составных облачных приложений с использованием шаблона через собственный REST API OpenStack. Heat обеспечивает оркестровку на основе шаблонов путем выполнения соответствующих вызовов API для запуска ВМ в среде OpenStack.

Шаблоны Heat описывают инфраструктуру в текстовых файлах, которые удобно корректировать под конкретные задачи, и которыми можно управлять с помощью инструментов контроля версий.

Шаблоны позволяют создавать различные типов ресурсов OpenStack (например, ВМ, плавающие IP-адреса, тома, группы безопасности, пользователей и т. д.).

ВАЖНО.

Программное обеспечение проекта Heat связано с другими компонентами OpenStack.

Одной из важных функций является возможность передачи user-data с помощью шаблонов сервиса Heat. Информацию по использованию user-data можно получить выше (Раздел 6.7.1).

6.7.2.1 Установка оркестратора Heat¶

Установка сервиса осуществляется с помощью плейбуков Ansible. О подготовке рабочего окружения можно прочитать в документе Инструкция по развертыванию.

Установка выполняется с помощью сценария deploy.yml с использованием тега „Heat“:

ansible-playbook deploy.yml -t heat -vv

Сервисы Openstack Heat:

openstack-heat-api
openstack-heat-api-cfn
openstack-heat-engine

Внимание.

В случае если в архитектуре используется менеджер ресурсов Pacemaker, рекомендуется добавить сервисы Heat в группу к остальным сервисам Openstack.

Пример команд для добавления сервисов в Pacemaker:
pcs resource create p_openstack-heat-api systemd:openstack-heat-api meta interleave=true --group pcs_os op monitor interval=15s
pcs resource create p_openstack-heat-api-cfn systemd:openstack-heat-api-cfn meta interleave=true --group pcs_os op monitor interval=15s
pcs resource create p_openstack-heat-engine systemd:openstack-heat-engine meta interleave=true --group pcs_os op monitor interval=15s

6.7.2.2 Структура шаблонов¶

Шаблоны оркестратора Heat имеют формат YAML и структуру, описанную ниже:

heat_template_version: 2016-10-14 – параметр, имеющий значение от 2013-05-23 (или более поздней даты), указывает, что документ YAML является шаблоном оркестратора Heat указанной версии;

description – раздел, в котором указывается описание шаблона;

Этот раздел является необязательным и при необходимости может быть пропущен.

parameter_groups – в этом разделе можно указать, как следует группировать входные параметры и в каком порядке вводить параметры;

Этот раздел является необязательным и при необходимости может быть пропущен.

parameters – в этом разделе можно указать входные параметры, которые должны быть заданы при обработке шаблона;

Этот раздел является необязательным и может быть пропущен, если ввод данных не требуется.

resources – в этом разделе задаются ресурсы, используемые при обработке шаблона;

Этот раздел является обязательным для любого шаблона.

outputs – этот раздел позволяет указать исходящие параметры, доступные пользователям после создания экземпляров шаблона;

Этот раздел является необязательным и может быть пропущен, если выходные значения не требуются.

conditions – раздел включает в себя условия, которые можно использовать как ограничения при создании ресурса или при определении свойств. Они могут быть связаны с ресурсами и свойствами ресурсов в разделе «Ресурсы», а также могут быть связаны с выходными данными в разделе «Выходные данные».

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

Примечание.

Полное описание функций и возможностей сервиса Heat можно получить тут.

ВАЖНО.

Наиболее подробную информацию можно узнать в дашборде:

по функциям определенной версии шаблона: во вкладке Оркестрация > Версии шаблонов

по типам ресурсов (атрибуты, свойства): во вкладке Оркестрация > Типы ресурсов.

6.7.2.3 Создание стека в OpenStack CLI¶

Для создания стека требуется выполнить следующую команду в OpenStack CLI:

openstack stack create -e <environment file name>  --parameter "<parameter>=<value>" -t  <template name> <stack name>

Например, для создания стека по шаблону basic-stack.yaml с названием basic-stack требуется выполнить команду:

openstack stack create -e env.yaml --parameter "server_image=cirros;server_network=external" -t basic-stack.yaml basic-stack

Данная команда возвращает вывод следующего вида:

+---------------------+--------------------------------------+
|        Field        |                 Value                |
+---------------------+--------------------------------------+
| id                  | 6be269ec-d22f-4cf0-bf04-df71cc6dcf75 |
| stack_name          | basic-stack                          |
| description         | No description                       |
| creation_time       | 2021-011-12T15:58:20Z                |
| updated_time        | None                                 |
| stack_status        | CREATE_IN_PROGRESS                   |
| stack_status_reason | Stack CREATE started                 |
+---------------------+--------------------------------------+

Для удобства можно использовать bash-скрипт, запускающий создание стека:

#!/bin/bash
set -e
### deploy instance
openstack stack create CIRROS \
--template cirros.yaml \
--parameter server_name=cirros-server \
--parameter server_network=external \
--parameter server_image=cirros \
--parameter server_flavor=1x1x0 \
--parameter key_name=key-1

6.7.2.4 Создание стека в Dashboard¶

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

Перейти: Проект >> Оркестрация >> Стеки (Рис. 6.48).

Рис. 6.48 Стеки

Нажать на кнопку Запустить стек (Рис. 6.49).

Рис. 6.49 Выбор шаблона

Выбрать источник шаблона и источник среды:

Доступные источники шаблона:

Файл;

Непосредственный ввод;

Адрес.

Доступные источники среды:

Файл;

Непосредственный ввод.

Рис. 6.50 Запуск стека

Ввести дополнительные параметры (Рис. 6.50).

Дополнительные параметры:

Имя стека;

Таймаут создания стека;

Определение разрешения на откат при сбое процесса создания или обновления;

Пароль для пользователя с учетной записью Admin (требуется для выполнения операций в жизненном цикле стека);

Дополнительные переменные, определяемые шаблоном, например NetID.

После успешного создания стека осуществится переход на страницу топологии данного стека (Рис. 6.51).

Рис. 6.51 Страница топологии стека

6.7.2.5 Примеры шаблонов¶

Образец самого простого шаблона может содержать только определение ресурсов с использованием только предопределенных свойств (вместе с обязательным тегом версии шаблона Heat).

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

Минимальный шаблон создания ВМ:

heat_template_version: 2015-04-30

description: Simple template to deploy a single compute instance

resources:
    my_instance:
        type: OS::Nova::Server
        properties:
            key_name: my_key
            image: cirros
            flavor: m1.small
            networks:
                - network: external

Минимальный шаблон ВМ с использованием user-data:

heat_template_version: 2015-04-30
description: Simple template to deploy a single compute instance
resources:
    my_instance:
        type: OS::Nova::Server
        properties:
            key_name: my_key
            image: cirros
            flavor: m1.small
            networks:
                - network: external
            user_data: |
                #!/bin/sh
                echo "Hello, World!"
            user_data_format: RAW

Создание ВМ с Cinder диском и передачей user-data:

heat_template_version: 2013-05-23

description: An example Heat Orchestration Template (HOT).

parameters:

    key_name:
        type: string
        description: Name of a KeyPair to enable SSH access to the instance
        default: key1

    instance_type:
        type: string
        description: Instance type for deploy
        default: m1.medium

    image_id:
        type: string
        description: Name or ID of the image to use.
        default: cirros

    inst_vol_size:
        type: number
        description: The size of the Cinder volume Instance 1
        default: 20

    instance_name:
        type: string
        description: Instance name
        default: cirros1

resources:
    Instance:
        type: OS::Nova::Server
        properties:
            block_device_mapping: [{ device_name: "vda", volume_id : { get_resource: volume_root }, delete_on_termination : "true"}]
            name: { get_param: instance_name }
            flavor: { get_param: instance_type }
            key_name: { get_param: key_name
            networks:
                - network: external
            user_data: |
                #cloud-config
                timezone: Europe/Moscow
            user_data_format: RAW

    volume_root:
        type: OS::Cinder::Volume
        properties:
            image: { get_param: image_id }
            size: { get_param: inst_vol_size }

Создание ВМ c дополнительным cinder диском, монтируемым в :file:`/tmp` и передачей user-data:

heat_template_version: 2013-05-23

description: An example Heat Orchestration Template (HOT).

parameters:
    network:
        type: string
        description: Network
        default: 204a9ff6-14b1-40ea-a23d-f90b47cc0244

    key_name:
        type: string
        description: Name of a KeyPair to enable SSH access to the instance
        default: key1

    instance_type:
        type: string
        description: Instance type for deploy
        default: m1.medium

    image_id:
        type: string
        description: Name or ID of the image to use.
        default: cirros

    inst_vol_size:
        type: number
        description: The size of the Cinder volume Instance 1
        default: 20

    instance_name:
        type: string
        description: Instance name
        default: cirros1

resources:
    Instance:
        type: OS::Nova::Server
        properties:
            block_device_mapping_v2:
              - device_name: vda
                boot_index: 0
                volume_id : { get_resource: volume_root }
                delete_on_termination : true
              - device_name: vdb
                boot_index: 1
                volume_id : { get_resource: volume_tmp }
                delete_on_termination : true
            name: { get_param: instance_name }
            flavor: { get_param: instance_type }
            key_name: { get_param: key_name }
            networks:
                - network: { get_param: network }
            user_data: |
                #!/bin/sh
                apt-get update
                apt-get -y upgrade
                mkfs.ext4 /dev/vdb
                mount /dev/vdb /tmp
                user_data_format: RAW
    volume_root:
        type: OS::Cinder::Volume
        properties:
            image: { get_param: image_id }
            size: { get_param: inst_vol_size }

    volume_tmp:
        type: OS::Cinder::Volume
        properties:
            size: 10

6.7.2.6 Пример с разделением на разные файлы: шаблон, переменные и user-data¶

Команда для создания стека выглядит следующим образом:

openstack stack create -e env.yaml -t basic-stack.yaml basic-stack

Пример env.yaml:

parameters:
    network_id: external
    key_name: external
    instance_type: 4x4x0
    image_id: ubuntu-18.04-server-cloudimg-i386.img
    inst_vol_size: 20
    instance_name: default

Пример basic-stack.yaml:

.. literalincude:: basic-stack.yaml

Пример user-data.yaml:

#!/bin/bash
mkfs.ext4 /dev/vdb
mount /dev/vdb /tmp
apt-get update
apt-get -y upgrade

Table of Contents

Предыдущий раздел

Следующий раздел