🧠 DevOps-задача: "Контейнер Шрёдингера"

Условие:
Ты получаешь баг-репорт:
> "Приложение внутри Docker-контейнера после деплоя не работает, но docker exec показывает, что оно запущено, порт слушает, ошибок нет. Однако при curl изнутри — всё работает, а снаружи — нет ответа."

Что известно:

- Docker-контейнер на основе alpine:3.18
- Приложение запускается через CMD ["/bin/service-start"]
- Порт 8080 проброшен (`-p 8080:8080`)
- curl localhost:8080 внутри контейнера возвращает 200 OK
- curl localhost:8080 на хосте — зависает
- netstat -tulpn показывает, что порт 8080 прослушивается внутри

Задача:
Найди вероятную причину, предложи способ воспроизведения, диагностики и исправления. Подумай как DevOps, а не просто как админ.

📌 Разбор:

🕵️ Подвох №1: **приложение слушает 127.0.0.1:8080**, а не 0.0.0.0
• внутри `curl localhost:8080` работает
• а хост не может достучаться, потому что `127.0.0.1` — это loopback внутри контейнера, а не на host

Решение:
- Проверить снаружи: `docker inspect <container_id> | grep IPAddress`
- Проверить bind-порт внутри:
```bash
netstat -tulpn | grep 8080
# или ss -tulpn | grep 8080
```
- Если видим `127.0.0.1:8080` — всё ясно: нужно слушать на `0.0.0.0:8080`

🛠 Исправление:

1. Проверь запуск приложения. Может, внутри у тебя:
```bash
python3 app.py
```
и он слушает только на localhost? Добавь:
```bash
python3 app.py --host=0.0.0.0
```

2. В Go, Node.js, Python и т.д. — по умолчанию bind'ят на 127.0.0.1
Проверь в настройках приложения или командной строке

🎯 Что проверяет задача:

• Умение мыслить в терминах изоляции контейнеров
• Понимание сетевых пространств имён (network namespaces)
• Знание, как работает NAT между контейнером и хостом
• Умение диагностировать "невидимый" bind
• Привычку **проверять всё снаружи**, а не только внутри контейнера

Подобные ошибки легко пропустить, особенно если всё проверяешь изнутри контейнера.