🥇Ми оновлюємо маркетплейс: розкажіть нам, як краще?

Цього року ми поставили собі амбітні цілі щодо покращення продукту.

Деякі завдання вимагають серйозної підготовки, за ними ми збираємо зворотний зв'язок від користувачів: запрошуємо до офісу розробників, сисадмінів, керівників команд, фахівців з Kubernetes.

У деяких - видаємо сервери у відповідь за фідбек, як, наприклад, було зі студентами Blurred Education. У нас дуже насичені чати з обговоренням UI/UX, беклог навчальних статей у довідник і великі плани щодо поліпшення досвіду користувача.

Більшість змін вимагають велику кількість годинників розробників, але маркетплейс - Зовсім інша історія. З появою снапшотів у нас з'явилася можливість залучати зовнішніх системних адміністраторів, які можуть підготувати образ, щоб ми буквально за день увімкнули його в маркетплейс.

Як зробити свій внесок у маркетплейс RUVDS і що буде, ми покажемо на прикладі нашого нового образу, підготовленого нашим клієнтом takezi - GitLab

Як створювався шаблон 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 за замовчуванням, і доступна за цією URL.

Є дві різні частини інтеграції 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

gitlab.mydomain.ru/-/grafana/login/gitlab

При першому вході з використанням 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

Ми оновлюємо маркетплейс: розкажіть нам як краще?