Версия: v2 (текущая)

Сеть и порты PanDev Metrics on-prem

import Head from "@docusaurus/Head";

On-prem PanDev Metrics публикует для пользователей два TCP-порта: 8080 для API backend и 8090 для workspace UI. Третий порт, 9090, — это Spring Boot actuator, он остаётся внутренним. На этой странице — все требования к входящей и исходящей сети, рекомендуемая настройка reverse proxy и варианты TLS.

Модель безопасности — данные не покидают ваш контур

On-prem PanDev Metrics работает целиком внутри вашей инфраструктуры. Аналитическая база (PostgreSQL) и все компоненты находятся в вашем периметре — никакая телеметрия, аналитика или исходные данные не отправляются вендору PanDev или третьим сторонам.

PanDev Metrics устанавливает соединения только с теми системами, которые вы сами подключили: ваш Git-провайдер, таск-трекер и опционально LDAP/AD.
При self-managed провайдерах (GitLab self-managed, Jira Data Center, Azure DevOps Server, GitHub Enterprise Server) трафик не покидает корпоративную сеть.
При облачном провайдере (Azure DevOps Services, GitHub.com, Jira Cloud) PanDev Metrics обменивается данными только с тем же облаком — где ваши данные уже хранятся. Нового внешнего получателя не появляется.
Для Git хранятся только метаданные (коммиты, pull request, прогоны пайплайнов) — исходный код не хранится. См. Как работает плагин.
Единственное обращение к инфраструктуре самого PanDev — проверка лицензии: HTTPS-запрос к серверу лицензирования PanDev, который передаёт только лицензионные и идентификационные данные инсталляции, но не вашу аналитику, код или метаданные.

Дальше на странице — точные порты и направления связи, которые стоят за этими гарантиями.

Кратко

Параметр	Значение
Хранение данных	Все данные остаются в вашем периметре — вендору PanDev и третьим сторонам ничего не отправляется
Публичный вход	TCP 8080 (API backend) и 8090 (workspace UI) — или 443 за reverse proxy
Внутренний вход	TCP 9090 (actuator), 5432 (PostgreSQL)
Исходящий	HTTPS до подключённых интеграций и сервера лицензирования PanDev — минимальный, отключить нельзя
Вебхуки интеграций	Входящий HTTPS от подключённых Git-провайдеров / таск-трекеров на публичный URL backend (пути `/v1/…`)
TLS	Терминируется на reverse proxy или через самоподписанный сертификат с отключённой клиентской валидацией
Air-gapped	Не поддерживается

Входящие порты

Пользовательский трафик несут два порта; actuator остаётся внутренним:

Порт	Сервис	Назначение	Доступ
8080	Backend (server)	REST API для workspace и IDE-плагинов	Публичный (обычно за reverse proxy на 443)
8090	Workspace (UI)	Веб-интерфейс — статический React-бандл за Nginx	Публичный (обычно за reverse proxy на 443)
9090	Spring Boot actuator	Health, метрики, info	Только внутренний — Compose-файлом не публикуется

Порт базы — не часть публичной поверхности:

Порт	Сервис	Доступ
5432	PostgreSQL	Публикуется на хост поставляемым Compose-файлом. Backend ходит в базу по внутренней сети — для не-локальных установок забиндите на `127.0.0.1` или закройте на firewall

Порт 8080 — API backend

Backend отдаёт REST API для workspace и IDE-плагинов. Должен быть доступен от:

Reverse proxy (именно этот адрес вы публикуете как API_BASE_URL)
Хостов IDE-плагинов (рабочие станции разработчиков или машины за VPN)
Подключённых Git-провайдеров и таск-трекеров, которые шлют вебхуки на backend (см. Входящие вебхуки от интеграций)

Если порт 8080 закрыт для рабочих станций — данные не теряются. Плагины буферизуют события локально и проигрывают их, как только связь восстанавливается через VPN или корпоративную сеть.

Порт 8090 — workspace UI

Контейнер workspace (Nginx) отдаёт single-page UI. Браузеры загружают UI с этого порта, после чего UI обращается к backend напрямую по API_BASE_URL — поэтому из браузера пользователя должны быть доступны и хост UI, и хост API. См. Установка → про API_BASE_URL.

Порт 9090 — actuator

Spring Boot actuator отдаёт операционные эндпоинты для health-check и сбора метрик. В Docker Compose он не публикуется на хост; в Helm-чарте на него опираются liveness/readiness-пробы пода. Оставьте его доступным только из мониторинговой сети — наружу выставлять нельзя.

Часто используемые эндпоинты:

Эндпоинт	Назначение
`/actuator/health/liveness`	Цель liveness-пробы
`/actuator/health/readiness`	Цель readiness-пробы
`/actuator/health`	Агрегированный health — возвращает `{"status":"UP"}`, когда всё хорошо
`/actuator/info`	Сборка и версия
`/actuator/metrics`	Метрики приложения

Исходящий egress

On-prem PanDev Metrics требует минимального исходящего HTTPS:

Сервер лицензирования PanDev (точный хостнейм сообщается вместе с лицензией) — для активации лицензии при первом запуске и последующей проверки лицензии. Нужен ещё до подключения любой интеграции.
Ваш Git-провайдер (GitHub, GitLab Self-Managed или Cloud, Bitbucket, Azure DevOps)
Ваш таск-трекер (Jira Cloud или Data Center, YouTrack, ClickUp, Yandex Tracker, Azure Boards)
Опционально — LDAP / Active Directory (если включена LDAP-интеграция)

warning

Исходящий трафик минимальный, но отключить нельзя. Air-gapped развёртывания не поддерживаются.

Откройте исходящий TCP 443 к серверу лицензирования PanDev и к хостнеймам интеграций, которые вы подключаете. Если в сети используется HTTP-прокси, задайте HTTPS_PROXY и NO_PROXY в окружении контейнера backend.

Входящие вебхуки от интеграций

Интеграции двусторонние — исходящий HTTPS выше это лишь половина. Каждый подключённый Git-провайдер и таск-трекер должен также дотягиваться до PanDev Metrics, чтобы доставлять вебхуки. Именно это обеспечивает синхронизацию в реальном времени; без входящей доступности данные обновляются только при периодическом backfill, а не на каждое событие.

Направление связи по интеграциям

Интеграция	Порты	Направление	Зачем
Git-провайдер (GitHub, GitLab, Bitbucket, Azure DevOps)	443 (или 80)	Двусторонняя	Egress: опрос API и backfill. Inbound: вебхуки на push, pull / merge request и прогоны пайплайнов
Таск-трекер (Jira, YouTrack, ClickUp, Yandex Tracker, Azure Boards)	443 (или 8080 / 80)	Двусторонняя	Egress: опрос API и backfill. Inbound: вебхуки на задачи, смену статусов и worklog
AD / LDAP / LDAPS	389, 636	Односторонняя — PanDev → LDAP	Синхронизация пользователей и групп плюс аутентификация. Каталог сам соединение к PanDev Metrics не открывает

Вебхуки — это HTTP POST от провайдера на публичный URL backend, по путям /v1/… — например /v1/github/webhook/pull-request, /v1/gitlab/webhook/merge-request или /v1/jira-worklog. Они приходят на тот же публичный endpoint, что и API (порт 8080, обычно за reverse proxy на 443).

Что это значит для сети:

Облачные провайдеры (GitHub.com, GitLab SaaS, Bitbucket Cloud, Jira Cloud, Azure DevOps Services) шлют вебхуки из интернета — webhook-URL PanDev Metrics должен быть доступен из публичного интернета (обычно через reverse proxy на 443).
Self-managed провайдеры (GitHub Enterprise Server, GitLab self-managed, Bitbucket Data Center, Jira Data Center) должны дотягиваться до PanDev Metrics только по вашей внутренней сети.

:::note Azure DevOps всегда двусторонний Azure DevOps — и Services (облако), и Server (self-managed) — требует доступа в обе стороны:

PanDev → Azure (исходящий 443): PanDev Metrics регистрирует service hooks, опрашивает REST API, делает backfill и постит PR-комментарии.
Azure → PanDev (входящий на публичный или внутренний webhook-URL): Azure сам создаёт service hooks и POST-ит события — pull request, прогоны пайплайнов и work items Azure Boards — в PanDev Metrics.

Без входящего доступа Azure → PanDev синхронизации в реальном времени не будет: данные подтянутся только периодическим backfill раз в 15 минут. См. гайды Azure DevOps и Azure Boards. :::

Коротко: видимость INTEGRATION ↔ METRICS должна быть взаимной — egress, чтобы backend опрашивал провайдера и делал backfill, и входящий доступ, чтобы провайдер доставлял вебхуки. Публичный URL, на который обращаются провайдеры, задаётся в PanDev Metrics — см. гайды по интеграциям в разделе Git-интеграции и таск-трекеры.

Reverse proxy

Терминируйте TLS на reverse proxy и маршрутизируйте два имени: UI — на workspace (:8090), API — на backend (:8080). Подходят и Nginx, и Traefik — это стандартная reverse-proxy-форма.

Nginx

/etc/nginx/conf.d/pandev.conf
# Workspace UI
server {
  listen 443 ssl http2;
  server_name app.example.com;

  ssl_certificate     /etc/ssl/certs/pandev.crt;
  ssl_certificate_key /etc/ssl/private/pandev.key;

  location / {
    proxy_pass http://127.0.0.1:8090;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
  }
}

# Backend API  (этот хостнейм и есть ваш API_BASE_URL)
server {
  listen 443 ssl http2;
  server_name metrics.example.com;

  ssl_certificate     /etc/ssl/certs/pandev.crt;
  ssl_certificate_key /etc/ssl/private/pandev.key;

  client_max_body_size 50m;

  location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_read_timeout 60s;
  }
}

Traefik

traefik dynamic config
http:
  routers:
    pandev-ui:
      rule: "Host(`app.example.com`)"
      entryPoints: [websecure]
      tls: {}
      service: pandev-workspace
    pandev-api:
      rule: "Host(`metrics.example.com`)"
      entryPoints: [websecure]
      tls: {}
      service: pandev-backend
  services:
    pandev-workspace:
      loadBalancer:
        servers:
          - url: "http://127.0.0.1:8090"
    pandev-backend:
      loadBalancer:
        servers:
          - url: "http://127.0.0.1:8080"

В Kubernetes встроенный Helm-чарт создаёт эту маршрутизацию за вас из serverUrl и workspaceUrl через Ingress — см. Установка → Helm.

TLS и reverse proxy

PanDev Metrics работает в любой из трёх TLS-конфигураций ниже. Выберите ту, что соответствует вашей security-политике.

Вариант	Что настраивается	Когда применять
Сертификат публичного CA	Reverse proxy с сертификатом от Let's Encrypt или вашего корпоративного CA	По умолчанию — рекомендуется для любого прод-инстанса, доступного с рабочих станций
Сертификат внутреннего CA	Reverse proxy с внутренним CA, которому уже доверяет ваш парк машин	Корпоративные сети, где машины разработчиков доверяют внутреннему CA
Самоподписанный + отключённая валидация на клиенте	Backend отдаётся напрямую с самоподписанным сертификатом, плагины настроены пропускать SSL-валидацию	Только air-gapped тесты или evaluation — не рекомендуется для прода

IDE-плагины PanDev Metrics умеют отключать клиентскую SSL-валидацию для подключения к self-signed-инсталляции. Настройка задаётся в каждом плагине отдельно и описана в гайдах плагинов.

Firewall

Минимальные входящие правила для application-хоста:

terminal (пример firewalld)
firewall-cmd --permanent --add-port=443/tcp              # reverse proxy
firewall-cmd --permanent --add-port=8080/tcp             # только если выставляете API без proxy
firewall-cmd --permanent --add-port=8090/tcp             # только если выставляете UI без proxy
firewall-cmd --reload

Если вы держите внешнюю базу на отдельном хосте, ограничьте PostgreSQL приёмом соединений только с IP application-хоста:

terminal (пример firewalld — хост внешней БД)
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" \
  source address="<APPLICATION_HOST_IP>" port port="5432" protocol="tcp" accept'
firewall-cmd --reload

Поставляемый Docker Compose-файл публикует PostgreSQL на 5432 на хост. Backend ходит в базу по внутренней сети, поэтому для не-локальных установок забиндите порт на 127.0.0.1 (или закройте на firewall), а не оставляйте на всех интерфейсах.

HTTP-прокси

Если application-хост работает за корпоративным HTTP-прокси, настройте его через стандартные env-переменные сервиса backend:

Переменная	Назначение
`HTTP_PROXY`	URL прокси для plain HTTP — используется редко
`HTTPS_PROXY`	URL прокси для исходящего HTTPS до Git / таск-трекера
`NO_PROXY`	Список хостов через запятую, для которых прокси не применяется (PostgreSQL и другие внутренние сервисы)

Добавьте их в окружение сервиса pandev-metrics-server, затем docker compose up -d --force-recreate pandev-metrics-server.

Ограничения и edge-кейсы

Egress отключить нельзя. PanDev Metrics нужен минимальный исходящий HTTPS для проверки лицензии на сервере лицензирования PanDev и для общения с интеграциями. Offline-режима нет.
Actuator должен оставаться внутренним. Порт 9090 не предназначен быть публичным.
Между компонентами нет mTLS. Backend и PostgreSQL общаются внутри доверенной сети Docker/Kubernetes. mTLS добавляйте на сетевом уровне, если этого требует ваша политика.
Поддержка WebSocket зависит от reverse proxy. Длинные соединения, используемые частью UI, требуют proxy_read_timeout выше дефолтных 60 секунд на Nginx.

Связанные материалы

How-to: Установка PanDev Metrics on-prem
Reference: Системные требования
Концепция: Архитектура on-prem

Модель безопасности — данные не покидают ваш контур​

Кратко​

Входящие порты​

Порт 8080 — API backend​

Порт 8090 — workspace UI​

Порт 9090 — actuator​

Исходящий egress​

Входящие вебхуки от интеграций​

Направление связи по интеграциям​

Reverse proxy​

Nginx​

Traefik​

TLS и reverse proxy​

Firewall​

HTTP-прокси​

Ограничения и edge-кейсы​

Связанные материалы​

Источники​