DevOps

🚑 HEALTHCHECK: Спасательный круг или выстрел в ногу? Продолжаем тему стабильности. Сегодня про Healthchecks (в Docker) и Probes (в K8s). Казалось бы, что сложного? Написал curl -f http://localhost/ || exit 1 и пошел пить кофе. Но именно такие "простые" решения часто становятся причиной того, что ваш прод лежит, хотя нагрузка детская. Разберем две крайности и как делать правильно. ❌ Ошибка №1: "Зомби-апокалипсис" (Слишком слабый чек) Вы проверяете только то, что процесс веб-сервера запущен и порт слушается. 🔘Сценарий: У приложения отвалился коннект к БД (pool exhaustion), или случился дедлок внутри кода. 🔘Итог: Хелсчек проходит (порт-то открыт!), балансировщик продолжает лить трафик на под, а пользователи получают 500-ки. 🔘Лечение: Чек должен проверять работоспособность логики, а не просто наличие процесса. ❌ Ошибка №2: "Эффект Домино" (Слишком жадный чек) Вы решили быть умными и в /health эндпоинт засунули проверку коннекта к Базе, Редису и S3. 🔘Сценарий: База данных немного приуныла (медленные запросы). 🔘Итог: Хелсчеки всех 50 подов начинают тайм-аутить. Kubernetes думает: "Ага, поды сдохли!" и начинает их перезагружать. 🔘Финал: Все поды рестартуют одновременно, ломятся устанавливать соединения к и так лежащей базе и добивают её окончательно. Congratulations, you played yourself. ✅ Как делать правильно: Liveness vs Readiness В Kubernetes (да и в грамотном Docker Compose) эти понятия разделены. Это фундамент. 1. Liveness Probe (Я жив?) 🔘Цель: Понять, не завис ли процесс намертво. 🔘Действие при сбое: РЕСТАРТ контейнера. 🔘Что проверять: Очень легкий запрос. "Я могу отвечать на HTTP?". Не трогайте тут базу данных! Если база лежит, рестарт бэкенда не поможет ей подняться. 2. Readiness Probe (Я готов работать?) 🔘Цель: Понять, можно ли пускать на меня трафик. 🔘Действие при сбое: УБРАТЬ из балансировки (не убивать!). 🔘Что проверять: Вот тут проверяем зависимости. Есть коннект к БД? Прогрелся кэш? Если нет, просто временно не шлите на меня юзеров. 📝 Пример (K8s Manifest):

livenessProbe:
  httpGet:
    path: /health/live # Максимально тупой ответ 200 OK
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

readinessProbe:
  httpGet:
    path: /health/ready # Проверка БД, очередей и т.д.
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 10
  failureThreshold: 3

💡 Главный совет Никогда не делайте зависимость Liveness-пробы от внешних сервисов. Если у вас упал сторонний API, ваш сервис не должен уходить в циклическую перезагрузку. Он должен просто перестать говорить, что он Ready, или отдавать ошибку юзеру, оставаясь "живым". #k8s #devops #fails #stability #bestpractices 📲 Мы в MAX #devops #девопс Подпишись 👉@i_DevOps

🎥 Вебинар: Выбор между Serverless и Kubernetes для AI-ворклоадов: как определить оптимальную платформу под задачу На открытом уроке рассмотрим: - В чем различаются Serverless-подходы и Kubernetes при работе с AI-ворклоадами; - Какие преимущества и ограничения есть у каждого подхода с точки зрения масштабируемости, стоимости и сложности эксплуатации; - Какие трейдоффы нужно учитывать при выборе платформы: холодный старт, управление состоянием, поддержка GPU; - Как обосновывать выбор архитектуры для разных AI-сценариев на практическом воркшопе. После занятия вы будете знать: - Как сравнивать Serverless и Kubernetes для различных AI-задач; - Как выбирать платформу оркестрации в зависимости от требований к нагрузке, бюджету и архитектуре решения; - Как учитывать ключевые технические ограничения при проектировании AI-инфраструктуры; - Как аргументированно обосновывать выбор платформы для задач масштабирования, потоковой обработки данных и построения гибридных сред. ⚠ Открытый урок проходит в преддверии старта курса «ИИ-архитектор». 👉Для участия зарегистрируйтесь: https://vk.cc/cZJGfr Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

SnapScheduler — это контроллер Kubernetes, который автоматически создает снапшоты PVC (PersistentVolumeClaim) по расписанию, используя встроенный механизм VolumeSnapshot. Он не зависит от CSI-драйвера, пока тот поддерживает VolumeSnapshot, и работает с любым сторедж-классом, поддерживающим снапшоты. Основные возможности: - Создание снапшотов PVC по расписанию (cron). - Поддержка нескольких расписаний для одного PVC. - Возможность настройки политики хранения (retention policy). - Не требует изменений в приложении или манифестах PVC. Как это работает: Вы создаете ресурс SnapshotSchedule, в котором указываете: - Селектор PVC. - Cron-расписание. - Максимальное количество снапшотов для хранения. Контроллер следит за расписанием и создает VolumeSnapshot объекты автоматически. Пример использования:

apiVersion: snapscheduler.backube/v1
kind: SnapshotSchedule
metadata:
  name: example-schedule
spec:
  schedule: "0 */6 * * *"
  snapshotTemplate:
    labels:
      createdBy: snapscheduler
  pvcSelector:
    matchLabels:
      snapshot: "true"
  retention:
    maxCount: 5

Такой манифест будет создавать снапшоты каждые 6 часов для всех PVC с лейблом snapshot=true, и хранить максимум 5 последних. https://github.com/backube/snapscheduler 📲 Мы в MAX #devops #девопс Подпишись 👉@i_DevOps

Docker для начинающих: простое развертывание приложения за несколько шагов Всем привет! Для своей первой статьи я решил выбрать проблему, с которой сам столкнулся при изучении Java и попытке упаковки приложения в докер-контейнер. К сожалению не нашел ни одной исчерпывающей статьи, как это делать, поэтому решил написать свою. Начну, пожалуй, с самого сервиса. Я написал достаточно простое веб-приложение на стеке - Java, Spring, Maven, REST, HTTP, Hibernate, Postgresql, JSP/JSTL. Пока приложение представлено достаточно в сыром виде, но для понимания, как оно упаковывается в контейнер, вполне подойдет. Если вкратце, то это сервис для голосования за лучший ресторан, где можно зарегистрироваться, добавить ресторан, его описание, оставить отзыв и проставить рейтинг. Также, в зависимости от роли, можно посмотреть информацию о пользователях и редактировать ее. https://habr.com/ru/articles/888540/ 📲 Мы в MAX #devops #девопс Подпишись 👉@i_DevOps

erid: 2W5zFHvrYfK Бесплатный урок: доверь прод ИИ. Испугались? Не бойтесь, мы друг ⭐Слёрм запускает БЕСПЛАТНУЮ вечернюю школу «ИИ для инженеров: польза и риски». Это серия онлайн-занятий о том, как использовать ИИ в инженерной работе осознанно, безопасно и с понятной пользой. 🧩 Будем разбирать реальные инженерные сценарии: — как ИИ помогает DevOps-, SRE- и infrastructure-командам — как использовать LLM для алёртов, инцидентов, логов, тикетов и документации — где ИИ реально экономит время, а где создаёт новые риски — как проверять результат модели и не ловить галлюцинации в проде — что делать с безопасностью, данными, compliance и юридическими ограничениями — как встроить ИИ в рабочий процесс, а не просто иногда спрашивать у него команды. 🧩 В программе — шесть онлайн-занятий с практиками из ИТ: — ИИ для разбора метрик и шумных алёртов — автофикс проблем прода с ИИ — ИИ-агенты в бизнес-задачах — юридические риски использования ИИ — LLM в SOC и борьба с alert fatigue — инженерное мышление в эпоху LLM Школа подойдёт DevOps-, SRE-, infrastructure-, platform- и security-инженерам, а также всем, кто уже пробовал ИИ в работе и хочет понять, как использовать его системнее и безопаснее. 📅 Старт — 21 июля. 💸 Участие бесплатное, занятия проходят онлайн 👉🏻 Узнать подробнее и зарегистрироваться в боте

Это репозиторий aws2tf от AWS Samples, предназначенный для автоматического преобразования существующих ресурсов AWS в код Terraform. Он может помочь экспортировать инфраструктуру AWS в виде кода Terraform, что полезно для управления IaC (Infrastructure as Code). Основные возможности aws2tf: - Генерация Terraform-кода на основе существующей AWS-инфраструктуры. - Поддержка множества сервисов AWS. - Автоматическое создание зависимостей между ресурсами. - Упрощение миграции и управления конфигурацией. https://github.com/aws-samples/aws2tf 📲 Мы в MAX #devops #девопс Подпишись 👉@i_DevOps

🐳 Хватит тащить curl и vim в продакшн! (Используем Ephemeral Containers) Салют, коллеги, всех с прошедшими праздниками! 👋 Сколько раз я видел Dockerfile, который начинается за здравие (FROM alpine), а заканчивается установкой половины интернета: apk add curl vim net-tools bind-tools...? Аргумент всегда один: "Ну мне же надо как-то дебажить, если под отвалится!" В итоге мы получаем: 1. Раздутый образ. (Платим за сторадж и трафик). 2. Дыру в безопасности. (Хакер, попавший в контейнер, скажет спасибо за curl и nmap, любезно оставленные вами). Правильный путь - это Distroless образы или минимальный Alpine, где нет даже шелла. А для дебага мы используем Ephemeral Containers (эфемерные контейнеры). 🛠 Как это работает? В Kubernetes (начиная с v1.25 это уже стабильная фича) вы можете "подселить" временный контейнер в работающий Pod. Он будет делить с подом пространство имен процессов (PID) и иногда сети, но файловая система у него будет своя. То есть: ваш прод-контейнер остается чистым, а дебаг-тулзы прилетают только по требованию. 🔥 Практика: kubectl debug Допустим, у вас есть "глухой" под my-app, в котором нет ничего, кроме бинарника приложения. Вам нужно проверить сеть. Вместо того чтобы пересобирать образ, делаем так:

kubectl debug -it my-app \
  --image=nicolaka/netshoot \
  --target=my-app-container

Разберем магию: 🔘 --image=nicolaka/netshoot: Мой любимый образ для траблшутинга. Там есть ВСЁ: tcpdump, curl, dig, iperf, mtr. 🔘 --target: Указываем, к какому контейнеру в поде подключиться (важно, чтобы видеть процессы друг друга). Теперь вы внутри пода, но со швейцарским ножом в руках. Проверили коннект до базы, сняли дамп трафика, вышли и эфемерный контейнер исчез. Чисто, красиво, секьюрно. 🛡 💡 А если я не в K8s? Если вы сидите на чистом Docker, похожий трюк делается через --pid и --network:

docker run -it --rm \
  --network container:my-prod-container \
  --pid container:my-prod-container \
  nicolaka/netshoot

Итог: Перестаньте бояться Distroless образов. Инструментарий для внешнего дебага уже давно вырос. 📲 Мы в MAX #k8s #docker #security #tips #debug Подпишись 👉@i_DevOps

Пакетная фильтрация в Linux Бесконтекстная пакетная фильтрация (iptables): stateless Контекстная пакетная фильтрация (iptables): stateful источник 📲 Мы в MAX #devops #девопс Подпишись 👉@i_DevOps

Проект dockur/windows позволяет запускать Windows внутри контейнера Docker. Он предоставляет такие возможности, как загрузка ISO-образов, ускорение с помощью KVM и веб-интерфейс для просмотра. Основные особенности: - Загрузчик ISO-образов - Аппаратное ускорение через KVM - Веб-интерфейс для доступа Пример использования с Docker Compose:

services:
  windows:
    image: dockurr/windows
    container_name: windows
    environment:
      VERSION: "11"
    devices:
      - /dev/kvm
      - /dev/net/tun
    cap_add:
      - NET_ADMIN
    ports:
      - 8006:8006
      - 3389:3389/tcp
      - 3389:3389/udp
    restart: always
    stop_grace_period: 2m

Пример использования с Docker CLI:

docker run -it --rm -p 8006:8006 --device=/dev/kvm --device=/dev/net/tun --cap-add NET_ADMIN --stop-timeout 120 dockurr/windows

https://github.com/dockur/windows 📲 Мы в MAX #devops #девопс Подпишись 👉@i_DevOps

📌Docker Удаление промежуточных образов без тэгов: docker rmi $(docker images --filter "dangling=true" -q --no-trunc) Мягко перезапустить контейнер: docker kill --signal="USR1" <yourcontainer_name> Список контейнеров: docker ps -a Подключиться к контейнеру: docker exec -it container_name bash Остановить все контейнеры: docker stop $(docker ps -a -q) Удалить все контейнеры, из которых вышли: docker rm -v $(docker ps -aq -f status=exited) Удалить образ: docker rmi image_name Создать образ: docker build -t image_name Удалить все неиспользуемые тома: docker volume prune Подключиться под рутом в контейнер Alpine: docker exec -it --user root alpine-container bash 📲 Мы в MAX #devops #девопс Подпишись 👉@i_DevOps

Ingress-nginx уходит в прошлое. С марта 2026 поддержка прекратилась. А что вместо него? Предлагаем посмотреть на Gateway API, новый стандарт Kubernetes SIG. 23 июля в 17:00 старший SRE-инженер MWS Cloud Евгений Макеев на практике покажет: ⚫️ чем маршрутизация Gateway API отличается от Ingress ⚫️ как выбрать контроллер ⚫️ как установить Gateway API в Managed Kubernetes ⚫️ как настроить безопасное подключение через TLS-сертификат Будет полезно для DevOps, платформенным инженерам и разработчикам. Регистрируйтесь по ссылке

Шпаргалка по Kubernetes 1. Основные понятия 🔘Pod – наименьшая единица развертывания, содержит один или несколько контейнеров. 🔘Deployment – контроллер, который управляет репликами Pod’ов и их обновлением. 🔘Service – абстракция, предоставляющая доступ к Pod’ам (ClusterIP, NodePort, LoadBalancer). 🔘ConfigMap – хранит конфигурационные данные в виде ключ-значение. 🔘Secret – безопасное хранилище для конфиденциальных данных (пароли, токены). 🔘PersistentVolume (PV) – абстракция для хранения данных. 🔘PersistentVolumeClaim (PVC) – запрос на использование хранилища (PV). 🔘Namespace – логическое разделение ресурсов в кластере. 🔘Ingress – объект, предоставляющий доступ к сервисам внутри кластера через HTTP/HTTPS. 2. Основные команды kubectl Работа с контекстом kubectl config get-contexts # Список контекстов kubectl config use-context <name> # Переключение контекста kubectl config set-context <name> --namespace=<namespace> # Установить namespace по умолчанию Работа с ресурсами kubectl get pods # Список Pod'ов kubectl get deployments # Список Deployment'ов kubectl get services # Список Service'ов kubectl get nodes # Список узлов kubectl get namespaces # Список namespace'ов kubectl get events # Лог событий kubectl describe pod <pod-name> # Подробная информация о Pod kubectl logs <pod-name> # Логи Pod kubectl exec -it <pod-name> -- /bin/sh # Зайти внутрь контейнера Создание и удаление объектов kubectl apply -f <file>.yaml # Применить манифест kubectl delete -f <file>.yaml # Удалить объект kubectl delete pod <pod-name> # Удалить Pod kubectl delete deployment <deploy-name> # Удалить Deployment 3. Пример манифестов Простой Pod apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: my-container image: nginx ports: - containerPort: 80 Deployment apiVersion: apps/v1 kind: Deployment metadata: name: my-deployment spec: replicas: 3 selector: matchLabels: app: my-app template: metadata: labels: app: my-app spec: containers: - name: my-container image: nginx ports: - containerPort: 80 Service (NodePort) apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: my-app ports: - protocol: TCP port: 80 targetPort: 80 nodePort: 30080 type: NodePort Ingress apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress spec: rules: - host: example.com http: paths: - path: / pathType: Prefix backend: service: name: my-service port: number: 80 4. Полезные команды kubectl top pod # Мониторинг использования CPU/RAM Pod'ов kubectl top node # Мониторинг узлов kubectl rollout status deployment <deploy-name> # Статус развертывания kubectl rollout undo deployment <deploy-name> # Откат изменений kubectl autoscale deployment <deploy-name> --min=2 --max=10 --cpu-percent=80 # Авто-масштабирование 5. Отладка и устранение проблем kubectl get pods --all-namespaces # Проверить состояние всех Pod'ов kubectl describe pod <pod-name> # Подробности о Pod kubectl logs <pod-name> # Логи контейнера kubectl logs <pod-name> -p # Логи завершившегося контейнера kubectl exec -it <pod-name> -- /bin/sh # Подключение внутрь контейнера kubectl get events --sort-by=.metadata.creationTimestamp # Последние события 📲 Мы в MAX #devops #девопс Подпишись 👉@i_DevOps

Я SRE-инженер, и ночные алерты — часть моей работы. Один из таких прилетел в 2:13:

latency API выросла почти в 10 раз.

Первая мысль — приложение. Открываю дашборды: часть метрик зелёная, часть ничего не объясняет. Иду в логи, потом в трассировки, потом проверяю инфраструктуру. Гипотез всё больше, времени всё меньше. Бизнес теряет деньги, а я всё ещё собираю контекст вручную. В итоге источник оказался не в API, а в поде базы данных: резко выросло потребление IOPS из-за тяжёлого запроса. В старой схеме я бы ещё долго переключался между системами и выяснял, какие сервисы затронуты. С Deckhouse Observability Platform (DOP) картина другая: я вижу инцидент в разрезе инфраструктуры — узел, под, сервис, зависимости, признаки деградации и связь с бизнес-сервисом. Платформа не делает работу за инженера, но помогает быстрее понять, где искать причину. 17 июля в 12:00 будет вебинар, где технический директор продукта DOP покажет такой сценарий подробнее — от алерта до первопричины. А ещё продемонстрирует AI-ассистента, которыйнаходит причину инцидента за вас. 👉 Зарегистрироваться бесплатно

Pipeline CI/CD, объясненный простыми словами Раздел 1 - SDLC с CI/CD Жизненный цикл разработки программного обеспечения (SDLC) состоит из нескольких ключевых этапов: разработка, тестирование, развертывание и сопровождение. CI/CD автоматизирует и интегрирует эти этапы, чтобы обеспечить более быстрые и надежные релизы. Когда код размещается в git-репозитории, он запускает автоматизированный процесс сборки и тестирования. Для проверки кода запускаются сквозные (e2e) тесты. Если тесты пройдены, код может быть автоматически развернут на этапе staging/продакшен. Если обнаружены проблемы, код возвращается в разработку для исправления ошибок. Такая автоматизация обеспечивает быструю обратную связь с разработчиками и снижает риск появления ошибок в продакшене. Раздел 2 - Разница между CI и CD Непрерывная интеграция (CI) автоматизирует процесс сборки, тестирования и слияния. Она запускает тесты при коммите кода, чтобы обнаружить проблемы интеграции на ранней стадии. Это стимулирует частые коммиты кода и быструю обратную связь. Continuous Delivery (CD) автоматизирует процессы выпуска, такие как изменение инфраструктуры и развертывание. Она обеспечивает надежный выпуск программного обеспечения в любое время благодаря автоматизированным рабочим процессам. CD также может автоматизировать ручное тестирование и этапы утверждения, необходимые перед развертыванием продакшена. Раздел 3 - CI/CD Pipeline Типичный pipeline CI/CD состоит из нескольких взаимосвязанных этапов: - Разработчик коммитит изменения кода в системе контроля исходного кода - CI-сервер обнаруживает изменения и запускает сборку - Код компилируется, тестируется (модульные, интеграционные тесты) - Результаты тестирования сообщаются разработчику - При успешном завершении артефакты развертываются в среде staging. - Дальнейшее тестирование может быть проведено в среде staging перед выпуском. - Система CD развертывает одобренные изменения в продакшене 📲 Мы в MAX #devops #девопс Подпишись 👉@i_DevOps

🤖У нас есть ИИ дома Узнайте, как запустить корпоративный ИИ в собственном контуре за 2 недели Не готовы мириться с ограничениями и дырами в безопасности при использовании публичных ИИ-сервисов, но разворачивать собственную инфраструктуру для инференса долго и тяжело? Присоединяйтесь к вебинару от Selectel и узнайте, как быстро запускать и масштабировать ИИ в собственном контуре без крупных капитальных затрат. В программе вебинара: 🔹Модели развертывания ИИ-инфраструктуры и причины выбора решений на собственной площадке. 🔹Обзор возможностей и сценариев применения нового сервиса AIBox от Selectel, Yandex Cloud и Metamentor — развертывания локального ИИ в контуре клиента на базе серверов Selectel. 🔹Разбор реальных бизнес-кейсов. 📍 Онлайн ⏰ 23 июля в 12:00 Регистрируйтесь и ускорьте внедрение ИИ в компании ➡️ https://slc.tl/rm0gi Больше мероприятий для ИТ-специалистов в канале @selectel_events. Подписывайтесь! Реклама. АО "Селектел". erid:2W5zFGYwGhP

🔥 Как снизить Latency в Kubernetes? 🔥 Высокая задержка (latency) в Kubernetes может стать настоящей головной болью для DevOps-инженера. Давайте разберем, какие ключевые настройки помогут снизить задержку и ускорить ваш кластер! 🚀 1. Настройка Kube-Proxy Если используете iptables-режим, попробуйте переключиться на IPVS:

kubectl edit configmap -n kube-system kube-proxy

Установите mode: "ipvs". Это значительно улучшает балансировку нагрузки и снижает задержку при обработке запросов. 🚀 2. Подключение eBPF (Cilium) Классические iptables могут быть узким местом. Попробуйте Cilium с eBPF, который обеспечивает более быструю маршрутизацию:

helm install cilium cilium/cilium --namespace kube-system

🚀 3. Использование NodeLocal DNSCache DNS-запросы — частая причина высокой задержки. Включите локальный кэш:

kubectl apply -f https://k8s.io/examples/admin/dns/nodelocaldns.yaml

Это уменьшит нагрузку на CoreDNS и ускорит обработку запросов. 🚀 4. Tuning TCP (sysctl) Настройте TCP-параметры для более быстрой передачи данных:

sysctl -w net.core.somaxconn=1024
sysctl -w net.ipv4.tcp_tw_reuse=1
sysctl -w net.ipv4.tcp_max_syn_backlog=8192

Эти параметры помогут лучше обрабатывать соединения и снижать задержку. 🚀 5. Использование Multi-NIC и CNI-плагинов Если у вас высокий сетевой трафик, попробуйте Multus CNI для распределения нагрузки между несколькими сетевыми интерфейсами. 📲 Мы в MAX #devops #девопс Подпишись 👉@i_DevOps

Garnet — это удалённое кэш-хранилище от Microsoft Research, обеспечивающее высокую производительность (пропускную способность и задержку), масштабируемость, хранение, восстановление, шардирование кластера, миграцию ключей и функции репликации. Garnet может работать с существующими клиентами Redis. Основные возможности: - Высокая производительность: миллионы операций в секунду с минимальной задержкой. - Масштабируемость: поддержка горизонтального масштабирования. - Оптимизация работы с памятью: эффективное использование DRAM и SSD. Этот проект может стать серьезным конкурентом Redis и Memcached в сфере облачных сервисов. https://github.com/microsoft/garnet 📲 Мы в MAX #devops #девопс Подпишись 👉@i_DevOps

🚀 CI/CD: Как не устроить себе ад 🚀 Автоматизация деплоя – это must-have. Но сколько раз ты видел, как CI/CD ломает прод? Разберём ключевые моменты, чтобы не наступать на грабли. ✅ Грамотный пайплайн 1️⃣ Lint & Code Style – форматируй код перед билдами (Prettier, Black, ESLint). 2️⃣ Тесты – без них CI/CD превращается в русскую рулетку. Покрываем юнит и интеграцией. 3️⃣ Security Checks – SAST, DAST, секреты в коде (Trivy, Snyk, GitLeaks). 4️⃣ Билд образов – минимизируем размер, убираем уязвимости. 5️⃣ Деплой – делаем blue-green или canary, чтобы не убить прод сразу. ✅ Выбор инструментов - GitHub Actions / GitLab CI – удобно, если уже сидишь на этих платформах. - ArgoCD / Flux – GitOps для Kubernetes. - Jenkins – старый, но всё ещё мощный, если его правильно готовить. - Tekton – если хочешь true cloud-native CI/CD. ✅ Ошибки, которые убьют прод ⚠️ Деплой без тестов – поздравляю, у тебя теперь ручное QA на проде. ⚠️ Хранение секретов в репо – топ-1 причина утечек. Vault, SealedSecrets, Doppler. ⚠️ Отсутствие Rollback – если нет возможности быстро откатиться, ты в опасности. 🔥 Вывод: CI/CD – это не просто кнопка "деплой". Это стратегия, которую надо строить с умом. Инвестируй в тесты, автоматизацию и безопасность, и будет тебе стабильность. 📲 Мы в MAX #devops #девопс Подпишись 👉@i_DevOps

🚀 Как правильно организовать CI/CD в Kubernetes Если деплой в кластер до сих пор выглядит как «собрал образ руками - накатил kubectl apply - помолился», пора это менять. Разбираем, из чего должен состоять нормальный CI/CD-пайплайн для K8s. 1. Разделяйте CI и CD CI (сборка, тесты, линт, сборка образа) и CD (доставка в кластер) - это разные зоны ответственности. Смешивать их в один монолитный скрипт - путь к боли. CI живёт в GitHub Actions / GitLab CI / Jenkins, а за CD лучше отвечает отдельный инструмент. 2. GitOps - ваш друг Вместо того чтобы пайплайн напрямую пушил изменения в кластер, используйте GitOps-подход: Argo CD или Flux следят за Git-репозиторием с манифестами и сами синхронизируют состояние кластера. Плюсы: — вся история изменений в Git; — откат = git revert; — кластер не нужно пускать в CI-раннер с полными правами. 3. Отдельный репозиторий для манифестов Код приложения и его K8s-манифесты (или Helm-чарты/Kustomize-оверлеи) стоит держать раздельно. CI-пайплайн после сборки образа просто обновляет тег в репозитории с манифестами - а дальше в дело вступает GitOps-контроллер. 4. Иммутабельные образы и семантические теги Никаких latest в проде. Тегируйте образы по SHA коммита или семверу — это даёт трассируемость и предсказуемость. 5. Progressive delivery Canary- и blue-green-деплои через Argo Rollouts или Flagger снижают риск раскатки. Добавьте автоматический анализ метрик (Prometheus) - и плохой релиз откатится сам, без участия человека. 6. Секреты - не в манифестах External Secrets Operator, Sealed Secrets или Vault - выбирайте, но никогда не коммитьте секреты в открытом виде, даже в «приватный» репозиторий. 7. Тестируйте манифесты до применения kubeval, conftest (OPA), kube-score - валидируйте YAML и политики безопасности ещё на этапе CI, а не когда под уже упал в проде. 8. Отдельные пайплайны под окружения Dev - быстрый автодеплой на каждый коммит. Staging - деплой по мержу в основную ветку. Prod - только по тегу/релизу, с ручным approval-гейтом. Итог: связка CI (сборка + тесты) → registry → Git-репозиторий манифестов → GitOps-контроллер (Argo CD/Flux) → progressive delivery - это тот самый «правильный» CI/CD для Kubernetes, который не превращается в источник инцидентов. Какой стек используете вы - Argo CD, Flux или что-то своё? 👇 📲 Мы в MAX #devops #девопс Подпишись 👉@i_DevOps

🚀 GitOps: Почему DevOps больше не будет прежним GitOps – это не просто модное слово, а подход, который меняет игру в управлении инфраструктурой. Почему? Давай разберёмся! 🔹 1. Вся инфраструктура как код Вместо ручного изменения конфигурации – все в Git. Хочешь новый сервис или обновление? Открыл Pull Request, проверил, замерджил – и всё развернулось автоматически. 🔹 2. Автоматическое применение изменений Git становится единственным источником правды (SSOT). Если что-то изменилось в репозитории – операционные изменения автоматически применяются в инфраструктуре. 🔹 3. Быстрое восстановление Если что-то сломалось, просто откатываешь коммит в Git, и система сама приводит всё в правильное состояние. 🔹 4. Аудит и безопасность Любое изменение фиксируется. Можно посмотреть, кто что сделал, когда и зачем – плюс автоматический контроль доступа через Git-платформу. 🔹 5. Простота масштабирования Добавить новый кластер или окружение? Просто создать новый файл в Git и всё развернётся само. 🔥 Топ-3 инструмента для GitOps ✅ ArgoCD – управление Kubernetes-кластерами через Git. ✅ FluxCD – лёгкое и гибкое GitOps-решение для Kubernetes. ✅ Terraform + Atlantis – автоматическое применение Terraform-конфигов по PR. GitOps – это про контроль, скорость и удобство. Если ты всё ещё делаешь kubectl apply -f, самое время задуматься! 📲 Мы в MAX #devops #девопс Подпишись 👉@i_DevOps