# GitLab ## Що це таке GitLab — це єдиний застосунок, побудований довкола git-репозиторіїв: він зберігає код і додає до нього merge request для рев'ю, issues для планування та вбудовану систему CI/CD, яка збирає, тестує й розгортає з того самого місця. Від інших його відрізняє вибір того, де він працює. Той самий продукт доступний як GitLab.com, сервіс, який GitLab веде сам; як GitLab Self-Managed, який встановлюють на власні сервери; і як GitLab Dedicated, окремий екземпляр для одного клієнта, який GitLab розміщує й обслуговує в регіоні AWS, обраному цим клієнтом. Під усім цим лежить звичайний git. Кожен проєкт — це git-репозиторій, який можна клонувати, надсилати в нього зміни й отримувати їх звичними командами, а історія в клоні повна. Усе, що GitLab додає зверху, від обговорень під час рев'ю та issues до результатів конвеєрів і прав доступу, зберігає сам GitLab поза репозиторієм, і клон нічого з цього не несе. Merge request — це назва, яку GitLab дає запропонованій зміні, що чекає на злиття; інші платформи називають ту саму ідею pull request. Документація описує його як центральне місце, де переглядають код, ведуть обговорення і відстежують зміну. На одній сторінці видно опис, зміни в коді з коментарями до окремих рядків, стан конвеєрів CI/CD, звіти про те, чи можна зміну злити, і список комітів. Merge request можна пов'язати з issue, і тоді він автоматично закриє це issue під час злиття. Усталено основну гілку проєкту, зазвичай main, захищено, і зливати в неї можуть лише люди з роллю Maintainer або вищою. Систему CI/CD налаштовують у файлі `.gitlab-ci.yml` у корені проєкту. Він визначає етапи, завдання та скрипти, з яких складається конвеєр: етапи задають порядок, наприклад збирання, потім тести, потім розгортання, а завдання — це роботи, які виконуються на кожному етапі. Завдання виконує GitLab Runner, окрема програма, написана мовою Go й поширювана як один бінарний файл. Runner під'єднується до екземпляра GitLab, чекає на завдання, виконує кожне просто на машині, у контейнері Docker або на віддаленому сервері через SSH і повідомляє результат назад. ## Чому це важливо Більшість того, що команда розробників робить між написанням коду та його випуском, може відбуватися в одному екземплярі GitLab: код, рев'ю, конвеєр, що його тестує, issue, у якому про нього попросили, і запис про те, хто що схвалив. Один застосунок означає один набір облікових записів і прав, одне місце для пошуку і зв'язки, які тримаються між issue, merge request, що його закрив, і конвеєром, що зміну перевірив. Можливість вести GitLab самостійно — причина, через яку багато організацій узагалі його обирають. Коли код має лишатися на власній інфраструктурі компанії через договір, регулятора чи внутрішні правила, хостинговий сервіс відпадає, а GitLab можна встановити всередині тієї мережі, яка має цей код берегти. Документація вважає це повноцінним сценарієм: вона публікує еталонні архітектури для встановлень на 1 000–50 000 користувачів, поруч із пакетом для Linux і Helm-чартом для Kubernetes. Цей контроль має ціну, і платять її роботою з експлуатації, а не лише ліцензіями. Вести GitLab самостійно означає підібрати для нього сервер, підтримувати в доброму стані базу PostgreSQL і сховище Redis або Valkey, виділити машини для runner-ів, робити резервні копії, з яких справді можна відновитися, і проходити оновлення в тому порядку, якого вимагає проєкт. Хостингові варіанти передають цю роботу GitLab; самостійний лишає її вам. ## Як це виглядає на практиці Робота компанії стикалася з GitLab з обох боків. Протягом кількох років роботи з даними [практики CI/CD на основі GitHub і GitLab](/uk/portfolio/streamlined-data-analysis-and-software-development-processes-saving-43/), де саму автоматизацію забезпечували Bash і Python, замінили ручні кроки і в аналізі даних, і в розробці. Шлях роботи від розробки до постачання стандартизували, щоб він щоразу був однаковим, а не вигадувався заново для кожного проєкту, а аналітичний напрям, який довго вважали окремим і більш ручним світом, увійшов у той самий конвеєр, що й розробка. Сторінка називає приблизно 4 000 заощаджених годин і більш узгоджені результати постачання, бо роботу більше не виконували щоразу трохи по-різному. Власний код компанії показує інший бік самостійного хостингу. Коли код переїхав зі стороннього хостингового сервісу, він потрапив на [форджу, яку компанія веде сама: один бінарний файл, насамперед SSH і без адміністративного вебінтерфейсу](/uk/portfolio/deployed-the-companys-own-git-forge-121/). Її обрали за принципом: що менше інтерфейсу, то менше треба захищати. Ця форджа ділить [робочий сервер із 512 МБ пам'яті](/uk/portfolio/ran-the-whole-company-on-one-512mb-host-109/), з яких придатні до використання близько 464 МБ, з вебсервером для семи доменів, onion-сервісом Tor, сервером Gemini, сервером Gopher, зашифрованими резервними копіями та блокуванням спроб вторгнення. Жодна з цих двох сторінок не згадує GitLab, і подальше порівняння — власна арифметика цієї статті. GitLab називає 8 ГБ пам'яті мінімумом, з яким може працювати встановлення на одному вузлі; увесь той сервер має шістнадцяту частину цього обсягу. Вести GitLab самостійно означає мати сервер, розрахований на GitLab, а невелика форджа з однією метою — інший шлях тримати код на власних машинах. Мінімальний файл конвеєра показує форму налаштувань CI/CD: два етапи, що виконуються по черзі, і по одному завданню в кожному: ```yaml stages: - build - test build-site: stage: build script: - make build run-tests: stage: test script: - make test ``` ## Де виникають проблеми - **Малий сервер сповільнює весь екземпляр.** Документація GitLab називає 16 ГБ пам'яті базовим рівнем для встановлення на одному вузлі, а 8 ГБ — найменшим обсягом, з яким воно може працювати в середовищі з обмеженою пам'яттю. Вона також попереджає, що swap може суттєво знизити продуктивність під навантаженням, і просить вимикати swap, де це можливо, або дати стільки пам'яті, щоб GitLab ніколи ним не користувався. - **Резервна копія відновлюється в екземпляр, що не може прочитати власні дані.** Команда резервного копіювання не включає каталог конфігурації `/etc/gitlab`, а з ним і `gitlab-secrets.json` — ключі, що розшифровують зашифровані значення в базі даних. Без цього файлу ці значення у відновленій базі лишаються замкненими. Документація просить робити резервну копію конфігурації окремо, щонайменше `gitlab-secrets.json` і `gitlab.rb`. - **Оновлення перескакує через обов'язкову зупинку.** Шляхи оновлення містять обов'язкові зупинки, тобто версії, які треба встановити перед будь-якою пізнішою, і починаючи з GitLab 17.5 вони припадають на x.2, x.5, x.8 і x.11. Фонові міграції кожної зупинки мають завершитися до початку наступного оновлення, тож екземпляр, що відстав на кілька версій, наздоганяє їх по одній зупинці за раз. - **Кероване сховище даних виявляється непідтримуваним.** PostgreSQL — єдина підтримувана база даних. Redis або Valkey зберігає сесії та фонові задачі й має бути окремим самостійним екземпляром: Redis Cluster і serverless-варіанти Redis і Valkey не підтримуються. Керований хмарний сервіс дозволено, якщо він саме самостійного типу. - **Конвеєри чекають на машини, які ніхто не запланував.** GitLab.com надає готові runner-и, а на самостійному екземплярі адміністратор сам забезпечує й обслуговує інфраструктуру, де виконуються завдання CI/CD, зокрема стежить, щоб runner-и мали достатньо потужності для навантаження організації. Завантажена команда з одним малим runner-ом стоїть за ним у черзі. ## Що почитати далі - [GitLab Docs](https://docs.gitlab.com/) — повна документація про використання, встановлення та адміністрування GitLab. - [Installation requirements](https://docs.gitlab.com/install/requirements/) — пам'ять, процесор, сховище та підтримувані версії PostgreSQL і Redis. - [Back up GitLab](https://docs.gitlab.com/administration/backup_restore/backup_gitlab/) — що містить резервна копія, чого в ній немає і як зберігати секрети поруч із нею. - [Upgrade paths](https://docs.gitlab.com/update/upgrade_paths/) — обов'язкові зупинки оновлення і чому фонові міграції мають завершитися між ними. - [Get started with GitLab CI/CD](https://docs.gitlab.com/ci/) — файл `.gitlab-ci.yml`, етапи, завдання й конвеєри. - [GitLab Runner](https://docs.gitlab.com/runner/) — програма, що виконує завдання, і способи, якими вона може їх виконувати.