Addon Controller

Sveltos Addon Controller позволяет пользователям применять Kubernetes-манифесты к любым кластерам, управляемым Sveltos. Это может быть сделано следующими способами:

- Добавляя YAML-файлы с Kubernetes-ресурсами в ConfigMap или Secret.
- Указывая URL с YAML-ресурсами.
- Указывая Helm-чарт.

Addon Controller – это контроллер Kubernetes, который работает в управляющем кластере (management cluster). Он следит за созданием и обновлением объектов Addon, а также применяет соответствующие манифесты в целевых (managed) кластерах, на которые ссылается Addon.

Возможности

- Поддержка ConfigMap, Secret, URL и Helm-чартов.
- Поддержка переменных через ClusterProfile и ClusterSummary.
- Возможность динамически применять или удалять аддоны при изменении кластера или его свойств.
- Возможность настройки приоритетов применения ресурсов.
- Поддержка зависимостей между ресурсами.
- Поддержка dry-run и прерывания применения при ошибке.

Архитектура

1. Пользователь создает объект ClusterProfile, в котором указывает критерии выбора кластеров.
2. Для каждого подходящего кластера создается объект ClusterSummary, который содержит список Addon объектов.
3. Addon Controller применяет ресурсы, указанные в Addon, к каждому целевому кластеру.


https://github.com/projectsveltos/addon-controller?tab=readme-ov-file

#devops #девопс

Подпишись 👉@i_DevOps

Освойте Linux с Selectel
 
Вы начинающий DevOps-инженер, системный администратор или разработчик? Или только думаете над тем, чтобы начать освоение Linux?
 
Selectel запускает бесплатный курс «Администрирование Linux с нуля». Проходите в комфортном для себя темпе и проверяйте полученные знания на реальных задачах.
 
Чему вы научитесь:
 
– Управлять пакетами и обновлениями программного обеспечения
– Настраивать сети, SSH-соединения и мониторинг системы
– Управлять пользователями, файлами и правами доступа
– Работать с командной строкой Linux и основными утилитами
– Анализировать логи и устранять инциденты
 
Зарегистрируйтесь на курс «Администрирование Linux с нуля» по ссылке
 
Реклама. АО «Селектел», ИНН 7810962785, ERID: 2Vtzqv2HnyP

Как настроить автоматический откат в Ansible

Петя запускает плейбук, чтобы обновить конфигурацию Nginx — и ломает сайт. В конфиге ошибка, сервис не стартует.

Ansible не умеет откатывать изменения сам. Но есть способ настроить автоматический откат — с помощью блоков block, rescue и always.

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

#devops #девопс

Подпишись 👉@i_DevOps

Запускаем Sentry в Kubernetes в Яндекс облаке и храним Nodestore в S3

Sentry — это инструмент для отслеживания ошибок и производительности приложений в реальном времени.

Кратко о Sentry: что это, зачем он нужен
- Отслеживает баги и exceptions в бекенд, веб и мобильных приложениях.

Для кого этот пост
- Этот пост для тех кто хочет перейти с Sentry в docker-compose
- Для тех кто хочет перейти с Nodestore в PostgreSQL

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

#devops #девопс

Подпишись 👉@i_DevOps

Расследование аферы с GitHub: как тысячи «модов» и «кряков» крадут наши данные

Просматривая статьи на тематическом форуме по социальной инженерии, я обнаружил относительно новую схему мошенничества, которая меня потрясла. На GitHub создаются тысячи репозиториев с разными штуками — от модов для Roblox и Fortnite до «взломанных» FL Studio и Photoshop.

Как только вы скачиваете и запускаете любую из них, все данные с вашего компьютера собираются и отправляются на Discord-сервер, где сотни злоумышленников просматривают их в поисках закрытых ключей криптокошельков, банковских счетов и учётных данных социальных сетей, а также аккаунтов Steam и Riot Games.

https://habr.com/ru/companies/flant/articles/899158/

original https://timsh.org/github-scam-investigation-thousands-of-mods-and-cracks-stealing-your-data/

#devops #девопс

Подпишись 👉@i_DevOps

⚡️ Performance Testing в микросервисах: как избежать коллапса под нагрузкой?

Что произойдёт, если на ваш сервис внезапно обрушится поток пользователей? Выдержит ли архитектура или ляжет под нагрузкой? Разбираем, как правильно тестировать производительность микросервисов, чтобы система работала без сбоев!

📅 17 апреля в 20:00
🎓 Открытый вебинар с Сергеем Прощаевым

💡 Что разберём?
✅ Как нагрузка ломает архитектуру и что с этим делать
✅ Главные ошибки при тестировании распределённых систем
✅ Как увеличить RPS и подготовить систему к реальной нагрузке
✅ Инструменты стресс-тестирования и шаблоны конфигурации

🎯 Что получите?
✔️ Понимание, как прогнозировать нагрузку и готовить систему
✔️ Навыки работы с инструментами нагрузочного тестирования
✔️ Готовые шаблоны для тестирования и повышения устойчивости микросервисов

Присоединяйтесь и узнайте, как защитить свой сервис от падений!

👉 Регистрируйтесь по ссылке: https://vk.cc/cKOkqx

Бесплатное занятие приурочено к старту курса Microservice Architecture, обучение на котором позволит освоить микросервисы: Docker, Kafka, API и стать мастером производительных систем.

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

🔥 Как ускорить docker build и сократить размер образа

Иногда docker build тянется вечность, а итоговый образ весит больше, чем база данных 🐘. Разбираемся, как ускорить сборку и оптимизировать размер образа без потери функциональности.


1. Используй multistage build
Разделяй стадии сборки и финальный образ. Это особенно важно при компиляции (Go, Java, Node.js):

# Стадия 1: билд
FROM golang:1.20 as builder
WORKDIR /app
COPY . .
RUN go build -o app

# Стадия 2: минимальный runtime
FROM alpine:latest
COPY --from=builder /app/app /usr/local/bin/app
ENTRYPOINT ["app"]

Образ получается меньше 10 МБ!


2. Минимизируй base image
Используй alpine, distroless, scratch, если не нужен полноценный дистрибутив:

FROM python:3.12-slim

Или вообще:

FROM scratch

3. Правильно расставляй COPY и RUN
Кешируй слои — сначала зависимости, потом исходники:

COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .

Так pip install не будет повторяться при каждом изменении исходников.


4. Убирай мусор и временные файлы
После установки пакетов — чисти кэш:

RUN apt-get update && apt-get install -y ... \
 && rm -rf /var/lib/apt/lists/*

5. Используй .dockerignore
Иначе в билд попадут node_modules, .git, логи и прочее:

.git
node_modules
*.log

Вывод:
Минимизация образа — это не только про размер, но и про безопасность (меньше surface area), скорость CI/CD, стабильность. И не забывай — docker build тоже надо профилировать.

#devops #docker #ci #optimization

Подпишись 👉 @i_DevOps

🔥 Ускоряем сборку Docker-образов: слои и кэш — наши друзья

Когда сборка Dockerfile занимает минуты — это мешает dev-loop'у. А ведь можно сильно ускориться с парой простых правил 👇


🧠 Основные принципы ускорения:

1. Максимально используем кэш
Docker кэширует каждый слой. Если слой не изменился — пересобирать не будет.

➤ Сначала COPY зависимости, потом остальной код:

   COPY requirements.txt .
   RUN pip install -r requirements.txt  # кэшируется

   COPY . .  # некэшируемо при любом изменении в коде
   

2. Объединяем RUN-команды
Меньше слоёв — быстрее сборка и push:

   RUN apt update && apt install -y curl git \
       && rm -rf /var/lib/apt/lists/*
   

3. .dockerignore
Убедись, что не копируешь лишние файлы (например, .git/, tests/, node_modules/):

   .git
   node_modules
   *.log
   __pycache__/
   

4. Меньше COPY, больше multi-stage
Разделяй сборку и runtime — не таскай компиляторы в прод:

   FROM golang:1.20 AS builder
   WORKDIR /app
   COPY . .
   RUN go build -o app

   FROM debian:bullseye-slim
   COPY --from=builder /app/app /usr/bin/app
   CMD ["app"]
   

5. Кэшируй pip/npm/go-пакеты
→ в Dockerfile сначала копируй файл зависимостей, ставь пакеты, только потом — весь код проекта.


📌 Используй эти практики, чтобы ускорить CI/CD, локальную сборку и деплой. Чем меньше слоёв изменяется — тем быстрее весь процесс.


#devops #девопс

Подпишись 👉@i_DevOps

🔥 Как ускорить GitHub Actions на 40% и платить меньше

CI — это не место для медлительности. Особенно когда билд идёт 15 минут, а запусков в день — сотни. Сейчас разберём, как оптимизировать GitHub Actions: быстрее, дешевле, эффективнее.


🔹 1. Используйте actions/cache правильно
Загрузка и компиляция зависимостей — одно из самых дорогих мест. Добавьте кэширование для npm, pip, go mod, docker layers. Пример для Node.js:

- uses: actions/cache@v3
  with:
    path: ~/.npm
    key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-npm-

⚠️ Не кэшируйте build-артефакты, которые зависят от среды (OS, runner version) — это приведёт к нестабильности.


🔹 2. Job matrix + fail-fast: false = контроль над параллелизмом
Matrix позволяет запускать тесты параллельно (например, разные версии Python), а fail-fast: false не останавливает все джобы при первом фейле.

strategy:
  fail-fast: false
  matrix:
    python-version: [3.8, 3.9, 3.10]

🔹 3. Разделяйте пайплайн на reusable workflows
Выносите повторяющуюся логику в .github/workflows/reusable.yml и вызывайте с параметрами. Это уменьшает дублирование и ускоряет поддержку.

- uses: ./.github/workflows/reusable.yml
  with:
    env: staging

🔹 4. Используйте self-hosted runners, если билд тяжёлый
Если у вас сборка Docker-образов весит десятки минут — дешевле и быстрее поднять свои раннеры в EC2 или Kubernetes (особенно с GPU или кастомной средой).

📌 Попробуйте actions-runner-controller для Kubernetes:
https://github.com/actions/actions-runner-controller


🔹 5. Откажитесь от setup-* при каждом запуске
setup-node, setup-go, setup-java — удобны, но каждый раз качают и устанавливают SDK. Замените на preinstalled версии в раннерах или кэшируйте вручную.


✅ Вывод:
Оптимизация GitHub Actions — это про кэш, параллельность и минимизацию накладных расходов. Даже простые изменения могут ускорить пайплайн в 2–3 раза. А главное — вы перестаёте платить за простой.


🔥 Ресурсы:
- Официальная дока по кэшу https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows


#devops #девопс

Подпишись 👉@i_DevOps

⚡ 22 апреля вебинар Luntry: «Безопасность контейнеров и Kubernetes для специалистов анализа качества». 

Пройдем путь от приложения — «чёрного ящика» в контейнерном исполнении до полного понимания, что это за средство, как оно устроено и насколько все хорошо (или плохо) с безопасностью.

Запишитесь, чтобы получить напоминание и не пропустить эфир. Всем, кто зарегистрировался, вышлем полезные материалы после вебинара. 
Регистрация здесь

#реклама
О рекламодателе

Dokploy — Самый простой способ развернуть и управлять вашими контейнерами

Dokploy — это open-source инструмент для деплоя и управления контейнерами, разработанный для упрощения процессов CI/CD и DevOps. Он позволяет разработчикам легко развёртывать, управлять и масштабировать приложения без необходимости писать сложные скрипты или конфигурации.

Возможности:
- 🚀 Быстрый деплой контейнеров
- 🔄 Автоматическое обновление на основе webhook’ов
- 🧩 Простая интеграция с GitHub
- 🔒 Безопасное хранение переменных окружения
- 📦 Поддержка множества приложений
- 🛠️ Web UI и CLI для управления

Как это работает:
1. Подключаете свой репозиторий GitHub.
2. Dokploy следит за изменениями и автоматически деплоит ваше приложение.
3. Управляете всем через простой UI или CLI.

Цель проекта — дать каждому разработчику простой и эффективный способ доставки своего кода в прод.

https://github.com/dokploy/dokploy

#devops #девопс

Подпишись 👉@i_DevOps

Что такое userspace, kernelspace? Чем они отличаются?

Под пользовательским пространством понимается весь код операционной системы, который находится вне ядра.

Большинство Unix-подобных операционных систем (включая Linux) поставляются с разнообразными предустановленными утилитами, средствами разработки и графическими инструментами — это все приложения пространства пользователя.

Все пользовательские приложения (и контейнеризированные, и нет) при работе используют различные данные, но где эти данные хранятся?

Ядро обеспечивает абстракцию для безопасности, оборудования и внутренних структур данных. Например, системный вызов open() используется для получения дескриптора файла в Python, C, Ruby и других языках программирования. Вряд ли бы вы хотели, чтобы ваша программа работала с XFS на уровне битов, поэтому ядро предоставляет системные вызовы и работает с драйверами. Фактически этот системный вызов настолько распространен, что является частью библиотеки POSIX .

Краткое определение:

👉 Пользовательское пространство представляющее собой набор местоположений, в которых выполняются обычные пользовательские процессы (т. е. все, кроме ядра). Роль ядра состоит в том, чтобы управлять приложениями, работающими в этом пространстве, от взаимодействия друг с другом и с машиной.
👉 Пространство ядра , то есть место, где хранится и выполняется код ядра.
Пользовательское пространство имеет доступ к ограниченной памяти, ядро имеет всю память.

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

#devops #девопс

Подпишись 👉@i_DevOps

CI/CD пайплайны на стероидах: 5 фишек для ускорения сборок 🚀

⏱ Устали ждать, пока пройдут все джобы в CI? Время — деньги, особенно на продакшене. Вот 5 проверенных способов прокачать скорость и стабильность пайплайнов.


1. Кэширование зависимостей — must have
Кэшируйте node_modules, .m2, Docker-слои или Python virtualenv.
В GitHub Actions:

   - uses: actions/cache@v3
     with:
       path: ~/.npm
       key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
   

2. Matrix strategy для параллельных задач
Разбейте тесты по окружениям, версиям или компонентам:

   strategy:
     matrix:
       python: [3.9, 3.10]
   

3. Docker Layer Caching (DLC)
В GitLab CI включайте DLC:

   variables:
     DOCKER_DRIVER: overlay2
     DOCKER_TLS_CERTDIR: ""
   services:
     - docker:dind
   

4. Пропускайте джобы при отсутствии изменений
Нет изменений в директории — не триггери билд. В GitHub Actions:

   on:
     push:
       paths:
         - 'src/**'
         - '!docs/**'
   

5. Self-hosted runners для тяжёлых задач
Сильная машина с нужными зависимостями сэкономит десятки минут. Плюс — контроль среды и логирования.


Вывод:
Оптимизация CI/CD — это не про магию, а про дисциплину: кэш, параллелизм, условные шаги и правильные раннеры. Регулярно профилируйте пайплайны и фиксируйте bottlenecks.

#devops #девопс

Подпишись 👉@i_DevOps

#vacancy #DevOps #fulltime #вакансия #москва

DevOps

Локация: Москва
ЗП: 200к-350к net
Занятость: Полная, Гибридный формат
Оформление: ТК РФ
Компания: Федеральное Медико-биологическое агентство

ЦСП ФМБА занимается научными исследованиями связанными с геномом человека и анализом полученных данных.
Группа разработки создает внутренние сервисы для автоматизации движения, обработки и распределенного хранения больших объемов данных.

Требования:

•Опыт работы с Kubernetes обязателен
•Уверенные знания Linux, систем виртуализации и контейнеризации
•Опыт реализации CI/CD, большой опыт работы с Ansible и Git
•понимание работы web-серверов, балансировщиков и брокеров сообщений (на примере Nginx, Kafka)
•Понимание работы сетей и распределенных систем
•Опыт настройки и использования систем мониторинга: Zabbix, Grafana, Prometheus, ELK Stack
•Понимание процессов ITSM
•Законченное высшее образование


Чем предстоит заниматься:

•Настройка и последующая поддержка процессов CI/CD внутренних и публичных сервисов в различных окружениях
•Обеспечение непрерывной работоспособности и доступности сервисов
•Мониторинг систем, оптимизация производительности приложений и инфраструктуры, траблшутинг
•Настройка и управление Kubernetes
•Документирование процессов и систем
•Выстраивание процессов работы с командой разработки, командой данных, системными администраторами, Service Desk

Стек:
•Ubuntu, ALT Linux, Oracle
•Git, Gitlab-CI, Ansible, Terraform, Molecule
•Docker, Kubernetes
•Nginx, Haproxy, Traefik, Hashicorp Vault, MinioS3, Harbor, Consul, Postgres, Mariadb, Kafka
•Grafana, ELK, Prometheus, Loki, Victoria Metrics, Zabbix
•Bash, Python

Мы предлагаем:

•Оформление по ТК РФ.
•Работа в команде профессионалов на стыке передовых ИТ и науки. Мы работаем с Big Data и ML, у нас собственный корпоративный ЦОД.
•Только современное оборудование для рабочих мест.
•Прикрепление к корпоративной поликлинике.
•Возможность профессионального роста, обучение.
•График работы 5/2, гибрид, плавающее начало рабочего дня

Резюме отправлять: @ddsh_kl

Kubernetes: секреты быстрого rollback без боли и даунтайма

🔄 Rollback — неотъемлемая часть стабильного продакшена. Но сколько раз он превращался в хаос? Рассмотрим, как грамотно настроить откат в Kubernetes, чтобы не терять трафик, не ловить панику и не тратить часы на ручное восстановление.


🔹 1. Стратегия деплоя имеет значение

По умолчанию Deployment использует стратегию RollingUpdate. Это безопасно, но не всегда быстро. Убедись, что параметры maxUnavailable и maxSurge оптимальны:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0

➡️ Это даст zero downtime, но при большом количестве реплик откат будет медленным. Подстрой под нагрузку.


🔹 2. Используй kubectl rollout undo

Kubernetes хранит предыдущие ReplicaSets, так что простой rollback — дело одной команды:

kubectl rollout undo deployment my-app

Проверь текущую ревизию:

kubectl rollout history deployment my-app

📝 Храни истории изменений в git — манифесты должны быть version-controlled.


🔹 3. Хелм под капотом? Настрой helm rollback

Если ты используешь Helm, rollback проще:

helm rollback my-release 1

❗️Важно: иногда rollback не возвращает ConfigMap или Secret, если они были изменены. Используй флаг --recreate-pods или закладывай изменения в values.yaml через hash-аннотации.


🔹 4. Прогревай rollback заранее

На preprod окружении сделай dry-run откатов. Проверь:

- есть ли живая предыдущая ревизия
- не изменились ли зависимости (например, база данных)
- как себя ведёт app после downgrade


🔹 5. Автоматизируй возврат

Сценарий: новая версия падает по хелсчекам. Вместо ручного вмешательства — automation:

- Настрой alertmanager на провал readiness/liveness
- Свяжи с Argo Rollouts или Spinnaker, чтобы триггерить rollback автоматически


✅ Вывод: грамотный rollback — это не кнопка “назад”, а часть CI/CD культуры.

Обеспечь:

- контроль версий манифестов
- мониторинг после деплоя
- rollback как часть стратегии, а не костыль


#devops #девопс

Подпишись 👉@i_DevOps

Кто вы в зоопарке DevOps-тулзов?

Каждый день вы приручаете зверей CI/CD, но вместо управляемой экосистемы — хаос?

Kubernetes может стать тем самым ядром, которое унифицирует ваши процессы. 👉На курсе «Kubernetes Мега» от Слёрма вы освоите K8s как основу для построения эффективной и управляемой CI/CD платформы.

Вы овладеете:
🔸 Переносом продукта на K8s без боли
🔸 Настройкой отказоустойчивых кластеров
🔸 Мгновенным траблшутинг и уверенное устранение инцидентов
🔸 Повышением стабильности и безопасности приложений
🔸 Автоматизацией: ротация сертификатов, автодеплой, безопасное хранение секретов

Старт уже 21 апреля
Осталось всего 7 мест

Программа и регистрация ➡️ по ссылке
Не дайте своим DevOps-зверям вырваться из-под контроля!

#реклама
О рекламодателе
erid: 2W5zFJGbtkx

HULL - Helm Uniform Layer Library

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

Сама диаграмма и вся связанная с ней документация находятся в папке hull, которая является корневой директорией библиотечной Helm-диаграммы HULL.

https://github.com/vidispine/hull

#devops #девопс

Подпишись 👉@i_DevOps

Kubernetes: правильный подход к ресурсным лимитам и requests

🔧 Часто недооценённая, но критичная тема для стабильности и производительности кластеров.


🎯 Зачем это важно?
Неверные значения requests и limits приводят либо к перерасходу ресурсов, либо к OOM, Throttling и подам, которые бесконечно перезапускаются. Особенно больно это бьёт по продакшену.


🚀 Как правильно настраивать ресурсы:

1. Понимай разницу между requests и limits:
- requests — это гарантированный минимум, который получит контейнер.
- limits — это максимум, выше которого контейнер не сможет использовать (CPU throttling или OOMKill для памяти).

2. CPU — без жестких лимитов:
- Лучше не указывать limits.cpu, чтобы избежать throttling.
- Но обязательно ставь requests.cpu, чтобы kube-scheduler мог правильно распланировать нагрузку.

3. Memory — всегда с лимитом:
- Память не отбирается — контейнер либо получает всю, либо OOM.
- Обязательно ставь и requests.memory, и limits.memory.

4. Используй VPA (Vertical Pod Autoscaler):
- Он поможет подобрать адекватные значения ресурсов на основе истории.
- ⚠️ На проде использовать осторожно — часто в "recommendation only" режиме.

5. Метрики в помощь:
- Используй kubectl top, metrics-server, Prometheus/Grafana для анализа потребления.
- Наблюдай за container_cpu_usage_seconds_total, container_memory_usage_bytes.

6. Профилируй и оптимизируй:
- Легковесный nginx или sidecar не должен просить 500Mi памяти.
- Java-приложение без указанных лимитов съест весь узел.


🧠 Вывод:
Грамотно выставленные ресурсы — это баланс между надёжностью и эффективным использованием нод. Не копируй requests/limits вслепую из интернета — мерь, анализируй, настраивай под свой ворклоад.


#devops #девопс

Подпишись 👉@i_DevOps