Warning: mkdir(): No space left on device in /var/www/tg-me/post.php on line 37
Warning: file_put_contents(aCache/aDaily/post/DevOPSitsec/--): Failed to open stream: No such file or directory in /var/www/tg-me/post.php on line 50 DevOps | Telegram Webview: DevOPSitsec/1492 -
Условие: Ты получаешь баг-репорт: > "Приложение внутри 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 • Привычку **проверять всё снаружи**, а не только внутри контейнера
Подобные ошибки легко пропустить, особенно если всё проверяешь изнутри контейнера.
Условие: Ты получаешь баг-репорт: > "Приложение внутри 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 • Привычку **проверять всё снаружи**, а не только внутри контейнера
Подобные ошибки легко пропустить, особенно если всё проверяешь изнутри контейнера.
BY DevOps
Warning: Undefined variable $i in /var/www/tg-me/post.php on line 283
Among the actives, Ascendas REIT sank 0.64 percent, while CapitaLand Integrated Commercial Trust plummeted 1.42 percent, City Developments plunged 1.12 percent, Dairy Farm International tumbled 0.86 percent, DBS Group skidded 0.68 percent, Genting Singapore retreated 0.67 percent, Hongkong Land climbed 1.30 percent, Mapletree Commercial Trust lost 0.47 percent, Mapletree Logistics Trust tanked 0.95 percent, Oversea-Chinese Banking Corporation dropped 0.61 percent, SATS rose 0.24 percent, SembCorp Industries shed 0.54 percent, Singapore Airlines surrendered 0.79 percent, Singapore Exchange slid 0.30 percent, Singapore Press Holdings declined 1.03 percent, Singapore Technologies Engineering dipped 0.26 percent, SingTel advanced 0.81 percent, United Overseas Bank fell 0.39 percent, Wilmar International eased 0.24 percent, Yangzijiang Shipbuilding jumped 1.42 percent and Keppel Corp, Thai Beverage, CapitaLand and Comfort DelGro were unchanged.
Should You Buy Bitcoin?
In general, many financial experts support their clients’ desire to buy cryptocurrency, but they don’t recommend it unless clients express interest. “The biggest concern for us is if someone wants to invest in crypto and the investment they choose doesn’t do well, and then all of a sudden they can’t send their kids to college,” says Ian Harvey, a certified financial planner (CFP) in New York City. “Then it wasn’t worth the risk.” The speculative nature of cryptocurrency leads some planners to recommend it for clients’ “side” investments. “Some call it a Vegas account,” says Scott Hammel, a CFP in Dallas. “Let’s keep this away from our real long-term perspective, make sure it doesn’t become too large a portion of your portfolio.” In a very real sense, Bitcoin is like a single stock, and advisors wouldn’t recommend putting a sizable part of your portfolio into any one company. At most, planners suggest putting no more than 1% to 10% into Bitcoin if you’re passionate about it. “If it was one stock, you would never allocate any significant portion of your portfolio to it,” Hammel says.
