DevOps Star (Звезда Девопса)

Xeol

Cканер образов контейнеров, SBOM и файловых систем на проверку пакетов на end-of-life (EOL)

https://github.com/xeol-io/xeol

👉 @devops_star

Прокачай свои навыки Kubernetes

Kubernetes — это мощь. Но по-настоящему он раскрывается в руках тех, кто знает, как с ним обращаться.

Хотите уверенно управлять кластерами, настраивать сеть, разруливать инциденты и держать инфраструктуру под контролем? ➡️Тогда вам на курс «Kubernetes Мега» от Слёрма.

На обучении вы: 

👉 Освоите перенос продукта на Kubernetes
👉 Научитесь разворачивать отказоустойчивые кластеры
👉 Ускорите траблшутинг и будете решать инциденты как профи
👉 Повысите стабильность и безопасность инфраструктуры
👉 Настроите автоматическую ротацию сертификатов, автодеплой и защищённое хранение секретов

Это не просто курс. Это путь к 300к/наносек.

Старт — 27 октября, вы как раз успеваете!

Посмотрите программу и забронируйте место ➡️ по ссылке

Talos Linux & VirtualBox: готовим свой Kubernetes

Есть множество путей развернуть свой Kubernetes. Все они разные, выбор зависит от вашего бюджета, от того, какие задачи вы планируете решать, для каких нагрузок и что в конечном итоге вы планируете получить. В этой статье мы быстро пройдёмся по различным способам инсталляции, а затем попробуем развернуть свой K8s кластер на виртуальных машинах, воспользовавшись гипервизором второго типа (VirtualBox). Но это будет не условная Ubuntu, на которую мы будем ставить необходимые компоненты, а целая операционная система, разработанная специально для Kubernetes — Talos Linux!

https://habr.com/ru/articles/825682/

👉 @devops_star

Практическое руководство по Kubernetes: Сетевая политика 🛠️

Сетевые политики Kubernetes представляют собой надежный механизм контроля взаимодействия между подами и другими конечными точками сети. Они необходимы для обеспечения безопасности ваших приложений путем определения правил, определяющих, как поды могут взаимодействовать друг с другом и другими сетевыми ресурсами. В этом практическом руководстве мы рассмотрим основы и продемонстрируем, как реализовать сетевые политики на практическом примере, включающем фронтенд и бэкенд-приложения.

https://medium.com/@muppedaanvesh/a-hands-on-guide-to-kubernetes-network-policy-%EF%B8%8F-041bebe19a23

👉 @devops_star

11 советов по повышению безопасности контейнеров 🔐

1 🔒 Используйте официальные образы

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

2 📦 Регулярно обновляйте образы

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

3 🔍 Сканирование образов на наличие уязвимостей

Используйте такие инструменты, как Clair, Trivy или Anchore, для проверки образов контейнеров на уязвимости перед развертыванием. Сделайте это частью вашего CI/CD pipeline.

4 📜 Следуйте принципу наименьших привилегий

Запускайте контейнеры с минимально необходимыми привилегиями. Избегайте запуска контейнеров от имени root и используйте пространства имен пользователей для разграничения привилегий.

5 🛠️ Используйте средства обеспечения безопасности на этапе выполнения

Используйте инструменты безопасности во время выполнения, такие как Falco или Sysdig Secure, для мониторинга и защиты запущенных контейнеров от угроз и аномалий.

6 🔐 Внедрите сегментацию сети

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

7 📋 Ограничение использования ресурсов

Ограничьте ресурсы (процессор, память), которые могут использовать контейнеры, чтобы предотвратить атаки на исчерпание ресурсов. Используйте квоты и лимиты ресурсов Kubernetes.

8 🛡️ Включение контекстов безопасности

Определите контексты безопасности в платформе оркестровки контейнеров для контроля доступа и разрешений. Используйте PodSecurityPolicies в Kubernetes.

9 🧩 Используйте решения для управления секретами

Безопасное управление и хранение конфиденциальных данных, таких как пароли и ключи API, с помощью таких инструментов, как HashiCorp Vault, AWS Secrets Manager или Kubernetes Secrets.

10 🌐 Регулярные аудиты и проверки на соответствие требованиям

Регулярно проводите аудиты безопасности и проверки на соответствие требованиям, чтобы обеспечить соблюдение политик и стандартов безопасности. Автоматизируйте аудиты с помощью таких инструментов, как kube-bench.

11 🔄 Постоянно обучайте свою команду

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

👉 @devops_star

Kubernetes: контейнеры и «потерянные» сигналы SIGTERM

У нас есть API-сервис с Gunicorn в Kubernetes, который периодически возвращает 502, 503, 504 ошибки.

Я начал его отлаживать и обнаружил странную вещь: в логах не было сообщений о полученном SIGTERM, поэтому я сначала пошел разбираться с Kubernetes - почему он его не отправляет?

https://itnext.io/kubernetes-containers-and-the-lost-sigterm-signals-40007f35759a

👉 @devops_star

Как ускорить релизы и не утонуть в рутине

С ростом компании и числа цифровых продуктов разработка начинает буксовать. Без единого подхода к инфраструктуре скорость падает, а DevOps всё чаще тушат пожары вместо того, чтобы развивать процессы и автоматизацию.

22 октября в 12:00 мск Hilbert Team и Yandex Cloud расскажут,
как выстроить в облаке конвейер разработки, который помогает команде быстрее доставлять продукт — без лишних затрат и выделенной платформенной команды.

В программе:
✔️ Как взять из платформенной инженерии нужное, не строя «монстра»;
✔️ Как использовать облачные технологии для разработки, тестирования и вывода новых решений на рынок;
✔️ Архитектура цифрового конвейера, которая масштабируется без боли;
✔️ Кейсы российских компаний.

Кому будет полезно: руководителям команд разработки и DevOps-отделов, DevOps-инженерам, продактам, архитекторам и всем, кто отвечает за развитие цифровых продуктов.

22 октября, 12:00 мск
Регистрируйтесь на вебинар по ссылке

Мониторинг черных ящиков и котов в мешке через eBPF

Привет! Меня зовут Петр Бобров, в QIWI я отвечаю за отказоустойчивость, расскажу немного историй про сторонних вендоров, у всех они разные. У нас есть карточный процессинг, потому что мы банк, у нас банковская лицензия, проводим много платежей. Еще можно черными ящиками считать и базы данных: кто знает, как там работает Oracle, кто знает, как работает Linux внутри? Думаю, очень немного людей разбирается в этом, как оно работает на низком уровне.

https://habr.com/ru/companies/qiwi/articles/738968/

👉 @devops_star

Глубокое погружение в сетевые технологии Kubernetes

На вебинаре описывается сетевая модель Kubernetes (узлы, поды, сервисы), ее преобразование в сетевые конструкции Linux, интеграция с физической сетью и оркестровка виртуальных сетевых устройств, таких как маршрутизаторы, балансировщики нагрузки и NAT-шлюзы.

https://my.ipspace.net/bin/list?id=Kubernetes#INTRO

👉 @devops_star

Топ-10 распространенных проблем с линтингом Dockerfile

Мы добавили возможность линтинга Docker-файлов по требованию в Depot. В этом посте мы рассмотрим 10 наиболее распространенных проблем с линтингом Dockerfile, которые мы наблюдали в Depot.

https://depot.dev/blog/dockerfile-linting-issues

👉 @devops_star

Вопросы с собеседования

df сообщает о наличии 20 Гб занятого пространства, подсчёт занятого файлами места при помощи du даёт результат в 20 Мб. При каких обстоятельствах может возникнуть описанная ситуация?

Когда файл удален т. к. файловый дескриптор «держит» его.

Ищем файл через:

lsof -a +L1 | grep var | grep httpd

При удалении файла, который в этот момент был «занят» процессом — его имя удаляется, но inode — остаётся в файловой системе до тех пор, пока не завершится процесс, который «держит» этот файл.

Соответственно, что бы «освободить» уже удалённые файлы — необходимо перезапустить процесс, который этот файл держит.

👉 @devops_star

В чем разница между Registry и Repository?

Registry — это сервис хранения и распространения образов, также DockerHub — это Registry по умолчанию. Repository — это набор связанных образов. У них одно и то же имя, но разные метки.


Расскажите об образах Docker, DockerHub, Dockerfile

Образы: файлы, содержащие несколько слоев, используемые для выполнения кода внутри контейнера. Они собираются по инструкциям для получения исполняемой версии приложения. Образы могут ускорить сборку в Docker с помощью кэширования каждого этапа.

DockerHub: сервис для поиска и совместного использования образов контейнеров. Вы можете выгружать туда свои образы, скачивать их оттуда, работать с частными репозиториями образов контейнеров, собирать автоматически образы с помощью GitHub (Bitbucket), а затем закачивать их в DockerHub. Этот сервис предоставляет компания Docker.

Dockerfile: текстовый файл, используемый для сборки образа. Он содержит инструкции и команды по сборке образа. Docker читает их и автоматически собирает образ.

👉 @devops_star

AI уже в терминале, пайплайнах и IDE — теперь это не тренд, а часть ежедневной работы 🤝

Если вы хотите использовать его не для генерации котиков и резюме, а в реальных DevOps-процессах — посмотрите на этот курс

Ребята показывают, как AI помогает инженерам каждый день:
 - генерирует IaC через локальную LLM
 - автоматизирует CI/CD через GitLab API и n8n
 - делает авто-триаж алертов и документацию из действий

Не «генерация ради генерации», а конкретные инструменты: локальная LLM, GitLab API, n8n, RAG-бот.

Всё проверяется кодом и метриками, чтобы AI не ломал пайплайн, а действительно ускорял релизы

После внедрения таких решений MTTR снижается на треть, а релизы проходят стабильнее 👌

📅 Старт 20 октября, всего 20 мест
 Курс «AI в DevOps» →здесь 📍

Рабочие процессы Арго - паттерны, проверенные на продакшене

Argo Workflows представляет собой отличную платформу для автоматизации инфраструктуры и заменил Jenkins в качестве основного инструмента для выполнения запланированных или управляемых событиями задач автоматизации.

За время работы с Argo Workflows мне приходилось убивать кластеры, ломать рабочие процессы и вообще вносить беспорядок в работу. Я также создал множество рабочих процессов, которые нуждались в рефакторинге, поскольку их стало сложно поддерживать.

Цель этой статьи - поделиться некоторыми уроками, которые я извлек, и некоторыми паттернами, которые я разработал, чтобы помочь вам избежать тех же ошибок, которые совершил я.

https://hodgkins.io/blog/argo-workflow-proven-patterns-from-production/

👉 @devops_star

Облако ITENTIS CLOUD: технологии топов, цена без наценки (и живая поддержка!)

Нашли брендовую вещь в надежном маркете на 30% дешевле? Вот и мы так же. 😉

ITENTIS CLOUD — не "бюджетный" вариант. Это ВСЕ те же технологии, что у Яндекса, Mail или VK (VPC, Kubernetes, S3, снимки, автомасштабирование), но...

🔥 ...ЗНАЧИТЕЛЬНО ДЕШЕВЛЕ! 🔥

Зачем платить за бренд? Получите то же самое (а кое-что лучше) и сэкономьте. Не верите? Сравните тарифы! Надежные дата-центры Tier III, как у всех.

И главное — наша поддержка. Вот где мы их РЕАЛЬНО обходим:

💩 У них: очереди, боты, ответ "в течение 24 часов".
😍 У нас: живой, компетентный специалист 24/7. Не бот! Настоящий человек, который РАЗБЕРЕТСЯ. Ответ за минуты. Сложный Kubernetes? Объясним и поможем. Это наш стандарт.

Что вы получаете за меньшие деньги:

1. Та же "начинка": все ключевые технологии (VPC, Kubernetes, S3 и т.д.) — как у топов.
2. Надежность: Tier III, 2FA, шифрование, брандмауэры.
3. Скорость: запуск кластера быстрее доставки пиццы.
4. Простой контроль: интуитивное управление.
5. ГЛАВНОЕ: цена, от которой улыбнетесь + поддержка, которая реально спасает.

"А подвох?" Да нигде!

▶️14 дней БЕСПЛАТНО: протестируйте всё.
▶️БЕСПЛАТНАЯ миграция: перенесем ваши проекты без простоев.
▶️Гарантия возврата: риск — ноль.

‼️ Понравится? Расскажите друзьям! Реферальная программа: за каждого клиента — бонус или скидка. Без мишуры.

Итог: ITENTIS CLOUD = Технологии топов + Честная цена + Человеческая поддержка 24/7.

Хватит переплачивать и ждать ответа! Получите максимум.

👉 Действуйте выгодно:

1. Сравните тарифы: https://itentis.cloud
2. Пишите:
🤖 Telegram-бот: @itentis_bot (Фраза: "Хочу облако дешевле Яндекса!")
✉️ Почта: sales@itentis.ru
3. Скажите: "Читал пост про ЭКОНОМИЮ в облаке!" 🚀(Получите бонус!)
4. Присоединяйтесь: @itentis

https://itentis.cloud Мощное облако. Честная цена. Люди на связи.

Реклама. ООО "АВАНГАРД", ОГРН 1107746046550, erid: 2VtzqvR4orm

Расскажите, как вы будете запускать приложение в Kubernetes, если из инструментов у вас только kubectl?

Общий процесс запуска приложения в Kubernetes выглядит следующим образом:

1. Сначала необходимо упаковать приложение в контейнер.
2. Далее запускаем контейнер в виде реплик с использованием Deployment.
3. Для доступности приложения в интернете и возможности подключения к нему настраиваем сервис LoadBalancer, который присваивает публичный IP-адрес и позволяет подключаться к кластеру извне.
4. Для маршрутизации трафика через балансировщик создаем Ingress в кластере, описывающий правила маршрутизации, и запускаем Ingress-контроллер.

Все эти шаги можно выполнить с помощью kubectl, используя командную строку. Это императивный способ управления Kubernetes, когда мы явно указываем, что нужно сделать.

В промышленной эксплуатации часто используется декларативный подход, при котором мы описываем желаемое состояние в манифестах, и Kubernetes самостоятельно принимает решения о необходимых действиях. Затем мы применяем эти манифесты с помощью команды kubectl apply.


Terraform Backend. Какой лучше?

AWS S3 — Standard (с блокировкой через DynamoDB). Сохраняет состояние в виде заданного ключа в заданном сегменте на Amazon S3. Этот бэкэнд также поддерживает блокировку состояния и проверку согласованности через DynamoDB.

terraform enterprise — Standard (без блокировки).

etcd — Standard (без блокировки). Сохраняет состояние в etcd 2.x по заданному пути.

etcdv3 — Standard (с блокировкой). Сохраняет состояние в хранилище etcd в виде K/V с заданным префиксом.

gcs — Standard (с блокировкой). Сохраняет состояние как объект в настраиваемом префиксе в заданном сегменте в Google Cloud Storage (GCS). Этот бэкэнд также поддерживает блокировку состояния.

Gitlab Terraform state (с блокировкой). Хранит состояние в Gitlab Terraform state хранилище, используя HTTP протокол и права Gitlab для доступа.

Существуют также и другие Backend для Terraform.

👉 @devops_star

Контейнеризация

От Docker до Kubernetes: историческая ретроспектива
Введение в Docker
Введение в Kubernetes. Часть 1. Установка кластера
Введение в Kubernetes. Часть 2. Поды и сервисы
Введение в Kubernetes. Часть 3. Горизонтальное маштабирование.
Введение в Kubernetes. Часть 4. Отказоустойчивость для клиентов
Введение в Kubernetes. Часть 5. Интеграция с NFS
Что такое операторы в Kubernetes?

источник

👉 @devops_star