Этапы введения ВМ в эксплуатацию
Каждая новая ВМ при ее создании в PVE проходит ряд этапов:
- Описание для администратора:
- Обновление комплекса технических средств (таблица КТС) в NextCloud - она доступна тут); // Выгрузить КТС в NextCloud
- Обновление инфраструктурной схемы.
- Настройка окружения:
- Прогон скрипта для автоматической настройки хоста;
- Регистрация ее в NetBox;
- Сохранение секретов в Hashicorp Vault (даже в случае, если автоматизация в любой форме к ней не применима);
- Создание A-записи в доменной зоне DNS (на домен-контроллере);
- Проверка работоспособности. // Настроить пайплайн
- Добавление ВМ в мониторинг. // Настроить пайплайн
Рассмотрим каждый из этих этапов отдельно.
Описание для администратора
Первым делом, до или после заведения ВМ, необходимо обновить комплекс технических средств (таблица КТС). Она доступна как локально, так и тут, в NextCloud. Вносить хост можно по аналогии с уже существующими записями - за все время существования проекта это - наиболее оптимальный формат, к которому я пришел через пробы и ошибки.
После чего нужно обновить инфраструктурную схему на сайте. Она существует в репозитории самого сайта, но туда попадает только конечный вариант в формате SVG:
- Схема редактируется через DrawIO локально;
- Она обезличивается (удаляются IP-адреса, которые определены в WAN);
- После чего схема экспортируется в формате SVG и загружается в репозиторий GitLab.
Обновление структуры сайта (в том числе, схемы) - автоматический процесс. Достаточно только коммита/Pull-Request в ветку Main, а все остальное сделает пайплайн Gitlab-CI.
Делается это по той же причине, по которой заполняется таблица КТС. Такой подход позволяет понимать что и где расположено, а так же, быстрее решать проблемы инфраструктуры в случае чего.
По сути, это полноценный релизный процесс, только здесь публикуется не ПО или сервис, а сама ВМ.
Скрипт для автоматической настройки ВМ
Вот вы воздали ВМ в PVE и подключились к ней по SSH. Что дальше?
А дальше - первичная настройка. Это первый шаг настройки любой ВМ в моей инфраструктуре. И он он включает в себя несколько этапов:
- Синхронизация времени
- Установка последних обновлений пакетов
- Настройка SSH:
- Генерация пары из открытого и закрытого ключа
- Настройка основного конфигурационного файла SSHD
- Применение изменений
- Расположение TLS-сертификатов для веб-сервера (даже если они не будут использоваться на этом хосте) и применение прав доступа к ним
- Установка набора ПО по-умолчанию
Все эти этапы можно выполнить вручную, но у любого администратора с таким кол-вом сервисов быстро задергается глаз. Особенно с учетом того, что эти действия иногда приходится выполнять ни один раз. Поэтому для этого действия существует скрипт, который прогоняет все необходимые этапы автоматически. Его достаточно просто скопировать и выполнить на хосте.
И да, этот скрипт не будет тут указан, потому что он хранит некоторую конфиденциальную информацию. Например, листинг конфигурационного файла SSHD. Где он расположен знает только администратор и лишь ему позволен доступ к нему.
NetBox и реестр служб
Зачем он нужен? В моей инфраструктуре принят принцип описания каждого нового хоста (ВМ), которая вводится в эксплуатацию. Для этого я поднял сервис, который называется NetBox. Он доступен по по адресу netbox.elijahkamsky.ru.
Его задача - хранить описание всех ВМ, чтобы отвечать на вопросы:
- Что это за ВМ?
- Какие у нее параметры?
- Где она находится и к чему принадлежит?
- Зачем она нужна?
- С какими сервисами она связана?
- Какая у нее критичность?
Все эти вопросы берет на себя NetBox. У описанной ВМ есть:
- Название
- Список сетевых интерфейсов и IP-адреса
- Серийный номер
- Домен
- Описание
- Ресурсная конфигурация
- Роль
- Расположение
- Владелец
- Теги (как раз они используются в сценариях автоматизации)
- Принадлежность к кластеру и/или группе служб
- Статус активности хоста в данный момент
Конкретно по статусу активности хосты. Заполняется в т.ч. и информация о его запуске при перезагрузке ноды PVE. Делается это потому, что некоторые хосты описаны, но еще не были введены в эксплуатацию, а некоторые используются ситуативно и поэтому запускаются вручную.
Домен-контроллер
Для каждой ВМ так же создаются 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, который это верифицирует.
Настройки пайплайна включают только сам хост (или хосты). Укажите их в списке хостов и запустите пайплайн.
В логах вы увидите явный вывод: верно ли вы настроили систему. При наличии проблем, по выводу так же можно понять, что именно и почему не заработало. Первостепенная задача администратора - сделать так, чтобы пайплайн завершился без ошибок на новом хосте.
Стоит уточнить, что это идемпотентный пайплайн. Т.е. это пайплайн, который можно запускать сколько угодно раз с одинаковыми входными данными, и после первого успешного выполнения состояние системы больше не изменится.
Добавление ВМ в мониторинг
К этому шагу можно переходить только в случае, если пайплайн из предыдущего шага завершился успешно!
Если с предыдущими шагами проблем более не возникает, можно переходить к настройке мониторинга. Тут точно так же, как и в случае со скриптом автоматической настройки, есть свои стандарты. Минимум, что должно мониториться на каждом хосте - метрики самого хоста (ЦПУ / ОЗУ / Дисковое пространство и т.п.).
Конечно, вы можете сделать это вручную. Тут ничего сложного нет. И да, как вы могли догадаться, - и здесь тоже есть свой пайплайн. В очередной раз. И он тоже идемпотентен
Что конкретно он делает?
- Берет имя хоста, который требуется добавить в список мониторинга
- Проверяет, есть ли этот хост в мониторинге или нет
- Если хоста в мониторинге пока что не появлялось, он:
- Зайдет на хост и установит Prometheus-node-exporter;
- Добавит хост в цели для мониторинга Prometheus;
- Зальет обновленный конфиг в ветку этого репозитория (чтобы администратор мог удобно изменить его вручную).
- В противном случае вы получите предупреждение о том, что хост уже добавлен в мониторинг.
После чего, вы сможете проверить состояние хоста в системе мониторинга, в дашборде PNE 25.06.2026.
Метрики собираются автоматически, но аллертинг по утилизации ресурсов в этой схеме пока не предусмотрен!
Как настроить пайплайн?
Перед добавлением хоста нужно задать всего одну настройку - полный домен новой ВМ.
Помните пример с home-srv-jitsi01? Не просто так мы настраивали DNS-записи. В этом примере мы создавали A-запись в домене homeserver.ru, следовательно прописывать нам нужно именно home-srv-jitsi01.homeserver.ru.
Будьте внимательны! Прописывать полный и правильный домен здесь критически важно - от этого зависит качество мониторинга.
Пайплайн так же поддерживает добавления множества хостов - достаточно прописать их в соответствующем окне, по 1 на строку.