Skip to main content

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

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

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

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

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

Вот вы воздали ВМ в 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

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

2

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

3

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

4

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

5

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

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

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

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

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

 

 

Back to top