## 🐳 Когда объединение сетей [[Docker]] неудобно, а нужно срочно связаться через порт хоста {#sec-f27028c85270}

Обычно для связи между контейнерами создают общую мостовую сеть и вызывают по имени службы (например, `http://app-b:8080`). Но иногда в жизни возникают обстоятельства, когда следовать стандартным правилам невозможно.

## Используйте этот метод в следующих "непредвиденных ситуациях" {#sec-3da904d03848}

*   **При необходимости связи со службами, установленными непосредственно на хосте:** Когда DB или Redis установлены непосредственно на ОС хоста, а не в контейнере, и объединение сетей невозможно.
*   **При работе с чужим контейнером, когда страшно менять сетевые настройки:** Когда вы опасаетесь, что принудительное включение вашего контейнера в сложную, неуправляемую вами сетевую конфигурацию может привести к сбоям.
*   **При необходимости "временной" проверки соединения во время локальной разработки:** Когда проектирование сети не имеет значения, и нужно просто немедленно проверить, проходит ли запрос к службе, доступной через порт хоста.

В таких случаях полезным "чит-кодом" является `host.docker.internal`.

![Связь между контейнерами через хост](/media/whitedec/blog_img/4e661ed1ddb648529e5b1681c022cd25.webp)

---

## Решение: "Окно в мир за пределами контейнера" `host.docker.internal` {#sec-979a012d89c8}

Если внутри контейнера вы обратитесь к `127.0.0.1`, вы увидите только самого себя (контейнер). Однако, используя специальный домен `host.docker.internal`, вы можете "пробить" стену контейнера и получить IP-адрес хост-машины.

**Пример кода Python (DRF):**

```python
# Вместо 'localhost' используйте 'host.docker.internal' для обращения к порту хоста.
# Если App-B привязан к порту 8080 на хосте, вызов будет выглядеть так:
NEXTCLOUD_URL = "http://host.docker.internal:8080"

response = requests.get(NEXTCLOUD_URL)

```

---

## ⚠️ Для пользователей [[Linux]] необходима "ручная настройка" {#sec-169e1a1f873c}

В Docker Desktop (Mac/Windows) это работает по умолчанию, но на **чистом Linux-сервере** Docker не назначает этот домен автоматически. Необходимо явно указать при сборке или запуске, что "этот домен означает IP-адрес хоста".

**Пример настройки Docker Compose:**

```yaml
services:
  drf-app:
    image: my-drf-app-image
    extra_hosts:
      # Объявление доступа к шлюзу хоста под именем host.docker.internal
      - "host.docker.internal:host-gateway"

```

---

## Это не всегда лучшее решение {#sec-bb28e4a13c7f}

Повторюсь, этот метод является скорее **крайней мерой**.

1.  **Наилучший подход:** Создать общую мостовую сеть и общаться по именам контейнеров (наиболее безопасно).
2.  **Причины для использования этого метода:** Необходимость доступа к процессам, запущенным непосредственно на хосте, или когда сетевую структуру невозможно объединить в "изолированной" среде.

Используйте этот "запасной выход", записанный в прошлом году, только как скрытую карту, когда стандартные методы не работают!