Обзор Ingress

Opfield использует управляемые ноды nginx как публичный Ingress. Полностью настроенный публичный сервис объединяет Domain, сертификат, Route, целевую службу, политику состояния и размещение на ноде. Такой состав даёт единый управляемый путь от имени хоста до приложения.

Routes могут проксировать запросы, перенаправлять их или возвращать 404. Целевой службой прокси может быть введённый вручную адрес, автономный Container, Deployment, служба Compose или готовый Pages Tag. Additional Routes направляют буквальные префиксы путей, например /api, к отдельным целевым службам.

Используйте режим nginx managed, если Opfield должен владеть заведомо исправной базовой конфигурацией. Выбирайте integrate, если существующая установка nginx должна сохранить свою базовую конфигурацию и подключать включаемые файлы под управлением Opfield.

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

Владение ресурсами

У ресурсов Ingress разные жизненные циклы, даже если для пользователя они выглядят как одно публичное приложение:

• Domain владеет именем хоста и размещением на nginx;
• SSL Certificate владеет материалом сертификата и состоянием продления;
• Route владеет поведением запросов, политикой состояния и основной целевой службой;
• Additional Route владеет одним переопределением буквального префикса пути;
• Access List — переиспользуемая политика, которую можно подключить к нескольким Routes;
• принадлежащий Route Secure Link следует за этим Route и не может быть удалён отдельно.

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

Рекомендуемый порядок создания

1. Зарегистрируйте и проверьте целевую ноду Ingress.
2. Зарегистрируйте Domain и подтвердите его размещение.
3. Выпустите или загрузите TLS-сертификат.
4. Создайте Route и выберите целевую службу.
5. Добавляйте политику доступа, заголовки, WebSockets, правила переписывания или изменённые тайм-ауты только при необходимости.
6. Включите Route и дождитесь валидации конфигурации nginx.
7. Проверьте HTTP и HTTPS с внешнего клиента.
8. Подтвердите историю состояния, журналы доступа и распространение сертификата.

Правила безопасной эксплуатации

• Сохраняйте одного канонического владельца каждого имени хоста; не создавайте вне Opfield конкурирующие Routes для того же хоста.
• Считайте необработанную конфигурацию nginx экспертным аварийным механизмом. Она отключает часть управляемой валидации и функций жизненного цикла.
• Не публикуйте порт приватной рабочей нагрузки только потому, что Secure Link временно неисправен.
• Для запланированных работ, заметных клиентам, используйте режим обслуживания. Отключайте Route только тогда, когда трафик должен остановиться полностью.
• Переносите размещение через явный сценарий миграции, чтобы Domains, Routes, сертификаты, состояние, изменения DNS и проверки оставались согласованными.

Ответственность Opfield и оператора

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

Это различие особенно важно при инциденте. Работоспособная нода Ingress подтверждает доступность демона и nginx, но не доказывает, что публичный DNS указывает на эту ноду, что у каждого Route доступна целевая служба или что внешняя сеть пропускает трафик. И наоборот, неуспешная проверка состояния приложения не требует перестраивать хост nginx. Диагностируйте цепочку от публичного имени хоста к приложению и изменяйте только неисправный уровень.

Для рабочей среды заранее назначьте ответственных за DNS, сертификаты, Routes, Access Lists и релизы приложений. Сохраняйте аварийный доступ к Opfield независимо от имени хоста обслуживаемого приложения. Перед изменением общих сертификатов и Access Lists проверяйте их связи: одна правка может затронуть несколько Routes.

Приёмка сервиса в рабочей среде

Прежде чем объявить имя хоста готовым, проверьте его из сети вне управляемых хостов. Подтвердите ответы DNS, поведение перенаправления HTTP, цепочку и имя хоста HTTPS-сертификата, ожидаемый ответ приложения и WebSocket, если он используется. Затем сопоставьте запрос с историей состояния Opfield и журналами доступа nginx.

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

Далее настройте цепочку по разделу Домены, Routes и TLS, подключите закрытые Docker-цели по разделу Приватные целевые службы или найдите неисправность с помощью Диагностики Ingress.