
Цього року ми поставили собі амбітні цілі щодо покращення продукту.
Деякі завдання вимагають серйозної підготовки, за ними ми збираємо зворотний зв'язок від користувачів: запрошуємо до офісу розробників, сисадмінів, керівників команд, фахівців з Kubernetes.
У деяких - видаємо сервери у відповідь за фідбек, як, наприклад, було . У нас дуже насичені чати з обговоренням UI/UX, беклог навчальних статей у довідник і великі плани щодо поліпшення досвіду користувача.
Більшість змін вимагають велику кількість годинників розробників, але маркетплейс - Зовсім інша історія. З появою снапшотів у нас з'явилася можливість залучати зовнішніх системних адміністраторів, які можуть підготувати образ, щоб ми буквально за день увімкнули його в маркетплейс.
Як зробити свій внесок у RUVDS і що буде, ми покажемо на прикладі нашого нового образу, підготовленого нашим клієнтом -
Як створювався шаблон Gitlab на Centos 8
Для встановлення Gitlab Юра вибрав сервер з 8 Гб RAM і 2 ядрами CPU (можна і 4 Гб і 1 CPU, але в цьому випадку доведеться задіяти swap-файл, і з продуктивністю Gitlab в такому випадку помітно нижче).

Переконайтеся, що встановлені необхідні пакети для встановлення Gitlab:
sudo dnf install -y curl policycoreutilsВідкриємо доступ до портів 80 та 443:
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo systemctl reload firewalldДодамо репозиторій Gitlab:
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.rpm.sh | sudo bash
Якщо сервер має налаштоване DNS-ім'я, то Gitlab можна встановити використовуючи його. Якщо вказати префікс https://, Gitlab автоматично згенерує сертифікати Lets Encrypt.
У разі, т.к. ми робили шаблон віртуальної машини, то Юра поставив шаблонну адресу (яку потім без проблем можна буде змінити в майбутньому):
sudo EXTERNAL_URL="http://0.0.0.0" dnf install -y gitlab-ee
Після цього можна перевірити, що сервіси Gitlab працюють, зайшовши на
http://vps_ip_address/
система запропонує встановити початковий пароль для облікового запису адміністратора root.
На цьому етапі зробимо снапшот сервера, і далі будемо вже налаштовувати використовуючи його.

І все!
Бонус: розкажемо, що можна зробити цікавого, розгорнувши з образом GitLab.
Моніторинг Gitlab за допомогою Grafana
Три роки тому команда Gitlab реалізувала систему моніторингу, щоб управляти величезною кількістю метрик пов'язаних з сервісами Gitlab.
З тих пір Gitlab став поставляти свій інсталяційний пакет разом з Prometheus, щоб дати можливість своїм користувачам скористатися можливостями моніторингу, що надаються Prometheus.
Prometheus є відкритою (Apache 2.0) time series СУБД, написаною мовою Go та спочатку розробленою в компанії SoundCloud. Іншими словами, ця штука зберігає ваші метрики. Цікавою особливістю Prometheus є те, що він сам тягне метрики із заданої множини сервісів (робить pull). За рахунок цього у Prometheus не можуть забитися якісь там черги чи на кшталт того, а отже моніторинг ніколи не стане вузьким місцем системи. Також проект цікавий тим, що він принципово не пропонує будь-якого горизонтального масштабування або високої можливості.
Ледве більше року тому команда Gitlab зробила висновок, що метрики не дуже зручні без дашбордів. Тому вони інтегрували Grafana з налаштованими дашбордами, щоб допомогти своїм користувачам візуалізувати дані, без необхідності встановлювати Grafana вручну.
Починаючи з версії 12.0, Gitlab інтегрована Grafana, налаштована з SSO за замовчуванням, і .
Є дві різні частини інтеграції Gitlab з Prometheus:
- Моніторинг GitLab (Omnibus)
- Моніторинг окремих додатків GitLab у кластері Kubernetes
Як це використовувати
"Omnibus" - так GitLab називає свій основний настановний пакет.

Як настроїти Grafana
Вхід за логіном та паролем у Grafana за замовчуванням вимкнено (дозволено лише вхід SSO), але якщо є необхідність увійти в обліковий запис з правами адміністратора або мати можливість входу за логіном та паролем, необхідно дозволити це у файлі конфігурації Gitlab /etc/gitlab/gitlab .rb, відредагувавши відповідний рядок:
grafana['disable_login_form'] = false
І виконати реконфігурацію Gitlab для застосування змін:
sudo gitlab-ctl reconfigure
У випадку, якщо ви запустили Gitlab використовуючи наш шаблон віртуальної машини з нашого маркетплейсу, необхідно призначити серверу свою URL-адресу, змінивши відповідний рядок в /etc/gitlab/gitlab.rb:
external_url = 'http://gitlab.mydomain.ru'
Виконати реконфігурацію:
sudo gitlab-ctl reconfigureІ змінити Redirect URI для Grafana відповідно до
Admin Area > Applications > GitLab Grafana

При першому вході з використанням SSO Gitlab запросить дозвіл на авторизацію входу в Grafana.

Метрики
У Grafana налаштовані та доступні у категорії Gitlab Omnibus готові дашборди основних сервісів.

Дашборд Overview

Дашборд Service Platform Metrics
- Overview - оглядовий дашборд, що показує стан сервісів, черги та використання ресурсів сервера
- Gitaly — моніторинг сервісу, що надає RPC доступ до репозиторій Gitlab
- NGINX VTS — статистика з трафіку сервісів та кодів HTTP на запит
- PostgreSQL — статистика доступності та навантаження на базу даних PostgreSQL
- Praefect — моніторинг навантаження на сховище з високою доступністю Praefect
- Rails App - оглядовий дашборд для додатків Rails
- Redis - моніторинг навантаження на сервіс Redis
- Registry - моніторинг реєстру образів
- Service Platform Metrics — сервісні метрики, що показують утилізацію ресурсів Gitlab'ом, доступність сервісів, кількість запитів RPC та кількість помилок.
Інтеграція досить комплексна, і користувачі Gitlab мають можливість аналізувати візуалізовані метрики Gitlab прямо з коробки.
У Gitlab підтримкою та оновленням дашбордів займається окрема команда і за словами Бена Кочі (Ben Kochie), інженера SRE Gitlab, налаштування за умовчанням та підготовлені дашборди підійдуть більшості користувачів.
А тепер головне: давайте робити маркетплейс разом
Ми хочемо запропонувати всьому ком'юніті Хабра взяти участь у створенні маркетплейсу. Є три варіанти, як ви можете приєднатися:
Підготувати образ самому та отримати 3000 рублів на баланс
Якщо ви готові відразу кинутися в бій і створити образ, якого вам не вистачає, ми зарахуємо вам 3000 рублів на внутрішній баланс - ви зможете витратити на сервери.
Як створити свій образ:
- Створіть обліковий запис у нас на
- Повідомте, що ви збираєтеся створювати та тестувати образи
- Ми зарахуємо вам 3000 рублів та включимо можливість створювати снапшоти
- Замовте віртуальний сервер із чистою операційною системою
- Встановіть на це VPS програмне забезпечення та налаштуйте його
- Складіть інструкцію або скрипт для розгортання ПЗ
- Створіть снапшот для налаштованого сервера
- Замовте новий віртуальний сервер, вибравши у списку «Шаблон сервера» створений раніше снапшот
- У разі успішного створення сервера, передайте матеріали отримані на етапі 6 технічної підтримки
- У разі помилки ви можете уточнити у підтримки причину та повторити налаштування
Для власників бізнесу: запропонуйте свій софт
Якщо ви розробник софту, який розгортають і використовують на VPS, то ми можемо включити вас в маркетплейс. Так ми можемо допомогти вам привести нових клієнтів, трафік та впізнаваність.
Просто запропонувати нам образ у коментарях
Напишіть, який із яким софтом ви хотіли б мати можливість розгортати віртуалки в один клік?
Чого вам не вистачає у маркетплейсі RUVDS?
Що кожен хостинг, що поважає себе, повинен обов'язково включити в свій маркетплейс?
Тільки зареєстровані користувачі можуть брати участь в опитуванні. , будь ласка.
Які образи нам варто включити до маркетплейс першими?
50,0%LEMP10
15,0%Drupal3
10,0%Joomla2
5,0%Dokku1
0,0%PacVim0
0,0%Runcloud0
5,0%code-server1
15,0%Ghost3
5,0%WikiJs1
0,0%Discourse0
0,0%Rstudio0
5,0%OpenCart1
35,0%Django7
40,0%Laravel8
20,0%Ruby on Rails4
55,0%NodeJs11
Проголосували 20 користувачів. Утрималися 12 користувачів.
Джерело: habr.com
