DevOps

🔍 Google Cloud представил **KHI (Kubernetes History Inspector)** — инструмент, который превращает логи Kubernetes в интерактивную визуальную историю. 🧠 Зачем нужен KHI: • Когда что-то ломается в кластере, часто приходится разбираться по сырым логам, и это ад • KHI решает эту проблему: загружает все события в память и строит понятную временную шкалу всего, что происходило с ресурсами 🚀 Что умеет: • Визуализирует логи как временную шкалу: деплой, рестарты, скейлы, падения • Поддерживает фильтры и поиск — быстро находит нужные события • Работает без агентов — использует уже существующие логи • Показывает историю манифестов, состояния контейнеров, эвенты подов и многое другое 🛠 Подходит для: • Отладки инцидентов и RCA (root cause analysis) • Разработчиков и SRE, которым важно понимать, что именно пошло не так и когда 📎 GitHub: https://github.com/GoogleCloudPlatform/khi @devopsitsec

Безопасность приложений будущего — в ваших руках В karpovꓸcourses запускается новая совместная программа с МФТИ — ведущим техническим вузом страны, который входит в престижные рейтинги лучших университетов мира, — «Application Security: безопасная разработка приложений». За 3 месяца вы: > Научитесь разрабатывать безопасные приложения, выявлять уязвимости и защищать сервисы от атак. > Освоите ключевые инструменты анализа безопасности и интегрируете защиту на всех этапах разработки. > Изучите безопасность AI-систем и ML-моделей. Кому это может быть интересно? Программа подойдёт для: разработчиков, DevOps-инженеров, архитекторов, специалистам по информационной безопасности, Security Champions и студентам факультетов инфо- и кибербезопасности Узнать больше о программе и подать заявку можно по ссылке. Реклама. ООО «Карпов Курсы», ИНН: 7811764627, erid: 2VtzqwrtNh3

🌒 LunaTrace — бесплатный open-source инструмент для аудита безопасности зависимостей. Он автоматически сканирует зависимости в проектах, выявляет уязвимости и интегрируется с GitHub Pull Requests, чтобы предупреждать о рисках до деплоя. Главное преимущество проекта — это гибкость развёртывания. Можно использовать готовый SaaS или запустить свою инстанс-версию. Помимо мониторинга, в арсенале есть Log4Shell CLI для поиска и исправления уязвимых JAR-файлов и блог с разборами security-проблем. 🤖 GitHub @devsecops

7 популярных мифов о Service mesh, которые мешают вам его освоить 🚫 Service mesh окружен заблуждениями, из-за которых многие его боятся внедрять или считают бесполезным: ➖ «У него огромный оверхед из-за нагрузки на систему» ➖ «Для разработчика это лишнее, пусть DevOps разбираются» ➖ «Зачем он нужен, если есть API Gateway? И многое другое. Собрали противоречивые утверждения в одном файле и разобрались, где – правда, а где – миф. 📌 Забирайте полезный материал у бота-помощника в один клик. erid: 2W5zFFwDVYC

🧠 Claude Opus решил баг, с которым я боролся почти 5 лет — личная история разработчика C++ и бывшего старший инженер FAANG с 💬 Один из пользователей на Reddit поделился настоящим инсайтом: после многолетней борьбы с трудноуловимым багом, ему наконец-то помог… Claude Opus. Баг был из тех, что появляются раз в полгода, ведут себя нестабильно, и каждый раз ускользают от дебаггера. В отчаянии он просто описал проблему Claude-у — без стеков, логов, трейсинга. И внезапно получил абсолютно точный ответ: баг оказался связан с тем, как обрабатывались замыкания внутри лямбд, теряющих доступ к нужному контексту после асинхронного вызова. 🤯 Результат: 5 лет неуловимого бага ушли за 30 секунд диалога с ИИ. 📌 Это не просто красивая история. Она показывает, как LLM уровня Opus начинает конкурировать не только с поиском и документацией — но и с самим процессом инженерного мышления. 🔍 Что можно вынести: • Не бойся формулировать даже "глупые" вопросы — хорошие модели часто угадывают суть • Застрял на баге? Попробуй объяснить его как человеку — иногда именно это помогает найти решение • Хороший ИИ не заменит опыт, но может стать отличным напарником по отладке 📎 Оригинальный пост на Reddit

🏰 SSHportal — умный шлюз для SSH-доступа без головной боли. Этот проект превращает управление SSH-доступом в интуитивный процесс. Вместо ручного редактирования authorized_keys на каждом сервере, SSHportal централизует контроль через единую точку входа с ролевой моделью доступа. Инструмент имеет встроенную систему инвайтов: можно приглашать пользователей без обмена ключами вручную. Под капотом SQLite/MySQL для хранения данных и полная совместимость с обычными SSH-клиентами. 🤖 GitHub @devopsitsec

☸ История создания Kubernetes — от внутреннего инструмента Google до мировой революции Когда в 2014 году Google выложил в открытый доступ свой внутренний проект под странным именем Kubernetes, мало кто осознал, что это начало настоящей контейнерной революции. Но за этой лаконичной оболочкой скрывалась мощь, проверенная на миллиардах пользователей Google Search, Gmail и YouTube. 🔥 Всё началось с Borg Внутри Google уже с 2003 года существовала система управления контейнерами — Borg. Это был секретный, монструозный и невероятно мощный оркестратор, позволявший запускать сотни тысяч задач на десятках тысяч серверов. Но Borg был закрыт, сложный и не предназначен для внешнего мира. 💡 Факт: Borg умел автоматически лечить упавшие сервисы задолго до того, как "self-healing" стал модным словом в DevOps. 🚀 Почему Kubernetes? Google хотел подарить миру упрощённую, но эффективную версию Borg — с понятным API, без проприетарных завязок и... с хорошим маркетингом. Так родился Kubernetes — проект с открытым исходным кодом, построенный на Go, и вдохновлённый Borg и его экспериментальным "младшим братом" — Omega. 🔷 Факт: Название "Kubernetes" пришло из греческого языка и означает "штурман". Это намёк: Kubernetes управляет "флотом" контейнеров как кораблями. 👨‍💻 Кто стоял у истоков? Изначально за Kubernetes отвечали три инженера Google: Joe Beda Brendan Burns Craig McLuckie Позже к ним присоединился Brian Grant, архитектор Borg, и вскоре десятки инженеров со всего мира стали развивать проект под крылом Cloud Native Computing Foundation (CNCF). 🧨 Факт: Kubernetes стал самым активным проектом на GitHub в 2015 году — больше коммитов, чем у Linux! 🌐 Как Kubernetes завоевал мир? 🔄 Контейнеры стали стандартом благодаря Docker, но их нужно было как-то управлять — и тут вошёл Kubernetes. 🎯 Kubernetes оказался универсальным: он мог запускаться на ноутбуке, в дата-центре, в облаке, даже на Raspberry Pi. 💥 Все большие игроки — AWS, Azure, IBM, Red Hat — вынуждены были поддержать Kubernetes, иначе рисковали остаться вне игры. 📦 Экосистема вокруг Kubernetes выросла в десятки раз: Helm, Istio, Prometheus, ArgoCD, Knative — всё это родилось в его тени. 🛡 Факт: Kubernetes — это не просто оркестратор. Это операционная система для облака. Она изменила сам подход к разработке: теперь приложения проектируются "cloud-native", а не "серверные". ⚙️ Kubernetes сегодня Сейчас Kubernetes: Работает в каждом втором крупном enterprise-проекте Поддерживается всеми облачными провайдерами Является де-факто стандартом для микросервисной архитектуры Вдохновил создание K8s-альтернатив: Nomad, OpenShift, K3s, и других 💡 Вывод Kubernetes — это не просто проект, это движение, начатое с утечки идей из недр Google и переросшее в открытую революцию управления инфраструктурой. Как Git изменил подход к коду, так Kubernetes изменил подход к запуску программ. Сегодня без Kubernetes — ни один серьёзный DevOps не чувствует себя в безопасности. Хочешь больше таких историй из мира технологий? 😉

⚡️ OneUptime — open-source-платформа для мониторинга всего и сразу. Этот инструмент предлагает готовый комплект: от мониторинга uptime до управления инцидентами. Редкий случай, когда open-source-проект не уступает коммерческим аналогам по функционалу. Особенность проекта в глубокой интеграция компонентов. Например, при падении сервиса система автоматически создаёт инцидент, уведомляет ответственных через эскалацию и обновляет статус-страницу. Есть даже встроенный APM с трейсами и метриками производительности. Развернуть можно на Kubernetes или через Docker Compose. 🤖 GitHub @devopsitsec

🚀 Разгоняем kube-prometheus-stack: секретный ингредиент в Observability 🔥 9 июня в 20:00 мск — бесплатный вебинар «Разгоняем kube-prometheus-stack». Мониторинг не должен тормозить, особенно когда что-то идёт не так. Что разберём: – как ускорить отклик Grafana при работе с большими объёмами данных, – что замедляет Prometheus и как с этим бороться, – как сократить сетевой трафик мониторинга без потерь, – как не положить observability-инфру при инциденте, – и какие архитектурные подходы помогают сделать мониторинг отказоустойчивым. Оптимизируйте kube-prometheus-stack и держите руку на пульсе — даже в условиях пиковых нагрузок. 👉 Регистрируйтесь здесь: https://otus.pw/JuU8/?erid=2W5zFGaKsHS Занятие приурочено к старту курса "Observability: мониторинг, логирование, трейсинг", на котором вы научитесь строить эффективные системы мониторинга, работать с Prometheus, Grafana, ELK и другими инструментами, визуализировать метрики. Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

🔧 DevOps Pro Tips: Оптимизация контейнеров как у SRE Google Контейнер — это не просто Dockerfile. Это микросистема, и если её не настраивать — она будет жечь CPU, RAM и SSD без пользы. Вот 🔥 продвинутые советы по настройке контейнеров: ⚫ Ограничь права контейнера

docker run --read-only --cap-drop=ALL --security-opt no-new-privileges ...

▪️ --read-only — защищает файловую систему ▪️ --cap-drop=ALL — удаляет лишние привилегии ▪️ no-new-privileges — запрещает повышение прав в процессе ⚫ Установи лимиты CPU и памяти

docker run --memory="512m" --cpus="1.5" ...

▪️ Не давай контейнеру жрать весь хост — особенно на multi-tenant нодах ▪️ Используй cpu-shares, cpuset, ulimits для тонкой настройки ⚫ Чисти от мусора - Используй multi-stage builds — минимизируй размер образа - Оставляй только необходимые бинарники и конфиги - Пример:

FROM golang:1.22 as builder
WORKDIR /app
COPY . .
RUN go build -o app

FROM alpine:3.19
COPY --from=builder /app/app /bin/app
ENTRYPOINT ["/bin/app"]

⚫ Используй distroless или Alpine - Образы типа gcr.io/distroless/static — без шелла, package manager и мусора - alpine — легче, но следи за совместимостью с glibc ⚫ Пропиши healthcheck

HEALTHCHECK --interval=30s --timeout=3s CMD curl -f http://localhost:8080/health || exit 1

▪️ Kubernetes будет перезапускать только при реальных сбоях ⚫ Подключи observability - Встраивай Prometheus exporter - Логи — в stdout/stderr (для kubectl logs и EFK/PLG стека) - Используй otel, если нужен tracing ⚫ Проверь, чем занят контейнер

docker top <container>
docker inspect --format '{{ .HostConfig }}' <container>

▪️ Вовремя заметишь, если процесс форкает что-то лишнее или идёт через /dev 💡 Эти практики критичны, если: - Вы деплоите в прод с autoscaling - Контейнеры крутятся в k8s или Fargate - Вам важно сократить издержки на ресурсы и повысить безопасность Минимальный, безопасный, ограниченный и наблюдаемый контейнер — залог стабильности продакшна. @devopsitsec

🔧 DevOps Pro Tips: Оптимизация контейнеров как у SRE Google Контейнер — это не просто Dockerfile. Это микросистема, и если её не настраивать — она будет жечь CPU, RAM и SSD без пользы. Вот 🔥 продвинутые советы по настройке контейнеров: ⚫ Ограничь права контейнера

docker run --read-only --cap-drop=ALL --security-opt no-new-privileges ...

▪️ --read-only — защищает файловую систему ▪️ --cap-drop=ALL — удаляет лишние привилегии ▪️ no-new-privileges — запрещает повышение прав в процессе ⚫ Установи лимиты CPU и памяти

docker run --memory="512m" --cpus="1.5" ...

▪️ Не давай контейнеру жрать весь хост — особенно на multi-tenant нодах ▪️ Используй cpu-shares, cpuset, ulimits для тонкой настройки ⚫ Чисти от мусора - Используй multi-stage builds — минимизируй размер образа - Оставляй только необходимые бинарники и конфиги - Пример:

FROM golang:1.22 as builder
WORKDIR /app
COPY . .
RUN go build -o app

FROM alpine:3.19
COPY --from=builder /app/app /bin/app
ENTRYPOINT ["/bin/app"]

⚫ Используй distroless или Alpine - Образы типа gcr.io/distroless/static — без шелла, package manager и мусора - alpine — легче, но следи за совместимостью с glibc ⚫ Пропиши healthcheck

HEALTHCHECK --interval=30s --timeout=3s CMD curl -f http://localhost:8080/health || exit 1

▪️ Kubernetes будет перезапускать только при реальных сбоях ⚫ Подключи observability - Встраивай Prometheus exporter - Логи — в stdout/stderr (для kubectl logs и EFK/PLG стека) - Используй otel, если нужен tracing ⚫ Проверь, чем занят контейнер

docker top <container>
docker inspect --format '{{ .HostConfig }}' <container>

▪️ Вовремя заметишь, если процесс форкает что-то лишнее или идёт через /dev 💡 Эти практики критичны, если: - Вы деплоите в прод с autoscaling - Контейнеры крутятся в k8s или Fargate - Вам важно сократить издержки на ресурсы и повысить безопасность Минимальный, безопасный, ограниченный и наблюдаемый контейнер — залог стабильности продакшна.

Музыка, бег и летний драйв: что вас ждет на фестивале IT и спорта RUNIT: https://clck.ru/3M6upQ  🥁Хиты любимых групп. Фестиваль RUNIT пройдет 13 июля в Мещерском парке и соберет на одной площадке 10000 человек. Атмосферу драйва со сцены будут задавать «Отпетые мошенники», «Пропаганда», «Краски» и другие звезды. Имя хедлайнера пока в секрете. 🏃Зеленые трассы и классный мерч. Главное событие RUNIT — забег на 3, 5, 10 и 21 км, командный и личный зачет, эстафета и трассы для детей. Бежать будет комфортно — в парке мягкий грунт, много тени и красивые виды. На финише бегуны получат именные медали и футболки от бренда GRI. 🏸 Активности на любой вкус. Для гостей фестиваля будут работать несколько площадок: — спортивная: волейбол, бадминтон, йога, фитнес и т. д; — развлекательная: денди, дженга, мастер-классы и т. д; — фудкорт: еда на выбор и освежающие напитки. Регистрируйтесь на забег по ссылке https://clck.ru/3M6upQ и следите за новостями RUNIT 2025 в телеграм-канале.

🚀 VS Code трансформируется в опенсорнсый ИИ-редактор! Команда Visual Studio Code объявила о планах трансформировать VS Code в редактор с открытым исходным кодом для работы с ИИ. Конкуренция - двигатели прогресса! Где-то напряглась команда Cursor 🤓 🔗 Подробности: aka.ms/open-source-ai-editor #VSCode #OpenSource #ИИ #Разработка #Сообщество

🛠️ Отправка уведомлений Slack из shell-скриптов Автоматизация задач — это здорово, но ещё лучше — знать, когда они завершились или если что-то пошло не так. Slack — популярный мессенджер, поддерживающий ботов, которых можно настроить для автоматических оповещений о важных событиях. Сервер упал? Получите уведомление. Скрипт завершил выполнение? Получите уведомление. Добавив уведомления Slack в свои shell-скрипты, вы можете: - 📣 легко делиться результатами работы скриптов с командой, - 🛡️ быстро реагировать на проблемы, - 🔍 быть в курсе событий без просмотра логов. > Предполагается, что вы уже используете Slack и знакомы с понятием Slack Bot. Также необходимо базовое знание Bash. 🔗 Webhook + curl: секретная связка Slack позволяет использовать входящие Webhook-и для получения сообщений. А curl позволяет отправлять эти сообщения через HTTP POST. Принцип: - Slack даёт вам URL вида https://hooks.slack.com/services/... - Вы используете curl для отправки JSON с текстом сообщения. ⚙️ Как включить входящие Webhook в Slack 1. Зарегистрируйтесь на [api.slack.com/apps](https://api.slack.com/apps) 2. Создайте новое приложение 3. В разделе Incoming Webhooks — активируйте их 4. Добавьте Webhook в рабочее пространство (выберите канал) 5. Сохраните Webhook URL — он понадобится далее 💬 Bash-скрипт для отправки уведомлений Добавьте Webhook в .bashrc:

export SLACK_WEBHOOK_URL="https://hooks.slack.com/services/your/webhook/url"

Пример скрипта мониторинга:

#!/bin/bash

source ~/notify_slack.sh

disk_usage=$(df -h / | awk 'NR==2 {print $5}')
cpu_load=$(uptime | awk -F'load average:' '{ print $2 }' | cut -d',' -f1 | xargs)
hostname=$(hostname)

message="*Отчёт о системе - $hostname*\n* Диск (/): $disk_usage\n* CPU (1 мин): $cpu_load"
notify_slack "$message"

✅ Рекомендации Не хардкодьте токены — используйте переменные окружения Slack ограничивает частоту Webhook-запросов Используйте уведомления только при необходимости (ошибки, алерты и т.п.) Теперь вы можете: - Добавить Slack-уведомления в свои cron-задачи - Отслеживать состояние системы - Получать оповещения об ошибках в скриптах. Подробнее

Можно ли за 4 года стать хорошим фулстек-разработчиком с дипломом престижного вуза, готовым портфолио и сильной теоретической базой? В совместном онлайн-бакалавриате НИУ ВШЭ и Нетологии «Программные системы и автоматизация процессов разработки» готовят как раз таких специалистов. На первых курсах вы изучите базовые математические и гуманитарные предметы, основы программирования и профильные дисциплины по фулстек-разработке. А с третьего курса выберете углублённый трек: руководитель командой разработки или DevOps-инженер. По итогу обучения освоите 4 языка программирования: Java, Python, JavaScript, Go. Вас ждёт сильное студенческое комьюнити, постоянная практика, хакатоны и стажировки. А ещё — все бонусы очной формы обучения: отсрочка от армии, льготы на проезд, доступ к библиотеке, привилегии при посещении театров, льготный кредит на образование. Получите диплом, который поможет строить карьеру в сильных IT-командах. Подробнее Реклама. ООО "Нетология". ИНН 7726464125 Erid 2VSb5xYYjqJ

🌐 Задача-ловушка: Пропавший трафик после настройки iptables Условие: На сервере настроен простой iptables-фильтр для блокировки всего входящего трафика, кроме SSH:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

После применения этих правил вы проверяете, что SSH соединения работают нормально (локально и удалённо). Сервер отвечает на пинги, всё ок. На следующий день вы добавляете локальный контейнер (например, Docker), запускаете его с пробросом порта:

docker run -d -p 8080:80 nginx

❗ Проблема: Снаружи контейнер не доступен. В браузере или curl получаете Connection refused. Но в ss -tlnp порт 8080 виден и слушает. Дополнительно, если выполнить:

curl http://localhost:8080

— сервер отвечает нормально. Но с других машин — нет. ❓ Вопрос: Почему порт 8080 недоступен извне? В чём подвох с iptables? Как починить проблему? 🔍 Подсказка: Docker использует nat таблицы и PREROUTING`/`FORWARD цепочки для проброса портов. ✅ Разбор: 💥 Ловушка: Ваш iptables-правила:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

запрещают ВСЁ, кроме SSH. Вы думаете, что входящие соединения через Docker должны идти через INPUT, но это не так! Когда Docker пробрасывает порт с хоста (например, 8080), схема такая: - Входящий пакет попадает в цепочку PREROUTING (nat) - Потом через FORWARD, если пакет не адресован хосту напрямую, а перенаправлен внутрь контейнера И тут главная ловушка: даже если контейнер слушает порт на 0.0.0.0, Docker обрабатывает проброс трафика через FORWARD, а у вас политика по умолчанию:

iptables -P FORWARD DROP

Поэтому трафик до контейнера блокируется именно на этапе FORWARD. 🔧 Как проверить: Запустить:

iptables -L -v -n

Вы увидите, что счётчик пакетов в FORWARD показывает дропы. 🛠 Как починить: Добавить правило разрешения проброса пакетов для Docker:

iptables -A FORWARD -o docker0 -j ACCEPT

Или (более строго):

iptables -A FORWARD -i eth0 -o docker0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i docker0 -o eth0 -j ACCEPT

✅ Вывод: • В Linux iptables цепочки работают по строгой логике: - INPUT — для пакетов к хосту - FORWARD — для пакетов, которые переходят через хост (например, контейнеры или маршрутизаторы) • Даже если кажется, что контейнер слушает на 0.0.0.0, проброс портов Docker работает через FORWARD, а не напрямую через INPUT. 💡 Бонус-вопрос: Что изменится, если вы запустите контейнер с флагом --network=host? Какие цепочки будут задействованы тогда?

🦙 RamaLama — контейнерный подход к работе с AI-моделями. Этот инструмент переносит логику Docker/Podman в мир искусственного интеллекта, позволяя запускать LLM-модели как контейнеры с автоматической подгрузкой оптимизированных образов под ваше железо. Вместо ручной настройки зависимостей RamaLama сама определяет доступные GPU/CPU и разворачивает изолированную среду для инференса. Модели из HuggingFace, Ollama или OCI-регистров можно тестировать через REST API или чат-интерфейс, не опасаясь утечек данных — все запуски происходят без сети с удалением временных файлов. 🤖 GitHub @devopsitsec

Знание контейнеров: путь к большим деньгам в ИТ или временный хайп? 💰 19 мая (понедельник) в 18:00 присоединяйтесь к настоящему батлу мнений. В прямом эфире разработчики контейнерной платформы «Штурвал» вместе с AM Live соберут тех, кто знает индустрию изнутри. Топовые спикеры обсудят, действительно ли знание Docker и Kubernetes в приоритете нужных навыков или это проходящая мода, которая никак не влияет на успешный карьерный трек? Основные вопросы дискуссии: ▪️Насколько знания контейнеризации повышают конкурентоспособность и стоимость специалиста на рынке? ▪️Кто сейчас нужен больше — IT-специалист или IT generalist? ▪️Опыт работы с «ванильным» K8s VS с коммерческой платформой: есть ли разница? ▪️Что делать, если Kubernetes вообще не нравится? ▪️Площадки для обучения контейнеризации: норм или стрем? 🔜 Регистрация

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