13139
Присоединяйтесь к нашему каналу и погрузитесь в мир DevOps Сотрудничество, реклама: @devmangx Менеджер: @Spiral_Yuri РКН: https://clck.ru/3P8kFH
Откопал живой интерактивный тренажёр для прокачки практических навыков по DevOps, облачным техам и не только – Killercoda.
Это браузерная платформа с реальными интерактивными средами, где ты можешь запускать:
• Linux/Ubuntu терминал
• Kubernetes‑кластеры (включая контрольную плоскость)
• инструменты типа Docker, bash, Git и др.
• готовые учебные сценарии и playground‑среды прямо в браузере без локальной настройки окружения
Платформа подходит как для новичков (практика базовых команд), так и для прокачки в Kubernetes/DevOps, подготовки к CKA/CKAD/CKS и другим кейсам – можно запускать сценарии, выполнять задачи и экспериментировать с реальными системами
Плюс можно создавать и делиться своими сценариями с сообществом .
Ссылка: killercoda.com
👉 DevOps Portal
Бывали ли у вас ситуации, когда использовать Kubernetes — это уже перебор, но деплоить на пачку VM с самописными скриптами или Ansible-плейбуками тоже не особо хочется?
Docker Swarm может быть жив или мёртв — вопрос спорный, но сама ниша никуда не делась. И такие проекты, как Kamal (от 37signals) и Uncloud (от Паши Свидерского), пытаются её закрыть.
Если вы ещё не слышали про последний, Uncloud — это лёгкий (по сравнению с Kubernetes) инструмент для деплоя и управления контейнеризованными приложениями в сети Docker-хостов.
Антон Овчинников недавно опубликовал пошаговый гайд на iximiuz Labs, в котором показано, как развернуть кластер Uncloud на нескольких VM. Рекомендуем посмотреть:
https://labs.iximiuz.com/tutorials/uncloud-create-cluster-ebebf72b
Традиционно, все команды из туториала можно прогнать прямо в приложенной песочнице ✌️
👉 DevOps Portal
Что на самом деле происходит, когда вы запускаете контейнер самой типичной командой docker run nginx?
На первый взгляд кажется, что Nginx становится вашим foreground-процессом в терминале – он перехватывает stdio-потоки и реагирует на сигналы, когда вы нажимаете Ctrl+C или меняете размер окна терминала.
Но в реальности терминалом управляет процесс Docker-клиента, а сам Nginx работает в фоне или вообще на удалённой машине. При этом между docker CLI, dockerd (основным Docker-демоном) и containerd (низкоуровневым container runtime) происходит довольно сложная проксировка данных и сигналов — из-за чего всё ощущается как простой локальный запуск.
Почему это важно? Понимание того, как работает docker run под капотом — ключ к пониманию Kubernetes и других продакшн-рантаймов. В продакшене контейнеризованные приложения обычно работают в фоне, но Kubernetes и похожие системы позволяют стримить логи приложений и даже переподключаться к процессам в контейнерах, используя те же самые трюки, что и Docker.
Подробнее о магии за командой docker run — в подробном разборе (с кучей практических упражнений):
https://labs.iximiuz.com/tutorials/docker-run-vs-attach-vs-exec
👉 DevOps Portal
Если вы разработчик, вы уже участвуете в выборе и настройке облаков для клиентов. Обычно бесплатно для себя.
Itentis Cloud предлагает зарабатывать на этом системно.
Itentis Cloud - это изолированная и безопасная облачная платформа для бизнеса: масштабируемый и отказоустойчивый виртуальный датацентр, который разворачивается за пару кликов.
Как вы зарабатываете:
📌Вариант 1. Партнерская модель
Вы приводите компанию в Itentis Cloud. Клиент платит за облако, а вы получаете фиксированную долю с каждого платежа.
📌Вариант 2. Субаренда
Вы арендуете облако у Itentis Cloud и сдаете его своим клиентам по собственной цене.
Что это дает вам:
– дополнительный доход с текущих клиентов
– прозрачную схему: привели → настроили → сопровождаете → регулярно получаете деньги
Что получает клиент:
– российскую облачную платформу для бизнеса, построенную как изолированный виртуальный датацентр
- закрытие базовой задачи IaaS
- прозрачную модель для инженеров: понятная модель ресурсов, быстрый старт, возможность кастомной настройки под требования проекта
- совместимость с российской инфраструктурой
- настройку за несколько кликов
Подробности - на сайте Itentis Cloud.
Этот туториал показывает, как задеплоить полноценный LGTM observability-стек (Loki, Grafana, Tempo, Mimir) с использованием OpenTelemetry в Kubernetes для единого сбора метрик, логов и трейсов
Читайте тут
👉 DevOps Portal
Используйте эту команду kubectl, чтобы мгновенно найти pod’ы с утечками ресурсов или чрезмерным потреблением по всему кластеру Kubernetes
👉 DevOps Portal
• Друзья, пришло время провести очередной конкурс. На этот раз мы разыгрываем бумажную версию книги "Практическая безопасность Linux", которая поступила в продажу 2 недели назад. Автор издания лично подпишет для вас книгу и направит по нужному адресу. Ну и чтобы повысить шанс на победу, мы сделали целых 15 призовых мест!
• Итоги подведём 17 января в 11:00 по мск., случайным образом, при помощи бота. Доставка для победителей бесплатная в зоне действия СДЭК.
Для участия нужно:
1. Быть подписанным на наш канал: Infosec.
2. Подписаться на канал наших друзей: Мир Linux.
3. Нажать на кнопку «Участвовать»;
4. Ждать результат.
Бот может немного подвиснуть — не переживайте! В таком случае просто нажмите еще раз на кнопку «Участвовать».
#Конкурс
Все знают, что балансировщики нагрузки на eBPF превосходят user-space LB, потому что они избегают копирования пакетов и переключений контекста.
Но вот малоизвестный факт: ты можешь написать собственный eBPF-балансировщик, с выбором бэкенда и session affinity, всего в 200 строках на C.
Теодор снова это доказывает:
https://labs.iximiuz.com/tutorials/xdp-load-balancer-700a1d74
👉 DevOps Portal
С кодом у тебя всё ок.
Если что-то не работает — смотришь логи, находишь баг, фикcишь.
А с женщинами ощущение, будто:
— документации нет
— поведение недетерминированное
— один и тот же input → разный output
— вчера работало, сегодня — игнор
Ты вроде нормальный парень.
Не токсик. Не дурак. Не бедный.
По логике этого должно хватать.
Но система не сходится.
Ты общаешься — вроде без ошибок.
А в ответ холод, странные реакции или «давай как-нибудь потом».
Самое бесячее — ты не понимаешь, где именно происходит краш.
Со временем я понял простую вещь:
в отношениях и общении с женщинами другая архитектура.
Не интуиция. Не магия.
Просто другие правила, которые никто не объяснил.
В этом канале я разбираю это как систему:
что реально влияет, где ты теряешь контроль,
и как перестать действовать методом тыка.
Если ты привык дебажить, а не гадать — оставайся. Тут будет полезно: /channel/+phixOQ8pvDAxNTY6
Как установить и настроить kubectl на Linux
kubectl - это CLI-инструмент для взаимодействия с кластерами Kubernetes. Независимо от того, управляете ли вы контейнерами, деплоите приложения или устраняете проблемы в кластере, kubectl является вашим основным интерфейсом для работы с API-сервером K8s.
Читать тут
👉 DevOps Portal
Мини-курс по containerd обновлён и переведён на недавно вышедшую версию containerd 2.2.1. Если нужно глубже разобраться, как контейнеры управляются низкоуровневыми рантаймами (тем самым слоем под Docker или Kubernetes), это хорошая отправная точка
https://labs.iximiuz.com/courses/containerd-cli
👉 DevOps Portal
How-To: как собрать eBPF-фаервол, который фильтрует пакеты по диапазонам IP
В большинстве туториалов показывают, как заблокировать один конкретный IP-адрес. Но в реальном мире (Kubernetes, автоскейлинг нод, короткоживущие ворклоады, managed-сервисы и т. п.) IP-адреса постоянно меняются, поэтому на практике имеет смысл работать именно с CIDR-диапазонами.
В этой статье вы узнаете, как правильно блокировать целые подсети:
https://labs.iximiuz.com/tutorials/ebpf-firewall-ed03d648
👉 DevOps Portal
Kubernetes совет
Удалить все поды в неймспейсе
При работе с тестовым кластером или в процессе обучения
могут возникнуть ситуации, когда нужно удалить все поды в конкретном неймспейсе.
Сделать это можно с помощью флага --all
👉 DevOps Portal
🤔 Как хранят Docker-образы на реальной работе? Как делать так, чтобы уязвимости не попадали в прод?
Harbor — топ-1 open-source приватный Docker Registry, который даёт всё для DevOps/DevSecOps:
• Встроенное сканирование уязвимостей (Trivy).
• Proxy-cache для быстрого pull без rate-limit.
• Подпись образов (Cosign) от подмены.
• Политики блокировки небезопасных артефактов.
• Retention для автоматической очистки.
• Мониторинг через Kube-Prometheus-Stack.
Самый распространённый способ запустить контейнер — использовать Docker CLI. Но что именно делает команда docker run? Чем она отличается от:
🔹 podman run
🔹 nerdctl run
🔹 ctr run
🔹 runc create/start
Мини-курс, чтобы научиться запускать контейнеры с разными рантаймами:
https://labs.iximiuz.com/skill-paths/run-containers-across-runtimes
👉 DevOps Portal
Быстрый совет по Linux
Вместо tail смотри лог-файлы в реальном времени с флагом +F:
less +F hello.txt
Shift+F, чтобы снова начать следить за файлом в реальном времени.q, чтобы полностью выйти из less.
Let’s Encrypt начал выдавать TLS-сертификаты для IP-адресов и запустил короткоживущие 6-дневные сертификаты
Теперь можно поднимать HTTPS напрямую на IPv4/IPv6 без доменного имени – удобно для homelab, тестовых стендов, временных сервисов, внутренних бэкендов и начальной настройки серверов. Сертификаты для IP выдаются только в short-lived формате и живут 160 часов (чуть больше 6 дней)
Параллельно стали доступны опциональные 6-дневные сертификаты и для доменов – как дополнительный уровень защиты: при компрометации ключа ущерб ограничен самим сроком жизни сертификата, а не отзывом.
Для получения нужен ACME-клиент с поддержкой профиля shortlived (например, свежий Certbot). Для IP валидация только через http-01 или tls-alpn-01 – dns-01 не поддерживается
@linuxos_tg
Откопал полезную базу по Linux / Unix от Tutorialspoint – простые и понятные объяснения без лишней воды
Там разбирают всё, с чем сталкиваешься в линуксе каждый день:
— как работают процессы и сигналы
— что происходит с памятью
— как устроена файловая система
— как читать и настраивать права доступа
Каждая тема с примерами команд и лаконичными пояснениями
Забирайте тут
👉 DevOps Portal
Linux-совет для DevOps-инженеров
Как получить публичный IP сервера с помощью команды?
Можно использовать curl и публично доступные сервисы, чтобы получить внешний адрес, как показано на изображении.
Для AWS и GCP всегда используйте соответствующий metadata-сервис, чтобы получать публичный IP.
Примечание: не используйте публично доступные сервисы в реальном проекте или продакшн-коде. Всегда консультируйтесь с вашей командой по безопасности по доступным вариантам
👉 DevOps Portal
Аннотации в Kubernetes часто объясняют просто как метаданные
Большинство знают, что аннотации используются такими инструментами, как Prometheus или Ingress-контроллеры.
Но многие не осознают, какая мощь в них скрыта.
Аннотации не имеют фиксированной структуры – Kubernetes их не валидирует и не пытается интерпретировать. И именно поэтому они настолько мощные.
Они работают как механизм расширения Kubernetes.
Каждый контроллер, оператор и внешний инструмент использует аннотации для передачи информации, не меняя core API.
Именно так Kubernetes эволюционирует, не ломая старые конфигурации.
Аннотации не предназначены для селекции или фильтрации – для этого есть labels.
Аннотации существуют для описания поведения и контекста, а не идентичности.
Поэтому они могут быть большими, описательными и разными для каждого инструмента.
Аннотации не бесконечны – у них есть лимит в 256 КБ, с которым многие из вас наверняка сталкивались.
Аннотации не обязаны жить только на Pod’ах.
Одни инструменты читают их из Service, другие – из Namespace, а некоторые даже используют аннотации на Node. Механизм один и тот же, меняется только область применения.
Хороший реальный пример – Argo CD Image Updater.
Вместо того чтобы напрямую менять манифесты, он использует аннотации на Application, чтобы управлять тем, какие образы отслеживать, стратегией обновления и правилами тегов.
Вся логика работы управляется через аннотации.
Никаких новых CRD.
Никаких кастомных конфигов.
Просто метаданные, которые управляют автоматизацией.
Вот разбор этого на практическом примере.
Читайте здесь: https://devopscube.com/setup-argocd-image-updater
Примечание: аннотации – это не конфигурация, это средство коммуникации.
Когда начинаешь смотреть на них именно так, многие архитектурные решения Kubernetes внезапно становятся понятными
👉 DevOps Portal
Kargo — это платформа непрерывной доставки и оркестрации жизненного цикла приложений для Kubernetes.
Она основана на принципах GitOps и интегрируется с Argo CD, чтобы упростить и автоматизировать поэтапный (progressive) rollout изменений на протяжении всего жизненного цикла приложения
https://github.com/akuity/kargo
👉 DevOps Portal
Kubernetes Gateway API постепенно вытесняет кастомные API маршрутизации, используемые в service mesh
В материале разобрано, что такое GAMMA и как он работает
Опубликован подробный практический гайд, в котором ключевые концепции объясняются на наглядных примерах и иллюстрациях.
Что рассматривается в гайде:
- что из себя представляет подход GAMMA
- как он отделяет логику маршрутизации от реализации mesh
- реализация canary-деплоев с использованием GAMMA
- использование HTTPRoute совместно с DestinationRule в Istio
- production-кейс применения подхода GAMMA
Полный гайд:
https://devopscube.com/gateway-api-for-service-mesh/
Несмотря на то, что API VirtualService и DestinationRule в Istio по-прежнему широко используются,
GAMMA предлагает вендорно-независимый подход.
Это означает отсутствие жёсткой привязки к Istio-специфичным API, таким как VirtualService и DestinationRule.
Внутренний трафик можно описывать через HTTPRoute, отделяя маршрутизацию от нижележащего mesh-слоя в Kubernetes.
👉 DevOps Portal
Отладка контейнеров 101: как выполнять команды хоста внутри уже запущенного контейнера
Хорошие контейнерные образы должны содержать только те пакеты, которые необходимы приложению для работы в продакшене. Но что делать, если такой идеальный минималистичный контейнер начинает вести себя некорректно?
https://labs.iximiuz.com/challenges/docker-container-execute-commands-with-nsenter
👉 DevOps Portal
Это инструмент на Golang, который анализирует распределение и использование GPU-ресурсов в кластерах Kubernetes, снижая нагрузку на API-server примерно до ~75 %, при этом предоставляя наглядную статистику использования по каждому node и pod
GitHub: k8s-gpu-analyzer
👉 DevOps Portal
Встречайте новый формат инженерного диалога
T-Sync Conf — офлайн-конференция от Группы «Т-Технологии» для опытных инженеров. 7 февраля в Москве на площадке TAU соберутся платформенные, security- и дата-инженеры, аналитики, DevOps-, SRE-, CI/CD-, AI-, ML-, R&D- и DX -специалисты.
Как все устроено:
— Контуры — тематические зоны, каждая из которых раскрывает отдельный слой инженерной реальности: AI, Data, R&D, Security, Platform и другие направления.
— Вместо классических докладов — круглые столы, стенды, хакатон, воркшопы и мастер-классы.
— Инженерные решения изнутри — возможность посмотреть, как устроены технологии в Т-Банке и других компаниях, и пообщаться напрямую с теми, кто их создает.
А еще много практики, интересных знакомств и живых систем.
Успейте подать заявку
Простой способ создавать свои DevOps-лабы
Примерно год iximiuz Labs поддерживает создание кастомных плейграундов: вы выбираете стандартную базу (Ubuntu-VM, Docker-хост, Kubernetes-кластер и т.д.) и донастраиваете её под свои задачи с помощью скриптов, похожих на cloud-init.
Подход хорошо себя зарекомендовал, таким образом было создано около 700 плейграундов. Но при всей "чистоте" скриптового провижининга у него есть и заметные минусы:
- Init-скрипты запускаются при каждом старте плейграундов, увеличивая time-to-prompt, иногда весьма существенно
- Некоторые задачи провижининга гораздо проще решать запуском shell-команд вручную (попутно чиня упавшие шаги)
- Некоторые "случайные" состояния VM имеет смысл сохранить как переиспользуемые кастомные плейграунды (но задним числом заскриптовать их уже нельзя)
Большинство людей сразу прыгают в Prometheus и Grafana, не понимая, какую именно задачу они на самом деле решают.
Я постоянно вижу это на собеседованиях. Человек говорит: «Мы используем Prometheus для мониторинга», но при этом не может объяснить, почему логи и метрики требуют разных пайплайнов, или что вообще происходит, когда CloudWatch перестаёт справляться на масштабе.
В observability вы решаете две принципиально разные проблемы.
Логи отвечают на вопрос "что произошло". Произошла ошибка. Пришёл запрос. Упал запрос к базе данных.
Это события - истории, которые рассказывает ваше приложение.
Метрики отвечают на вопрос "как система чувствует себя прямо сейчас". Латентность 200 мс. CPU 75%. 500 запросов в минуту. Это измерения.
Разные типы данных. Разные способы сбора. Разное хранение. И именно здесь большинство людей путается.
В прошлом месяце на моём DevOps-буткемпе мы собрали полноценную систему observability для микросервисов в Kubernetes.
Логи
Для логов мы использовали Fluentd sidecar-контейнеры, которые шарят volume с основным контейнером приложения:
- приложение пишет логи в volume;
- Fluentd читает их и отправляет дальше;
- чёткое разделение ответственности;
- на небольшом масштабе логи просто улетают напрямую в CloudWatch.
Но когда у вас тысячи строк логов в секунду, приходится добавлять слои:
- Lambda для форматирования.
- Kinesis для буферизации.
- OpenSearch для быстрых запросов по петабайтам данных.
- S3 для долгосрочного бэкапа.
Мы держали 7 дней в OpenSearch для активных расследований. 30 дней — в CloudWatch. Годы — в S3 для комплаенса. У каждого слоя разные характеристики по цене и производительности.
Метрики
Для метрик Prometheus скрейпит application endpoints каждые 30 секунд:
- разработчики инструментируют код клиентскими библиотеками Prometheus;
- экспонируют /metrics endpoint;
- Prometheus сам подтягивает данные.
Мы создали ServiceMonitor’ы, которые говорят Prometheus, какие pod’ы скрейпить на основе label’ов:
- Как только поднимаются новые pod’ы, Prometheus их обнаруживает и начинает скрейпить.
- Дальше Grafana визуализирует всё это.
- Мы импортировали готовые дашборды с grafana.com для мониторинга Kubernetes.
- И также собрали кастомные панели под метрики конкретного приложения.
Логи и метрики идут параллельно.
Когда что-то ломается, метрики показывают вам всплеск: error rate подпрыгнул в PM. Латентность выросла со 100 мс до 2 секунд.
Дальше вы идёте в логи: фильтруете по тому же окну времени, находите stack trace’ы и видите, что именно упало.
Нельзя нормально дебажить, имея только один тип данных. Нужны обе перспективы.
Мы всё это реализовали и оттраблшутали в лайв-созвоне: нагенерили метрики и логи и собрали дашборды в Grafana
Прочитать подробный пост можно здесь: https://open.substack.com/pub/akhileshmishra/p/youre-not-ready-for-kubernetes-observability
👉 DevOps Portal
Тормозят Docker-сборки? Используй мощь build cache
Build cache переиспользует слои образа и метаданные, чтобы ускорить сборку. Когда ты пересобираешь образ без изменений или с минимальными изменениями, билдер повторно использует результаты предыдущей сборки.
На картиинке наглядный пример того, как build cache работает между сборками
Если хочешь ускорить сборки, в этом туториале разобраны ключевые концепции и практики, которые помогают выжать максимум из кэша:
https://depot.dev/blog/ultimate-guide-to-docker-build-cache
👉 DevOps Portal
Репозиторий для изучения Prometheus и понимания, зачем и где его использовать
https://github.com/acend/prometheus-training
👉 DevOps Portal
Нашёл максимально залипательный способ прокачать system design и облачную архитектуру – игра Server Survival
Это 3D tower defense, где вы играете за облачного архитектора: строите инфраструктуру, раскидываете файрволы, балансировщики, сторэджи, отбиваетесь от дудоса, следите за бюджетом и здоровьем сервисов.
По сути, интерактивный симулятор продакшн-нагрузки, только в формате игры 🥳
И да, проект опенсорс, код на GitHub
@IT_Portal