На каком Raspberry Pi можно поднять Git-сервер?

Question

[volkahowl]

Собираемся сделать для конторы внутренний Git-сервер на Raspberry Pi. Кто сталкивался с этими комрьютерами? Какая версия подойдет для этой задачи? Например, 2 или 3 подойдет? Вроде мощность не нужна тут особая.

Comments

[paran0id]

Зачем? Контора деньги зарабатывает, дайте ей нормальный инструмент для этого.

[Сергей Кузнецов]

Какая функциональность вам нужна от такого сервера?
Гит отлично и без сервера работает. Коммитами можно обмениваться по локалке.

Или вы хотите развернуть свой GitLab?

[volkahowl]

Сергей Кузнецов, Свой гитлаб. Дело в том, что нужно минимизировать утечку, в т.ч. использованием внешних сервисов

[Сергей Кузнецов]

volkahowl, вот и смотрите на сайте гитлаба про системные требования. Гитлаб это не только гит, это еще тяжелое веб-приложение, которое требует много ресурсов. Там и управление проектами и задачами, непрерывная интеграция и развертывание, обсуждение кода и рецензирование, вики и документация, интеграция с инструментами разработки. Авторы требуют как минимум версию 4.
Готовьтесь выделить под него нормальный сервер лучше.

Answer 1

[Dmtm]

> для конторы внутренний GIT сервер на raspberry pi.
будет программный RAID1 на USB дисках?
любая древняя материнка + pci-e raid controller - намного, намного лучше

Comments

[Adamos]

RAID1 в данном случае не имеет вообще никакого смысла.
Скорость будет упираться в сеть, а не диск, а безопасность обеспечивается бэкапами, а не рейдами.

[Dmtm]

> безопасность обеспечивается бэкапами, а не рейдами.
так правильнее "безопасность обеспечивается бэкапами и рейдами"

[Wexter]

Adamos,

RAID1 в данном случае не имеет вообще никакого смысла.

удачи восстановить всё когда единственный диск умрёт

[Dmtm]

Wexter, ну с гитом идея понятная - где-то есть локальная копия потерянного состояния и данные не пропадут, но - просто восстановить зеркало или поднять с нуля сервер, бэкакп а потом всей конторой мерджить свое последнее состояние - может оказаться намного дороже рейда

[Adamos]

Dmtm, рейды не обеспечивают безопасность, они создают ее иллюзию, мешая оценить реальные риски.
Шансы того, что рейд продублирует испорченную информацию, на порядки выше, чем выход диска из строя.
Итого - тот же самый второй диск, вставленный в другой компьютер с грамотно настроенным бэкапом, реально повышает безопасность. А риск выхода из строя диска, в частности, включает ситуации, когда БП сжигает все, что к нему подключено...

[pfg21]

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

причем это лучше делать силами самого git
https://docs.github.com/en/repositories/creating-a...
продбулировать репы и постоянно их синхронизировать.

ну а бекап это просто бекап, он не связан Нни с рейдом ни с гитом и делается отдельно.

Answer 2

[VoidVolker]

Поднять можно на любом. Вопрос только в юзабельности полученного решения.
UPD:

Свой гитлаб. Дело в том, что нужно минимизировать утечку, в т.ч. использованием внешних сервисов

В таком случае максимальную версию малинки с 8ГБ ОЗУ + SSD диск для ОС и данных или для данных можно подключить сетевое хранилище, например. Этого будет достаточно для работы сотни-двух пользователей. Больше - скорее всего будут лаги/тормоза.

Answer 3

[d-stream]

Скорее всего малинка начнёт захлёбываться на работе с дисками. По крайней мере если будет сверх хранения версий ещё и ci/cd.
Ну а скармливать логи и артефакты сборки на быстрое хранилище S3 - а чего бы тогда не подсадить туда и сам gitlab? )

Из моей практики на x86 - 4..8vCPU и 7..8Гб ОЗУ и в силу специфики (огромные артефакты) - быстрые диски.

Ну и да - "диски" - это надёжная дисковая полка + регулярные бэкапы. Ибо система контроля версий - это сердце разработки.

Answer 4

[Mars36]

Проще было бы VPS арендовать на такой случай

Comments

[Adamos]

ТС хочет "минимизировать утечку".
То есть сначала наколхозит локальный сервер, а уже потом будет колхозить VPN-ы до него для разработчиков, которым понадобился доступ из дома.