Всем привет, меня зовут Алексей, являюсь IT‑инженером в одной из крупных компаний. Иногда включаю внутреннего авантюриста и ищу что‑то редкое и очень интересное.И в данной статье хочу поделиться стеком, который имеет право на жизнь.
Сразу скажу тут не будет BestPractics ( я не так давно я взялся «Nix» и где‑то я отхожу от его «философии»).
Но эти примеры с небольшими изменениями будут работать и в других дистрибутивах.
Можно рассматривать эту статью как пример или же как не самый лучший( но все же) мануал, которого мне не хватало.
Да и надеюсь, что информация для кого‑то будет интересна, как и для меня.
Что сегодня будет:
Experimental stand:
Начнем с Дистрибутива.
О NixOS — дистрибутив Linux использует декларативную конфигурацию, контейнеризацию всех программ с хэшированием, и инкрементное сшивание их в состояния (поколения). Это гарантирует однозначность и предсказуемость состояния системы и обновлений в любой точке, и возможность возврата к любому предыдущему состоянию средствами ОС.
NixOS разрабатывается по DevOps методике и имеет инструменты, посвященные задачам развёртывания.
Модель декларативной конфигурации NixOS позволяет легко воспроизвести конфигурацию системы на другом компьютере. Копирование файла конфигурации на целевой компьютер и выполнение команды обновления системы генерирует ту же конфигурацию системы (ядро, приложения, системные службы и т. д.), за исключением тех частей системы, которые не управляются диспетчером пакетов, например пользовательскими данными.
Ставим ОС с помощью гуевого инсталлера с live образа (Можно было и без графического инсталлятора обойтись,но он здесь для наглядности).
Скриншот первого запуска
Пропустим стандартные шаги — ввод пользователя(не стал слишком далеко ходить — сделал юзера Васю,где‑то в конфигах проскочит Барсик и тд,так что не пугаемся).
Выбираем графическую подсистему
Остановимся на этом моменте: для серверных нужд,таких как файловое хранилище,веб‑сервер,хранилище бэкапов,телефония и тд — графическая подсистема‑не нужна,поэтому выбираем No Desktop.Если будем использовать для жизни,то ставим,то уже по настроению,желанию.
Использование несвободных компонентов(тут надо смотреть по железу и по желанию)
Работаем с разбивкой диска
Поле этого шага устанавливаем систему (от 5 минут до …получаса в зависимости от интернет соединения и скорости чтения/записи).
Установка системы
И потом перезапускаемся и видим :
Этап первый пройден.
теперь можно увидеть,что у нас доступно по командам.
Маленькая ,но полезная справка:
nixos-rebuild --rollback switch - не создавать новую конфигурацию, а использовать предыдущую конфигурацию . Полезно для быстрого возврата из-за ошибок.
nixos --upgrade обновить канал пользователя root перед созданием конфигурации
nixos-rebuild также может использоваться для создания и развертывания системных конфигураций на удаленных хостах через SSH.
Чтобы использовать удаленный хост для сборки вашей системы и ее развертывания на текущем хосте, используйте:
nixos-rebuild --build-host user@remotehost switch
Чтобы собрать систему локально и развернуть ее на удаленном хосте, используйте:
nixos-rebuild --target-host user@remotehost switch
Обратите внимание, что для этого часто потребуется использовать конфигурацию, отличную от той, что в /etc/nixos.
--build-host и --target-host может использоваться одновременно, даже с разными хостами.
Если вы перестраиваете удаленный хост от имени пользователя без полномочий root, используйте опцию --use-remote-sudoдля повышения прав на удаленном компьютере во время процесса восстановления:
nixos-rebuild --target-host user@remotehost --use-remote-sudo switch
По умолчанию nixos-rebuild создает конфигурацию в файле, указанном в nixos-config поле NIX_PATH переменной среды, значение которой установлено /etc/nixos/configuration.nix по умолчанию. Это можно перезаписать с помощью:
nixos-rebuild switch -I nixos-config=path/to/configuration.nix
И это только малая часть того,что можно сделать ,за болеегорячим интересным контентом - официальный сайт - https://nixos.org/
Правим hostname:
nano /etc/nixos/configuration.nix
networking.hostName = "nixos" меняем на networking.hostName = "nixserver"
Обновляем конфигурацию:
nixos-rebuild switch
Ставим нужные (нам пакеты):
nano /etc/nixos/configuration.nix
wget, caddy, minio, minio-cllient, restic, prometheus, postgresql
пример:
Записал в системные переменные, чтобы можно было работать от любого пользователя, а не только от одного (например рута) .( ДА Небезопасно ,но более удобно.)
Потом жмем на команду - nixos-rebuild switch и они доступны.
Через cli ( пример) : nix-env –install (-I ) vim
Так же в директиве network.firewall.allowedTCPPorts вписываем [22 9000 9001 80 443]
открытие портов
9001- WebUI Minio ( он нам нужен только для тестов,потом уберем порт отсюда)
Обновляем конфигурацию:
nixos-rebuild switch
крупномасштабных рабочих нагрузок AI/ML, хранения данных и баз данных.
Он работает локально и в любом облаке (публичном или частном), от центра обработки данных до периферии. MinIO является программно определяемым и имеет открытый исходный код под GNU AGPL v3. © official suite.
Настраиваем Minio:
Для удобства своего делаю файлик /etc/default/minio c таким содержимым:
nano /etc/default/minio
MINIO_VOLUMES=/var/cloud # Path to save data
MINIO_OPTS="--console-address :9001" #Port to Web-UI
MINIO_ROOT_USER=barsik # Superuser Minio
MINIO_ROOT_PASSWORD=barsikpassword # password sureruser
Сначала командой find / -name minio ищем как бинарники,так и демонов, если таковы имеются.
=(
Только при написании статьи обнаружил баг пакета Minio(сервер), когда ставишь его через пакетный мененджер , то возникает ошибка парсера JSON .... ,так что:
wget https://dl.min.io/server/minio/release/linux-amd64/minio
chmod +x minio
mv minio /var/cloud (например или оставляем его в той директории,куда скачали)
Раз демона нету, то впишем в конфиг его сами:
nano /etc/nixos/configuration.nix и прописываем:
systemd.services.minioserver = {
description = "MinioServer" ;
wantedBy = [ "default.target" ];
serviceConfig = {
EnvironmentFile= "/etc/default/minio";
# ExecStart = "${pkgs.minio}/bin/minio server $MINIO_OPTS $MINIO_VOLUMES ";
ExecStart = "/home/vasya/minio server $MINIO_OPTS $MINIO_VOLUMES ";# ExecStop = " ";
Type = "notify";
Restart = "always";
LimitNOFILE="1048576";
TimeoutStopSec="infinity";
SendSIGKILL="no";
User="vasya"; #"minio-user";
Group= "root"; #"minio-user";
ProtectProc="invisible";
};
};
systemd.services.minioserver.enable=true;
Ребилдимся:
nixos-rebuild switch
*Есть тут нюанс о который я наткнулся - локалхост тут не просто так,а для того чтобы caddy сделало временный серт для разработки.Если он стоит наружу,и с открытым портами 80/443 для http/https(естесственно) то прописываем вместо локалхост- свой домен и он сам подтянет у letsencrypt сертификат.Так же можно через директиву
tls cert key
прописать свой сертификат
Но мы пойдем более простым путем.
mkdir /etc/caddy
nano /etc/caddy/Caddyfile
localhost {
header /* {
-Server
Permissions-Policy interest-cohort=()
Strict-Transport-Security max-age=31536000;
X-Content-Type-Options nosniff
X-Frame-Options DENY
Referrer-Policy no-referrer-when-downgrade
}
route /console/* {
uri strip_prefix /console
reverse_proxy 127.0.0.1:9001
}
}
Прописываем сервис в system config
systemd.services.caddy = {
description = "Caddy" ;
wantedBy = [ "multi-user.target" ];
serviceConfig = {
EnvironmentFile= "/etc/caddy/Caddyfile";
ExecStart = "${pkgs.caddy}/bin/caddy run --environ --config /etc/caddy/Caddyfile";
ExecStop = " ${pkgs.caddy}/bin/caddy stop";
ExecReload = "${pkgs.caddy}/bin/caddy --config /etc/caddy/Caddyfile --force";
Type = "notify";
Restart = "always";
LimitNOFILE="1048576";
TimeoutStopSec="infinity";
SendSIGKILL="no";
User="root"; #caddy
Group="root"; #caddy
ProtectProc="invisible";
PrivateTmp="true";
AmbientCapabilities="CAP_NET_BIND_SERVICE";
};
};
systemd.services.caddy.enable=true;
Обновляем конфигурацию:
nixos-rebuild switch
Заходим и проверяем,что все работает.
Проверка работоспособности.
На гипервизоре пробрасываем порты для https( 443 ) и порт ssh .
проверяем,что все работает /localhost/console
Для теста сделал пару бакетов ,чтобы понять точно ,что все ок
Prometheus
It's FAIL
Ага,метрики недоступны,потому что Minio не может достучаться до прометеуса. Это Поправимо. Сейчас покажу пример как можно сделать это по старинке.
Поэтому будем изобретать «велосипед» заново.
Заходим на официальный сайт прометеуса и идем в раздел скачать и выбираем prometheus-2.46.0.linux-amd64 ,копируем его ссылку и скачиваем wget’ом прямо на сервер:
wget https://github.com/prometheus/prome.../v2.46.0/prometheus-2.46.0.linux-amd64.tar.gz
Разархивируем его:
tar -xvf prometheus-2.46.0.linux-amd64.tar.gz
переименовываем директорию переносом
mv prometheus-2.46.0.linux-amd64 prometheus
Запускать будем из этой же директории,так что лезем в configuration.nix и прописываем:
systemd.services.prometheus = {
description = "Prometheus" ;
wantedBy = [ "multi-user.target" ];
serviceConfig = {
# EnvironmentFile= "/etc/caddy/Caddyfile";
ExecStart = "/home/vasya/prometheus/prometheus --config.file=/home/vasya/prometheus/prometheus.yml ";
ExecStop = " ";
ExecReload = " ";
Type = "notify";
Restart = "always";
LimitNOFILE="1048576";
TimeoutStopSec="infinity";
SendSIGKILL="no";
User="root";
Group="root";
ProtectProc="invisible";
PrivateTmp="true";
AmbientCapabilities="CAP_NET_BIND_SERVICE";
};
};
systemd.services.prometheus.enable=true;
Делаем ребилд в реалтайме и смотрим на результат
nixos-rebuild switch
Результат
Ага,заработало.
На скриншоте вывод от команд
curl localhost:9090
curl localhost:9090/graph
Теперь делаем ключи для авторизиации для mc(minio-client’a).
И сгенерируем для прометеуса конфиг.
Заходим сюда на веб-интерфейс и выбираем Access keys и кликаем на create access key
Веб-интерфейс
И сгенерированные ключи пишем на клиента (сначала идет access key потом secret key):
mc alias set mys3 http://localhost:9000 ACCESSKEY SECRETKEY
или
mc alias set myminio http://localhost:9000 ACCESSKEY SECRETKEY --api "s3v4"
mys3 – алиас на наш сервер
http://localhost:9000 – адрес с портом API
Указываем что используется API : --api "s3v4"
Командой
mc admin prometheus generate mys3
( mc admin prometheus generate ALIAS )
нам сгенерировался конфиг,который копируем в Prometheus.yml :
nano prometheus.yml
и вставляем эту часть :
- job_name: minio-job
bearer_token: сгенерированный токен
metrics_path: /minio/v2/metrics/cluster
scheme: http
static_configs:
- targets: ['localhost:9000']
И теперь прописываем где работает прометеус В /etc/default/minio
MINIO_PROMETHEUS_URL=http://localhost:9090
И ребутаем minio
systemctl restart minioserver.service
Графики
Для работы с Эвентами minio нужна база данных или мененджер очередей.
Настроим Postgresql под это дело.
services.postgresql = {
enable = true;
ensureDatabases = [ "miniodb" ];
enableTCPIP = true;
authentication = pkgs.lib.mkOverride 10 ''
#type database DBuser auth-method
local all all trust
host all all 127.0.0.1/32 trust
# ipv6
host all all ::1/128 trust
'';
};
Наше традиционное:
nixos-rebuild switch
Проверяем что он жив и логинимся под postgres :
su postgres
и создаем пользователя,его пароль и бд
CREATE ROLE minio WITH LOGIN PASSWORD 'minio' CREATEDB;
CREATE DATABASE minio;
GRANT ALL PRIVILEGES ON DATABASE minio TO minio;
Настройка Events
Спустя какое-то время в бакете можно будет настроить подписку на эвенты
Restic
Чем он понравился :
Делаем отдельные ключи или же используем те, что делали до этого.
Делаем текстовый файл с паролем:
echo "barsik " > password
Прописываем в терминале
export AWS_ACCESS_KEY_ID= ACCESS KEY
export AWS_SECRET_ACCESS_KEY= SECRET KEY
Запускаем restic для иницализации репозитория:
restic -r s3:http://localhost:9000/1111 init
-r –репозиторий
s3 –протокол
http://localhost:9000/ -сервер
1111 –бакет
Init –инициализация
После ввода пароля – репозитори будет создан
Сейчас пропишем подготовим другой диск,куда minio будет хранить данные и подправим его конфиг.
lsblk
Форматируем его
mkfs.ext4 /dev/sdb
Примонтируем его
mkdir /mnt (изначально этоq директории нет в NIXOS)
mount /dev/sdb /mnt
Для автомонтирования редактирование /etc/fstab –не поможет, так как оно только для чтения, и мы пойдем другим путем.
Смотрим UUID дисков
ls /dev/disk/by-uuid/
Копируем их и идем в /etc/nixos/hardware-configuration.nix
ls /dev/disk/by-uuid
И делаем отдельный блок,где будет наш UUID и точка монтирования
Сохраняем файл и ребилдимся.
Останавливаем нашу хранилище systemctl stop minioserver.service
Переносим папку mv /var/cloud/ /mnt/
Правим путь в переменных /etc/default/minio –
MINIO_VOLUMES=/mnt/cloud
Вместо:
MINIO_VOLUMES=/var/cloud
И запускаем хранилище - systemctl start minioserver.service
И теперь можно проверить работу.
restic -r s3:http://localhost:9000/1111 backup / -p password --exclude=/mnt --exclude=/proc --exclude=/sys/
протокол:сервер:бакет( куда он будет бекапится)
/ - раздел,который бекапим
--exclude=/.... –исключаем папку, в которой он будет это сохранять,так же полезным будет исключить блочные устройства.
Первый прогон
Второй прогон
Теперь почистим nix-store cache и посмотрим на результат.
nix-collect-garbage
Результат чистки:
note: currently hard linking saves -0.00 MiB
1850 store paths deleted, 375.93 MiB freed
restic -r s3:http://localhost:9000/1111 backup / -p password --exclude=/mnt --exclude=/proc --exclude=/sys/
repository 9d310fc7 opened (version 2, compression level auto)
using parent snapshot dbeefb91
Files: 10 new, 13 changed, 168367 unmodified
Dirs: 5 new, 42 changed, 76552 unmodified
Added to the repository: 59.025 MiB (11.062 MiB stored)
processed 168390 files, 4.037 GiB in 2:35
snapshot 50b958c1 saved
Отлично,теперь можно проверить разницу между снапшотами:
restic -r s3:http://localhost:9000/1111 diff 4463d77a 50b958c1 -p password
(пропущу тут лог с именами файлов)
Files: 120 new, 8012 removed, 8 changed
Dirs: 14 new, 878 removed
Others: 0 new, 1122 removed
Data Blobs: 226 new, 5912 removed
Tree Blobs: 60 new, 921 removed
Added: 71.350 MiB
Removed: 347.188 MiB
Удаляем файл
rm prometheus-2.46.0.linux-amd64.tar.gz
и смотрим что осталось:
ls
minio password prometheus
После
restic -r s3:http://localhost:9000/1111 -p password restore latest --target /
смотрим в лог
ignoring error for /....: read-only file system
There were 533335 errors
Вспоминаем что мы находимся в NixOS и то что большая часть директорий
в режиме только чтения,так что Смотрим на файл который мы восстановили:
ll
total 189280
-rwxr-xr-x 1 root root 98934784 авг 24 02:00 minio
-rw-r--r-- 1 root root 8 авг 24 14:56 password
drwxr-xr-x 6 1001 123 4096 авг 24 12:30 prometheus
-rw-r--r-- 1 root root 94876162 июл 25 16:16 prometheus-2.46.0.linux-amd64.tar.gz
Сделаем снапшот диска с которого мы работаем,но для начала нужно будет переребилдить конфиг(убрать или закомментить диск с точкой монтирования /mnt ), чтобы не было возможных проблем с загрузкой со снапшота.С этого снапшота будем восстанавливаться на другую виртуалку.
hardware-configuration.nix
отправляемся в конфиг хардваре:
nano /etc/nixos/hardware-configuration.nix
правим и потом и ребилдимся
И у нас отвалился диск!
Чиним временно
mount /dev/sdb /mnt/
и
systemctl restart minioserver.service
Иначе куда бы бекапы отправились..
Снимем дамп нашего диска.
dd if=/dev/sda | restic -r s3:http://localhost:9000/iii -p password backup --stdin --stdin-filename sda1
и смотрим результат:
repository 4ea9802a opened (version 2, compression level auto)
created new cache in /root/.cache/restic
67108864+0 records in9 GiB, total 1 files 0 B, 0 errors
67108864+0 records out
34359738368 bytes (34 GB, 32 GiB) copied, 759,113 s, 45,3 MB/s
Files: 1 new, 0 changed, 0 unmodified
Dirs: 0 new, 0 changed, 0 unmodified
Added to the repository: 10.014 GiB (2.742 GiB stored)
processed 1 files, 32.000 GiB in 12:37
snapshot ae4bdfcf saved
Делаем вторую виртуалку (в моем случае в VirtualBox):
Загружаемся с nixos_minimal livecd)
смотрим ее IP
Командой
passwd
меняем ей пароль и входим по SSH на live образ.
Смотрим что примонтированно:
df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 197M 0 197M 0% /dev
tmpfs 2.0G 0 2.0G 0% /dev/shm
tmpfs 983M 2.6M 980M 1% /run
tmpfs 2.0G 384K 2.0G 1% /run/wrappers
tmpfs 2.0G 25M 1.9G 2% /
/dev/root 833M 833M 0 100% /iso
/dev/loop0 800M 800M 0 100% /nix/.ro-store
tmpfs 2.0G 8.0K 2.0G 1% /nix/.rw-store
overlay 2.0G 8.0K 2.0G 1% /nix/store
tmpfs 393M 0 393M 0% /run/user/1000
Ставим restic
nix-env --install restic
Получаем такой результат:
installing 'restic-0.15.2'
these 2 paths will be fetched (21.58 MiB download, 90.60 MiB unpacked):
/nix/store/91hfy0g7a9qq38qa05bann19sy152s9x-rclone-1.62.2
/nix/store/rf3qps2gxqy3n22nlh8fybm09qgyy0dc-restic-0.15.2
copying path '/nix/store/91hfy0g7a9qq38qa05bann19sy152s9x-rclone-1.62.2' from 'https://cache.nixos.org'...
copying path '/nix/store/rf3qps2gxqy3n22nlh8fybm09qgyy0dc-restic-0.15.2' from 'https://cache.nixos.org'...
building '/nix/store/ijbbja3frzd7ab6l3awsd7k3k9rkwz2r-user-environment.drv'...
Копируем на нашу лайф виртуалку ключи:
export AWS_ACCESS_KEY_ID=ACCESS_KEY
export AWS_SECRET_ACCESS_KEY=SECRET_KEY
сразу делаем файл password
echo "barsik" > password
И пишем наш образ командой:
restic -r s3:http://192.168.4.4:9000/iii -p password dump latest sda > /dev/sda
И пока он раскатывается дамп, остается поправить конфиг на сервере:
nano /etc/nixos/hardware-configuration.nix
ребилдимся и все будет работать.
Раскомментируем наш второй диск
Тем временем дамп залился на наш диск:
# ll /dev/sda
sda sda1
Теперь перезапускаемся и у нас есть копия нашей виртуалки.
Original VM с IP внутренней сети 192.168.4.4/24
[root@nixserver:/home/vasya]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 100M 0 100M 0% /dev
tmpfs 992M 28K 992M 1% /dev/shm
tmpfs 496M 2,6M 494M 1% /run
tmpfs 992M 432K 992M 1% /run/wrappers
/dev/sda1 32G 5,2G 25G 18% /
tmpfs 199M 0 199M 0% /run/user/1000
/dev/sdb 30G 12G 17G 40% /mnt
Copy VM (inet 192.168.4.6/24)
[sudo] password for vasya:
[root@nixserver:/home/vasya]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 197M 0 197M 0% /dev
tmpfs 2,0G 28K 2,0G 1% /dev/shm
tmpfs 983M 2,5M 980M 1% /run
tmpfs 2,0G 432K 2,0G 1% /run/wrappers
/dev/sda1 32G 5,3G 25G 18% /
tmpfs 393M 0 393M 0% /run/user/1000
Теперь пишем systemd service ,чтобы по таймеру делал бэкап:
nano /etc/nixos/configuration.nix
systemd.services.s3backup= {
serviceConfig.Type = "oneshot";
path = with pkgs; [ bash ];
script = ''
export AWS_ACCESS_KEY_ID=VnwVEv0iLtpUWaiHRvXL
export AWS_SECRET_ACCESS_KEY=dQjjJyvNjGUfyQIn2PHJbvkEaWqI5JKffEE3i0J6
${pkgs.restic}/bin/restic -r s3:http://192.168.4.4:9000/1111 backup /home/vasya -p /home/vasya/password
'';
};
systemd.timers.s3backup = {
wantedBy = [ "timers.target" ];
partOf = [ "s3backup.service" ];
timerConfig = {
OnCalendar = "OnCalendar=*:0/15"; #every 15 minutes
Unit = "s3backup.service";
};
};
systemd.services.s3backup.enable=true;
Ребилдимся и запускаем:
systemctl start s3backup.timer && systemctl start s3backup.service
на сервере проверяем:
restic -r s3:http://localhost:9000/1111 snapshots -p password
repository 9d310fc7 opened (version 2, compression level auto)
ID Time Host Tags Paths
------------------------------------------------------------------
4463d77a 2023-08-24 17:55:16 nixserver /
f9e5538f 2023-08-24 18:09:58 nixserver /
7782b8ec 2023-08-25 09:02:05 nixserver /
dbeefb91 2023-08-25 09:06:00 nixserver /
50b958c1 2023-08-25 09:18:49 nixserver /
4b03d494 2023-08-25 16:47:13 nixserver /home/vasya
------------------------------------------------------------------
6 snapshots
И на этом пожалуй все.
Сейчас прорабатываю вопрос о чем еще можно написать,например о встроенных генераторах,написании бота,чтобы отписывал когда бэкап залился, контейнерах, деплое, как вариант, но уже в рамках 2й части.
habr.com
Сразу скажу тут не будет BestPractics ( я не так давно я взялся «Nix» и где‑то я отхожу от его «философии»).
Но эти примеры с небольшими изменениями будут работать и в других дистрибутивах.
Можно рассматривать эту статью как пример или же как не самый лучший( но все же) мануал, которого мне не хватало.
Да и надеюсь, что информация для кого‑то будет интересна, как и для меня.
Что сегодня будет:
- Краткий обзор с установкой ПО для интересного, редкого, но весьма достойного дистрибутива.
- Настройка нестандартного веб‑сервера(на моей памяти — в основном везде Apache/Nginx,и в последнее время traefik появляется, как прокси ).
- Развернем свое хранилище,по которому можно будет как по s3,так и по sftp подключится.
- Готовка бэкапов + пару лайфхаков.
Experimental stand:
- NixOS
- Caddy
- Minio
- Prometheus
- restic
Начнем с Дистрибутива.
О NixOS — дистрибутив Linux использует декларативную конфигурацию, контейнеризацию всех программ с хэшированием, и инкрементное сшивание их в состояния (поколения). Это гарантирует однозначность и предсказуемость состояния системы и обновлений в любой точке, и возможность возврата к любому предыдущему состоянию средствами ОС.
NixOS разрабатывается по DevOps методике и имеет инструменты, посвященные задачам развёртывания.
Модель декларативной конфигурации NixOS позволяет легко воспроизвести конфигурацию системы на другом компьютере. Копирование файла конфигурации на целевой компьютер и выполнение команды обновления системы генерирует ту же конфигурацию системы (ядро, приложения, системные службы и т. д.), за исключением тех частей системы, которые не управляются диспетчером пакетов, например пользовательскими данными.
И так начинаем.
Ставим ОС с помощью гуевого инсталлера с live образа (Можно было и без графического инсталлятора обойтись,но он здесь для наглядности).
Скриншот первого запуска
Пропустим стандартные шаги — ввод пользователя(не стал слишком далеко ходить — сделал юзера Васю,где‑то в конфигах проскочит Барсик и тд,так что не пугаемся).
Выбираем графическую подсистему
Остановимся на этом моменте: для серверных нужд,таких как файловое хранилище,веб‑сервер,хранилище бэкапов,телефония и тд — графическая подсистема‑не нужна,поэтому выбираем No Desktop.Если будем использовать для жизни,то ставим,то уже по настроению,желанию.
Использование несвободных компонентов(тут надо смотреть по железу и по желанию)
Поле этого шага устанавливаем систему (от 5 минут до …получаса в зависимости от интернет соединения и скорости чтения/записи).
Установка системы
Этап первый пройден.
теперь можно увидеть,что у нас доступно по командам.
Маленькая ,но полезная справка:
nixos-rebuild --rollback switch - не создавать новую конфигурацию, а использовать предыдущую конфигурацию . Полезно для быстрого возврата из-за ошибок.
nixos --upgrade обновить канал пользователя root перед созданием конфигурации
nixos-rebuild также может использоваться для создания и развертывания системных конфигураций на удаленных хостах через SSH.
Чтобы использовать удаленный хост для сборки вашей системы и ее развертывания на текущем хосте, используйте:
nixos-rebuild --build-host user@remotehost switch
Чтобы собрать систему локально и развернуть ее на удаленном хосте, используйте:
nixos-rebuild --target-host user@remotehost switch
Обратите внимание, что для этого часто потребуется использовать конфигурацию, отличную от той, что в /etc/nixos.
--build-host и --target-host может использоваться одновременно, даже с разными хостами.
Если вы перестраиваете удаленный хост от имени пользователя без полномочий root, используйте опцию --use-remote-sudoдля повышения прав на удаленном компьютере во время процесса восстановления:
nixos-rebuild --target-host user@remotehost --use-remote-sudo switch
По умолчанию nixos-rebuild создает конфигурацию в файле, указанном в nixos-config поле NIX_PATH переменной среды, значение которой установлено /etc/nixos/configuration.nix по умолчанию. Это можно перезаписать с помощью:
nixos-rebuild switch -I nixos-config=path/to/configuration.nix
И это только малая часть того,что можно сделать ,за более
Правим hostname:
nano /etc/nixos/configuration.nix
networking.hostName = "nixos" меняем на networking.hostName = "nixserver"
Обновляем конфигурацию:
nixos-rebuild switch
Ставим нужные (нам пакеты):
nano /etc/nixos/configuration.nix
wget, caddy, minio, minio-cllient, restic, prometheus, postgresql
пример:
Записал в системные переменные, чтобы можно было работать от любого пользователя, а не только от одного (например рута) .( ДА Небезопасно ,но более удобно.)
Потом жмем на команду - nixos-rebuild switch и они доступны.
Через cli ( пример) : nix-env –install (-I ) vim
Так же в директиве network.firewall.allowedTCPPorts вписываем [22 9000 9001 80 443]
открытие портов
9001- WebUI Minio ( он нам нужен только для тестов,потом уберем порт отсюда)
Обновляем конфигурацию:
nixos-rebuild switch
MinIO Object Store
Это высокопроизводительное хранилище объектов, совместимое с S3. Он создан длякрупномасштабных рабочих нагрузок AI/ML, хранения данных и баз данных.
Он работает локально и в любом облаке (публичном или частном), от центра обработки данных до периферии. MinIO является программно определяемым и имеет открытый исходный код под GNU AGPL v3. © official suite.
Настраиваем Minio:
Для удобства своего делаю файлик /etc/default/minio c таким содержимым:
nano /etc/default/minio
MINIO_VOLUMES=/var/cloud # Path to save data
MINIO_OPTS="--console-address :9001" #Port to Web-UI
MINIO_ROOT_USER=barsik # Superuser Minio
MINIO_ROOT_PASSWORD=barsikpassword # password sureruser
Сначала командой find / -name minio ищем как бинарники,так и демонов, если таковы имеются.
=(
Только при написании статьи обнаружил баг пакета Minio(сервер), когда ставишь его через пакетный мененджер , то возникает ошибка парсера JSON .... ,так что:
wget https://dl.min.io/server/minio/release/linux-amd64/minio
chmod +x minio
mv minio /var/cloud (например или оставляем его в той директории,куда скачали)
Раз демона нету, то впишем в конфиг его сами:
nano /etc/nixos/configuration.nix и прописываем:
systemd.services.minioserver = {
description = "MinioServer" ;
wantedBy = [ "default.target" ];
serviceConfig = {
EnvironmentFile= "/etc/default/minio";
# ExecStart = "${pkgs.minio}/bin/minio server $MINIO_OPTS $MINIO_VOLUMES ";
ExecStart = "/home/vasya/minio server $MINIO_OPTS $MINIO_VOLUMES ";# ExecStop = " ";
Type = "notify";
Restart = "always";
LimitNOFILE="1048576";
TimeoutStopSec="infinity";
SendSIGKILL="no";
User="vasya"; #"minio-user";
Group= "root"; #"minio-user";
ProtectProc="invisible";
};
};
systemd.services.minioserver.enable=true;
Ребилдимся:
nixos-rebuild switch
Caddy
Это мощный корпоративный веб-сервер с открытым исходным кодом и автоматическим HTTPS, написанный на Go (c)official suite.*Есть тут нюанс о который я наткнулся - локалхост тут не просто так,а для того чтобы caddy сделало временный серт для разработки.Если он стоит наружу,и с открытым портами 80/443 для http/https(естесственно) то прописываем вместо локалхост- свой домен и он сам подтянет у letsencrypt сертификат.Так же можно через директиву
tls cert key
прописать свой сертификат
Но мы пойдем более простым путем.
mkdir /etc/caddy
nano /etc/caddy/Caddyfile
localhost {
header /* {
-Server
Permissions-Policy interest-cohort=()
Strict-Transport-Security max-age=31536000;
X-Content-Type-Options nosniff
X-Frame-Options DENY
Referrer-Policy no-referrer-when-downgrade
}
route /console/* {
uri strip_prefix /console
reverse_proxy 127.0.0.1:9001
}
}
Прописываем сервис в system config
systemd.services.caddy = {
description = "Caddy" ;
wantedBy = [ "multi-user.target" ];
serviceConfig = {
EnvironmentFile= "/etc/caddy/Caddyfile";
ExecStart = "${pkgs.caddy}/bin/caddy run --environ --config /etc/caddy/Caddyfile";
ExecStop = " ${pkgs.caddy}/bin/caddy stop";
ExecReload = "${pkgs.caddy}/bin/caddy --config /etc/caddy/Caddyfile --force";
Type = "notify";
Restart = "always";
LimitNOFILE="1048576";
TimeoutStopSec="infinity";
SendSIGKILL="no";
User="root"; #caddy
Group="root"; #caddy
ProtectProc="invisible";
PrivateTmp="true";
AmbientCapabilities="CAP_NET_BIND_SERVICE";
};
};
systemd.services.caddy.enable=true;
Обновляем конфигурацию:
nixos-rebuild switch
Заходим и проверяем,что все работает.
Проверка работоспособности.
На гипервизоре пробрасываем порты для https( 443 ) и порт ssh .
проверяем,что все работает /localhost/console
Для теста сделал пару бакетов ,чтобы понять точно ,что все ок
Prometheus
It's FAIL
Ага,метрики недоступны,потому что Minio не может достучаться до прометеуса. Это Поправимо. Сейчас покажу пример как можно сделать это по старинке.
Поэтому будем изобретать «велосипед» заново.
Заходим на официальный сайт прометеуса и идем в раздел скачать и выбираем prometheus-2.46.0.linux-amd64 ,копируем его ссылку и скачиваем wget’ом прямо на сервер:
wget https://github.com/prometheus/prome.../v2.46.0/prometheus-2.46.0.linux-amd64.tar.gz
Разархивируем его:
tar -xvf prometheus-2.46.0.linux-amd64.tar.gz
переименовываем директорию переносом
mv prometheus-2.46.0.linux-amd64 prometheus
Запускать будем из этой же директории,так что лезем в configuration.nix и прописываем:
systemd.services.prometheus = {
description = "Prometheus" ;
wantedBy = [ "multi-user.target" ];
serviceConfig = {
# EnvironmentFile= "/etc/caddy/Caddyfile";
ExecStart = "/home/vasya/prometheus/prometheus --config.file=/home/vasya/prometheus/prometheus.yml ";
ExecStop = " ";
ExecReload = " ";
Type = "notify";
Restart = "always";
LimitNOFILE="1048576";
TimeoutStopSec="infinity";
SendSIGKILL="no";
User="root";
Group="root";
ProtectProc="invisible";
PrivateTmp="true";
AmbientCapabilities="CAP_NET_BIND_SERVICE";
};
};
systemd.services.prometheus.enable=true;
Делаем ребилд в реалтайме и смотрим на результат
nixos-rebuild switch
Результат
Ага,заработало.
На скриншоте вывод от команд
curl localhost:9090
curl localhost:9090/graph
Теперь делаем ключи для авторизиации для mc(minio-client’a).
И сгенерируем для прометеуса конфиг.
Заходим сюда на веб-интерфейс и выбираем Access keys и кликаем на create access key
Веб-интерфейс
И сгенерированные ключи пишем на клиента (сначала идет access key потом secret key):
mc alias set mys3 http://localhost:9000 ACCESSKEY SECRETKEY
или
mc alias set myminio http://localhost:9000 ACCESSKEY SECRETKEY --api "s3v4"
mys3 – алиас на наш сервер
http://localhost:9000 – адрес с портом API
Указываем что используется API : --api "s3v4"
Командой
mc admin prometheus generate mys3
( mc admin prometheus generate ALIAS )
нам сгенерировался конфиг,который копируем в Prometheus.yml :
nano prometheus.yml
и вставляем эту часть :
- job_name: minio-job
bearer_token: сгенерированный токен
metrics_path: /minio/v2/metrics/cluster
scheme: http
static_configs:
- targets: ['localhost:9000']
И теперь прописываем где работает прометеус В /etc/default/minio
MINIO_PROMETHEUS_URL=http://localhost:9090
И ребутаем minio
systemctl restart minioserver.service
Графики
Для работы с Эвентами minio нужна база данных или мененджер очередей.
Настроим Postgresql под это дело.
services.postgresql = {
enable = true;
ensureDatabases = [ "miniodb" ];
enableTCPIP = true;
authentication = pkgs.lib.mkOverride 10 ''
#type database DBuser auth-method
local all all trust
host all all 127.0.0.1/32 trust
# ipv6
host all all ::1/128 trust
'';
};
Наше традиционное:
nixos-rebuild switch
Проверяем что он жив и логинимся под postgres :
su postgres
и создаем пользователя,его пароль и бд
CREATE ROLE minio WITH LOGIN PASSWORD 'minio' CREATEDB;
CREATE DATABASE minio;
GRANT ALL PRIVILEGES ON DATABASE minio TO minio;
Настройка Events
Спустя какое-то время в бакете можно будет настроить подписку на эвенты
Restic
- Настраивается restic ко многим различным типам хранилищ, включая локальные и онлайн‑сервисы.
- Легко, поскольку представляет собой один исполняемый файл, который можно запускать без сервера или сложной настройки.
- Эффективно, передавая только те части, которые действительно были изменены в файлах, для которых вы создаете резервную копию.
- Безопасно, благодаря тщательному использованию криптографии на каждой стадии процесса.
- Проверяемо, что позволяет вам быть уверенным, что ваши файлы могут быть восстановлены при необходимости.
- Свободно — Restic полностью бесплатен для использования и имеет полностью открытый исходный код.
Чем он понравился :
- сжимает данные;
- можно подключится к хранилищу через local/sftp/ftp/s3/http;
- при повторном прогоне копировал/восстанавливал только изменившиеся данные;
- «моментальная» передача сжатых данных на сервер;
- можно отключить кэширование (возможно понадобится).
- нужно помнить куда положил файл с паролем.
Делаем отдельные ключи или же используем те, что делали до этого.
Делаем текстовый файл с паролем:
echo "barsik " > password
Прописываем в терминале
export AWS_ACCESS_KEY_ID= ACCESS KEY
export AWS_SECRET_ACCESS_KEY= SECRET KEY
Запускаем restic для иницализации репозитория:
restic -r s3:http://localhost:9000/1111 init
-r –репозиторий
s3 –протокол
http://localhost:9000/ -сервер
1111 –бакет
Init –инициализация
После ввода пароля – репозитори будет создан
Сейчас пропишем подготовим другой диск,куда minio будет хранить данные и подправим его конфиг.
lsblk
Форматируем его
mkfs.ext4 /dev/sdb
Примонтируем его
mkdir /mnt (изначально этоq директории нет в NIXOS)
mount /dev/sdb /mnt
Для автомонтирования редактирование /etc/fstab –не поможет, так как оно только для чтения, и мы пойдем другим путем.
Смотрим UUID дисков
ls /dev/disk/by-uuid/
Копируем их и идем в /etc/nixos/hardware-configuration.nix
ls /dev/disk/by-uuid
И делаем отдельный блок,где будет наш UUID и точка монтирования
Сохраняем файл и ребилдимся.
Останавливаем нашу хранилище systemctl stop minioserver.service
Переносим папку mv /var/cloud/ /mnt/
Правим путь в переменных /etc/default/minio –
MINIO_VOLUMES=/mnt/cloud
Вместо:
MINIO_VOLUMES=/var/cloud
И запускаем хранилище - systemctl start minioserver.service
И теперь можно проверить работу.
restic -r s3:http://localhost:9000/1111 backup / -p password --exclude=/mnt --exclude=/proc --exclude=/sys/
протокол:сервер:бакет( куда он будет бекапится)
/ - раздел,который бекапим
--exclude=/.... –исключаем папку, в которой он будет это сохранять,так же полезным будет исключить блочные устройства.
Первый прогон
Второй прогон
Теперь почистим nix-store cache и посмотрим на результат.
nix-collect-garbage
Результат чистки:
note: currently hard linking saves -0.00 MiB
1850 store paths deleted, 375.93 MiB freed
restic -r s3:http://localhost:9000/1111 backup / -p password --exclude=/mnt --exclude=/proc --exclude=/sys/
repository 9d310fc7 opened (version 2, compression level auto)
using parent snapshot dbeefb91
Files: 10 new, 13 changed, 168367 unmodified
Dirs: 5 new, 42 changed, 76552 unmodified
Added to the repository: 59.025 MiB (11.062 MiB stored)
processed 168390 files, 4.037 GiB in 2:35
snapshot 50b958c1 saved
Отлично,теперь можно проверить разницу между снапшотами:
restic -r s3:http://localhost:9000/1111 diff 4463d77a 50b958c1 -p password
(пропущу тут лог с именами файлов)
Files: 120 new, 8012 removed, 8 changed
Dirs: 14 new, 878 removed
Others: 0 new, 1122 removed
Data Blobs: 226 new, 5912 removed
Tree Blobs: 60 new, 921 removed
Added: 71.350 MiB
Removed: 347.188 MiB
Удаляем файл
rm prometheus-2.46.0.linux-amd64.tar.gz
и смотрим что осталось:
ls
minio password prometheus
После
restic -r s3:http://localhost:9000/1111 -p password restore latest --target /
смотрим в лог
ignoring error for /....: read-only file system
There were 533335 errors
Вспоминаем что мы находимся в NixOS и то что большая часть директорий
в режиме только чтения,так что Смотрим на файл который мы восстановили:
ll
total 189280
-rwxr-xr-x 1 root root 98934784 авг 24 02:00 minio
-rw-r--r-- 1 root root 8 авг 24 14:56 password
drwxr-xr-x 6 1001 123 4096 авг 24 12:30 prometheus
-rw-r--r-- 1 root root 94876162 июл 25 16:16 prometheus-2.46.0.linux-amd64.tar.gz
Сделаем снапшот диска с которого мы работаем,но для начала нужно будет переребилдить конфиг(убрать или закомментить диск с точкой монтирования /mnt ), чтобы не было возможных проблем с загрузкой со снапшота.С этого снапшота будем восстанавливаться на другую виртуалку.
hardware-configuration.nix
отправляемся в конфиг хардваре:
nano /etc/nixos/hardware-configuration.nix
правим и потом и ребилдимся
И у нас отвалился диск!
mount /dev/sdb /mnt/
и
systemctl restart minioserver.service
Иначе куда бы бекапы отправились..
Снимем дамп нашего диска.
dd if=/dev/sda | restic -r s3:http://localhost:9000/iii -p password backup --stdin --stdin-filename sda1
и смотрим результат:
repository 4ea9802a opened (version 2, compression level auto)
created new cache in /root/.cache/restic
67108864+0 records in9 GiB, total 1 files 0 B, 0 errors
67108864+0 records out
34359738368 bytes (34 GB, 32 GiB) copied, 759,113 s, 45,3 MB/s
Files: 1 new, 0 changed, 0 unmodified
Dirs: 0 new, 0 changed, 0 unmodified
Added to the repository: 10.014 GiB (2.742 GiB stored)
processed 1 files, 32.000 GiB in 12:37
snapshot ae4bdfcf saved
Делаем вторую виртуалку (в моем случае в VirtualBox):
Загружаемся с nixos_minimal livecd)
смотрим ее IP
Командой
passwd
меняем ей пароль и входим по SSH на live образ.
Смотрим что примонтированно:
df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 197M 0 197M 0% /dev
tmpfs 2.0G 0 2.0G 0% /dev/shm
tmpfs 983M 2.6M 980M 1% /run
tmpfs 2.0G 384K 2.0G 1% /run/wrappers
tmpfs 2.0G 25M 1.9G 2% /
/dev/root 833M 833M 0 100% /iso
/dev/loop0 800M 800M 0 100% /nix/.ro-store
tmpfs 2.0G 8.0K 2.0G 1% /nix/.rw-store
overlay 2.0G 8.0K 2.0G 1% /nix/store
tmpfs 393M 0 393M 0% /run/user/1000
Ставим restic
nix-env --install restic
Получаем такой результат:
installing 'restic-0.15.2'
these 2 paths will be fetched (21.58 MiB download, 90.60 MiB unpacked):
/nix/store/91hfy0g7a9qq38qa05bann19sy152s9x-rclone-1.62.2
/nix/store/rf3qps2gxqy3n22nlh8fybm09qgyy0dc-restic-0.15.2
copying path '/nix/store/91hfy0g7a9qq38qa05bann19sy152s9x-rclone-1.62.2' from 'https://cache.nixos.org'...
copying path '/nix/store/rf3qps2gxqy3n22nlh8fybm09qgyy0dc-restic-0.15.2' from 'https://cache.nixos.org'...
building '/nix/store/ijbbja3frzd7ab6l3awsd7k3k9rkwz2r-user-environment.drv'...
Копируем на нашу лайф виртуалку ключи:
export AWS_ACCESS_KEY_ID=ACCESS_KEY
export AWS_SECRET_ACCESS_KEY=SECRET_KEY
сразу делаем файл password
echo "barsik" > password
И пишем наш образ командой:
restic -r s3:http://192.168.4.4:9000/iii -p password dump latest sda > /dev/sda
И пока он раскатывается дамп, остается поправить конфиг на сервере:
nano /etc/nixos/hardware-configuration.nix
ребилдимся и все будет работать.
Раскомментируем наш второй диск
Тем временем дамп залился на наш диск:
# ll /dev/sda
sda sda1
Теперь перезапускаемся и у нас есть копия нашей виртуалки.
Original VM с IP внутренней сети 192.168.4.4/24
[root@nixserver:/home/vasya]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 100M 0 100M 0% /dev
tmpfs 992M 28K 992M 1% /dev/shm
tmpfs 496M 2,6M 494M 1% /run
tmpfs 992M 432K 992M 1% /run/wrappers
/dev/sda1 32G 5,2G 25G 18% /
tmpfs 199M 0 199M 0% /run/user/1000
/dev/sdb 30G 12G 17G 40% /mnt
Copy VM (inet 192.168.4.6/24)
[sudo] password for vasya:
[root@nixserver:/home/vasya]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 197M 0 197M 0% /dev
tmpfs 2,0G 28K 2,0G 1% /dev/shm
tmpfs 983M 2,5M 980M 1% /run
tmpfs 2,0G 432K 2,0G 1% /run/wrappers
/dev/sda1 32G 5,3G 25G 18% /
tmpfs 393M 0 393M 0% /run/user/1000
Теперь пишем systemd service ,чтобы по таймеру делал бэкап:
nano /etc/nixos/configuration.nix
systemd.services.s3backup= {
serviceConfig.Type = "oneshot";
path = with pkgs; [ bash ];
script = ''
export AWS_ACCESS_KEY_ID=VnwVEv0iLtpUWaiHRvXL
export AWS_SECRET_ACCESS_KEY=dQjjJyvNjGUfyQIn2PHJbvkEaWqI5JKffEE3i0J6
${pkgs.restic}/bin/restic -r s3:http://192.168.4.4:9000/1111 backup /home/vasya -p /home/vasya/password
'';
};
systemd.timers.s3backup = {
wantedBy = [ "timers.target" ];
partOf = [ "s3backup.service" ];
timerConfig = {
OnCalendar = "OnCalendar=*:0/15"; #every 15 minutes
Unit = "s3backup.service";
};
};
systemd.services.s3backup.enable=true;
Ребилдимся и запускаем:
systemctl start s3backup.timer && systemctl start s3backup.service
на сервере проверяем:
restic -r s3:http://localhost:9000/1111 snapshots -p password
repository 9d310fc7 opened (version 2, compression level auto)
ID Time Host Tags Paths
------------------------------------------------------------------
4463d77a 2023-08-24 17:55:16 nixserver /
f9e5538f 2023-08-24 18:09:58 nixserver /
7782b8ec 2023-08-25 09:02:05 nixserver /
dbeefb91 2023-08-25 09:06:00 nixserver /
50b958c1 2023-08-25 09:18:49 nixserver /
4b03d494 2023-08-25 16:47:13 nixserver /home/vasya
------------------------------------------------------------------
6 snapshots
И на этом пожалуй все.
Сейчас прорабатываю вопрос о чем еще можно написать,например о встроенных генераторах,написании бота,чтобы отписывал когда бэкап залился, контейнерах, деплое, как вариант, но уже в рамках 2й части.
1.0.BackupStorage на NixOS
Всем привет, меня зовут Алексей, являюсь IT‑инженером в одной из крупных компаний. Иногда включаю внутреннего авантюриста и ищу что‑то редкое и очень интересное.И в данной статье хочу...
habr.com