🗃 Как хранятся данные в Redis: RDB vs AOF

Когда речь заходит о персистентности данных в Redis, используются два основных механизма:

• RDB (Redis Database Backup) – снимки базы в определённые моменты времени.

• AOF (Append Only File) – журнал, записывающий все изменения в базе.

➖ Как работает RDB

Раз в заданный интервал времени Redis делает снимок всех данных и сохраняет его в файл.

Одним из главных плюсов RDB является быстрое восстановление после аварии — загрузка данных идёт значительно быстрее, чем при использовании AOF.

Основной минус RDB — потенциальная потеря данных. Если сервер неожиданно упадёт между созданием снимков, все изменения, сделанные после последнего сохранения, будут утеряны.

➖ Как работает AOF

Каждый запрос, изменяющий данные записывается в лог.

Основное преимущество AOF — минимальная потеря данных. В зависимости от настроек можно записывать изменения каждую секунду или в реальном времени.

Файл AOF занимает больше места на диске, так как содержит историю всех операций. Восстановление из AOF занимает больше времени по сравнению с RDB, так как необходимо последовательно выполнить все записанные команды.

Делитесь в комментариях где бы использовали каждый метод? 👇

🐸Библиотека devops'a

🛠 Tekton: Гибкий CI/CD для Kubernetes

Tekton — это open-source фреймворк для построения CI/CD-пайплайнов, созданный специально для облачных и Kubernetes-ориентированных сред.

Как работает Tekton

В Tekton всё строится вокруг нескольких ключевых компонентов:

🔹 Tasks — базовые строительные блоки: сборка, тестирование, деплой.

🔹 Pipelines — объединение задач в последовательный процесс.

🔹 PipelineRuns — конкретные запуски пайплайнов.

🔹 Triggers — автоматизация запуска пайплайнов по событиям.

Tekton управляет процессами сборки, тестирования и развертывания внутри Kubernetes, обеспечивая масштабируемость и отказоустойчивость.

Когда использовать Tekton

• Уже используете Kubernetes и хотите CI/CD, интегрированное в кластер.

• Нужен гибкий пайплайн без привязки к конкретному CI-серверу.

• Важна интеграция с DevOps-инструментами, такими как ArgoCD или GitOps.

🌐 Официальный сайт проекта

🐸Библиотека devops'a

🌐 Как DNS-сервер меняет правила игры

Настройка собственного DNS-сервера — это шаг к безопасности, скорости и контролю.

Что такое DNS

Кратко — вместо того чтобы запоминать IP-адреса сайтов, вы вводите привычный адрес, например, google.com, а DNS находит нужный IP. Подробнее тут.

Преимущества собственного DNS-сервера:

➕ Конфиденциальность: никто посторонний не видит ваши запросы.

➕ Скорость: кэширование часто посещаемых сайтов ускоряет загрузку.

➕ Безопасность: фильтрация вредоносных доменов и защита от фишинга.

➕ Контроль: вы сами решаете, какие сайты разрешать или блокировать.

Популярные инструменты для создания своего сервера

1. Pi-hole — отличный вариант для блокировки рекламы на уровне всей сети.

2. BIND (Berkeley Internet Name Domain) — классический DNS-сервер.

3. Unbound — легкий и быстрый DNS-сервер с упором на безопасность.

➡️ Пошаговый гайд в статье

🐸Библиотека devops'a

Сегодня — День всех влюбленных. И знаете, какая самая важная любовь? Конечно, к своей работе! ❤️👨‍💻👩‍💻

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

Без нас не взлетит ни одна программа, не оживут серверы, не соберутся пайплайны!

Делитесь в комментариях, за что вы любите свою работу (или не очень 😄). Какие моменты заставляют вас чувствовать себя героем DevOps? 💙👇

Герой DevOps не знает сна
Инфраструктуру держит он крепко

🐸Библиотека devops'a

🛠 Инструмент для наблюдаемости за приложениями

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

🔑 Ключевые возможности HyperDX:

• Логи, метрики, трейсы, ошибки и записи сеансов отображаются вместе, что помогает быстро находить источники проблем.

• Фильтрация по уровням логов, запросам, трассировкам и свойствам за секунды.

• Отслеживание задержек, ошибок и метрик производительности от фронтенда до базы данных.

• Визуализация сложных метрик без сложных SQL-запросов.

• Простая настройка уведомлений по логам, метрикам и трассировкам.

• Быстрая установка через Docker Compose.

HyperDX легко подключается к вашим сервисам с помощью OpenTelemetry SDK, а также имеет готовые клиенты для Node.js и Python.

Где узнать больше:

📎 GitHub-репозиторий

📎 Документация

🐸Библиотека devops'a

🐥🥚 Проблема «курицы и яйца»

В экосистеме Kubernetes Cloud Controller Manager (CCM) отвечает за управление ресурсами, такими как балансировщики нагрузки, тома хранения и сетевые интерфейсы.

Проблема «курицы и яйца» в контексте CCM заключается в следующем: для полноценной работы кластера Kubernetes необходим CCM, который, в свою очередь, зависит от облачных ресурсов, создаваемых и управляемых самим кластером. Это создает замкнутый круг, где ни одна из сторон не может быть инициализирована первой без наличия другой.

Возможные решения этой проблемы включают:

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

2️⃣ Использование внешних инструментов: применение сторонних утилит или скриптов для предварительного создания необходимых облачных ресурсов до запуска кластера. Это обеспечивает основу для последующей работы CCM.

3️⃣ Постепенная инициализация: построение процесса развертывания таким образом, чтобы сначала запускались минимальные компоненты кластера, способные взаимодействовать с облаком, после чего инициализируется CCM, который завершает настройку и управление ресурсами.

Разработчики Kubernetes работают над упрощением развертывания и минимизации зависимости от предварительных настроек.

📎 Подробнее в блоге kubernetes

🐸Библиотека devops'a

Kubernetes в облаке: краткая инструкция по развёртыванию

Kubernetes обеспечивает оркестрацию контейнеров, но для успешного развёртывания важны дополнительные компоненты:

1. Kubeadm — утилита, которая автоматизирует инициализацию и настройку кластера Kubernetes.

2. Containerd — менеджер контейнеров, который обеспечивает выполнение и управление контейнерами без лишних зависимостей.

3. Cilium CNI — сетевой плагин, использующий eBPF для высокопроизводительного сетевого взаимодействия и безопасности внутри кластера.

Для развёртывания Kubernetes в облаке используйте kubeadm для инициализации кластера, установив необходимые пакеты и выполнив команду kubeadm init с указанием сети подов.

Контейнерная среда настраивается с помощью containerd: после установки сгенерируйте стандартную конфигурацию и перезапустите сервис.

Для сетевого взаимодействия используйте Cilium CNI, установив его через Helm после добавления официального репозитория.

📎 Подробная инструкция в статье

🐸Библиотека devops'a

🚨 Почему стоит избегать phpMyAdmin на проде

phpMyAdmin — удобный, но уязвимый инструмент. Вот почему:

• Легко доступен по предсказуемому URL — мечта для хакеров.

• Подвержен атакам перебором.

• Имеет историю уязвимостей, которые регулярно находят и используют.

Что делать:

1. Использовать SSH-туннель, если нужен удалённый доступ.

2. Перейти на MySQL Workbench, DBeaver, DataGrip и др.

3. Ограничить доступ по IP, использовать HTTPS и 2FA.

➡️ Оригинальная статья

💬 Какие инструменты для баз данных используете вы? Пишите в комментарии👇

🐸Библиотека devops'a

⚙️ #инфографика про работу Kubernetes

На изображении показана архитектура Kubernetes и как она работает:

➖ Пользовательский интерфейс и CLI (kubectl) — точка взаимодействия разработчика с кластером Kubernetes.

➖ Kubernetes Master (Control Plane) — управляющий центр:

• API Server — принимает и обрабатывает запросы.
• Controller Manager — контролирует и поддерживает заданное состояние кластера.
• Etcd — key-value хранилище для конфигураций и состояния.

➖ Worker Nodes (рабочие узлы) — выполняют приложения:

• Kubelet — управляет контейнерами на узле.
• Container Runtime — среда выполнения контейнеров.
• Kube-proxy — управляет сетевыми взаимодействиями между подами.

🐸Библиотека devops'a

⚡️ Оптимизируем терминал с fzf

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

Практические применения fzf:

1️⃣ История команд: настройте fzf на Ctrl+R, чтобы искать команды в истории за считанные секунды.

2️⃣ Поиск файлов: используйте fzf с find или rg для поиска файлов по проекту без долгих ожиданий.

3️⃣ Быстрая смена директорий: привяжите Alt+C для мгновенного перехода в нужную папку, выбрав её через fzf.

4️⃣ Интеграция с Vim: откройте файл прямо из редактора командой vim $(fzf), а в Neovim используйте встроенную поддержку.

5️⃣ Гибкая настройка: создайте свои алиасы, скрипты и горячие клавиши для задач, которые выполняете каждый день.

С fzf вы перестанете тратить время на рутинный поиск и ускорите работу в терминале.

➡️ Подробнее с примерами в статье

🐸Библиотека devops'a

⌨️ tldr-pages: шпаргалки по командам терминала

tldr-pages — это проект с краткими и понятными примерами команд для терминала. Вместо десятков страниц документации вы получите простые примеры, которые сразу можно использовать.

Проект охватывает команды Linux, macOS и Windows, включая git, curl, docker и многое другое. Благодаря сообществу, база команд постоянно пополняется и актуализируется.

Установить tldr можно через пакетные менеджеры вроде npm, apt, brew и другие.

После установки достаточно ввести:

tldr git

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

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

➡️ Репозиторий проекта

🐸Библиотека devops'a

🆚 Различия между DaemonSets и Deployments в k8s

Kubernetes предоставляет два способа управления подами: DaemonSets и Deployments. Сейчас разберём основные отличия между ними.

➖ Назначение:
• Deployment: управляет статическими приложениями, обеспечивая масштабирование, обновления и откаты.

• DaemonSet: гарантирует запуск одного пода на каждом узле кластера или их подмножеств).

➖ Управление подами:

• Deployment: количество подов определяется через replicas. Поды распределяются по узлам автоматически, но могут группироваться на одних узлах. Для распределения требуется PodAntiAffinity.

• DaemonSet: поды запускаются на каждом узле автоматически. При добавлении/удалении узлов DaemonSet адаптируется.

➖ Стратегии обновлений:

• Deployment: поддерживает rolling updates (постепенное обновление) и rollback (откат к предыдущей версии).

• DaemonSet: обновления выполняются последовательно для каждого пода, но откаты не поддерживаются нативно.

➖ Использование ресурсов:

• DaemonSet может быть избыточным в больших кластерах, если задача не требует присутствия на всех узлах. Например, запуск 15 подов на 50 узлах приведет к неэффективному использованию ресурсов.

• Deployment позволяет гибко масштабировать приложение независимо от количества узлов.

➖ Типичные сценарии:

• Deployment: веб-серверы, микросервисы, пакетные задания.

• DaemonSet: логирование, мониторинг, сетевые компоненты.

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

Deployment — Nginx:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

DaemonSet — Fluentd для сбора логов:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
spec:
  selector:
    matchLabels:
      name: fluentd
  template:
    metadata:
      labels:
        name: fluentd
    spec:
      containers:
      - name: fluentd
        image: fluentd:latest
        volumeMounts:
        - name: varlog
          mountPath: /var/log
      volumes:
      - name: varlog
        hostPath:
          path: /var/log

📎 Подробности в статье

🐸Библиотека devops'a

👨‍💻 StackQL: Интерактивное взаимодействие с API через SQL

StackQL предлагает унифицированную среду для управления облачными ресурсами с помощью знакомого SQL-синтаксиса.

➖ Что это такое

StackQL — это открытый фреймворк на основе SQL, который позволяет пользователям выполнять запросы, провижининг и управление облачными и SaaS-ресурсами. Он поддерживает популярные облачные провайдеры, такие как Google Cloud, AWS, Microsoft Azure, Digital Ocean и другие.

Доступен для Windows, MacOS и Linux и поддерживает несколько режимов использования, включая интерактивную оболочку REPL, утилиту командной строки и выполнение запросов через файлы IQL.

➖ Основные Возможности StackQL

Навигация по облачным API: используйте команды SHOW SERVICES и SHOW RESOURCES для ознакомления с доступными сервисами и ресурсами. Например:

SHOW SERVICES IN google LIKE '%compute%';SHOW RESOURCES IN google.compute LIKE '%instances%';

Операции CRUD: выполняйте создание, чтение, обновление и удаление ресурсов с помощью знакомых SQL-запросов.

Примеры:
Создание ресурса:

INSERT INTO google.compute.disks (project, zone, name, sizeGb)
SELECT 'stackql-demo', 'europe-north1-a', 'disk-1', 16;

Обновление ресурса:

UPDATE google.compute.disks
SET sizeGb = 32WHERE project = 'stackql-demo' AND zone = 'europe-north1-a' AND name = 'disk-1';



Удаление ресурса:

DELETE FROM google.compute.disks
WHERE disk = 'disk-1' AND project = 'stackql-demo' AND zone = 'europe-north1-a';

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

Остановка инстанса:

EXEC google.compute.instances.stop  @instance = 'instance-1',
  @project = 'stackql-demo',  @zone = 'europe-north1-a';



Запуск инстанса:

EXEC google.compute.instances.start
  @instance = 'instance-1',  @project = 'stackql-demo',
  @zone = 'europe-north1-a';

➡️ Подробнее про инструмент

🐸Библиотека devops'a

🚀 DevDocs.io – must-have инструмент

DevDocs – универсальный хаб документации, объединяющий справочные материалы по Kubernetes, Docker, Terraform, AWS, Bash, Linux, Git, CI/CD и многим другим технологиям в одном месте.

Особенности:

• Мгновенный поиск — находим нужную команду в пару кликов

• Офлайн-доступ — документация всегда под рукой, даже без интернета

• Горячие клавиши — быстрая навигация без мышки.

Только документация, только хардкор

➡️ Читать документацию удобно

🐸Библиотека devops'a

⚡️ Как разбудить сервер, если он спит

Если у вас дома или в офисе стоит Linux-сервер, который большую часть времени простаивает, но при этом потребляет электричество – пора решить эту проблему.

➖ Что можно сделать

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

➖ Как это настроить

• Активируем Wake-on-LAN с поддержкой unicast — сервер будет реагировать не только на специальные WoL-пакеты, но и на обычные обращения по сети.

• Добавляем "дружественного соседа" — это устройство (например, Raspberry Pi), которое будет «притворяться» сервером, отвечая на сетевые запросы от имени спящего устройства.

• Настраиваем Avahi — для сетевого объявления сервисов, даже если сервер спит.

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

💬 Как вы решаете вопрос энергопотребления? Делитесь опытом в комментариях! 👇

📎 Подробный гайд

🐸Библиотека devops'a

Karpenter vs. Kubernetes Cluster Autoscaler

Если ваш Kubernetes-кластер нуждается в автоматическом масштабировании, у вас есть два мощных инструмента: Cluster Autoscaler (CA) и Karpenter. Давайте разберёмся какой выбрать.

➖ Cluster Autoscaler — классический подход

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

Он работает с группами узлов, что требует предварительной настройки, но обеспечивает стабильное масштабирование.

Кроме того, CA поддерживает AWS, GCP, Azure и другие облачные платформы.

❌ Минусы:

• Масштабирование зависит от предустановленных групп узлов.
• Медленнее реагирует на изменения.

➖ Karpenter — гибкость и скорость

Karpenter динамически создаёт новые узлы в реальном времени, когда это необходимо, без предварительно настроенных групп узлов. Он автоматически подбирает размер и тип узла в зависимости от требований нагрузки, что делает масштабирование более гибким.

Кроме того, Karpenter может использовать Spot-инстансы, помогая оптимизировать затраты на инфраструктуру.

Благодаря своей архитектуре он реагирует на изменения в кластере быстрее, чем традиционные инструменты автоматического масштабирования.

❌ Минусы:

• Требует более глубокой настройки.
• Пока поддерживает только AWS (официально).

💬 Какой инструмент используете вы? Делитесь опытом в комментариях👇

📎 Подробнее в источнике

🐸Библиотека devops'a

🔄 Flux обновился

Вышло обновление Flux — инструмента для управления Kubernetes в стиле GitOps. Разбираем, что изменилось и как это повлияет на использование Flux.

Главные обновления

➖ Настраиваемые проверки состояния

Теперь можно использовать Common Expression Language для настройки гибких проверок состояния ресурсов.

➖ Поддержка аутентификации через GitHub App

Flux теперь умеет работать с GitHub App вместо SSH/HTTPS-токенов.

➖ Гибкие метаданные для уведомлений
Теперь можно добавлять настраиваемые метаданные к событиям, улучшая контекст оповещений в Slack, Discord, Microsoft Teams и других системах

➖ Улучшение CLI и диагностики
Обновленный flux CLI получил новые команды для анализа и устранения неполадок в кластере.

➖ Эфемерные окружения с Flux Operator
Теперь можно автоматически деплоить изменения из Pull Requests в временные тестовые окружения.

➡️ Подробнее в блоге разработчиков

🐸Библиотека devops'a