Post #1492

🧠 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 • Привычку **проверять всё снаружи**, а не только внутри контейнера Подобные ошибки легко пропустить, особенно если всё проверяешь изнутри контейнера.