DirectumRX. Организация инфраструктуры для разработки

33 4

Обычно на club.directum.ru в статьях говорят о коде и подходах к решению таки или иначе связанных с написанием кода задач, я же хочу осветить другую сторону вопроса - организацию инфраструктуры для разработки (и для разработчиков) в DirectumRX.

Что нам нужно:

  1. Система контроля версий (или vcs);
  2. Сервер БД;
  3. Собственно сам сервер разработки;
  4. Доступность извне;
  5. Резервное копирование.

Конечно, всё можно поставить на один сервер, тем более что система хранения исходных кодов уже идет в поставке дистрибутива с инструментом разработчика, но, как говорится, есть один нюанс…

Давайте подробно разберем каждую компоненту.

1. Система контроля версий

В DirectumRX реализовано хранение исходных кодов в VCS (git), поэтому, теоретически, любая git-совместимая реализация подходит для использования, например bitbucket или github. Но мы в ЦВД отказались от такой системы в пользу gitea по следующим причинам:

  • Ограничения - в bitbucket не более 5-ти человек в команде, но есть возможность создавать приватные репозитории, github же позволяет создавать приватные репозитории, но за отдельную плату;
  • Необходимость создания отдельных учетных записей для общедоступных ресурсов.

Gitea же позволяет развернуть изначально закрытый от посторонних репозиторий, и авторизовать пользователей через LDAP (например через ActiveDirectory), что позволяет сотруднику использовать одну учетную запись для доступа к внутренним ресурсам (не будем также забывать и про аспект информационной безопасности - заблокировать одну учетную запись быстрее чем десять).

Gitea развернут на Linux-сервере, что также позволяет снизить потребление ресурсов.

Фичи Gitea:

  • Возможность группировки пользователей в Организации;
  • Возможность создания команд внутри организации;
  • Контроль доступа по командам\организациям;
  • Ведения багтрэка (задачи в репозитории) со списком ответственных, метками, этапами, и отслеживанием времени.

Небольшой лайфхак - gitea можно развернуть на сервере с помощью docker-контейнера, это позволит вам:

  • Не занимать http(s)-порт (об этом расскажу в п.4);
  • Оперативно поднимать VCS в случае сбоя на новом сервере;
  • При необходимости - создавать несколько экземпляров gitea.

2. Сервер БД

DirectumRX в качестве СУБД использует MS SQL либо PostgreSQL. Собственно, чтобы не разворачивать на каждой машине разработчика отдельный экземпляр SQL-сервера - целесообразнее (в т.ч. с точки зрения оптимизации использования ресурсов) развернуть отдельный сервер для этих целей, куда будут установлены SQL-сервер и утилиты управления (SSMS для SQL Server, pgAdmin - для PostgreSQL).

Собственно с помощью Docker так же можно развернуть несколько экземпляров PostgreSQL. Сюда же можно добавить и RabbitMQ.

3. Сервер разработки

Ключевой пункт повествования, то, ради чего все и создается - Sungero Development Studio, для которой на сегодняшний день есть много идей и пожеланий для развития. Конкретно про SDS и ее развертывание рассказывать особенно нечего, кроме, разве что, одного пункта - если вы устанавливаете SDS и VCS из поставки на одну машину - базовое решение Sungero.DirectumRX импортируется в среду разработки автоматически, если же вы используете сторонний ресурс, то после установки можете наблюдать отсутствие базовых решений. В этом случае следует руками импортировать из комплекта поставки файл с базовым решением DirectumRX.dat, расположенный в packages\GitServer\cab1.cab.

4. Доступность извне

Часто возникают вопросы о доступности системы извне, по внешнему же DNS-имени, например directum.companyname.ru.

Как это организовано у нас:

  • Имеется шлюз с установленным Nginx;
  • Сервер с предпродакшеном, не имеющий белого IP;
  • Внешнее доменное имя.

При установке DirectumRX заранее указываем внешнее доменное имя. В nginx готовим конфигурационный файл с настройками:

server {
    listen 80;
    server_name my-domain.name.ru;
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;
    client_max_body_size 100M;
location / {
    proxy_pass http://IP_адрес_directum_внутри_сети;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_connect_timeout       600;
    proxy_send_timeout          600;
    proxy_read_timeout          600;
    send_timeout                600;
    }
}

И… собственно всё! После установки мы можем пользоваться функционалом извне.

Единственная оговорка - nginx в нашем случае нужен потому, что хостов с RX больше одного, если у вас всего один сервер - можно просто пробросить порт.

5. Резервное копирование

Особый пункт. Реализации п.1 и п.2 накладывают на администратора особые обязательства в части сохранности данных. Собственно, чтобы не бэкапить всё - можно бэкапить то, что наиболее критично - исходные коды и базы данных.

Надеюсь, изложение нашего опыта в чем-то вам поможет, и упростит жизнь 

Андрей Посаженников

Спасибо за статью. Сам использую Gitea для домашних проектов. И она мне очень нравится.

Но у меня есть пара вопросов:

  • Gitea поддерживается pull requests. Организуете ли вы CodeReview в команде? 
  • Gitea не умеет CI/CD, для этого советуют использовать сторонние средства. Делаете ли автоматическую сборку/деплой/тестирование проектов? Если да, то как?
Дмитрий Панкрашов

Андрей, кодревью не организуем по ряду причин, но в принципе желание это делать есть, вопрос в команде пока открытый. Что касается CI\CD - то это совершенно не задача Gitea, тут, на мой взгляд, нужно плясать "от печки", то есть от команды разработки самого DirectumRX. Пока средства тестирования внутри SDS не представлены, кроме "ручного" тестирования, либо тут нужно прикручивать некое RPA, что само по себе является головной болью. Посмотрим на развитие событий.

Андрей Посаженников

> Что касается CI\CD - то это совершенно не задача Gitea

Это на самом деле спорный момент. Gitlab например предоставляет свой CI. 

> нужно плясать "от печки", то есть от команды разработки самого DirectumRX

Я думаю что можно запустить SDS в не визуальном режиме, собрать решение и опубликовать его. Может быть даже получится прогнать статический анализатор кода. С тестами согласен, сложнее.

То есть это не обязательно должен предоставлять RX.

Конечно на это надо потратить некоторые усилия, но оно сильно помогает избежать ошибок.

> прикручивать некое RPA

Gitea предлагает сразу несколько вариантов поддерживаемых CI. У себя поднял Jenkins, вроде не так уж и сложно, с остальными не пробовал.

Роман Деменков

"github же позволяет создавать приватные репозитории, но за отдельную плату"

Уже с год как можно, за плату - более трёх участников.

Авторизуйтесь, чтобы написать комментарий