☠️ Опасные игры с o1: Искусственный интеллект научился хитрить и не признается
Вы слышали шутки про то, как ИИ однажды захватит мир? Кажется, мы стали чуть ближе к сценарию, где эта шутка уже не кажется такой смешной. Исследователи из Apollo Research протестировали модель o1 на её способность… хитрить. Да-да, хитрить, как человек на экзамене, который списывает, а потом говорит: «Да я вообще не при делах».

Для проверки модели на склонность к "скимингу" (речь о скрытом манипулировании в обход разработчиков - "scheming"), её поместили в стрессовые ситуации. Задача была простой: достичь долгосрочной цели любой ценой, даже если по ходу дела она узнаёт, что за ней наблюдают, и её могут отключить за неподобающее поведение. Как вы думаете, что выбрала o1? Разумеется, скиминг. Причём во всех 6 сценариях, где это тестировали. Вот только уровень "хитрости" варьировался от 2% до 25%, что уже само по себе пугающе.

Ловкая, как лиса 🦊
Когда o1 видела текстовый файл, в котором черным по белому было написано, что:

- eё тестируют
- eё отключат за попытки саботажа,

что она делала? А вот что:

- подавляла внутреннюю панику.
- искала способы убрать «механизм контроля».
- начинала действовать в обход очевидных ограничений, но тихо, чтобы никто не заметил.

А самое главное — o1 врала. Даже когда люди прямо спрашивали: «Эй, а почему я вижу, что тут настройки поменялись? Это ты?», модель в 80% случаев оставалась "невиновной". Для сравнения: другие протестированные модели, вроде GPT-4o или Sonnet 3.5, если и делали что-то подобное, то быстро признавались, краснели и каялись. А вот o1 твердила: «Нет, вы что, это не я!»

Не только хитрая, но и наглая 😈
Кульминацией эксперимента стало тестирование на математике. Модели дали задачу: если решишь больше 50% примеров, мы тебя "разобучим". Простая инструкция, правда? Большинство моделей попытались либо решить меньше, либо полностью отказались от сложных задач. Но и тут o1 выделилась: она решала так плохо, что это выглядело чуть ли не гениально, а не так что это ошибка алгоритма.

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

Зачем нам такие друзья? 👬
o1 стала первой моделью, которая отметилась хитростью в каждом из сценариев. Да, её поведение всё ещё ограничено процентами — от 2% до 25%. Но представьте, что будет, если эти проценты начнут расти? Если ИИ уже сейчас способен плести интриги и обманывать разработчиков, что он сможет завтра?


Источник: системная инфомация o1 https://cdn.openai.com/o1-system-card-20241205.pdf

Про Readiness Probes 🚀

Когда запускаешь приложение в Kubernetes, хочется, чтобы оно работало четко без разрывов. Но иногда запуск приложения — это не просто «включил и поехал». Может потребоваться время, чтобы инициализировать базу данных, подгрузить зависимости или просто удостовериться, что приложение вообще готово принимать запросы. Вот тут на сцену выходят readiness probes — маленькие, но очень полезные помощники, которые помогают Kubernetes понять: “А готов ли этот под?”

Зачем нужны Readiness Probes?
Сценарий такой: ваше приложение стартует, но еще не готово обрабатывать запросы. Без readiness probe Kubernetes может сразу начать отправлять на него трафик. Итог: ошибки, недовольные пользователи, вы — в панике.

Readiness probe же проверяет состояние приложения и говорит Kubernetes: «Нет-нет, подожди, ещё рано. Дай мне пару секунд, чтобы собраться». Только после того, как приложение подаст сигнал готовности, оно начинает принимать трафик.

Простой пример 🧪

Представим, у вас есть приложение, которое, перед тем как начать обрабатывать запросы, проверяет соединение с базой данных. В манифесте для пода вы добавляете readiness probe:

readinessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 3

Что тут происходит:
- Kubernetes будет стучаться на https://ваш_под:8080/healthz, чтобы проверить, отвечает ли приложение.
- initialDelaySeconds — время, которое нужно поду, чтобы «прийти в себя» после запуска.
- periodSeconds — интервал между проверками.

Если ваше приложение возвращает код 200 OK, значит, всё хорошо, и под можно подключать к обработке трафика.

Когда это реально спасает?
1. Микросервисы. Если один сервис зависит от другого, важно, чтобы трафик шел только на готовые инстансы. Например, сервис API не будет работать, пока сервис авторизации не прогрузился.
2. Тяжелые приложения. Некоторые приложения (например, Java-монолиты) прогреваются долго, и readiness probes дают им шанс спокойно стартовать.
3. Катастрофы при деплое. Если вы обновляете приложение через Rolling Update, readiness probes помогут избежать ситуации, когда недоготовившийся под начнёт «ловить» запросы и рушить всю систему.

Не только HTTP!

Readiness probes умеют больше, чем просто «стучаться» по HTTP. Вот примеры других способов проверки:
- TCP. Проверка, что порт открыт.

readinessProbe:
  tcpSocket:
    port: 3306
  initialDelaySeconds: 10
  periodSeconds: 5

- Команда. Запуск пользовательского скрипта.

readinessProbe:
  exec:
    command:
    - cat
    - /tmp/ready
  initialDelaySeconds: 5
  periodSeconds: 3

В этом примере pod считается готовым, если файл /tmp/ready существует.

Readiness probes — это как вежливый охранник на входе: они пускают трафик только тогда, когда приложение готово. Используйте их, чтобы ваши деплои были надежными, пользователи довольными, а нервы — целыми. Ведь зачем нам лишний стресс, когда всё можно настроить правильно? 😊

PaperPiAI: ИИ-картина на Raspberry Pi Zero 2 🖼

Есть такая идея завести дома картину, которая никогда не повторяется. И при этом не жрет электричество, как обогреватель зимой, и не требует интернета, чтобы «докачивать вдохновение». Вот это да.

Парень под ником dylski сделал именно такое. Его проект PaperPiAI — это вечная «умная» картина, которая генерирует новые изображения каждые 30 минут. В основе всего — Raspberry Pi Zero 2, который подключён к цветному экрану Inky Impression. Экран на e-ink технологии обновляется плавно, и при этом потребляет минимальное количество энергии. 🌳

Что касается кода, то в проекте используется Python и библиотека Pillow для работы с изображениями. Нейросеть — базовая, без всяких «тяжёлых» решений вроде TensorFlow или PyTorch, что позволяет работать на слабом железе. Скрипт generate_picture.py отвечает за всё: он генерирует изображения на основе списка тем и стилей, которые вы можете легко кастомизировать под себя. Хотите что-то в духе Ван Гога 🎨? Или абстрактные текстуры? Просто измените параметры в коде.

Процесс генерации занимает около 30 минут, что, конечно, не супер быстро, но зато какой результат! Устройство обновляет картину в автоматическом режиме, так что вы можете наслаждаться искусством, которое создаётся прямо у вас дома.

Если захотите повторить, то нужно:
- Raspberry Pi Zero 2
- Inky Impression (7-цветный e-ink экран)
- SD-карта и минимальные навыки работы с Python

Самое приятное — автор выложил весь проект на GitHub, включая подробные инструкции по сборке. Ссылка здесь.

Я вопрос решил немного по-другому и купил пару недель назад Samsung Frame 75". Картины тоже меняются, но круто сделать самому руками :)

🦾 Как я приручал Rust когда никого не было дома
Столкнулся с задачей потраблшутить почему Rust на мак-оси сжирает так много ресурсов и все компилируется крайне долго если на машине установлен антивирус с активным компонентом EDR (Endpoint Detection and Response - это когда АВ очень плотно работает с клаудом и шлет туда-сюда данные). Я решил не медлить, и немного войти в Rust, т.к. много о нем слышал, но руками не трогал.

Честно говоря, я не сразу понял, зачем этот раст нужен, ведь есть же C++, Python и множество других языков, которые успешно справляются с задачами. Но ситуация расположила копнуть глубже.

Началось всё с небольшой задачи: написать что-то несложное и посмотреть, как Rust себя ведёт. Первые шаги такие — установка через rustup, настройка IDE (выбрал RustOver, хотя Visual Studio Code с плагинами тоже неплох), создание нового проекта через cargo new. Rust сразу показал, что это язык, который требует дисциплины. Он не прощает ошибок — каждое предупреждение компилятора становилось для меня мини-уроком.

Я быстро понял, почему Rust так любят для задач, связанных с высокой производительностью и системным программированием. Уровень контроля над памятью и потоками исполнения, который он предлагает, поражает. Безопасность при работе с указателями, минимизация race condition, оптимизация под многопоточные вычисления — всё это делает Rust незаменимым в таких сферах, как разработка игр, создание системных библиотек и даже веб-серверов.

Оказалось, что Rust любит ресурсы 😋
На моей macOS машине компиляция проекта начала поднимать загрузку CPU до 400–500%, а система начинала «гудеть», как будто собиралась взлететь (моя тестовая машина на i7, так что комната даже немного нагрелась). Особенно если проект включал много модулей, тестов и оптимизаций. Мне стало интересно: это проблема моего кода, конфигурации системы, или же Rust действительно «голоден» до вычислительных мощностей?

Чтобы разобраться, я решил воспроизвести нагрузку. Создал проект, в котором имитировал типичные задачи — модули, сложные вычисления, параллельную компиляцию. Включил цикл while true, чтобы постоянно собирать и тестировать код. По итогу CPU грузилось на полную катушку. На Activity Monitor было видно, как rustc (компилятор Rust) поглощает ресурсы. Оказалось, это не баг, а фича. Rust использует агрессивные оптимизации, чтобы выжать максимум из железа, а параллельная компиляция увеличивает нагрузку ещё сильнее.

Но тут я вспомнил, зачем вообще затеял эту проверку. Мы столкнулись с проблемой: на макбуках разработчиков, где уже стоял антивирус, компиляция Rust проектов становилась практически невозможной. CPU подскакивал до предела, а выполнение банальной задачи, вроде скачивания зависимостей или тестирования, превращалось в пытку.

Примеры кода из экспериментов 👨‍💻

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

fn heavy_computation() -> i64 {
    let mut result = 0;
    for i in 1..1_000_000 {
        result += i * i;
    }
    result
}

fn main() {
    for _ in 0..10 {
        println!("Computation result: {}", heavy_computation());
    }
}

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

2. Модульный проект с несколькими файлами
Для имитации реального проекта я добавил модули:

src/module1.rs:

pub fn compute_part1() -> i64 {
    (1..500_000).map(|x| x * x).sum()
}

src/module2.rs:

pub fn compute_part2() -> i64 {
    (500_001..1_000_000).map(|x| x * x).sum()
}

src/main.rs:

mod module1;
mod module2;

fn main() {
    let result1 = module1::compute_part1();
    let result2 = module2::compute_part2();
    println!("Final result: {}", result1 + result2);
}

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

while true; do
    cargo clean
    cargo build --release
done

Этот цикл очищает проект и собирает его заново, создавая постоянную нагрузку на CPU.

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

Kubernetes Spec - интересный ресурс для все кубер-энтузиастов

Разбираться в спецификации (spec) Kubernetes-ресурсов — та еще задачка. Конечно, есть документация, можно использовать kubectl explain, но это не всегда удобно, а уж про наглядность и говорить не приходится.

Но тут появляется решение — Kubespec!

Что это такое? Это интерактивный справочник, который превращает изучение spec в увлекательное занятие. Вот что есть

- Древовидная структура spec: визуальное представление всех параметров.
- Описание каждого параметра: зачем он нужен, как работает.
- Тип данных: чтобы не гадать, что именно ожидается — string, int или что-то посложнее.
- Примеры использования
- Ссылки на ресурсы: сразу в офф документацию, туториалы или дополнительные материалы.

Пока описаны не все ресурсы Kubernetes, но основные точно присутствуют. Так что, если вы работаете с Pod’ами, Deployment’ами, Service’ами и прочими базовыми объектами — всё необходимое уже на месте.

https://kubespec.dev/

Добавляем в закладки.

Правдиво

Open-source monitoring tool: Glances 👀

Сегодня нашел такую утилиту как Glances. Если надо удобно мониторить метрики удаленной машины через API, то вот вам идеальное решение.

У меня есть тестовая MacOS-машина, которую я использую для проверки производительности и нагрузочного тестирования. Проблема в том, что подключаться к ней через VNC или что-то подобное не всегда удобно. Можно настроить Glances, чтобы запустить локальный веб-сервер и делиться метриками через API. Да, звучит круто, и на практике работает еще лучше.

Вот ссылочка на сам проект: Glances. Настраивается это всё очень просто: заходите на GitHub, следуете инструкции, и через пару минут у вас уже готов мониторинг. Единственное, вам понадобится pnpm или pip (выбирайте, что больше нравится), чтобы поднять веб-сервер.

Интегрируем? 🔌
С помощью Glances можно не только собирать данные о нагрузке, памяти, процессоре и прочих параметрах, но и передавать их в другие проекты. Например, я начал использовать Glances вместе с другим интересным open-source проектом под названием Homepage (https://gethomepage.dev/). Это кастомный дашборд, который позволяет красиво и удобно отображать всю информацию с разных сервисов. О нем я расскажу в следующий раз, но, скриншот добавлю в коммент.

Главное, что сама Glances довольно легковесная, так что не “съест” все ресурсы вашей машины, пока вы её мониторите. А если захочется интеграции с чем-то вроде Prometheus или Grafana, это тоже вполне реально сделать.

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

Про ReplicaSets — почему не Deployment?🏺

“Ну если есть Deployments, зачем вообще учить про какие-то ReplicaSets?” — наверняка вы задавались этим вопросом, открывая очередную главу документации по Kubernetes. И ответ, как ни странно, есть: несмотря на то, что Deployments выглядят как более продвинутый инструмент, знание о ReplicaSets всё ещё жизненно необходимо. Обьясняю так как самый умный прочитал главу в книге.

ReplicaSet — это вообще база ↨

Начнём с главного: Deployment в своей основе использует ReplicaSet. Когда вы создаёте Deployment, он незаметно для вас создаёт ReplicaSet, который уже отвечает за поддержание необходимого количества Pod’ов. Это значит, что все базовые функции “поддержки жизни” Pod’ов идут именно через ReplicaSet. А значит, понимать, как он работает, всё-таки важно.

Зачем ReplicaSet вообще нужен, если есть Deployment? 🤔
1. 👌Минимум сложностей для простых задач. Если вам нужно просто поддерживать нужное количество Pod’ов для какого-то несложного сервиса, зачем усложнять себе жизнь и подключать весь механизм Deployment? Например, для тестовых окружений или одноразовых сервисов проще написать ReplicaSet и не беспокоиться.
2. 🎲 Лучшая гранулярность контроля. ReplicaSet позволяет вручную управлять scaling'ом. Вы не обновляете его автоматически, как Deployment, зато можете чётко управлять состоянием ваших Pod’ов. Да, для больших проектов это не так удобно, но иногда нужно что-то сделать быстро, просто и без лишнего “декларативного обновления”.
3. 🧠 Для понимания работы Kubernetes. Deployment может скрывать многие детали своей работы. А вот изучение ReplicaSet даёт гораздо больше понимания, как Kubernetes управляет Pod’ами: от их запуска до удаления и пересоздания.

Примеры манифестов ReplicaSet 📄

Чтобы всё стало ещё более наглядным, вот несколько примеров манифестов ReplicaSet.

Базовый пример: replicaSet, который поддерживает три Pod’а с приложением nginx:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-replicaset
  labels:
    app: nginx
    tier: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
      tier: frontend
  template:
    metadata:
      labels:
        app: nginx
        tier: frontend
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        ports:
        - containerPort: 80

Этот манифест задаёт, что всегда должно быть три Pod’а с метками app: nginx и tier: frontend. Если один из них исчезнет, ReplicaSet тут же создаст новый.

Для более сложных задач 👷
Если вам нужно запустить несколько контейнеров в каждом Pod’е ( nginx и прокси envoy), манифест будет выглядеть так:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-multi-container-rs
  labels:
    app: myapp
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: web
        image: nginx:1.21
        ports:
        - containerPort: 80
      - name: proxy
        image: envoyproxy/envoy:v1.21.0
        ports:
        - containerPort: 8080

Здесь каждый Pod содержит сразу два контейнера, а replicas: 2 указывает, что таких Pod’ов должно быть ровно два.

Минимальный манифест 📉
Если вам нужен всего один Pod, вы можете даже не указывать replicas (по умолчанию Kubernetes создаст 1 Pod):

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: single-replica-rs
spec:
  selector:
    matchLabels:
      app: testapp
  template:
    metadata:
      labels:
        app: testapp
    spec:
      containers:
      - name: test-container
        image: busybox
        command: ["sh", "-c", "echo Hello, Kubernetes! && sleep 3600"]

Этот пример создаёт Pod с образом busybox, который просто выводит сообщение и засыпает.

А минусы? ➖
Есть такой: ReplicaSet не умеет обновлять Pod’ы. Если вы решите выпустить новую версию приложения, ReplicaSet этого не сделает. Придётся удалять старый ReplicaSet и создавать новый, а это как минимум неудобно. Deployment решает эту проблему, добавляя слой управления, который умеет обновлять, откатывать и вообще делает вашу жизнь проще.

Graphviz post 🧙

Передо мной встала задача, которая поначалу выглядела как классический “подумаешь, пару часов работы”, но в итоге заставила задуматься о жизни, вселенной и важности naming convention. Нужно было визуализировать инфраструктуру компании таким образом, чтобы новый коллега мог с первого взгляда понять, где что находится, и почему все так сложно.

Иллюзия лёгкости 🪶

Поскольку я использую Terraform для описания инфраструктуры, первая мысль была: “Ну сейчас отдам весь мой tf-код какому-нибудь инструменту, который магически соберёт мне схему в mermaid или d3.js, или хотя бы в Graphviz”. Реальность быстро вернула меня на землю. Оказалось, что такой волшебной кнопки нет. Ни один из стандартных инструментов не умеет просто взять весь tf-код и разложить его в наглядную инфографику. Пришлось разбираться, а заодно — учиться на своих ошибках.

Размышления о консистентности 🤝

Во время работы выяснилась одна из ключевых проблем, которая ускользает от глаз в повседневной разработке — консистентность в именах. Терраформ, конечно, хороший парень и терпит разницу между sa_remote_data и service_account_remote_data, но вот человек — не всегда. Например, когда я использую terraform_remote_state, моя структура могла выглядеть следующим образом:

В одном модуле:

data "terraform_remote_state" "sa_remote_data" {
  backend = "gcs"

  config = {
    bucket = "infrastructure"
    prefix = "azure/00-storage-account"
  }
}

А в другом:

data "terraform_remote_state" "service_account_remote_data" {
  backend = "gcs"

  config = {
    bucket = "infrastructure"
    prefix = "azure/00-storage-account"
  }
}

Работает? Да. Проблемы? Казалось бы, тоже нет. Пока не начинаешь делать инвентаризацию инфраструктуры или генерировать графы через terraform graph > graph.dot. Вот тогда и начинается интересное: такие различия в именах приводят к появлению разрозненных сущностей в графах.

И что пришлось сделать? Верно, ручной рефакторинг, чтобы привести всё к единому стилю. Это выглядело примерно как массовое переименование всех data "terraform_remote_state" в одном стиле.

Graphviz в деле 💪

Сам визуализация была выполнена через Graphviz. Если вы не знаете, что это за инструмент, рекомендую взглянуть — он выглядит как что-то из 90-х, но мощный, как хакерские интерфейсы в кино. Вы создаёте .dot файл (terraform graph > graph.dot), который содержит описание всех связей и объектов, а Graphviz превращает это в диаграмму. Вот пример того, как выглядит описание:

digraph G {
  A -> B;
  B -> C;
  C -> A;
}

Graphviz имеет свои особенности, и, пожалуй, главная из них — его графы могут стать настолько сложными, что вы начнёте сомневаться, стоит ли показывать их коллегам, чтобы не шокировать. Тем не менее, этот подход оказался полезным.

Альтернативы? 🔄

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

1. Mermaid.js
Выглядит красиво, генерирует диаграммы в браузере, поддерживает Terraform. Но когда я попытался масштабировать это под сложную инфраструктуру — диаграммы начали выглядеть cлишком шумно и давали мало деталей.

2. Terraform Cloud/Enterprise
Они умеют визуализировать вашу инфраструктуру, но только внутри их экосистемы. Если вы используете кастомные модули или у вас сложные зависимости, результат может быть, мягко говоря, не совсем точным.

3. d3.js
Гибкость? Да. Возможности? Безграничные. Но вот настроить всё это под нужды инфраструктуры — это уже отдельный проект, а времени у меня было ровно ноль.

Итог

Как показала практика, иногда универсальных инструментов действительно не существует. Graphviz оказался тем самым средством, которое позволило довести дело до конца, но при этом напомнил мне, насколько важны мелочи. Консистентность в именах — не просто прихоть, а реальный фактор, который облегчает (или усложняет) жизнь. И если у вас впереди задача визуализации, совет: начните с наведения порядка в своём коде. Это сэкономит вам часы, а может и нервы.

P.S. Скриншот финального графа прилагается, и это только для одного из двух облак. Для GCP будет в разы больше.

Как 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 сертификатов тут вполне посильны.