Практическая работа. Использование файлов спецификаций

Кратко:

Создание, обновление и удаление группы виртуальных машин (ВМ) с использованием Yandex Cloud CLI.
Создание группы ВМ требует создания файла-спецификации с описанием параметров и настроек.
Использование спецификаций - это первый шаг в освоении подхода Infrastructure as Code (IaC).
Создание группы ВМ включает настройку сети, идентификатора сервисного аккаунта, создание ВМ и настройку их параметров.
Для балансировщика нагрузки указывается целевая группа, к которой он будет привязан.
Обновление ОС на машинах группы выполняется постепенно, без увеличения общего числа машин.
Удаление машины из группы и удаление группы и балансировщика выполняются с помощью соответствующих команд.

Практическая работа. Использование файлов спецификаций

В этой практической работе вы создадите, обновите и удалите группу ВМ.

Вы уже убедились, что создать даже одну ВМ через yc непросто: нужно установить много разных параметров. Создание группы ВМ требует ещё больше параметров. Чтобы не указывать их все в командной строке, конфигурацию описывают в файле, который используют при создании группы. Такой файл называется спецификацией. Использование спецификаций — это первый шаг в освоении подхода Infrastructure as Code (IaC), который мы будем применять на следующих уроках.

Спецификации пишутся в разных форматах. Для группы ВМ используется язык YAML. Если вы не знакомы с ним — ничего страшного. В документации есть шаблоны спецификаций, и на первых порах вам будет достаточно лишь немного их изменять. Ниже мы разберём, как составлять спецификации.

Часть 1. Создание Instance Group

Для разворачивания группы ВМ потребуется сеть. Если сети ещё нет, создайте её.
Посмотрите информацию об имеющихся сетях.
```
yc vpc network list
```
Сохраните идентификатор сети, он понадобиться нам в дальнейшем.
По умолчанию все операции в Instance Groups выполняются от имени сервисного аккаунта c ролью editor на каталог. Если сервисного аккаунта нет, то тоже создайте его и назначьте эту роль.
Посмотрите информацию об имеющихся сервисных аккаунтах.
```
yc iam service-account list
```
Сохраните идентификатор сервисного аккаунта, он понадобится нам в дальнейшем.
Для создания группы необходимо подготовить её спецификацию. Создайте в любом текстовом редакторе файл с расширением yaml, например specification.yaml.

Обратите внимание: в формате YAML важны отступы слева. Даже если текст правильный, но отступы не соблюдены, при выполнении спецификации возникнут ошибки.

Сначала внесите информацию о группе. Пусть группа называется my-group. Укажите идентификатор сервисного аккаунта, от имени которого будете работать (см. шаг 2).

Идентификаторы ресурсов уникальны. Копируя команды из текста урока, не забывайте подставлять свои идентификаторы.

    name: my-group
    service_account_id: <идентификатор_сервисного_аккаунта>

Наша группа будет содержать три одинаковые ВМ. Машины создадим из публичного образа Ubuntu 18.04 LTS (возьмём не последнюю версию, чтобы потренироваться обновлять ВМ). Узнайте идентификатор образа с помощью команды:
```
yc compute image list --folder-id standard-images
```
В столбце FAMILY найдите ubuntu-1804-lts, в столбце ID будет указан нужный идентификатор.
Опишите в спецификации ВМ. Это раздел instance_template.
Пусть каждая машина использует платформу Intel Broadwell (посмотрите поддерживаемые платформы в документации Yandex Compute Cloud), имеет 2 Гб оперативной памяти и два процессорных ядра.
```
instance_template:
     platform_id: standard-v2
     resources_spec:
         memory: 2g
         cores: 2
```
Добавьте описание загрузочного диска. Он будет использоваться на чтение и запись (режим READ_WRITE). Укажите идентификатор образа, который получили на шаге 5. Выделите сетевой HDD объёмом 32 Гб.
```
     boot_disk_spec:
        mode: READ_WRITE
        disk_spec:
            image_id: <идентификатор_образа>
            type_id: network-hdd
            size: 32g 
```
Теперь опишите сеть: идентификатор сети из каталога по умолчанию (см. шаг 1). Задайте публичный IP-адрес, чтобы к ВМ можно было обращаться извне.
```
     network_interface_specs:
         - network_id: <идентификатор_сети>
           primary_v4_address_spec: { one_to_one_nat_spec: { ip_version: IPV4 }} 
```
В политике планирования укажите, что машина не прерываемая.
```
     scheduling_policy:
         preemptible: false 
```
В политике развертывания (раздел deploy policy) укажите, что в каждый момент времени может быть неработоспособной только одна машина, не больше. Запретите увеличивать число ВМ, т. е. создавать больше трех машин одновременно. Мы чуть подробнее разберём эти настройки, когда будем обновлять ВМ в группе.
```
     deploy_policy:
         max_unavailable: 1
         max_expansion: 0 
```
Мы создаем группу фиксированного размера из трёх ВМ. Укажите это в политике масштабирования (раздел scale_policy):
```
    scale_policy:
        fixed_scale:
        size: 3 
```
Наконец, в политике распределения машин по зонам (раздел allocation_policy) укажите, что будет использоваться зона ru-central1-a. Мы делаем это для простоты. Лучше распределять ВМ группы по разным зонам доступности — это позволит пережить краткие сбои или выход зоны из строя.
```
    allocation_policy:
        zones:
            - zone_id: ru-central1-a 
```
Для балансировщика нагрузки (раздел load_balancer_spec) укажите целевую группу, к которой он будет привязан (это мы рассмотрим чуть ниже).
```
    load_balancer_spec:
        target_group_spec:
        name: my-target-group 
```
Нашей спецификации уже достаточно, чтобы создать группу ВМ. Но на эти машины не будет установлено никакого ПО, только операционная система из публичного образа. Если не менять конфигурацию, то после создания ВМ вам придётся устанавливать программы вручную.

Чтобы сэкономить время и сократить число ошибок, давайте максимально автоматизируем создание ВМ, включая установку ПО. Для этого добавим в конфигурацию машины секцию, где будут вызываться команды установки программ. В этой же секции можно описать создание пользователей, но мы этого делать не будем, так как заходить на ВМ не планируем.

Установим на машины веб-сервер NGINX и на веб-странице index.nginx-debian.html, которая создается по умолчанию и выводит приветственное сообщение «Welcome to nginx», заменим слово nginx идентификатором активной ВМ и версией ОС. Поскольку мы подключим балансировщик нагрузки, идентификатор активной ВМ будет различаться для разных пользователей. Это и позволит нам убедиться в том, что балансировщик работает.

Для установки ПО используйте cloud-init — пакет, выполняющий команды на ВМ при первом запуске. Вы узнали о нём из курса о ВМ. Команды опишите в блоке конфигурации #cloud-config. Примеры команд смотрите в документации cloud-init.
Содержимое #cloud-config описывается в разделе instance_template в секции metadata:
```
    metadata:
      user-data: |-
        #cloud-config
          package_update: true
          runcmd:
            - [apt-get, install, -y, nginx ]
            - [/bin/bash, -c, 'source /etc/lsb-release; sed -i "s/Welcome to nginx/It is $(hostname) on $DISTRIB_DESCRIPTION/" /var/www/html/index.nginx-debian.html'] 
```

Спецификация готова. Вот ее полный текст. Помните, что в формате YAML важно соблюдать отступы слева.

name: my-group
service_account_id: ajeu495h1s9tn1rorulb
 
instance_template:
    platform_id: standard-v1
    resources_spec:
        memory: 2g
        cores: 2
    boot_disk_spec:
        mode: READ_WRITE
        disk_spec:
            image_id: fd8fosbegvnhj5haiuoq 
            type_id: network-hdd
            size: 32g
    network_interface_specs:
        - network_id: enpnr4onfs6ihtoao32u
          primary_v4_address_spec: { one_to_one_nat_spec: { ip_version: IPV4 }}
    scheduling_policy:
        preemptible: false
    metadata:
      user-data: |-
        #cloud-config
          package_update: true
          runcmd:
            - [ apt-get, install, -y, nginx ]
            - [/bin/bash, -c, 'source /etc/lsb-release; sed -i "s/Welcome to nginx/It is $(hostname) on $DISTRIB_DESCRIPTION/" /var/www/html/index.nginx-debian.html']
 
deploy_policy:
    max_unavailable: 1
    max_expansion: 0
scale_policy:
    fixed_scale:
        size: 3
allocation_policy:
    zones:
        - zone_id: ru-central1-a
 
load_balancer_spec:
    target_group_spec:
        name: my-target-group

Теперь создайте группу ВМ по подготовленной спецификации. Уточните синтаксис команды сами:

yc compute instance-group --help

Проверить синтаксис команды
yc compute instance-group create --file <путь_к_файлу_specification.yaml>

Для тренировки можете вызвать эту команду в асинхронном режиме, а затем проверить её статус и дождаться завершения.

Убедитесь, что группа создана, в веб-консоли или выведя список групп с помощью yc.

yc compute instance-group list

В списке вы должны увидеть свою группу машин my-group:

 
+----------------------+------------+------+
|          ID          |    NAME    | SIZE |
+----------------------+------------+------+
| amc65sbgfqeqf00m02sc | my-group   |    3 |
+----------------------+------------+------+

Часть 2. Балансировщик

Создайте балансировщик my-load-balancer. Посмотрите, какие параметры должны быть у соответствующей команды:
```
yc load-balancer network-load-balancer create --help
```
В выводе справки обратите внимание, что при создании балансировщика можно сразу создать и обработчик входящего трафика (параметр --listener).
Формат параметра --listener достаточно хитрый: в нём можно указать сразу несколько подпараметров через запятую:
```
...
--listener name=my-listener,external-ip-version=ipv4,port=80
...
```
Помимо имени обработчика, здесь указывается версия IP-протокола и порт, на котором балансировщик будет принимать трафик.

Проверить синтаксис команды

yc load-balancer network-load-balancer create \
  --region-id ru-central1 \
  --name my-load-balancer \
  --listener name=my-listener,external-ip-version=ipv4,port=80

Затем подключите к балансировщику целевую группу (команда attach-target-group). Вам понадобится идентификатор целевой группы. Чтобы узнать его, запросите с помощью yc список доступных целевых групп и выберите ту, которую вы указали в спецификации specification.yaml.

Проверить синтаксис команды

yc load-balancer target-group list

Целевая группа также подключается с помощью нескольких подпараметров, которые соответствуют настройкам в консоли управления (их вы изучали на первом курсе). Для целевой группы укажите такие параметры:

target-group-id — идентификатор группы;
healthcheck-name, healthcheck-interval, healthcheck-timeout, healthcheck-unhealthythreshold, healthcheck-healthythreshold, healthcheck-http-port — параметры проверки состояния (см. документацию). Эти параметры аналогичны тем, что задаются в консоли управления при создании балансировщика. Вы изучали их в первом курсе.

Укажите 80-й порт, на котором запущен NGINX.

Проверить синтаксис команды

yc load-balancer network-load-balancer attach-target-group my-load-balancer \
  --target-group target-group-id=<идентификатор целевой группы>,healthcheck-name=test-health-check,healthcheck-interval=2s,healthcheck-timeout=1s,healthcheck-unhealthythreshold=2,healthcheck-healthythreshold=2,healthcheck-http-port=80

Можно не выполнять две команды (создание балансировщика и подключение целевой группы) по очереди, а одной командой create создать балансировщик с привязанной целевой группой.

Убедитесь, что балансировщик создан, а целевая группа подключена через консоль управления или с помощью yc.

Часть 3. Доступ к машинам группы

Проверьте состояние машин группы. Для этого запросите список машин и дождитесь статуса HEALTHY.
```
yc load-balancer network-load-balancer target-states my-load-balancer \
    --target-group-id <идентификатор_целевой_группы>
```
Теперь откройте в браузере страницу балансировщика. IP-адрес балансировщика вы можете узнать с помощью консоли управления или yc.

На странице вы увидите приветственное сообщение и в нём идентификатор одной из машин.

Часть 4. Обновление Instance Group

При создании на ВМ группы была установлена ОС Ubuntu 18.04 LTS. Теперь обновите её до Ubuntu 20.04 LTS (ubuntu-2004-lts в столбце FAMILY). Ещё раз посмотрите список доступных образов (см. часть 1) и в файле спецификации specification.yaml измените параметр image_id.
```
...
boot_disk_spec:
   mode: READ_WRITE
   disk_spec:
       image_id: <идентификатор_образа>
       type_id: network-hdd
       size: 32g
...
```
Теперь запустите обновление группы с изменённым файлом спецификации.

Проверить синтаксис команды

yc compute instance-group update \
  --id <instance_group_id> \
  --file <путь_к_файлу_specification.yaml>

Группа будет обновляться постепенно: когда одна машина из группы удаляется, ей на замену создаётся новая. Общее число машин в группе не увеличится. Именно такую политику обновления мы задали в файле спецификации (см. часть 1):

...
deploy_policy:
    max_unavailable: 1
    max_expansion: 0
...

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

...
deploy_policy:
    max_unavailable: 0
    max_expansion: 1
...

Убедитесь, что машины обновились. На приветственной странице должна выводиться новая версия ОС.

Часть 5. Удаление машины из группы

На приветственной странице балансировщика посмотрите имя активной машины и попробуйте удалить ее. Убедитесь, что приветственная страница остаётся доступна всё время: балансировщик переключит трафик на другую машину группы. А Yandex Cloud тем временем пересоздаст удалённую машину.

Проверить синтаксис команды

yc compute instance delete <имя_ВМ>

Часть 6. Удаление Instance Group

Теперь удалите группу и балансировщик командами yc.

Проверить синтаксис команд

yc compute instance-group delete --name my-group
 
yc load-balancer network-load-balancer delete --name my-load-balancer

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

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

В этой теме вы узнали принцип работы с интерфейсом командной строки Yandex Cloud, а также начали осваивать использование файлов-спецификаций для описания IT-инфраструктуры.

Дальше мы продолжим применять подход Infrastructure as Code и посмотрим, как оптимизировать создание ВМ.

: Категория: Cloud Services Engineer; Просмотров: 762

CLI. ПР. Использование файлов спецификаций

Практическая работа. Использование файлов спецификаций

Практическая работа. Использование файлов спецификаций

Часть 1. Создание Instance Group

Часть 2. Балансировщик

Часть 3. Доступ к машинам группы

Часть 4. Обновление Instance Group

Часть 5. Удаление машины из группы

Часть 6. Удаление Instance Group