Пишем Ansible-модули для управления разными системами хранения данных через Swordfish

Большинство современных систем хранения данных (СХД) предоставляют REST API для управления ими, включая настройку, конфигурирование, выполнение различных команд, получение логов, работу с пользователями и т.д. В зависимости от производителя СХД REST API могут отличаться друг от друга. Если вы используете несколько разных систем, их одновременная поддержка становится проблемой: нужно учитывать многообразие протоколов, интерфейсов, команд и способов взаимодействия с API.

Меня зовут Александр Пономарев, вместе с группой студентов СПбПУ Петра Великого на базе Лаборатории YADRO мы изучали способы сделать управление разными СХД менее трудоемким. Вариант, на котором мы остановились, — использовать системы, которые удовлетворяют спецификации Swordfish, в связке с Ansible. Рассказываю о проекте, который мы выполняли с инженерами компании и преподавателями университета.

https://habr.com/ru/companies/yadro/articles/784070/

Мы в MAX

#devops #девопс

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

Unused

CLI-инструмент, экспортер для Prometheus и модуль на Go для перечисления неиспользуемых дисков во всех облачных провайдерах

Этот репозиторий содержит библиотеку на Go для поиска ваших неиспользуемых постоянных дисков у разных облачных провайдеров, а также бинарные файлы для отображения этой информации в CLI или экспорта метрик для Prometheus.

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

https://github.com/grafana/unused

Мы в MAX

#devops #девопс

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

Что такое docker и какие инструменты linux лежат в основе? Для чего он используется?

Docker базируется на технологиях:

🔸 namespaces — обеспечивает изоляцию (например, можно айдишники процессов разместить в разных контейнерах)
🔸 cgroups — позволяет управлять группой процессов, и управлять их ресурсами
🔸 capabilities — позволяет дать некоторые рут привелегии процессам или исполняемым файлам. Например, изменить UID процесса на 0, или дать возможность монтировать файловые системы.
🔸 overlay namespaces — (overlayFS, overlay2-драйвер) - файловая система, которая умеет работать "слоями". Не сохранять каждый раз новые файлы, а наслаивать один слой на другой, тем самым экономя место на диске и время создания контейнера.

А вот докер — это уже штука, которая всеми этими технологиями рулит, удобным для нас образом.

Компоненты докера:

🔻 Docker Daemon — тот самый Container Engine; запускает контейнеры.
🔻 Docker CLI — утилита по управлению Docker.
🔻 Dockerfile — инструкция по тому, как собирать образ.
🔻 Image — образ, из которого раскатывается контейнер.
🔻 Container
🔻 Docker registry — хранилище образов.

На Docker_host работает Docker daemon и запускает контейнеры.
Client — передаёт команды: собери образ, скачай образ, запусти контейнер. Docker daemon ходит в registry и выполняет их. Docker-клиент может обращаться и локально (к юникс-сокету), и по TCP с удалённого хоста.

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

Docker CLI — клиентская часть Docker, консольная утилита для работы с демоном. Может работать не только локально, но и по сети.

Мы в MAX

#devops #девопс

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

Для чего нужна команда git commit --amend?

Команда git commit --amend используется для изменения последнего коммита в локальном репозитории. Она позволяет исправить сообщение коммита, добавить в него изменения, которые не были учтены, или удалить файлы, которые не должны были быть в коммите.

Основные случаи использования:

1. Изменение сообщения коммита: если было допущено опечатку или необходимо уточнить содержание сообщения коммита.

   git commit --amend -m "Новое сообщение коммита"
   

2. Добавление изменений в последний коммит: если были забыты изменения, которые нужно включить в последний коммит, можно их добавить, выполнить git add для этих файлов и затем git commit --amend, чтобы объединить их с предыдущим коммитом.

3. Удаление ненужных файлов: если случайно добавлен лишний файл, можно удалить его с помощью git rm, затем выполнить git commit --amend, чтобы пересобрать коммит без этого файла.

После выполнения git commit --amend создается новый коммит с измененной историей, что важно помнить, если работа ведется в команде.

Мы в MAX

#devops #девопс

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

Архитектура кластеров Kubernetes - выбор размера рабочего узла

Стоит ли создавать кластер Kubernetes с меньшим количеством крупных узлов или с большим количеством мелких узлов? В этой статье мы рассмотрим все плюсы и минусы.

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

Если вы создаете локальный кластер, стоит ли заказывать серверы последнего поколения или использовать дюжину или около того старых машин, которые валяются в вашем центре обработки данных?

Или если вы используете управляемый сервис Kubernetes, например Google Kubernetes Engine (GKE), следует ли вам использовать восемь экземпляров n1-standard-1 или два экземпляра n1-standard-4 для достижения желаемой вычислительной мощности?

https://learnk8s.io/kubernetes-node-size

Мы в MAX

#devops #девопс

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

💡 Сегодня немного про боль Kubernetes-кластеров

Когда у тебя всё крутится в k8s, кажется - удобно: автоскейлинг, изоляция, сервисы живут своей жизнью. Но как только в кластере начинают появляться десятки namespace и сотни подов, без нормальной политики ресурсов всё превращается в хаос.

👉 У каждого пода должны быть requests и limits. Если этого нет - кластер живёт как коммуналка без счётчиков: кто успел, тот и съел. Один жадный контейнер может легко задушить соседей.

👉 Мониторинг на уровне ResourceQuota и LimitRange реально спасает от «сюрпризов» в проде.

👉 А ещё - включите PodPriority и Preemption. Это даёт возможность критичным сервисам выжить, даже если какой-то non-prod под начал жрать всю память.

В итоге Kubernetes сам по себе не магия. Это инструмент. А инструмент требует гигиены и правил.

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

Sudo без бинарного setuid или SSH через UNIX-сокет

В этом посте я подробно расскажу, как заменить sudo (программу с setuid), используя SSH через локальный UNIX-сокет.

Я считаю, что программы с setuid / setgid — это устаревшая часть наследия UNIX, которую следует исключить. В будущем посте я объясню причины безопасности, стоящие за этим утверждением.

Это связано с работой группы Confined Users SIG в Fedora.

https://tim.siosm.fr/blog/2023/12/19/ssh-over-unix-socket/

Мы в MAX

#devops #девопс

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

Teller — универсальный open-source менеджер секретов для разработчиков

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

Вместо использования кастомных скриптов, токенов в файлах .zshrc, видимых команд EXPORT в истории bash, ошибочно размещенных файлов .env.production и других уязвимостей на рабочей станции, просто используйте Teller и подключите его к любому хранилищу секретов, ключевому хранилищу или облачному сервису, который вам нужен (Teller поддерживает HashiCorp Vault, AWS Secrets Manager, Google Secret Manager и многие другие).

Вы можете использовать Teller для упорядочения своего окружения или внедрения его как процесса и лучшей практики для вашей команды.

https://github.com/tellerops/teller

Мы в MAX

#devops #девопс

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

mk - Интерактивный запуск задач для Makefile(Taskfile.yml)

Функции:
- Интерактивный интерфейс: Просматривайте и выбирайте доступные команды make с помощью стрелок или фильтруйте, вводя текст.
- Документация: Ознакомьтесь с описанием каждой команды, чтобы понять её назначение и использование.
- Клавиши, как в Vim: Используйте j и k для навигации, Enter для выполнения, а q для выхода.
- Фильтрация: Быстро находите команды, вводя часть их названия. Нажмите ? для справки.
- Удалённый Makefile: Загрузите Makefile с удалённого URL и выполните команды.
- Локальный Makefile: Загрузите Makefile из любой директории и выполните команды.
- Поддержка Taskfile.yml: Загрузите Taskfile.yml из удалённого URL или локального пути и выполните задачи.

https://github.com/orangekame3/mk

Мы в MAX

#devops #девопс

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

6 Docker-фич для продвинутого использования

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

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

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

Мы в MAX

#devops #девопс

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

Когда повторы убивают: метастабильные отказы в распределённых системах

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

https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s11-bronson.pdf

Мы в MAX

#devops #девопс

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

Buildg - Интерактивный отладчик для Dockerfile, с поддержкой IDE (VS Code, Emacs, Neovim и т.д.).

Source-level inspection
Breakpoints and step execution
Interactive shell on a step with your own debugigng tools
Based on BuildKit (with unmerged patches)
Supports rootless

https://github.com/ktock/buildg

Мы в MAX

#devops #девопс

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

Vault-secrets-operator

Создавайте секреты Kubernetes из Vault для безопасного рабочего процесса на основе GitOps.

https://github.com/ricoberger/vault-secrets-operator

Мы в MAX

#devops #девопс

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

🧠 Логи — Самые частые IP-адреса в access.log

Когда нужно быстро понять, кто чаще всего лупит по серверу — вот простой однострочник:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

🔍 Что делает:
1. awk '{print $1}' — вытаскивает IP из первой колонки.
2. sort и uniq -c — считает повторы.
3. sort -nr | head — выводит топ-10 по частоте.

📊 Вывод будет примерно такой:

  152 192.168.1.10
  103 203.0.113.45
   87 172.16.0.5

🔥 Подходит для NGINX, Apache и других web-логов с классическим форматом.

👉@bash_srv

Перечислите некоторые исходные пространства имен, из которых запускается Kubernetes

Вот некоторые начальные пространства имен:
Default: это пространство имен включено Kubernetes, чтобы пользователи могли начать использовать новый кластер без необходимости предварительного создания пространства имен.
Kube-system: это пространство имен для объектов, созданное системой Kubernetes.
Kube-public: это пространство имен доступно для чтения как аутентифицированным, так и неаутентифицированным клиентам. Оно зарезервировано в основном для использования в кластере.

Мы в MAX

#devops #девопс

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