Переезд с Docker[-Compose] на Kubernetes - мини-разбор инфраструктурного вебинара глазами архитектора данных.

Я не настоящий ДевОпс, и часто кручу что-то простое в докере и докер-компоузе. Нужен просто Аэрфлоу или Суперсет - нет ничего проще развернуть готовый компоуз с ГитХаба и (какое-то время) радоваться, что все работает. Но все мы понимаем, что это времянка и рано или поздно при выходе на продакшен с SLA-ями придется переинжинирить инсталляцию на что-то более устойчивое.

Чуть ранее я анонсировал вебинар про перенос инфрастурктуры с докера на кубер от коллег. Теперь у нас есть его запись.

В вебинаре все разложили по полочкам - почему умные делают так, какие именно недостатки в простом докере и чего именно мы добиваемся переходя на более взрослое решение на основе K8S.

💾💾💾💾💾💾💾💾💾💾💾💾💾💾

Выписал себе пункты:

1️⃣ Докер - отличный старт, когда контейнеров мало и инфра небольшая.

2️⃣ Докер решает только задачу запуска контейнера. Не управления многими контейнерами, не интеграции с инструментами разработки.

3️⃣ В докере нет централизованного хранилища секретов, что приводит к хранению паролей и ключей в .env и прочих текстовых файлах, и в конце концов рано или поздно, к утечкам критических доступов.

4️⃣ То же - для сетевых практик, например разделения dev & prod

5️⃣ Docker Compose - хороший способ поддержать локальное окружение разработки.

6️⃣ Docker Compose - по дизайну односерверная инфраструктура. Он не подходит для создания хоть сколь-нибудь отказоустойчивой конфигурации, непрерывной выкатки, масштабирования.

7️⃣ На основе K8S намного легче добиться ситуации когда выкатка для разработчика - это просто коммит. То же с непрерывным обслуживанием конечных пользователей.

8️⃣ То же - для возможности быстрой откатки на предыдущее состояние, если что-то идет не так

💾💾💾💾💾💾💾💾💾💾💾💾💾💾

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

🚀 JetBrains запускает Developer Productivity AI Arena (DPAI Arena)

JetBrains представила открытую платформу для бенчмаркинга AI-агентов, которые помогают писать код.

🧠 DPAI Arena оценивает, как ИИ-инструменты справляются с задачами вроде:

🔘исправления багов,

🔘ревью pull-реквестов,

🔘генерации тестов,

🔘апдейта зависимостей.


Платформа открытая и нейтральная - JetBrains планирует передать её под крыло Linux Foundation.
Первый бенчмарк - на Java/Spring, но архитектура поддерживает и Python, Go, JS и др.

🤔 Главное: теперь качество AI-помощников в кодинге будут оценивать по реальным метрикам - не просто "собралось или нет", а насколько код читаемый, устойчивый и тестируемый.

#ai #agents #agentic #llm #dev #jetbrains

Релиз 🖼️
🔘Apache Airflow 3.1.2
🔘Task SDK 1.1.2

🤔 Что нового

⏩Улучшена стабильность при работе с динамическими задачами и TaskFlow API

⏩Оптимизированы механизмы импорта и загрузки плагинов

⏩Повышена совместимость с Python 3.12

⏩Улучшения в логировании, UI и Scheduler

😊 Ничего нового, баги фиксят

📦 Релизные ресы

▶️ Дока

▶️ Release Notes

▶️ Constraints

#airflow #release #de

🤖 XPeng показала IRON - самый человечный робот года

На AI Day в Гуанчжоу IRON вышел на сцену, прошёл "кошачьим шагом" и жестами как человек. Зрители решили, что это костюм - поэтому Хэ Сяопэн прямо на сцене "распаковал" робота, показав skелет и "мышцы".

Что интересно:
⏩1:1 габариты человека: 178 см, 70 кг
⏩22 DOF в каждой руке, до 82 DOF по телу
⏩Три чипа Turing, до 3 000 TOPS (по данным XPeng)
⏩Полноразмерная мягкая "кожа" и бионные "мышцы"
⏩Впервые для класса - твердотельная батарея
⏩Цель - коммерция и масштабирование в 2026

Применение: витрины/гиды в ритейле и промышленные инспекции (партнёрство с China Baowu уже в работе).

📹 Смотри на видео как доказывали, что это не человек.

#XPeng #IRON #роботы #гуманоид #AI #humanoid #robotics

🖼️ Релиз Apache Airflow CTL 0.1.0

airflowctl - новый официальный CLI, который разговаривает с Airflow Public API и даёт удобные команды для повседневных задач:
🔘триггерить DAG-и
🔘листать и проверять DagRun-ы
🔘паузить/анпаузить
🔘управлять connections/variables

Всё это удалённо, из CI/CD или локально, без SSH на кластеры.

Зачем это нужно:
🔘централизованный доступ к продам и стейджам через API
🔘единый инструмент для SRE/Platfоrm/DE‑команд и пайплайнов
🔘безопаснее: используем API‑токен, который хранится в keyring.

Пример - поставить и дернуть DAG удалённо:

# установка
pip install apache-airflow-ctl

# логин (через токен; API должен быть включён)
export AIRFLOW_CLI_TOKEN=<api_token>
airflowctl auth login --api-url https://airflow.example.com --env prod

# посмотреть доступные DAG-и
airflowctl dags list -o table

# триггернуть DAG с конфигом и заметкой
airflowctl dags trigger \
  --dag-id example_etl \
  --conf '{"country":"RU"}' \
  --note "triggered from airflowctl"

# проверить последние запуски
airflowctl dagrun list --dag-id example_etl --limit 5 -o table

Подробнее в доке.


#airflow #release #airflowctl