DevOps
По всем вопросам- @workakkk @itchannels_telegram - 🔥полезные ит-каналы https://t.me/Golang_google - Golang программирование @golangl - golang chat @GolangJobsit - golang channel jobs @golang_jobsgo - jobs РКН: clck.ru/3FmvZA #VRHSZ
Mostrar más📈 Análisis del canal de Telegram DevOps
El canal DevOps (@devopsitsec) en el segmento lingüístico de Ruso es un actor destacado. Actualmente la comunidad reúne a 23 428 suscriptores, ocupando la posición 5 808 en la categoría Tecnologías y Aplicaciones y el puesto 28 659 en la región Rusia.
📊 Métricas de audiencia y dinámica
Desde su creación el невідомо, el proyecto ha mostrado un crecimiento acelerado, reuniendo a 23 428 suscriptores.
Según los últimos datos del 11 junio, 2026, el canal mantiene una actividad estable. En los últimos 30 días la variación de miembros fue de -25, y en las últimas 24 horas de -4, conservando un alto alcance.
- Estado de verificación: No verificado
- Tasa de interacción (ER): El promedio de interacción de la audiencia es 11.89%. Durante las primeras 24 horas tras publicar, el contenido suele obtener 6.42% de reacciones respecto al total de suscriptores.
- Alcance de las publicaciones: Cada publicación recibe en promedio 2 785 visualizaciones. En el primer día suele acumular 1 503 visualizaciones.
- Reacciones e interacción: La audiencia responde de forma activa: el promedio de reacciones por publicación es 8.
- Intereses temáticos: El contenido se centra en temas clave como devops, kubernetes, git, github, кластер.
📝 Descripción y política de contenido
El autor describe el recurso como un espacio para expresar opiniones subjetivas:
“По всем вопросам- @workakkk
@itchannels_telegram - 🔥полезные ит-каналы
https://t.me/Golang_google - Golang программирование
@golangl - golang chat
@GolangJobsit - golang channel jobs
@golang_jobsgo - jobs
РКН: clck.ru/3FmvZA
#VRHSZ”
Gracias a la alta frecuencia de actualizaciones (últimos datos recibidos el 12 junio, 2026), el canal mantiene la vigencia y un amplio alcance. La analítica demuestra que la audiencia interactúa activamente con el contenido, lo que lo convierte en un punto de referencia dentro de la categoría Tecnologías y Aplicaciones.
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/EuFjzuVHkHEactions/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 #девопс/var/log неожиданно «занялось» много места. Проверяете это так:
df -h /var
И видите, что диск почти полностью заполнен. Но при этом, когда проверяете размер файлов в /var/log:
du -sh /var/log
— оказывается, что размер логов совсем небольшой, явно не соответствующий тому, что показывает df.
❓ Вопрос:
Почему возникает такая ситуация? Что именно занимает место, если файлы почти пустые? Как это исправить, не перезагружая сервер?
🔍 Подсказка:
На сервере активно работают несколько приложений, которые записывают логи. Недавно был произведён logrotate, старые логи удалились.
---
✅ Разбор:
💥 Подвох:
Многие думают, что после удаления файла место сразу освобождается. Но в Linux есть важный нюанс: если процесс всё ещё держит файл открытым, даже после удаления файла из файловой системы, его содержимое продолжает занимать место на диске.
Вот что происходит:
- du показывает размер существующих файлов, поэтому он маленький (ведь файлы удалены).
- df показывает реальное использование блочного устройства, и оно включает те данные, которые всё ещё заняты удалёнными, но открытыми файлами.
🚩 Это классическая ситуация после logrotate: старые логи удаляются, но процессы, которые их писали (например, nginx, `mysql`), продолжают держать дескрипторы открытыми.
🔧 Как найти виновника:
Используем lsof для поиска удалённых, но ещё открытых файлов:
```bash
lsof | grep deleted
```
Вы увидите что-то вроде:
```
nginx 1234 ... /var/log/nginx/access.log (deleted)
```
🛠 Как исправить без перезагрузки:
1️⃣ Перезапустить приложение, которое держит файл открытым:
```bash
systemctl restart nginx
```
2️⃣ Если нельзя перезапустить, можно попробовать «сбросить» файл, подменив его на новый (подходит не всегда).
---
✅ Вывод:
• df и du показывают разное, потому что считают разными методами:
- df: что реально занято на диске (включая удалённые, но ещё открытые файлы)
- du: что физически доступно через файловую систему
• Если место не освобождается после удаления файла — ищите открытые файловые дескрипторы удалённых файлов. Это классика для DevOps!
💡 Бонус-вопрос для гуру:
Что произойдёт, если в lsof вы видите удалённый файл, но процесс — это docker? Как поступить в этом случае? 😉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
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 = масштабирование.. ├─ 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.
🔜 Решение
¡Ya disponible! Investigación de Telegram 2025 — los principales insights del año 
