Comments 27

Да ну, он же настраивается. И я не заметил, чтобы большую нагрузку давал на процессор. Возможно потому, что мало пользователей работает. Но память жрёт, это да.
И прежде всего я рассчитываю на своё железо так, чтобы получился некий гайд, позволяющий реализовать конечный продукт.

Честно говоря рад что у вас получилось.
Я запускал у себя на ноуте с 16 гигами из официального образа и это было нечто.
Оно ещё и свопилось непрерывно.

Странно. У меня 16 ГБ (пока, ещё 16 сейчас лежат и ждут отправки) и нет такой проблемы: из них вот прямо сейчас занято порядка 8 (работает не только гитлаб) и в свопе 1.4. Для того, чтобы не свопилось нужно специально донастраивать, у меня понижен swapiness и установлен overcommit:


vm.overcommit_memory = 1
vm.swappiness = 10

Это есть в sysctl.conf, лежащем в репозитории.

Эм. Очень странно. Я использую гитлаб в докере на хосте с 4 vCPU и 8GB vRAM — и тормозов не вижу. Возможно, что дело в ноуте (десктопные настройки, конкуренция по ОЗУ с каким-нибудь Гугль Хром).
И да — на ноуте с Хромом и КДЕ все реально плохо


gaal@5580-gaal:~/images/ansible> free -m
             total       used       free     shared    buffers     cached
Mem:         15927      15193        734       1135          1       7944
-/+ buffers/cache:       7247       8680
Swap:         2054         70       1984

И это без каких-либо тяжелых приложений.

Согласен. У меня на мини-сервачке (2 гб оперативной) под lxc даже не запустилось, пришлось разворачивать на полноценном сервере.

Сейчас думаю о переезде на Gitea (мне кажется эта система более зрелой, чем gogs), поскольку для меня функционал gitlab излишен, а ресурсов он ест много.
Спасибо, что напомнили. Я дополнил мини-обзор. Gitea — форк gogs, я когда смотрел, не увидел серьёзных различий, а вот на Kallithea посмотреть стоит.
Вообще, я только недавно увидел Phacility. Возможно, если бы я о нём знал до того, как установил, настроил обкатал Gitlab, выбрал бы его, даже странно, что я его упустил из виду.
Активно пользуемся, недавно перешли с gogs. Пока никаких нареканий. Функционал богаче, да.
Используемые:
  • Review!!!
  • 2FA
  • LFS
  • Метки
  • Доработанный поиск
  • Responsive UI
  • Настройка стратегии слияния PR
  • Подсказки @-упоминаний
  • Прогресс задач с чекбоксами


Потенциально важные:
  • LDAP
  • Discord-хуки
  • Кастомизация UI
  • Тёмная тема
Спасибо.

А gogs, вроде, тоже имеет LDAP плагин, не?
Докину приведённые фичи в обзор для Gitea.

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

Мне кажется если 10-летний core2quad q9400 с 8 гигами ddr2 тянет его то проблем на любом современном x86 NAS'е не должно быть.
UFO landed and left these words here

Какая-то подозрительная надпись там в самом начале:


Achtung! sr.ht is still under heavy development, and while many of the services are usable, expect to find lots of missing polish, broken links, incomplete docs, and so on. Here be dragons!

А в чём его плюсы и особенности?


Пока добавил ссылку в мини-обзор.

UFO landed and left these words here
это по сути надстройка над стандартными командами git

Но ведь есть фарфор и фаянс. Никто не запрещает пользоваться командами высокого уровня. Но часто команды низкого дают большую гибкость: это просто особенность реализации, она не является плюсом или минусом.


Можно выделить в веб-интерфейсе коммит и одной кнопкой послать его, например, Линусу Торвальдсу в LKML. И наоборот, можно получить письма из LKML, эта штука их распарсит и покажет примерно в таком и таком виде.

git patch? Мне редко требуется его функционал, потому что я не коммичу в ядро Linux. Там исторически сложилось, что коммиты отправляют патчами через e-mail, однако это не типично для большинства проектов.
Кроме того, Gitlab и подобные, насколько я помню, в формате git patch могут дифф выдать.


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

Разница есть: для кого-то они не важные, но важные для меня. С таким подходом, ПО будет дырявым, и дыры не будут закрывать. Сейчас все ловят последствия.
Да и зачем мне тогда надёжное железо, на котором будет заведомо ненадёжное ПО?
Я NAS делаю с целью защитить данные.

Разница есть: для кого-то они не важные, но важные для меня. С таким подходом, ПО будет дырявым, и дыры не будут закрывать. Сейчас все ловят последствия.
Да и зачем мне тогда надёжное железо, на котором будет заведомо ненадёжное ПО?
Я NAS делаю с целью защитить данные.

Это неактуально, если NAS не светит своими сервисами на весь интернет. Вы же так не делаете, я надеюсь? Тем более, что 0-day в каком-нибудь ftp server в NAS легко заиметь. Поэтому — самое верное — контролируемый доступ к NAS по белым спискам, VPN, basic auth etc.

Конечно делаю. Gitlab торчит в Интернет по SSH и HTTPS. А иначе он для меня бесполезен.
VPN не совсем удобен, потому что задумывалось, что пользоваться буду не только я (нельзя всех заставить использовать VPN, чтобы подключиться к NAS).
Белые списки тоже, потому что я пользуюсь NAS с разных адресов.
Я использую образ Gitlab от sameersbn.

интересно, почему этот образ, а не официальный.
SSL_SELF_SIGNED

еще из этого я предполагаю, что сертификат SSL самоподписанный. LE было не судьба получить?
GITLAB_MATTERMOST_ENABLED=true

реально пользуетесь Mattermost?
— /var/run/docker.sock:/var/run/docker.sock:rw

это в гитлаб-раннере — прям божественно. Т.е. чисто гипотетически кривой gitlab-ci процесс может угробить всю среду.
expose:
— 443
— 80
— 22

в первый раз вижу использование expose в docker-compose. Зачем?
интересно, почему этот образ, а не официальный.

Нормальный docker-compose.yml с выведенными параметрами.
В отличие того, что я сразу увидел в официальном:


app:
  image: gitlab/gitlab-ce:latest

Это всё, хотя наверняка он настраивается. У него же больше адаптировано "для людей".


еще из этого я предполагаю, что сертификат SSL самоподписанный. LE было не судьба получить?

в первый раз вижу использование expose в docker-compose. Зачем?

Прочитайте введение в статью и, по крайней мере три вопроса (из других комментариев тоже) уйдут.
Напомню, что всё указано по ссылке.
Вопросы совершенно не в тему и ответы тут очевидны, если вы заметите, что эта статья опубликована в рамках цикла по конкретной реализации NAS.
В том числе, замечу, что LE там используется.


реально пользуетесь Mattermost?

Хотел подключить и потыкать, но руки не дошли, забыл убрать.


это в гитлаб-раннере — прям божественно. Т.е. чисто гипотетически кривой gitlab-ci процесс может угробить всю среду.

Справедливости ради, да тут вы правы. С раннером я прокидался, скопировав по привычке environment, и сокет там лишний. Сейчас поправлю.

TL;DR, пролистал по диагонали «введение», ответы неочевидны.
А Вам лень написать еще раз, ОКей, так и запишем.
Это всё, хотя наверняка он настраивается. У него же больше адаптировано «для людей».

принято. Я пользуюсь официальным. И насколько я помню, он настраивается и через проброс gitlab.rb из volume, так и через переменные окружения
Справедливости ради, да тут вы правы. С раннером я прокидался, скопировав по привычке environment, и сокет там лишний. Сейчас поправлю.

да, пожалуйста, мне не жалко )
TL;DR, пролистал по диагонали «введение», ответы неочевидны. А Вам лень написать еще раз, ОКей, так и запишем.

Ещё раз написать цикл статей? Да, лень и бессмысленно.
Если кратко: nginx-reverse-proxy+letsencrypt+cloud DNS.

Only those users with full accounts are able to leave comments. Log in, please.