GearRepo — различия между версиями

Материал из ALT Linux Wiki
Перейти к: навигация, поиск
м (Техническая реализация)
Строка 96: Строка 96:
 
Общая схема выглядит так:
 
Общая схема выглядит так:
 
[[Image:Gearrepo.png|center|Схема GearRepo]]
 
[[Image:Gearrepo.png|center|Схема GearRepo]]
Http-запрос клиента идёт на фронтенд apache, который затем проксируется на бэкенд  [https://metacpan.org/module/Twiggy twiggy], который передаёт данные в веб-приложение GearRepo::Web (на веб-фреймворке [http://perldancer.org/ Dancer] ).  
+
*Http-запрос клиента идёт на фронтенд apache, который затем проксируется на бэкенд  [https://metacpan.org/module/Twiggy twiggy], который передаёт данные в веб-приложение GearRepo::Web (на веб-фреймворке [http://perldancer.org/ Dancer] ).  
 
Веб-сервер Twiggy используется по причине необходимости использования [https://metacpan.org/module/AnyEvent AnyEvent] в веб-приложении.  
 
Веб-сервер Twiggy используется по причине необходимости использования [https://metacpan.org/module/AnyEvent AnyEvent] в веб-приложении.  
  
Веб-приложение обрабатывает запрос и если в результате потребуется выполнить какое-либо действие с gear-репозиторием, например, создать/переименовать или выполнить сборку, формируется запрос на демона задач [http://gearman.org/ gearmand] , который передаёт задачу в соответствующий worker (отдельный процесс), который асинхронно выполняет эту операцию и возвращает результат.  
+
*Веб-приложение обрабатывает запрос и если в результате потребуется выполнить какое-либо действие с gear-репозиторием, например, создать/переименовать или выполнить сборку, формируется запрос на демона задач [http://gearman.org/ gearmand] , который передаёт задачу в соответствующий worker (отдельный процесс), который асинхронно выполняет эту операцию и возвращает результат.  
  
Использование сервера задач необходимо, поскольку не все задачи могут выполняться за приемлемое время ( ~ 1 сек) и следовательно должны выполняться асинхронно, при этом не требовать ресурсоёмких операций (как например, fork() на каждую новую задачу).  
+
*Использование сервера задач необходимо, поскольку не все задачи могут выполняться за приемлемое время ( ~ 1 сек) и следовательно должны выполняться асинхронно, при этом не требовать ресурсоёмких операций (как например, fork() на каждую новую задачу).  
  
Worker'ы для выполнения операций подключаются по ssh к серверу (gear/apt или build-server). Используется одно постоянное ssh-соединение, в рамках которого мультиплексируются новые сеансы. Команды выполняются с правами непривилегированных пользователей, через специальный враппер команд, проверяющий корректность команд и выполняющих их.  
+
*Worker'ы для выполнения операций подключаются по ssh к серверу (gear/apt или build-server). Используется одно постоянное ssh-соединение, в рамках которого мультиплексируются новые сеансы. Команды выполняются с правами непривилегированных пользователей, через специальный враппер команд, проверяющий корректность команд и выполняющих их.  
  
Число сборочных серверов может неограниченно расширяться, они могут находиться где угодно. Пока я наладил только один, на картинке два, но это обман .) - ресурсов всё-таки маловато.  
+
*Число сборочных серверов может неограниченно расширяться, они могут находиться где угодно. Пока я наладил только один, на картинке два, но это обман .) - ресурсов всё-таки маловато.  
  
На данный момент используется быстрая и лёгкая СУБД SQLite, которая в принципе легко может быть заменена на любую другую если это потребуется.  
+
*На данный момент используется быстрая и лёгкая СУБД SQLite, которая в принципе легко может быть заменена на любую другую если это потребуется.  
  
Помимо веб-интерфейса есть также доступ по протоколам ssh и git. Для ssh используется также враппер команд, сходный [https://github.com/sitaramc/gitolite gitolite]. Для git развёрнут git-daemon, который обслуживает только RO-запросы к публичным репозиториям.  
+
*Помимо веб-интерфейса есть также доступ по протоколам ssh и git. Для ssh используется также враппер команд, сходный [https://github.com/sitaramc/gitolite gitolite]. Для git развёрнут git-daemon, который обслуживает только RO-запросы к публичным репозиториям.  
  
Также стоит упомянуть и сторону клиента. Сейчас строк в проекте написанных на JavaScript больше, чем кода серверной части на Perl .) Используется фреймворк [http://jquery.com/ JQuery]. Пока раздумываю стоит ли искать фреймворк пользовательского интерфейса или обойтись своими силами. Для git-браузера обмен с сервером ведётся с использованием JSON, в котором передаются структуры с данными git-репозитория, а вывод формируется уже в браузере. Будет использоваться кэширование на стороне клиента, что позволит быстро и удобно работать с gear-репозиторием.  
+
*Также стоит упомянуть и сторону клиента. Сейчас строк в проекте написанных на JavaScript больше, чем кода серверной части на Perl .) Используется фреймворк [http://jquery.com/ JQuery]. Пока раздумываю стоит ли искать фреймворк пользовательского интерфейса или обойтись своими силами. Для git-браузера обмен с сервером ведётся с использованием JSON, в котором передаются структуры с данными git-репозитория, а вывод формируется уже в браузере. Будет использоваться кэширование на стороне клиента, что позволит быстро и удобно работать с gear-репозиторием.  
  
 
[[Категория:ALT-review]]
 
[[Категория:ALT-review]]

Версия 08:36, 5 октября 2012

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






GearRepo

GearRepo

GearRepo - это ресурс для разработчиков и майнтейнеров, где можно создавать Gear-репозитории исходного кода программ, собирать из них бинарные RPM-пакеты и формировать APT-репозитории, пригодные для использования в дистрибутивах на базе стабильных бранчей ALTLinux и/или нестабильной ветки Sisyphus. На данный момент GearRepo находится в процессе разработки.

От первого лица

Здравствуйте, Владимир! В рамках подготовки роллинг-релиз журнала ALT-review хотелось бы задать Вам несколько вопросов относительно ресурса GearRepo и не только. На портале http://gear.truecrux.org есть пояснение о назначении ресурса, также там размещен практически исчерпывающий работу с ресурсом скринкаст. Однако, хотелось бы детальнее осветить создание этого ресурса и того,что с ним связано. Ниже приведены вопросы, однако хотелось бы оставить за собой право задать дополнительные позже (если такие появятся). Также сами ответы Вы сможете найти на вики a.o (в категории ALT-review) до анонса статьи и сообщить о необходимых корректировках.


Torabora.jpgВопросы(Q): Михаил Радюк torabora Crux.jpgОтветы (A): Владимир Леттиев crux

Q: Скажите, это те самые "карманы", обсуждение которых давно ведется?

A: Это несколько шире, чем "карманы". Да, там можно создать свой apt-репозиторий (оверлей/карман ...), но этим дело не ограничивается.


Q: Почему о разработке этого портала не знают даже многие тимовцы? Вы его пока специально широко не афишировали или есть какие-то иные причины?

A: Анонс был и достаточно давно http://lists.altlinux.org/pipermail/sisyphus/2011-May/353930.html

Протестировать альфа-релиз я приглашал на irc-канале #altlinux, откликнулся raorn@, за что ему спасибо. Было исправлено несколько серьёзных недочётов.

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

Никакого ажиотажа это не вызвало и, как я и предполагал с самого начала, никому, на самом деле, это не интересно. У большинства участников уже сложился свой собственный workflow и менять его и лениво, и трудно (вспоминаем переезд с srpm на gear).


Q: На какой основе он создан - при чьей-то поддержке или самостоятельно?

A: Сделан он самостоятельно, прежде всего для создания комфортного инструмента для ведения пакетов в Sisyphus и бранчах, проведения экспериментов и т.п. Например, последний perl 5.16.1 с зависимостями был как раз собран в "кармане" GearRepo.


Q: Сколько времени и сил Вам потребовалось для его создания?

A: Сейчас трудно уже посчитать, но практически целый месяц (август 2011) я всё свободное время программировал. Дальше уже было значительно меньше времени затрачено.

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


Q: Глупый наверное вопрос - на чем он написан и почему?

A: Кое-какие техн. детали реализации я опубликовал http://blog.truecrux.org/post/xiii

Серверная часть пишется на Perl, клиент на JavaScript с использованием фреймворка JQuery. Выбор определён опытом и вкусом.


Q: Планируются и возможны ли дополнительные возможности ресурса?

A: Фичи добавляются по мере необходимости.


Q: На сколько стабильным и надежным будет ресурс, когда будет запущен в качестве "боевого"?

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


Q: На чьих серверах он "крутится"? Нет ли вероятности, что его прикроют при росте его популярности (и соответственно гигантской нагрузке)?

A: Хостится на своём выделенном железе, с этим проблемы нет. Если ресурс вдруг станет популярным и ему станет тесно в рамках имеющихся ресурсов, то можно будет заняться поиском соответствующего хостинга.


Q: Несет ли какую-то смысловую нагрузку слово truecrux в названии? Или он чему-то посвящен?

A: Нет. В теории он должет переехать на домен второго уровня, имя которому пока не придумалось. Сейчас просто используется существующиий личный домен.


Q: Надеюсь Вы ответите на вопросы. Срочности нет никакой. Заранее спасибо!

A: Вам спасибо.


Техническая реализация

Созданы 3 контейнера openvz: сервер веб-приложения, сервер с gear/apt репозиториями, сборочный сервер. Общая схема выглядит так:

Схема GearRepo
  • Http-запрос клиента идёт на фронтенд apache, который затем проксируется на бэкенд twiggy, который передаёт данные в веб-приложение GearRepo::Web (на веб-фреймворке Dancer ).

Веб-сервер Twiggy используется по причине необходимости использования AnyEvent в веб-приложении.

  • Веб-приложение обрабатывает запрос и если в результате потребуется выполнить какое-либо действие с gear-репозиторием, например, создать/переименовать или выполнить сборку, формируется запрос на демона задач gearmand , который передаёт задачу в соответствующий worker (отдельный процесс), который асинхронно выполняет эту операцию и возвращает результат.
  • Использование сервера задач необходимо, поскольку не все задачи могут выполняться за приемлемое время ( ~ 1 сек) и следовательно должны выполняться асинхронно, при этом не требовать ресурсоёмких операций (как например, fork() на каждую новую задачу).
  • Worker'ы для выполнения операций подключаются по ssh к серверу (gear/apt или build-server). Используется одно постоянное ssh-соединение, в рамках которого мультиплексируются новые сеансы. Команды выполняются с правами непривилегированных пользователей, через специальный враппер команд, проверяющий корректность команд и выполняющих их.
  • Число сборочных серверов может неограниченно расширяться, они могут находиться где угодно. Пока я наладил только один, на картинке два, но это обман .) - ресурсов всё-таки маловато.
  • На данный момент используется быстрая и лёгкая СУБД SQLite, которая в принципе легко может быть заменена на любую другую если это потребуется.
  • Помимо веб-интерфейса есть также доступ по протоколам ssh и git. Для ssh используется также враппер команд, сходный gitolite. Для git развёрнут git-daemon, который обслуживает только RO-запросы к публичным репозиториям.
  • Также стоит упомянуть и сторону клиента. Сейчас строк в проекте написанных на JavaScript больше, чем кода серверной части на Perl .) Используется фреймворк JQuery. Пока раздумываю стоит ли искать фреймворк пользовательского интерфейса или обойтись своими силами. Для git-браузера обмен с сервером ведётся с использованием JSON, в котором передаются структуры с данными git-репозитория, а вывод формируется уже в браузере. Будет использоваться кэширование на стороне клиента, что позволит быстро и удобно работать с gear-репозиторием.