Kurgan-Telecom Ru | Информационные технологии

Первая статья, само собой — сборка своего deb-пакета из ничего. Такие пакеты будут очень полезны для того, чтобы деплоить свою конфигурацию — вы из коробки получаете контроль версий установленной конфигурации на машине. Штатными средствами системы можно будет быстро откатиться на старую версию пакета. Легче обновляться, легче деплоить на несколько машин. И так далее. Бла-бла-бла.
На одном из своих выступлений я рассказывал о том, что именно deb-пакетами деплоится конфигурация машин и самописный софт (в том числе и сервисы) в Яндексе. Конечно, не во всех отделах, но все стараются двигаться к этому.

Несмотря на то, что давно уже создана куча инструментов декларативной конфигурации серверов (chef, puppet, Salt, ansible) — пока ещё ничего лучше родной пакетной системы дистрибутива не сделали. Конечно, у пакетов есть некоторые ограничения, поэтому есть смысл использовать пакетирование совместно с системами конфигурации, но большую часть конфигурации имеет смысл держать именно в пакетах (а каким-нибудь паппетом смотреть за актуальностью/установленностью нужных пакетов на нужных хостах). Вооот.

Сразу оговорюсь, что я не ставлю прямо сейчас цели описать то, как собрать пакет в соответствии с debian policy (они развесистые и соблюдать их внутри своей инфраструктуры тяжело). Прямо сейчас я описываю понятный способ сборки. Примерно поэтому я не буду использовать dh_install, например (но по debian policy мне бы за это надо голову оторвать).

Ну поехали собирать.

Мы соберем пакет, который кладет наш ключик руту, кладет пачку конфигов для nginx’a в conf.d, sites-available, добавляет пару задач в крон, притаскивает, собственно, скрипты для этих задач, тащит за собой нужный софт.

Для начала установим все нужные инструменты для сборки пакета описанным ниже способом:

Создаём каталог, из которого мы будем собирать пакет. Относительно этого каталога мы дальше будем работать (и относительно него будем собирать пакет). Каталог нужно назвать в формате «packagename-version»
В качестве названия пакета я буду использовать «example-package»:

Генерируем пустой «скелет» для сборки:

В --copyright мы указываем «лицензию» для нашего пакета (кому какая разница=)? ), --createorig — создаёт tar-ник с исходниками каталогом выше. Можно использовать опцию --native, но он не работает в текущей версии dh_make в Wheezy, так что нужно быть к этому готовым.

Удаляем лишние файлы, которые нагенерил нам dh_make:

Если вся эта эпопея происходит внутри каталога системы контроля версий (git, svn?), то самое время убрать номер версии из названия каталога:

Иначе при сборке пакета каждый раз будет меняться название каталога (в итоге у вас будет куча каталогов внутри VCS — переименование будет делаться через обычный mv, а не через git mv, например). Можно всё это контролировать руками, но лень.

Теперь быстренько нагадим файлами, которые будут «исходниками» пакета. Здесь всё очень условно, воспринимайте это как очень простой пример. Вся основная магия будет происходить в файле debian/rules, поэтому неважно как сейчас вы расположите файлы (главное, чтобы они были внутри каталога, из которого будет собираться пакет).

Создадим каталог для исходников, чтобы отделить мух от котлет:

В итоге у нас должно быть так:

Создадим файлы и каталоги внутри sources:

Ещё раз — всё это условности. Располагайте файлы так, как вам в дальнейшем будет удобно. Само собой, в эти файлы нужно что-то записать, если хотите притащить не пустые файлы на машину из пакета ;)

Теперь напишем файл debian/rules.
Основная задача этого файла с нашей точки зрения — подготовить каталог debian/packagename (в нашем случае это будет debian/example-package), из которого потом будет сгенерирован архив внутри пакета, который будет распакован поверх корневой файловой системы там, куда этот пакет мы будем ставить.
То есть, в нашем случае, файл, который мы положим в debian/example-package/root/.ssh/authorized_keys после установки собранного пакета станет файлом /root/.ssh/authorized_keys
Это, в целом, самый-самый главный момент при сборке пакета, который нужно понимать. Остальное за нас сделают разные debhelper’ы (и мы можем не понимать, что они там делают, но им-то на это наплевать).

В нашем примере я бы использовал такой rules (напомню, что это нифига не по debian policy, зато понятно и работает):

Если вы (зачем-то) скопировали текст-примера debian/rules, то придется ввести эту команду:

В rules-файле (он же - и Makefile) обязательно должны быть символы табуляции, а не 4 пробела. Вообще же debian/rules вам придется писать самим каждый раз.

Следующий на очереди - файл debian/control. В этом файле описывается мета-информация о наших исходниках, мета-информация о пакетах, которые мы собираем, то, как наш пакет будет взаимодействовать с другими пакетами (с какими конфликтует, от каких зависит).
В нашем примере подойдет такой control:

Это минимальное содержимое файла debian/control. Его хватит для сборки нашего пакета.

Сейчас самое время обратить на то, что в нашем пакете мы кладем какие-то файлы в /etc/nginx/sites-available. Само собой, в этом случае, nginx не будет использовать наши файлы. Нам нужно создать симлинк файла из /etc/nginx/sites-available в /etc/nginx/sites-enabled. Для этого есть 2 способа.
Первый - варварский, но понятный - использовать уже заведенный нами debian/rules и вписать в нём в секцию override_dh_install команду создания симлинка:

Либо использовать файл debian/links и вписать в него такое:

Этот файл будет прочитан deb-helper'ом dh_link, который и создаст симлинку внутри каталога, из которого будет собран архив. Это как раз про строчку "запустим все debhelperы по умолчанию".

Остаётся последний штрих - postinstall (скрипт, который будет запускаться после установки нашего пакета).
В примере я буду рестартить nginx, чтобы применилась конфигурация nginx'a из пакета.

Создадим файл и выставим на него флаг +x:

Внутрь запишем примерно такое содержимое:

Теперь всё готово к сборке пакета. Сообщим собиралке пакетов, что у нас новая версия (и заодно напишем правильно поля в changelog'e):

У нас откроется файл changelog в редакторе. В него будут добавлены примерно такие строки:

Сотрем всё это и напишем то, что нам нужно:

В скобочках - версия. Последняя строка (начинающаяся с " --") - кто и когда собирал пакет. "Кто" должно совпадать с нашей подписью, но сейчас её у нас нет, поэтому можете написать туда что угодно.

Собираем пакет (находясь в каталоге example-package или example-package-0.2, если не переименовывали):

После сборки у нас должно получиться несколько файлов каталогом выше:

.build - лог сборки
.changes - файл с метаинформацией о пакете (нужен для того, чтобы потом залить пакет в репозиторий).
.deb - сам deb-пакет.

Проверим, что в пакет попали все нужные файлы нужного размера с нужными правами:

Пока что мы можем поставить deb-пакет ручками. Для этого копируем его на нужную машину, ставим руками все зависимости и запускаем установку (от рута или с sudo):

В общем-то всё.

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