В последнее время разработчики платного и даже бесплатного программного обеспечения закрывают доступ к своим продуктам пользователям и компаниям из России. А ведь для IТ-компаний проблемы с тем же трекером или хранилищем репозиториев грозят частичной или полной остановкой работы. В зоне повышенного риска — распределенные команды, для которых данные системы — место силы всей компании.
На связи Саша Хрущев, технический директор IT-компании WINFOX. Рассказываю, как мы быстренько развернули свое независимое локальное хранилище репозиториев в GitLab CE, сколько времени это заняло и какие особенности вам нужно учитывать при переезде, чтобы все прошло гладко.
Как все началось
В один прекрасный летний день Atlassian не дал нам продлить платную подписку на наш облачный Bitbucket. Из-за этого наши разработчики больше не могли пушить свои изменения и создавать merge-реквесты. Все это грозило замедлить нашу работу на неопределенный срок.
Подумав про себя «А нас-то за что?..», мы бросились искать варианты продления подписки. Это оказалось напрасно: варианты с VPN и прочими хитростями не сработали, и мы просто потратили наше драгоценное время впустую. Плюс все понимали: даже если сейчас этот фокус прокатит, то уже завтра ситуация гарантированно повторится.
Решение нужно было принимать очень быстро, так как любая проволочка грозила прямыми финансовыми потерями.
Мы поискали различные облачные альтернативы Bitbucket, включая отечественные облачные репозитории. Изучив доступные сервисы, поняли, что при выборе любого из этих вариантов сохраняется риск недоступности сервиса в случае каких-либо проблем. То есть мы рискуем снова потерять возможность пушить туда свои изменения, а то и доступ ко всему репозиторию.
В общем, мы решили разворачивать свое локальное хранилище репозиториев и сделать его полностью независимым от действий сторонних компаний.
Почему мы выбрали GitLab CE
Самое нормальное бесплатное решение, которое есть на рынке и которое обладает всем необходимым доступным функционалом, — это GitLab CE. Под всем необходимым доступным функционалом мы понимаем следующее:
безлимит репозиториев Git как по количеству, так и размерам;
безлимит юзеров;
CI/CD;
вебхуки;
интеграции с трекерами и прочими корпоративными системами;
вменяемый процесс бэкапирования.
На следующий день после блокировки доступа к Bitbucket мы начали переезд на GitLab CE. Об этом по порядку.
Этап 1. Установка
Прежде всего надо было установить GitLab на корпоративном сервере. Несмотря на то, что GitLab CE имеет достаточно подробную инструкцию по установке, в процессе установки возникли некоторые сложности. Вот главное, на что рекомендую обратить внимание при установке.
Конфигурация сервера. Сервер должен быть не менее 8 Гб оперативной памяти и 2 ядра процессора с нормальным большим дисковым хранилищем. Попытки экономии здесь обязательно выйдут боком — если не сразу, так потом.
Домен или поддомен. Они нужны изначально.
Установка на Ubuntu. Мы ставили GitLab на Ubuntu, использовали эту подробную инструкцию по установке.
Https в external_url. Обязательно ставьте https в external_url, так как GitLab умеет самостоятельно выпускать и использовать сертификаты от Let’s Encrypt. Если поставить https в external_url при установке, проблем в дальнейшем будет меньше.
Конфигурация ОС. Если локали на Linux не скофигурены должным образом, в процессе установки будут появляться ошибки. А именно невозможность поднять базу данных Postgres, локаль которой по умолчанию UTF-8.
Если вы столкнулись с подобным, помогут уже расписанные решения. Вот одно из таких решений.
Этап 2. Конфигурация
После установки настало время сконфигурировать. Немного расскажу, как делать изначальную настройку GitLab и как ее делали мы.
Главное на этом этапе — минимизировать время, за которое команда сможет полностью возобновить работы на новых репозиториях.
Регистрация. Чтобы ускорить регистрацию всех членов команды, мы оставили открытой регистрацию на главной странице.При этом мы ограничили возможности регистрации по строго определенному доменному имени e-mail. Таким образом, вся команда зарегистрируется сама, нам же останется сделать аппрув и доступы, после чего открытую регистрацию можно закрывать.
Импорт репозиториев. Пока команда регистрируется, импортируем репозитории. Этот процесс специфический для каждого из облачных репозиториев, но он подробно описан в документации для GitLab.
Большая часть репозиториев нормально импортируется автоматом, однако GitLab автоматически неправильно ставит имена репозиториев в которых есть «_» (нижнее подчеркивание). В сложных именах репозиториев вместо этого символа появляется пробел и система не может импортировать эти репозитории. Для таких репозиториев надо будет руками ввести нормальное имя, что немного задержит автоматический импорт.
Еще одна проблема, которая у нас всплыла, — не все репозитории скопировались нормально. Из более чем 140 репозиториев один скопировался не полностью, поэтому пришлось вручную переносить ветки. Это затянуло процесс импорта.
Этап 3. Настройка
После импорта репозиториев не стоит сразу раздавать доступы и приступать к работе. Если вам надо настроить вебхуки или прочие интеграции, самое время это сделать.
Группировка вебхуков. Для правильной настройки вебхуков надо правильно сгруппировать проекты.
В нашем процессе разработки вебхуки разделены по платформам/стеку. У других команд, например, они сгруппированы по проектам. Соответственно, надо сгруппировать репозитории. При этом путь к ним изменится. Именно поэтому до группировки не стоит раздавать доступы и скидывать URL репозиториев разработчикам, иначе им придется повторно менять эти URL у себя.
Раздача доступов. Как только группировка закончена, можно возобновлять работу с репозиторием и раздавать разработчикам доступы.
Можно считать, что с этого момента работа команды продолжится в нормальном режиме. Нам же ничто не мешает продолжать настройку.
Настройка вебхуков. После того, как мы перенесли все репозитории и раздали доступы, переходим к настройке GitLab, то есть настройке вебхуков.
У нас вебхуки используются для информирования в каналах дискорда о коммитах, пушах и merge-реквестах. Соответствующим образом настраиваются вебхуки для групп репозиториев. Кстати, в Bitbucket Cloud сделать это без определенной прослойки у нас не получилось, а в GitLab CE это без проблем заработало из коробки.
Настройка пайплайнов. Теперь настраиваем пайплайны CI-CD на новом месте. Это долгий процесс — у нас ушла почти неделя.
Настройка других полезных фич. Далее мы настроили несколько полезных вещей, которых не было ранее. Вот они:
уведомление руководства о событиях в репозиториях: все коммиты, мердж-реквесты, операции с ветками уходят письмами руководству компании;
интеграция с Sentry: получение инцидентов из веб-приложений в реальном времени и заведение их автоматом в GitLab;
заведение инцидентов через почту: аналогично Sentry, но инциденты создаются из писем на определенный ящик.
На этом переезд на Gitlab CE закончен.
Бонусом скажу про плюсы этого инструмента и покажу примерный roadmap переезда исходя из опыта.
Плюсы переезда на GitLab CE
Среди главных плюсов — экономия, независимость и широкие возможности кастомизации.
Экономия (внезапно). Мощный сервер под GitLab CE обошелся нам в 1,5 раза дешевле, чем мы платили за Bitbucket Cloud, а у нас не такая уж большая команда — GitLab используют 20 сотрудников. Для большой команды разница будет еще существеннее.
Независимость от политики и прочих мировых событий. GitLab CE — независимый веб-инструмент. А если хотите максимально минимизировать риски, можно выделить железный сервер в своем дата-центре под это дело. (Правда, с учетом реалий современного мира все равно ничто не гарантирует сохранность и доступность этого дата-центра).
Широчайшие возможности кастомизации. GitLab CE можно гибко настроить под себя, начиная от простой настройки до дописывания интеграционных прослоек. При этом возможностей гораздо больше, чем у самых дорогих облачных решений, например Bitbucket и GitHub.
Это просто приятно)
Примерный roadmap переезда на GitLab CE
Я посчитал, сколько времени занял переезд у нас. Это поможет вам спланировать время в своей команде.
Важно. Чтобы возобновить работу команды на новых репозиториях, вам, скорее всего, потребуется 5-6 часов или 2-3 часа при хорошем раскладе.
Полностью продублировать функционал своего предыдущего хранилища репозиториев, включая вебхуки и интеграции, вы сможете в течение 1-2 недель.
Что дальше
На очереди — дальнейшее изучение возможностей GitLab CE и настройка новых интеграций, например интеграции с таск-трекерам, базами знаний, мониторингом Prometeus и рассылкой уведомлений через Pushover.
Если интересно про это почитать, пишите в комментариях — буду рад поделиться опытом.
Комментарии (29)
metamorph
11.08.2022 18:15+1Настоятельно рекомендую:
отключить регистрацию
включить обязаловку 2fa (галка в админке)
закрыть инстанс вайтлистом (у гитлаба апишка наружу торчит, и не все методы оттуда Вы хотите экспозить)
AlexGluck
11.08.2022 21:48Я бы вообще завернул не на виртуалку, а на k3s однонодовый и закрыл впном.
Не только гитлаб, а всю инфраструктурную черёмуху.
Взял бы мидлового админа и отправил бы его доводить сервисы до полного автопилота.
metamorph
12.08.2022 10:43Любопытно.
А какие задачи и проблемы гитлаба в данном случае будет решать кубер, тем более однонодовый?
AlexGluck
12.08.2022 10:55-1Предоставлять возможность обновления без простоя?
Восстановление в случае сбоев?
Добавлять инструменты мониторинга, логирования?
Возможность расширить второй и более нод, для автоматического сканирования нагрузки?
Это инструмент, как колеса которые давно изобрели. Можно руками камни таскать, а можно на телеге возить.
metamorph
12.08.2022 11:51+2Вы написали стандартные buzzwords которые любому сервису неплохо бы иметь.
Конкретно в случае гитлаба:
Обновление без простоя требуется очень редко. Для SaaS - да, для селф-хостед - ну такое. Пушить в гитлаб в процессе обновления версии - не для слабонервных.
При серьезном сбое одной ноды кубер Вас никак не спасет.
Мониторинг и логи в гитлабе идут из коробки, если что. Хотите - используете встроенное, хотите - забираете метрики внешним сервисом с готового эндпоинта.
Про скейл желание понятно, но даже в доке гитлаба указано, что до 2000 юзеров легко умещаются в одну ноду. Воркеров надо выносить, конечно.
Ну то есть я намекаю на то, что профит с развертывания k3s достаточно небольшой. А вот дополнительную точку отказа (и сложность переконфигурации) Вы подкидываете. Зачем?..
AlexGluck
12.08.2022 12:16Было бы классно уважать и заботиться о людях, кстати разработчики\админы\девопсы это люди, кажется иногда об этом забывают.
Если в компании человек 100 разработчиков, то простой сервиса и потениальные опасности человеческого фактора при обновлении сервисов могут стоить организации простоя в работе. С другой стороны специалист которые сопровождает сервис, тоже человек и заставлять его работать ночами и в выходные, а потом ещё целый день без каких либо компенсаций плохо. Ведь можно выбрать другую архитектуру, которая избавит такой необходимости.
При сбое единственной ноды наверное всё сложно, но у вас появляется гибкая возможность эти ноды добавлять, а с добавлением и обслуживать эти ноды.
Сервисы сопровождения тоже надо сопровождать, а высокая сложность атомарного управления в случае единой коробки этому не способствует. Ну и сбор метрик это задача, у неё должна быть цель. Цель смотреть в красивую картинку, это не очень то ценно для бизнеса. Цель в поддержании работоспособности сервиса не требует наблюдения дашбордов, скорее определённого действия или предварительно поиска этого действия, его может выполнить и автоматика.
Не знаю в чём сложность добавить\изменить параметры конфигурации в value helm чарта и применить их.
TheKnight
12.08.2022 15:38А вы настраивали High Availability кластер Gitlab на базе CE? Сходу выглядит так, что просто две ноды не помогут вам.
DuD
12.08.2022 22:27На k3s который на виртуалке который на железном сервере который в колокейшне. Чтоб прям целая ИС получилось и команду саппорта на нее и отдел начальства :))
AlexGluck
12.08.2022 23:28Если нанять одного специалиста, то не придётся нанимать такое количество сотрудников непонятно зачем.
DuD
12.08.2022 23:45Непонятно зачем, это про k3s в текущем конфиге. Чтобы автоматом рестартить приложение не нужен k3s. Без даунтайма накатывать апдейты в данном конфиге, тоже такое себе. Ничего больше переключения балансера k3s тут не сделает. Зачем его тащить, не понятно.
AlexGluck
13.08.2022 00:24А какое приложения вы рестартить будете? Постгрес, нджинкс, гитали, сайдкик, ганикорн, эластик, графану, Прометей? Там ещё и другие есть компоненты гитлаба.
DuD
13.08.2022 00:31k3s не обладает AI и не особо думает что рестартить. Поднимает все что упало, но должно было работать. Сей уникальный функционал вполне доступен и без него.
AlexGluck
13.08.2022 00:34Можете конечно написать свой кубер, но нам надоело.
DuD
13.08.2022 00:38Чтобы сервисы рестартить хватает systemd из коробки. 3 строки конфига, одна из которых заголовок.
AlexGluck
13.08.2022 01:09Конечно, ведь именно поэтому есть хелсчеки, рэдинес-чеки, отдельно за процессом следит кубелет. База не может в дедлок уйти, место на диске не кончается. Логи ротирруются все правильно и живём мы в стране пони где единороги какают бабочками.
DuD
13.08.2022 01:18Да-да, вот именно что следить с k3s придется еще за +n сервисов, которые будут так же иметь возможность встать в дедлок и сожрать место. Или k3s нерушимый из вселенной с единорогами и бабочками?
А вообще очень рекомендую посмотреть на пакеты гитлаба и то как там все устроено. За последние 5 лет не пропустил ни одной версии. Обновление стоковым пакетным менеджером занимает порядка 5-7 минут. Пользователей чуть больше сотни. И ни разу за это время он не падал и есть не просил. Не говорю о том что ему не нужен резерв, скорее про то что однонодовый k3s с ним будет менее отказоустойчивый чем без него.
Lynx_PDA
11.08.2022 19:05+7Немного иронично получается, учитывая, что GitLab это Украинский стартап.
funca
11.08.2022 22:11Скорее с украинскими корнями. А так они в юрисдикции USA, что в прочем в контексте топика все равно звучит как анекдот - помню ещё несколько лет тому назад были шумные новости, что они перестали хантить удаленщиков для работы с sensitive data из стран с тоталитарными режимами.
TheKnight
11.08.2022 21:34+1А как вы планируете решать проблемы доступности при отказе вашего сервера?
funca
11.08.2022 22:23Там ребята всеми силами пытаются склонять пользователей на покупку платной версии. Разумеется не пряниками. Поэтому ограничения у CE вылезают в самых неожиданных местах. Например он не позволяет добавить более одного код ревьювера, не сбрасывает флажок апрува если запушить новое измерение и ещё over 9K мелких пакостей. Если что-то не нравится, то законтрибьютить фикс вам просто так не дадут по тем же самым причинам. Плюс риски из-за их юрисдикции - будучи американской компанией, они обязаны подчиняться требованиям местных властей. Лучше посмотрите свободные аналоги без этих энтерпрайзов за спиной, тот же Gitea.
select26
11.08.2022 23:54Уважаемый Саша Хрущев, технический директор IT-компании WINFOX!
Тему вы подняли интересную, но технические детали стоили бы описать подробнее.
Что значит "Обязательно ставьте https в external_url"? Где ставьте? Что "ставьте"?
"Если локали на Linux не скофигурены должным образом, в процессе установки будут появляться ошибки." Что значит "должным образом"? Неужели сложно указать перечень необходимых локалей?
Про феерию с импортом уже написали выше.
В общем, повторюсь, тема актуальная. Спасибо!
Но изложение не тянет никак на уровень технического директора. Постарайтесь вычитать пожалуйста.
Spider55
12.08.2022 10:03А как быть с тем, что он тормоз? Может есть у кого конкретный пример настройки на ускорение?
Суть проблемы: тыкаем в любой репозиторий, а он задумывается на секунды и потом только его отображает. И так почти любой переход по UI самого гитлаба.
Сервер крутит его достаточно мощный: 24 ядра Xeon(R) X5650 и 128 Гб оперативки. Но там 99% ресурсов просто простаивает и gitlab не хочет их брать. Может можно какое-то кэширование приподнять?
Я глубоко в него не погружался :(
AlexBream
12.08.2022 10:16+1От "технического директора" ожидается статья никак не уровня "как развернули", а скорее "из чего выбирали", "как проводили сравнение", "какие цифры для анализа были получены/каком образом"... как-то так
А рассказ галопом по европам "как мы с одной иглы перескочили на другую" в виде конспекта "делай так" - даже неинтересно.
Я допускаю, что "при всем богатстве выбора другой альтернативы нет", но хотелось бы видеть обоснуй
beremour
12.08.2022 17:25+1Прикольно читать, как бывшие плюсы пререезда В облако теперь превратились в плюсы перезеда ИЗ облака :-)
screwer
Двухъядерный сервер ? Сэкономить ? Да сейчас смартфоны имеют лучшие ТТХ, чем вы привели)))
1) клонируем свои репозитории как bare
2) имея корректную копию "на руках" пушим в гитлаб. Даже если что-то пройдет не тек - всегда можно повторить.
ЗЫ: получить bare репозиторий из полного обычного можно склонировав его с опцией --bare. И наоборот.
Кстати, учтите что могут быть проблемы со штатным (gitlab) развертыванием бесплатных Let's encrypt сертификатов с российского ИП. Через VPN все работает как и должно.
Во-сколько ? Почему не рассматривали вариант поднять сервер локально. Для 20 человек ваш гитлаб сервер будет простаивать большую часть времени.