Вышла интерсная штука — padws!
Это бесконечная онлайн-доска с встроенным редактором кода и терминалом.
Поддерживает импорт объектов из VSCode и Cursor.
Посмотреть демо можно здесь, а селф-хост версию скачать на GitHub здесь.
https://github.com/pad-ws/pad.ws
#padws #coding #onlinewhiteboard #selfhost
Это бесконечная онлайн-доска с встроенным редактором кода и терминалом.
Поддерживает импорт объектов из VSCode и Cursor.
Посмотреть демо можно здесь, а селф-хост версию скачать на GitHub здесь.
https://github.com/pad-ws/pad.ws
#padws #coding #onlinewhiteboard #selfhost
⚙️ DevOps‑челлендж «Zero‑Downtime? Серьёзно?»
Вам выдали репозиторий ShopCat (SaaS‑платформа).
Он уже «работает» в Kubernetes‑кластере AWS EKS, собирается GitHub Actions и раскатывается Helm‑чартом.
Менеджеры уверяют, что *«релизы без простоя, всё по‑мажору»* — но пользователи получают 502 при каждом деплое.
Ваша миссия — найти и устранить скрытую причину даунтайма, не внося изменений в само приложение.
📂 Что есть в репо
⚠️ Подвох № 1 (скрытый таймер)
В
но только если кеш Docker‑слоёв инвалидирован (например, при обновлении base‑image).
⚠️ Подвох № 2 (невидимая «дырка» в rolling‑update)
В шаблоне Deployment:
*
*
* В итоге старый Pod уже не принимает новые запросы, но остаётся в EndpointSlice ещё ±60 секунд.
⚠️ Подвох № 3 («сам себе злобный Буратино»)
Helm‑values указывают образ
GitHub Actions пушит тэгированный
В production во время canary‑release может внезапно оказаться незамёрженый код Pull‑Request’а.
## 🏆 Задание
1. Настройте pipeline, чтобы:
* на каждый PR собирался
* на
2. Измените манифесты так, чтобы во время rolling‑update не было 502/504:
* никакого даунтайма, даже если контейнеру нужно 60 с на graceful‑shutdown;
* сетевой трафик должен _сначала_ уходить от старых Pod’ов, а _потом_ те выключаются.
3. Ограничьте blast‑radius: превратить
4. Найдите и исправьте «застревающий» шаг в Dockerfile, чтобы кэш всегда использовался, а билд не ждал интерактива.
5. ✅ Предоставьте:
* патчи (`.diff`) или PR в репозиторий,
* скриншот успешного
* краткое Post‑mortem (≤ 300 слов): *«Почему был даунтайм и какой фикс вы сделали»*.
## 💣 Неочевидные ограничения
* Нельзя менять исходный код приложения (только инфраструктура).
* Кластер prod имеет 2 ноды t3.medium (4 vCPU, 8 GiB) — бюджету больно от лишних replica‑set’ов.
* CI‑время — ≤ 5 мин на каждый PR.
* Все секреты — только через AWS Secrets Manager; в манифестах не должно быть
🔜 Решение
@DevOPSitsec
Вам выдали репозиторий ShopCat (SaaS‑платформа).
Он уже «работает» в Kubernetes‑кластере AWS EKS, собирается GitHub Actions и раскатывается Helm‑чартом.
Менеджеры уверяют, что *«релизы без простоя, всё по‑мажору»* — но пользователи получают 502 при каждом деплое.
Ваша миссия — найти и устранить скрытую причину даунтайма, не внося изменений в само приложение.
📂 Что есть в репо
.
├─ docker/
│ └─ Dockerfile # двухступенчатая сборка
├─ helm/
│ └─ shopcat/ # Chart.yaml + values.yaml + templates/*
├─ k8s/
│ ├─ namespace.yaml
│ └─ ingress.yaml # AWS ALB Ingress Controller
├─ .github/workflows/
│ └─ deploy.yml # CI → CD
└─ terraform/
├─ eks.tf
├─ rds.tf
└─ outputs.tf
⚠️ Подвох № 1 (скрытый таймер)
В
Dockerfile есть RUN adduser ... с интерактивным sudo‐prompt’ом, который «застревает», но только если кеш Docker‑слоёв инвалидирован (например, при обновлении base‑image).
⚠️ Подвох № 2 (невидимая «дырка» в rolling‑update)
В шаблоне Deployment:
livenessProbe:
httpGet:
path: /healthz
port: 8080
---
readinessProbe:
httpGet:
path: /healthz
port: 8080
*
/healthz возвращает 200 даже во время graceful‑shutdown (SIGTERM → 30 с drain). *
terminationGracePeriodSeconds = 60, а Ingress ALB считает Pod «живым», пока тот не закроется. * В итоге старый Pod уже не принимает новые запросы, но остаётся в EndpointSlice ещё ±60 секунд.
⚠️ Подвох № 3 («сам себе злобный Буратино»)
Helm‑values указывают образ
image: shopcat:latest. GitHub Actions пушит тэгированный
:vX.Y.Z, но тэг :latest перезаписывается той же джобой PR‑preview. В production во время canary‑release может внезапно оказаться незамёрженый код Pull‑Request’а.
## 🏆 Задание
1. Настройте pipeline, чтобы:
* на каждый PR собирался
shopcat:<sha> и катил preview‑релиз в namespace pr‑<num>, * на
main пушился shopcat:v<semver>, после чего Helm делал blue/green‑deploy в prod.2. Измените манифесты так, чтобы во время rolling‑update не было 502/504:
* никакого даунтайма, даже если контейнеру нужно 60 с на graceful‑shutdown;
* сетевой трафик должен _сначала_ уходить от старых Pod’ов, а _потом_ те выключаются.
3. Ограничьте blast‑radius: превратить
latest в «immutable image tag» и запретить Helm обновлять release, если image.tag уже был задеплоен (hint: .Chart.AppVersion + `helm.sh/hook`).4. Найдите и исправьте «застревающий» шаг в Dockerfile, чтобы кэш всегда использовался, а билд не ждал интерактива.
5. ✅ Предоставьте:
* патчи (`.diff`) или PR в репозиторий,
* скриншот успешного
kubectl rollout status deployment/shopcat ‑‑watch,* краткое Post‑mortem (≤ 300 слов): *«Почему был даунтайм и какой фикс вы сделали»*.
## 💣 Неочевидные ограничения
* Нельзя менять исходный код приложения (только инфраструктура).
* Кластер prod имеет 2 ноды t3.medium (4 vCPU, 8 GiB) — бюджету больно от лишних replica‑set’ов.
* CI‑время — ≤ 5 мин на каждый PR.
* Все секреты — только через AWS Secrets Manager; в манифестах не должно быть
plaintext.@DevOPSitsec
Please open Telegram to view this post
VIEW IN TELEGRAM
👾 eBPF вместо прокси: новый подход к масштабированию в Kubernetes.
Инженеры WSO2 предложили нестандартное решение для scale-to-zero в Kubernetes — отказ от прокси в пользу eBPF. Они создали прототип, где eBPF-программа на уровне XDP перехватывает пакеты, инициируя масштабирование сервисов без промежуточного слоя.
🧑💻 Как это работает?
— eBPF-драйвер отслеживает запросы к остановленным сервисам, временно блокируя их и запуская масштабирование
— После готовности POD запрос проходит напрямую, минуя прокси
— Подход работает для любых TCP-сервисов, включая базы данных
Преимущества:
— Работает для любых TCP-сервисов (не только HTTP)
— Снижение latency на 30-50% по сравнению с прокси-решениями
— Полная совместимость с существующими сетевыми политиками
— Поддержка даже stateful-сервисов вроде PostgreSQL
🔗 Ссылка - *клик*
@devopsitsec
Инженеры WSO2 предложили нестандартное решение для scale-to-zero в Kubernetes — отказ от прокси в пользу eBPF. Они создали прототип, где eBPF-программа на уровне XDP перехватывает пакеты, инициируя масштабирование сервисов без промежуточного слоя.
🧑💻 Как это работает?
— eBPF-драйвер отслеживает запросы к остановленным сервисам, временно блокируя их и запуская масштабирование
— После готовности POD запрос проходит напрямую, минуя прокси
— Подход работает для любых TCP-сервисов, включая базы данных
Преимущества:
— Работает для любых TCP-сервисов (не только HTTP)
— Снижение latency на 30-50% по сравнению с прокси-решениями
— Полная совместимость с существующими сетевыми политиками
— Поддержка даже stateful-сервисов вроде PostgreSQL
🔗 Ссылка - *клик*
@devopsitsec
🏗️ Гайд: Эффективная оркестрация контейнеров с Docker в продакшн-среде
Ниже — подробное руководство для продвинутых пользователей, с примерами из реальной практики, кодом и комментариями.
1️⃣ Выбор инструмента оркестрации
Docker предоставляет базовые возможности, но для продакшн-оркестрации требуется полноценный движок:
✅ Docker Swarm — встроенный, подходит для малых и средних проектов
✅ Kubernetes (K8s) — промышленный стандарт, подходит для масштабных систем
✅ Nomad (от HashiCorp) — легковесная альтернатива
👉 Для быстрого старта используй Swarm, для больших систем — Kubernetes.
2️⃣ Архитектура кластера
Рекомендуемый минимум:
• 3 manager-ноды (quorum, HA)
• 2+ worker-ноды
• overlay-сеть
• load balancer (например nginx, HAProxy)
• private registry (Harbor, GitLab Registry)
Инициализация кластера:
Создание overlay-сети:
---
3️⃣ Развёртывание сервисов
Пример
Запуск:
---
4️⃣ Zero-Downtime Updates
Добавь healthcheck в Dockerfile:
В
---
5️⃣ Резервное копирование
Полезные команды:
Бэкап Raft:
6️⃣ Мониторинг и логирование
✅ Prometheus + Grafana — метрики
✅ ELK Stack / Loki — логи
Пример запуска cAdvisor:
7️⃣ Безопасность
• Запуск от непривилегированного пользователя:
• Read-only root filesystem:
• Ограничение capability:
• Сканирование образов (Trivy):
• Не использовать
8️⃣ Оптимизация Dockerfile
✅ multi-stage build
✅ минимизируй слои
✅ данные — во внешние volume
Пример multi-stage:
9️⃣ Управление секретами
Создание секрета:
Использование в
В контейнере доступно как
🔟 CI/CD
Пример пайплайна (GitLab):
🎯 Заключение
Эффективная оркестрация =
✅ грамотная архитектура
✅ rolling updates + healthchecks
✅ безопасность (secrets, cap_drop, read_only)
✅ мониторинг и логирование
✅ CI/CD интеграция
✅ регулярный бэкап
👉 Swarm = быстрый старт, Kubernetes = масштабирование.
Ниже — подробное руководство для продвинутых пользователей, с примерами из реальной практики, кодом и комментариями.
1️⃣ Выбор инструмента оркестрации
Docker предоставляет базовые возможности, но для продакшн-оркестрации требуется полноценный движок:
✅ Docker Swarm — встроенный, подходит для малых и средних проектов
✅ Kubernetes (K8s) — промышленный стандарт, подходит для масштабных систем
✅ Nomad (от HashiCorp) — легковесная альтернатива
👉 Для быстрого старта используй Swarm, для больших систем — Kubernetes.
2️⃣ Архитектура кластера
Рекомендуемый минимум:
• 3 manager-ноды (quorum, HA)
• 2+ worker-ноды
• overlay-сеть
• load balancer (например nginx, HAProxy)
• private registry (Harbor, GitLab Registry)
Инициализация кластера:
docker swarm init --advertise-addr MANAGER_IP
docker swarm join --token <join-token> MANAGER_IP:2377
Создание overlay-сети:
docker network create --driver overlay --attachable my-overlay
---
3️⃣ Развёртывание сервисов
Пример
docker-compose.yml (версии 3 для Swarm):
version: '3.9'
services:
web:
image: mycompany/webapp:latest
replicas: 5
deploy:
update_config:
parallelism: 2
delay: 10s
restart_policy:
condition: on-failure
networks:
- frontend
ports:
- "80:80"
networks:
frontend:
driver: overlay
Запуск:
docker stack deploy -c docker-compose.yml mystack
---
4️⃣ Zero-Downtime Updates
Добавь healthcheck в Dockerfile:
HEALTHCHECK --interval=30s --timeout=10s \
CMD curl -f http://localhost/health || exit 1
В
docker-compose.yml уже используется update_config → обновления происходят без даунтайма (по 2 контейнера каждые 10s, с проверкой healthcheck).---
5️⃣ Резервное копирование
Полезные команды:
docker swarm unlock-key
docker swarm join-token manager
docker node ls
Бэкап Raft:
docker container stop $(docker container ls -q --filter name=swarm)
cp -r /var/lib/docker/swarm ~/swarm-backup
6️⃣ Мониторинг и логирование
✅ Prometheus + Grafana — метрики
✅ ELK Stack / Loki — логи
Пример запуска cAdvisor:
docker run -d \
-p 9323:9323 \
--name cadvisor \
--volume=/:/rootfs:ro \
--volume=/var/run:/var/run:ro \
--volume=/sys:/sys:ro \
--volume=/var/lib/docker/:/var/lib/docker:ro \
google/cadvisor:latest
7️⃣ Безопасность
• Запуск от непривилегированного пользователя:
USER appuser
• Read-only root filesystem:
deploy:
read_only: true
• Ограничение capability:
deploy:
cap_drop:
- ALL
• Сканирование образов (Trivy):
trivy image mycompany/webapp:latest
• Не использовать
latest тег:
image: mycompany/webapp:1.3.2
8️⃣ Оптимизация Dockerfile
✅ multi-stage build
✅ минимизируй слои
✅ данные — во внешние volume
Пример multi-stage:
FROM node:18 AS build
WORKDIR /app
COPY . .
RUN npm install && npm run build
FROM nginx:alpine
COPY --from=build /app/build /usr/share/nginx/html
9️⃣ Управление секретами
Создание секрета:
echo "my-secret-value" | docker secret create db_password -
Использование в
docker-compose.yml:
secrets:
- db_password
В контейнере доступно как
/run/secrets/db_password.🔟 CI/CD
Пример пайплайна (GitLab):
stages:
- build
- deploy
build:
stage: build
script:
- docker build -t registry.example.com/myapp:$CI_COMMIT_SHA .
- docker push registry.example.com/myapp:$CI_COMMIT_SHA
deploy:
stage: deploy
script:
- docker service update --image registry.example.com/myapp:$CI_COMMIT_SHA mystack_web
🎯 Заключение
Эффективная оркестрация =
✅ грамотная архитектура
✅ rolling updates + healthchecks
✅ безопасность (secrets, cap_drop, read_only)
✅ мониторинг и логирование
✅ CI/CD интеграция
✅ регулярный бэкап
👉 Swarm = быстрый старт, Kubernetes = масштабирование.
@devopsitsec
Please open Telegram to view this post
VIEW IN TELEGRAM
🐳 Как устроен Docker: что происходит «под капотом»
Поговорим немного про базу.
Docker — одно из самых популярных средств контейнеризации. Его простота снаружи скрывает сложную архитектуру. Разберём, как он устроен внутри.
1) Что такое контейнер?
Контейнер — изолированная среда, где запускается приложение со всеми зависимостями.
⚠️ Это не виртуальная машина: контейнер делит ядро ОС с хостом, но видит только свою «песочницу» через изоляцию.
2) Основные компоненты
• Docker Engine
– Docker Daemon (`dockerd`) управляет контейнерами, образами, сетями
– Docker CLI (`docker`) — интерфейс пользователя
– REST API — взаимодействие CLI и Daemon
👉 Пример:
3) Namespaces
Механизм изоляции в Linux, создающий для контейнера:
• свой процессный ID (pid namespace)
• файловую систему (mnt namespace)
• сеть (net namespace)
• hostname (uts namespace)
• IPC (ipc namespace)
👉 Благодаря namespace контейнер видит «свою» мини-ОС, хотя на деле — это лишь виртуальные границы.
4) Cgroups
Ограничивают и учитывают ресурсы (CPU, RAM, I/O, сеть).
Пример: можно задать лимит 512 МБ RAM и 0.5 CPU.
Если приложение превышает лимит — Docker его ограничит или остановит.
5) Union File Systems (OverlayFS)
Docker использует многослойную файловую систему. Каждый шаг
При запуске контейнера создаётся верхний writable-слой, остальные read-only.
👉 10 контейнеров на одном образе разделяют слои → экономия места.
6) Container Runtime
Docker использует
Daemon вызывает
7) Docker Images
Образ — read-only слои, собранные в Union FS.
Каждый слой — изменения относительно предыдущего (например, установка пакета → новый слой).
Хранение: локально (`/var/lib/docker`) или в реестре (Docker Hub, GitLab Container Registry).
8) Docker Networking
Docker создаёт виртуальные сети (bridge, overlay, host).
По умолчанию контейнеры подключаются к bridge и получают IP из внутреннего пула.
👉 Можно пробросить порты через
В Swarm используется Overlay network (сеть между хостами).
9) Безопасность
Docker использует:
• seccomp (ограничение системных вызовов)
• AppArmor / SELinux (контроль привилегий)
• user namespaces (отображение UID контейнера в другой UID хоста)
⚠️ По умолчанию контейнеры имеют широкий доступ (например,
10) Что происходит при `docker run nginx`?
1. CLI отправляет запрос через API
2. Daemon ищет образ (локально или в registry)
3. Создаётся read-write слой контейнера
4. Создаются namespace (pid, net, mnt…)
5. Применяются cgroups
6. Вызывается
7. Контейнер подключается к сети
8. Запускается ENTRYPOINT/command
Контейнер живёт, пока жив его процесс.
11) Почему Docker — не магия?
Docker использует стандартные возможности ядра Linux (namespaces, cgroups, chroot, seccomp, overlayfs), оборачивая их в удобный интерфейс.
Контейнер — просто изолированный процесс, а не полноценная VM.
Поэтому Docker лёгкий, быстрый, удобный.
12) Заключение
Под капотом Docker:
• namespaces — изоляция
• cgroups — контроль ресурсов
• runc — запуск
• overlayfs — многослойная ФС
• REST API + Daemon + CLI — взаимодействие
Docker скрывает сложность, давая простой инструмент для запуска, сборки, развёртывания приложений.
Теперь, зная внутреннее устройство, можно глубже понять контейнеры, лучше их настраивать и оптимизировать.
➡️ Подробнее
@DevopsDocker
Поговорим немного про базу.
Docker — одно из самых популярных средств контейнеризации. Его простота снаружи скрывает сложную архитектуру. Разберём, как он устроен внутри.
1) Что такое контейнер?
Контейнер — изолированная среда, где запускается приложение со всеми зависимостями.
⚠️ Это не виртуальная машина: контейнер делит ядро ОС с хостом, но видит только свою «песочницу» через изоляцию.
2) Основные компоненты
• Docker Engine
– Docker Daemon (`dockerd`) управляет контейнерами, образами, сетями
– Docker CLI (`docker`) — интерфейс пользователя
– REST API — взаимодействие CLI и Daemon
👉 Пример:
docker run nginx → CLI отправляет запрос, Daemon находит образ, создаёт контейнер, запускает процесс.3) Namespaces
Механизм изоляции в Linux, создающий для контейнера:
• свой процессный ID (pid namespace)
• файловую систему (mnt namespace)
• сеть (net namespace)
• hostname (uts namespace)
• IPC (ipc namespace)
👉 Благодаря namespace контейнер видит «свою» мини-ОС, хотя на деле — это лишь виртуальные границы.
4) Cgroups
Ограничивают и учитывают ресурсы (CPU, RAM, I/O, сеть).
Пример: можно задать лимит 512 МБ RAM и 0.5 CPU.
Если приложение превышает лимит — Docker его ограничит или остановит.
5) Union File Systems (OverlayFS)
Docker использует многослойную файловую систему. Каждый шаг
Dockerfile создаёт новый слой. При запуске контейнера создаётся верхний writable-слой, остальные read-only.
👉 10 контейнеров на одном образе разделяют слои → экономия места.
6) Container Runtime
Docker использует
runc для запуска контейнера (соответствует OCI Runtime Spec). Daemon вызывает
runc, который через clone(), setns(), chroot() изолирует процесс.7) Docker Images
Образ — read-only слои, собранные в Union FS.
Каждый слой — изменения относительно предыдущего (например, установка пакета → новый слой).
Хранение: локально (`/var/lib/docker`) или в реестре (Docker Hub, GitLab Container Registry).
8) Docker Networking
Docker создаёт виртуальные сети (bridge, overlay, host).
По умолчанию контейнеры подключаются к bridge и получают IP из внутреннего пула.
👉 Можно пробросить порты через
-p, создать собственные сети, объединять контейнеры через docker network connect.В Swarm используется Overlay network (сеть между хостами).
9) Безопасность
Docker использует:
• seccomp (ограничение системных вызовов)
• AppArmor / SELinux (контроль привилегий)
• user namespaces (отображение UID контейнера в другой UID хоста)
⚠️ По умолчанию контейнеры имеют широкий доступ (например,
/proc виден). Для production стоит ограничивать права (например, `--cap-drop`).10) Что происходит при `docker run nginx`?
1. CLI отправляет запрос через API
2. Daemon ищет образ (локально или в registry)
3. Создаётся read-write слой контейнера
4. Создаются namespace (pid, net, mnt…)
5. Применяются cgroups
6. Вызывается
runc для изоляции процесса7. Контейнер подключается к сети
8. Запускается ENTRYPOINT/command
Контейнер живёт, пока жив его процесс.
11) Почему Docker — не магия?
Docker использует стандартные возможности ядра Linux (namespaces, cgroups, chroot, seccomp, overlayfs), оборачивая их в удобный интерфейс.
Контейнер — просто изолированный процесс, а не полноценная VM.
Поэтому Docker лёгкий, быстрый, удобный.
12) Заключение
Под капотом Docker:
• namespaces — изоляция
• cgroups — контроль ресурсов
• runc — запуск
• overlayfs — многослойная ФС
• REST API + Daemon + CLI — взаимодействие
Docker скрывает сложность, давая простой инструмент для запуска, сборки, развёртывания приложений.
Теперь, зная внутреннее устройство, можно глубже понять контейнеры, лучше их настраивать и оптимизировать.
@DevopsDocker
Please open Telegram to view this post
VIEW IN TELEGRAM
@devopsitsec
Please open Telegram to view this post
VIEW IN TELEGRAM
🗺 Google maps scraper
Это Golang парсер, на основе фреймворка scrapemate который позволяет удобно парсить данные из Google Maps.
Он автоматизирует просмотр веб-страниц и позволяет извлекать: имя, адрес, номер телефона, URL-адрес веб-сайта, рейтинг и количество отзывов для каждого выбранного вами места.
Все данные сохраняются в файл CSV для удобства анализа и обработки.
Содержит код для быстрого запуска с использованием Docker.
▪Github
@devopsitsec
Это Golang парсер, на основе фреймворка scrapemate который позволяет удобно парсить данные из Google Maps.
Он автоматизирует просмотр веб-страниц и позволяет извлекать: имя, адрес, номер телефона, URL-адрес веб-сайта, рейтинг и количество отзывов для каждого выбранного вами места.
Все данные сохраняются в файл CSV для удобства анализа и обработки.
Содержит код для быстрого запуска с использованием Docker.
▪Github
@devopsitsec
Media is too big
VIEW IN TELEGRAM
🔥 Ошибка Therac-25: когда код убивает
▪ В 1980-х Therac-25 считался чудом медицины: новый линейный ускоритель для лечения рака с точной дозировкой радиации. Разработчики гордились: теперь всё управляет программное обеспечение — минимум ручной работы и максимум безопасности… казалось бы.
Но вскоре пациенты начали получать смертельные дозы радиации. Люди приходили на лечение и получали 100-кратное превышение нормы буквально за секунды. Некоторые умирали мгновенно, другие — спустя несколько недель.
Что же случилось? 👇
▪ Гонка потоков (race condition) — незаметный баг в коде. Если техник слишком быстро переключал режимы лечения, программа не успевала правильно активировать защиту. Результат: машина включала мощнейший луч без блокировки и буквально сжигала пациентов.
Разработчики уверяли, что код «идеален» и проблема не в них. Только после нескольких трагедий независимые эксперты нашли источник: баг проявлялся лишь при экстремально быстром вводе комбинаций клавиш — ситуация, которую никто даже не тестировал.
💥 Итог: Therac-25 стал примером того, что даже одна строка кода может убить, если игнорировать тестирование edge-case сценариев. Этот случай навсегда изменил стандарты разработки критически важных систем, введя новые международные нормы безопасности.
👉 Урок:
Никогда не верь, что твой код «без ошибок». Особенно когда от него зависят жизни.
#код #баги #историиИТ #therac25 #разработка #тестирование #fail
▪ В 1980-х Therac-25 считался чудом медицины: новый линейный ускоритель для лечения рака с точной дозировкой радиации. Разработчики гордились: теперь всё управляет программное обеспечение — минимум ручной работы и максимум безопасности… казалось бы.
Но вскоре пациенты начали получать смертельные дозы радиации. Люди приходили на лечение и получали 100-кратное превышение нормы буквально за секунды. Некоторые умирали мгновенно, другие — спустя несколько недель.
Что же случилось? 👇
▪ Гонка потоков (race condition) — незаметный баг в коде. Если техник слишком быстро переключал режимы лечения, программа не успевала правильно активировать защиту. Результат: машина включала мощнейший луч без блокировки и буквально сжигала пациентов.
Разработчики уверяли, что код «идеален» и проблема не в них. Только после нескольких трагедий независимые эксперты нашли источник: баг проявлялся лишь при экстремально быстром вводе комбинаций клавиш — ситуация, которую никто даже не тестировал.
💥 Итог: Therac-25 стал примером того, что даже одна строка кода может убить, если игнорировать тестирование edge-case сценариев. Этот случай навсегда изменил стандарты разработки критически важных систем, введя новые международные нормы безопасности.
👉 Урок:
Никогда не верь, что твой код «без ошибок». Особенно когда от него зависят жизни.
#код #баги #историиИТ #therac25 #разработка #тестирование #fail
🐧 Задача с подвохом: Странное поведение с `df` и `du`
Условие:
Вы замечаете, что на сервере
И видите, что диск почти полностью заполнен. Но при этом, когда проверяете размер файлов в
— оказывается, что размер логов совсем небольшой, явно не соответствующий тому, что показывает
❓ Вопрос:
Почему возникает такая ситуация? Что именно занимает место, если файлы почти пустые? Как это исправить, не перезагружая сервер?
🔍 Подсказка:
На сервере активно работают несколько приложений, которые записывают логи. Недавно был произведён
---
✅ Разбор:
💥 Подвох:
Многие думают, что после удаления файла место сразу освобождается. Но в Linux есть важный нюанс: если процесс всё ещё держит файл открытым, даже после удаления файла из файловой системы, его содержимое продолжает занимать место на диске.
Вот что происходит:
- показывает размер существующих файлов, поэтому он маленький (ведь файлы удалены).
- показывает реальное использование блочного устройства, и оно включает те данные, которые всё ещё заняты удалёнными, но открытыми файлами.
🚩 Это классическая ситуация после : старые логи удаляются, но процессы, которые их писали (например, , `mysql`), продолжают держать дескрипторы открытыми.
🔧 Как найти виновника:
Используем для поиска удалённых, но ещё открытых файлов:
```bash
lsof | grep deleted
```
Вы увидите что-то вроде:
```
nginx 1234 ... /var/log/nginx/access.log (deleted)
```
🛠 Как исправить без перезагрузки:
1️⃣ Перезапустить приложение, которое держит файл открытым:
```bash
systemctl restart nginx
```
2️⃣ Если нельзя перезапустить, можно попробовать «сбросить» файл, подменив его на новый (подходит не всегда).
---
✅ Вывод:
• и показывают разное, потому что считают разными методами:
- : что реально занято на диске (включая удалённые, но ещё открытые файлы)
- : что физически доступно через файловую систему
• Если место не освобождается после удаления файла — ищите открытые файловые дескрипторы удалённых файлов. Это классика для DevOps!
💡 Бонус-вопрос для гуру:
Что произойдёт, если в вы видите удалённый файл, но процесс — это ? Как поступить в этом случае? 😉
Условие:
Вы замечаете, что на сервере
/var/log неожиданно «занялось» много места. Проверяете это так:
df -h /var
И видите, что диск почти полностью заполнен. Но при этом, когда проверяете размер файлов в
/var/log:
du -sh /var/log
— оказывается, что размер логов совсем небольшой, явно не соответствующий тому, что показывает
df.❓ Вопрос:
Почему возникает такая ситуация? Что именно занимает место, если файлы почти пустые? Как это исправить, не перезагружая сервер?
🔍 Подсказка:
На сервере активно работают несколько приложений, которые записывают логи. Недавно был произведён
logrotate, старые логи удалились.---
✅ Разбор:
💥 Подвох:
Многие думают, что после удаления файла место сразу освобождается. Но в Linux есть важный нюанс: если процесс всё ещё держит файл открытым, даже после удаления файла из файловой системы, его содержимое продолжает занимать место на диске.
Вот что происходит:
-
du-
df🚩 Это классическая ситуация после
logrotatenginx🔧 Как найти виновника:
Используем
lsof```bash
lsof | grep deleted
```
Вы увидите что-то вроде:
```
nginx 1234 ... /var/log/nginx/access.log (deleted)
```
🛠 Как исправить без перезагрузки:
1️⃣ Перезапустить приложение, которое держит файл открытым:
```bash
systemctl restart nginx
```
2️⃣ Если нельзя перезапустить, можно попробовать «сбросить» файл, подменив его на новый (подходит не всегда).
---
✅ Вывод:
•
dfdu-
df-
du• Если место не освобождается после удаления файла — ищите открытые файловые дескрипторы удалённых файлов. Это классика для DevOps!
💡 Бонус-вопрос для гуру:
Что произойдёт, если в
lsofdockerCI/CD без боли: оптимизация пайплайнов на GitHub Actions 🚀
GitHub Actions — мощный инструмент, но без оптимизации ваш пайплайн легко превратится в тормозную мясорубку. Разбираемся, как выжать максимум из CI/CD на GitHub.
Почему это важно:
Быстрые и надёжные пайплайны — ключ к высокой скорости доставки. Медленные сборки = потеря времени, нервов и денег.
1. Кэшируй разумно
Используй
⚠️ Ключ должен быть завязан на lock-файлы, иначе можно словить конфликты версий.
2. Делай job-ы параллельными
Разделяй пайплайн на независимые шаги — unit-тесты, линтеры, сборка. Добавляй
3. Matrix strategy — must-have
Хочешь тестировать на разных версиях языка/ОС? Используй
Это масштабирует проверку без дублирования кода.
4. Отключи ненужные события
Не запускай воркфлоу на каждом чихе. Используй
Это поможет не перегружать runners.
5. Используй
Иногда надо протестить пайплайн руками — не бойся добавить ручной триггер:
6. Логи и таймауты — твои друзья
Добавляй
Вывод:
Грамотно настроенный GitHub Actions экономит время и снижает головную боль. Избегай монолитных пайплайнов, кэшируй умно и тестируй только то, что нужно. Автоматизация — это про контроль, а не хаос.
#devops #девопс
GitHub Actions — мощный инструмент, но без оптимизации ваш пайплайн легко превратится в тормозную мясорубку. Разбираемся, как выжать максимум из CI/CD на GitHub.
Почему это важно:
Быстрые и надёжные пайплайны — ключ к высокой скорости доставки. Медленные сборки = потеря времени, нервов и денег.
1. Кэшируй разумно
Используй
actions/cache для ускорения зависимостей, но не кэшируй всё подряд. Пример для Node.js:
- uses: actions/cache@v4
with:
path: ~/.npm
key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-node-
⚠️ Ключ должен быть завязан на lock-файлы, иначе можно словить конфликты версий.
2. Делай job-ы параллельными
Разделяй пайплайн на независимые шаги — unit-тесты, линтеры, сборка. Добавляй
needs: там, где реально нужно, а не везде.3. Matrix strategy — must-have
Хочешь тестировать на разных версиях языка/ОС? Используй
matrix:
strategy:
matrix:
node-version: [16, 18, 20]
Это масштабирует проверку без дублирования кода.
4. Отключи ненужные события
Не запускай воркфлоу на каждом чихе. Используй
on: грамотно:
on:
push:
branches:
- main
pull_request:
paths:
- 'src/**'
Это поможет не перегружать runners.
5. Используй
workflow_dispatch для ручных запусков Иногда надо протестить пайплайн руками — не бойся добавить ручной триггер:
on:
workflow_dispatch:
6. Логи и таймауты — твои друзья
Добавляй
timeout-minutes к job-ам и выводи ключевые логи через ::group:: и ::endgroup::, чтобы не утонуть в консоли.Вывод:
Грамотно настроенный GitHub Actions экономит время и снижает головную боль. Избегай монолитных пайплайнов, кэшируй умно и тестируй только то, что нужно. Автоматизация — это про контроль, а не хаос.
#devops #девопс
Forwarded from Machinelearning
Media is too big
VIEW IN TELEGRAM
Y Combinator сделал ставку на ИИ-агентов, способных переосмыслить целые индустрии. Вместо точечных решений, основателям советуют создавать «полноценные ИИ-компании» - например, запускать собственные юридические бюро с ИИ-юристами вместо сотрудников. Такой подход позволяет обойти медлительных конкурентов, предлагая клиентам более дешевые и эффективные сервисы.
Особый интерес к автоматизации рутины: персональные ассистенты, которые не просто напоминают о задачах, а самостоятельно отвечают на письма, планируют встречи и имитируют стиль общения пользователя. Y Combinator верит: будущее за командами, которые не просто внедряют ИИ, а перестраивают рынки с нуля, как это сделали Airbnb или Stripe.
ycombinator.com
Ученые из Центра геномной регуляции в Барселоне впервые применили генеративный ИИ для проектирования синтетических молекул ДНК, способных управлять активностью генов в здоровых клетках млекопитающих. Модель, обученная на данных тысяч экспериментов, генерирует последовательности «с нуля», задавая критерии.
В качестве теста создали фрагменты ДНК, активирующие ген флуоресцентного белка в клетках крови мышей. Результаты совпали с прогнозами: синтетические усилители генной активности работали как «переключатели» в зависимости от типа клеток. Исследование открывает путь к персонализированным методам коррекции генов. По словам авторов, это похоже на «написание софта для биологии», где каждая инструкция для клетки становится программируемой.
technologynetworks.com
OpenAI представила HealthBench - бенчмарк для тестирования ИИ-систем в сфере здравоохранения. Разработанный при участии 262 врачей из 60 стран, он включает 5000 реалистичных диалогов, имитирующих общение пациентов и медиков. Каждый сценарий оценивается по индивидуальным критериям, созданным экспертами: точность данных или ясность ответов.
Всего в бенчмарке 48 562 параметра оценки, что позволяет глубоко анализировать работу моделей. Особый упор сделан на надежность: даже один ошибочный ответ в медицине критичен. HealthBench включает подборки сложных кейсов (HealthBench Hard), где современные ИИ еще отстают. Все данные и методики уже доступны в GitHub-репозитории OpenAI .
openai.com
Google анонсировала AI Futures Fund — программу для поддержки ИИ-стартапов. Участники получат ранний доступ к моделям DeepMind (Gemini, Imagen и Veo). Кроме технологий, стартапы смогут консультироваться с инженерами и исследователями Google, а также получат облачные кредиты для обучения и масштабирования решений. Уже сейчас с фондом работают проекты из разных сфер: индийский Toonsutra внедряет Gemini для перевода комиксов, Viggle экспериментирует с генерацией мемов, а платформа Rooms тестирует интерактивные 3D-пространства.
Программа открыта для стартапов из регионов, где доступен Gemini. Подать заявку можно на сайте фонда. Участники смогут претендовать не только на технические ресурсы, но и на прямые инвестиции от Google.
blog.google
Злоумышленники активно используют популяризацию ИИ для распространения вредоносного стиллера Noodlophile, маскируя атаки под сервисы для генерации видео и изображений. Как сообщает Morphisec, фейковые страницы Luma Dreammachine Al и CapCut AI рекламируются через соцсети, собирая до 62 000 просмотров на пост. Пользователям предлагают скачать «ИИ-софт», но вместо этого загружается ZIP-архив с исполняемым exe-файлом.
Запуск файла активирует легитимный CapCut.exe, который загружает .NET-лоадер CapCutLoader. Тот, в свою очередь, запускает Python-скрипт, устанавливающий Noodlophile Stealer. Вредонос крадет пароли, данные кошельков и другую информацию, а в некоторых случаях дополняется трояном XWorm для удаленного доступа. Эксперты напоминают: атаки через ИИ-технологии стали трендом. Осторожность — лучшая защита.
thehackernews.com
@ai_machinelearning_big_data
#news #ai #ml
Please open Telegram to view this post
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
📜 История SQL — от лабораторной идеи до «языка данных» № 1
Как появился самый известный язык работы с базами, почему он едва не остался «Сиквелом» и какие любопытные факты о нём редко всплывают в учебниках.
1. Всё началось с таблицы на бумаге
- 1970 г. — британский математик Эдгар Ф. Кодд публикует культовую статью *“A Relational Model of Data for Large Shared Data Banks”*.
- В ней впервые прозвучала идея: хранить данные в виде связанных таблиц, а не как запутанные иерархии (IMS) или сетевые графы (Codasyl).
- Коллеги в IBM скептически называли это «бумагой на буквы», но разрешили сделать прототип, чтобы проверить утопию Кодда на практике.
2. SEQUEL — «английский» запрос к таблицам
- 1973–1974 гг. — в лаборатории IBM San José (ныне Almaden) двое молодых исследователей, Дональд Чемберлин и Рэймонд Бойс, берутся за проект System R.
- Чтобы обращаться к реляционным таблицам, они придумывают Structured English QUEry Language — SEQUEL.
- Ключевая фишка — запросы выглядят почти как английские предложения:
- В 1974‑м публикуют первую спецификацию; академики критикуют за «слишком поверхностный английский», но программисты в восторге.
3. Почему SEQUEL стал SQL
- Торговая марка “SEQUEL” уже принадлежала авиастроительной компании *Hawker Siddeley*.
- IBM, опасаясь суда, в 1976 г. официально отказывается от «E» и оставляет SQL (Structured Query Language).
- *Небольшая путаница осталась навсегда: кто‑то произносит «эс‑кью‑эл», кто‑то — «сиквел».*
4. Коммерческий взлёт
- 1978 | Первая демонстрация System R внутри IBM | показала, что SQL работает быстрее ожиданий |
- 1979 | Стартап Relational Software (позже Oracle**) выпускает **Oracle V2 — первый коммерческий SQL‑движок | IBM ещё не успела выйти на рынок
- 1981 | IBM выпускает SQL/DS для мейнфреймов | стандарт де‑факто закрепляется
- 1983 | Дебют DB2 — теперь SQL есть почти в каждом крупном банке
5. Стандартизация и эволюция
- ANSI SQL‑86 → SQL‑92 (появился `JOIN ... ON`) → SQL:1999 (рекурсия, триггеры) → SQL:2003 (XML) → … → SQL:2023 (JSON, property graphs).
- Каждые 3–5 лет комитет добавляет «модные» возможности, но 90 % повседневных запросов всё ещё укладываются в синтаксис 1980‑х.
6. Забавные факты, которые украсят small talk 🍸
1. NULL ≠ 0 и NULL ≠ NULL — «неизвестное значение» нарушает законы логики, за что его зовут *“пятой ногой”* реляционной алгебры.
2. `SELECT *` — наследие печати на станке. Звёздочка означала «все колонки», чтобы не писать их руками в 132‑символьных перфокартах.
3. Команда `GO` в MS SQL Server не принадлежит стандарту SQL — это директива из старого клиента isql.
4. В Oracle долго не было `LIMIT`, а в MySQL — `RIGHT JOIN`. Поэтому админы шутили: «истинный межплатформенный SQL — это `SELECT 1;`».
5. Первый SQL‑вирус — червь *Slammer* (2003) — парализовал интернет за 10 минут через уязвимость в SQL Server 2000.
6. SQL — декларативный язык, но внутри СУБД каждый
7. `DROP DATABASE` придумали позже, чем `CREATE`. Сначала удалять целую БД казалось слишком опасным.
7. Почему SQL живёт дольше модных NoSQL‑наследников
- Математическая база. Таблицы + операции Кодда образуют алгебру с предсказуемой оптимизацией.
- Стандарты и переносимость. Код двадцатилетней давности можно запустить в современной Postgres или MariaDB.
- Большая экосистема. От Excel‑плагинов до BigQuery — везде так или иначе поддерживается SQL‑диалект.
- Сопротивляемость моде. Каждый «убийца SQL» (MapReduce, GraphQL, документные БД) в итоге добавляет свой адаптер
Итог: SQL родился как эксперимент IBM, пережил смену названий и юридические баталии, но в итоге стал «лентой Мёбиуса» мира данных: можно зайти с любой стороны — и всё равно окажешься в
https://www.youtube.com/shorts/EuFjzuVHkHE
Как появился самый известный язык работы с базами, почему он едва не остался «Сиквелом» и какие любопытные факты о нём редко всплывают в учебниках.
1. Всё началось с таблицы на бумаге
- 1970 г. — британский математик Эдгар Ф. Кодд публикует культовую статью *“A Relational Model of Data for Large Shared Data Banks”*.
- В ней впервые прозвучала идея: хранить данные в виде связанных таблиц, а не как запутанные иерархии (IMS) или сетевые графы (Codasyl).
- Коллеги в IBM скептически называли это «бумагой на буквы», но разрешили сделать прототип, чтобы проверить утопию Кодда на практике.
2. SEQUEL — «английский» запрос к таблицам
- 1973–1974 гг. — в лаборатории IBM San José (ныне Almaden) двое молодых исследователей, Дональд Чемберлин и Рэймонд Бойс, берутся за проект System R.
- Чтобы обращаться к реляционным таблицам, они придумывают Structured English QUEry Language — SEQUEL.
- Ключевая фишка — запросы выглядят почти как английские предложения:
SELECT name, salary
FROM employees
WHERE dept = 'R&D';
- В 1974‑м публикуют первую спецификацию; академики критикуют за «слишком поверхностный английский», но программисты в восторге.
3. Почему SEQUEL стал SQL
- Торговая марка “SEQUEL” уже принадлежала авиастроительной компании *Hawker Siddeley*.
- IBM, опасаясь суда, в 1976 г. официально отказывается от «E» и оставляет SQL (Structured Query Language).
- *Небольшая путаница осталась навсегда: кто‑то произносит «эс‑кью‑эл», кто‑то — «сиквел».*
4. Коммерческий взлёт
- 1978 | Первая демонстрация System R внутри IBM | показала, что SQL работает быстрее ожиданий |
- 1979 | Стартап Relational Software (позже Oracle**) выпускает **Oracle V2 — первый коммерческий SQL‑движок | IBM ещё не успела выйти на рынок
- 1981 | IBM выпускает SQL/DS для мейнфреймов | стандарт де‑факто закрепляется
- 1983 | Дебют DB2 — теперь SQL есть почти в каждом крупном банке
5. Стандартизация и эволюция
- ANSI SQL‑86 → SQL‑92 (появился `JOIN ... ON`) → SQL:1999 (рекурсия, триггеры) → SQL:2003 (XML) → … → SQL:2023 (JSON, property graphs).
- Каждые 3–5 лет комитет добавляет «модные» возможности, но 90 % повседневных запросов всё ещё укладываются в синтаксис 1980‑х.
6. Забавные факты, которые украсят small talk 🍸
1. NULL ≠ 0 и NULL ≠ NULL — «неизвестное значение» нарушает законы логики, за что его зовут *“пятой ногой”* реляционной алгебры.
2. `SELECT *` — наследие печати на станке. Звёздочка означала «все колонки», чтобы не писать их руками в 132‑символьных перфокартах.
3. Команда `GO` в MS SQL Server не принадлежит стандарту SQL — это директива из старого клиента isql.
4. В Oracle долго не было `LIMIT`, а в MySQL — `RIGHT JOIN`. Поэтому админы шутили: «истинный межплатформенный SQL — это `SELECT 1;`».
5. Первый SQL‑вирус — червь *Slammer* (2003) — парализовал интернет за 10 минут через уязвимость в SQL Server 2000.
6. SQL — декларативный язык, но внутри СУБД каждый
SELECT превращается в процедурный план. 7. `DROP DATABASE` придумали позже, чем `CREATE`. Сначала удалять целую БД казалось слишком опасным.
7. Почему SQL живёт дольше модных NoSQL‑наследников
- Математическая база. Таблицы + операции Кодда образуют алгебру с предсказуемой оптимизацией.
- Стандарты и переносимость. Код двадцатилетней давности можно запустить в современной Postgres или MariaDB.
- Большая экосистема. От Excel‑плагинов до BigQuery — везде так или иначе поддерживается SQL‑диалект.
- Сопротивляемость моде. Каждый «убийца SQL» (MapReduce, GraphQL, документные БД) в итоге добавляет свой адаптер
SELECT ….Итог: SQL родился как эксперимент IBM, пережил смену названий и юридические баталии, но в итоге стал «лентой Мёбиуса» мира данных: можно зайти с любой стороны — и всё равно окажешься в
FROM.https://www.youtube.com/shorts/EuFjzuVHkHE
⚡️ Kubernetes устраняет проблему безопасности с приватными образами, которую не решали более 10 лет
Ранее, при использовании политики imagePullPolicy: IfNotPresent, kubelet мог запускать контейнеры из приватных образов, даже если pod не передавал нужные imagePullSecrets. Это означало, что уже загруженные образы могли использоваться без повторной проверки прав доступа.
Начиная с Kubernetes v1.33, kubelet теперь проверяет учетные данные pod-а даже для локально кэшированных образов. Если образ найден на узле, kubelet удостоверяется, что pod имеет соответствующие pull credentials, прежде чем разрешить его запуск.
Ожидается, что в v1.34 эта функция перейдёт в бета-стадию и получит дополнительные улучшения.
https://kubernetes.io/blog/2025/05/12/kubernetes-v1-33-ensure-secret-pulled-images-alpha/
Ранее, при использовании политики imagePullPolicy: IfNotPresent, kubelet мог запускать контейнеры из приватных образов, даже если pod не передавал нужные imagePullSecrets. Это означало, что уже загруженные образы могли использоваться без повторной проверки прав доступа.
Начиная с Kubernetes v1.33, kubelet теперь проверяет учетные данные pod-а даже для локально кэшированных образов. Если образ найден на узле, kubelet удостоверяется, что pod имеет соответствующие pull credentials, прежде чем разрешить его запуск.
Ожидается, что в v1.34 эта функция перейдёт в бета-стадию и получит дополнительные улучшения.
https://kubernetes.io/blog/2025/05/12/kubernetes-v1-33-ensure-secret-pulled-images-alpha/
На пути к 9999: практики обработки и мониторинга инцидентов
Каждый продукт Яндекс 360 (Диск, Почта, Телемост и другие) состоит из десятков, а то и сотен микросервисов, и каждый из них должен стабильно работать 24/7/365 и соответствовать самым высоким требованиям надёжности.
Игорь Обручев, руководитель группы SRE в Яндекс 360, рассказал, какими принципами они руководствуются, когда делают сервисы, как без паники чинят инциденты. А также кратко об учениях и для чего они нужны.
В докладе — про всё это, а также про команду 9999, тиры надёжности и про то, за что отвечает синий цвет протокола.
Больше материалов о технологиях в Яндекс 360
@yandex360team
Каждый продукт Яндекс 360 (Диск, Почта, Телемост и другие) состоит из десятков, а то и сотен микросервисов, и каждый из них должен стабильно работать 24/7/365 и соответствовать самым высоким требованиям надёжности.
Игорь Обручев, руководитель группы SRE в Яндекс 360, рассказал, какими принципами они руководствуются, когда делают сервисы, как без паники чинят инциденты. А также кратко об учениях и для чего они нужны.
В докладе — про всё это, а также про команду 9999, тиры надёжности и про то, за что отвечает синий цвет протокола.
Больше материалов о технологиях в Яндекс 360
@yandex360team
🧠 DevOps-задача: "Контейнер Шрёдингера"
Условие:
Ты получаешь баг-репорт:
> "Приложение внутри Docker-контейнера после деплоя не работает, но
Что известно:
- Docker-контейнер на основе
- Приложение запускается через
- Порт 8080 проброшен (`-p 8080: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
python3app.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: **приложение слушает
• внутри `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
```
- Если видим `
🛠 Исправление:
1. Проверь запуск приложения. Может, внутри у тебя:
```bash
python3
```
и он слушает только на localhost? Добавь:
```bash
python3
```
2. В Go, Node.js, Python и т.д. — по умолчанию bind'ят на
Проверь в настройках приложения или командной строке
🎯 Что проверяет задача:
• Умение мыслить в терминах изоляции контейнеров
• Понимание сетевых пространств имён (network namespaces)
• Знание, как работает NAT между контейнером и хостом
• Умение диагностировать "невидимый" bind
• Привычку **проверять всё снаружи**, а не только внутри контейнера
Подобные ошибки легко пропустить, особенно если всё проверяешь изнутри контейнера.
Знание контейнеров: путь к большим деньгам в ИТ или временный хайп? 💰
19 мая (понедельник) в 18:00 присоединяйтесь к настоящему батлу мнений.
В прямом эфире разработчики контейнерной платформы «Штурвал» вместе с AM Live соберут тех, кто знает индустрию изнутри.
Топовые спикеры обсудят, действительно ли знание Docker и Kubernetes в приоритете нужных навыков или это проходящая мода, которая никак не влияет на успешный карьерный трек?
Основные вопросы дискуссии:
▪️Насколько знания контейнеризации повышают конкурентоспособность и стоимость специалиста на рынке?
▪️Кто сейчас нужен больше — IT-специалист или IT generalist?
▪️Опыт работы с «ванильным» K8s VS с коммерческой платформой: есть ли разница?
▪️Что делать, если Kubernetes вообще не нравится?
▪️Площадки для обучения контейнеризации: норм или стрем?
🔜 Регистрация
19 мая (понедельник) в 18:00 присоединяйтесь к настоящему батлу мнений.
В прямом эфире разработчики контейнерной платформы «Штурвал» вместе с AM Live соберут тех, кто знает индустрию изнутри.
Топовые спикеры обсудят, действительно ли знание Docker и Kubernetes в приоритете нужных навыков или это проходящая мода, которая никак не влияет на успешный карьерный трек?
Основные вопросы дискуссии:
▪️Насколько знания контейнеризации повышают конкурентоспособность и стоимость специалиста на рынке?
▪️Кто сейчас нужен больше — IT-специалист или IT generalist?
▪️Опыт работы с «ванильным» K8s VS с коммерческой платформой: есть ли разница?
▪️Что делать, если Kubernetes вообще не нравится?
▪️Площадки для обучения контейнеризации: норм или стрем?
🔜 Регистрация
🦙 RamaLama — контейнерный подход к работе с AI-моделями. Этот инструмент переносит логику Docker/Podman в мир искусственного интеллекта, позволяя запускать LLM-модели как контейнеры с автоматической подгрузкой оптимизированных образов под ваше железо.
Вместо ручной настройки зависимостей RamaLama сама определяет доступные GPU/CPU и разворачивает изолированную среду для инференса. Модели из HuggingFace, Ollama или OCI-регистров можно тестировать через REST API или чат-интерфейс, не опасаясь утечек данных — все запуски происходят без сети с удалением временных файлов.
🤖 GitHub
@devopsitsec
Вместо ручной настройки зависимостей RamaLama сама определяет доступные GPU/CPU и разворачивает изолированную среду для инференса. Модели из HuggingFace, Ollama или OCI-регистров можно тестировать через REST API или чат-интерфейс, не опасаясь утечек данных — все запуски происходят без сети с удалением временных файлов.
🤖 GitHub
@devopsitsec
🌐 Задача-ловушка: Пропавший трафик после настройки iptables
Условие:
На сервере настроен простой iptables-фильтр для блокировки всего входящего трафика, кроме SSH:
После применения этих правил вы проверяете, что SSH соединения работают нормально (локально и удалённо). Сервер отвечает на пинги, всё ок.
На следующий день вы добавляете локальный контейнер (например, Docker), запускаете его с пробросом порта:
❗ Проблема: Снаружи контейнер не доступен. В браузере или curl получаете
Дополнительно, если выполнить:
— сервер отвечает нормально. Но с других машин — нет.
❓ Вопрос:
Почему порт 8080 недоступен извне? В чём подвох с iptables? Как починить проблему?
🔍 Подсказка:
Docker использует nat таблицы и
✅ Разбор:
💥 Ловушка:
Ваш iptables-правила:
запрещают ВСЁ, кроме SSH. Вы думаете, что входящие соединения через Docker должны идти через
Когда Docker пробрасывает порт с хоста (например, 8080), схема такая:
- Входящий пакет попадает в цепочку
- Потом через
И тут главная ловушка: даже если контейнер слушает порт на 0.0.0.0, Docker обрабатывает проброс трафика через FORWARD, а у вас политика по умолчанию:
Поэтому трафик до контейнера блокируется именно на этапе FORWARD.
🔧 Как проверить:
Запустить:
Вы увидите, что счётчик пакетов в
🛠 Как починить:
Добавить правило разрешения проброса пакетов для Docker:
Или (более строго):
✅ Вывод:
• В Linux iptables цепочки работают по строгой логике:
- INPUT — для пакетов к хосту
- FORWARD — для пакетов, которые переходят через хост (например, контейнеры или маршрутизаторы)
• Даже если кажется, что контейнер слушает на 0.0.0.0, проброс портов Docker работает через
💡 Бонус-вопрос:
Что изменится, если вы запустите контейнер с флагом
Условие:
На сервере настроен простой 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? Какие цепочки будут задействованы тогда?🛠️ Отправка уведомлений Slack из shell-скриптов
Автоматизация задач — это здорово, но ещё лучше — знать, когда они завершились или если что-то пошло не так.
Slack — популярный мессенджер, поддерживающий ботов, которых можно настроить для автоматических оповещений о важных событиях.
Сервер упал? Получите уведомление.
Скрипт завершил выполнение? Получите уведомление.
Добавив уведомления Slack в свои shell-скрипты, вы можете:
- 📣 легко делиться результатами работы скриптов с командой,
- 🛡️ быстро реагировать на проблемы,
- 🔍 быть в курсе событий без просмотра логов.
> Предполагается, что вы уже используете Slack и знакомы с понятием Slack Bot. Также необходимо базовое знание Bash.
🔗 Webhook + curl: секретная связка
Slack позволяет использовать входящие Webhook-и для получения сообщений.
А
Принцип:
- Slack даёт вам URL вида
- Вы используете
⚙️ Как включить входящие Webhook в Slack
1. Зарегистрируйтесь на [api.slack.com/apps](https://api.slack.com/apps)
2. Создайте новое приложение
3. В разделе Incoming Webhooks — активируйте их
4. Добавьте Webhook в рабочее пространство (выберите канал)
5. Сохраните Webhook URL — он понадобится далее
💬 Bash-скрипт для отправки уведомлений
Добавьте Webhook в
✅ Рекомендации
Не хардкодьте токены — используйте переменные окружения
Slack ограничивает частоту Webhook-запросов
Используйте уведомления только при необходимости (ошибки, алерты и т.п.)
Теперь вы можете:
- Добавить Slack-уведомления в свои cron-задачи
- Отслеживать состояние системы
- Получать оповещения об ошибках в скриптах.
Подробнее
Автоматизация задач — это здорово, но ещё лучше — знать, когда они завершились или если что-то пошло не так.
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-задачи
- Отслеживать состояние системы
- Получать оповещения об ошибках в скриптах.
Подробнее