Частна мрежа и .internal домейни в Dockup

Частната мрежа позволява на услугите и управляваните бази данни в един Dockup проект да комуникират, без трафикът между ресурсите в проекта да преминава през публичния интернет. Всеки ресурс получава стабилно име на хост от вида <slug>.internal, а отделните проекти остават изолирани един от друг.

Мрежата се активира по желание. Включването ѝ свързва съществуващите ресурси в проекта, без да изисква трафикът на приложението да бъде пренасочен незабавно, а услугите получават вътрешните connection променливи след redeploy.

Как комуникацията между услугите намалява публичната експозиция?

Публичен endpoint на база данни е достъпен от интернет, дори когато автентикацията блокира неоторизираното използване. Частният маршрут премахва тази експозиция за трафика на приложението и предоставя на услугите стабилно вътрешно име, което не зависи от публичен адрес.

Същият принцип важи и за извикванията между услуги. Един API може да извиква worker, вътрешна admin услуга или backend през мрежата на проекта, вместо през публичен custom домейн.

Път на трафика	Публичен маршрут	Частен маршрут
API към PostgreSQL	Публичен host и port	main-db.internal
Web към API	Публичен custom домейн	api.internal
Worker към Redis	Публичен host и port	app-redis.internal
Preview към production базата данни	Публичен credential за базата	Вътрешен потребител само за четене
Извикване между проекти	Изисква се публичен endpoint	Блокирано от изолацията на проектите

Частен не означава без автентикация. Продължете да използвате потребители на базата данни, оторизация на услугите и secrets. Мрежата определя достижимостта, а credentials определят правата.

Как активирате частната мрежа за проекта?

Активирайте мрежата за slug-а на проекта:

dockup network enable production --json

Операцията свързва услугите и управляваните бази данни към мрежата на проекта. Съществуващите публични listeners остават достъпни по подразбиране, така че преминаването може да бъде постепенно.

Извършете redeploy на всяка application услуга, която трябва да получи вътрешни environment променливи:

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

Dockup инжектира connection данни като DATABASE_URL_INTERNAL, специфични за базата данни вътрешни URL и host променливи, както и host/port стойности на услугите. Прегледайте ключовете в environment-а на услугата, без да разкривате secrets:

dockup env list -s production/api --json

Не конструирайте ръчно URL от display име. Slug-овете на ресурсите определят името на хоста <slug>.internal.

Преди да промените конфигурацията на приложението, проверете дали всяка зависимост се намира в същия проект. Отделните проекти имат отделни мрежи и не могат да се резолвват или достигат един друг чрез вътрешния маршрут.

Как .internal домейните променят конфигурацията на услугите?

Вътрешният DNS предоставя стабилно име, докато контейнерите и nodes се променят под него. Услуга с slug api е достъпна като api.internal от услугите в същия проект; база данни със slug main-db е достъпна като main-db.internal.

Предпочитайте инжектираните connection променливи, когато са налични. Те съдържат правилния protocol, credentials, име на базата данни и формат на host-а. Ръчно създаден string може да пропусне TLS, encoding на паролата или параметри на базата данни.

Мигрирайте по една зависимост наведнъж:

1. Активирайте мрежата.
2. Извършете redeploy на услугата, която използва зависимостта.
3. Потвърдете, че вътрешната променлива съществува.
4. Променете приложението да я използва.
5. Направете deploy с --wait.
6. Проверете новите connections.
7. Наблюдавайте runtime логовете и времето за отговор.
8. Преминете към следващата зависимост.

Услугата може да запази публичния си custom домейн за потребителския трафик, като едновременно използва частни hostnames за backend извикванията. Публичните и частните маршрути обслужват различни trust boundaries.

Ръководството environment променливи и secrets обяснява защо промените в connection изискват redeploy.

Как правите управлявана база данни достъпна само през частната мрежа?

След като всеки необходим consumer използва вътрешния маршрут, премахнете публичния listener:

dockup db private production/main-db --json

Възстановете достъпа едновременно през публичния и частния маршрут, когато е необходимо:

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

Тази операция върху базата данни пресъздава контейнера, като запазва данните. Планирайте maintenance window, подходящ за натоварването, потвърдете наличието на скорошен backup и тествайте повторното свързване на приложението.

Преди да направите базата достъпна само през частната мрежа, проверете:

• Всяка production услуга, която използва базата данни, е в същия проект.
• Operational tools не изискват публичния endpoint.
• Достъпът от preview средите използва поддържания частен маршрут.
• Съществува backup и възстановяването е изяснено.
• Connection pools извършват retry безопасно.
• Точният target project/db е записан.

База данни, достъпна само през частната мрежа, не може да бъде достигната директно от laptop на оператор през публичния интернет. Използвайте поддържания достъп до платформата и diagnostics на ниво приложение, вместо безпричинно да отваряте listener-а отново.

За операции с бази данни вижте управляван PostgreSQL.

Как PR preview средите получават безопасен достъп до production данни?

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

Dockup автоматично създава потребител само за четене за production управляваната база данни, използвана от preview средата. Preview средата може да изпълнява заявки към данни със структура като в production, но не може да записва чрез този потребител.

Този дизайн намалява риска feature branch да промени клиентски записи, но достъпът за четене все пак има последствия:

• Лични или чувствителни данни може да се появят в preview средата.
• Новият application code може да записва в логовете извлечени данни.
• Уязвим preview URL може да изложи резултатите от заявките.
• Скъпи заявки могат да повлияят на production натоварването.
• Предположенията за schema-та може да се различават между branch-а и production.

Активирайте preview deployment само съгласно прегледана политика:

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

Използвайте изолираната environment среда на preview за feature flags и secrets, които не са свързани с базата данни. Не заменяйте автоматичния credential само за четене с production credential с права за запис.

Как се наблюдава и отстранява проблем с частната мрежа?

Започнете с топологията и конфигурацията, вместо да приемате, че проблемът е в платформата.

Симптом	Вероятна област	Проверка
Името не е намерено	Грешен slug/project или услугата не е redeploy-ната	Списък с услуги и env ключове
Connection refused	Ресурсът е спрян или port-ът е грешен	Status и логове на DB/услугата
Неуспешна автентикация	Грешен credential	Rotation на secret и потребител
Публичният маршрут работи, частният не	Вътрешна променлива или непълно включване в мрежата	Активиране на мрежата, redeploy
Preview може да чете, но не и да записва	Очаквана политика само за четене	Не заменяйте credential-а
Извикването между проекти не работи	Очаквана изолация	Използвайте публичен автентикиран API

Прегледайте runtime логовете на приложението:

dockup logs production/api --json

Проверете размера на базата данни и грешките при връзка от приложението:

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

Не записвайте пълни вътрешни connection URL адреси в incident бележки. Те може да съдържат credentials, въпреки че самият hostname не е secret.

План за миграция и rollback

Запазете публичния listener по време на първата фаза. Ако вътрешното deployment се провали, възстановете предишната конфигурация на приложението и направете redeploy. Направете базата данни достъпна само през частната мрежа едва след като вътрешният маршрут е стабилен.

За да деактивирате цялата мрежа на проекта:

dockup network disable production --json

Това трябва да бъде обмислен rollback, а не първата стъпка при troubleshooting. Деактивирането на мрежата засяга всеки свързан ресурс в проекта.

Записвайте промените по мрежата чрез audit log:

dockup audit --writes --json

Production checklist за частната мрежа

Пълният runbook за частна мрежа включва slug на проекта, slug-ове на услугите и базите данни, вътрешни hostnames, имена на инжектираните променливи, политика за публичния listener, политика за достъп на preview средите, status на backup-а, реда на redeploy-ите и rollback пътя.

CPU, RAM и disk продължават да се таксуват според използването и се измерват на минута; частното маршрутизиране е архитектурен избор, а не фиксиран клас инстанция. Използвайте Обяснение на PaaS ценообразуването за моделиране на разходите.

Справочникът за Dockup CLI съдържа актуалните команди за мрежи и бази данни. За обща изолация при deployment вижте най-добри практики за сигурност.

Моделирайте оторизацията на услугите отделно от достижимостта

Вътрешният hostname доказва само, че caller-ът е в мрежата на проекта. Той не доказва коя услуга е направила заявката или дали тази услуга има право да извърши действието. Запазете application authentication за чувствителни вътрешни API и credentials на базата данни за достъп до данните.

Използвайте специфични за услугата secrets, вместо един споделен вътрешен token. Ако preview средата получава достъп само за четене до базата данни, не ѝ предоставяйте и production service token, който може да задейства записи чрез API.

Измерете ефекта от преминаването

Сравнете latency на connection-ите, error rate и p95 времето за отговор преди и след преминаването към вътрешни endpoints. Основната цел е изолация и стабилен частен маршрут; всяко подобрение в latency трябва да бъде измерено, а не обещавано.

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

Запазете observation window и ID на deployment-а. Така промяната в частната мрежа получава измерим критерий за завършеност, вместо да приключва с „DNS се резолва“.

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

Някои външни интеграции, operator tools или услуги между проекти може все още да изискват публичен endpoint. Избройте всяко изключение, неговата автентикация, owner-а и условието за премахване. Така публичният listener няма да остане отворен безсрочно, защото никой не помни защо съществува.

Пълното внедряване на частна мрежа може да бъде частично, но всеки публичен маршрут трябва да е умишлено оставен.

Преглеждайте вътрешните зависимости след преименуване

Преименуването или подмяната на ресурс може да промени slug-а, използван за .internal адресиране. Направете инвентаризация на consumer-ите, преди да променяте имената, извършете redeploy с актуализираните инжектирани променливи и проверете всяка частна връзка.

Това поддържа частната мрежа стабилна с развитието на проекта.

Започнете с deployment, което може да бъде проверено

Активирайте мрежата в non-production проект, мигрирайте една зависимост към нейния .internal endpoint и докажете rollback пътя, преди да премахнете публичен listener.

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

Често задавани въпроси

Какъв hostname използват ресурсите на Dockup в частната мрежа?

Всяка услуга и управлявана база данни в същия проект е достъпна чрез стабилен hostname във формата <slug>.internal.

Активирането на частната мрежа премахва ли публичния достъп до базата данни?

Не. По подразбиране мрежата се добавя, без да премахва съществуващия достъп. Използвайте отделната команда за частна база данни, за да премахнете публичния listener, след като consumer-ите започнат да използват вътрешния маршрут.

Могат ли различни Dockup проекти да се достигат през частната мрежа?

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

Може ли PR preview среда да записва в production базата данни?

В проект с частна мрежа Dockup автоматично създава потребител на базата данни само за четене за preview средата, което позволява четене, но предотвратява запис чрез този credential.

Защо услугите трябва да направят redeploy след активиране на мрежата?

Redeploy предоставя на новия контейнер вътрешните connection променливи и позволява на приложението да стартира с конфигурация за частния endpoint.