DevOps Portal | Linux

Автоматизация платформы не отбирает у вас интересные задачи. Она забирает рутину.

Deckhouse Platform берёт на себя обновление, масштабирование и поддержку инфраструктуры «из коробки». Освободившееся время остаётся вам — на то, что вам действительно нравится.

Обсудите с инженерами Deckhouse, что можно автоматизировать в вашем стеке 👈

Этот кейс показывает, как мигрировать с хрупкой инфраструктуры на базе EC2 на AWS EKS с GitOps через ArgoCD, Jenkins и SonarQube для платформы сокращения ссылок

В результате деплои ускорились на 80%, а инфраструктура получила возможность самовосстановления

➜ https://medium.com/@chi.naedu/from-fragile-vms-to-bulletproof-gitops-modernizing-a-devops-platform-on-aws-eks-81db558cb7d4

👉 DevOps Portal

ИИ-агенты теперь могут работать как отдельные участники команды в GitLab

В SourceCraft появилась возможность подключать автономных ИИ-агентов, которым можно поручать задачи прямо в обсуждениях GitLab.
Агент работает под собственной учетной записью: получает задачу, самостоятельно выполняет ее и возвращает результат на ревью. Если в процессе не хватает данных или требуется согласование, он сам обращается к команде.

Например, таким образом можно поручить агенту разработку или проверку безопасности кода. При этом компании могут подключать и собственных агентов, в том числе созданных в Yandex AI Studio.

Помимо GitLab, взаимодействовать с агентами можно через VS Code, командную строку, мессенджеры и веб-интерфейс SourceCraft.

Анатомия Terraform-проекта

До сих пор путаетесь в Terraform-файлах и структуре директорий?

Вот основные файлы Terraform, с которыми стоит разобраться:
• main.tf: описывает ресурсы и вызовы модулей.
• variables.tf: объявляет входные переменные конфигурации.
• outputs.tf: экспортирует значения ресурсов, например ID и ARN.
• terraform.tfvars: задаёт конкретные значения для объявленных переменных.
• backend.tf: настраивает удалённый бэкенд для хранения state, например S3 или Terraform Cloud.
• modules/: директория с переиспользуемыми компонентами, например сетью и вычислительными ресурсами.
• terraform.lock.hcl: фиксирует выбранные версии провайдеров и их контрольные суммы.
• terraform.tfstate: хранит информацию о ресурсах, которыми управляет Terraform, и их текущем состоянии.

Когда понимаешь структуру проекта, ревью изменений и отладка вывода terraform plan становятся намного проще.

Поэтому, когда подключаетесь к новому проекту или разбираете чужой Terraform-код, сначала изучите структуру, а уже потом запускайте apply.

Вот подробный гайд, который поможет разобраться с Terraform-модулями и тем, как правильно организовать их структуру.

Читать: https://devopscube.com/terraform-module-best-practices/

Примечание: такие имена файлов, как main.tf, variables.tf и backend.tf, — это лишь соглашения по именованию. Terraform считывает все .tf-файлы в рабочей директории как одну конфигурацию.

👉 DevOps Portal

На Stepik вышла программа «DevOps с нуля: от Linux до Kubernetes»

Это комплексная программа из 5 практических курсов по ключевым технологиям DevOps: Linux, Git, Docker, GitLab CI/CD, Kubernetes

Вы последовательно пройдёте путь от работы в Linux и управления кодом через Git до контейнеризации приложений, настройки CI/CD-пайплайнов и развёртывания в Kubernetes.

Что вы изучите:

• работу с Linux и командной строкой
• Git и контроль версий в реальных проектах
• создание Docker-образов и запуск контейнеров
• автоматизацию сборки, тестирования и деплоя в GitLab CI/CD
• развёртывание и управление приложениями в Kubernetes
• сети, хранилища, конфигурации и секреты
• диагностику инфраструктуры и автоматизацию рутинных задач
... и многое другое

Все знания закрепляются на практике с помощью заданий с автопроверкой.

Материал подаётся последовательно и понятным языком: с примерами, схемами и демонстрациями. Во время обучения можно задавать вопросы по урокам и заданиям, получать обратную связь и помощь при возникновении сложностей.

После прохождения программы вы получите сертификат, который можно добавить в резюме.

Скидка 20% на 48 часов: по промокоду DEVOPS20 стоимость всей программы составит 10 392 ₽.

Открыть программу на Stepik

Работа с 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

Как работает 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

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

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

kubectl tree — плагин для kubectl, который проходит по ownerReferences и выводит полное дерево объектов под Deployment или кастомным ресурсом, чтобы было видно, какой объект что создал.

➜ https://github.com/ahmetb/kubectl-tree

👉 DevOps Portal

Изучайте 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