⚡️ Apache Camel в архитектуре решений бэкенда

📅 4 февраля | 20:00 мск | бесплатно

Хотите строить надёжные и гибкие интеграции между сервисами без лишней сложности?

На вебинаре разберём:

- Роль Apache Camel в современной backend-архитектуре
- Enterprise Integration Patterns и их практическое применение
- Типовые сценарии: синхронные и асинхронные интеграции
- Camel как связующее звено между микросервисами, брокерами сообщений и внешними системами
- Архитектурные преимущества и реальные ограничения использования Apache Camel

✅ После вебинара вы сможете:

- Определять, когда Apache Camel — правильный архитектурный выбор
- Проектировать интеграционные потоки на основе проверенных паттернов
- Строить устойчивые и слабо связанные backend-решения
- Принимать осознанные архитектурные решения в области интеграций

👉 Регистрируйтесь https://vk.cc/cU2J9n

Занятие приурочено к старту курса "Software Architect", обучение на котором позволит освоить компетенции архитектора по моделированию и построению отказоустойчивых, масштабируемых и хорошо интегрируемых информационных систем. Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

MLOps — дитя DevOps и ML

Один ML-проект в проде вам или два другому? Внедрение машинного обучения в производственную среду остаётся одной из главных проблем индустрии. По статистике, 80% ML-проектов никогда не доходят до продакшена. Однако хитрые опсы и тут решили выделиться, и в результате появился MLOps — методология, которая поможет вам сократить путь от эксперимента до деплоя с месяцев до дней. В этой статье мы пройдёмся по верхам MLOps и посмотрим на фундаментальные принципы и конкретные инструменты.

https://habr.com/ru/companies/ruvds/articles/990814/

📲 Мы в MAX

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

🧪 K8E — это форк проекта K3s, предназначенный для локального тестирования.
Он не требует root-доступа и не использует systemd.
Также вы можете легко собрать и запустить его без сетевого подключения (air-gap режим).

Основные особенности:
- Без root-доступа
- Без systemd
- Один бинарник
- Простой запуск кластера: k8e server &
- Не требует внешней сети
- Поддерживает полностью автономную сборку

Если вы когда-либо хотели поднять Kubernetes-кластер за пару секунд и без привилегий — этот инструмент идеально подойдёт для тестов и локальной разработки.

https://github.com/xiaods/k8e

📲 Мы в MAX

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

Собрал основные концепции Docker в одну диаграмму


📲 Мы в MAX

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

Zed — это высокопроизводительный текстовый редактор, ориентированный на разработчиков. Он написан на Rust и использует пользовательский движок рендеринга на базе GPU для достижения минимальных задержек. Архитектура Zed основана на многопоточности и асинхронности, что позволяет редактору эффективно использовать ресурсы современных многоядерных систем.

Редактор также разрабатывается с упором на совместную работу в реальном времени: Zed предлагает встроенные функции для коллаборации между разработчиками — от редактирования кода до видеозвонков. Это делает его особенно удобным для удалённых команд.

Среди особенностей:
- Мгновенный отклик и плавная анимация благодаря GPU-рендерингу
- Полноценная поддержка нескольких курсоров и мощное автодополнение
- Интеграция с языковыми серверами (LSP)
- Глубокая коллаборативность: совместное редактирование, общие терминалы, голос и видео

https://github.com/zed-industries/zed

📲 Мы в MAX

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

Путь в DevOps: полное руководство для новичков с НУЛЯ

00:00 - Вступление
00:14 - Всевозможные компетенции DevOps Инженера
00:44 - Кому проще стать DevOps Инженером
02:29 - Что учить по минимуму и в каком порядке
10:27 - 1. Основы Networking TCP/IP
11:46 - 2. Администрирование Windows
12:38 - 3. Основы Linux
13:28 - 4. Ansible
13:56 - 5. Git
14:26 - 6. GitHub
14:52 - 7. CI/CD: GitHub Actions, GitLab CI/CD
15:29 - 8. Docker + DockerHub
16:16 - 9. Kubernetes + Helm + ArgoCD
17:04 - 10. AWS: Amazon Web Services
19:12 - 10. GCP: Google Cloud Platform
20:27 - 10. Azure: Microsoft Azure
21:38 - 11. Terraform + Terragrunt
22:42 - 12. Python
23:09 - Как стать профессиональным DevOps Ннженером
24:37 - Девопс это хорошее будущее вашей карьеры

источник

📲 Мы в MAX

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

26 февраля — Deckhouse User Community meetup #4. Это митап для тех, кто хочет понимать Kubernetes глубже.

Зарегистрироваться

Эксперты Deckhouse и приглашённые спикеры расскажут, как запускать K8s поверх любых дистрибутивов, эксплуатировать платформу в одиночку, развёртывать домашнюю виртуализацию на бюджетном железе и грамотно подходить к безопасности.

И покажут: на митапе будет работать зона «Попробуй сам», где можно протестировать работу Deckhouse Kubernetes Platform Community Edition своими руками.

🛠Построение CI/CD-фреймворка MLOps уровня Enterprise (MLflow + Kubeflow)

Разработка MLOps-фреймворка в масштабах предприятия — непростая задача. Она требует интеграции множества компонентов: обработки данных, экспериментов, мониторинга и CI/CD. В этом посте рассказывается, как объединить MLflow, Kubeflow, Seldon Core, GitHub Actions и другие инструменты для построения полноценного MLOps-пайплайна.

Архитектура

Архитектура построена на:

- MLflow — для логирования и управления экспериментами
- Kubeflow Pipelines — для оркестрации пайплайнов
- Seldon Core — для деплоя моделей в Kubernetes
- MinIO — объектное хранилище для артефактов
- GitHub Actions — для CI/CD
- Prometheus + Grafana — мониторинг моделей

Компоненты развернуты в Kubernetes-кластере с использованием Helm.

Поток разработки

1. Подготовка данных — скрипты ETL обрабатывают сырые данные и сохраняют в MinIO.
2. Обучение модели — тренинг происходит в Kubeflow, результаты логируются в MLflow.
3. Тестирование и валидация — автоматизированные проверки модели.
4. CI/CD — GitHub Actions запускает пайплайны при изменении кода или модели.
5. Деплой — модель деплоится через Seldon Core, становится доступной по REST/gRPC.
6. Мониторинг — метрики поступают в Prometheus и отображаются в Grafana.

Преимущества подхода

- Реплицируемость и трассировка экспериментов
- Централизованное хранилище артефактов
- Автоматизация развёртывания моделей
- Мониторинг производительности и дрифта

Заключение

Такой фреймворк обеспечивает устойчивую MLOps-инфраструктуру, подходящую как для небольших команд, так и для крупных корпораций. Он позволяет быстрее и безопаснее доставлять ML-модели в продакшен.

https://rkmaven.medium.com/building-an-enterprise-level-mlops-ci-cd-framework-mlflow-kubeflow-fb1cdd1f74fc

📲 Мы в MAX

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

💡 Лучшие практики работы с Helm: что нужно знать

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

📦 1. Структура директорий чарта
Соблюдайте стандартную структуру чарта Helm:

mychart/
  charts/
  templates/
  values.yaml
  Chart.yaml
  README.md

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

🧩 2. Разделяйте общие шаблоны
Используйте _helpers.tpl для определения общих шаблонов, таких как аннотации, метки и имена ресурсов. Это снижает дублирование и упрощает сопровождение:

{{/* Генерация полного имени */}}
{{- define "mychart.fullname" -}}
{{- printf "%s-%s" .Release.Name .Chart.Name | trunc 63 | trimSuffix "-" -}}
{{- end -}}

⚙️ 3. Используйте параметры в values.yaml
Делайте чарты гибкими, передавая конфигурации через values.yaml. Никогда не хардкодьте значения в шаблонах.

🧪 4. Валидация values.yaml
Добавляйте проверку обязательных значений с помощью required:

{{ required "Variable mychart.image.repository is required" .Values.image.repository }}

🔍 5. Используйте шаблоны if/else разумно
Старайтесь не перегружать шаблоны логикой. Разделяйте шаблоны на несколько файлов, если они становятся слишком сложными.

🗃️ 6. Не добавляйте чарт в шаблон напрямую
Вместо включения зависимостей в директорию charts/, указывайте их в Chart.yaml и используйте helm dependency update.

🛑 7. Не хардкодьте версии образов
Передавайте версию через values.yaml. Это повышает гибкость CI/CD:

image:
  repository: nginx
  tag: "1.21.1"

🔒 8. Управление чувствительными данными
Не храните пароли и токены в values.yaml. Используйте секреты Kubernetes или инструменты типа Sealed Secrets или External Secrets.

🔁 9. Helm hooks
Helm предоставляет хуки для выполнения задач до/после установки. Используйте их, например, для миграций БД. Пример:

annotations:
  "helm.sh/hook": pre-install

🧹 10. Чистка старых релизов
Используйте helm uninstall и регулярно проверяйте статус релизов с помощью helm list. Это помогает избегать конфликта имён и мусора.

🧪 11. Тестирование чарта
Добавляйте unit-тесты с помощью helm unittest и не забывайте про проверку синтаксиса:

helm lint .

🔄 12. Автоматизация через CI/CD
Интегрируйте Helm в пайплайны CI/CD для установки и обновления чартов — например, с помощью GitLab CI, GitHub Actions, ArgoCD или Flux.


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

📲 Мы в MAX

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

Блокировка состояния Terraform с использованием S3 (без DynamoDB)

В этом посте мы рассмотрим:

- Зачем нужна блокировка состояния Terraform
- Блокировка состояния с помощью DynamoDB
- Блокировка состояния только с использованием S3, без DynamoDB
- Когда стоит использовать DynamoDB
- Когда можно обойтись только S3
- Лучшие практики хранения state-файлов в S3

https://devopscube.com/terraform-state-locking-with-s3/

📲 Мы в MAX

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

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

📲 Мы в MAX

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

🔥 Как ускорить 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

📲 Мы в MAX

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

🚀 Ищем Kubernetes Platform Engineer (Middle+/ Senior) в 2ГИС

В команде Infrastructure & Operations мы строим внутреннюю PaaS-платформу для Data Services: PostgreSQL, Redis, Kafka, ClickHouse.

Наша цель — сделать DBaaS и DS self-service, надёжной и стандартизированной частью платформы для десятков продуктовых команд.
Что будешь делать:

• Развивать PaaS на базе Kubernetes

• Автоматизировать lifecycle DS (deploy, scale, backup, restore)

• Строить DBaaS (начинаем с PostgreSQL)

• Внедрять GitOps, IaC и платформенные стандарты

Наш стек

Kubernetes, GitLab CI/CD, Terraform, Ansible, ELK, Vault, S3.
Ищем инженера, который понимает Kubernetes как платформу, работал со stateful-нагрузками и тюнил PostgreSQL.

Удалёнка или офис. Белая зарплата, ДМС, обучение и конференции — всё по-взрослому.

👉Откликайся

Другие инженерные инсайты от 2ГИС →в Telegram-канале RnD