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

Обычно на 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 накладывают на администратора особые обязательства в части сохранности данных. Собственно, чтобы не бэкапить всё - можно бэкапить то, что наиболее критично - исходные коды и базы данных.

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