​​В комментариях к заметкам про синхронизацию файлов не раз упоминались отказоустойчивые сетевые файловые системы. Прямым представителем такой файловой системы является GlusterFS. Это условный аналог Ceph, которая по своей сути не файловая система, а отказоустойчивая сеть хранения данных. Но в целом обе эти системы используются для решения одних и тех же задач. Про Ceph я писал (#ceph) уже не раз, а вот про GlusterFS не было ни одного упоминания.

Вообще, когда выбирают, на основе чего построить распределённое файловое хранилище, выбирают и сравнивают как раз GlusterFS и Ceph. Между ними есть серьёзные отличия. Первое и самое основное, GlusterFS - это файловая система Linux. При этом Ceph - объектное, файловое и блочное хранилище с доступом через собственное API, минуя операционную систему. Архитектурно для настройки и использования GlusterFS более простая система и это видно на практике, когда начинаешь её настраивать и сравнивать с Ceph.

Я покажу на конкретном примере, как быстро поднять и потестировать GlusterFS на трёх нодах. Для этого нам понадобятся три идентичных сервера на базе Debian с двумя жёсткими дисками. Один под систему, второй под GlusterFS. Вообще, GlusterFS - детище в том числе RedHat. На её основе у них построен продукт Red Hat Gluster Storage. Поэтому часто можно увидеть рекомендацию настраивать GlusterFS на базе форков RHEL с использованием файловой системы xfs, но это не обязательно.

❗️ВАЖНО. Перед тем, как настраивать, убедитесь, что все 3 сервера доступны друг другу по именам. Добавьте в /etc/hosts на каждый сервер примерно такие записи:
server1 10.20.1.1
server2 10.20.1.2
server3 10.20.1.3

На все 3 сервера устанавливаем glusterfs-server:
# apt install glusterfs-server
Запускаем также на всех серверах:
# service glusterd start

На server1 добавляем в пул два других сервера:
# gluster peer probe server2
# gluster peer probe server3
На остальных серверах делаем то же самое, только указываем соответствующие имена серверов.

Проверяем статус пиров пула:
# gluster peer status
На каждом сервере вы должны видеть два других сервера.

На всех серверах на втором жёстком диске создайте отдельный раздел, отформатируйте его в файловую систему xfs или ext4. Я в своём тесте использовал ext4. И примонтируйте в /mnt/gv0.
# mkfs.ext4 /dev/sdb1
# mkdir /mnt/gv0
# mount /dev/sdb1 /mnt/gv0

Создаём на этой точке монтирования том glusterfs:
# gluster volume create gv0 replica 3 server1:/mnt/gv0 server2:/mnt/gv0 server3:/mnt/gv0
Если получите ошибку:
volume create: gv0: failed: Host server1 is not in 'Peer in Cluster' state
то проверьте ещё раз файл hosts. На каждом хосте должны быть указаны все три ноды кластера. После исправления ошибок, если есть, остановите службу glusterfs и почистите каталог /var/lib/glusterd.

Если всё пошло без ошибок, то можно запускать том:
# gluster volume start gv0
Смотрим о нём информацию:
# gluster volume info

Теперь этот volume можно подключить любому клиенту, в роли которого может выступать один из серверов:
# mkdir /mnt/gluster-test
# mount -t glusterfs server1:/gv0 /mnt/gluster-test

Можете зайти в эту директорию и добавить файлы. Они автоматически появятся на всех нодах кластера в директории /mnt/gv0.

По этому руководству наглядно видно, что запустить glusterfs реально очень просто. Чего нельзя сказать о настройке и промышленно эксплуатации. В подобных системах очень много нюансов, которые трудно учесть и сразу всё сделать правильно. Нужен реальный опыт работы, чтобы правильно отрабатывать отказы, подбирать настройки под свою нагрузку, расширять тома и пулы и т.д. Поэтому в простых ситуациях, если есть возможность, лучше обойтись синхронизацией на базе lsyncd, unison и т.д. Особенно, если хосты территориально разнесены. И отдельное внимание нужно уделить ситуациям, когда у вас сотни тысяч мелких файлов. Настройка распределённых хранилищ будет нетривиальной задачей, так как остро встанет вопрос хранения и репликации метаданных.

⇨ Сайт / Исходники

#fileserver #devops

​​Я вроде бы уже когда-то упоминал про англоязычную рассылку devopsweekly.com, но не могу найти этой записи. Возможно и нет. В общем, это такая олдскульная рассылка на почту в текстовом формате раз в неделю с некоторыми новостями. Я её давно уже читаю, более двух лет.

Мне нравится такой формат, когда раз в неделю, в воскресенье, приходят новости по определённой тематике. Читаю я там далеко не всё, но просматриваю регулярно. Я как раз в воскресенье вечером сажусь за компьютер, проверить и подготовить список основных дел на неделю. Заодно читаю эту рассылку.

Вчерашнюю заметку про HTTPS записи DNS как раз там повстречал. Было бы круто, если бы кто-то ещё начал вести подобные рассылки по разным направлениям: безопасность, сети, обновления, Windows, Linux и т.д. Можно в Telegram. А лучше и здесь, и по почте.

Дарю готовую идею 😀 Я сам когда-то думал подобное вести, но у меня нет на это времени. Данный канал всё занимает. В таких подборках важно, чтобы они выходили не чаще раза в неделю. В качестве монетизации можно одну новость делать рекламную.

Если кто-то знает похожие рассылки, не обязательно на русском языке, поделитесь.

#devops

Что такое Devops 😂
https://www.youtube.com/watch?v=NXwtcjOdaHw

Work-life balance ставишь 0.

Не понял только одно. Зачем докер контейнер упаковали в zip?

#юмор #devops

Я уже не раз делал заметки про Gitea - легковесную open source систему для управления git репозиториями. Изначально это был просто веб интерфейс для git, который можно было сделать с помощью соответствующей темы очень похожей на github. Написана Gitea на Go и по своей сути это просто бинарник, поэтому с установкой и настройкой никаких проблем. Бонусом гошечки идёт очень быстрая работа и отзывчивость веб интерфейса.

Как я уже сказал, Gitea была создана просто для работы с кодом, без какой-либо автоматизации. Для построения конвейера для сборки, деплоя и хранения образов я предлагал связку: Gitea + Drone CI + Docker Registry.

С недавних пор в Gitea завезли Gitea Actions, которые полностью совместимы с GitHub Actions. То есть она превратилась в полноценную CI/CD систему с собственным Package Registry и Gitea Runner. Получился аналог gitlab на минималках.

Подробно посмотреть обзор всех этих возможностей, а также инструкцию по настройке, можно в серии из двух видеороликов:
▶️ Gitea-01: домашний github (+ actions)
▶️ Gitea-02: домашний github (+ actions)

#git #devops #cicd

Есть тут настоящие девопсы? У вас так же в среднем проходит рабочий день? В целом, распорядок неплохой.

Музыкальная комната немного удивила. Впервые услышал, что такие есть в офисах. Немного поискал информации в интернете. Оказывается, такие комнаты много где есть - Яндекс, VK, Ростелеком и т.д.

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

p.s. видео отсюда

#devops

​​Для автоматической проверки Docker образов на уязвимости (CVE) есть хороший open source инструмент Trivy. Год назад я делал по нему пару заметок с обзором и автоматическим исправлением уязвимостей. Потом всё это в небольшую статью оформил.

Этот продукт хорошо дополняет open source утилита Dockle. Она тоже проверяет контейнеры на уязвимости, но помимо этого проверяет образ на соответствие best-practice Dockerfile и рекомендации CIS Docker Benchmarks (#cis).

Использовать очень просто, так как это по сути одиночный бинарник. В репозитории есть пакеты для установки под все популярные системы. Можно запустить и в Docker без установки:

# docker run --rm goodwithtech/dockle:v0.4.14 [YOUR_IMAGE_NAME]

Пример отчёта можно посмотреть на тестовом образе, для которого есть замечания:

# docker run --rm goodwithtech/dockle:v0.4.14 goodwithtech/dockle-test:v2

С помощью ключа -f json вывод можно сохранить в json файле. Dockle легко интегрировать в пайплайн. В репозитории есть примеры (gitlab).

⇨ Исходники

#docker #devops #cicd #security

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

Работает он примерно так. Запускаем контейнер, внутри которого ничего нет, кроме nginx:

# docker run --name nginx -d -p 8080:80 nginx
# docker exec -it nginx bash
# ps axf
bash: ps: command not found

Подключаем к нему network-multitool:

# docker run --rm -it \
--network=container:nginx \
--pid container:nginx \
wbitt/network-multitool:alpine-extra bash

# ps axf
  PID TTY   STAT  TIME COMMAND
   47 pts/0  Ss   0:00 bash
   60 pts/0  R+   0:00 \_ ps axf
   1 ?    Ss   0:00 nginx: master process nginx -g daemon off;
   29 ?    S   0:00 nginx: worker process
   31 ?    S   0:00 nginx: worker process
   30 ?    S   0:00 nginx: worker process
   32 ?    S   0:00 nginx: worker process

Дальше всё остальное можно запускать: ping, dig, tcpdump и т.д.

Я тут выбрал самую жирную сборку alpine-extra, где максимальный набор инструментов, в том числе tshark, ApacheBench, mysql & postgresql client, git и т.д. Если всё это не надо, то используйте alpine-minimal. Описание сборок в репозитории.

Похожую функциональность имеет cdebug. У него принцип работы такой же, только он для удобства собран в бинарник. А подключается он к контейнерам точно так же.

Кстати, с помощью network-multitool можно и хост дебажить, если не хочется его засорять различными утилитами. Запускаем его в сети хоста и пользуемся:

# docker run --rm -it --network=host wbitt/network-multitool:alpine-extra bash
# tcpdump

На хост ничего ставить не надо. Полезная штука, берите на вооружение.

#docker #devops

​​Недавно посмотрел видео про Diun (Docker Image Update Notifier). Это маленькая консольная утилита, которая делает одно простое действие - проверяет наличие обновлений для образов запущенных контейнеров на хосте. Если обновление есть, уведомляет через email, telegram, gotify, slack и другие каналы. Больше ничего не делает, не качает обновление, не применяет, не перезапускает образ.

Diun состоит из одного бинарника. Запустить можно как на хосте, создав службу systemd, так и в контейнере, прокинув туда docker.sock. Процесс описан в документации:

# docker run -d --name diun \
 -e "TZ=Europe/Moscow" \
 -e "DIUN_WATCH_WORKERS=20" \
 -e "DIUN_WATCH_SCHEDULE=0 */6 * * *" \
 -e "DIUN_WATCH_JITTER=30s" \
 -e "DIUN_PROVIDERS_DOCKER=true" \
 -e "DIUN_NOTIF_TELEGRAM_TOKEN=1493678911:AAHtETAKqxUH8ZpyC28R-wxKfvH8WR6-vdNw" \
 -e "DIUN_NOTIF_TELEGRAM_CHATIDS=211805263" \
 -v "$PWD/data:/data" \
 -v "/var/run/docker.sock:/var/run/docker.sock" \
 -l "diun.enable=true" \
 crazymax/diun:latest

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

Diun умеет следить за актуальностью образов запущенных Docker контейнеров, образов подов в Kubernetes, Swarm, Nomad. Также можно настроить наблюдение за образами, используемыми в определённых Dockerfiles или конфигурационных файлах yaml, где указаны образы.

Простая, маленькая, удобная утилита. Описание установки, настройки, работы:
▶️ Diun - это вам не watchtower

⇨ Сайт / Исходники

#docker #devops

​​Наиболее популярным и простым в настройке мониторингом сейчас является Prometheus. Простым не в плане возможностей, а в плане начальной настройки. Так как для него очень много всего автоматизировано, начать сбор метрик можно в несколько простых действий. Мониторинг сразу заработает и дальше с ним можно разбираться и настраивать.

Напишу краткую шпаргалку по запуску связки Prometheus + Grafana, чтобы её можно было сохранить и использовать по мере надобности. Я установлю их в Docker, сразу буду мониторить сам Prometheus и локальных хост Linux. Подключу для примера ещё один внешний Linux сервер.

Ставим Docker:

# curl https://get.docker.com | bash -

Готовим файл docker-compose.yml:

# mkdir ~/prometheus && cd ~/prometheus
# touch docker-compose.yml

Содержимое файла:

version: '3.9'
networks:
monitoring:
driver: bridge
volumes:
prometheus_data: {}

services:

prometheus:
image: prom/prometheus:latest
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
- prometheus_data:/prometheus
container_name: prometheus
hostname: prometheus
command:
- '--config.file=/etc/prometheus/prometheus.yml'
- '--storage.tsdb.path=/prometheus'
expose:
- 9090
restart: unless-stopped
environment:
TZ: "Europe/Moscow"
networks:
- monitoring

node-exporter:
image: prom/node-exporter
volumes:
- /proc:/host/proc:ro
- /sys:/host/sys:ro
- /:/rootfs:ro
container_name: exporter
hostname: exporter
command:
- '--path.procfs=/host/proc'
- '--path.rootfs=/rootfs'
- '--path.sysfs=/host/sys'
- '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$|/)'
expose:
- 9100
restart: unless-stopped
environment:
TZ: "Europe/Moscow"
networks:
- monitoring

grafana:
image: grafana/grafana
user: root
depends_on:
- prometheus
ports:
- 3000:3000
volumes:
- ./grafana:/var/lib/grafana
- ./grafana/provisioning/:/etc/grafana/provisioning/
container_name: grafana
hostname: grafana
restart: unless-stopped
environment:
TZ: "Europe/Moscow"
networks:
- monitoring

И рядом кладём конфиг prometheus.yml:

scrape_configs:
- job_name: 'prometheus'
scrape_interval: 5s
scrape_timeout: 5s
static_configs:
- targets: ['localhost:9090']

- job_name: 'node-local'
scrape_interval: 5s
static_configs:
- targets: ['node-exporter:9100']

Запускаем весь стек:

# docker-compose up -d

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

Ждём, когда всё поднимется, и идём по IP адресу сервера на порт 3000. Логинимся в Grafana под учёткой admin / admin. Заходим в Connections ⇨ Data sources и добавляем источник prometheus. В качестве параметра Prometheus server URL указываем http://prometheus:9090. Сохраняем.

Идём в Dashboards, нажимаем New ⇨ Import. Вводим ID дашборда для Node Exporter - 1860. Сохраняем и идём смотреть дашборд. Увидите все доступные графики и метрики хоста Linux, на котором всё запущено.

Идём на удалённый Linux хост и запускаем там любым подходящим способом node-exporter. Например, через Docker напрямую:

# docker run -d --net="host" --pid="host" -v "/:/host:ro,rslave" prom/node-exporter:latest --path.rootfs=/host

Проверяем, что сервис запущен на порту 9100:

# ss -tulnp | grep 9100

Возвращаемся на сервер с prometheus и добавляем в его конфиг еще одну job с этим сервером:

- job_name: 'node-remote'
scrape_interval: 5s
static_configs:
- targets: ['10.20.1.56:9100']

Перезапускаем стек:

# docker compose restart

Идём в Dashboard в Grafana и выбираем сверху в выпадающем списке job от этого нового сервера - node-remote.

На всю настройку уйдёт минут 10. Потом ещё 10 на настройку базовых уведомлений. У меня уже места не хватило их добавить сюда. Наглядно видна простота и скорость настройки, о которых я сказал в начале.

❗️В проде не забывайте ограничивать доступ ко всем открытым портам хостов с помощью файрвола.

#мониторинг #prometheus #devops

​​Вчера была заметка про быструю установку связки Prometheus + Grafana. Из-за лимита Telegram на длину сообщений разом всё описать не представляется возможным. А для полноты картины не хватает настройки уведомлений, так как мониторинг без них это не мониторинг, а красивые картинки.

Для примера я настрою два типа уведомлений:

◽SMTP для только для метки critical
◽Telegram для меток critical и warning

Уведомления будут отправляться на основе двух событий:

▪️ С хоста нету метрик, то есть он недоступен мониторингу, метка critical
▪️ На хосте процессор занят в течении минуты более чем на 70%, метка warning

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

Постить сюда все конфигурации в формате yaml неудобно, поэтому решил их собрать в архив и прикрепить в следующем сообщении. Там будут 4 файла:

- docker-compose.yml - основной файл с конфигурацией всех сервисов. Его описание можно посмотреть в предыдущем посте. Там добавился новый контейнер с alertmanager и файл с правилами для prometheus - alert.rules
- prometheus.yml - настройки Прометеуса.
- alert.rules - файл с двумя правилами уведомлений о недоступности хоста и превышении нагрузки CPU.
- alertmanager.yml - настройки alertmanager с двумя источниками для уведомлений: email и telegram. Не забудьте там поменять токен бота, id своего аккаунта, куда бот будет отправлять уведомления и настройки smtp.

Для запуска всего стека с уведомлениями достаточно положить эти 4 файла в отдельную директорию и там запустить compose:

# docker compose up

На момент отладки рекомендую запускать прямо в консоли, чтобы отлавливать ошибки. Если где-то ошибётесь в конфигурациях правил или alertmanager, сразу увидите ошибки и конкретные строки конфигурации, с которыми что-то не так. В таком случае останавливайте стэк:

# docker compose stop

Исправляйте конфиги и заново запускайте. Зайдя по IP адресу сервера на порт 9090, вы попадёте в веб интерфейс Prometheus. Там будет отдельный раздел Alerts, где можно следить за работой уведомлений.

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

#мониторинг #prometheus #devops