13139
Присоединяйтесь к нашему каналу и погрузитесь в мир DevOps Сотрудничество, реклама: @devmangx Менеджер: @Spiral_Yuri РКН: https://clck.ru/3P8kFH
💡 Быстрый совет по Linux 🐧
Найдите недавно изменённые файлы за последние 5 минут:
find . -type f -mmin -5
Как HTTP(S)-порты пробрасываются из VM, у которых есть только приватные IP-адреса
- У каждого bare-metal хоста есть только один публичный IP-адрес
- DNS-запись *.node-xyz.iximiuz.com и wildcard-сертификат Let’s Encrypt указывают на этот IP
- Каждый раз, когда наружу пробрасывается порт VM, генерируется новый случайный поддомен
- Этот рандомный поддомен не существует за пределами конкретного хоста, он известен только соответствующему bare-metal серверу
- Все запросы к этому поддомену приходят на единственный публичный IP хоста, где слушает ingress-прокси (Envoy)
-Интерфейс VM виден только внутри её «обёртки» — Docker-контейнера (для дополнительной изоляции), поэтому Envoy не может достучаться до VM напрямую
- Вместо этого Envoy прокидывает запросы к поддомену в локальный UNIX-сокет, смонтированный в контейнер-обёртку VM
- Этот UNIX-сокет открыт специальным процессом-forwarder’ом (крошечный Go-сервис), который работает внутри контейнера-обёртки
- Forwarder делает io.Copy(UNIX socket, VM's private IP:port)
Профит! Десятки полностью изолированных VM на одном bare-metal хосте, и у каждой свой публичный URL
👉 DevOps Portal
Хотите перейти в DevOps или уверенно освоить Kubernetes?
Авторский курс «Администратор Kubernetes [Junior]» на Stepik — это практика с первого урока:
- Docker — сборка образов, запуск контейнеров, лучшие практики
- Kubernetes — Pods, Deployments, Services, Ingress, установка кластера и многое другое
- Helm — шаблоны и D.R.Y. подход
- GitLab CI — раннеры, синтаксис, сборка и деплой в K8s
⭐️ Рейтинг курса — 4.9 по отзывам студентов
🎁 Есть пробные уроки, а по итогам — сертификат Stepik.
🚀 Начните прямо сейчас:
- https://stepik.org/a/188289/pay?promo=3d60da1e6f9f15cd
А по промокоду MYDEVOPS — вы получите скидку 25%.
Быстрый совет по Linux
Логи упакованы в .gz? Их не нужно распаковывать, чтобы читать или искать по содержимому.
Используй инструменты с префиксом z прямо по месту:zcat — просмотреть файлzless — пролистывать содержимоеzgrep — искать внутри файлаzegrep — искать с расширенными регулярками (ERE)zfgrep — искать по фиксированным строкамzcmp/zdiff — сравнивать файлы
Эти команды позволяют анализировать сжатые логи без предварительной распаковки, идеально для быстрых сеансов устранения неполадок ✌️
👉 DevOps Portal
Уменьшили размер Docker-образа с 588 MB до 47,7 MB
Исходная сборка:
🔹Полноценный базовый образ Python 3.9
🔹Множество инструкций RUN, создающих лишние слои
🔹Отсутствие .dockerignore
🔹Одностадийная сборка со всеми зависимостями
Применённые оптимизации:
1. Более лёгкий базовый образ
- Перешли на Python 3.9-alpine
- Образ стал легче на ~95% и быстрее скачивается
2. Оптимизация слоёв
- Объединили связанные команды
- Убрали избыточные инструкции RUN
3. .dockerignore
- Исключили venv, кэши и временные файлы
- Сократили контекст сборки
4. Multi-stage build
- Отдельный stage для сборки зависимостей
- Production-stage с минимальным runtime-набором
Результат:
🔹Размер образа: 47,7 MB (с 588 MB)
🔹Снижение размера: −91,89%
🔹Более быстрый старт контейнера
🔹Меньше времени деплоя и меньше места в registry
Маленькие оптимизации дают большой эффект. Каждый сэкономленный мегабайт ускоряет каждый билд.
👉 DevOps Portal
Kubernetes позволяет добавлять собственные API
В Kubernetes есть мощный механизм под названием API Aggregation Layer.
Он помогает добавлять кастомные API в кластер.
Это означает, что вы можете создавать собственные типы ресурсов и заставлять Kubernetes делать больше, чем он умеет из коробки.
Классический пример использования Aggregation Layer в Kubernetes - это реализация Metrics Server.
Metrics Server реализует Metrics API как дополнительный API-сервер, используя Aggregation Layer.
Это означает, что хоть Metrics Server и является отдельным сервисом, к его API можно обращаться так, как будто он - нативная часть Kubernetes API.
В целом, поток запросов выглядит так:
- Когда вы запускаете kubectl get pods, запрос уходит на /api/v1/pods и маршрутизируется в Core API Server.
- Когда вы запускаете kubectl top pods, запрос уходит на /apis/metrics.k8s.io/v1beta1/ и маршрутизируется в Metrics Server.
Prometheus Adapter также использует этот механизм, чтобы отдавать кастомные метрики по адресу /apis/custom.metrics.k8s.io/
👉 DevOps Portal
Мы все знаем, что у AWS недавно случился даунтайм. Давайте разберём, что именно произошло.
Регион US-EAST-1 — один из крупнейших и наиболее критичных дата-центров AWS, где размещена инфраструктура тысяч крупных сайтов и приложений. Когда у DynamoDB, ключевого сервисa баз данных, начали расти ошибки, это вызвало эффект домино по взаимосвязанным системам AWS. Сбои стали массовыми, потому что многие приложения полагаются на DynamoDB для операций хранения и выборки данных.
DynamoDB глубоко интегрирован в архитектуру control plane AWS. Многие сервисы AWS используют его внутри для хранения метаданных, информации о состоянии и конфигураций сервисов. Поэтому, когда API-эндпоинт DynamoDB стал недоступен через DNS, зависящие от него сервисы потеряли доступ к критически важным операционным данным. Сбой одновременно затронул более 36 сервисов AWS.
Когда упала DNS-резолюция, клиенты просто перестали находить нужные эндпоинты DynamoDB. Это запустило фидбек-луп, похожий на тот, что произошёл во время даунтайма DynamoDB в сентябре 2015 года: каждый повторный запрос потреблял больше ресурсов, вызывал новые таймауты, которые, в свою очередь, генерировали ещё больше ретраев - и так по кругу, пока система не ушла в штопор.
AWS, вместо того чтобы ждать, пока найдут и устранят одну конкретную корневую причину, сразу пошёл по нескольким параллельным сценариям восстановления.
Основное исправление заключалось в стабилизации инфраструктуры DNS-резолвинга для эндпоинта DynamoDB. Команды инженеров AWS, вероятно:
🔹переконфигурировали или перезапустили DNS-резолверы, обслуживающие DynamoDB
🔹временно перевели трафик на альтернативные пути DNS-резолвинга
🔹применили аварийные настройки DNS-кэширования
Этот инцидент отражает взаимозависимость и хрупкость крупномасштабных облачных экосистем, где даже единственная точка отказа в базовом сервисе способна за минуты вызвать каскад проблем в десятках систем.
P.S. Это лишь часть деталей и предположений, которые я нашёл в интернете и сформировал на основе собственного понимания. Точные и подробные данные AWS ещё не раскрыл.
👉 DevOps Portal
Хочешь в DevOps, но не знаешь, с чего начать?
Ты админ, инженер и хочешь перейти в DevOps,
но не понимаешь, какие шаги приведут к росту, а не к потере дохода?
На бесплатной консультации с тьютором разберём твою ситуацию по полочкам:
— определим стартовую точку и реальные цели,
— покажем, как выстроить путь к DevOps без отката по зарплате,
— составим персональный roadmap с конкретными шагами,
— дадим рекомендации по инструментам, форматам обучения и проектам.
Консультация — это пинок из зоны комфорта и честный разговор о том, что мешает расти.
💡 Мы поможем увидеть карьерные траектории, которые сложно заметить самому,
и выстроить чёткий план действий, чтобы зарабатывать больше и расти быстрее.
Запишись на консультацию по ссылке —
первый шаг к осознанной карьере в DevOps начинается здесь.
Быстрый совет по Linux
Хочешь повторно использовать последний аргумент из предыдущей команды? Используй !$
Сбережёшь своё драгоценное время ✌️
👉 DevOps Portal
Знали ли вы, что поды могут становиться «невидимыми»?
Проверьте свои знания Kubernetes, попробуйте найти невидимый pod в этом челлендже: https://labs.iximiuz.com/challenges/kubernetes-invisible-pod-0bf2109b
Никаких подсказок и решений. Готовьтесь к жёсткой задаче 😈
👉 DevOps Portal
В этой статье экспериментируют с запуском кластера MariaDB Galera в Kubernetes-лаборатории за $150, собранной на платах Orange Pi.
Подробно разбираются установка K3s, деплой MariaDB Kubernetes Operator и настройка resource limits для малых SBC
Читайте здесь
👉 DevOps Portal
10 ошибок Kubernetes, которые нужно знать (и как их исправить)
Ошибки в K8s - одна из самых распространённых проблем, с которыми разработчики сталкиваются при запуске ворклоадов в продакшене, что приводит к неудачным деплоям, даунтайму и пустой трате времени на траблшутинг.
Читайте здесь
👉 DevOps Portal
🚀 Ты — DevOps-инженер, но мониторинг всё ещё вызывает вопросы?
Пора разобраться с новым курсом «Мониторинг с Prometheus» на Stepik!
От установки и настройки до сбора метрик, PromQL-запросов, алертов и дашбордов в Grafana — всё, что нужно для современного мониторинга.
📝 30+ тем, реальные примеры, минимум воды.
👨💻 Уже десятки инженеров учатся на курсе.
🎁 Для подписчиков канала: PROMETHEUS15 — скидка 15%!
👉 Открыть курс на Stepik
Как удаляется Pod: разбор закулисных процессов
Когда мы выполняем команду:
kubectl delete pod
$ kubectl delete pod techops-pod
pod "techops-pod" deleted
SIGTERM — запрашивает корректное завершение работы. Позволяет приложению завершить активные задачи и выполнить очистку перед остановкой. В Kubernetes при получении SIGTERM Pod получает время, чтобы завершиться “по-человечески”.
SIGKILL — принудительно завершает процесс без какой-либо очистки. Если Pod не завершился в отведённое время после SIGTERM, Kubernetes отправляет SIGKILL, чтобы окончательно его убить.
Этот репозиторий содержит более 20 инструментов, которые автоматически генерируют диаграммы архитектуры Kubernetes на основе манифестов, Helm-чартов или состояния кластера.
Github: Awesome-Kubernetes-Architecture-Diagrams
👉 DevOps Portal
Если вы хотите избавиться от сотен уязвимостей (CVE) в своих контейнерных образах, первым шагом будет понять, откуда они берутся
Типичные источники:
- «Толстый» базовый образ
- Забытые инструменты сборки
- Устаревшие зависимости
Простое решение? Многоэтапная сборка с более свежим и лёгким базовым образом.
Пример анализа базового образа: Более глубокий взгляд на Docker-образы Node.js: «Помогите, в моём Node-образе есть Python!»
👉 DevOps Portal
Основы сетей - Проброс портов
Древний трюк, который может помочь сделать сервис доступным на другом порту без рестарта, либо подключиться к базе данных внутри приватного VPC.
Практика:
🔸socat: https://labs.iximiuz.com/challenges/port-forwarding-using-socat
🔸netcat: https://labs.iximiuz.com/challenges/port-forwarding-using-netcat
🔸без прокси: https://labs.iximiuz.com/challenges/port-forwarding-without-proxy
👉 DevOps Portal
В чём разница между этими двумя DNS-запросами?
На вид они похожи, но на самом деле показывают совершенно разные вещи.
В первом случае:
— nslookup http://academy.networkchuck.com
Ты обращаешься к своему дефолтному DNS-резолверу (роутер или DNS от провайдера).
✅ Рекурсивный lookup — он пройдёт по всей цепочке CNAME до финального IP.
❌ Non-authoritative — ответ может быть из кэша и потенциально устаревшим.
Во втором случае:
— nslookup http://academy.networkchuck.com http://ns.cloudflare.com
Ты напрямую спрашиваешь авторитативный DNS-сервер.
✅ Ответ приходит прямо из первоисточника.
❌ Он покажет только то, что знает сам сервер — lookup остановится на первом CNAME.
И что же лучше? Зависит от задачи.
- Используй дефолтный резолвер, если тебе просто нужен конечный IP как можно быстрее.
- Обращайся к авторитативному серверу, если нужно проверить, кто чем реально управляет.
👉 DevOps Portal
Cовременная, легковесная дашборда для Kubernetes, которая предоставляет метрики в реальном времени, поддержку мультикластерных окружений, редактирование YAML и управление ресурсами через интуитивно понятный UI
GitHub: kite
👉 DevOps Portal
Свежий сбой в AWS (US-EAST-1)
Самое время пересмотреть стратегии аварийного восстановления в облаке (объяснённые простым языком)
Любая стратегия Disaster Recovery начинается с определения:
🔹RTO (Recovery Time Objective) —
сколько простоя вы можете себе позволить?
🔹RPO (Recovery Point Objective) —
какую потерю данных вы готовы терпеть?
Стратегии Disaster Recovery:
1. Backup and Restore → регулярные бэкапы и восстановление после инцидента
RTO: от нескольких часов до нескольких дней, RPO: момент последнего бэкапа
2. Pilot Light → ядро системы находится в standby и разворачивается при необходимости
RTO: от минут до часов, RPO: зависит от частоты репликации
3. Warm Standby → укороченная «живая» копия среды, которую можно быстро расшscaleить
RTO: минуты, RPO: от нескольких минут до часов
4. Hot / Multi-Site → оба сайта работают активно с мгновенным фейловером
RTO: близок к нулю, RPO: секунды
👉 DevOps Portal
⚡️ Новый курс по GitLab CI/CD уже на Stepik!
Внутри 50+ уроков: от разбора концепций CI/CD до написания рабочего GitLab CI пайплайна со сборкой, тестами, линтингом, временными отчетами и деплоем нейросети DeepSeek!
Материал подаётся простым языком, с пошаговыми инструкциями и реальными примерами.
📝 50+ уроков, реальные примеры, минимум теории.
👨💻 80+ учащихся уже записаны на курс.
⭐️ Рейтинг — 5 звёзд на Stepik.
🎁 Для подписчиков канала — промокод CICD15 (скидка 15%).
👉 Открыть курс на Stepik.
Совет дня по Linux
В Linux оператор конвейера (|) полезен, когда нужно направить вывод одной команды на вход другой для дальнейшей обработки:
$ cat data.txt | grep "No such file"
grep не даст результата.|&.$ cat data.txt |& grep "No such file"
grep смогла найти совпадение.|& в bash является сокращением для оператора перенаправления 2>&1 |:$ cmd-1 2>&1 | cmd-2
Упрощённое визуальное руководство по CI/CD
Непрерывная интеграция (CI) — практика частого слияния изменений кода в общий репозиторий с автоматической проверкой их целостности
Непрерывное развёртывание (CD) — автоматизирует релиз и деплой изменений кода в продакшен, обеспечивая отлаженный и надёжный процесс
Этот визуальный гайд поможет быстро разобраться, как это работает
👉 DevOps Portal
⚡️ На Stepik вышел курс по Linux
Ребята сделали крутейший курс по Linux, где понятным языком, шаг за шагом, на реальных примерах и с наглядными схемами обучают работе с этой ОС
Внутри 20+ модулей: от установки Linux и работы с файлами до сетей, прав, дисков, процессов, автоматизации на Bash и многого другого. Всё сразу закрепляется на практике (200+ заданий с автопроверкой).
После прохождения вы получите сертификат, который можно добавить в резюме.
Есть бесплатные демо-уроки для ознакомления. В ближайшие 48ч курс доступен со скидкой 25% по промокоду «LINUX=25»: открыть курс на Stepik
Знал, что в IP-адресах можно опускать нули - и всё равно будет работать?
Например:10.20.0.2 → 10.20.210.0.0.68 → 10.68
Оба варианта указывают на один и тот же хост.
Маленький, но прикольный трюк, который реально экономит пару нажатий в лабах.
👉 DevOps Portal
Маленькая шпаргалка для начинающих линуксоидов
Сохраняем и пользуемся ✌️
👉 DevOps Portal
Официальным языком DevOps должен быть YAML
- Helm использует YAML
- GitHub использует YAML
- Ansible использует YAML
- Argo CD использует YAML
- Kubernetes использует YAML
- Azure DevOps использует YAML
- Docker Compose использует YAML
и многие другие…
Все продвинутые инструменты, которые ты стремишься изучить и применять, работают на YAML.
Так что сначала разберись с ним, вот тебе шпаргалка
👉 DevOps Portal
Начиная с Kubernetes 1.34.1, интерфейс контейнерного рантайма (CRI-O) по умолчанию требует указания полностью квалифицированных имён образов.
При указании образов контейнеров в ваших деплойментах используйте полный путь до реестра.
Например: docker.io/nginx вместо просто nginx.
Если вы укажете короткое имя образа, которое совпадает с несколькими реестрами, пулл образа завершится ошибкой со следующим сообщением:
Warning Failed 57m (x12 over 59m) kubelet Error: ImageInspectError
Warning InspectFailed 4m43s (x258 over 59m) kubelet Failed to inspect image "": rpc error: code = Unknown
📆DevOps-митап с докладами от Altenar и Флант — встречаемся в центре Питера и онлайн вечером 30 октября.
Ребята из международного разработчика ПО Altenar расскажут, как устроена их гибридная инфраструктура и:
• Сравнят три способа подружить секреты из Vault с Kubernetes, которые опробовали в продакшене, а также рассмотрят альтернативные подходы.
• Поделятся, как построили и поддерживают секьюрити-пайплайн на базе SonarQube, Trivy Operator и DefectDojo силами одного инженера.
А также представитель Фланта поделится не так часто освещаемым опытом: как подойти к процессу сборки и доставки приложений в закрытые Kubernetes-кластеры.
👉🏻Все что нужно — зарегистрироваться.
📍Участие бесплатное, число мест в зале ограничено. Все зарегистрировавшиеся получат ссылки на трансляции в день мероприятия.
Образы контейнеров FROM scratch стоит ли так делать? 🤔
Довольно часто можно встретить практику, когда статически слинкованный бинарник на Go просто кладут в образ, собранный FROM scratch. Но у такого подхода есть ряд подводных камней:
- нет rootfs-лейаута
- отсутствуют CA-сертификаты
- нет базы данных часовых поясов
Решение? Использовать distroless-базу вместо этого
Подробнее о проблеме и одном из возможных решений:
🔹Building Container Images FROM Scratch: 6 Pitfalls That Are Often Overlooked
🔹What's Inside Distroless Container Images: Taking a Closer Look
👉 DevOps Portal