Puppet/Запуск puppetry (пример с libvirt)

Данная страница находится в разработке.
Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.

цель

Виртуальная сеть с виртуальными машинами для тестирования отработки манифестов puppet на подчинённых нодах с ALT-ом. Образы для таких виртуальных машин.

Помимо прочего на этой странице получилось своеобразное руководство к некоторым командам virt-* (для libvirt). Приветствуются исправления и дополнения к этому тексту (и пакетам и образам)!

Содержание

Нерешённые проблемы и задачи

Перечень нерешённых сейчас проблем и задач, решение которых нужно для успешного запуска ALT puppetry (кем угодно из сообщества по этой инструкции):

 описано как Выполнение манифеста на другой ноде. -- #Тестирование puppet Проверка и адаптация к ALT базовых средств, модулей puppet (пакетный менеджер в первую очередь, задействованный при работе некоторых других модулей). -- task #175947 test-only sisyphus ruby-facter.git=2.0.1-alt2 puppet.git=4.8.1-alt1 Подготовка образа для тестирования puppet.

И перечень задач, ради совместного решения которых пригодится ALT puppetry (к чему готовиться?):

Проверка и адаптация к ALT прочих модулей. Как эти наработки по адаптации интегрировать в экосистему puppet (upstream) и в ALT Sisyphus? Как гарантировать консистентность того, что записано в исходниках puppet и его модулей, и пакетов ALT Sisyphus?

Такой вопрос касается:

консистентности внутри ALT Sisyphus:
-- Все изменения для puppet и управляемых пакетов общего назначения полностью под контролем ALT, но как формализовать зависимости, проверки? ситуации когда к людям попадает upstream-ный puppet-мастер (крутящийся на какой угодно ОС), но часть подчинённых нод с ALT:
-- А может ли подчинённая нода хранить некоторые знания о своих особенностях (особенностях ALT) и влиять на выполняемые по заказу мастера действия, когда мастер не имеет информации обо всех особенностях ALT? Это бы позволило перенести достижения разработки в ALT Sisyphus на такой случай. предыдущей ситуации, суженной до конкретного специализированного дистрибутива с puppet-мастером и некоторым набором пакетов, рассчитанного на то, чтобы управлять подчинёнными нодами в т.ч. на ALT (с использованием пакетов из этого подготовленного набора).
-- Ввиду уже сформулированных общих вопросов про разработку и проверку внутри ALT Sisyphus и интеграцию с upstream-ным puppet-ом остаётся вопрос о том, как упростить создание (или адаптацию для ALT) таких дистрибутивов.

(Дополнительно к решению всех озвученных проблем в лоб, есть мысли обратиться к distrodb/distromap, чтобы "переводить" использование пакетов других дистрибутивов в пакеты ALT для стыковки с puppet-ом ALT-овых нод.)

Оформление инструкций в этом руководстве

Изменяемые (по вкусу каждого пользователя) параметры в примерах я старался выделять жирным, чтобы можно было их легко отличить от определённых не нами штук с жёстко заданными именами.

Создание сети

цель В сети у нас будет свой DNS (для обращения к puppet по имени), и для удобства -- свой DHCP-сервер. При этом хотелось бы сохранить возможность выхода в "интернет" (сеть хост-системы).

Такая сеть таким образом (как нам нужно) будет использоваться, когда машина будет создаваться virt-install --network network=puppettheatre (а не --network bridge=BRIDGE; см. man virt-install).

(BUG: Чтобы запустить такую сеть, как мы делаем, нужен /dev/net/tun. Его может не быть в системе без systemd (altbug 31718#c27). Появлется после загрузки модуля: modprobe tun или описанным действием, которого сейчас не хватает: /sbin/systemd-tmpfiles --prefix=/dev --create --boot.)

(удобно) КОМАНДОЙ

???

(неудобно) ВРУЧНУЮ через GUI virt-manager

(Использовался virt-manager-1.4.0-alt1.)

virt-manager > Edit > Connection Details > Virtual Networks

+ (Add Network)

Тип такой сети, как нам нужна, будет называться "Isolated Physical Network".

Параметры в итоге получаются такие:

Name puppettheatre Device some vibrNN Domain theatre (??? для чего используется? для чего важно?) Network e.g., 192.168.121.0/24

Gateway будет автоматически выставлен в 192.168.121.1; Static routing наверное, не нужно;

DHCP range Disabled Forwarding NAT

Создание машины с ALTовым puppet-мастером

(BUG altbug #33801: требуется установить qemu; по зависимостям libvirt-daemon-driver-qemu оно не вытягивается.)

(удобно) КОМАНДОЙ

???

(неудобно) ВРУЧНУЮ через GUI инсталлятора alterator через virt-viewer

(Использовался virt-viewer-5.0-alt1, virt-install-1.4.0-alt1, libvirt-1.3.2-alt1, а также более поздние версии.)

Пример:

Пример:

virt-install --virt-type kvm \
  --name imz-puppetry0-master-ALT \
  --memory 1024 --disk size=10 \
  --cdrom /space/iso/nightly/tested/regular-lxde-latest-x86_64.iso \
  --network network=puppettheatre \
  --os-variant altlinux7.0

--name imz-puppetry0-master-ALT -- какое-нибудь имя; regular-lxde-latest-x86_64.iso выбран как небольшой образ для инсталляции системы с systemd (сначала грузится LiveCD, что пока не важно, хотя есть планы тестировать puppet-мастер прямо с LiveCD); до исправления altbug #33334 рекомендуется использовать рабочий архивный образ /space/iso/nightly/archive/regular-tde-20170111-x86_64.iso, а после настройки доступа по ssh сделать apt-get dist-upgrade; --network network=... прокомментирован выше в #Создание сети; --os-variant altlinux7.0 просто выбран как самый свежий из известных ему ALTовых. (В man-странице из virt-install-1.4.0-alt1 и позже сказано посмотреть варианты командой osinfo-query os; оно из пакета libosinfo-1.0.0-alt1; раньше было немного по-другому.)

Запуск машины

См. #Запуск машин.

Конфигурация сети на машине

(Конфигурация сети на машине задаётся, конечно, вручную -- во время инсталляции или через alterator или привычным образом через конф.файлы.)

[user@puppet ~]$ tail /etc/sysconfig/network /etc/net/ifaces/eth0/*
==> /etc/sysconfig/network <==
# Used by hotplug/pcmcia/ifplugd scripts to detect current network config
# subsystem.
CONFMETHOD=etcnet

# Used by rc.sysinit to setup system hostname at boot.
HOSTNAME=puppet.localdomain

# This is used by ALTLinux ppp-common to decide if we want to install
# nameserver lines into /etc/resolv.conf or not.
RESOLV_MODS=yes

==> /etc/net/ifaces/eth0/ipv4address <==
192.168.121.2/24

==> /etc/net/ifaces/eth0/ipv4route <==
default via 192.168.121.1

==> /etc/net/ifaces/eth0/options <==
TYPE=eth
CONFIG_WIRELESS=no
BOOTPROTO=static
CONFIG_IPV4=yes

==> /etc/net/ifaces/eth0/resolv.conf <==
nameserver 10.4.0.1
[user@puppet ~]$ 

Здесь имя машины сделано puppet специально. IP-адрес назначен произвольно из доступного диапазона. (Один из адресов этой сети уже использован для шлюза -- хост-системы с гипервизором.) Т.к. в сети есть NAT для связи со внешним миром, мы можем использовать наш реальный DNS из внешнего мира. (Был прописан вручную, конечно.)

Удалим мешающееся для настройки сети:

apt-get remove NetworkManager

Напоследок включим sshd для входа по сети (правда, только с хост-системы, потому что IP нашей виртуальной машины за NAT.)

Общие добавочные костыли и плюшки в конфигурации

Добавочные "костыли" в конфигурации этой создаваемой ВРУЧНУЮ машины делаем ради удобства/быстроты получения уже чуточку сконфигурированных подчинённых машин как клонов.

TODO: Планируется реализовать эту добавочную конфигурацию более прозрачными, чем костыли, способами: сетевыми сервисами; внести всё потребовавшееся и описанное на этой странице в запланированный нами профиль для mkimage (образ VM/LiveCD для тестирования puppet в сети-песочнице -- "puppetry.img/.iso").

Скорее всего нам будет удобно ходить на эти машины по ssh, так что убедимся что sshd включен и настроен. (Остальные действия можно будет делать по ssh.)

Пусть клоны видят свой puppet-мастер по имени на фиксированном IP-адресе (этой машины):

echo '192.168.121.2 puppet' >>/etc/hosts

Можно поставить какие-то любимые пакеты сейчас, перед тем, как эта машина будет использована как исходник для клонирования; например:

apt-get update; apt-get install emacs25-X11-gtk3 emacs-misc-modes emacs-prog-modes slocate apt-printchanges telnet lsof moreutils
systemctl enable crond
updatedb

Для удобства положим технический SSH-ключ:

[root@vb ~]# rsync -avP ~/.ssh/id_rsa.pub user@192.168.121.2:.ssh/hypervisor-id_rsa.pub
[root@vb ~]# ssh user@192.168.121.2 'cat .ssh/hypervisor-id_rsa.pub >>.ssh/authorized_keys'
[root@vb ~]# ssh user@192.168.121.2 -t su -c "'cat ~user/.ssh/hypervisor-id_rsa.pub >>/root/.ssh/authorized_keys'"

Используем машину как исходник для клонирования

Прежде, чем что-то делать с машиной, используем её как исходник для клонирования и создания других (подчинённых) нод с ALT, чтобы не повторять инсталляцию вручную.

Думаю, удобно будет её сохранить в первоначальном виде и не трогать эту копию. (А копию уже использовать как исходник для всяких ALTовых нод.)

ssh user@192.168.121.2 -t su -c /sbin/poweroff; ping 192.168.121.2
virt-clone --original imz-puppetry0-master-ALT --auto-clone

Заметьте, что сеть будет использоваться та же самая -- как нам и нужно (для общения создаваемых нод между собой).^[1]

Для удобства будущей перенастройки новых клонов этого клона без выключения других машин (без коллизии с IP-адресом работающего puppet-мастера) я бы в клоне сразу поменял IP-адрес на некий выделенный временный, как это делается потом для всех рабочих подчинённых нод, например, 192.168.121.16:

[root@vb ~]# virsh start imz-puppetry0-master-ALT-clone
[root@vb ~]# ssh root@192.168.121.2
[root@puppet ~]# emacs /etc/net/ifaces/eth0/ipv4address 
[root@puppet ~]# cat /etc/net/ifaces/eth0/ipv4address 
192.168.121.16/24
[root@puppet ~]# poweroff

Создание подчинённой машины с ALTом

(удобно) КОМАНДОЙ

???

(неудобно) ВРУЧНУЮ: склонируем что-то; сконфигурируем

Для простоты склонируем созданную ВРУЧНУЮ машину; у нас уже заготовлена копия; её склонируем и сконфигурируем потом:

virt-clone --original imz-puppetry0-master-ALT-clone --name imz-puppetry0-slave0-ALT --auto-clone

Сконфигурируем сеть (пока исходник клона опущен), зайдя по ssh по старому IP-адресу:

[root@vb ~]# virsh start imz-puppetry0-slave0-ALT; ping 192.168.121.16
[root@vb ~]# ssh user@192.168.121.16
[user@puppet ~]$ su -
# emacs /etc/net/ifaces/eth0/ipv4address /etc/sysconfig/network 

Назначим новый IP-адрес и имя, убдимся, что по имени puppet мы можем обратиться к puppet-мастеру:

[root@puppet ~]# tail /etc/net/ifaces/eth0/ipv4address /etc/sysconfig/network /etc/hosts
==> /etc/net/ifaces/eth0/ipv4address <==
192.168.121.3/24

==> /etc/sysconfig/network <==
# Used by hotplug/pcmcia/ifplugd scripts to detect current network config
# subsystem.
CONFMETHOD=etcnet

# Used by rc.sysinit to setup system hostname at boot.
HOSTNAME=slave0.localdomain

# This is used by ALTLinux ppp-common to decide if we want to install
# nameserver lines into /etc/resolv.conf or not.
RESOLV_MODS=yes

==> /etc/hosts <==
127.0.0.1	localhost.localdomain localhost
192.168.121.2 puppet
[root@puppet ~]# 

Можно перезагружать: ssh user@192.168.121.16 -t su -c /sbin/reboot; ping 192.168.121.3

Запуск машин

Примеры:

virsh start imz-puppetry0-master-ALT; ping 192.168.121.2
virsh start imz-puppetry0-slave0-ALT; ping 192.168.121.3

Работа с машинами происходит подключением через virt-manager или по ssh с хост-системы-гипервизора.

Остановка машин

Примеры остановки по-хорошему:

ssh root@192.168.121.2 poweroff
ssh user@192.168.121.2 -t su -c /sbin/poweroff

Остановка грубо (подсмотрено в virt-delete из #Удаление машин):

virsh destroy imz-puppetry0-master-ALT

(это именно аналог выключения питания, а не удаление образов).

Удаление машин

Если нужно, удаление той или иной машины делается[1] так, как записано в скрипте virt-delete из virt-utils.

Тестирование puppet

Предварительные штуки: пакеты, сервисы

[root@puppet ~]# apt-get install puppet-server 
[root@slave0 ~]# apt-get install puppet

[root@puppet ~]# service puppetmaster start
[root@puppet ~]# systemctl enable puppetmaster

Демона агента на подчинённой ноде пока запускать не будем, потому что тестировать интереснее однократным вызовом с отладочной информацией (как будет ниже в примере: puppet agent --test --debug):

[root@slave0 ~]# #service puppet start

Создание и выполнение тестовых манифестов

Место, где лежат манифесты, которые будут выполнятся (в конфигурации по умолчанию). (В конфигурации по умолчанию агент обращается к мастеру на хосте по имени puppet.)

[root@puppet puppet]# mkdir -p /etc/puppet/environments/production/manifests

В Puppet3 нужно отредактировать файл /etc/puppet/puppet.conf, добавив в секцию Main следующий код:

environmentpath = $confdir/environments

Затем нужно перезапустить puppetmaster.

Попробуем простейший пример манифеста (эта ссылка просто на пример исходного кода для puppet; команды для тестирования все перечислены и на нашей странице; нет необходимости пробовать, например, puppet apply). Этот пример манифеста создаст /tmp/puppet-testfile. В начале работы его нет:

[root@slave0 ~]# l /tmp/puppet-testfile
ls: cannot access /tmp/puppet-testfile: No such file or directory

Сам манифест:

[root@puppet puppet]# cat >/etc/puppet/environments/production/manifests/test0.pp
file { "/tmp/puppet-testfile":
        ensure => "present",
        owner => "root",
        group => "root",
        mode => "664",
        content => "This is a test file created using puppet.
                    Puppet is really cool",
}

Выполнить его на slave0, возможно, не получится с первого раза (см. решение про подпись ниже), но попробовать запустить агент можно всё равно сразу, и пробовать сколько угодно раз. Перезапускать puppetmaster не нужно, чтобы читался новый манифест. Имя .pp-файла не важно. Одноразовое тестирование выполнения с отладочной информацией делается командой:

puppet agent --test --debug
l /tmp/pup*

(service puppet start собственно и запускает такого агента, но не в одноразовом режиме; мы пока так демона-агента не запускаем, потому что неинтересно для тестирования выполнения манифестов.)

А на том же хосте (puppet), где мастер, получится выполнить тестовый манифест сразу с первого раза этой командой.

Чтобы выполнить на другом хосте, а именно slave0, придётся подписать ключ этого подчинённого хоста (чтобы ходить к puppet-мастеру с этим сертификатом). Это делается просто, если знать; можно просто подписать на puppet-мастере. Перед началом работы на puppet-мастере видим только свой сертификат (подписанный -- отмечено +):

[root@puppet ~]# puppet cert list --all
+ "puppet.localdomain" (SHA256) 05:70:76:4B:78:42:57:D8:10:14:29:42:FD:E1:84:5D:39:AB:77:60:EF:2F:87:3C:80:B5:59:BB:75:62:D9:16 (alt names: "DNS:puppet", "DNS:puppet.localdomain")

а после первого вызова агента на подчинённом хосте (обычным образом, т.е. так, как указано выше: puppet agent --test --debug) в этом списке появится его ключ:

[root@puppet ~]# puppet cert list --all
  "slave0.localdomain" (SHA256) 4C:D1:8F:00:76:FD:A1:50:D5:BD:3F:4F:C7:69:E0:1E:17:1E:EC:9F:B0:F6:D2:32:2E:C3:4C:F0:99:71:88:C7
+ "puppet.localdomain" (SHA256) 05:70:76:4B:78:42:57:D8:10:14:29:42:FD:E1:84:5D:39:AB:77:60:EF:2F:87:3C:80:B5:59:BB:75:62:D9:16 (alt names: "DNS:puppet", "DNS:puppet.localdomain")

(имя явно берётся не из DNS мастером, потому что имени slave0.localdomain мастеру неизвестно; оно было вписано подчинённой нодой при создании запроса на подпись сертификата). Подписываем:

[root@puppet ~]# puppet cert sign slave0.localdomain
Signing Certificate Request for:
  "slave0.localdomain" (SHA256) 4C:D1:8F:00:76:FD:A1:50:D5:BD:3F:4F:C7:69:E0:1E:17:1E:EC:9F:B0:F6:D2:32:2E:C3:4C:F0:99:71:88:C7
Notice: Signed certificate request for slave0.localdomain
Notice: Removing file Puppet::SSL::CertificateRequest slave0.localdomain at '/etc/puppet/ssl/ca/requests/slave0.localdomain.pem'
[root@puppet ~]# puppet cert list --all
+ "puppet.localdomain" (SHA256) 05:70:76:4B:78:42:57:D8:10:14:29:42:FD:E1:84:5D:39:AB:77:60:EF:2F:87:3C:80:B5:59:BB:75:62:D9:16 (alt names: "DNS:puppet", "DNS:puppet.localdomain")
+ "slave0.localdomain" (SHA256) 1A:2A:15:08:F4:AD:0B:3A:CA:46:EF:2A:B5:0D:60:4E:DC:BA:BA:E2:63:EC:D1:A3:84:4A:06:B3:9A:A4:22:ED

После этого повторный запуск puppet agent --test --debug на подчинённой ноде выполняет наш тестовый манифест!^[2]

См. также

Puppet/Запуск puppetry (инструкция для PVE)

Примечания