Отладка и валидация сложных инфраструктурных решений с помощью Vagrant (Евгений Синельников, OSSDEVCONF-2017)

Ссылки сюда (2) →

Короткая ссылка: 20170923P

Докладчик

Евгений Синельников

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

В случае сложных инфраструктурных решений из нескольких узлов, многократное соблюдение этого условия становится всё более трудоёмким. В этом докладе представлен один из эффективных сценариев отладки развёртывания и валидации конфигурации Active Directory на базе Samba с помощью механизма управления конфигурациями виртуальных машин Vagrant.

Видео

on youtube

Посмотрели доклад? Понравился? Напишите комментарий! Не согласны? Тем более напишите.

Презентация

Thesis

Отладка сложных клиент-серверных решений, которые для воспроизведения рабочих конфигураций требуют несколько вычислительных узлов, существенно упрощается при использовании современных средств виртуализации. Важной характеристикой таких средств, для задач отладки, является возможность автомати\-ческого создания, запуска, остановки и контроля за состоянием виртуальных машин с помощью команд внешнего управления средой виртуализации. В более широком виде такие возможности предоставляются специализированными средствами управления конфигурациями. Одним из таких средств является открытый проект Vagrant. В данной работе рассматривается вариант отладки рабочих станций и контроллеров домена для клиент-серверных решений на базе проекта Samba.

Для создания и конфигурирования виртуальной среды Vagrant поддерживает базовый набор встроенных средств виртуализации (VirtualBox, Hyper-V и Docker), который может быть расширен с помощью сторонних расширений:

$ gem list --remote ^vagrant- 
          | head -e vmware-fusion -e 'aws ' -e 'xenserver '
vagrant-aws (0.7.2)
vagrant-vmware-fusion (0.0.1)
vagrant-xenserver (0.0.14)
$ gem list --remote ^vagrant- | wc -l
507

Средства виртуализации в терминологии среды управления конфигурациями Vagrant называются «провайдерами» (Providers), а механизмы управления виртуаль\-ными машинами — «развёртывателями» (Provisioners). В качестве «развёртывате\-лей» Vagrant поддерживает Ansible, Chef, Puppet и Salt, а также копирование файлов (File) и запуск скриптов через SSH и WinRM (Shell).

Для настройки виртуальных машин, прежде всего настроек сети, Vagrant поддержи\-вает определение различных Linux дистрибутивов. Начиная с версии 2.0.0 в него включена поддержка определения дистрибутивов ALT и настройка etcnet, включая возможность задания имени хоста, маски подсети в CIDR{}-нотации и управления через NetworkManager. Минимальный вариант рабочей конфигурации (Vagrantfile) с двумя видами сетевых интерфейсов выглядит следующим образом:

<code-ruby> Vagrant.configure("2") do |config|

 config.vm.box = "mastersin/basealt-p8-server-systemd"
 config.vm.network "private_network", ip: "192.168.2.2", 
                       netmask: "24", gateway: "192.168.2.1"
 config.vm.network "public_network", nm_controlled: "yes"
 config.vm.hostname = "example.com"

end </code-ruby>

Стенд для отладки Samba

Основная задача отладки Samba состояла в том, чтобы в заданном наборе дистрибу\-тивных решений ALT (как серверных, так и клиентских) иметь возможность сказать:

• какие механизмы, необходимые для развёртывания инфраструктуры Active Directory работают, а какие требуют

доработки;

• какие службы, «из коробки», сконфигурированы корректно, а какие требуют дополнительного конфигурирования;
• какое пакетное окружение влияет на работоспособность базовых сценариев развёртывания и для каких дистрибутивных

решений оно специфично;

• какой порядок действий подходит для заданного пакетного окружения, а какой требует уточнения.

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

• статическая настройка сетевых интерфейсов в /etc/net/ifaces/$IFACE/;
• настройка DNS в /etc/net/ifaces/$IFACE/resolv.conf;
• настройка Kerberos в /etc/krb5.conf;
• настройка Samba в /etc/samba/smb.conf;
• комплексная настройка аутентификации PAM \\ (/etc/pam.d/system-auth) и авторизации NSS\\

(/etc/nsswitch.conf) через SSS (/etc/sssd/sssd.conf) с помощью встроенной утилиты system-auth.

Для отладки дистрибутивных решений было подготовлено три виртуальных образа или, в терминологии Vagrant, «бокса» (Box) ([2]):

• mastersin/basealt-p8-server — сервер на базе SysVinit.
• mastersin/basealt-p8-server-systemd — сервер на базе Systemd.
• mastersin/basealt-p8-workstation — клиент на базе Systemd и NetworkManager.

Минимальный сценарий отладки (Рис. \ref{sin:ref0}) строился на использовании одного и того же «серверного бокса» как для сервера (контроллера домена), так и для клиента (рабочей станции в домене Samba). Сначала для образов на базе SysVinit, а затем для образов на базе Systemd. Последним в цепочку отладки был добавлен «клиентский бокс» на основе минимального дистрибутива Альт Рабочая станция.

На текущий момент с помощью рассмотренного подхода выявлена и оперативно исправлена ошибка некорректных путей к модулям ldb (ALT\#33427). Стабильно воспроизводится проблема обновления DNS после подключения к домену:

==> client.domain.alt: DNS update failed: 
                                 NT_STATUS_INVALID_PARAMETER
==> client.domain.alt: 
                  Joined 'CLIENT' to dns domain 'domain.alt'
==> client.domain.alt: No DNS domain configured for client. 
                                Unable to perform DNS Update.
==> client.domain.alt: DNS update failed!
==> client.domain.alt: No DNS domain configured for . 
                                Unable to perform DNS Update.

Также, процесс отладки во время написания тезисов моего доклада позволил выявить проблему падения net ads join при наличии двух доменов в списке поиска локальных доменов (search) файла /etc/resolv.conf (SAMBA\#13022).

В связи с поддержкой дистрибутивов Альт и даже шире — любых дистрибутивов на базе Sisyphus в новых версиях Vagrant, предлагается более широкое использование рассмотренного сценария отладки для решения следующих задач:

• демонстрации воспроизводимых рабочих конфигураций желающим ознакомиться пользователям;
• выявления регрессий в процессе жизненного цикла дистрибутивных решений;
• последовательного внедрения во время отладки решений таких современных средств оркестрации, как Ansible, Chef и Puppet;
• непосредственного использования отладочного стенда для решения проблем разработки и отладки.

Примечания и ссылки

• Discuss on Facebook
• Discuss on VK

Plays:63   Comments:0