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И это без каких-либо тяжелых приложений.
Сейчас думаю о переезде на Gitea (мне кажется эта система более зрелой, чем gogs), поскольку для меня функционал gitlab излишен, а ресурсов он ест много.
Вообще, я только недавно увидел Phacility. Возможно, если бы я о нём знал до того, как установил, настроил обкатал Gitlab, выбрал бы его, даже странно, что я его упустил из виду.
Какая-то подозрительная надпись там в самом начале:
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!
А в чём его плюсы и особенности?
Пока добавил ссылку в мини-обзор.
это по сути надстройка над стандартными командами git
Но ведь есть фарфор и фаянс. Никто не запрещает пользоваться командами высокого уровня. Но часто команды низкого дают большую гибкость: это просто особенность реализации, она не является плюсом или минусом.
Можно выделить в веб-интерфейсе коммит и одной кнопкой послать его, например, Линусу Торвальдсу в LKML. И наоборот, можно получить письма из LKML, эта штука их распарсит и покажет примерно в таком и таком виде.
git patch? Мне редко требуется его функционал, потому что я не коммичу в ядро Linux. Там исторически сложилось, что коммиты отправляют патчами через e-mail, однако это не типично для большинства проектов.
Кроме того, Gitlab и подобные, насколько я помню, в формате git patch могут дифф выдать.
И вообще, какая разница, если речь идет о небольших не слишком важных проектах на личном сервере.
Разница есть: для кого-то они не важные, но важные для меня. С таким подходом, ПО будет дырявым, и дыры не будут закрывать. Сейчас все ловят последствия.
Да и зачем мне тогда надёжное железо, на котором будет заведомо ненадёжное ПО?
Я NAS делаю с целью защитить данные.
Разница есть: для кого-то они не важные, но важные для меня. С таким подходом, ПО будет дырявым, и дыры не будут закрывать. Сейчас все ловят последствия.
Да и зачем мне тогда надёжное железо, на котором будет заведомо ненадёжное ПО?
Я NAS делаю с целью защитить данные.
Это неактуально, если NAS не светит своими сервисами на весь интернет. Вы же так не делаете, я надеюсь? Тем более, что 0-day в каком-нибудь ftp server в NAS легко заиметь. Поэтому — самое верное — контролируемый доступ к NAS по белым спискам, VPN, basic auth etc.
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, и сокет там лишний. Сейчас поправлю.
А Вам лень написать еще раз, ОКей, так и запишем.
Это всё, хотя наверняка он настраивается. У него же больше адаптировано «для людей».
принято. Я пользуюсь официальным. И насколько я помню, он настраивается и через проброс gitlab.rb из volume, так и через переменные окружения
Справедливости ради, да тут вы правы. С раннером я прокидался, скопировав по привычке environment, и сокет там лишний. Сейчас поправлю.
да, пожалуйста, мне не жалко )
del
GitLab в NAS