Приватна мережа та домени .internal у Dockup

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

Мережа вмикається за бажанням. Після її ввімкнення наявні ресурси проєкту під’єднуються до мережі, але застосунковий трафік не потрібно одразу перемикати на неї. Після повторного розгортання сервіси отримують внутрішні змінні підключення.

Як взаємодія між сервісами зменшує публічну доступність?

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

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

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

Приватний не означає неавтентифікований. Продовжуйте використовувати користувачів бази даних, авторизацію сервісів і секрети. Мережа визначає доступність, а облікові дані — дозволи.

Як увімкнути приватну мережу проєкту?

Увімкніть мережу для slug проєкту:

dockup network enable production --json

Ця операція під’єднує сервіси та керовані бази даних до мережі проєкту. Наявні публічні listener-и за замовчуванням залишаються доступними, тому перехід можна виконувати поступово.

Повторно розгорніть кожен застосунковий сервіс, який має отримати внутрішні змінні середовища:

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

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

dockup env list -s production/api --json

Не створюйте URL вручну на основі display name. Slug ресурсу визначає ім’я хоста <slug>.internal.

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

Як домени .internal змінюють конфігурацію сервісів?

Внутрішній DNS надає стабільне ім’я, навіть якщо контейнери й вузли під ним змінюються. Сервіс зі slug api доступний як api.internal із сервісів того самого проєкту; база даних зі slug main-db доступна як main-db.internal.

Якщо доступно, надавайте перевагу змінним підключення, які додаються автоматично. Вони містять правильний протокол, облікові дані, назву бази даних і формат хоста. У рядку, створеному вручну, можуть бути відсутні TLS, кодування пароля або параметри бази даних.

Переносьте залежності по одній:

1. Увімкніть мережу.
2. Повторно розгорніть сервіс, який використовує залежність.
3. Переконайтеся, що внутрішня змінна існує.
4. Змініть застосунок, щоб він використовував цю змінну.
5. Виконайте розгортання з --wait.
6. Перевірте нові підключення.
7. Переглядайте runtime-логи та час відповіді.
8. Перейдіть до наступної залежності.

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

У посібнику змінні середовища та секрети пояснюється, чому зміни підключення потребують повторного розгортання.

Як зробити керовану базу даних доступною лише через приватну мережу?

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

dockup db private production/main-db --json

За потреби відновіть одночасно публічний і приватний доступ:

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

Ця операція з базою даних повторно створює контейнер, зберігаючи дані. Заплануйте вікно обслуговування відповідно до навантаження, переконайтеся, що є свіжа резервна копія, і протестуйте повторне підключення застосунку.

Перш ніж залишати доступ лише приватним, перевірте:

• Усі production-сервіси, які використовують базу даних, належать до того самого проєкту.
• Операційним інструментам не потрібен публічний endpoint.
• Preview-доступ використовує підтримуваний приватний маршрут.
• Резервна копія існує, а відновлення перевірено.
• Пули підключень безпечно повторюють спроби.
• Точну ціль project/db зафіксовано.

До бази даних із доступом лише через приватну мережу не можна напряму підключитися з ноутбука оператора через публічний інтернет. Використовуйте підтримуваний platform access і діагностику на рівні застосунку, а не вмикайте listener повторно без потреби.

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

Як PR preview-середовища безпечно отримують доступ до production-даних?

Кожен PR або branch preview у Dockup отримує власне ізольоване розгортання та URL. У проєкті з приватною мережею preview під’єднується до мережі проєкту й може знаходити <slug>.internal.

Dockup автоматично створює користувача лише для читання для production-бази даних, яку використовує preview. Preview може виконувати запити до даних, структурованих як production-дані, але не може записувати їх через цього користувача.

Такий підхід зменшує ризик того, що feature branch змінить записи клієнтів, однак доступ на читання все одно має наслідки:

• У preview можуть відображатися персональні або конфіденційні дані.
• Новий код застосунку може записувати отримані дані в логи.
• Вразливий preview URL може розкрити результати запитів.
• Дорогі запити можуть вплинути на навантаження production.
• Припущення щодо схеми можуть відрізнятися у branch і production.

Вмикайте preview-розгортання лише відповідно до перевіреної політики:

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

Використовуйте ізольоване середовище preview для feature flags і секретів, не пов’язаних із базою даних. Не замінюйте автоматичні облікові дані лише для читання production-обліковими даними з правом запису.

Як відстежувати стан і усувати проблеми приватної мережі?

Почніть із топології та конфігурації, а не з припущення про збій платформи.

Симптом	Ймовірна причина	Перевірка
Ім’я не знайдено	Неправильний slug або проєкт, чи сервіс не було повторно розгорнуто	Список сервісів і ключі змінних середовища
Підключення відхилено	Ресурс зупинено або вказано неправильний порт	Статус і логи БД/сервісу
Помилка автентифікації	Неправильні облікові дані	Ротація секретів і користувач
Публічний маршрут працює, приватний — ні	Внутрішня змінна або підключення до мережі	Увімкнення мережі, повторне розгортання
Preview може читати, але не записувати	Очікувана політика доступу лише для читання	Не замінюйте облікові дані
Виклик між проєктами не працює	Очікувана ізоляція	Використовуйте публічний автентифікований API

Перегляньте runtime-логи застосунку:

dockup logs production/api --json

Перевірте розмір бази даних і помилки підключення застосунку:

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

Не додавайте повні внутрішні URL підключення до нотаток про інцидент. Вони можуть містити облікові дані, навіть якщо саме ім’я хоста не є секретом.

План міграції та відкату

На першому етапі залиште публічний listener. Якщо внутрішнє розгортання не вдасться, відновіть попередню конфігурацію застосунку та повторно розгорніть його. Робіть базу даних доступною лише через приватну мережу після того, як внутрішній маршрут працюватиме стабільно.

Щоб вимкнути всю мережу проєкту:

dockup network disable production --json

Це має бути свідомим відкатом, а не першим кроком під час пошуку проблеми. Вимкнення мережі впливає на кожен під’єднаний ресурс проєкту.

Фіксуйте зміни мережі в audit log:

dockup audit --writes --json

Production-чекліст приватної мережі

Повний runbook для приватної мережі містить slug проєкту, slug сервісів і баз даних, внутрішні імена хостів, назви змінних, доданих автоматично, політику публічних listener-ів, політику доступу preview, статус резервних копій, порядок повторного розгортання та шлях відкату.

CPU, RAM і диск і надалі оплачуються залежно від використання та вимірюються щохвилини; приватна маршрутизація — це архітектурне рішення, а не фіксований клас інстансу. Для моделювання витрат скористайтеся матеріалом пояснення цін PaaS.

У довіднику Dockup CLI наведено актуальні команди для роботи з мережею та базами даних. Загальні принципи ізоляції розгортань описано в матеріалі найкращі практики безпеки.

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

Внутрішнє ім’я хоста доводить лише те, що відправник перебуває в мережі проєкту. Воно не підтверджує, який саме сервіс виконав запит і чи має цей сервіс право виконувати дію. Зберігайте автентифікацію застосунку для чутливих внутрішніх API, а облікові дані бази даних — для доступу до даних.

Використовуйте окремі секрети для кожного сервісу, а не один спільний внутрішній токен. Якщо preview отримує доступ до бази даних лише для читання, не надавайте йому також production-токен сервісу, за допомогою якого через API можна запускати операції запису.

Вимірюйте ефект переходу

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

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

Зберігайте період спостереження та ID розгортання. Це дає зміні приватної мережі вимірюваний критерій завершення, замість того щоб завершувати її на етапі «DNS розв’язав ім’я».

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

Деякі зовнішні інтеграції, операторські інструменти або сервіси з інших проєктів можуть і надалі потребувати публічного endpoint. Зазначте для кожного винятку спосіб автентифікації, відповідального та умову видалення. Це не дасть публічному listener-у залишатися назавжди лише тому, що ніхто не пам’ятає причину його існування.

Повний rollout приватної мережі може бути частковим, але кожен публічний маршрут має бути навмисним рішенням.

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

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

Так приватна мережа залишатиметься стабільною в міру розвитку проєкту.

Почніть із розгортання, яке можна перевірити

Увімкніть мережу в непостійному production-проєкті, перенесіть одну залежність на її .internal endpoint і перевірте шлях відкату, перш ніж видаляти будь-який публічний listener.

Почніть безкоштовно на app.dockup.ai. План Free коштує $0 на місяць, включає стартовий кредит $10 і підтримує один workspace, три бази даних та три розгортання.

FAQ

Яке ім’я хоста використовують ресурси Dockup у приватній мережі?

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

Чи видаляє ввімкнення приватної мережі публічний доступ до бази даних?

Ні. За замовчуванням мережа додає приватний маршрут, не змінюючи публічний. Скористайтеся окремою командою для приватного режиму бази даних, щоб видалити публічний listener після переходу споживачів на внутрішній маршрут.

Чи можуть різні проєкти Dockup приватно взаємодіяти між собою?

Ні. Кожен проєкт має ізольовану мережу, тому для взаємодії між проєктами потрібно використовувати відповідний публічний автентифікований інтерфейс.

Чи може PR preview записувати дані в production-базу?

У проєкті з приватною мережею Dockup автоматично створює для preview користувача бази даних лише для читання. Це дає змогу читати дані, але не записувати їх через ці облікові дані.

Чому після ввімкнення мережі сервіси потрібно повторно розгорнути?

Після повторного розгортання новий контейнер отримує внутрішні змінні підключення, і застосунок може запуститися з конфігурацією приватного endpoint.