Практичні поради: розгортаємо self-managed GіtLab на хмарні системи

Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!

Привіт усім! Мене звати Андрій, я DevOps-інженер у компанії Cloudfresh. Наша спеціалізація — впровадження, міграція, інтеграція та інші процеси, пов’язані з хмарними рішеннями Google Cloud Platform, GitLab і Microsoft Azure.

У цій статті я розповім про різні способи встановлення GitLab на деяких хмарних платформах, таких як GCP, AWS, Azure та інші. Також я покажу, як легко встановити GitLab для компаній з обсягом до 500 користувачів, враховуючи їх потреби та вимоги.

Почнемо з того, які методи інсталяції взагалі існують.

Official Linux package

GitLab рекомендує використовувати пакет Linux (також відомий як Omnibus) для розгортання самостійного GitLab на хмарних платформах, таких як GCP, AWS, Azure та інші, до 1000 користувачів.

Використання цього методу дозволяє швидко та якісно розгорнути повноцінну платформу DevSecOps для впровадження найкращих практик у життєвому циклі розробки програмного забезпечення (SDLC).

Пакет Omnibus містить всі необхідні служби та інструменти для безперебійної роботи, легкого адміністрування і, що дуже важливо, оновлення.

Reference architectures (Еталонні архітектури)

GitLab розробив і перевірив еталонні архітектури, які забезпечують рекомендовані розгортання на великому масштабі. Пакети еталонної архітектури GitLab можуть підтримувати від 1 000 до 50 000 користувачів.

Однак, якщо вам потрібно розглянути розгортання для меншої кількості користувачів (до 3 000), я б рекомендував використовувати попередній метод, оскільки еталонна архітектура вимагає великої доступності, що забезпечує можливість кожного компонента в налаштуванні GitLab впоратися з відмовами за допомогою різних механізмів.

Досягнення цього рівня — складне завдання, а створення необхідного середовища може бути довготривалим та витратним.

GitLab Helm chart (Kubernetes)

Helm Chart містить всі необхідні компоненти для початку роботи й може масштабуватись до великих розгортань. Якщо ви плануєте встановити GitLab на базі OpenShift, рекомендується використовувати GitLab Operator.

В протилежному випадку, вам потрібно буде самостійно оновлювати обмеження контексту безпеки. Проте GitLab не рекомендує використовувати цей метод для прод середовищ, оскільки він розгортає всі сервіси GitLab у кластері.

Щоб забезпечити ідеальну та надійну роботу GitLab, компоненти, такі як PostgreSQL або Gitaly, повинні працювати поза кластером. Ця конфігурація забезпечить масштабованість та надійне обслуговування робочих навантажень в середовищі GitLab.

Якщо ви намагаєтесь використовувати Kubernetes, GitLab пропонує розгорнути еталонну архітектуру для Kubernetes, відому як «Cloud Native Hybrid».

Cloud Native Hybrid

Це підхід, який використовує еталонну архітектуру, але з істотною відмінністю: не всі сервіси розміщуються у кластері для реалізації робочих процесів. Усі компоненти збереження даних мають перебувати поза кластером.

GitLab розробляє інфраструктуру як код (IaC), яка може налаштувати комбінацію Helm Chart та додаткової хмарної інфраструктури, такої як Google Kubernetes Engine (GKE) або Amazon Elastic Kubernetes Service (EKS).

Як встановити GitLab та зробити мінімальні налаштування для повноцінної роботи

Хочу звернути вашу увагу на найпростіший і найпоширеніший метод — офіційний пакет для Linux.

GitLab self-managed має два типи:

• GitLab CE (Community Edition).
• GitLab EE (Enterprise Edition).

У них немає суттєвих відмінностей, обидва типи є безкоштовними до тих пір, поки не буде придбана ліцензія. Однак, основна різниця полягає в тому, що GitLab CE є безкоштовною версією, і неможливо додати ліцензії до неї.

Тому, якщо компанія планує використовувати платний функціонал, їй доведеться встановлювати GitLab EE та проводити міграцію. Враховуючи це, я рекомендую одразу встановлювати GitLab EE, щоб уникнути додаткових витрат на майбутню міграцію.

Спочатку нам потрібен сервер, на якому ми будемо розгортати наш GitLab.

Ось рекомендації GitLab щодо вибору машини на платформах AWS, GCP та Azure:

Ми розглядаємо мінімально рекомендовані характеристики робочої машини від GitLab, а також їхню пропозицію додати 2 ГБ простору SWAP. Я хотів би запропонувати обрати машину з мінімум 8 ГБ оперативної пам’яті й додати 4 ГБ простору SWAP (на мою думку, це покращить безперебійну адміністрацію), оскільки під час налаштування та оновлення система може працювати з максимальним навантаженням і зупинити весь процес.

Я вважаю, що різниця в ціні машини все одно перекриє затрати часу на виправлення помилок. Після створення необхідної машини з обраною операційною системою, у моєму випадку Ubuntu 22.04, ми встановлюємо та налаштовуємо необхідні залежності.

1. Починаємо з встановлення та налаштування відповідних залежностей.

sudo apt-get update

sudo apt-get upgrade

sudo apt-get install -y curl openssh-server ca-certificates tzdata perl

2. Згідно з рекомендаціями GitLab, наступним кроком є встановлення Postfix для відправки сповіщень електронною поштою. Проте, якщо ви бажаєте використовувати інший інструмент, ви можете пропустити цей крок і налаштувати зовнішній SMTP-сервер після встановлення GitLab. Детальні вказівки щодо конфігурації можна знайти тут.

sudo apt-get install -y postfix

Далі Postfix надає нам екран конфігурації. Вибираємо сайт:

Далі вказуємо домен нашого GitLab <gitlab.example.com>

Та на всі інші питання тиснемо <OK>, щоб прийняти всі значення за замовчуванням.

3. Додаємо та встановлюємо репозиторій пакетів GitLab.

curl 
https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash

Далі інсталюємо GitLab:

sudo apt-get install gitlab-ee

Після інсталяції пароль до користувача root буде згенерований автоматично та зберігатиметься протягом 24 годин у файлі /etc/gitlab/initial_root_password.

Важливо! Рекомендую після встановлення одразу змінити пароль.

4. Налаштовуємо та активуємо брендмауер у своїй операційній системі, зауважте, що це Ubuntu 22.04 (якщо ці дозволи вже надані, можна пропустити цей крок).

Спочатку надаю дозволи на доступ до сервера:

1|  sudo ufw allow http
2|  sudo ufw allow https
3|  sudo ufw allow OpenSSH

Вмикаємо брендмаувер:

sudo ufw enable

5. Редагуємо конфігурації GitLab. Файл конфігурації gitlab.rb, який знаходиться /etc/gitlab/gitlab/gitlab.rb:

sudo vim /etc/gitlab/gitlab.rb 
або 
sudo nano /etc/gitlab/gitlab.rb

Потрібно вказати свій IP в наступному рядку:

external_url  <'http://51.120.241.152'>

sudo gitlab-ctl reconfigure

Після цього має зʼявитись наступне повідомлення (це може зайняти деякий час):

Після даної реконфігурації переходимо по своєму IP та переконуємось, що GitLab встановлений:

6. Далі повертаємося до файлу конфігурації gitlab.rb та вносимо наступні зміни, розкоментовуючи необхідні рядки.

sudo vim /etc/gitlab/gitlab.rb 
або 
sudo nano /etc/gitlab/gitlab.rb

external_url — домен сервера, на якому встановлено GitLab, уважно перевірити, щоб було вказано https:// 

• letsencrypt['enable']= true  — використання сертифіката Let’s Encrypt;
• letsencrypt['contact_emails'] — вказую електронну пошту для реєстрації;
• Letsencrypt['auto_renew']= true — автооновлення сертифіката Let’s Encrypt;
• Letsencrypt['auto_renew_hour']= “12” вказую годину оновлення;
• letsencrypt['auto_renew_minute']= “30” вказую хвилини оновлення;
• letsencrypt['auto_renew_day_of_month']=“*/7” вказую день місяця коли має оновитись сертифікат.

Перевіряємо, що зміни виглядають таким чином (зауваження: файл gitlab.rb досить об’ємний, тому різні зміни можуть бути розташовані далеко одна від одної).

external_url 'https://gitlab.example.com'
letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ['example@com']
letsencrypt['auto_renew'] = true
letsencrypt['auto_renew_hour'] = "12"
letsencrypt['auto_renew_minute'] = "30"
letsencrypt['auto_renew_day_of_month'] = "*/7"

Зберігаємо наші зміни та вводимо їх в дію:

sudo gitlab-ctl reconfigure

Це також може зайняти деякий час.

7. Після такого повідомлення (можливо, знадобиться декілька хвилин очікування, якщо виникає помилка 502), можна здійснити вхід в систему GitLab.

Нагадую, що згенерований пароль можна знайти у відповідному файлі від GitLab.

sudo cat /etc/gitlab/initial_root_password

Отримаємо наступний вивід;

В полі username or email вказуємо користувача root та пароль з файлу /etc/gitlab/initial_root_password, після авторизації ми зайдемо в наш GitLab:

Нагадую, що важливо негайно змінити свій пароль! Для цього потрібно натиснути на свій аватар у верхньому правому куті.

Натиснути <Edit profile -> Password>

8. На попередньому етапі ми вже виконали необхідні дії для налаштування GitLab, але я пропоную провести додаткові налаштування. На зображенні видно, що GitLab пропонує нам відключити можливість реєстрації нових акаунтів для будь-якої особи, яка знає наш домен.

Це означає, що будь-хто, хто знає наш домен, зможе зареєструвати акаунт (адміністратор все ж повинен підтвердити таку реєстрацію, але я вважаю, що адміністратор може самостійно надсилати запрошення новим користувачам).

Забираємо галочку:

Можна також одразу налаштувати дозвіл на реєстрацію з вашою організацією:

Та натискаємо нижче синю кнопку <Save changes>.

Порожній GitLab споживає наступні потужності:

Тепер можна сміливо користуватись зручним функціоналом GitLab, залишається тільки правильно налаштувати SMTP для нотифікацій та можна братися до створення робочого середовища.

Таким чином я показав тут покроково, як провести інсталяцію, що в більшості випадків підійде компаніям.

Підсумки

Стосовно того, чи розгортати self-managed GitLab на GCP, AWS, Azure або інших хмарах, чи користуватись SaaS-версією — залежить від компанії-замовника, тому що не всі проєкти можна тримати в хмарах, згідно з певними законами тієї чи іншої країни. Але якщо закони не забороняють, то мій вибір би припав на SaaS-версію GitLab.

Є беззаперечні переваги такого методу:

• Економія на тримання клауда.
• Економія часу та витрат на обслуговуванні системи.
• Відсутність додаткових налаштувань, які часто бувають дуже болючими та довготривалими.
• Налаштування SMTP для нотифікацій.
• Оновлення і багато іншого, що ви отримуєте в ході користування.

Але це не означає, що self-managed GitLab є якоюсь катастрофою. Просто воно вимагає більшої уваги, зусиль та ресурсів для ефективного функціонування. Self-managed GitLab може бути вигідним варіантом для компаній, які мають специфічні потреби, високі безпекові вимоги або потребують повного контролю над своїми даними.

Якщо у вас з’явилися питання щодо інструкції або інші — з радістю відповім на них у коментарях.