DevOps Portal | Linux

Работа с HTTP API: практика Подготовили мини-серию из пары десятков практических заданий: от простых GET-запросов к эндпойнтам до обработки сложных JSON-ответов, работы с аутентификацией API и проверки целостности скачанных файлов:

Вызов HTTP API через curl: получение ресурсов https://labs.iximiuz.com/challenges/linux-call-http-api-with-curl Вызов HTTP API через curl: создание, обновление и удаление ресурсов https://labs.iximiuz.com/challenges/linux-call-http-api-with-curl-create-update-delete Вызов HTTP API через curl: обработка JSON-ответов с помощью jq https://labs.iximiuz.com/challenges/linux-call-http-api-with-curl-process-json-with-jq Вызов HTTP API через curl: аутентификация через Basic Auth и Bearer-токены https://labs.iximiuz.com/challenges/linux-call-http-api-with-authentication Проверка скачанных файлов по SHA-256-хешам https://labs.iximiuz.com/challenges/linux-verify-downloads-with-sha256-checksums

Удачной практики! 👉 DevOps Portal

Ops 101: как определить источник неожиданных запросов Одна из типичных задач при эксплуатации сервиса - отличить легитимные запросы от нежелательных. Попрактиковаться можно здесь:

— В классической on-prem-инфраструктуре https://labs.iximiuz.com/challenges/linux-identify-hosts-behind-unexpected-requests — В Kubernetes-кластере https://labs.iximiuz.com/challenges/kubernetes-identify-workloads-behind-unexpected-requests

👉 DevOps Portal

Kubernetes Goat С помощью этого репозитория можно прокачать навыки тестирования безопасности кубера (Там есть готовая инфраструктура, которая разворачивается по скрипту) https://github.com/madhuakula/kubernetes-goat 👉 DevOps Portal

Псс, хочешь перестать мониторить Telegram в поисках работы? 👀 Ты листаешь каналы, видишь вакансию, сохраняешь и откладываешь отклик «на потом». Потому что на каждую нужно потратить минут 20. В итоге из десятков сохранённых вакансий до отклика доходят единицы. Софи забирает эту рутину на себя. Она сама находит подходящие вакансии в 350+ Telegram-каналах, изучает их, пишет персональное сопроводительное и отправляет отклик. А еще она умеет откликаться на: ▫️ hh ru ▫️ карьерных сайтах компаний - Авито, Сбер, Т-Банк ▫️ Geekjob ▫️ youngjunior.ru Тебе больше не нужно выбирать, где сегодня искать работу. Софи будет искать везде. Доступ откроется уже завтра. Первые 3 дня - бесплатно. Мест немного. Подпишись, чтобы не пропустить старт.

Как работает NodeLocal DNSCache в Kubernetes Когда речь идёт о производительности, в Kubernetes важен каждый DNS-запрос. Без NodeLocal DNSCache поды отправляют DNS-запросы на Service IP kube-dns/CoreDNS. Перед тем как попасть в CoreDNS, эти запросы проходят через kube-proxy, правила DNAT и conntrack. В нагруженных кластерах это может увеличивать задержки и создавать дополнительную нагрузку на таблицу conntrack. NodeLocal DNSCache решает эту проблему, запуская локальный DNS-кеш на каждой ноде в виде DaemonSet. Вместо того чтобы обращаться напрямую к CoreDNS, поды отправляют DNS-запросы в локальный кеш на той же ноде. Основные преимущества: - Снижает среднее время DNS-резолвинга, поскольку DNS-запросы обрабатываются локально через DNS-кеш. - Снижает нагрузку на CoreDNS. - Помогает избежать переполнения таблицы conntrack, поскольку соединения от подов к локальному кешу не создают записи в таблице conntrack. - DNS-запросы к внешним URL могут форвардиться напрямую, без участия CoreDNS. 👉 DevOps Portal

DNS 101: как резолвятся публичные, внутренние и локальные хостнеймы В большинстве случаев при работе с curl или ssh вы указываете хостнейм. Когда сетевой запрос использует имя вместо IP-адреса, сначала это имя нужно зарезолвить. Как именно это происходит: https://labs.iximiuz.com/challenges/linux-resolve-hostnames-with-hosts-file-and-dns 👉 DevOps Portal

На Stepik запустили годный курс по «Troubleshooting Docker и Kubernetes: поиск и устранение проблем» В программе только важные аспекты: — troubleshooting Docker и образов — диагностика сетевых проблем — настройка readiness/liveness probes — отладка pod’ов, деплоев и ingress — анализ логов контейнеров и кластера — разбор ошибок CrashLoopBackOff, OOMKilled, ImagePullBackOff и других Собеседования на DevOps/SRE сейчас всё чаще строятся вокруг реальных инцидентов. Данный курс фокусируется именно на таких сценариях и помогает в подготовке к практическим вопросам 48 часов доступен со скидкой 25% ↗️ Пройти курс на Stepik

DevOps-инструмент недели: sofka Kubernetes говорит, что что-то сломалось. Но говорит ли он, почему именно? Приходится проверять статус, события, логи и пытаться понять, в чём проблема. Именно это решает sofka. sofka — это TUI для Kubernetes, вдохновлённый k9s. Он показывает состояние rollout, деградировавшие состояния, блокирующие поды и последние warning-события Вот что он умеет: • Объясняет, почему ресурс сломан, а не просто сообщает, что с ним проблема • Встроенная поддержка Flux CD: можно приостанавливать, возобновлять и запускать reconcile без установленного Flux CLI • Инспектор Helm: история релизов, values и сгенерированные манифесты без установленного Helm • Есть фильтры вроде cpu>500m, restarts>=5, age<2h, чтобы быстро находить именно то, что нужно • Можно просматривать таймлайн всех изменений объекта, которые зафиксировал инструмент • Можно просматривать и передавать файлы напрямую из PVC • Можно выбрать несколько подов и смотреть их логи одновременно • Поддержка плагинов Popeye и Trivy Согласно бенчмаркам проекта, sofka открывает представление подов на 59% быстрее k9s и использует меньше половины его объёма памяти. В следующий раз, когда деплой зависнет и придётся по кусочкам выяснять, что произошло, попробуйте sofka. Начать здесь: http://github.com/nklmilojevic/sofka 👉 DevOps Portal

В этом туториале показано, как KEDA масштабирует ворклоады на основе глубины очереди, а не загрузки CPU, на полноценном примере с RabbitMQ: установка, настройка TriggerAuthentication, ScaledObject и нагрузочный тест, который подтверждает, что масштабирование работает: https://the-devops-engineer.medium.com/kubernetes-keda-autoscaling-scale-smarter-not-harder-d186da29175a 👉 DevOps Portal

👩‍💻 Всем программистам посвящается! Вот 14 авторских обучающих IT каналов по самым востребованным областям программирования: Выбирай своё направление: 👩‍💻 Python — t.me/python_ready 🤔 InfoSec & Хакинг — t.me/hacking_ready 🖥 SQL & Базы Данных — t.me/sql_ready 👩‍💻 IT Новости — t.me/it_ready 🤖 AI & ML — t.me/neuro_ready 👩‍💻 Frontend — t.me/frontend_ready 👩‍💻 C/C++ — https://t.me/cpp_ready 👩‍💻 C# & Unity — t.me/csharp_ready 👩‍💻 Linux — t.me/linux_ready 👩‍💻 Java — t.me/java_ready 📖 IT Книги — t.me/books_ready 📱 JavaScript — t.me/javascript_ready 🖼️ DevOps — t.me/devops_ready 🖥 Design — t.me/design_ready 📌 Гайды, шпаргалки, задачи, ресурсы и фишки для каждого языка программирования!

Kubernetes Secret: data vs stringData При создании Secret в Kubernetes секретные данные можно указать в двух разных полях: - data - stringData В чём разница? Если использовать поле data, значения нужно заранее закодировать в Base64. Если же хочется указывать значения в манифесте обычным текстом, можно использовать stringData. При создании Secret через stringData Kubernetes автоматически преобразует эти значения и сохраняет их в поле data в виде Base64. То есть stringData нужен в основном для удобства разработчика при создании и обновлении Secret. В самом объекте Secret данные в итоге всегда хранятся в поле data. Кроме того, в одном манифесте можно одновременно использовать и stringData, и data. Если ключи дублируются, приоритет имеет stringData. Например, если username указан и в data, и в stringData, будет использовано значение из stringData, а значение из data будет проигнорировано. Если же ключи разные, в созданном Secret будут доступны все значения. 👉 DevOps Portal

В этом туториале пошагово разбирается полноценная GitOps-настройка на minikube: Argo CD деплоит Go-сервис напрямую из Git, а HPA масштабирует поды под нагрузкой https://medium.com/clerion/kubernetes-gitops-from-scratch-a-hands-on-guide-with-argocd-hpa-and-karpenter-3188a99c7647 👉 DevOps Portal

🎇Главная идея DevSecOps: безопасность перестаёт тормозить разработку. Вместо проверок «после релиза» всё встроено в пайплайн: код проходит SAST, контейнеры сканируются, инфраструктура проверяется на комплайенс. В итоге релизы выходят быстрее и при этом безопаснее. Этому и учит курс DevSecOps от Академии Codeby на практике: ⏺️9 модулей, 48 занятий, 90% практики ⏺️Стек: Docker, Kubernetes, Terraform, Vault, Ansible, Prometheus ⏺️Финальный экзамен в стиле OSCP — только реальные задачи ⏺️Авторы — практики: внедрение Zero Trust, построение SOC, разработка DevSec-инструментов под Burp Suite Инженеры, которые умеют встраивать безопасность в CI/CD, сегодня в дефиците на стыке ИБ и DevOps — компании поняли, что «сначала сделать, потом чинить» обходится дороже. 👉 Старт курса 5 октября ➡️️️Программа и регистрация Бесплатная консультация — @CodebyAcademyBot

В этом туториале пошагово разбирается полноценная настройка GitOps на minikube: Argo CD разворачивает Go-сервис напрямую из Git, а HPA масштабирует поды под нагрузкой ➜ https://itnext.io/sveltos-clusterpromotion-progressive-rollouts-and-the-mistake-that-made-the-architecture-better-a1471b92ee8f 👉 DevOps Portal

Как conntrack обеспечивает работу Kubernetes Services В этом гайде вы разберётесь, как работает conntrack на реальных сценариях Kubernetes-сетей, и поймёте, почему он играет критически важную роль в работе Kubernetes Services, kube-proxy, NAT и DNS-трафика. Вы узнаете: - что такое conntrack и зачем он нужен; - почему Kubernetes Services зависят от него; - как посмотреть таблицу conntrack; - что происходит, когда таблица переполняется; - как диагностировать и устранять исчерпание conntrack в продакшене. Подробный гайд: https://newsletter.devopscube.com/p/conntrack-in-kubernetes 👉 DevOps Portal

‼️У вас 50 алертов‼️ А какой из них реально должен разбудить в 3:00? Когда мониторинг строится вокруг всего, что можно измерить, команда получает много данных — но не обязательно больше понимания. Чтобы нормально разобраться сделали мини-интенсив по SRE На нем вы работаете с надёжностью как с системой: SLI/SLO, error budget, мониторинг, алертинг, incident response и postmortem 👉Посмотреть программу

kubectl tree — плагин для kubectl, который проходит по ownerReferences и выводит полное дерево объектов под Deployment или кастомным ресурсом, чтобы было видно, какой объект что создал. ➜ https://github.com/ahmetb/kubectl-tree 👉 DevOps Portal

⚡️⚡️Инциденты, Kubernetes и мок-собеседования — на DevOops 2026 Уже этой осенью на конференции DevOops 2026 будет пять практических воркшопов, где недостаточно просто слушать. Участники будут расследовать продакшен-инциденты, работать с живой инфраструктурой, собирать Kubernetes-платформу, разбираться с runtime security и проходить техническое мок-собеседование. 📆12–13 октября, Санкт-Петербург + онлайн Здесь важен именно офлайн: эти форматы не будут транслироваться и не попадут в запись. Воркшопы и мастер-классы построены вокруг командной работы, живых стендов, вопросов участников и задач, которые нужно решать прямо в зале. Все подробности — в карточках и на сайте. Если интересны именно эти форматы, нужен офлайн-билет. На месте также можно попасть на вечеринку, посмотреть стенды партнеров и остаться на живые дискуссии после каждого доклада. 🌟По промокоду: loosecode персональные билеты со скидкой. [Купить билет]

Изучайте Linux-сети на практике Новый практический челлендж — потренируйтесь разбираться в сетевой конфигурации Linux-хостов: находить имена интерфейсов, IP- и MAC-адреса, шлюз по умолчанию, а также определять, какие маршруты сервер использует для доступа к разным адресам. https://labs.iximiuz.com/challenges/linux-inspect-network-interfaces-and-routes 👉 DevOps Portal

В iximiuz Labs появился новый сложный челлендж по контейнеризации:

Отладить Go-контейнер, который перестал запускаться после недавнего изменения.

Сможете найти первопричину и исправить сборку? https://labs.iximiuz.com/challenges/fix-go-container-image-broken-by-recent-change 👉 DevOps Portal