Моя организация пишет программное обеспечение для Linux. Программное обеспечение предназначено для работы в торговых точках, территориально распределенных.
Изначально программное обеспечение предоставлялось клиентам в виде набора deb-пакетов для разных дистрибутивов и архитектур со списком пакетов, которые необходимо было установить в качестве зависимостей перед установкой этих deb-файлов.
Я хотел бы рассказать вам, какой был путь эволюции от раздачи файлов по ftp до создания репозитория и запуска системы управления конфигурациями и начала внедрения сервера непрерывной интеграции.
Происхождение жизни
Итак, ПО представляет собой коммерческую разработку, которая написана на Qt, все собрано для двух архитектур (i386 и amd64) и для нескольких дистрибутивов.На данный момент мы определили это: два-три последних релиза Debian и два последних LTS от Ubuntu. Плюс есть несколько версий (на данный момент три), которые используются клиентами.
Три версии получились так: при покупке ПО клиенту предлагается поддержка и за достаточно приемлемую цену предоставление новых версий ПО.
Изменение минорных версий бесплатно, независимо от поддержки.
Мажор - либо с поддержкой, либо продается снова только со скидкой.
Пока версий было мало и количество установок клиентами было небольшим, вполне можно было обойтись ftp. Выглядело это так: после сборки всех исходников в deb-пакеты, набор файлов для каждого клиента (в зависимости от версии) архивировался и заливался для каждого клиента на ftp в свой раздел.
Со временем на фтп скопилось множество одинаковых таров от разных клиентов, которые время от времени приходилось удалять.
Шло время, клиенты добавлялись, клиентские сети росли в размерах, а обновление версии ПО на точках становилось еще одной задачей, особенно учитывая, что в 99% точек Интернет был (и есть) GPRS. Кстати, о сборе пакетов.
Скипы, собиравшие деб-пакеты, изначально были написаны «300 лет назад» по какому-то мануалу на английском языке и ИМХО не совсем корректно.
Причесать и отмыть скрипты помогли следующие статьи (за что хочу поблагодарить их авторов):
Начало эволюции
Разумеется, был поднят вопрос о том, как распределить собранные пакеты каким-то более правильным способом."И тут Остап увлекся" (с), я решил сделать всё правильно, чтобы на рутинные операции тратилось минимум времени.
В качестве программного обеспечения, поддерживающего репозиторий, было выбрано reprepro. На тот момент возможностей, которые оно предоставляло, было вполне достаточно.
Далее, исходя из опыта обновления и настройки большого количества компьютеров, мне захотелось иметь инструмент управления конфигурацией.
На помощь были вызваны Google и Хабр.
Я познакомился с ansible, Chef, Puppet и другими системами, названия которых уже не помню.
На основании ясности конфигов, документации, порога входа и совокупности других параметров принят на вооружение кукольный .
К кукле был прикреплен бригадир.
И счастье пришло.
Прошло не так много времени, и мне захотелось чего-то более необычного для управления хранилищем.
Reprepro устраивал всех, кроме возможности хранить разные версии одного и того же пакета в одном репозитории: чтобы иметь возможность быстро откатиться к определенной версии в случае какого-то регресса или быстро установить нужную версию и протестировать поведение системы определенной версии на определенном наборе данных на определенных конфигурациях оборудования.
Как пример: один клиент обнаружил сбой приложения при работе с документами.
Их набор данных без проблем перелетел на компьютеры разработчиков, все прекрасно открывалось и работало без сбоев.
Собрали стенд, установили тот же линукс, ту же версию ПО, опять все работает и не вылетает. Стали действовать максимально параноидально — собрали другую машину, максимально приближенную по характеристикам к машине клиента, дисковому пространству, памяти, процессору, разрешению монитора, и о чудо! повторил падение.
Начали разбираться: выяснили, что суть в разрешении монитора, точнее не в разрешении как таковом, а в соотношении сторон.
Разработчики и первая тестовая машина имели соотношение сторон монитора 16:9, а вторая тестовая машина имела соотношение сторон 4:3. В результате мы подсчитали, что одна строка в qss приводит к краху.
Что, конечно, было большим сюрпризом.
Вот о чем этот пример.
На момент этих тестов такого репозитория не было, и для каждой собранной машины приходилось по старинке копировать deb-пакеты с помощью scp, устанавливать зависимости вручную, потом устанавливать сами пакеты и только потом проверять.
Вместо установки за пару минут через aptitude со всеми зависимостями.
Мне пришлось поискать в Google. Я закончил тем, что погуглил это статья .
Я начал понимать описанные в нем варианты.
Мне удалось посмотреть:
- ДАК - Я вообще не смог освоить.
Я начал с него, потому что это было «официальное решение», но, к своему стыду, я не смог понять, что делать с деревом проекта, которое мне скачал git. Поэтому я не стал особо напрягаться и продолжил читать дальше.
- Второй товар, который я заметил, это мини-дак.
И вроде из конфига и описания всё более-менее понятно.
Единственное, что меня останавливало, это невозможность сделать имена репозиториев (то, что в терминах мини-дака называется сюитой) такими, как я хочу.
Например, я хочу получить путь к репозиторию следующим образом:
deb http://SERVER_NAME/ squeeze-evolution-beta non-free
Но не могу, потому что где-то глубоко в скриптах создается имя переменной со знаками «-», что в bash не работает. Попытки модифицировать скрипты файлом не увенчались успехом, поскольку мой уровень программирования на bash несколько ниже уровня человека, который их написал, и мне все равно не хотелось тратить много времени на изучение всех тонкостей bash (хотя не самый плохой способ провести время). - Третий вариант обзора оказался удачным.
И этот инструмент, кажется, отвечает всем требованиям.
Работаем умело
Документация Aptly довольно подробная и включает примеры.Кроме того, есть bash-дополнение.
аптли имеет очень широкие возможности; ниже я приведу только те команды, которые использую я.
Советую тем, кому интересно, посмотреть повнимательнее.
Создание репозитория:
Вы можете создать его со всеми параметрами сразу: aptly repo create -comment="Wheezy prehistoric" -distribution="wheezy-prehistoric" -architectures="i386,amd64,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,amd64,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
Также имеется поддержка снимков, создание зеркал, перемещение пакетов между репозиториями, поддержка зависимостей и встроенный HTTP-сервер для работы с опубликованными репозиториями.
Есть одна особенность, о которой писал автор - пул один общий для всех репозиториев, и это правильно, но если у меня в разных репозиториях есть файлы с одинаковым названием, но разные по содержанию и размеру, то при публикации этих сообщений никаких сообщений не возникает. репозитории, по логике должно было быть хоть что-то написать.
А файл первого опубликованного репозитория остаётся в пуле.
Кстати, автор очень быстро отреагировал и создал задача отслеживания ошибок .
Ээволюция продолжается
На данный момент пакеты собираются вручную на виртуальных машинах.Что нехорошо.
Уже началась работа по реализации Дженкинс .
Из всего списка доступных инструментов для CI был выбран именно этот. Изначально был установлен TeamCity, но стоимость лицензий не была понятна в связи с тем, что есть и другие проекты, полностью бесплатные и имеющие не худший функционал.
По крайней мере, так это выглядит сейчас.
Если при работе Дженкинса его возможностей по каким-то причинам будет не хватать (хотя при таком количестве плагинов в это сложно поверить), мы поменяем его на что-нибудь получше.
P.S.
В конце статьи хотелось бы подвести итог.Идея статьи заключалась в том, чтобы описать замечательный инструмент — метко, потому что.
на просторах Хабра я о нем ничего не нашел.
Ну, я не посчитал интересным рассказывать это в стиле «вот инструмент, можешь пользоваться».
Я решил, что гораздо интереснее будет прочитать, как именно развивалась моя организация и какие инструменты она использовала, и на личном примере привлечь внимание сообщества к полезному инструменту.
Спасибо за внимание.
Теги: #linux #настройка Linux #Aptly
-
Quattro Wireless Подходит К Концу
19 Oct, 24 -
Идея: Я Пишу Правильно
19 Oct, 24 -
Практическая Биоинформатика Часть 2
19 Oct, 24 -
Энергоэффективная Рождественская Елка
19 Oct, 24 -
Skype Вводит Платные Звонки
19 Oct, 24 -
Windows: Сон(0.5)
19 Oct, 24
