Як розгорнути self-managed GitLab на хмарних платформах?

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

З чого почнемо? GitLab можливо встановити для Amazon Web Services, Google Cloud Platform, Microsoft Azure та інших хмарних систем, де підтримується Linux.

Для цього, існують різні методи, які покриті в статті нижче. Також, там ви знайдете необхідні інструкції щодо простого встановлення 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. Ось рекомендації від GitLab щодо вибору сервера на платформах AWS, GCP та Azure:

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

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

sudo apt-get update

sudo apt-get upgrade

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

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

sudo apt-get install -y postfix

Після цього Postfix відкриє екран конфігурації, на якому нам потрібно обрати тип веб-сайту:

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

Для всіх інших запитань натисніть кнопку “OK”, щоб прийняти всі значення за замовчуванням.

Здійснюємо додавання та встановлення репозиторію пакетів 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.

Зверніть увагу! Настійно рекомендується змінити пароль відразу після встановлення.

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

Спочатку, нам необхідно надати права доступу до сервера:

1|  sudo ufw allow http

2|  sudo ufw allow https

3|  sudo ufw allow OpenSSH

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

sudo ufw enable

Зараз ми відкриваємо конфігураційний файл 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 встановлений та працює належним чином:

Потім перейдіть назад до файлу конфігурації 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 виглядають наступним чином, при цьому зверніть увагу, що файл 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

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

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

sudo cat /etc/gitlab/initial_root_password

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

В поле “Ім’я користувача або електронна пошта” введіть користувача “root”, а в поле “Пароль” введіть пароль, який знаходиться у файлі “/etc/gitlab/initial_root_password”. Після успішної авторизації ми зможемо увійти до нашого GitLab-акаунту.

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

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

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

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

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

Натискаємо  <Save changes>.

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

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

Підсумки

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

Цей підхід має кілька незаперечних переваг:

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

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

GitLab and Cloudfresh

Cloudfresh є сертифікованим партнером GitLab (ГітЛаб), який надає послуги імплементації, міграції, навчання, інтеграції, консультування і підтримки.Ми допомагаємо організаціям повний потенціал рішення GitLab, підвищуючи операційну ефективність, скорочуючи час на розробку і знижуючи ризики з безпеки. 

Наші експерти допоможуть вам впровадити та керувати високоякісними технічними рішеннями GitLab. Ознайомтеся з нашими професійними сервісами GitLab. 

А щоб отримати 30-денну безкоштовну пробну версію для самоврядних ліцензій GitLab, професійної адаптації, консультацій, досвіду та технічної підтримки від Cloudfresh – тисніть сюди.

Давайте прискоримо вашу трансформацію DevSecOps разом!