🎇Главная идея 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://medium.com/clerion/kubernetes-gitops-from-scratch-a-hands-on-guide-with-argocd-hpa-and-karpenter-3188a99c7647

👉 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

В этом туториале показано, как KEDA масштабирует ворклоады на основе глубины очереди, а не загрузки CPU, на полноценном примере с RabbitMQ: установка, настройка TriggerAuthentication, ScaledObject и нагрузочный тест, который подтверждает, что масштабирование работает:

https://the-devops-engineer.medium.com/kubernetes-keda-autoscaling-scale-smarter-not-harder-d186da29175a

👉 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

DNS 101: как резолвятся публичные, внутренние и локальные хостнеймы

В большинстве случаев при работе с curl или ssh вы указываете хостнейм.

Когда сетевой запрос использует имя вместо IP-адреса, сначала это имя нужно зарезолвить.

Как именно это происходит:
https://labs.iximiuz.com/challenges/linux-resolve-hostnames-with-hosts-file-and-dns

👉 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

Kubernetes Goat

С помощью этого репозитория можно прокачать навыки тестирования безопасности кубера

(Там есть готовая инфраструктура, которая разворачивается по скрипту)

https://github.com/madhuakula/kubernetes-goat

👉 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

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

Анатомия 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

Этот кейс показывает, как мигрировать с хрупкой инфраструктуры на базе 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