DevOps

Какую функцию выполняет ReplicaSet? Функция ReplicaSet (RS) в Kubernetes заключается в обеспечении стабильного количества экземпляров подов в кластере. RS является основным компонентом Kubernetes, который используется для развертывания Stateless-приложений. Он обеспечивает непрерывную доступность приложения, автоматически запуская новые экземпляры подов в случае их выхода из строя. Без использования RS такие поды пришлось бы запускать вручную, что затруднило бы поддержание доступности приложения для пользователей. Что такое пространство имен (namespaces)? Почему не стоит использовать одно namespace для всех приложений? Пространства имен позволяют разделить кластер на виртуальные группы, внутри которых можно объединять приложения по нужному принципу. Таким образом, создается возможность изолировать различные группы приложений друг от друга. Например, благодаря этой функции можно создать приложение с одинаковым именем в двух разных пространствах. Если использовать только одно пространство имен, которое было задано по умолчанию при запуске кластера, со временем может стать сложно ориентироваться во всех приложениях, запущенных в нем. Группировка приложений в разных пространствах имен упрощает работу: например, можно разместить приложение мониторинга в одном пространстве, а приложения, связанные с информационной безопасностью, в другом. Еще один случай, когда несколько пространств имен могут пригодиться, — это ситуация, когда несколько команд работают с одним кластером. 📲 Мы в MAX #devops #девопс Подпишись 👉@i_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