DevOps со отворен код во голем обем: GitLab на сопствена инфраструктура
Изворниот код е единственото добро за кое речиси сите технолошки фирми се согласуваат дека е критично, и истовремено она што повеќето го држат на инфраструктура што не ја поседуваат, во јурисдикција што не ја избрале, по договор што не го прочитале внимателно. Најчесто таквиот аранжман е сосема во ред. Сепак вреди да се знае колку чини алтернативата, зашто GitLab веќе повеќе од деценија прави навистина изводливо целиот развоен циклус да го хостирате сами.
Тоа е и производ чие бесплатно ниво е подарежливо, а оперативниот товар потежок отколку што повеќето очекуваат. И двете треба да се разберат пред одлуката, па овој водич зборува за тоа што GitLab во сопствена режија навистина е, што бесплатното ниво навистина дава и кои три оперативни проблеми носат најголем дел од маката.
Што е GitLab
Не е Git хостинг со прикачени додатоци. Апликација во Rails, PostgreSQL, Redis, Gitaly за складирање репозиториуми, Sidekiq за позадински задачи и регистар на контејнери, спакувани заедно како еден систем што покрива контрола на верзии, преглед на код, следење задачи, CI/CD, регистри на пакети и контејнери, безбедносно скенирање и распоредување.
Таа широчина е целиот аргумент. GitHub плус Actions плус Dependabot плус регистар на пакети плус алатка за следење проект даваат споредлив сет функции, склопен од делови. GitLab е една апликација со еден модел на дозволи и една база. Тоа е или токму она што го сакате, или повеќе отколку што ви треба, а кое од двете зависи од тоа колкав дел од циклусот навистина имате намера да го водите на едно место.
Архитектонски важниот факт е истиот како кај самостојното хостирање на аналитиката со Matomo, маркетинг автоматизацијата со Mautic или тимската комуникација со Mattermost: работи таму каде што ќе го поставите. Вашите репозиториуми, вашите CI логови, вашите артефакти, вашата база.
Сликата со лиценците, кажано директно
Ова навистина збунува и заслужува прецизност, зашто забуната оди во насока спротивна од очекуваната.
Постојат две дистрибуции на изворниот код. Community Edition е под MIT лиценца. Enterprise Edition има сопствена, порестриктивна лиценца што го покрива директориумот ee/ во репозиториумот. Досега звучи како вообичаениот модел на отворено јадро.
Она што изненадува: Linux пакетот што го инсталира речиси секој е билд на Enterprise Edition, и без внесен лиценцен клуч работи како ниво Free и се однесува како Community Edition. Значи не ја вртите дистрибуцијата под MIT, освен ако намерно сте го избрале CE пакетот. Во практика тоа ретко има значење, но ако вашата причина за самостојно хостирање е строга политика на отворен код а не контрола врз податоците, тогаш има огромно значење, а речиси никој не проверува.
Комерцијалните нивоа се Free, Premium по 29 долари по корисник месечно при годишна наплата и Ultimate со цена по договор. Premium додава напреден CI/CD, подобро управување со проекти и приоритетна поддршка. Ultimate го додава пакетот за безбедност и усогласеност: тестирање на безбедноста на апликациите, безбедност на синџирот на снабдување, скенирање на зависности. Двете платени нивоа сега вклучуваат GitLab Credits за функциите со вештачка интелигенција, 12 долари по корисник месечно кај Premium и 24 кај Ultimate.
А еве го фактот што на мнозинството тимови им ја менува сметката, и точната спротивност на состојбата кај Mattermost: нивото Free во сопствена режија нема ограничување на бројот корисници. Границата од пет корисници за која луѓето слушнале важи само за приватни групи на GitLab.com. Самостојно хостираниот Free ви дава неограничено корисници, контрола на верзии, CI/CD и регистри, а складиштето и runner-ите ги носите сами. Организација од сто инженери може целосно да работи на него.
Она од што се откажувате е безбедносното скенирање, известувањето за усогласеност, напредните правила за одобрување и поддршката. Ако потпаѓате под актот за сајбер отпорност и сакате скенирање на зависности и генерирање SBOM вградени во pipeline-ите наместо склопени од одделни алатки, тоа е разговор за Ultimate. За мнозинството други тимови Free не е пробен период. Тоа е одржливо трајно решение.
Поставување
Мала инсталација
GitLab е потежок отколку што изгледа. Документираната основа за еден јазол е 8 vCPU и 16 GB RAM, и за разлика од повеќето минимуми на производителите таа бројка е чесна, а не оптимистична. Може да се стисне во 8 GB, но се чувствува, а swap подобро да е исклучен, зашто swap-ирањето на оваа апликација е полошо од тоа воопшто да ја нема меморијата.
PostgreSQL е единствената поддржана база. Која верзија, зависи од вашата верзија на GitLab: 17.x бара PostgreSQL од 14.14 до 16.x, 18.x бара од 16.5 до 17.x, а 19.x бара 17.x. Се препорачува Redis 7.2, минимум е 7.0, а Valkey 7.2 служи како замена. Само самостојни инстанци, зашто кластерските и serverless варијантите на Redis не се поддржани.
Инсталирајте со Linux пакетот. Постојат Helm chart-ови, 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 правилно од прв пат, зашто таа вредност завршува вградена во адресите за клонирање, webhook-ите и адресите на регистарот.
Продукциска инсталација
GitLab објавува референтни архитектури од 1.000 до 50.000 корисници и вреди да се прочитаат дури и ако ниедна не ја применувате, зашто покажуваат која компонента прва станува тесно грло.
Советот што штеди најмногу пари доаѓа од самиот GitLab и зборува против сложеноста: под 3.000 корисници препорачуваат цврста стратегија за резервни копии наместо висока достапност. Документацијата е тука необично искрена и забележува дека пристапот со резервни копии има побавно време на закрепнување, но значи многу помала архитектура и пониски трошоци за одржување. Над 3.000 корисници, или таму каде што испадот навистина ја запира фирмата, високата достапност станува препорака.
Сфатете го тоа сериозно. Еден добро обезбеден јазол со тестирано враќање во практика е посигурен од полуразбран HA кластер и значително поевтин.
Артефактите, прикачените датотеки, LFS објектите и сликите на регистарот преместете ги во објектно складиште од самиот почеток. Истото размислување како секаде: го држи јазолот без состојба, копиите управливи, а миграцијата можна.
Трите работи што тргнуваат наопаку
Сè погоре стои во документацијата. Ова се оние што создаваат инциденти.
Вашата резервна копија не го содржи она што ја дешифрира
Ова е најважниот пасус во текстов.
gitlab-backup create опфаќа подоста: базата, репозиториумите, LFS објектите, CI артефактите и логовите на задачите, сликите на регистарот, wiki, прикачените датотеки, содржината на Pages, состојбата на Terraform, snippet-ите. Она што не го опфаќа е конфигурацискиот директориум, а особено /etc/gitlab/gitlab-secrets.json.
Таа датотека го чува клучот за шифрирање на базата. Документацијата е остра за последицата: ако ја изгубите, апликацијата GitLab нема да може да дешифрира ниту една шифрирана вредност во базата. Тоа значи CI/CD променливи, токени, тајни за двофакторска најава и акредитиви на интеграции. Би имале копија што се враќа во инстанца неспособна да ги прочита сопствените тајни.
Исклучени се и /etc/gitlab/gitlab.rb, TLS клучевите и сертификатите, SSH host клучевите, како и содржината на објектното складиште кога тоа е поставено. Последното ги фаќа токму оние што архитектонски ја направиле вистинската работа, па претпоставиле дека копијата го покрива тоа.
Затоа правете копија на /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.
Со секоја постојка одат позадински миграции што мора целосно да завршат пред да продолжите. Стартувањето на следната надградба додека миграциите сè уште работат е начинот на кој инстанците завршуваат во состојби што ги расплетува само поддршката. На голема инстанца тие миграции можат да траат со часови.
Две практични последици. Надградувајте редовно, зашто година одложени надградби е викенд последователни. И секогаш земајте го последното закрпено издание на целната помала верзија наместо првото, што документацијата го кажува изречно. GitLab одржува алатка што го пресметува патот на надградба за вас и подобро е да ја користите отколку да пресметувате сами.
Вистинскиот трошок седи кај runner-ите
Серверот на GitLab не го извршува вашиот CI. GitLab Runner е одделна компонента што ја инсталирате, конфигурирате и плаќате, на инфраструктура што ја обезбедувате вие. Free во сопствена режија не вклучува ниту една пресметковна минута, зашто нема вклучена пресметковна моќ што би се дала: сопствените машини ги носите вие.
Обично е тоа добра работа, зашто наменски runner чини помалку по минута од хостиран CI штом обемот стане сериозен, а на секој build можете да му дадете хардвер каков што му треба. Но тоа е вистинска инфраструктурна работа. Ќе носите одлуки за executor-ите, дали shell, Docker или Kubernetes; за автоскалирањето, за да не работат runner-ите на празно во три наутро; и за кеширањето, кое е разликата меѓу pipeline од четири и pipeline од четиринаесет минути.
Ставете ја флотата runner-и како посебна буџетска ставка. Тимовите што трошокот на самостојното хостирање го пресметуваат гледајќи само во јазолот на GitLab потценуваат многу, па празнината ја откриваат како редица задачи што чекаат.
Заминување од GitHub
Увозникот од GitHub е добар, значително подобар од повеќето миграциски алатки на добавувачите, и пренесува податоци од репозиториумот, гранки, LFS објекти, задачи и pull request-ови со нивните коментари, прегледи и одговори во дискусиите, wiki страници, изданија и прилози, ознаки, пресвртници, правила за заштита на гранки и соработници со мапирање на улогите.
Документираните празнини треба да се испланираат. Организациите и групите не преминуваат, па структурата на групите ја проектирате вие наместо да ја наследите, што обично е подобрување. Тековите на GitHub Actions не се претвораат во GitLab CI. Коментарите на pull request-ови постари од 2017 доаѓаат како одделни нишки поради ограничувања на GitHub API, а репозиториумите со над околу 30.000 коментари бараат вклучување на алтернативниот метод за увоз на коментари.
Бидејќи GitHub користи # и за задачи и за pull request-ови, а GitLab ги разликува, дел од вкрстените референци нема да се разрешат. Ништо не се губи, но линковите во старите дискусии може да покажуваат на погрешно место.
Планирајте го препишувањето на CI како вистинскиот проект, зашто тој и е. Сето друго е увоз што го пуштате и проверувате.
Европскиот агол
За фирмите што работат во Европа на трошокот му се придодава димензија на усогласеност. Изворниот код, pipeline-ите за градба и артефактите спаѓаат меѓу најчувствителните нешта што ги има една технолошка фирма, а каде живеат сè почесто е прашање што ви го поставуваат, а не такво на кое сами избирате да одговорите.
Сопственото хостирање ги сместува внатре во граница што ја контролирате, што со еден потег ја поедноставува анализата на преноси според ГДПР и прашањата за синџирот на снабдување од NIS2, и тоа е истиот аргумент за суверенитет околу кој е изграден Cloud and AI Development Act.
Поостра врска е актот за сајбер отпорност. Кој пушта софтвер на пазарот на ЕУ, ќе му требаат пописи на зависности, справување со ранливости и координиран процес на објавување. Тие обврски се исполнуваат во pipeline-от за градба а не во документ, а да ги имате pipeline-от, регистарот и скенирањето во еден систем со кој самите управувате го прави произведувањето докази значително помалку мачно отколку нивното собирање од четири добавувачи.
Кога не вреди
Ако сте помалку од дваесет инженери, нема регулаторен притисок ниту силни ставови за тоа каде живее кодот, земете SaaS. GitLab.com и GitHub се и двата одлични, а оперативната работа ќе чини повеќе од претплатата.
Ако вашата организација седи длабоко во екосистемот на GitHub, пребројте чесно што би изгубиле. Actions, marketplace и самата познатост на платформата кај секој кандидат што го вработувате се вистински вредности, а одговорот не гласи автоматски дека GitLab победува.
А ако никој нема да ја преземе инстанцата, не почнувајте воопшто. GitLab наградува некого што го крпи, ја следи флотата runner-и и го тестира враќањето. Без таа личност се изродува во незакрпена кутија што го држи вашето највредно добро, а тоа е полошо од SaaS-от од кој сакавте да заминете.
Како можеме да помогнеме
Поставуваме и одржуваме самостојно хостирана развојна инфраструктура за фирми што работат во Европа, вклучувајќи ги и деловите што никој не ги сака: секвенци на надградба низ задолжителните постојки, флоти runner-и што автоскалираат како што треба, миграции кон објектно складиште и шеми за копии што навистина биле враќани.
Ако сакате GitLab инстанца димензионирана чесно, миграција од GitHub планирана од некој што препишувањето на CI веќе го работел, или преглед дали вашата сегашна копија би преживеала судир со вистински дефект, пишете на office@c9group.dev. Повеќе за нашата работа со инфраструктура на страницата за оптимизација на AWS трошоците.
Ако составувате целосен самостојно хостиран стек, истото размислување важи за аналитиката, маркетинг автоматизацијата и тимската комуникација.
Објавено: 8 август 2026 Категории: DevOps, Отворен код, Приватност