DevOps с отворен код в голям мащаб: собствен GitLab

Изходният код е единственият актив, за който почти всяка технологична компания е съгласна, че е критичен, и същевременно този, който повечето от тях държат на инфраструктура, която не притежават, в юрисдикция, която не са избрали, по договор, който не са прочели внимателно. Обикновено това е напълно приемливо. Все пак си струва да знаете колко струва алтернативата, защото от над десет години GitLab прави самостоятелния хостинг на целия цикъл на разработка наистина практичен.

Това е и продукт, чийто безплатен план е по-щедър, а поддръжката му е по-тежка, отколкото повечето хора очакват. И двете неща трябва да са ви ясни, преди да се обвържете, затова това ръководство обяснява какво всъщност е GitLab self-managed, какво наистина ви дава безплатният план и кои са трите оперативни проблема, които причиняват по-голямата част от главоболията.

Какво е GitLab

Не е Git хостинг с допълнения, закачени отстрани. Това е Rails приложение, PostgreSQL, Redis, Gitaly за съхранение на хранилищата, Sidekiq за фоновите задачи и регистър за контейнери, пакетирани заедно като една система, която покрива контрола на версиите, прегледа на кода, проследяването на задачи, CI/CD, регистрите за пакети и контейнери, сканирането за сигурност и внедряването.

Тази широта е целият аргумент. GitHub плюс Actions плюс Dependabot плюс регистър за пакети плюс инструмент за проследяване на проекти е сравним набор от функции, сглобен от части; GitLab е едно приложение с един модел на правата и една база данни. Това е или точно каквото искате, или повече, отколкото ви трябва, а кое от двете зависи от това каква част от цикъла наистина смятате да държите на едно място.

Важният архитектурен факт е същият като при собствения хостинг на аналитиката с Matomo, маркетинговата автоматизация с Mautic или екипния чат с Mattermost: работи там, където го сложите. Вашите хранилища, вашите CI журнали, вашите артефакти, вашата база данни.

Лицензите, казано направо

Тук наистина е объркващо и си струва да сме точни, защото объркването е в обратна посока на това, което хората очакват.

Има две дистрибуции на изходния код. Community Edition е под лиценз MIT. Enterprise Edition има собствен, по-рестриктивен лиценз, който покрива директорията ee/ в хранилището. Дотук изглежда като обичайния модел open core.

Изненадващата част: Linux пакетът, който почти всички инсталират, е компилацията на Enterprise Edition и без приложен лицензен ключ работи като план Free, който се държи като Community Edition. Не използвате дистрибуцията под лиценз MIT, освен ако съзнателно не сте избрали пакета CE. На практика това рядко има значение, но ако причината за собствения хостинг е строга политика за отворен код, а не контролът върху данните, значението е огромно и почти никой не проверява.

Платените планове са Free, Premium за 29 долара на потребител на месец при годишно плащане и Ultimate с цена по договаряне. Premium добавя разширени възможности за CI/CD, по-добро управление на проекти и приоритетна поддръжка. Ultimate добавя пакета за сигурност и съответствие: тестване на сигурността на приложенията, сигурност на веригата на доставки, сканиране на зависимостите. И двата платени плана в момента включват GitLab Credits за функциите с ИИ: 12 долара на потребител на месец при Premium и 24 при Ultimate. На страницата си с цени GitLab нарича тези включени кредити ограничена във времето промоционална оферта, която може да бъде променена по преценка на GitLab.

Ето факта, който променя сметката за повечето екипи и е точно обратното на ситуацията с Mattermost: планът Free при self-managed няма ограничение за броя потребители. Ограничението от петима потребители, за което хората са чували, важи само за частни групи в GitLab.com. Безплатният самостоятелно хостван GitLab ви дава неограничен брой потребители, контрол на версиите, CI/CD и регистри, а хранилището и runners осигурявате вие. Организация със сто инженери може да работи изцяло на него.

Това, от което се отказвате, е сканирането за сигурност, отчетите за съответствие, разширените правила за одобрение и поддръжката. Ако за вас важи Актът за киберустойчивост и искате сканирането на зависимостите и генерирането на SBOM да са вградени в конвейерите ви, а не сглобени от отделни инструменти, това е разговор за Ultimate. За повечето други екипи Free не е пробен период. Той е жизнеспособно постоянно решение.

Инсталиране

Малко внедряване

GitLab е по-тежък, отколкото изглежда. Документираният минимум за един възел е 8 vCPU и 16 GB RAM и за разлика от повечето минимални изисквания на доставчиците тази цифра е честна, а не оптимистична. Може да се събере и в 8 GB, но ще го усетите, а swap трябва да е изключен, защото суапването на това приложение е по-лошо от липсата на памет.

PostgreSQL е единствената поддържана база данни. Версията зависи от версията на GitLab: 17.x изисква PostgreSQL от 14.14 до 16.x, 18.x изисква от 16.5 до 17.x, а 19.x изисква от 17.x до 18.x. Препоръчва се Redis 7.2, като минимумът е 7.0, а Valkey 7.2 работи като заместител. Само самостоятелни инстанции, защото клъстерните и serverless вариантите на Redis не се поддържат.

Инсталирайте с Linux пакета. Има Helm charts, Operator, Docker образи и инсталиране от изходен код, но Linux пакетът е най-зрелият вариант и на него работи самият GitLab.com. Той включва PostgreSQL, Redis и Sidekiq, което означава, че с една машина и един конфигурационен файл получавате работеща инстанция.

# /etc/gitlab/gitlab.rb
external_url 'https://git.example.com'

# Let's Encrypt, on by default when external_url is https
letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ['ops@example.com']

# Keep Puma and Sidekiq honest on a small box
puma['worker_processes'] = 2
sidekiq['max_concurrency'] = 9

# Move artefacts and uploads off local disk early
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
  'provider' => 'AWS',
  'region' => 'eu-central-1',
  'aws_access_key_id' => 'REPLACE_ME',
  'aws_secret_access_key' => 'REPLACE_ME'
}

Изпълнете gitlab-ctl reconfigure и имате инстанция. Задайте external_url правилно още първия път, защото той се вгражда в URL адресите за клониране, уебкуковете и адресите на регистъра.

Производствено внедряване

GitLab публикува референтни архитектури за от 1 000 до 50 000 потребители и те си струват прочита, дори никога да не внедрите някоя от тях, защото показват кой компонент пръв се превръща в тясно място.

Съветът, който спестява най-много пари, е на самия GitLab и е против усложняването: под 3 000 потребители те препоръчват солидна стратегия за резервни копия вместо висока достъпност. Документацията е необичайно откровена по въпроса и отбелязва, че подходът с резервни копия „наистина има по-бавно възстановяване", но „означава много по-малка архитектура и по-ниски разходи за поддръжка". Над 3 000 потребители или когато прекъсването наистина спира компанията, HA става препоръката.

Приемете това сериозно. Един възел с добри резервни копия и тествано възстановяване е на практика по-надежден от наполовина разбран HA клъстер и е много по-евтин.

Преместете артефактите, качените файлове, LFS обектите и образите в регистъра в обектно хранилище от самото начало. Същата логика като навсякъде другаде: възелът остава без състояние, резервните копия остават управляеми, а миграцията остава възможна.

Трите неща, които се объркват

Всичко дотук е в документацията. Тези три неща са тези, които водят до инциденти.

Резервното ви копие не съдържа това, с което се дешифрира

Това е най-важният абзац в тази статия.

gitlab-backup create обхваща много: базата данни, хранилищата, LFS обектите, CI артефактите и журналите на задачите, образите в регистъра, уикитата, качените файлове, съдържанието на Pages, Terraform състоянието, фрагментите код. Не обхваща обаче конфигурационната директория и по-конкретно /etc/gitlab/gitlab-secrets.json.

Този файл съдържа ключа за криптиране на базата данни. Документацията е безпощадно ясна за последствията: „Ако го загубите, приложението GitLab няма да може да дешифрира нито една криптирана стойност в базата данни." Това означава CI/CD променливите, токените, тайните за двуфакторна автентикация и идентификационните данни на интеграциите. Ще имате резервно копие, което се възстановява в инстанция, неспособна да прочете собствените си тайни.

Също така изключени са: /etc/gitlab/gitlab.rb, TLS ключовете и сертификатите, SSH ключовете на хоста и съдържанието на обектното хранилище, когато такова е конфигурирано. Последното хваща хората, които са направили правилното от архитектурна гледна точка и после са приели, че резервното копие го покрива.

Затова правете резервно копие на /etc/gitlab отделно, съхранявайте го другаде, а не до архива, защото то е ключът към архива, и след това възстановете всичко на тестова машина и проверете, че можете да влезете и да прочетете CI променлива. Нетестваното възстановяване не е резервно копие, а при GitLab нетестваното възстановяване обикновено е развалено.

Не можете да надградите с един скок

GitLab има задължителни спирки при надграждане и това не е препоръка. Не можете да ги прескочите. От 17.5 спирките са предвидими и се падат на x.2, x.5, x.8 и x.11, така че надграждането от 18.0 до 19.2 означава първо да спрете на 18.2, 18.5, 18.8 и 18.11. 19.0 не е спирка, така че от 18.11 преминавате направо на 19.2.

Всяка спирка включва фонови миграции, които трябва да завършат напълно, преди да преминете към следващата. Започването на следващото надграждане, докато миграциите още вървят, е начинът, по който инстанциите попадат в състояния, за чието разплитане е нужна поддръжката. При голяма инстанция тези миграции може да отнемат часове.

Две практически последици. Надграждайте редовно, защото година отлагани надграждания е един уикенд последователни надграждания. И винаги вземайте последното издание с корекции на целевата минорна версия, а не първото, както документацията изрично посочва. GitLab поддържа инструмент за пътя на надграждане, който изчислява последователността вместо вас, и си струва да го използвате, вместо да я изчислявате сами.

Истинският разход са runners

Сървърът на GitLab не изпълнява вашия CI. GitLab Runner е отделен компонент, който инсталирате, конфигурирате и плащате вие, върху инфраструктура, която осигурявате вие. Self-managed Free не включва никакви изчислителни минути, защото няма включени изчислителни ресурси, които да се дадат: машините са ваши.

Обикновено това е изгодно, тъй като собственият runner е по-евтин на минута от хостван CI при сериозен обем и можете да закачите какъвто хардуер изисква дадена компилация. Но това е истинска инфраструктурна работа. Ще вземате решения за изпълнителите (shell, Docker или Kubernetes), за автоматичното мащабиране, така че runners да не стоят без работа в три сутринта, и за кеширането, което прави разликата между конвейер от четири минути и такъв от четиринадесет.

Планирайте бюджета за парка от runners като отделен ред. Екипите, които моделират разходите за собствен хостинг, като гледат само възела на GitLab, ги подценяват значително и после откриват недостига като опашка от чакащи задачи.

Миграция от GitHub

Инструментът за импорт от GitHub е добър, значително по-добър от повечето инструменти за миграция на доставчиците, и пренася данните от хранилищата, клоновете, LFS обектите, задачите и pull заявките с техните коментари, прегледи и отговори в дискусиите, уики страниците, изданията и прикачените файлове, етикетите, етапите, правилата за защита на клонове и сътрудниците със съпоставяне на ролите.

Документираните пропуски трябва да се вземат предвид при планирането. Организациите и групите не се пренасят, така че структурата на групите проектирате вие, вместо да я наследите, което обикновено е подобрение. Работните потоци на GitHub Actions не се преобразуват в GitLab CI. Коментарите в pull заявки отпреди 2017 г. се импортират като отделни нишки заради ограничения на GitHub API, а за хранилища с повече от приблизително 30 000 коментара трябва да се включи алтернативният метод за импорт на коментари.

Тъй като GitHub използва # както за задачите, така и за pull заявките, а GitLab ги разграничава, някои кръстосани препратки няма да се разрешат. Нищо не се губи, но връзките в стари дискусии може да сочат към грешното място.

Планирайте пренаписването на CI като същинския проект, защото то е точно това. Всичко останало е задача за импорт, която можете да пуснете и да проверите.

Европейският аспект

За компаниите, които работят в Европа, има и измерение на съответствието отвъд разходите. Изходният код, конвейерите за компилация и артефактите са сред най-чувствителните неща, които една технологична компания притежава, а къде се намират, все по-често е въпрос, който ви задават, а не такъв, на който сами решавате да отговорите.

Собственият хостинг ги поставя в граници, които контролирате, което с един ход опростява анализа на предаването на данни по ОРЗД и въпросите за веригата на доставки по NIS2, и това е същият аргумент за суверенитет, върху който е изграден Актът за развитие на облака и ИИ.

По-пряката връзка е с Акта за киберустойчивост. Ако пускате софтуер на пазара на ЕС, ще ви трябват описи на зависимостите, обработка на уязвимостите и процес за координирано разкриване. Тези задължения се изпълняват в конвейера ви за компилация, а не в документ, и когато конвейерът, регистърът и сканирането са в една система, която управлявате вие, събирането на доказателствата е значително по-малко болезнено, отколкото сглобяването им от четирима доставчици.

Кога не си струва

Ако имате под двадесет инженери, нямате регулаторен натиск и не ви интересува особено къде стои кодът, използвайте SaaS. И GitLab.com, и GitHub са отлични, а оперативната работа ще ви струва повече от абонамента.

Ако организацията ви е дълбоко навлязла в екосистемата на GitHub, пресметнете честно какво бихте загубили. Actions, маркетплейсът и самото познаване на платформата от всеки кандидат, когото наемате, са реални активи и отговорът не е автоматично, че GitLab печели.

А ако никой няма да отговаря за инстанцията, не започвайте. GitLab се отплаща на собственик, който го обновява, следи парка от runners и тества възстановяването. Без такъв човек той се превръща в необновявана машина, която държи най-ценния ви актив, а това е по-лошо от SaaS, от който сте се опитвали да избягате.

Помощ

Внедряваме и поддържаме самостоятелно хоствана инфраструктура за разработка за компании, които работят в Европа, включително частите, които никой не обича: последователности на надграждане през задължителните спирки, паркове от runners, които се мащабират правилно, миграции към обектно хранилище и схеми за резервни копия, които наистина са били възстановявани.

Ако искате GitLab инстанция, оразмерена честно, миграция от GitHub, планирана от човек, който вече е пренаписвал CI, или преглед дали сегашното ви резервно копие би издържало сблъсъка с истински срив, пишете ни на office@c9group.dev. Повече за инфраструктурната ни работа има на страницата за оптимизация на разходите в AWS.

Ако сглобявате цял самостоятелно хостван стек, същата логика важи и за аналитиката, маркетинговата автоматизация и екипните съобщения.

---

Публикувано: 8 август 2026 г. · Актуализирано: 10 октомври 2026 г. Категории: DevOps, отворен код, поверителност