gitlab in k8s requirements

30 коммитов в день

k8s

ты ж мой архитектор

А чего ты хотел?

Можешь посмотреть в сторону чего-нибудь легковесного, вроде gitea.

около 15 юзеров, около 30 коммитов в день

ИМХО тут надо считать не число коммитов в день, а число каких-нибудь пушей и MR.

если решил жрать bloatware - жри, никуда не денешься

да стоит gitea. нужны все свистелки gitlab.

Кластер из трёх нод по 6Гб в каждой переваривает и существенно большую нагрузку, чем описана в стартовом посте.

так возьми gitlab.com

точно нужен self-hosted? Все фичи будут доступны. А когда поймешь, что прям там очень нужно на свой переходить, то тоже делается без особых проблем. Но в перспективе можешь сэкономить много сил и денег.

точно нужен self-hosted?

Для этого проекта точно. Про все фичи и прочее я в курсе, не первый год замужем.

Кластер из трёх нод по 6Гб в каждой переваривает и существенно большую нагрузку, чем описана в стартовом посте.

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

Да нахер он нужен, это кубернетес… просто вручную настрой СУБД под гитлаб, с репликацией. Я даже умудрялся делать это на двух инстансах DigitalOcean, второй инстанс был менее жирный, чем первый, конечно. За год с небольшим - не одной минуты даунтайма… т.е. даже дешманский подход, при правильной настройке, вполне тру

ну если ты точно уверен, то..у них указано с запасом. По факту у тебя есть сам гитлаб, есть раннеры, есть реджистри, база, много чего еще, что можно не юзать в коробке, типа вебсервера. Можешь начинать с минимума ресурсов под каждую сущность, а потом уже увеличивать, а некоторые, типа раннеров запускать по требованию. У меня гитлаб на synlogy nas работал на 2g ram.

Но под «нагрузку», что ты написал, выглядит это всё конечно очень смешно :)

Надеюсь, деньги на внедрение и поддержку вы посчитали заранее :)

Да нахер он нужен, это кубернетес

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

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

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

Это не сервис сложения 2 и 2, а сервис-швейцарский нож, который предоставляет кучу всего значительно упрощающего жизнь группе разработчиков и экономящего множество их времени. Если вам это не нужно, то к чему вообще вопрос? Делайте всё вручную, заодно сэкономите на электричестве и побережёте планету.

И как я уже сказал ранее, вышеописанная конфигурация это в разы более серьёзная нагрузка, чем заявленная в первом посте топика.