Skip to main content

Этапы введения ВМ в эксплуатацию

Каждая новая ВМ при ее создании в PVE проходит ряд этапов:

  1. Описание для администратора:
    1. Обновление комплекса технических средств (таблица КТС) в NextCloud - она доступна тут);
    2. Обновление инфраструктурной схемы.
  2. Настройка окружения:
    1. Прогон скрипта для автоматической настройки хоста;
    2. Регистрация ее в NetBox;
    3. Сохранение секретов в Hashicorp Vault (даже в случае, если автоматизация в любой форме к ней не применима);
    4. Создание A-записи в доменной зоне DNS (на домен-контроллере);
    5. Проверка работоспособности.
  3. Добавление ВМ в мониторинг;

Рассмотрим каждый из этих этапов отдельно.

Описание для администратора

Первым делом, до или после заведения ВМ, необходимо обновить комплекс технических средств (таблица КТС). Она доступна как локально, так и тут, в NextCloud. Вносить хост можно по аналогии с уже существующими записями - за все время существования проекта это - наиболее оптимальный формат, к которому я пришел через пробы и ошибки.  

После чего нужно обновить инфраструктурную схему на сайте. Она существует в репозитории самого сайта, но туда попадает только конечный вариант в формате SVG: 

  1. Схема редактируется через DrawIO локально;
  2. Она обезличивается (удаляются IP-адреса, которые определены в WAN);
  3. После чего схема экспортируется в формате SVG и загружается в репозиторий GitLab.

Обновление структуры сайта (в том числе, схемы) - автоматический процесс. Достаточно только коммита/Pull-Request в ветку Main, а все остальное сделает пайплайн Gitlab-CI.

Делается это по той же причине, по которой заполняется таблица КТС. Такой подход позволяет понимать что и где расположено, а так же, быстрее решать проблемы инфраструктуры в случае чего. 

По сути, это полноценный релизный процесс, только здесь публикуется не ПО или сервис, а сама ВМ.

Скрипт для автоматической настройки ВМ

Вот вы воздали ВМ в PVE и подключились к ней по SSH. Что дальше?

А дальше - первичная настройка. Это первый шаг настройки любой ВМ в моей инфраструктуре. И он он включает в себя несколько этапов:

  1. Синхронизация времени
  2. Установка последних обновлений пакетов 
  3. Настройка SSH:
    1. Генерация пары из открытого и закрытого ключа
    2. Настройка основного конфигурационного файла SSHD
    3. Применение изменений   
  4. Расположение TLS-сертификатов для веб-сервера (даже если они не будут использоваться на этом хосте) и применение прав доступа к ним
  5. Установка набора ПО по-умолчанию

Все эти этапы можно выполнить вручную, но у любого администратора с таким кол-вом сервисов быстро задергается глаз. Особенно с учетом того, что эти действия иногда приходится выполнять ни один раз. Поэтому для этого действия существует скрипт, который прогоняет все необходимые этапы автоматически. Его достаточно просто скопировать и выполнить на хосте.

И да, этот скрипт не будет тут указан, потому что он хранит некоторую конфиденциальную информацию. Например, листинг конфигурационного файла SSHD. Где он расположен знает только администратор и лишь ему позволен доступ к нему.

NetBox и реестр служб 

Зачем он нужен? В моей инфраструктуре принят принцип описания каждого нового хоста (ВМ), которая вводится в эксплуатацию. Для этого я поднял сервис, который называется NetBox. Он доступен по по адресу netbox.elijahkamsky.ru.

Его задача - хранить описание всех ВМ, чтобы отвечать на вопросы:

  1. Что это за ВМ?
  2. Какие у нее параметры?
  3. Где она находится и к чему принадлежит?
  4. Зачем она нужна?
  5.  С какими сервисами она связана?
  6. Какая у нее критичность?

Все эти вопросы берет на себя NetBox. У описанной ВМ есть:

  1. Название
  2. Список сетевых интерфейсов и IP-адреса
  3. Серийный номер
  4. Домен
  5. Описание
  6. Ресурсная конфигурация
  7. Роль
  8. Расположение
  9. Владелец
  10. Теги (как раз они используются в сценариях автоматизации)
  11. Принадлежность к кластеру и/или группе служб
  12. Статус активности хоста в данный момент

Конкретно по статусу активности хосты. Заполняется в т.ч. и информация о его запуске при перезагрузке ноды PVE. Делается это потому, что некоторые хосты описаны, но еще не были введены в эксплуатацию, а некоторые используются ситуативно и поэтому запускаются вручную.

image.png

Домен-контроллер

Для каждой ВМ так же создаются A-записи на домен-контроллере (MS-AD). DNS-сервер, который на нем расположен, содержит полный список имен серверов, включая те, которые только запланированы, но еще не были введены. У ВМ этом может быть много доменов, но каждый из них там перечислен.

Хост может быть определен сразу в нескольких доменных зонах, если он имеет там IP-адрес. Например, такие записи имеет хост home-admin-ntopng.

Например, у меня есть приложение home-srv-jitsi01 с адресом 10.10.10.22. Вдобавок, оно является публичным сервисом, доступно в WAN. Поэтому оно будет иметь наиболее полный список DNS-записей (за исключением, почтового сервера - но то скорее частный случай). Конкретно в этом случае, список DNS-записей на DC будет выглядеть примерно так:

Значение A-записи Доменная зона IP-адрес Описание
home-srv-jitsi01 homeserver.ru 10.10.10.22 Полное наименование хоста в этой доменной зоне
jitsi01 homeserver.ru 10.10.10.22 Короткое наименование хоста в этой доменной зоне. Другие сервисы часто используют именно его
jisti homeserver.ru 10.10.10.22 Единая точка доступа к сервису указывающая на хост в LAN
jisti elijahkamsky.ru [WAN-IP] Единая точка доступа к сервису указывающая на хост в WAN

Конкретно для зоны elijahkamsky.ru настроено делегирование на DNS-сервер провайдера, потому что приоритетным DNS-сервером для ВМ обычно является внутренний домен-контроллер, но он может не хранить какие-то записи, которые уже есть на сервере провайдера.

Hashicorp Vault и секреты приложений

После того, как хост занесен в NetBox и настроены DNS-записи, нужно описать секреты, которые к нему относятся. Как минимум, для каждого хоста это настройки подключения к нему по SSH.

Да, в идеале на любой хост после его развертывания можно попасть только имея SSH-ключ. Я уже упоминал это, когда говорил про скрипт для автоматической настройки хоста.

Hashicorp Vault расположен по адресу vault.elijahkamsky.ru и имеет свою структуру секретов. Но общепринятый путь к хранению секретов там один - Secrets/ssh-secret/ssh/hosts. В этой директории расположены секреты для конкретных хостов. Из прошлого примера, файл назывался бы home-srv-jitsi01.

А теперь к его содержимому. Каждый хост имеет минимум эти поля:

Номер Название поля (строго как тут) Описание

1

 name Hostname ВМ. Это поле часто используется в различных пайплайнах, и именно поэтому шаг с настройкой DNS на домен-контроллере крайне важен 

2

 host IP-адрес хоста. Тут больше для информации и как резервный путь доступа к хосту

3

 port Порт для подключения по SSH. Да, обычно он не меняется, но порой порт отличается от значения по-умолчанию. Как раз это поле уточняет связанным системам наличие нюанса 

4

 username Имя пользователя для подключения к хосту по SSH

5

 private_key SSH-ключ, который используется для подключения к ВМ

Помимо этих полей там может храниться еще что-то - тут все зависит уже от конкретного назначения ВМ.

Каждое поле из указанных обязательно должно быть заполнено! Без этого не будет работать часть автоматических задач, включая обновление ВМ и синхронизации, а так же не будет возможности в целом подключить ВМ к пайплайнам в Jenkins 

Проверка работоспособности

Как проверить, что все работает правильно?

По сути, единственное что реально влияет на работу системы - это NetBox и Vault. Остальное - исключительно удобство администратора. Поэтому проверку можно проводить сразу, как только эти 2 шага выполнены. И ответ на вопрос прост: вот этот Jenkins-pipeline, который это верифицирует.

Настройки пайплайна включают только сам хост (или хосты). Укажите их в списке хостов и запустите пайплайн. 

В логах вы увидите явный вывод: верно ли вы настроили систему. При наличии проблем, по выводу так же можно понять, что именно и почему не заработало. Первостепенная задача администратора - сделать так, чтобы пайплайн завершился без ошибок на новом хосте. 

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

Добавление ВМ в мониторинг 

Back to top