Приватная сеть и домены .internal в Dockup

Приватная сеть позволяет сервисам и управляемым базам данных внутри одного проекта Dockup взаимодействовать без передачи трафика между ресурсами проекта через публичный интернет. Каждый ресурс получает стабильное имя хоста <slug>.internal, а отдельные проекты остаются изолированными друг от друга.

Сеть подключается по желанию. Её включение соединяет существующие ресурсы проекта, но не требует немедленно переводить трафик приложения на новый маршрут. После повторного деплоя сервисы получают внутренние переменные подключения.

Как взаимодействие сервисов уменьшает публичную экспозицию?

Публичный endpoint базы данных доступен из интернета, даже если аутентификация блокирует несанкционированное использование. Приватный маршрут устраняет такую экспозицию для трафика приложения и предоставляет сервисам стабильное внутреннее имя, не зависящее от публичного адреса.

Тот же принцип применяется к вызовам между сервисами. API может обращаться к worker, внутреннему admin-сервису или backend через сеть проекта, а не через публичный custom domain.

Путь трафика	Публичный маршрут	Приватный маршрут
API к PostgreSQL	Публичные host и port	main-db.internal
Web к API	Публичный custom domain	api.internal
Worker к Redis	Публичные host и port	app-redis.internal
Preview к production DB	Публичные учётные данные БД	Внутренний пользователь только для чтения
Вызов между проектами	Требуется публичный endpoint	Заблокирован изоляцией проектов

Приватный доступ не означает отсутствие аутентификации. Продолжайте использовать пользователей базы данных, авторизацию сервисов и secrets. Сеть определяет доступность, а учётные данные — разрешения.

Как включить приватную сеть проекта?

Включите сеть для slug проекта:

dockup network enable production --json

Операция подключает сервисы и управляемые базы данных к сети проекта. Существующие публичные listeners по умолчанию остаются доступными, поэтому переход можно выполнять постепенно.

Повторно задеплойте каждый application-сервис, который должен получить внутренние переменные окружения:

dockup deploy production/api --wait --json
dockup deploy production/worker --wait --json

Dockup добавляет данные для подключения, например DATABASE_URL_INTERNAL, внутренние URL и host-переменные для конкретных баз данных, а также значения host/port сервисов. Просматривайте ключи окружения сервиса, не раскрывая secrets:

dockup env list -s production/api --json

Не создавайте URL вручную на основе отображаемого имени. Имя хоста <slug>.internal определяется slug ресурса.

Прежде чем менять конфигурацию приложения, убедитесь, что все зависимости находятся в одном проекте. У отдельных проектов разные сети, и они не могут разрешать имена или обращаться друг к другу через внутренний маршрут.

Как домены .internal меняют конфигурацию сервисов?

Внутренний DNS предоставляет стабильное имя, пока контейнеры и nodes меняются под ним. К сервису API со slug api можно обращаться как к api.internal из сервисов того же проекта; к базе данных со slug main-db — как к main-db.internal.

По возможности используйте внедряемые переменные подключения. Они содержат правильные protocol, credentials, имя базы данных и формат host. В строке, составленной вручную, могут отсутствовать TLS, кодирование пароля или параметры базы данных.

Переносите зависимости по одной:

1. Включите сеть.
2. Повторно задеплойте использующий её сервис.
3. Убедитесь, что внутренняя переменная существует.
4. Измените приложение, чтобы оно использовало эту переменную.
5. Выполните deploy с --wait.
6. Проверьте новые подключения.
7. Наблюдайте за runtime-логами и временем ответа.
8. Перейдите к следующей зависимости.

Сервис может сохранить свой публичный custom domain для пользовательского трафика и одновременно использовать приватные hostnames для backend-вызовов. Публичные и приватные маршруты обслуживают разные границы доверия.

В руководстве переменные окружения и secrets объясняется, почему после изменения подключения требуется повторный deploy.

Как сделать управляемую базу данных доступной только через приватную сеть?

После того как все необходимые потребители перейдут на внутренний маршрут, удалите публичный listener:

dockup db private production/main-db --json

При необходимости восстановите публичный и приватный доступ:

dockup db private production/main-db --off --json

Эта операция с базой данных пересоздаёт контейнер, сохраняя данные. Запланируйте подходящее для рабочей нагрузки окно обслуживания, убедитесь в наличии свежей backup-копии и протестируйте повторное подключение приложения.

Перед переходом в режим только приватного доступа проверьте:

• Каждый production-сервис, использующий базу данных, находится в том же проекте.
• Для operational tools не требуется публичный endpoint.
• Preview-доступ использует поддерживаемый приватный маршрут.
• Backup существует, а восстановление протестировано и понятно.
• Connection pools безопасно выполняют повторные попытки.
• Точная цель project/db зафиксирована.

К базе данных, доступной только через приватную сеть, нельзя напрямую подключиться с laptop оператора через публичный интернет. Используйте поддерживаемый доступ к платформе и диагностику на уровне приложения, а не включайте listener обратно без необходимости.

Операции с базами данных описаны в руководстве управляемый PostgreSQL.

Как PR preview безопасно получает доступ к production-данным?

Каждый PR или branch preview в Dockup получает собственный изолированный deployment и URL. В проекте с приватной сетью preview подключается к сети проекта и может разрешать <slug>.internal.

Dockup автоматически создаёт пользователя только для чтения для production managed database, используемой preview. Preview может выполнять запросы к данным, соответствующим production по структуре, но не может изменять их через этого пользователя.

Такой подход снижает риск того, что feature branch изменит записи клиентов, однако доступ на чтение всё равно имеет последствия:

• Персональные или конфиденциальные данные могут попасть в preview.
• Новый код приложения может записывать запрошенные данные в logs.
• Уязвимый preview URL может раскрыть результаты запросов.
• Дорогие запросы могут повлиять на production-нагрузку.
• Предположения о схеме могут различаться в branch и production.

Включайте preview deployment только в рамках проверенной политики:

dockup pr-preview production/api --on --json
dockup preview branch feature/search production/api --json

Используйте изолированное окружение preview для feature flags и secrets, не связанных с базой данных. Не заменяйте автоматически созданные credentials только для чтения production credentials с правом записи.

Как наблюдать за приватной сетью и устранять неполадки?

Начинайте с топологии и конфигурации, а не с предположения о сбое платформы.

Симптом	Вероятная область проблемы	Что проверить
Имя не найдено	Неверный slug/project или сервис не был повторно задеплоен	Список сервисов и ключи окружения
Connection refused	Ресурс остановлен или указан неверный port	Status и логи БД/сервиса
Ошибка аутентификации	Неверные credentials	Ротацию secrets и пользователя
Публичный маршрут работает, приватный — нет	Внутренняя переменная или подключение к сети	Включение сети и повторный deploy
Preview может читать, но не писать	Ожидаемая политика доступа только для чтения	Не заменяйте credentials
Вызов между проектами не работает	Ожидаемая изоляция	Используйте публичный аутентифицированный API

Проверьте runtime-логи приложения:

dockup logs production/api --json

Проверьте размер базы данных и ошибки подключений приложения:

dockup db size production/main-db --json
dockup logs production/api --json

Не добавляйте полные внутренние URL подключений в заметки об инциденте. Они могут содержать credentials, даже если само имя хоста не является secret.

План миграции и отката

На первом этапе оставьте публичный listener. Если deployment через внутреннюю сеть завершится ошибкой, верните предыдущую конфигурацию приложения и выполните повторный deploy. Переводите базу данных в режим только приватного доступа лишь после того, как внутренний маршрут проработает стабильно.

Чтобы отключить всю сеть проекта:

dockup network disable production --json

Это должно быть осознанным откатом, а не первым шагом при устранении неполадок. Отключение сети затрагивает каждый подключённый ресурс проекта.

Фиксируйте изменения сети через audit log:

dockup audit --writes --json

Production-чеклист приватной сети

Полный runbook приватной сети включает slug проекта, slug сервисов и баз данных, внутренние hostnames, имена внедряемых переменных, политику публичных listeners, политику доступа preview, статус backup, порядок повторных deployments и путь отката.

CPU, RAM и disk по-прежнему оплачиваются на основе использования и измеряются поминутно; приватная маршрутизация — это архитектурный выбор, а не фиксированный instance class. Для расчёта стоимости используйте материал как устроено ценообразование PaaS.

В справочнике Dockup CLI приведены актуальные команды для работы с сетью и базами данных. Общие рекомендации по изоляции deployment описаны в руководстве рекомендации по безопасности.

Моделируйте авторизацию сервисов отдельно от доступности

Внутреннее имя хоста подтверждает лишь то, что вызывающая сторона находится в сети проекта. Оно не подтверждает, какой именно сервис отправил запрос и имеет ли этот сервис право выполнять действие. Сохраняйте application authentication для чувствительных внутренних API, а database credentials — для доступа к данным.

Используйте отдельные secrets для каждого сервиса, а не один общий internal token. Если preview получает доступ к базе данных только для чтения, не выдавайте ему также production service token, с помощью которого можно инициировать записи через API.

Измеряйте эффект перехода

Сравните latency подключения, error rate и время ответа p95 до и после перехода на внутренние endpoints. Основная цель — изоляция и стабильный приватный маршрут; любое улучшение latency следует измерять, а не обещать заранее.

dockup uptime production/api --hours 24 --json

Сохраните окно наблюдения и ID deployment. Это даёт изменению приватной сети измеримый критерий завершения, вместо того чтобы завершать работу на этапе «DNS разрешил имя».

Документируйте исключения для публичного маршрута

Некоторой внешней интеграции, operator tool или сервису из другого проекта может по-прежнему требоваться публичный endpoint. Для каждого исключения укажите способ аутентификации, владельца и условие удаления. Это не позволит публичному listener оставаться включённым бесконечно только потому, что никто не помнит причину его существования.

Полный rollout приватной сети может быть частичным, но каждый публичный маршрут должен быть осознанным.

Проверяйте внутренние зависимости после переименований

Переименование или замена ресурса может изменить slug, используемый для адресации через .internal. Перед изменением имён составьте список потребителей, повторно задеплойте их с обновлёнными внедряемыми переменными и проверьте каждое приватное подключение.

Так приватная сеть сохраняет стабильность по мере развития проекта.

Начните с проверяемого deployment

Включите сеть в непроизводственном проекте, перенесите одну зависимость на её .internal endpoint и проверьте путь отката, прежде чем удалять какой-либо публичный listener.

Начните бесплатно на app.dockup.ai. План Free стоит $0 в месяц, включает стартовый кредит $10 и поддерживает один workspace, три базы данных и три deployment.

FAQ

Какие hostnames используют ресурсы Dockup в приватной сети?

Каждый сервис и управляемая база данных в одном проекте доступны через стабильное имя хоста в формате <slug>.internal.

Удаляет ли включение приватной сети публичный доступ к базе данных?

Нет. По умолчанию сеть добавляется к существующей конфигурации. Используйте отдельную команду private для базы данных, чтобы удалить публичный listener после перехода потребителей на внутренний маршрут.

Могут ли разные проекты Dockup обращаться друг к другу через приватную сеть?

Нет. У каждого проекта изолированная сеть, поэтому для взаимодействия между проектами необходимо использовать подходящий публичный и аутентифицированный интерфейс.

Может ли PR preview записывать данные в production-базу данных?

В проекте с приватной сетью Dockup автоматически создаёт для preview пользователя базы данных с правами только на чтение. Он позволяет читать данные, но не записывать их с помощью этих credentials.

Почему после включения сети сервисы должны пройти повторный deploy?

Повторный deploy передаёт новому контейнеру внутренние переменные подключения и позволяет приложению запуститься с конфигурацией приватного endpoint.