Продолжаем ковырять angie, на этот раз посмотрим на Status Page, которая отображает всю статистику по веб-серверу. Выглядит прям хорошо.
ㅤ
Устанавливаем пакет:

sudo apt install angie-console-light

В папке /usr/share/angie-console-light/html появляется статика.

Добавляем локейшен:

location /console/ {
    auto_redirect on;

    alias /usr/share/angie-console-light/html/;
    index index.html;

    location /console/api/ {
        api /status/;
    }
}

Теперь открываем в браузере и видим красивую мордочку. Демо мордочки можешь посмотреть здесь.

Да, не забываем включить Basic Auth чтобы хитрожопые не подглядывали.

У меня на паре пет проектов эта морда включена (графана избыточна), чисто посмотреть статусы раз в сутки, которые возвращают 500ку. Если оно горит красным, значит что-то где-то пошло по пизде.

Подробнее читай в официальной документации.

🛠 #angie #devops
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Load Average на пальцах

Все про него знают, но не все понимают.
ㅤ
Давай рассмотрим такие цифры:

0.30  1.20  0.80

1. За последнюю 1 минуту средняя очередь = 0.30
2. за 5 минут = 1.20
3. за 15 минут = 0.80

Сразу куча вопросов, а что такое «очередь»?

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

➡️ Главное правило

Сравниваем Load Average с количеством ядер.

- У тебя 4 ядра → нормальная нагрузка = до 4.0
- У тебя 1 ядро → нормальная нагрузка = до 1.0
- У тебя 8 ядер → нормальная нагрузка = до 8.0

🟢 Всё в порядке:

- LA ≤ количество ядер → CPU успевает всё делать, очередей нет.

🟡 Чёт уже не то, подгрузилось:

- LA ≈ количество ядер × 1–2 → процессы начинают стоять в очереди, но система пока еще жива.

🔴 Жопа:

- LA сильно > количества ядер → процессы стоят в очереди, всё тормозит.

➡️ Теперь на котиках

Ты стоишь в магазине:

- 1 касса, 1 человек в очереди → заебись
- 1 касса, 10 человек в очереди → жопа
- 4 кассы, 6 человек → пока норм

CPU = кассы, Load Average == очередь.

LA это не про загрузку CPU в процентах — это просто «очередь».

➡️ Как задебажить

Берем top, htop или подобное и смотрим столбец %CPU, если один процесс жрёт 100% на однопроцессорной системе — он пидарас и забил ядро. Если процесс жрёт 300% на 4-ядерной — он занял 3 ядра.

Смотрим самых прожорливых пидарасов:

ps aux --sort=-%cpu | head

Если ничего не нашел, то смотрим в сторону:

- I/O wait — медленный диск / много дисковых операций
- много процессов, но каждый почти ничего не ест (fork storm)
- сеть или блокировки

Капля в море, но это базовый чеклист на ситуацию, когда сервер ушел в «полку».

А ты добавляй в комменты, что еще можно вынести в дебаг, будет полезно.

🛠 #linix #devops
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

А вот это нам надо!

TUI админка для Proxmox. И да, ее можно поставить себе локально и цепануть к ней все твои Proxmox кластера, которые находятся где-то в сети.
ㅤ
Называется всё это добро — pvetui

Работает под всеми операционками, так как реализован на GO.

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

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

Установка и запуск:

go install github.com/devnullvoid/pvetui/cmd/pvetui@latest
/home/user/go/bin/pvetui

Под другие ОС:

yay -S pvetui-bin
yay -S pvetui-git
brew install --cask devnullvoid/pvetui/pvetui
scoop bucket add pvetui https://github.com/devnullvoid/scoop-pvetui
scoop install pvetui

# либо из исходников
git clone https://github.com/devnullvoid/pvetui.git
cd pvetui
make install

При первом запуске утилита попросит сконфигурировать её. Жмем пару раз Enter, открывается редактор конфига, заполняем необходимые поля.

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

Но опять же если у тебя API ключ, делаешь под своё конфигурацию.

Инициализация, закончена, видим сообщение:

✅ Configuration is ready!
🔄 Please re-run 'pvetui' to start the application with your new configuration.
🚪 Exiting.

Запускаем морду и смотрим что получилось.

/home/user/go/bin/pvetui

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

А получилось у нас прям заебись. Теперь я нажимаю ALT+2 и попадаю в список всех своих виртуальных машин. Стрелочками выбираю нужную мне машину и нажимаю букву «m», открывается менюшка.

В менюшке можно сразу провалиться в машину по SSH, что мне и нужно. Но это еще не всё, там и ребуты и миграции, даже VNC есть (нужен xdg). Короче базовый минимум поадминить присутствует.

Да, если нажать «ESC» то откроется еще одна глобальная менюшка для конфигурации самой утилиты, выбор профилей, управление плагинами и т.п.

Короче явки-ссылки я тебе дал, дальше сам смотри, всё там гибко конфигурируется и настраивается. И тем более TUI интерфейсы сейчас прям в трендах.

Хорошей тебе рабочей недели! Не болей!

🛠 #selfhosting #linux #devops
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Как я обновил Proxmox и остался жив

Здрасти, приехали. Сегодня будем обновлять proxmox 8 на 9.1 Оно в принципе и необязательно, но очень хотелось потыкать новую фичу с OCI.

OCI это способ запускать контейнеры из Docker-образов. То есть proxmox теперь умеет скачивать Docker-образы (OCI-images) и превращать их в LXC-контейнеры.

А нахуя? Чтобы проще запускать приложения, которые уже существуют в виде Docker-образов. Теперь в LXC не нужно поднимать отдельно докер демон, все работает из коробки.

Ладно, отвлеклись. Про OCI отдельно распишу. Сегодня обновляем всю эту трихомудию до нужной версии.

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

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

По классике сюда всё не влезло, поэтому гоу в блог читать продолжение 👇

🅰️🅰️🅰️🅰️🅰️🅰️🅰️🅰️
➡️ https://two.su/4ui2c
🅰️🅰️🅰️🅰️🅰️🅰️🅰️🅰️

🛠 #proxmox #devops #selfhosting
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

В Proxmox 9.1 завезли OCI. В предыдущем посте про обновление с 8ки на 9ку я это уже упоминал, поэтому повторяться не буду.

➡️ Как я обновлял Proxmox и остался жив

Сегодня посмотрим как OCI работает на практике.
ㅤ
OCI это не какая-то отдельная сущность, это тот же самый LXC контейнер в котором будет запущен нужный тебе контейнер.

Тут важное замечание — тебе не нужно устанавливать руками docker демона в LXC и только затем запускать контейнер. OCI все сделает само. Это не какой-то встроенный docker или k8s. Всё так или иначе работает под управлением LXC.

К примеру возьмем заезженный образ nginx, который валяется в dockerhub:

nginx:latest

Заходим в Proxmox и идем в раздел с шаблонами, там будет кнопка Pull from OCI Registry.

➡️ ЧИТАТЬ ПРОДОЛЖЕНИЕ


🛠 #proxmox #devops #selfhosting
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Синхронизируем настройки Pi-Hole между инстансами.
ㅤ
У меня в сети живет несколько нод с pi-hole, которые раскиданы по разным устройствам (proxmox, raspberry pi и т.п.). И сразу встала необходимость, чтобы все ноды с pi-hole имели одинаковые настройки.

Pi-hole — это сетевой DNS‑фильтр и блокировщик рекламы с открытым исходным кодом. Он работает как свой DNS‑сервер, перехватывает DNS‑запросы от устройств в локальной сети и блокирует домены из списков рекламы, трекеров и вредоносных сайтов, возвращая «пустой» ответ вместо IP‑адреса рекламного ресурса.

Стратегия такая, одна нода будет master, где производятся все основное настройки, затем все эти настройки раскатываются на другие ноды (slave).

Раньше такой кейс разруливали с помощью Orbital Sync, Nebula Sync и т.п. Но одно сдохло, другое работает через хуй-пизда-копыто. Короче нужно рабочее решение.

Пишем свой велосипед

#!/usr/bin/env bash

set -euo pipefail

PRIMARY_PIH_DIR="/etc/pihole"

SECONDARY_USER="root"
SECONDARY_PIH_DIR="/etc/pihole"
SECONDARY_HOSTS=(
  "192.168.10.97"
  "192.168.10.98"
  "192.168.10.99"
)

RSYNC_EXCLUDES=(
  "--exclude=pihole-FTL.db"
  "--exclude=macvendor.db"
  "--exclude=*.log"
)

echo "[pihole-sync] $(date): start"

for host in "${SECONDARY_HOSTS[@]}"; do
  echo "[pihole-sync] ---- host ${host} ----"

  rsync -az \
    "${RSYNC_EXCLUDES[@]}" \
    "${PRIMARY_PIH_DIR}/" \
    "${SECONDARY_USER}@${host}:${SECONDARY_PIH_DIR}/"

  echo "[pihole-sync] ${host}: restart dns"
  ssh "${SECONDARY_USER}@${host}" "pihole restartdns >/dev/null 2>&1" || \
    echo "[pihole-sync] ${host}: FAILED to restart dns"

done

echo "[pihole-sync] $(date): done"

В SECONDARY_HOSTS забиваем айпишники slave инстансов, этакий массив. На этом настройка скрипта закончена. Весь лишний мусор вроде логов и статистики синхронизироваться не будет.

Сохраняем, чмодим, кидаем в крон (а лучше в systemd с таймерами):

Про таймеры подробно писал тут и тут.

crontab -e
*/5 * * * * /usr/local/sbin/pihole-sync.sh >> /var/log/pihole-sync.log 2>&1

Не забываем прокинуть ssh ключи с master на slave, чтобы скрипт не уперся рогом в логин и пароль.

Вроде мелочь, а полезная, да еще и на bash. Хороших тебе предстоящих выходных и береги себя!

🛠 #bash #linux #devops #selfhosting
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Volume VS Bind в Docker

Сегодня рассмотрим, как и в каких случаях правильно использовать bind или volume при запуске docker контейнеров.

Пересмотрев кучу docker compose файлов, можно сделать вывод — большинство даж не понимают что они делают. Что печально, прожжённые девопс-инженеры продолжают харкодить и творить дичь. Видимо придерживаются методологии — у меня работает, остальное похуй.

Вообще есть правило:

- Если нужно редактировать файлы руками с хоста, используешь Bind Mount.

- Если данные нужны только приложению (БД, логи, кэш) используешь Volumes.
ㅤ
Шпаргалка, что есть что:

# Это docker volume, данные хранятся в
# /var/lib/docker/volumes/

volumes:
  - nginx_data:/etc/data

# Это bind mount, данные хранятся рядом
# с файлом docker-compose.yml

volumes:
  - ./data:/etc/data

Ну и никто не запрещает это совмещать, но старайся разделять. Тем более при работе с volumes, в docker есть удобные команды, ну и через midnight commander можешь физически потыкать файлы, при условии если есть рутовый доступ к файловой системе.

Самое главное не делай так:

Про этот случай я и писал в начале поста, вроде человек 20 лет отрубил в айтишке, а пишет хуйню.

volumes:
  - /home/anus/conf.d:/etc/nginx/cond.f
  - /home/anus/data/logs:/var/log/nginx

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

Я лично предпочитаю volumes и порой даже конфиги в нем храню, потому что этот volume можно легко примаунтить к любому другому контейнеру и получить доступ к этим файлам.
Банально возьмем связку nginx + php-fpm, используем один общий volume и php скрипты корректно выполняются.

Bind mount удобен при разработке и отладки. Ты монтируешь папку с исходным кодом проекта. Правишь код в IDE на хосте и изменения мгновенно подхватываются приложением внутри контейнера.

А еще есть полезный флаг: «RO», используется в ситуациях, когда тебе нужно что-бы приложение в контейнере не перезаписывало данные в примонтированном каталоге. Удобно для отладки или для каких-то ограничений.

Пример:

services:
  web:
    image: nginx:alpine
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - ./logs:/var/log/nginx

При всём желании, конфиг nginx.conf нельзя модифицировать из приложения в контейнере. Это можно сделать только на хостовой машине. Второй же bind mount по умолчанию - «RW».

Ну и пожелания:

- Используйте именованные тома, вместо анонимных томов (которые выглядят как длинный хеш 4f32a...) всегда давайте томам осмысленные имена: db_data, app_uploads

- Придерживайся принципа - «Один контейнер — один вольюм». Старайтесь не монтировать один и тот же вольюм в 10 разных контейнеров на запись. Если нужно делиться данными, один контейнер должен быть «владельцем» (RW), а остальные — «потребителями» (RO).

- Бэкап: Правило «3-2-1». Volume — это не бэкап, это просто место хранения. Если ты случайно ёбнешь вольюм командой prune, данные исчезнут.

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

docker run --rm -v db_data:/data -v $(pwd):/backup busybox tar cvf /backup/backup.tar /data

- Docker со временем накапливает «висячие» (dangling) вольюмы — это те, что остались от удаленных контейнеров. Периодически запускай docker volume prune. Оно удалит только те тома, которые не подключены ни к одному контейнеру (включая остановленные).

- Разницы в скорости между Bind и Volume почти нет, оба работают напрямую через ядро. Но это зависит от операционной системы, если у тебя винда и 100500 абстракций, то будут тормоза.

Вот такие пироги, если есть чё добавить, жду тебя в комментариях.

🛠 #docker #linux #devops
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog