Aptly - створення власного репозиторію

Моя організація пише софт під Linux.
Софт призначений для роботи на торговельних точках, які розподілені географічно.
Спочатку ПО надавалося клієнтам як набір deb пакетів під різні дистрибутиви та архітектури зі списком пакетів, які потрібно встановити як залежності до інсталяції цих deb файлів.
Хочу розповісти, яким був шлях еволюції від поширення файлів через ftp до створення сховища та запуску системи управління конфігураціями і початку впровадження в роботу сервера безперервної інтеграції.
 
 

Зародження життя

Отже, софт — комерційна розробка, яка пишеться на Qt, все збирається під дві архітектури (i386 і amd64) і під кілька дистрибутивів. На поточний момент визначилися так: два-три останніх релізу Debian і два останніх LTS від Ubuntu. Плюс до всього є кілька версій (на поточний момент три), які використовуються у клієнтів.
Три версії вийшли таким чином: при покупці софта клієнту пропонується підтримка і за досить розумні гроші надання нових версій софта. Зміна мінорних версій надається безкоштовно незалежно від наявності підтримки. Мажорних — або за наявності підтримки, або продається заново тільки вже з дисконтом.
 
Поки версій було мало, і кількість інсталяцій у клієнтів було невелике, цілком можна було обходиться ftp. Виглядало це так: після складання всіх початкових кодів в deb пакети набір файлів для кожного клієнта (залежно від версії) тарілся в архів і викладався для кожного клієнта на ftp в його власний розділ. З часом на ftp накопичувалася маса однакових tar-ів у різних клієнтів, які доводилося час від часу видаляти.
Йшов час, клієнти додавалися, мережі клієнтів росли в розмірах, і оновлювати версію софта на точках стало ще тієї завданням, особливо якщо врахувати, що на 99% точок інтернет був (та й залишився) GPRS.
 
До речі, про збір пакетів. Скіпт, які збирали deb пакети, спочатку були написані "300 років тому" по якомусь мануалу на Английкий мовою і IMHO не зовсім правильно. Причесати і умити скрипти допомогли наступні статті (за що їх авторам хочу сказати спасибі):
  

Початок еволюції

Само собою було піднято питання про поширення зібраних пакетів якось більш правильним способом. "І тут Остапа понесло" ©, вирішив все зробити правильно, так щоб на рутинні операції витрачалося мінімум часу.
 
В якості софта, який підтримував репозиторій був обраний reprepro. На той момент можливостей, які він надавав, цілком вистачало.
 
Далі, грунтуючись на досвіді поновлення, конфігурування великої кількості комп'ютерів, захотілося мати інструмент з управління конфігураціями. На допомогу був покликаний гугл і Хабре. Знайомився з ansible, chef, puppet та іншими системами, назви яких вже не згадаю. За зрозумілості конфігов, документованості, порогу входження і сукупності інших параметрів на озброєння був узятий puppet . До puppet був прикручений foreman. І щастя наступило.
 
Минуло не дуже багато часу і захотілося у якості управління репозиторієм небудь більш іншого. Reprepro всім влаштовував, крім можливості зберігати в одному репозиторії різні версії одного і того ж пакету: щоб була можливість швидко відкотиться на певну версію в разі якоїсь регресії або, щоб швидко поставити потрібну версію і протестувати поведінку системи певної версії на певному наборі даних на певних апаратних конфігураціях.
 
Як приклад: одним клієнтом було виявлено падіння додатка при роботі з документами. Їх набір даних на комп'ютерах розробників літав без питань, все відкривалося й не падаючи чудово працювало. Зібрали стенд, поставили такий же linux, ту ж версію ПО, знову все працює і не падає. Почали надходити вже максимально параноїдально — зібрали іншу машину максимально наближену за характеристиками до машини клієнта, обсяг диска, пам'яті, процесор, дозвіл монітора і о диво! повторили падіння. Почали розбиратися: з'ясували, що суть в дозволі монітора, вірніше не в дозволі як такому, а в співвідношенні сторін. У розробників і на першій тестовій машині співвідношення сторін монітора було 16:9, а у другої тестової 4:3. У підсумку обчислювальному, що до падіння призводить один рядок в qss. Що було, звичайно, великою несподіванкою. Так ось до чого цей приклад. На момент цих тестів такого репозиторію не було і на кожну зібрану машину довелося по-старому через scp копіювати deb пакети, ручками ж ставити залежності, після чого встановлювати самі пакети і тільки потім перевіряти. Замість того, щоб за пару хвилин встановити через aptitude з усіма залежностями.
 
Довелося гуглити. Нагугліть в підсумку стаття . Почав розбиратися з описаними в ній варіантами. Встиг подивитися на:
 
     
  • DAK — взагалі не подужав. Почав саме з неї так як "official solution", але на свій сором взагалі не зміг зрозуміти, що робити з тим деревом проекту, який стягнув мені git. Тому особливо не напружувався і продовжив читати далі.
  •  
  • Другим продуктом, на який звернув увагу, став mini-dak. І як би все зрозуміло по конфігу і з описом більш-менш ясно. Ось тільки спинила неможливість зробити імена репозиторіїв (те, що в термінах mini-dak називається suite) такі як хочу. Наприклад я хочу получть шлях до репозитаріїв такий:
    deb http://SERVER_NAME/ squeeze-evolution-beta non-free 
    A не можу, тому-що десь в глибині скриптів створюється ім'я змінної зі знаками "-" що в bash-e не працює. Спроби доопрацювати скрипти напилком успіхом не увінчалися, бо мій рівень програмування на bash дещо не дотягує до рівня людини, яка їх писав, а вбити купу часу на вивчення всіх тонкощів bash (хоч і не найгірше проведення часу), але все ж не хотілося.
  •  
  • Третім варіантом для ознайомлення був вибраний aptly. І схоже, що цей інструмент підходить.
  •  
 

Робота з aptly

Документація у aptly досить докладна і з прикладами. Крім того є bash-completion.
Можливостей у aptly дуже широкі, нижче наведу лише ті команди які я використовую. Цікавиться більш глибоко ознайомитися рекомендую сайт продукту .
 
 
Створення репозиторія:
Можна створювати відразу з усіма параметрами:
 
aptly repo create -comment="Wheezy prehistoric" -distribution="wheezy-prehistoric" -architectures="i386,amd46,all" -component="non-free" wheezy-prehistoric

Можна параметри дописати пізніше, а створити просто так:
 
aptly repo create wheezy-prehistoric

 
Зміна параметрів
Міняємо параметри по одному:
 
aptly repo edit -comment="Wheezy prehistoric" wheezy-prehistoric

Або все відразу:
 
aptly repo edit -comment="Wheezy prehistoric" -distribution="wheezy-prehistoric" -architectures="i386,amd46,all" -component="non-free" wheezy-prehistoric

 
Перегляд існуючих репозиторіїв
 
aptly list

 
Отримання інформації про репозиторії
загальна інформація:
 
aptly show wheezy-prehistoric

інформації зі списком пакетів:
 
aptly repo show -with-packages wheezy-prehistoric

 
Додавання пакетів в репозиторій
одного файлу:
 
aptly repo add wheezy-prehistoric build//Debian-wheezy/chameleon-core_1.3.0-wheezy46_amd64.deb

всього каталогу:
 
aptly repo add wheezy-prehistoric build//Debian-wheezy

при додаванні кілька збентежило відсутність автодоповнення шляху до файлу / каталогу
 
 
Публікація репозитория
 
aptly publish repo wheezy-prehistoric

 
Видалення публікації
 
aptly publish drop wheezy-prehistoric

 
Отримати граф репозиторіїв
 
aptly graph

 
Також є підтримка snapshot-ів, створення дзеркал, переміщення пакетів між репозиторіями, підтримка залежностей, вбудований HTTP сервер для роботи з опублікованими репозиторіями.
 
Є одна особливість про яку написав авторові — pool один загальний для всіх репозиторіїв, що є правильно, от тільки якщо у мене в різних репозитаріях лежать файли з однаковим ім'ям, але різні за змістом і розміром при публікації цих репозитаріїв ніяких повідомлень немає, за логікою має було хоч щось написати. І в pool-е залишається лежати файл першого опублікованого репозиторію.
До речі автор дуже швидко відреагував і створив на багтрекер задачу .
 
 

Еволюція триває

В даний момент пакети збираються ручками на вітруальной машинах. Що не є добре. Вже розпочато роботи з впровадження в роботу Jenkins . З усього списку доступних засобів для CI був обраний саме він. Спочатку був встановлений TeamCity, але вартість ліцензій була незрозумілою через те, що є інші проекти, які повністю безкоштовні і володіють не гіршою функціональністю. Принаймні, це виглядає зараз саме так. Якщо в процесі експлуатації Jenkins-а його можливостей з якихось причин буде недостатньо (хоча з такою кількістю плагінів в це слабо віриться), поміняємо на щось краще.
 
 

P.S.

У кінці статті хотілося б підвести підсумки.
Ідея статті була описати чудовий інструмент — aptly, т.к. на просторах Хабра не знайшов про нього нічого. Ну а розповісти в стилі "ось інструмент — можна користуватися" порахував не цікавим. Вирішив, що буде набагато цікавіше почитати, яким саме шляхом розвивалася моя організація і які інструменти при цьому використовувала ну і звернути увагу спільноти на корисний інструмент за допомогою особистого прикладу.
 
Спасибі за увагу.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.