Comments 39
Сервер должен быть не менее 8 Гб оперативной памяти и 2 ядра процессора с нормальным большим дисковым хранилищем. Попытки экономии здесь обязательно выйдут боком — если не сразу, так потом.
Двухъядерный сервер ? Сэкономить ? Да сейчас смартфоны имеют лучшие ТТХ, чем вы привели)))
импортируем репозитории. Этот процесс специфический для каждого из облачных репозиториев
1) клонируем свои репозитории как bare
2) имея корректную копию "на руках" пушим в гитлаб. Даже если что-то пройдет не тек - всегда можно повторить.
ЗЫ: получить bare репозиторий из полного обычного можно склонировав его с опцией --bare. И наоборот.
Кстати, учтите что могут быть проблемы со штатным (gitlab) развертыванием бесплатных Let's encrypt сертификатов с российского ИП. Через VPN все работает как и должно.
Мощный сервер под GitLab CE обошелся нам в 1,5 раза дешевле, чем мы платили за Bitbucket Cloud
Во-сколько ? Почему не рассматривали вариант поднять сервер локально. Для 20 человек ваш гитлаб сервер будет простаивать большую часть времени.
Периодически гоняем мысль в голове взять один из своих серверов, нарезать виртуалку и развернуть репы там, но каждый раз находится больше "против" чем "за". В первую очередь из-за сетевой инфраструктуры - к сожалению у провайдеров в городе регулярно бывают проблемы и даже наличие двух каналов не гарантирует доступность. Во вторую - железный сервак это не только мощно и шумно, случается так что надо с ним что-то так же физически делать, а для этого нужен админ в офисе. В эпоху удаленки это роскошь. Так что пока что облако.
По поводу импорта через bare - может я чего не понимаю, но из Bitbucket в GitLab это можно сделать строго по одному. А это 140+ реп на минутку...
но из Bitbucket в GitLab это можно сделать строго по одному
Этого не может быть. Сильно сомневаюсь, что BitBucket не способен отдавать больше одного репозитория одновременно (иначе что у вас за совместная работа тогда?). Гилаб же способен пушить столько репозиторев сразу, сколько у вас железо вытянет.
Устриц ел, имею две виртуалки с инстансами гитлаба. Одна на 2,387 проектов, 303 группы, около 6-7 Тб. Вторая на 7,803 проектов, 1,579 групп, около 35 Тб.
Первый переводил с CE на EE с прыжком через 2 мажорные версии. Официально такой апгрейд не поддерживается. Переносил записи в БД "вручную", делая запросы в старом инстансе, и создавая нужные записи в новом. Там не такая уж сложная схема оказалась.
А это 140+ реп на минутку...
На одной странице выдачи 20 реп. Т.е. это всего лишь 7 страниц скопипастить в шелл скрипт, и чуть-чуть текст обработать. Делов минут на 15. Это же не тысячи проектов, для которых имеет смысл писать автоматизированный скрипт.
Настоятельно рекомендую:
отключить регистрацию
включить обязаловку 2fa (галка в админке)
закрыть инстанс вайтлистом (у гитлаба апишка наружу торчит, и не все методы оттуда Вы хотите экспозить)
Я бы вообще завернул не на виртуалку, а на k3s однонодовый и закрыл впном.
Не только гитлаб, а всю инфраструктурную черёмуху.
Взял бы мидлового админа и отправил бы его доводить сервисы до полного автопилота.
Любопытно.
А какие задачи и проблемы гитлаба в данном случае будет решать кубер, тем более однонодовый?
Предоставлять возможность обновления без простоя?
Восстановление в случае сбоев?
Добавлять инструменты мониторинга, логирования?
Возможность расширить второй и более нод, для автоматического сканирования нагрузки?
Это инструмент, как колеса которые давно изобрели. Можно руками камни таскать, а можно на телеге возить.
Вы написали стандартные buzzwords которые любому сервису неплохо бы иметь.
Конкретно в случае гитлаба:
Обновление без простоя требуется очень редко. Для SaaS - да, для селф-хостед - ну такое. Пушить в гитлаб в процессе обновления версии - не для слабонервных.
При серьезном сбое одной ноды кубер Вас никак не спасет.
Мониторинг и логи в гитлабе идут из коробки, если что. Хотите - используете встроенное, хотите - забираете метрики внешним сервисом с готового эндпоинта.
Про скейл желание понятно, но даже в доке гитлаба указано, что до 2000 юзеров легко умещаются в одну ноду. Воркеров надо выносить, конечно.
Ну то есть я намекаю на то, что профит с развертывания k3s достаточно небольшой. А вот дополнительную точку отказа (и сложность переконфигурации) Вы подкидываете. Зачем?..
Было бы классно уважать и заботиться о людях, кстати разработчики\админы\девопсы это люди, кажется иногда об этом забывают.
Если в компании человек 100 разработчиков, то простой сервиса и потениальные опасности человеческого фактора при обновлении сервисов могут стоить организации простоя в работе. С другой стороны специалист которые сопровождает сервис, тоже человек и заставлять его работать ночами и в выходные, а потом ещё целый день без каких либо компенсаций плохо. Ведь можно выбрать другую архитектуру, которая избавит такой необходимости.
При сбое единственной ноды наверное всё сложно, но у вас появляется гибкая возможность эти ноды добавлять, а с добавлением и обслуживать эти ноды.
Сервисы сопровождения тоже надо сопровождать, а высокая сложность атомарного управления в случае единой коробки этому не способствует. Ну и сбор метрик это задача, у неё должна быть цель. Цель смотреть в красивую картинку, это не очень то ценно для бизнеса. Цель в поддержании работоспособности сервиса не требует наблюдения дашбордов, скорее определённого действия или предварительно поиска этого действия, его может выполнить и автоматика.
Не знаю в чём сложность добавить\изменить параметры конфигурации в value helm чарта и применить их.
На k3s который на виртуалке который на железном сервере который в колокейшне. Чтоб прям целая ИС получилось и команду саппорта на нее и отдел начальства :))
Если нанять одного специалиста, то не придётся нанимать такое количество сотрудников непонятно зачем.
Непонятно зачем, это про k3s в текущем конфиге. Чтобы автоматом рестартить приложение не нужен k3s. Без даунтайма накатывать апдейты в данном конфиге, тоже такое себе. Ничего больше переключения балансера k3s тут не сделает. Зачем его тащить, не понятно.
А какое приложения вы рестартить будете? Постгрес, нджинкс, гитали, сайдкик, ганикорн, эластик, графану, Прометей? Там ещё и другие есть компоненты гитлаба.
k3s не обладает AI и не особо думает что рестартить. Поднимает все что упало, но должно было работать. Сей уникальный функционал вполне доступен и без него.
Можете конечно написать свой кубер, но нам надоело.
Чтобы сервисы рестартить хватает systemd из коробки. 3 строки конфига, одна из которых заголовок.
Конечно, ведь именно поэтому есть хелсчеки, рэдинес-чеки, отдельно за процессом следит кубелет. База не может в дедлок уйти, место на диске не кончается. Логи ротирруются все правильно и живём мы в стране пони где единороги какают бабочками.
Да-да, вот именно что следить с k3s придется еще за +n сервисов, которые будут так же иметь возможность встать в дедлок и сожрать место. Или k3s нерушимый из вселенной с единорогами и бабочками?
А вообще очень рекомендую посмотреть на пакеты гитлаба и то как там все устроено. За последние 5 лет не пропустил ни одной версии. Обновление стоковым пакетным менеджером занимает порядка 5-7 минут. Пользователей чуть больше сотни. И ни разу за это время он не падал и есть не просил. Не говорю о том что ему не нужен резерв, скорее про то что однонодовый k3s с ним будет менее отказоустойчивый чем без него.
регистрацию отключили как все зарегались, 2fa сделали, а насчет апишки и вайтлиста - спасибо, не подумали
Скорее с украинскими корнями. А так они в юрисдикции USA, что в прочем в контексте топика все равно звучит как анекдот - помню ещё несколько лет тому назад были шумные новости, что они перестали хантить удаленщиков для работы с sensitive data из стран с тоталитарными режимами.
off:
хранилище репозиториев
Это как договорной контракт или песочный песок.
А как вы планируете решать проблемы доступности при отказе вашего сервера?
Там ребята всеми силами пытаются склонять пользователей на покупку платной версии. Разумеется не пряниками. Поэтому ограничения у CE вылезают в самых неожиданных местах. Например он не позволяет добавить более одного код ревьювера, не сбрасывает флажок апрува если запушить новое измерение и ещё over 9K мелких пакостей. Если что-то не нравится, то законтрибьютить фикс вам просто так не дадут по тем же самым причинам. Плюс риски из-за их юрисдикции - будучи американской компанией, они обязаны подчиняться требованиям местных властей. Лучше посмотрите свободные аналоги без этих энтерпрайзов за спиной, тот же Gitea.
Уважаемый Саша Хрущев, технический директор IT-компании WINFOX!
Тему вы подняли интересную, но технические детали стоили бы описать подробнее.
Что значит "Обязательно ставьте https в external_url"? Где ставьте? Что "ставьте"?
"Если локали на Linux не скофигурены должным образом, в процессе установки будут появляться ошибки." Что значит "должным образом"? Неужели сложно указать перечень необходимых локалей?
Про феерию с импортом уже написали выше.
В общем, повторюсь, тема актуальная. Спасибо!
Но изложение не тянет никак на уровень технического директора. Постарайтесь вычитать пожалуйста.
Спасибо за фидбек) По ссылкам, которые я привел, как раз и раскрываются ответы на первые два вопроса:
1) В конфигурационном файле /etc/gitlab/gitlab.rb есть такая настройка external_url
2) Переменные LANG and LC_* на чистых инстансах Ubuntu не всегда изначально заданы и, если вы получаете при установке такую проблему, как у меня - задайте их сообразно инструкции, ссылка на ктороую приведена в статье
3) По поводу импорта, возможно, у меня не хватает знаний, но экспорт-импорт через bare в случае Bitbucket Cloud -> GitLab выглядит как будто надо делать это для каждой репы отдельно. Это пугает, их там 140+ штук
А как быть с тем, что он тормоз? Может есть у кого конкретный пример настройки на ускорение?
Суть проблемы: тыкаем в любой репозиторий, а он задумывается на секунды и потом только его отображает. И так почти любой переход по UI самого гитлаба.
Сервер крутит его достаточно мощный: 24 ядра Xeon(R) X5650 и 128 Гб оперативки. Но там 99% ресурсов просто простаивает и gitlab не хочет их брать. Может можно какое-то кэширование приподнять?
Я глубоко в него не погружался :(
От "технического директора" ожидается статья никак не уровня "как развернули", а скорее "из чего выбирали", "как проводили сравнение", "какие цифры для анализа были получены/каком образом"... как-то так
А рассказ галопом по европам "как мы с одной иглы перескочили на другую" в виде конспекта "делай так" - даже неинтересно.
Я допускаю, что "при всем богатстве выбора другой альтернативы нет", но хотелось бы видеть обоснуй
Как написал в начале статьи, все случилось как всегда ВНЕЗАПНО и времени на "из чего выбирали", "проводили сравнение", к сожалению, не было, здесь речи не шло о каком-то стратегическом взвешенном решении. Тут скорее умудрились наступить на грабли которые слишком явно торчали из травы и статья как раз о минимизации вреда от удара ими по башке. Вред = время простоя, в течение которого тестеры и клиенты не получают сборки. Выбирали по принципу с чем работали ранее, у нас несколько проектов велось и ведется до сих пор в гитлабе заказчика.
Да, я прочитал в оригинале
В один прекрасный летний день Atlassian не дал нам продлить платную подписку на наш облачный Bitbucket. Из-за этого наши разработчики больше не могли пушить свои изменения и создавать merge-реквесты. Все это грозило замедлить нашу работу на неопределенный срок.
и могу сказать, что "прэлэстно, просто прэлэстно": иметь в качестве инструмента DVCS и полностью пролюбить букву D, c гиперцентрализацией и POF. И это при том, что используется от Bitbucket, судя по тексту, всего ничего (вот с GitHub нынешнего, если его использовать на все деньги с CI + Actions, так легко не соскочить), что можно легко делать и чистым гитом. Может не так красиво и без гуев, но "вам шашечки или ехать"?
Прикольно читать, как бывшие плюсы пререезда В облако теперь превратились в плюсы перезеда ИЗ облака :-)
А оказывается еще не у всех есть куб)))
Личный опыт: переезд на собственное хранилище репозиториев в GitLab CE