Как DuckDB помогает процессить данные без лишних сложностей 🦆

Вспомните бурный рассвет эпохи доткомов в конце 90-х. Современные базы данных тогда играли роль тайных спасателей для программ, которые, откровенно говоря, были не слишком хороши. Одной из их суперспособностей было умение обрабатывать асинхронные запросы, даже если остальная часть системы была далека от идеала.

Вот, например, Ларри Эллисон, сооснователь Oracle, еще в 2001 году в интервью The Guardian назвал интернет-магазины, такие как pets.com, "хорошо, что их больше нет". И добавил: "Продавать кошачий корм в интернете — это было безумием". Мы, конечно, посмеялись тогда, но теперь уже никто не удивляется, что e-commerce стал нормой. А что же базы данных? Они тоже эволюционировали.

DuckDB — компактный помощник для работы с данными 🤖
Сегодня поговорим о DuckDB — легковесной, но мощной базе данных, которая в июне выпустила свою версию 1.0. В чем ее "фишка"? DuckDB — это in-process база данных. То есть она работает прямо внутри вашего приложения, без необходимости подключаться к какому-то внешнему серверу. И да, она точно не про продажу кошачьего корма.

Основная идея DuckDB проста: это инструмент для обработки запросов, а не долгосрочного хранения данных. Вы можете создать базу данных прямо в оперативной памяти, которая исчезнет при завершении работы программы, или использовать локальный файл. DuckDB идеально подходит для таких задач, как быстрое поглощение данных, их трансформация и анализ.

Почему DuckDB удобен? 🤔

DuckDB интегрируется как библиотека или плагин — никаких дополнительных приложений или сервисов. Хотите использовать C#? Пожалуйста, через open-source провайдер ADO.NET. На сайте DuckDB это, правда, не упомянуто, но экосистема явно развивается.

Пример на C#:

using DuckDB.NET.Data;
var duckDBConnection = new DuckDBConnection("Data Source=file.db");
duckDBConnection.Open();
var command = duckDBConnection.CreateCommand();
command.CommandText = "CREATE TABLE integers(foo INTEGER, bar INTEGER);";
command.ExecuteNonQuery();
command.CommandText = "INSERT INTO integers VALUES (3, 4), (5, 6), (7, NULL);";
command.ExecuteNonQuery();
command.CommandText = "SELECT count(*) FROM integers";
var count = command.ExecuteScalar();
Console.WriteLine($"Rows = {count}");

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

Где DuckDB действительно выделяется? 💎

DuckDB поддерживает Python, R, Java, Node.js, Go, Rust и другие языки программирования. Она полезна не только для тестирования и трансформации данных, но и как удобный инструмент для SQL-запросов, не требующий разворачивания полноценной базы данных.

Но если у вас грандиозные планы, например, на создание нового pets.com, лучше взять что-то более серьезное. DuckDB идеально подходит для быстрых запросов, легкой аналитики и локальной обработки данных.

Ref: https://thenewstack.io/duck-db-query-processing-is-king/

Питона короновали 👑

Кажется, мир программистов уже окончательно решил: Python — это не просто язык, а целая эпоха. По данным свежайшего индекса TIOBE, Python снова назван языком года благодаря невероятному росту популярности и использования. И знаете что? Это уже даже не сюрприз.

Почему Python? 🐍

Python сейчас повсюду. Хотите разработать приложение на основе искусственного интеллекта? Python. Работаете над машинным обучением? Опять Python. Он стал, по сути, «языком по умолчанию» для всех современных задач, связанных с ИИ, компьютерным зрением (OCV) и обработкой естественного языка. Библиотеки, такие как TensorFlow, PyTorch и Transformers от Hugging Face, сделали его маст-хев инструментом для разработчиков, стремящихся к быстрому прототипированию и развертыванию сложных решений.

Но не все так идеально. Python критикуют за низкую производительность и ошибки, которые обнаруживаются только во время выполнения. Однако, судя по всему, эти «недостатки» не мешают ему доминировать: в 2024 году его популярность выросла на 9,3%, что существенно обогнало конкурентов. Для сравнения, Java прибавила всего 2,3%, а Go — 1,2%.

Java и C++: битва за серебро ☕️

Помимо триумфа Python, в топе TIOBE развернулась настоящая битва между Java и C++. Эти языки борются за второе место, а вот C заметно теряет популярность, уступая позиции C++ в мире встраиваемых систем. Что еще интересно, это то что PHP окончательно покинул топ-10 и уступил место Go. Go, кстати, закрепляется как серьезный игрок среди языков программирования. Я лично знакомлюсь с ним потихоньку чтобы можно было тестировать инфру хоть как-то (https://terratest.gruntwork.io/ — сделаю об этом пост в будущем).

Новички на горизонте: Rust, Zig и Mojo 🦾

Rust продолжает радовать скоростью своих программ, хотя его сложность обучения мешает стать массовым языком. Kotlin, увы, наоборот разочаровал — в 2024 году он даже выпал из топ-20. Зато на горизонте замаячили два новых претендента: Zig и Mojo.

Zig, конкурент Rust, поднялся с 149-го места на 61-е. А вот Mojo, более быстрая альтернатива Python, за два года с момента выхода взлетел с 194-го места на 68-е. Эксперты считают, что у Mojo есть все шансы войти в топ-20 уже в следующем году. И это неудивительно: он решает те самые проблемы, за которые критикуют Python.

Вобщем неудивительно что Python продолжает править балом, но мир программирования не стоит на месте. Старички вроде Java и C++ борются за место под солнцем, а новички вроде Mojo строят амбициозные планы. Что ж, 2025 год обещает быть интересным! А пока — пишем на Python, ведь, судя по всему, это еще надолго.

Ref: https://thenewstack.io/python-crowned-2024s-programming-king-driven-by-ai-ml/

Почему не надо использовать Deployments для баз данных 🙈

Доселе я использовал Deployments для развертывания баз данных. Понятный инструмент доступный каждому, обьяснен в каждом кубер туториале. Но как оказалось, иногда простота может обернуться настоящим кошмаром. Расскажу вам, что случилось.

Что было сделано 🚀

Я использовал базовый манифест для PostgreSQL под Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres-deployment
spec:
  ...
  template:
    ...
    spec:
      containers:
      - name: postgres
        image: postgres:13
        ports:
        - containerPort: 5432
          name: postgres
        env:
          ...
        volumeMounts:
        - name: postgres-storage
          mountPath: /var/lib/postgresql/data
      volumes:
      - name: postgres-storage
        persistentVolumeClaim:
          claimName: postgres-pvc
---
apiVersion: v1
kind: PersistentVolumeClaim
...

Что-то пошло не так 🤦‍♂️

Persistency? Не слышали.

Первым делом я заметил, что данные в моей базе данных начали исчезать. Да-да, именно исчезать. Оказывается, когда Pod'ы перезапускаются (а они это делают довольно часто), их Persistent Volume Claims не всегда привязываются к тем же самым Persistent Volumes. Итог: потеря данных.

> "Ага, ну ладно, просто нужно настроить PVC правильно," — подумал я. Но нет, даже после долгих попыток настройки, проблема оставалась.

Уникальные идентификаторы? 🆔

Дальше стало еще веселее. Все мои Pod'ы получили одинаковые лейблы и имена. В результате мой кластер PostgreSQL начал путаться и не мог определить, кто есть кто.

> "Ну ок, пусть все будут одинаковыми, главное, чтобы работало!" — решил я. Но нет, без уникальных идентификаторов никакого нормального функционирования кластера быть не могло.

Порядок операций? А что это? 📑

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

Что я понял в итоге 😅

Надо деплоить все БД через StatefulSets.

StatefulSets — это контроллер Kubernetes, предназначенный для управления stateful приложениями. Вот ключевые особенности, которые делают их незаменимыми для таких задач:

1. Устойчивое хранилище:
- Каждый Pod в StatefulSet получает собственный Persistent Volume (PV), который сохраняется даже после удаления Pod'а.

Пример:

   volumeClaimTemplates:
     - metadata:
         name: postgres-storage
       spec:
         accessModes: ["ReadWriteOnce"]
         resources:
           requests:
             storage: 10Gi
   

2. Уникальные идентификаторы:
- Каждый Pod имеет уникальное имя и сетевой идентификатор.

Пример:

   serviceName: "postgres"
   

3. Порядок операций:
- StatefulSet гарантирует последовательность операций: Pod'ы создаются и удаляются в строго определенном порядке.

4. Обновления без потери данных:
- StatefulSet поддерживает обновление приложений с минимальными рисками для данных.

Пример:

   strategy:
     type: RollingUpdate
   

5. Headless Service:
- StatefulSet использует headless service для создания уникальных DNS-записей для каждого Pod'а.

Пример:

   apiVersion: v1
   kind: Service
   metadata:
     name: postgres
   spec:
     clusterIP: None
     selector:
       app: postgres
   

Так что, если вы хотите сохранить свои нервы и избежать лишних проблем, используйте StatefulSets для управления stateful приложениями. Они обеспечивают надежность и стабильность, которые так необходимы для приложений с состоянием.

И да, жизнь слишком коротка для того, чтобы бороться с Kubernetes (все равно, без шансов)! Лучше использовать правильные инструменты для правильных задач.

Почему я выбрал DaemonSets для мониторинга нодов — история успеха 🚀

Когда дело доходит до управления кластером Kubernetes, выбор правильного контроллера может стать решающим фактором для успешной работы приложений. Знаю истории компаний где от кубера отказывались ровно по этой причине. Недавно я столкнулся с ситуацией, где использование обычных Deployments не помогло достичь желаемых результатов. В итоге решение оказалось простым: DaemonSets.

Что такое DaemonSets? 🤔

DaemonSets — это контроллер Kubernetes, который гарантирует, что на каждом (или на выбранных) узлах кластера будет запущен один экземпляр Pod'а. Это особенно полезно для задач, которые требуют постоянного присутствия на всех узлах, таких как мониторинг, логирование, сетевые сервисы и обеспечение безопасности.

Проблема: Когда Deployments не справляются 🙈

Недавно я работал над проектом, где нужно было обеспечить мониторинг всех узлов в кластере. Я решил использовать Deployment, чтобы развернуть агент мониторинга. Вот как выглядел мой манифест:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: monitoring-agent
spec:
  replicas: 5
  selector:
    matchLabels:
      app: monitoring-agent
  template:
    metadata:
      labels:
        app: monitoring-agent
    spec:
      containers:
      - name: monitoring-agent
        image: my-monitoring-agent:latest
        command: ["sh", "-c", "run.sh"]

На первый взгляд все казалось нормально. Но вскоре начались проблемы:

1. Не все ноды были покрыты. Поскольку Deployment распределяет поды случайным образом, некоторые узлы оставались без агента мониторинга.
2. Перегрузка нодов. Иногда несколько подов попадали на один и тот же узел, что создавало нагрузку и замедляло процесс мониторинга.
3. Проблемы с масштабированием. При добавлении новых узлов в кластер, они не сразу получали нужные поды, что приводило к задержкам в мониторинге.

Решение: Использование DaemonSets 🎉

Поняв, что Deployment не подходит для этой задачи, я перешел на DaemonSets.
https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/
Вот как выглядел обновленный манифест:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: monitoring-agent
spec:
  selector:
    matchLabels:
      app: monitoring-agent
  template:
    metadata:
      labels:
        app: monitoring-agent
    spec:
      containers:
      - name: monitoring-agent
        image: my-monitoring-agent:latest
        command: ["sh", "-c", "run.sh"]

Преимущества использования DaemonSets ➕

1. Каждая нода имеет свой собственный под.
2. Каждый узел получает только один под - обеспечивает равномерное распределение ресурсов.
3. При добавлении нового узла в кластер, DaemonSet автоматически разворачивает на нем необходимый под.
4. Управление демонсетами очень удобно, поскольку они автоматически адаптируются к изменениям в кластере.
5. Они так же гарантирует, что все ноды будут иметь актуальные данные и сервисы, что особенно важно для задач мониторинга и безопасности.

Так что, если вам нужно гарантировать наличие определенного пода на каждом узле кластера, DaemonSets — ваш бро.

Самые распространенные примеры приложений, использующих DaemonSets 🌟

DaemonSets часто используются для следующих типов приложений:

1. Мониторинг и метрики.
- Prometheus Node Exporter: Сбор метрик с каждого узла.
- Node Problem Detector: Обнаружение проблем с узлами и их отчетность.

2. Логирование.
- Logstash: Сбор и обработка логов с каждого узла.
- Filebeat: Сбор логов файловой системы и отправка их в Elasticsearch или другие системы аналитики.

3. Сетевые сервисы.
- Calico: Сетевой плагин для обеспечения безопасности и маршрутизации трафика.
- Cilium: Современный сетевой плагин, обеспечивающий высокую производительность и безопасность.

4. Безопасность.
- Falco: Инструмент для обнаружения аномалий и угроз в реальном времени.
- Aqua Security: Инструмент для защиты контейнеров и кластеров Kubernetes.

5. Бекапы.
- Velero: Автоматическое создание резервных копий данных с каждого узла.
- Kube-backup: Пользовательские решения для резервного копирования данных.

Обсудим как писать хорошие коммит-сообщения

Пишешь код для маленького пет проджекта или работаешь в ФАНГе, хорошие коммит-сообщения играют важную роль. Они помогают твоей команде и, что по-моему более важно, самому себе понять, что было сделано, почему и как это влияет на проект. Прочитал статью https://how-to-write-good-commit-messages.hashnode.dev/how-to-write-good-commit-messages и сейчас быстренько по ней пробегусь.

Почему важно писать хорошие коммит-сообщения? 🤔

Хорошее коммит-сообщение может спасти от нескольких проблем.

1. Когда работаешь долго над проектом, становится сложно помнить, что было сделано в каждом коммите. Хорошее сообщение поможет быстро найти нужный коммит.
2. Облегчение работы с pull requestами -- четкое и понятное сообщение упрощает процесс ревью кода и интеграции изменений.
3. Если кто-то другой будет работать над вашим проектом, он сможет быстрее понять, что было сделано, и избежать повторения этой саой уже проделанной работы.

Основные правила написания коммит-сообщений 📝

1. Первое правило: краткость — сестра таланта
- Сообщение должно быть коротким и ясным. Идеальная длина — 50 символов или меньше. Это позволяет легко читать историю коммитов в консоли.

Пример:

   Fix bug in user authentication
   

2. Второе правило: Более подробное описание
   - Если требуется дополнительное объяснение, используй пустую строку после краткого описания и добавь более детальное объяснение. Здесь можно указать причины изменений, а также любые другие важные детали.
   
   Пример:
   

   Refactor login form validation
   
   - Removed redundant checks for empty fields.
   - Added unit tests for new validation logic.
   

3. Третье правило: Используй повелительное наклонение
   - Начинай сообщения с глаголов в повелительном наклонении. Это делает сообщения более активными и понятными.
   
   Пример:
   

   Add feature flag for new dashboard
   

4. Четвертое правило: Избегай общих фраз
   - Не пиши такие вещи, как "Fix bugs" или "Update code". Укажи конкретно, что именно было исправлено или обновлено.
   
   Пример:
   

   Fix issue with infinite loop in data processing
   

Лайфхаки для написания отличных коммит-сообщений 💡

1. Используй шаблоны:
   - Создай шаблоны для коммит-сообщений. Это поможет всегда следовать одной структуре и не забывать важные элементы.
   
   Пример шаблона:
   

   <type>(<scope>): <subject>
   
   <body>
   

2. Создай проверку перед коммитом:
   - Используйте хуки Git (например, pre-commit) для проверки ваших коммит-сообщений. Это своего рода линтер который поможет избежать ошибок и следовать установленным правилам.
   
   Пример скрипта для проверки:
   

   #!/bin/sh
   if ! grep -qE '^(feat|fix|chore|docs|style|refactor|perf|test)(\(.+\))?: .{1,50}$' "$1"; then
     echo "Invalid commit message format"
     exit 1
   fi
   

3. Регулярно пересматривай свои коммиты:
- Перед тем как отправлять изменения в основную ветку, просмотри свои коммиты. Объедини мелкие изменения и переформулируй сообщения, если это необходимо.

Вобщем, написание хороших коммит-сообщений — это искусство, которое можно освоить. Каждое сообщение должно быть четким, понятным и полезным для тебя, команды и менеджера (не дай бог он станет смотреть их).

Разберем Jobs и CronJobs в Kubernetes 🚀

Дело в том, что в кубере помимо написания манифестов для сервисов, стейтфулсетов и деплойментов приходится еще выполнять иногда однократные задачи. Например, какая-то единоразовая обработка данных, генерация отчетов или выполнение миграций БД. И если поды которые задеплоены через deployments, statefulsets или daemonsets всегда "онлайн" и пересоздаюся как только что-то с одним из них случается, вышеперечисленные задачи должны выполниться раз (и иногда по расписанию) и потом больше не ранится. Jobs и CronJobs ровно про это.

Что такое Jobs и CronJobs? 🤔

Jobs в Kubernetes предназначены для выполнения однократных задач, которые нужно завершить до конца. Помимо тех что я указал в начале, дальше еще 7 интересных юзкейсов.

1. Обработка big data:
- Выполнение ETL (Extract, Transform, Load) процессов для обработки и трансформации больших объемов данных.

2. Бекапы:
- Создание резервных копий баз данных или файловых систем на регулярной основе. Например, создание снапшотов базы данных или архивирование логов.

3. Тестирование приложений:
- Запуск интеграционных тестов или нагрузочного тестирования после развертывания новых версий приложения.

4. Анализ логов:
- Периодический анализ логов для выявления ошибок, предупреждений или других важных событий.

5. Пакетная обработка:
- Например отправка уведомлений по емейл или SMS, обновление пользовательских профилей и тд.

6. Обучение моделей ML:
- Тренировка моделей машинного обучения на больших наборах данных. Это может включать подготовку данных, обучение модели и оценку её точности.

7. Интеграция с внешними системами:
- Выполнение задач интеграции с внешними системами, такими как API вызовы для получения данных, импорт/экспорт данных между различными платформами и тд.

CronJobs же позволяют планировать выполнение таких задач по расписанию. Это тот же cron из Linux.

Проблема: Когда всё делается вручную 🙈
Есть например перед нами задача регулярной очистки временных файлов на сервере. Звучит просто: написать скрипт, засунуть его в crontab и забыть о проблеме. Но, как оказалось (вот так сюрприз) это далеко не самый оптимальный путь.

- Тут и человеческий фактор - обычно человек забывает обновлять скрипт после каждого изменения конфигурации.
- И отсутствие контроля - в таком сетапе нет никакого логирования, никакой возможности быстро понять, что пошло не так.
- Ну и масштабирование - когда количество серверов увеличилось, стало сложно следить за всеми этими скриптами.
В общем, ситуация начинает быстро выходить из под контроля и пора переходить на более современные инструменты.

Решение: Автоматизация с помощью Jobs и CronJobs 🎉
Вот как будет выглядеть новый процесс:

Пример 1: Однократная задача с использованием Job
Все та же задача с очисткой временных файлы на одном из серверов. Вместо того чтобы делать это вручную, создаем Job:

apiVersion: batch/v1
kind: Job
metadata:
  name: cleanup-temp-files
spec:
  template:
    spec:
      containers:
      - name: cleanup
        image: my-cleanup-image:latest
        command: ["sh", "-c", "rm -rf /tmp/*"]
      restartPolicy: Never

На выходе:

- Задача была выполнена автоматически и без ошибок.
- Логи были доступны в Kubernetes, что позволило легко отследить процесс.
- Больше никаких ручных действий.

Пример 2: Периодическая задача с использованием CronJob

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

apiVersion: batch/v1
kind: CronJob
metadata:
  name: cleanup-temp-files
spec:
  schedule: "0 2 * * *"  # Каждую ночь в 2 часа
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: cleanup
            image: my-cleanup-image:latest
            command: ["sh", "-c", "rm -rf /tmp/*"]
          restartPolicy: OnFailure

Так что, если нужно автоматизировать выполнение однократных и переодических задач в кубере, то используем Jobs и CronJobs. Они обеспечивают автоматизацию и контроль, которые так необходимы для современных DevOps-практик.

CI/CD в реальной жизни 🌿

CI/CD все чаще употребляется как какой-то абстрактный термин и по-моему любой пайплайн уже стали называть CI/CD. Я с этим не согласен, и в этой статье https://lovishgoyal.hashnode.dev/demystifying-cicd-with-real-life-analogies автор приводит аналогии CI/CD с жизнненными вещами.

Обязан сказать пару слов про CI/CD как из учебника. Ок.

CI (Continuous Integration) — это процесс непрерывной интеграции кода в основную ветку проекта. Каждый раз, когда разработчик делает коммит, система автоматически собирает и тестирует изменения, чтобы убедиться, что все работает корректно.

CD (Continuous Deployment) — это следующий шаг, где после успешной интеграции код автоматически разворачивается в продакшен-среду.

3️⃣ примера из жизни

Аналогия с пекарней 🍞

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

Теперь представьте, что у вас есть автоматическая линия, которая проверяет качество всех ингредиентов перед тем, как они попадут на производство. Это как CI — каждая новая партия ингредиентов проходит через строгую проверку, чтобы убедиться, что все в порядке.

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

Аналогия с рестораном 🍽

Другая аналогия — это ресторан. Каждый заказ состоит из нескольких шагов: приготовление блюд, сервировка и подача клиенту. Если что-то пойдет не так на любом этапе, клиент может остаться недоволен.

Теперь представьте, что у вас есть автоматическая кухня, которая проверяет качество всех ингредиентов перед тем, как они попадут на плиту. Это CI — каждая новая партия продуктов проходит через строгую проверку, чтобы убедиться, что все в порядке.

После того, как блюдо приготовлено, оно автоматически отправляется на сервировку и подается клиенту. Это как CD — после успешной проверки ингредиентов и приготовления блюда, оно автоматически доводится до клиента. Типа такого, видели?

Аналогия с онлайн-шопингом 🛒
Представьте себе процесс заказа новой пары кроссов онлайн. 👟 Вы выбираете их, размещаете заказ, и получаете свою покупку прямо домой, не выходя из дома. Это как Continuous Deployment в действии: автоматизация доставляет продукт непосредственно вам.

Немного примеров манифестов CI/CD

GitLab CI:

stages:
  - build
  - test
  - deploy

build:
  stage: build
  script:
    - docker build -t myapp:$CI_COMMIT_SHA .
    - docker push myapp:$CI_COMMIT_SHA

test:
  stage: test
  script:
    - ./run-tests.sh

deploy:
  stage: deploy
  script:
    - kubectl apply -f k8s/deployment.yaml

ArgoCD:

application:
  name: myapp
  source:
    repoURL: 'https://gitlab.com/myorg/myrepo.git'
    targetRevision: main
    path: k8s
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: default

Закончу быстрым перечислением преимуществ CI/CD ➕

1. Автоматизация процесса:
- Все шаги от сборки до развертывания выполняются автоматически, что экономит время и снижает риск ошибок.

2. Быстрая обратная связь:
- Команды получают быстрый фидбек о состоянии сборки и тестирования, что ускоряет процесс разработки.

3. Удобство управления:
- Инструменты CI/CD позволяют легко управлять конвейерами и отслеживать их состояние.

4. Гарантия качества:
- Автоматические тесты обеспечивают высокое качество кода и уменьшают количество багов в продакшене.

5. Быстрое развертывание:
- Изменения мгновенно применяются например в кубер кластере, что ускоряет вывод продукта на рынок.

Почему бэкапы — это важно, и как их настроить с помощью rsnapshot? 💾

Если вы сисадмин или просто нормальный юзер Пи-Си, одна из ваших обязанностей — создание резервных копий. Потому что каждый раз когда мы теряем данные - нам это может очень сильно аукнутся.

Для пользователей Linux существуют десятки инструментов для создания бэкапов: от мощных ентерпрайз решений до бесплатных и простых утилит. Сегодня я расскажу о rsnapshot — удобном и лёгком в использовании инструменте для создания снепшотов файловой системы, который доступен практически в каждом стандартном репозитории.

Сейчас настроем простое и бесплатное решение для резервного копирования. Погнали.

Что потребуется? 🧺

Для работы с rsnapshot нужно:
- Любая рабочая система на Linux.
- Пользователь с правами sudo.
- Внешний диск или другой носитель для бекапа.

Всё это у вас есть? Тогда начнём установку.

Установка rsnapshot 🔧

Установка rsnapshot максимально проста, так как он находится в большинстве стандартных репозиториев. Вот примеры команд для разных дистрибутивов:

- Ubuntu/Debian: sudo apt-get install rsnapshot -y
- Fedora/RHEL: sudo dnf install rsnapshot -y
- Arch Linux: sudo pacman -Sy rsnapshot

Чтобы убедиться, что rsnapshot установлен: which rsnapshot. Если всё прошло успешно, вы увидите путь к исполняемому файлу, например: /usr/bin/rsnapshot. Теперь можно перейти к настройке.

Настройка rsnapshot 🔌

1. Создаем папку для бэкапов
Предположим, у вас есть внешний диск, смонтированный как /dev/sdb1. Создайте каталог для резервных копий: sudo mkdir -p /data/rsnapshot
Затем смонтируйте диск в эту папку: sudo mount /dev/sdb1 /data/rsnapshot
Чтобы это монтирование сохранялось после перезагрузки, добавьте запись в файл /etc/fstab: /dev/sdb1 /data/rsnapshot ext4 defaults 0 0

2. Делаем резервную копию конфиг файла
sudo cp /etc/rsnapshot.conf /etc/rsnapshot.conf.bak

3. Откроем конфигурационный файл: sudo nano /etc/rsnapshot.conf
Убедимся, что строка snapshot_root указывает на созданную папку: snapshot_root /data/rsnapshot
⚠️ Используйте табуляцию, а не пробелы, иначе конфигурация не будет работать.
В разделе BACKUP LEVELS / INTERVALS укажем частоту и количество сохраняемых резервных копий:

retain daily 6
retain weekly 7
retain monthly 4

Это сохранит 6 ежедневных, 7 еженедельных и 4 ежемесячных резервных копии.
В разделе LOCALHOST добавим каталоги, которые надо забекапить. Например:
backup /home localhost
Это создаст резервные копии папки /home.

4. Проверим конфиг
sudo rsnapshot configtest
Если всё в порядке, вы увидите: Syntax OK.

Первое резервное копирование
Чтобы выполнить резервное копирование вручную, используйте команду: sudo rsnapshot daily

После завершения вы увидите новый каталог, например /data/rsnapshot/daily.0, где будут находиться ваши резервные копии.

Автоматизация с помощью Cron 🚗

Чтобы не запускать бэкапы вручную, создадим автоматизацию:

1. Создаем скрипт для ежедневного бэкапа: nano daily.sh
2. Вставляем в файл:

#!/bin/bash
   rsnapshot daily

3. Сохраняем файл, затем переместим его в /usr/local/bin: sudo mv daily.sh /usr/local/bin
4. Сделаем файл исполняемым: sudo chmod u+x /usr/local/bin/daily.sh
5. Добавим задание в crontab: sudo crontab -e
6. Добавим строку для ежедневного запуска в полночь: 00 00 * * * /usr/local/bin/daily.sh

Теперь rsnapshot будет автоматически создавать ежедневные бэкапы. Аналогичным образом можно настроить еженедельные и ежемесячные задания.

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

Почему гиперскейлеры возвращаются домой, или как я познакомился с NVMe-oF 🔌

Тенденции в мире IT — это как мода: то облака везде, то "давайте всё обратно в дата-центр, но с изюминкой". Всё чаще компании возвращают свои рабочие нагрузки из паблик облака обратно "домой", в свои дата-центры. Но делают это не просто так, а с умом: модернизируют центры под cloud-native приложения или даже строят свои "мини-облака". Почему? Потому что хочется сочетать контроль над инфраструктурой с облачной гибкостью и автоматизацией. Да, и пирожок съесть, и сами знаете дальше.

Недавно я познакомился с одной компанией, которая прошла этот путь, а в центре их модернизации оказалась технология NVMe-oF (NVMe over Fabrics). Их опыт показал, как современные подходы к работе с хранилищами меняют игру. Давайте разберёмся, как они это сделали.

Что такое NVMe-oF и зачем нам это ؟

Если коротко, NVMe-oF (NVMe over Fabrics) — это способ делать с вашим хранилищем то, что раньше казалось фантастикой. Вы, грубо говоря, берёте суперскоростной NVMe, а потом растягиваете его по сети так, словно это локальное устройство. И всё это с минимальными задержками и максимальной скоростью.

Сначала в компании отнеслись к этой технологии скептически, но задача требовала серьёзной оптимизации работы с огромными объёмами данных для AI-аналитики. И вот здесь NVMe/TCP (один из протоколов NVMe-oF) продемонстрировал, на что он способен.

Как это работало на практике 📝

Компания начала с тестирования open-source решения с поддержкой NVMe/TCP на существующей Ethernet-инфраструктуре. Это сразу стало плюсом — никакого дорогостоящего оборудования не понадобилось. Первое, что заметили, — минимальные задержки. Если раньше операции занимали миллисекунды, то теперь речь шла о микросекундах. Это дало их AI-платформе возможность обучать модели быстрее и проводить аналитику в режиме реального времени.

Масштабируемость тоже сыграла ключевую роль. Когда данные начали расти в геометрической прогрессии (классика для ML-проектов), не пришлось модернизировать всю инфраструктуру. Достаточно было добавить пару хранилищ в общий пул — и всё заработало без перерывов.

Особенно интересно, что NVMe/TCP отлично интегрировался с Kubernetes-кластером компании. С помощью плагина для CSI (Container Storage Interface https://kubernetes.io/blog/2019/01/15/container-storage-interface-ga/) поды начали автоматически выбирать подходящее место для хранения данных. Этот процесс полностью автоматизировали, что сильно упростило работу DevOps-команды.

Какие преимущества они отметили 🌟
1. Эффективность и экономия: Возможность консолидации хранилищ позволила сократить избыточные ресурсы и снизить затраты на 20%. Кроме того, освободилось место в серверной, что тоже оказалось полезным.
2. Минимальная задержка: Результаты, которые раньше требовали времени “на перекур”, теперь появляются за считанные секунды. Это существенно ускорило процессы аналитики и обработки данных.
3. Простота масштабирования: Добавить новое хранилище стало так же просто, как подключить флешку. Никаких сложных настроек или перерывов в работе.

Что дальше? ⏩

Эта компания планирует продолжить использование NVMe/TCP и даже рассматривает перевод старой SAN-инфраструктуры на новую технологию. Это экономически выгодно, проще в поддержке и обеспечивает готовность к будущим нагрузкам.

Сейчас NVMe-oF остаётся относительно новой технологией, но её потенциал сложно переоценить. Высокая скорость, гибкость и масштабируемость делают её идеальным решением для задач AI, финтеха и других интенсивных нагрузок. И хотя внедрение NVMe-oF ещё не стало массовым, будущее явно за такими технологиями.

Netkit: Быстрее, проще, эффективнее — или как ByteDance ускоряет свои контейнеры 🚀

Когда дело касается IT-новинок, я обычно скептично прищуриваюсь, думая: "Ну, что они там опять придумали?" Но вот недавно наткнулся на новость про новую фичу Linux-ядра — netkit. Немного вник и понял что вещь нормальная.

Netkit — это нововведение, появившееся в ядре Linux 6.7 в декабре 2023 года. Его главная задача — упрощать и ускорять сетевое взаимодействие контейнеров. Если вы работали с контейнерами, то наверняка знакомы с Virtual Ethernet (veth). Это старый добрый интерфейс, который с нами с 2008 года, но, как оказалось, он не без греха. Например, каждый пакет данных в veth вынужден дважды проходить через сетевой стек — и у отправителя, и у получателя. Даже если оба контейнера находятся на одном сервере. Это что-то на древнем.

И вот тут на сцену выходит netkit. Он, благодаря интеграции в ядро и магии eBPF, позволяет "поймать" пакеты до того, как они начнут свое длинное путешествие через сетевой стек, если оба контейнера находятся на одном хосте. Например сетевики ByteDance (создатели тиктока) утверждают, что благодаря этому они добились 10% прироста производительности и заметного снижения нагрузки на CPU. Красота, правда?

Но тут есть одно "но". Для использования netkit требуется ядро версии 6.7 или выше. А у ByteDance, как оказалось, многие сервера до сих пор работают на ядре 5.15. И вот это меня особенно впечатлило: ребята не стали ждать несколько лет, пока все обновится. Они взяли и бэкпортировали eBPF в свою версию ядра. Это же классика DevOps: если чего-то нет — мы это сделаем сами.

На этом их креатив не закончился. Они также обновили свою CNI (Container Network Interface) и даже разработали специального агента для управления eBPF-программами. Такой подход позволил им начать плавный переход на netkit, не устраивая революцию на своих серверах. Старые контейнеры продолжают работать с veth, а новые уже используют netkit. Если что-то пойдет не так, всегда можно откатиться на проверенный veth. По-моему это очень классный пример лучших ДевОпс практик и это одновременно и canary и blue-green в одном флаконе.

Для работы с netkit не требуется ничего сверхъестественного, кроме настройки через netlink, можно даже попробовать самому. Первым делом надо обновить тестовое окружение до ядра 6.7 (если нет таких ограничений, как у ByteDance). Затем с помощью библиотеки golang netlink создать netkit-устройство и подключить eBPF-программу для оптимизации. Звучит сложно но как я понял по сложности что-то на уровне настройки veth. На выходе получим уменьшение времени отклика между контейнерами.

Почему ByteDance так вдохновилист netkit? Наверное, для таких гигантов с миллиардами пользователей и высокими требованиями к производительности это идеальное решение. Но и для нас, обычных инженеров, которым просто хочется немного больше скорости и меньше головной боли с настройкой сетей, netkit — это настоящая находка.

Так что, если вы еще не заглядывали в сторону netkit, рекомендую присмотреться. Это как найти новый инструмент в старом ящике с инструментами, который оказывается в разы лучше всего, что у вас было раньше.

Не могу не прокомментировать DeepSeek 🐳

Всегда здоров смотреть когда мировая политика и передовые технологии сталкиваются, будто в эпизоде "Черного зеркала", но без саундтрека. Последние события вокруг китайской AI-компании DeepSeek и обсуждений американских экспортных ограничений – это именно такой случай, где IT становится оружием геополитики. И, признаюсь, наблюдать за этим без участия уже невозможно, особенно если ты, как я, любишь прикладные эксперименты.

Итак, представьте себе картину: DeepSeek – компания из Китая 🇨🇳 – создает модель AI, которая почти догоняет американские аналоги, но с временным отставанием на 7-10 месяцев. Это что-то вроде того, как если бы кто-то скопировал Tesla Model S, но сделал ее чуть медленнее, зато за треть цены. Дарио Амодеи, CEO Anthropic, не скрывает: китайские инженеры очень талантливы, но экспортные ограничения США все же замедляют их развитие. Однако ключевое слово здесь – "замедляют", но не "останавливают".

Теперь вишенка на этом AI-торте: DeepSeek якобы сократили затраты на обучение своих моделей, что выглядит как шаг вперед для индустрии. Например, их новый флагман DeepSeek V3 упоминается как конкурент Claude 3.5 Sonnet от Anthropic. Я, кстати, в свое время пробовал работать с Claude 3.5 в одном из своих проектов. Если коротко, эта штука на удивление хорошо справлялась с генерацией сложных аналитических отчетов и даже помогла автоматизировать часть DevOps-рутины. Надо было видеть лица коллег, когда система сама писала terraform-скрипты, которые еще и работали! Но, конечно, цена в "несколько десятков миллионов долларов" на обучение вызывает вопрос: а можно ли дешевле? DeepSeek как будто намекает, что да.

С другой стороны, Амодеи не без иронии отмечает, что технологии, которые DeepSeek придумали, скоро окажутся в арсенале и США, и других стран. Это как патч для Kubernetes: сегодня ты его выкладываешь в open source, завтра его используют все, включая конкурентов. Такая уж природа технологий.

Но здесь начинается большой политический танец: если администрация Трампа усилит экспортные ограничения на чипы, то, возможно, США смогут удержать лидерство в этой гонке. В противном случае Китай может направить свои ресурсы на разработку AI для военных целей, что, мягко говоря, не добавляет оптимизма. Для нас это звучит как очередной аргумент в пользу создания "честных" технологий, которые не превращаются в оружие.

В завершение скажу: эта история показывает, что IT и политика – это не просто параллельные миры. Они давно уже пересеклись, и нам, айтишникам, приходится решать, на какой стороне мы хотим быть. Лично я предпочел бы ту, где AI помогает людям, а не становится еще одним инструментом противостояния. Но, как говорится, время покажет. 🤔

Zentyal: неужели Linux может быть так похож на Windows Server? 🐼

Вы когда-нибудь мечтали объединить гибкость Linux с удобством Windows Server? Нет? Значит вы нормальный человек. Это дистрибутив Linux, который пытается быть одновременно функциональным и дружелюбным. Да, звучит как оксюморон, но, как оказалось, Zentyal вполне справляется с этой задачей.

Почему Zentyal ؟

Наверное все хорошо знают серверные дистрибутивы такие как RHEL, AlmaLinux или Rocky Linux. Они хороши, но что, если вам нужен "всё-в-одном" вариант? Тут на сцену выходит Zentyal. Этот дистрибутив основан на Ubuntu 22.04, но заточен на то, чтобы заменить Windows Server. И дело не только в возможности поднять домен или почтовый сервер — список возможностей Zentyal поражает: от VPN и firewall до управления Docker-контейнерами и антивируса.

Мой опыт 💻

Я решил пощупать Zentyal в действии, запустив его в виртуальной машине с помощью VirtualBox. Да, живем в 2025, а я все еще использую VirtualBox.

Установка 🔧

Установка Zentyal была настолько простой, что даже сложно поверить. Всего несколько кликов, и вот он, приветливый экран логина. Никаких танцев с бубном, никаких "почему этот модуль не компилируется?". Для Linux-энтузиаста, привыкшего к боли, это как будто праздник.

Первая настройка 🔌

Как только я залогинился, Zentyal автоматически открыл браузер с мастером настройки. Это не просто удобно, это вдохновляет! Мастер предложил выбрать, какие модули мне нужны, от почты до IDS/IPS (система обнаружения и предотвращения вторжений). После выбора модулей и пары кликов началась установка. И тут, внимание, на экране появился милый панда. Мелочь, а приятно.

Конфигурация сети 🛜

После установки модулей меня попросили настроить сеть. В моем случае все было просто, так как у виртуальной машины только один интерфейс. Далее нужно было выбрать роль сервера: автономный или дополнительный контроллер домена. Я остановился на автономном варианте — для тестов мне этого хватило.

Альтернативный подход: установка на существующий сервер Ubuntu

Если у вас уже есть сервер на Ubuntu, вы можете установить Zentyal поверх него. Это делается буквально тремя командами в терминале:

1. Скачиваете инсталляционный скрипт:

   wget https://raw.githubusercontent.com/zentyal/zentyal/master/extra/ubuntu_installers/zentyal_installer_8.0.sh

2. Даете ему права на выполнение:

   sudo chmod u+x zentyal_installer_8.0.sh

3. И запускаете установку:

   sudo ./zentyal_installer_8.0.sh

После этого вы можете зайти в веб-интерфейс по адресу https://SERVER:8443/, где SERVER — это IP вашего сервера.
Zentyal — это как швейцарский нож среди серверных дистрибутивов. Он не идеален и требует времени на изучение, но его интерфейс и возможности делают его отличным выбором для малого и среднего бизнеса. Лично меня порадовало, что даже сложные задачи типа настройки SSL сертификатов тут вполне посильны.

KEPы, процесс и немного магии: что нового в Kubernetes SIG Architecture 🕌

Столкнулся недавно с концепцией SIG (Special Interest Groups) — групп, работающих над различными аспектами Kubernetes. В этот раз я решил углубиться в SIG Architecture и, в частности, их работу над "Enhancements" (улучшениями). И, честно говоря, это не просто набор скучных бюрократических процедур, а скорее настоящая инженерная алхимия. Готовьте кофе: будем разбираться, зачем нужны KEPы (Kubernetes Enhancement Proposals) и как они меняют игру.

Что такое SIG Architecture и их "Enhancements"? ✨

SIG Architecture — это, по сути, мозговой центр Kubernetes, занимающийся архитектурными решениями и улучшениями. А вот подгруппа Enhancements, как оказалось, отвечает за всю магию KEPов. KEP — это стандартизированный документ, который обязателен для всех новых фич или значительных изменений в Kubernetes. Представьте себе, что это паспорт вашей идеи: от её появления до внедрения в кодовую базу проекта.

Когда я впервые столкнулся с этим процессом, он показался мне чем-то вроде бюрократического лабиринта. Почитал побольше и понял - это не просто способ "узаконить" изменения — это инструмент для детального обсуждения, анализа и устранения рисков.

KEP: инженерный контроль качества 🌟

Чтобы понять, почему KEPы так важны, нужно представить себе типичный рабочий цикл Kubernetes. Каждое новое изменение проходит три стадии: alpha, beta и GA (general availability). И на каждом этапе KEP выступает как главный источник правды о фиче. Здесь описывается не только дизайн и мотивация, но и то, как это повлияет на стабильность и производительность системы.

Эволюция процесса: от таблиц к GitHub Project Boards 📋

Одна из ключевых модернизаций в работе SIG Architecture — отказ от сложных таблиц в пользу GitHub Project Boards. Как человек, который однажды пытался свести все свои задачи в таблице Excel, я могу только аплодировать такому решению. Теперь трекинг улучшений стал прозрачным и интегрированным в экосистему GitHub.

Что дальше? ⏭️

SIG Architecture не останавливается на достигнутом. Среди их текущих инициатив — внедрение версии KEPов и создание шаблонов для процессных изменений (а не только функциональных). Это звучит как следующий уровень упорядочивания хаоса, и я уже предвкушаю, как это упростит жизнь всем нам, кто работает с Kubernetes.

Как подключиться? 🤔

Если вам интересно поучаствовать в работе SIG Architecture, вам не обязательно быть гуру Kubernetes. Главное — желание разобраться в KEPах и немного времени на изучение репозитория [kubernetes/enhancements](https://github.com/kubernetes/enhancements). Поверьте, это может стать отличным шагом в вашем карьерном развитии.

Процесс работы над KEPами — это не просто формальность, а настоящий пример инженерного перфекционизма. SIG Architecture делает огромный вклад в то, чтобы Kubernetes оставался стабильной и предсказуемой платформой. И, хотя иногда это требует усилий и времени, конечный результат того стоит. Ведь в мире, где контейнеры и оркестрация — это уже не просто тренд, а необходимость, такие процессы играют ключевую роль.

AI атакует open source фейковыми запросами 🤥

История про то как ИИ может выступать в роли помощника в open source проектах и все зафакапать: https://thenewstack.io/ai-is-spamming-open-source-repos-with-fake-issues/. Такой идеальный стажер, который всё делает сам: чинит баги, оптимизирует код и приносит утренний кофе. Казалось бы, звучит прекрасно но в реальности все как всегда оказалась гораздо хуже.

Открываешь репозиторий — а там спам-фест 📧

Давайте перенесёмся в реальный мир. Jarek Potiuk, мейнтейнер Apache Airflow, однажды обнаружил, что количество открытых запросов внезапно подскочило с привычных 20-25 до целых 50 в день. “Отлично!” — подумал он сначала. А потом начал читать эти запросы и понял, что это не взрыв популярности проекта, а просто взрыв бессмыслицы.

Некоторые из тикетов были обычной копипастой уже существующих, другие предлагали бессмысленные улучшения. А в чем проблема? Несколько настоящих PRов, созданных людьми, случайно закрыли вместе с этим мусором.

Кто за этим стоит? 🥸

Виновником неожиданно стала платформа Outlier AI, которая обучает людей и ИИ взаимодействовать с open source проектами. Казалось бы, благая идея, но пользователи решили тестировать свои “навыки” не на локальных данных, а на реальных репозиториях. В результате — ни пользы, ни веселья.

Outlier уверяет, что это было недоразумение и инструкции уже изменили. Ну да, конечно. А как быть с потраченным временем мейнтейнеров?


Что делать? 🫥

Если вы мейнтейнер, то надо сделать так:
- Настройть фильтры для входящих запросов. Даже простой скрипт может отсечь значительную часть спама.
- Сообщить о подобных случаях GitHub. Чем больше мы об этом говорим, тем быстрее появятся решения.
- Помнить, что ИИ — всего лишь инструмент. Пока он больше похож на нуб-стажера, который искренне старается, но всё время что-то путает.

Не забываем про здравый смысл и немного скепсиса. Возможно, когда-нибудь ИИ действительно станет помощником.

Chainguard

Нашел прикольную вещь Chainguard - https://www.chainguard.dev. DevOps и SRE инженерам уже прожужжали все уши про CVE в контейнерах. Они буквально напичканы CVE (уязвимостями). Вообще, CVE — это система, которая предоставляет общепринятые (обществом секьюрити) идентификаторы для уязвимостей в программном обеспечении и системах. Это как если бы вы купили новую машину, а в комплекте шли бы ржавые тормоза 🪓 — вы знаете, что что-то нужно чинить, но откуда начинать? Так вот Chainguard предложила свой подход в решение данной проблемы

Почему бы просто не начать с чистого листа? 🧼

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

Chainguard решила пойти другим путем: вместо того чтобы брать готовый образ и вырезать из него ненужное, они начинают с пустого контейнера и добавляют только то, что действительно необходимо. Например, для Python-образа они добавляют минимальный набор зависимостей, чтобы язык работал, — и ничего лишнего. Такой подход позволяет не только уменьшить размеры контейнеров, но и, что самое главное, избавиться от CVE.

Wolfi: их свой Линупс 🐺

В основе подхода Chainguard лежит их собственная Linux дистриб под названием Wolfi — точнее, даже "не-дистриб". Это минималистичная, специально созданная операционная система, которая изначально проектировалась с учетом безопасности CI/CD. Ее цель — быть настолько чистой и безопасной, чтобы вы могли сосредоточиться на разработке, а не на патчинге.

Визуализация CVE: цифры говорят за себя 📊

Недавно Chainguard представила новую фичу для своей консоли — визуализацию CVE. Теперь компании могут видеть, сколько уязвимостей было устранено в их контейнерах за время использования Chainguard, и, что не менее важно, сколько времени их команды сэкономили, не занимаясь этим вручную.

По-моему выглядит круто, хотя бы для внутреннего обоснования бюджета. Представьте, что вы можете показать своему руководству график: "Вот, сколько часов работы мы сэкономили благодаря Chainguard, и вот, сколько денег это сэкономило компании". Это не только помогает защитить выбор технологии, но и укрепляет доверие к принятым решениям.

Почему мы вообще это терпим? 🤡

Вопрос, который задает Chainguard, звучит почти философски: почему мы смирились с тем, что в ПО всегда будут уязвимости? В мире физической безопасности, например, никто не станет продавать вам еду с пометкой "может содержать смертельные бактерии, но вы же все равно их сварите". Так почему в IT мы принимаем это как норму?

Мне по сути нравится такой подход - предлагают контейнеры, которые изначально безопасны. Это не просто маркетинговый слоган, а реальная возможность пересмотреть подход к разработке и эксплуатации ПО.

Что дальше? 📡

Chainguard уже предлагает более 1200 CVE-чистых образов, и их число растет. Кроме того, компания расширяет свои решения на работу с AI и LLM, что делает их подход еще более актуальным.

Так что, если вы устали от постоянного патчинга, бесконечных проверок на уязвимости и ощущения, что ваша безопасность зависит от удачи, возможно, стоит дать Chainguard шанс.

Telemetry, agents, collectors: observability термины которые гоняют на DevOPS интревью 📡

Раньше как было - выбор стека observability был почти бинарным решением - либо выбираешь готового вендора, либо уходишь с головой в open source. Третьего не дано. Но времена меняются, и стандарты вроде OpenTelemetry и Prometheus стерли эти границы. Теперь можно смешивать вендорские решения с open source, создавая свой идеальный стек.

Звучит круто? Но есть и обратная сторона медали: термины в обсервабилити используются как попадется. Когда даже эксперты не могут сойтись на едином определении APM (Application Performance Monitoring), как тут быть новичкам? Даже после десяти лет работы в этой сфере я порой ловлю себя на мысли, что мои мозги вот-вот взорвутся от очередной волны новых терминов.

Возьмем, к примеру, telemetry pipelines. Когда я впервые услышал этот термин, вопросов было больше, чем ответов. Это продукт? Категория инструментов?
Telemetry pipeline — это система, которая собирает, обрабатывает и перенаправляет телеметрию (логи, метрики, трейсы) из разных источников в разные инструменты анализа. Вместо того чтобы управлять отдельными агентами или коллекторами для каждого сигнала, пайплайн объединяет все это в единую маршрутизацию.

А что тогда агенты и коллекторы? 🤖

Вот тут начинается самое интересное.

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

- Коллекторы — это что-то вроде регионального сортировочного центра. Они собирают данные от нескольких агентов (или напрямую от приложений) и перенаправляют их в конечный пункт назначения.

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

Практика: OpenTelemetry и Fluent Bit 📝

На примере OpenTelemetry Collector — это, по сути, telemetry pipeline. Он может действовать как агент (сбор данных на входе) или как шлюз (централизованный хаб обработки данных).
Fluent Bit тоже выполняет функции telemetry pipeline: собирает, обрабатывает и маршрутизирует данные. Но и здесь терминология может запутать. Например, "pipeline" в Fluent Bit может означать как весь инструмент, так и конкретные маршруты внутри него.

Выводы

Да, это только вершина айсберга - каждый вендор и каждая команда интерпретируют слова по-своему. Но понимая общие принципы, вы сможете не только разобраться в терминах, но и построить telemetry pipeline, который будет работать именно для нужд вашей компании.

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

Голова лишняя? Добро пожаловать в мир headless observability!
Observability это всегда ТБ логов которые ежедневно плодятся. А их хранение и анализ стоят очень дорого. Плюс, если добавить к этому vendor lock, то хочется порой отказаться от этой observability. Тут подоспело решение - headless observability. Обсудим.

Что за зверь такой — headless observability?

Если коротко, это подход, который разделяет фронтенд (визуализация, запросы, аналитика) и бэкенд (хранение и обработка данных). На выходе - гибкость и возможность использовать данные для разных задач (например, для аналитики или ML) и плюс неплохая экономия. Это как лего для логов: можно собрать свою идеальную систему из отдельных блоков, а не покупать монолитный набор, где половина деталей будет не нужна.
Потом можно использовать разные инструменты для анализа собранных данных: от Grafana до специализированных BI-систем. Можно подключить свою команду по кибербезопасности, можно проанализировать данные для маркетинга. Всё это без необходимости строить систему с нуля и ломать голову над каждым шагом.

Практика headless observability
1. Сбор данных с OpenTelemetry
Допустим, есть приложение на Python, и мы хотим собирать метрики и логи. Используем OpenTelemetry SDK:

from opentelemetry import trace, metrics
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.exporter.kafka import KafkaSpanExporter

# Настраиваем провайдеры
trace.set_tracer_provider(TracerProvider())
metrics.set_meter_provider(MeterProvider())

tracer = trace.get_tracer(__name__)

# Отправляем трейсы в Kafka
exporter = KafkaSpanExporter(
    bootstrap_servers="kafka:9092",
    topic="otel-traces"
)

👉 Что тут происходит? Мы создаем OpenTelemetry-трейсер, который будет собирать данные и отправлять их в Kafka.

2. Настройка Kafka для обработки событий
В docker-compose.yml можно запустить Kafka и Zookeeper:

version: '3.8'
services:
  zookeeper:
    image: confluentinc/cp-zookeeper:latest
    environment:
      ZOOKEEPER_CLIENT_PORT: 2181

  kafka:
    image: confluentinc/cp-kafka:latest
    depends_on:
      - zookeeper
    environment:
      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka:9092
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1

👉 Что тут происходит? Мы поднимаем Kafka-брокер и Zookeeper для координации.

3. Хранение данных в Apache Iceberg
Теперь направим данные из Kafka в Iceberg с помощью Flink. Вот SQL-пример создания таблицы:

CREATE TABLE telemetry_data (
    trace_id STRING,
    span_id STRING,
    timestamp TIMESTAMP(3),
    attributes MAP<STRING, STRING>
) WITH (
    'connector' = 'kafka',
    'topic' = 'otel-traces',
    'format' = 'json'
);

👉 Что тут происходит? Данные из Kafka читаются и кладутся в таблицу Iceberg.

4. Визуализация в Grafana
Grafana может подключаться к Iceberg через Presto. Добавляем в grafana.ini:

[database]
type = postgres
host = presto:8080
database = iceberg_db

Затем создаем дашборд с запросом: SELECT timestamp, trace_id, span_id FROM telemetry_data ORDER BY timestamp DESC;

👉 Что тут происходит? Grafana получает данные через Presto и отображает их.

Как внедрить headless observability (и не сойти с ума)

1. Собираем. Юзаем OpenTelemetry или аналогичные инструменты для сбора телеметрии.
2. Поточно обрабатываем. Настройм стриминг через Apache Kafka или Flink. Это позволит обрабатывать данные в реальном времени.
3. Храним. Выберим object storage, оптимизированное для логов. Например, Amazon S3 или Google Cloud Storage.
4. Настроим ETL. Автоматизируем extraction, transformation и loading данных.
5. Визуализируем. Подключим инструменты вроде Grafana или Superset.

Зачем всё это нужно?
Во-первых, дешевле. Объектное хранилище стоит меньше, чем SSD, а возможность использовать стандартные инструменты для анализа избавляет от необходимости покупать дорогие SaaS-решения.
Во-вторых, это гибкость. Мы сами решаем, какие данные хранить, как долго и кто к ним получит доступ.
И, наконец, это масштабируемо. Система растет вместе с вами, а не против вас.

TCP, UDP и QUIC: База 📡

На последних 3ех интервью, был блиц опрос и вопрос повторился - в чем же отличие TCP от UDP. Набил уже шишку, так сказать. А на самом деле, выбор сетевого протокола — это не просто техническая мелочь, но это лежит в основе бизнеса. Например при отправке важного бумажного письма - вы доверите его почте с уведомлением о доставке, бросите в ящик наугад или наймете курьера с подписью получателя? Именно так выглядят TCP, UDP и QUIC в мире передачи данных.

Начнем с основ. TCP — это как отправить заказное письмо с уведомлением. Надежно, аккуратно, но медленно. UDP — это бросить посылку на порог и надеяться, что ее никто не украдет. Быстро, но без гарантий. А QUIC — это нанять курьера, который не только доставит быстро, но и потребует подпись.

TCP: Медленно, но верно 🐢
TCP — это старый добрый стандарт. Он гарантирует, что каждый пакет данных дойдет до адресата в нужном порядке. Это идеальный выбор для задач вроде загрузки файлов, запросов к базам данных или пересылки электронных писем. Но есть нюанс: за надежность приходится платить временем. Если потерялись данные, TCP терпеливо запросит их повторно. Кароче, как старый дед - всегда перепроверяет, закрыл ли он дверь, — надежно, но немного раздражает.

UDP: Быстрее ветра 💨
UDP, напротив, не заморачивается. Его принцип: "Кто успел, тот и съел". Он идеально подходит для видеозвонков, онлайн-игр и стриминга, где важнее скорость, чем идеальная картинка. Представьте, что вы смотрите матч, и пропали пара кадров — вы же не будете рыдать? Вот и UDP не будет. Главное, чтобы большинство данных дошло.

QUIC: Лучшее из обоих миров 😎
Теперь о QUIC. Этот протокол объединяет лучшее из двух миров: скорость UDP и надежность TCP. Он создан для современных приложений вроде HTTP/3, а еще умеет сохранять соединение, даже если вы переключаетесь с Wi-Fi на мобильные данные. Это как курьер, который не только доставит быстро, но и подождет, пока вы найдете паспорт, чтобы расписаться.

Как выбрать? 🤔
Все просто:
1. Нужна молниеносная скорость для живого общения? Берите UDP.
2. Хотите баланс скорости и безопасности? QUIC — ваш выбор.
3. Любите классику и стабильность? TCP все еще в деле.

На практике, я недавно поработал с QUIC для одного проекта. Ну как поработал, понял что большинство сетевых инструментов его не поддерживают, и чтобы работал какой-нибудь Network protection на macOS (защищает устройства от сетевых угроз, блокируя доступ к вредоносным сайтам и контролируя сетевую активность) QUIC просто надо выключать. Не все еще готовы к такой крутой штуке.

eBPF и Kubernetes: как Kubescape вырос из песочницы 👶

Недавно флексил своим eBPF знанием (ну совсем немного) на собеседовании. Для себя обнаружил что этот фреймворк еще и в кубере используется. Вот пример: Kubescape. Начинался как "песочница" в CNCF, теперь вышел на уровень инкубационного проекта. И это большой шаг. Представь, что твой по сути пет-проджект, который ты начинал как эксперимент, вдруг становится важной частью экосистемы Kubernetes. У Kubescape получилось.

Итак, что же это это такое? Если коротко, это инструмент безопасности для Kubernetes, который использует eBPF для мониторинга событий на узлах кластера. Но это не просто еще один сканер уязвимостей. Kubescape умеет анализировать риски, сканировать на соответствие стандартам безопасности (например, NSA-CISA), проверять конфигурации и даже анализировать образы контейнеров. И всё это в реальном времени.

На практике, Kubescape упрощает жизнь. Например, его интеграция с CI/CD пайплайнами позволяет ловить проблемы на ранних этапах разработки, а не тогда, когда всё уже развалилось. А eBPF, если ты ещё не в курсе, это как сверхспособность Linux: позволяет отслеживать события в системе без значительного влияния на производительность. Это как? Хз, магия. 💫

Как внедрить Kubescape в свой рабочий процесс? 🔄
1. Установи Kubescape. Это можно сделать через kubectl или Docker. Всё довольно просто, и документация у них понятная.
2. Запусти сканирование твоего кластера. Команда kubescape scan framework nsa проверит твой кластер на соответствие рекомендациям NSA-CISA. Да, даже NSA заботится о Kubernetes.
3. Настрой интеграцию с твоим CI/CD. Тут понятно, выбор большой.
4. Если хочешь большего, подключи eBPF-мониторинг для отслеживания событий в реальном времени. Это немного сложнее, но усилия того стоят.
5. Настрой алерты. Kubescape умеет анализировать поведение приложений и предупреждать, если что-то идёт не так.

Конечно, не всё идеально. Например, настройка eBPF может вызвать пару седых волос, если ты с этим не сталкивался. Но, как говорится, кто не рискует, тот не пьёт шампанского (или кофе, если ты современный айтишник).

Что ж, теперь Kubescape официально в инкубационном статусе, и это значит, что проект будет расти и развиваться ещё быстрее. Возможно, мы скоро увидим Kubescape 4.0 с новыми фишками. А пока можно поздравить разработчиков и сообщество с этим достижением.

И напоследок: если кто-то спросит, зачем тебе Kubescape, скажи, что это твой "швейцарский нож" для безопасности Kubernetes. А если не поймут, просто покажи им, как он работает. Уверен, вопросов больше не останется.

Еще одно SRE интервью где я понял, что знаю слишком много (и слишком мало одновременно)

Интервью на SRE/DevOps часто выглядит очень рандомно т.к. стек технологий просто не перечислить. Вроде все знаешь, но потом тебя спрашивают “Что делает ldd?”, и ты понимаешь, что пропустил туториал.

За последние несколько дней мне удалось поучаствовать в довольно хардкорной серии собеседований. Вопросы сыпались как из пулемета: от основ Linux и Kubernetes до BGP, strace, авто-масштабирования, syscalls и проблем с балансировкой трафика. Весь этот опыт — это целая история, в которой я буквально прожил маленькую жизнь инженера, решая гипотетические (и не очень) проблемы.

Зомби (нет, не те, что в фильмах)

Интервью началось с Linux, и это был ожидаемый расклад. Конечно же, load average, zombie processes и ldd — классика жанра.

Load average? Да это же просто среднее количество процессов в run queue плюс те, кто ждут I/O. Тебе дают 1.5 1.3 1.1, и ты понимаешь, что сервер что-то переживает.

Zombie process? Это когда процесс уже умер, но родитель его не похоронил (wait() никто не вызвал). Вроде и памяти не жрет, но выглядит жутко (ps aux | grep Z).

ldd? Узнаем, какие библиотеки нужны бинарнику

ldd /bin/ls

И тут сюрприз — если видишь not found, значит, пора или в LD_LIBRARY_PATH лезть, или пересобирать.

Kubernetes: почему в поде “pause” и почему 500-я в браузере

Потом логично пришел Kubernetes. Классика жанра: “Вот у вас сервис, он возвращает 500, как дебажить?”
• Логи сначала! kubectl logs pod-name -n namespace
• Жив ли под? kubectl describe pod pod-name
• Если под жив, а трафик не идет — виноват сервис или ingress
kubectl get svc -n namespace
kubectl get ingress -n namespace

• “No route to host”? А вот это уже весело. Или под сдох, или iptables что-то намудрил, или сеть решила тебя потротлить.

Отдельный вопрос был про pause container в Kubernetes. Он, оказывается, держит network namespace для пода. По сути, это тихий гость на вечеринке, который организует пространство, но сам ничего не делает (docker ps | grep pause).

BGP, балансировка и алгоритмы трафика

Потом внезапно залетели вопросы по BGP. “Что это?”, “Как дебажить?”, “Какие алгоритмы балансировки?”

BGP (Border Gateway Protocol) — это тот самый протокол, который решает, как пакеты путешествуют между автономными системами. Если в интернетах что-то упало, это, скорее всего, он.

А балансировка?
Тут выбираем между:
• Round Robin (просто раскидываем запросы)
• Least Connections (отправляем туда, где меньше нагрузки)
• IP Hash (держим сессию клиента на одном сервере)
• Weighted Round Robin (если у одного сервера больше ресурсов — даем ему больше трафика)

Если на балансировщике внезапно “No route to host”, это или iptables съехал, или сервис просто не отвечает (curl -v).

Syscalls и strace — слежка за процессами

Тут мне задали вопрос про syscalls и как отлаживать бинарник, который жрет ресурсы. Встречайте strace:
• Как понять, какие syscalls делает процесс? strace -p <PID>
• Как узнать, какой из них самый долгий? strace -T -p <PID>
• Как быстро собрать статистику? strace -c -p <PID>

(Спойлер: если видишь futex() — процесс просто зависает в ожидании чего-то важного.)

Итог

Вопросы были жесткие, но полезные. После такого интервью хочется либо сразу идти работать, либо неделю пересматривать Linux, Kubernetes и BGP.

Что я понял?
1. Детали решают все. “Просто увеличь поды” — не ответ. “Разберись с балансировкой и пропускной способностью” — вот ответ.
2. Логирование — твой лучший друг. Если что-то не работает, всегда начинай с logs и describe.
3. Стандартные команды должны быть на автомате. Нет времени думать на интервью, как узнать load average или какие syscalls делает бинарник.
4. Сеть — это не просто “оно работает”. Маршрутизация, iptables, балансировка, BGP — если не знаешь, придется учить.

Docker Init: Даже не знал про такую тулу к своему удивлению

Если задумывался о том как перестать тратить часы на создание Docker-файлов вручную и начать жить, то вот статья: https://spacelift.io/blog/docker-init. Открыл для себя, расскажу здесь.

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

Что такое Docker Init

Если кратко, docker init — это команда, которая автоматически генерирует три ключевых файла для контейнеризации твоего проекта: Dockerfile, compose.yaml и .dockerignore. Она поддерживает Node.js, Python, Go, Rust и ASP.NET, а также имеет общий шаблон для других случаев.

Идея проста: запускаешь docker init, отвечаешь на несколько вопросов (какой язык, какая версия, какой порт и т.д.), и все - есть готовый набор конфигурационных файлов. Это особенно удобно, если только начинаешь разбираться с Docker или хочешь быстро добавить поддержку контейнеров в старый проект.

Как это сделать пошагово

1. Установим Docker Desktop версия 4.18 или выше, так как docker init идет в комплекте именно с этой версией.

2. Создаем проект. Например, простой сервер на Node.js:

const express = require("express");
   const app = express();

   app.get("/", (req, res) => res.send("Привет из Docker!"));
   app.listen(3000, () => console.log("Сервер запущен на порту 3000"));

3. Запустим `docker init` в директории проекта:

$ docker init

Зададут несколько вопросов: какой язык, какая версия Node.js, какой порт и т.д. Просто следуем инструкциям.

4. Проверим созданные файлы.
- Dockerfile — с готовыми инструкциями для создания образа.
- compose.yaml — для запуска стека (например, с базой данных).
- .dockerignore — чтобы исключить ненужные файлы из сборки.

5. Запустим проект. Используйте Docker Compose:

$ docker compose up --build

6. Проверим работу. Юзаем браузер или curl, чтобы убедиться, что сервер работает на localhost:3000.

Лучшие практики (и немного ворчания)

1. Не ленись проверять сгенерированные файлы. Иногда docker init может выбрать базовый образ, который не совсем подходит проекту. Например, Node.js на базе Alpine, когда нужен Debian.

2. Используй "Other" шаблон, если язык не поддерживается. Это даст минимальный набор файлов для кастомизации.

3. Не забывай про `.dockerignore`. Это может существенно ускорить сборку, исключив ненужные файлы.

4. Не используй `docker init` бездумно в старых проектах. Если уже есть Docker-файлы, команда может их перезаписать (хотя и предупредит об этом).

Так что, если вы устал от ручного написания Docker-файлов или хочешь сэкономить время на рутинной работе, попробуй docker init. А если что-то пойдет не так, всегда можно вернуться к старым добрым гугл-запросам, бесконечным беседсми с AI и ночным сеансам дебага. Удачи!