Присоединяйтесь к нашему каналу в телеграм: t.me/r4ven_me, уведомления о новых постах приходят туда в день публикации. А если у вас есть вопросы или просто желание пообщаться по тематике – заглядывайте в чат: t.me/r4ven_me_chat.

Приветствую!

Короткая заметка про то, как проверить скорость Download/Upload с помощью SSH в Linux. Подобная диагностика бывает полезна при анализе проблем, связанных с передачей данных по защищенным каналам связи, таким как VPN.

Присоединяйтесь к нашему каналу в телеграм: t.me/r4ven_me, уведомления о новых постах приходят туда в день публикации. А если у вас есть вопросы или просто желание пообщаться по тематике – заглядывайте в чат: t.me/r4ven_me_chat.

Демонстрация из статьи выполнялась в среде дистрибутива Linux Mint Debian Edition 6 (Debian 12). Все аналогичным образом будет работать и в других дистрибутивах Linux.

Подготовка

Для работы нам понадобятся:

• доступ к удаленному серверу по SSH;
• утилита контроля пайплайнов – pv (pipeviewer);
• утилита низкоуровневой передачи данных – dd;
• утилита вывода содержимого – cat.

Из списка выше доустановить потребуется лишь утилиту pv (крайне полезная вещь). Она есть в стандартных репозиториях:

sudo apt update && sudo apt install pv

Проверка скорости

Сразу стоит отметить, что скорость передачи данных может зависеть от:пропускной способности сети;производительности CPU, так как SSH использует шифрование;настроек SSH, таких как алгоритмы шифрования.

В моем примере для подключения используется имя пользователя на удаленном сервере – ivan и адрес хоста – vpn.r4ven.me (можно указать IP). Замените эти значения в командах на свои.

Отключите VPN и проверьте скорость download с помощью команды:

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

ssh ivan@vpn.r4ven.me dd if=/dev/zero bs=1M count=1024 | pv | cat > /dev/null

Для остановки проверки используйте сочетание клавиш Ctrl+c.

И теперь скорость upload:

dd if=/dev/zero bs=1M count=1024 | pv | ssh ivan@vpn.r4ven.me 'cat > /dev/null'

Затем включите VPN и выполните обе команды снова. Если без туннелирования трафика скорость значительно выше, значит факторы, влияющие на скорость передачи данных на самом сервере, где развернут VPN. Если скорость низкая в обоих случаях, вероятно дело в канале до сервера.

Что вообще делают эти команды

1-я команда (Download)

• ssh ivan@vpn.r4ven.me dd if=/dev/zero bs=1M count=1024 – генерирует поток нулевых данных (из /dev/zero) на удалённом сервере с помощью утилиты dd размером 1 ГБ (1024 блока по 1 МБ) и отправляет их через SSH-соединение;
• | pv – на локальной машине с помощью механизма перенаправления измеряет скорость получения по SSH данных;
• | cat > /dev/null – перенаправляет поток данных, проходящий через pv в псевдоустройство (черную дыру), исключая нагрузку на диск.

2-я команда (Upload)

• dd if=/dev/zero bs=1M count=1024 – генерирует поток нулевых данных (/dev/zero) на локальной машине также с помощью утилиты dd (1 ГБ);
• | pv – измеряет скорость передачи данных;
• | ssh ivan@vpn.r4ven.me 'cat > /dev/null' – передает данные через SSH на удалённый сервер также в черную дыру.

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

Если при включенном VPN маршрут до удаленного сервера идет не через туннель

В такой ситуации попробуйте временно добавить маршрут вручную, а после проведения проверок удалить. Но только если удаленный сервер – это не сам сервер VPN!

Вот пример команд:

# проверка маршрута
ip route get <IP_address>

# добавление маршрута через серетвой интерфейс tun0
ip route add <IP_address> dev tun0

# удаление добавленного ранее маршрута
ip route del <IP_address> dev tun0

Где <IP_address> – IP адрес сервера, а tun0 – это виртуальный сетевой интерфейс вашего туннельного соединения на локальной машине. Замените значения на свои. Узнать их можно с помощью команд:

# ip адрес
ping -c1 vpn.r4ven.me | head -1 | awk -F'[()]' '{print $2}'

# список интерфейсов
ip address

На почитать

• SSH – Безопасное подключение к удалённым хостам: введение | Вороний блог
• Командная строка Linux, перенаправление ввода и вывода: операторы “>”, “<“, “|”
• Поднимаем OpenConnect SSL VPN сервер (ocserv) в docker для внутренних проектов | Вороний блог
• pv — маленькая, но очень полезная утилита | Habr
• Мануал утилиты pv | ubuntu.com (EN)

Приветствую!

В прошлой заметке📝 мы говорили про терминальные мультиплексоры и какие задачи они выполняют. В сегодняшней статье я продемонстрирую установку и кастомизацию самого популярного инструмента из данной категории – Tmux🪟. Как обычно, уже все выстрадано настроено, и для повторения подобного у вас, необходимо будет выполнить всего несколько команд🧑‍💻.

Присоединяйтесь к нашему каналу в телеграм: t.me/r4ven_me, уведомления о новых постах приходят туда в день публикации. А если у вас есть вопросы или просто желание пообщаться по тематике – заглядывайте в чат: t.me/r4ven_me_chat.

Демонстрация, приведенная в данной статье выполнялась в среде дистрибутива Linux Mint 22 с Tmux версии 3.4✍️.

Предисловие

Я очень люблю тему Nord❄️ от разработчиков Arcticicestudio⛄️ и предпочитаю оформлять свою систему и приложения в этой палитре😌. Tmux не стал исключением, поэтому для корректного и гармоничного отображения конфигурации, как у меня вам понадобятся:

1. Любой моноширный иконочный Powerline шрифт⚡️.
• Например из проекта Nerd fonts. Я предпочитаю шрифт Hack Nerd Font Mono. Шрифт необходимо поместить по пути /usr/share/fonts/ либо отдельно для пользователя в ~/.local/share/fonts/ и применить его к терминалу.
2. Любой эмулятор терминал🧑‍💻, с поддержкой TrueColor и темы Nord.
• Например Gnome-terminal или выпадающий (drop-down) терминал – Guake. По моему опыту, данная тема есть под любой популярный эмулятор терминала;
3. (Опционально) Консольный редактор📝 с темой Nord.
• Например Vim/Neovim.
4. (Опционально) Интерактивная командная оболочка💻.
• Например Zsh + Oh-My-Zsh с темой agnoster.

Для тех, кто только знакомится с Tmux кратко перечислю его сущности🧐:

• Сессия (session) – основная единица работы, содержащая окна и панели;
• Окно (window) – отдельный терминал в сессии;
• Панель (pane) – разделение окна на несколько терминалов (панелей);
• Команды (command) – инструкции для управления tmux;
• Клавиша префикса (prefix) – клавиша для активации команд (по умолчанию Ctrl-b);
• Состояние (state) – активные и неактивные окна и панели;
• Конфигурация (config) – настройки tmux, например в файле ~/.tmux.conf или ~/.config/tmux/tmux.conf.

Можем приступать к установке.

Установка Tmux

Tmux почти всегда есть в стандартных репозиториях, а во многих дистрибутивах Linux он даже предустановлен👌.

Открываем терминал и выполняем:

sudo apt update && sudo apt install -y curl git xclip tmux

• curl – утилита для взаимодействия с web (понадобится для скачивания конфига);
• git – система контроля версий и одноименная утилита для работы с git репозиториями (нужна для установки сторонних плагинов);
• xclip – утилита управления буфером обмена в desktop системах Xorg, обычно предустановлена (если выполняете установку tmux на системе без gui, то ее можно не устанавливать);
• tmux – сам терминальный мультиплексор;

Скачивание конфига и запуск

Теперь воспользуемся утилитой curl, чтобы скачать файл конфигурации Tmux с моего GitHub😇 репозитория:

curl --create-dirs -fLo \
    ~/.config/tmux/tmux.conf \
    https://raw.githubusercontent.com/r4ven-me/dots/main/.config/tmux/tmux.conf

Осталось только запустить Tmux😳. Первый запуск займет некоторое время⏳, т.к. будут скачиваться менеджер плагинов и далее сами плагины с помощью этого менеджера.

Конфигурация построена так, что при добавлении новых плагинов, во время запуска/перезапуска Tmux, они будут устанавливаться автоматически😌. Для установки плагинов вручную используйте prefix+I.

Для создания новой именованной сессии воспользуйтесь командой:

tmux new -s Work

Где:

• new – команда создания новой сессии;
• -s – ключ для указания имени сессии;
• Work – произвольное имя сессии.

Должно получиться примерно так:

Все😃 настройка завершена! теперь можно активно пользоваться:

Понравился мой конфиг Neovim? Можете с легкостью создать аналогичный по статье: Neovim – Установка и настройка редактора кода с элементами IDE всего в несколько команд.

А если у вас широкий монитор, то вообще 🔥🔥🔥!

Для выхода из tmux без закрытия сессий отправьте команду dettach специальной горячей клавишей: сперва нажмите сочетание клавиш так называемого префикса, по умолчанию это Ctrl+b, а затем сразу же клавишу d, сокращенно: prefix+d.

Да, такой стиль горячих клавиш у Tmux🤷‍♂️. Сперва нажимается клавиша prefix, а затем клавиша действия/команды. К такому способу нужно привыкнуть. Клавишу prefix можно изменить в конфигурации. Но делать это не рекомендуется, чтобы сохранить универсальность🫠.

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

tmux attach -t Work || tmux new -s Work

Где:

• attach – команда подключения к запущенной сессии;
• -t – ключ для указания тега/имени существующей сессии;
• Work – имя запущенной ранее нами сессии;
• || – логическое “или” в контексте оболочки, другими словами, параметр контроля выполнения, который запустит следующую за ним команду в случае ошибки предыдущей.

Рекомендую сразу же создать удобный alias для вашей оболочки:

echo 'alias T="tmux attach -t Work || tmux new -s Work"' >> ~/.profile

source ~/.profile

Замените ~/.profile на файл с параметрами подготовки вашего окружения оболочки при необходимости☝️.

Теперь подключаться к существующей сессии с именем Work можно просто по команде из одной буквы T.

Описание конфигурации и обзор файла tmux.conf

Что дополняет/изменяет данная конфигурация

Общие настройки📖:

• включена поддержка 256 цветов: screen-256color;
• включена поддержка TrueColor для более точного отображения цветов;
• окна нумеруются с 1, а не с 0 (base-index 1);
• панели в окнах тоже нумеруются с 1 (pane-base-index 1);
• лимит буфера истории увеличен до 10,000 строк для прокрутки терминала;
• включена мышь! можно щелкать для выбора окон, прокручивать вывод, изменять размер панелей, менять их местами, также доступен вызов контекстного меню через ПКМ;
• включено автоматическое обновление заголовков окон терминала;
• используются vi-стиль клавиш для работы в режиме копирования (mode-keys vi) и взаимодействия с командами tmux (status-keys vi вызывается prefix+:);
• установлена Zsh как оболочка по умолчанию (замените на свою, если используется иная);
• установлена локаль ru_RU.UTF-8, чтобы корректно отображать русские символы.

Управление мышью🐁:

• Общие действия:
• двойной клик по строке статуса создает новое окно (bind-key -n DoubleClick1Status new-window);
• Если используется X11-сервер при работы с tmux:
• средняя кнопка мыши вставляет текст из системного буфера обмена (используется xclip);
• после выделения текста с помощью мыши копирует текст в буфер обмена без очистки выделения;
• в режиме копирования(!) поддерживается выбор слова/строки по двойному/тройному клику:
• двойной клик ЛКМ: выделяет слово, копирует его в буфер обмена;
• тройной клик ЛКМ: выделяет строку, копирует её в буфер обмена;
• нажатие ЛКМ в режиме копирования отменяет текущее выделение;
• В других средах (если не используется X11):
• поведение схоже, но текст сохраняется только во внутренний буфер tmux, а не в системный.

Клавиатурные сочетания🎹:

Немного расширены некоторые сочетания клавиш. Подробнее смотрите далее: Пункт 6. Кастомные горячие клавиши Tmux.

Список плагинов📋:

1. tmux-plugins/tpm – менеджер плагинов для tmux:
• обеспечивает установку и управление другими плагинами;
2. tmux-plugins/tmux-sensible – устанавливает оптимальные настройки tmux по умолчанию;
3. arcticicestudio/nord-tmux – устанавливает тему Nord для tmux;
4. tmux-plugins/tmux-resurrect – сохраняет состояние сессий (окна, панели, запущенные процессы) и позволяет восстанавливать сессии после перезапуска tmux;
5. tmux-plugins/tmux-continuum – расширение для tmux-resurrect:
• автоматически сохраняет сессии через заданные интервалы (60 минут);
• автоматически восстанавливает сессии при запуске tmux;
• активация с помощью юнита systemd:
• см. systemctl status --user tmux

Дополнительно📦:

• автоматическая установка tpm при первом запуске и проверка/установка новых плагинов при каждом запуске/перезапуске;
• очистка старых файлов сессий старше 3 дней (в ~/.local/share/tmux/resurrect/);
• используется система восстановления для Neovim через механизм сессий.

Содержимое файла tmux.conf

Дабы не делать из статьи полотно, последняя версия tmux.conf также доступна в моем GitHub.

Базовые горячие клавиши Tmux

Ниже представлены частоиспользуемые базовые команды/сочетания клавиш tmux. Если планируете регулярно работать в среде tmux, то настоятельно рекомендую их запомнить🤯.

Префикс❗️:

Ctrl-b – prefix;

Управление окнами (windows)🪟:

• prefix+c – создать новое окно (на статус панели выглядит, как вкладка);
• prefix+w – показать список окон;
• prefix+n – переключиться на следующее окно;
• prefix+p – переключиться на предыдущее окно;
• prefix+<номер> – перейти к окну с указанным номером (например, ptefix+1 – к первому окну);
• prefix+, – переименовать текущее окно.

Управление панелями (panes)🎛:

• prefix+% – разделить окно на панели вертикально;
• prefix+" – разделить окно на панели горизонтально;
• prefix+o – переключиться на следующую панель;
• prefix+q – показать номера панелей (полезно для выбора);
• prefix+x – закрыть текущую панель;
• prefix+z – развернуть текущую панель на весь экран (и вернуть её обратно);
• prefix+{ – переместить панель влево;
• prefix+} – переместить панель вправо;
• prefix+! – вынести текущую панель в отдельное окно.

Управление сессиями📚:

• tmux new -s <имя> – создать новую сессию с именем;
• tmux ls – показать список сессий;
• tmux attach -t <имя> – подключиться к сессии;
• prefix+d – отсоединиться от текущей сессии.

Копирование и вставка📋:

• prefix+[ – войти в режим копирования;
• Стрелки или PgUp/PgDn – навигация по истории;
• Пробел – начать выделение текста;
• Enter – скопировать выделенный текст;
• Esc – отмена выделения;
• q – выход из режима копирования;
• prefix+] – вставить скопированный текст.

Дополнительно📦:

• prefix+t – показать часы;
• prefix+? – показать справку о всех комбинациях клавиш;
• prefix+s – показать список сессий.

Кастомные горячие клавиши Tmux

Добавленные/измененные команды/клавиши из моего конфига.

Режим копирования и работа с буфером обмена📝:

1. prefix+v – включает режим копирования (аналог prefix+[);
2. v (в режиме копирования) – начинает выделение текста;
3. Enter и y (в режиме копирования, X11):
• копирует выделенный текст в системный буфер обмена с помощью xclip;
• завершает режим копирования;
4. y (в режиме копирования, не X11):
• копирует выделение в буфер tmux;
• завершает режим копирования;
5. p (в режиме копирования, X11):
• завершает режим копирования;
• вставляет содержимое системного буфера обмена с помощью xclip.
6. p (в режиме копирования, не X11):
• завершает режим копирования;
• вставляет содержимое буфера tmux;
7. prefix+] и prefix+P (в обычном режиме, X11):
• вставляет содержимое системного буфера обмена с помощью xclip;
8. prefix+] и prefix+P (в обычном режиме, не X11):
• вставляет содержимое буфера tmux.

Навигация между панелями (в стиле vi)🎛:

• prefix+h – переключиться на панель слева;
• prefix+j– переключиться на панель снизу;
• prefix+k – переключиться на панель сверху;
• prefix+l – переключиться на панель справа.

Изменение размеров панелей (в стиле vi)🎛, клавишу команды можно нажимать многократно:

• prefix+H – увеличить панель влево на 2 пикселя;
• prefix+J – увеличить панель вниз на 2 пикселя;
• prefix+K – увеличить панель вверх на 2 пикселя;
• prefix+L – увеличить панель вправо на 2 пикселя.

Сохранение и восстановление среды через tmux-resurrect💾:

1. prefix+F5:
• сохраняет текущее состояние tmux с помощью tmux-resurrect;
• перемещает последнюю сохранённую сессию в файл ~/.local/share/tmux/resurrect/main.txt для удобства восстановления;
• показывает сообщение о ручном сохранении;
2. prefix+F6:
• загружает сохранённое состояние из файла main.txt.

Послесловие

Фух😮‍💨. Сегодня в нашем арсенале Linux администратора появился еще один полезный инструмент🧑‍💻. С его помощью крайне удобно обслуживать системы📺, где нет графики, например на серверах, которые работают 24/7. Единожды запустили все необходимые утилиты и после просто подключаемся к запущенной сессии, с помощью короткого алиаса😌.

Обязательно подписывайтесь на наш телеграм канал✈️, чтобы не пропустить новых публикаций на сайте🌐. А если у вас остались вопросы, то добавляйтесь в Вороний чат: у нас там дружелюбное микросообщество🐧🚶‍♂️🐧🚶‍♂️🐧🚶‍♂️.

Спасибо, что читаете😇. Желаю успехов в освоении новых инструментов, которые упрощают рутину и повышают эффективность💪.

Полезные материалы

• Мой конфиг Tmux | GitHub
• Словарик линуксоида: Терминальный мультиплексор | Вороний блог
• Tmux | ArchWiki
• ‘Getting started’ из оф. документации | GitHub
• Плагин tpm | GitHub
• Плагин tmux-sensible | GitHub
• Плагин nord-tmux | GitHub
• Плагин tmux-resurrect | GitHub
• Плагин tmux-continuum | GitHub

Приветствую!

Сегодня в словарике линуксоида🐧 терминальный мультиплексор – инструмент, который очень часто используется в процессе администрирования Linux систем 🧑‍💻. Как обычно дадим определение термину, поговорим про популярные реализации терминальных мультиплексоров и конечно про их преимущества и недостатки🧐.

Присоединяйтесь к нашему каналу в телеграм: t.me/r4ven_me, уведомления о новых постах приходят туда в день публикации. А если у вас есть вопросы или просто желание пообщаться по тематике – заглядывайте в чат: t.me/r4ven_me_chat.

Также обратите внимание, что этот теоретический пост📗 предшествует будущей статье по установке и настройке популярного мультиплексора Tmux🪟.

Что такое терминальный мультиплексор?

Терминальный мультиплексор (terminal multiplexer) — это инструмент, позволяющий пользователю управлять несколькими сессиями терминала в одном окне. Он выполняет роль “менеджера окон” для консоли, позволяя запускать и переключаться между множеством процессов и оболочек, разделять экран на панели и (самое важное для меня) восстанавливать работу после разрыва соединения, например SSH. Управление происходит с помощью горячих клавиш🎹 и иногда мыши🐭.

В общем, незаменимый инструмент для продвинутых пользователей Linux😎.

Краткая история

Идея управления несколькими терминальными сессиями возникла вместе с развитием многозадачности в Unix-подобных системах. Первым популярным инструментом для этих целей стал screen от проекта GNU, выпущенный в 1987 году. Он был прост в использовании и позволял восстановить сессии после разрыва связи🧐.

Со временем появились новые инструменты, которые предложили более современный функционал. Так в верните мой 2007 году был выпущен tmux🔥, который пришел из мира BSD и стал популярной альтернативой screen, благодаря удобной настройке, расширяемости и поддержке сценариев.

В последние годы появились более современные реализации👀, такие, как Zellij и Wezterm, нацеленные на улучшение пользовательского опыта.

Популярные реализации, их плюсы и минусы

GNU Screen

• Написан на: С;
• Лицензия: GPL 3.0;
• Плюсы:
• лёгкость установки (доступен практически во всех репозиториях);
• простота конфигурации и работы;
• проверенная временем стабильность.
• Минусы:
• ограниченный функционал по сравнению с современными аналогами;
• несколько устаревший интерфейс, неудобство настройки горячих клавиш;
• низкая активность разработки в последние годы.

Tmux

А вот, как выглядит моя конфигурация Tmux, про которую я расскажу в будущей статье:

• Написан на: С;
• Лицензия: ISC (BSD);
• Плюсы:
• гибкость настройки, возможность создавать сложные конфигурации;
• активное сообщество и регулярные обновления;
• поддержка плагинов для расширения функциональности🤯;
• улучшенное управление окнами и панелями.
• Минусы:
• кривая обучения для новичков (особенно настройка конфигурационного файла);
• некоторые функции требуют установки сторонних плагинов.

Zellij

• Написан на: Rust;
• Лицензия: MIT;
• Плюсы:
• интуитивный интерфейс и продуманная система горячих клавиш;
• расширенные возможности для работы с несколькими пользователями;
• современный дизайн и активно развивающийся проект.
• Минусы:
• молодой инструмент, не такой стабильный, как tmux или screen;
• меньшее количество плагинов и документации.

Wezterm

• Написан на: Rust;
• Лицензия: MIT;
• Плюсы:
• интеграция с современными терминалами и поддержка GPU-рендеринга;
• расширенные возможности кастомизации интерфейса посредством Lua;
• по сути является полноценным терминалом.
• Минусы:
• сложность настройки для начинающих;
• менее популярный в сообществе инструмент, поэтому сложнее найти помощь.

Заключение

Выбор терминального мультиплексора зависит, конечно же, от ваших требований и вкусов🤷‍♂️.

Я предпочитаю работать в Tmux, т.к. это был первый мультиплексор, с которым я познакомился😌. Еще конечно немаловажный фактор – это время и ресурсы, которые я потратил на настройку Tmux🤯, чтобы превратить его в идеальный для меня инструмент работы с консолью.

Если вы часто находитесь в окне терминала, но еще не работали с терминальными мультиплексорами, рекомендую обратить на них внимание👍.

Подписывайтесь на Вороний блог в телеграм: @r4ven_me📱, чтобы не пропустить новые посты. Если возникли вопросы или желание пообщаться по теме – заглядывайте в наш чат там же: @r4ven_me_chat💬. У нас вежливое микросообщество🤓.

Полезные источники

• Терминальный мультиплексор | Википедия (EN)
• Терминальные мультиплексоры | Habr
• GNU Screen | ArchWiki (EN)
• Tmux | ArchWiki (EN)
• Zellij | Сайт проекта (EN)
• Wezterm | Сайт проекта (EN)

Приветствую!

В этой заметке мы с вами познакомимся с популярной open source системой управления конфигурациями с говорящим названием – Ansible🎻. Выполним установку и настройку🛠, составим инвентаризацию📋, научимся запускать плейбуки🚀, поговорим про Ansible facts🗂, узнаем, что такое Ansible console🖥 и напишем playbook📝 который правит конфиг sshd и копирует файлы на сервер. Будет познавательно😉!

Присоединяйтесь к нашему каналу в телеграм: t.me/r4ven_me, уведомления о новых постах приходят туда в день публикации. А если у вас есть вопросы или просто желание пообщаться по тематике – заглядывайте в чат: t.me/r4ven_me_chat.

Предисловие

Чтобы чуть лучше понимать суть происходящего, рекомендую прочитать мою теоретическую заметку📝 про системы управления конфигурациями (Cofiguration Management, CM). В ней дано описание термина, какие виды существуют, а также коротко рассказано про популярные реализации подобных систем и их отличия.

Возвращаясь к Ansible, с его помощью можно автоматизировать конфигурацию серверов путем описания желаемого состояния в удобном формате yaml. Стоит также отметить, что операции Ansible имеют свойство идемпотентности🙄. Это означает, что, если вы запускаете плейбук или задачу несколько раз, состояние системы не изменится после первого успешного выполнения.

Ну и прежде, чем мы продолжим углубляться перечислю основные сущности данной CM📒:

• Control node — управляющий сервер, на котором установлен Ansible и с которого запускаются команды и Playbooks с помощью SSH;
• Managed nodes — управляемые серверы, на которых Ansible выполняет задачи, не требуют установки Ansible на них;
• Inventory file — файл(ы) (обычно inventory.yml), содержащий список управляемых узлов и их групп для логического объединения. В нем указываются IP-адреса, DNS имена, порты и пользовательские переменные;
• Configuration file — файл конфигурации Ansible (по умолчанию ansible.cfg), где задаются настройки, например, путь к файлу инвентаря, параметры SSH и другие параметры, позволяющие настроить поведение Ansible под конкретные нужды;
• Variables — переменные, которые можно использовать для гибкой настройки задач и параметров. Переменные могут определяться на разных уровнях: в файле инвентаризации, плейбуке, ролях, командах и динамически собираться;
• Playbook — файл сценария в формате YAML, описывающий, какие задачи нужно выполнить на каких узлах;
• Facts (факты) — информация об управляемом сервере в виде системных переменных (например, тип и версия ОС, IP-адрес, версии пакетов и пр.), автоматически собираемая Ansible. Часто используются для описания условий выполнения задач (tasks);
• Task — отдельное задание, выполняемое на управляемом узле. Это атомарная инструкция (например, установка пакета), описанная с помощью Ansible module;
• Module — готовый модуль из библиотеки Ansible для выполнения конкретной задачи, например, копирование файла, управление сервисами, установка пакетов и пр.;
• Handler (обработчик) — задача, которая запускается только при изменении состояния (например, перезапуск сервиса), вызывается из задачи через параметр notify;
• Template — файл шаблона (в формате Jinja2), который позволяет, например, создавать динамические файлы конфигурации с использованием переменных и конструкций, свойственным языкам программирования (фильтры, циклы, условные выражения и т.д.), тут можно утонуть;
• Role — структура файлов и директорий для удобной организации задач, шаблонов, файлов переменных для Playbook. По сути, это плейбук, раздробленный на отдельные файлы/папки для большего удобства и наглядности;
• Plugins – дополнения Ansible, расширяющие его функционал.

Установка Ansible в Debian / Ubuntu / Linux mint

Пример установки я буду показывать в среде дистрибутива Debian 12😎:

Т.к. Ansible работает по push принципу (т.е. все управление происходит с административного сервера), то и устанавливать его необходимо только на одной машине. На управляемых серверах понадобится установленный Python🐍 и доступ по SSH.

Подробнее про использование и настройку SSH в Linux, в т.ч. и работу с ключами, читайте в отдельной инструкции: SSH – Безопасное подключение к удалённым хостам: введение.

Все необходимые пакеты Ansible есть в стандартных репозиториях🗄. Поэтому просто открываем терминал и вводим команду:

sudo apt update && sudo apt install -y ansible sshpass

Также мы устанавливаем утилиту sshpass, которая понадобится для передачи пароля при соответствующей SSH аутентификации, а также получение полномочий через sudo💪.

Зависимостей много, поэтому установка займет некоторое время⏳.

Настройка Ansible – файл ansible.cfg

Переходим к начальной настройке. Для этого создаем необходимые директории и файл конфигурации. Открываем его любым текстовым редактором (я предпочитаю vim/neovim)🧑‍💻:

mkdir -p ~/ansible/{playbooks,roles,tmp}

nvim ~/ansible/ansible.cfg

И наполняем его:

[defaults]
home = ~/ansible/                    ; основная директория Ansible
local_tmp = ~/ansible/tmp/           ; локальная временная директория для выполнения задач
inventory = ~/ansible/inventory.yml  ; путь к файлу инвентаря с перечнем хостов
playbook_dir = ~/ansible/playbooks/  ; директория, где хранятся плейбуки
roles_path = ~/ansible/roles/        ; директория, где Ansible ищет роли
remote_user = ivan                   ; пользователь, под которым Ansible подключается к хостам
become_method = sudo                 ; метод повышения прав (sudo, su)
become_user = root                   ; пользователь, от имени которого выполняются sudo команды
gather_facts = True                  ; собирать факты о системе перед выполнением задач
private_key_file = ~/ansible/id_ed25519  ; путь к приватному ключу для подключения по SSH
host_key_checking = False            ; отключает проверку ключей хоста SSH
fact_caching = jsonfile              ; кэширование фактов с использованием формата json
fact_caching_connection = ~/ansible/tmp/  ; путь для хранения кэшированных фактов

Понравился мой конфиг Neovim? Можете с легкостью создать аналогичный по статье: Neovim – Установка и настройка редактора кода с элементами IDE всего в несколько команд.

Такой конфигурации достаточно, чтобы начать использовать Ansible👍. Этот файл определяет поведение Ansible по умолчанию, которое может быть переопределено в других местах: файлах инвентаризации, плейбуках, файлах переменных, командах или в других конфигах.

Если есть потребность изучить все доступные параметры файла конфигурации🤓, то его можно сгенерировать такой командой:

ansible-config init --disabled > ~/ansible/ansible.cfg.example

Файл хорошо прокомментирован🧐.

Подробнее про процесс конфигурации смотрите на оф. сайте: Ansible Configuration Settings.

Также для удобства, рекомендую сразу добавить переменную окружения, указывающую на наш дефолтный файл конфига:

export ANSIBLE_CONFIG="$HOME/ansible/ansible.cfg"

# для создания переменной при входе в систему
echo 'export ANSIBLE_CONFIG="$HOME/ansible/ansible.cfg"' >> ~/.profile

Замените ~/.profile на файл загрузки окружения вашей оболочки. В моем случае используется интерактивная оболочка ZSH.

В таком случае можно будет пользоваться командами Ansible из любой директории без явного указания пути до файла с настройками😌.

Полный список доступных переменных окружения также смотрите в оф. доке: Environment Variables.

Инвентаризация – файл inventory.yml

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

nvim ~/ansible/inventory.yml

И добавляем в него список наших серверов📋, которыми будем управлять. В моем примере 5 Linux серверов (3 – Debian, 2 – Ubuntu):

## HOSTS
all:
  hosts:
    debian12-vpn:
      ansible_host: 192.168.122.93
      ansible_port: 22
      ansible_user: ivan
      ansible_ssh_private_key_file: ~/.ssh/id_ed25519
      project: vpn
    debian12-dns:
      ansible_host: 192.168.122.201
      ansible_port: 22
      ansible_user: ivan
      ansible_ssh_private_key_file: ~/.ssh/id_ed25519
      project: vpn
    debian12-monitoring:
      ansible_host: 192.168.122.30
      ansible_port: 22
      ansible_user: ivan
      ansible_ssh_private_key_file: ~/.ssh/id_ed25519
      project: monitor
    ubuntu22-storage:
      ansible_host: 192.168.122.5
      ansible_port: 22
      ansible_user: ivan
      ansible_ssh_private_key_file: ~/.ssh/id_ed25519
      # ansible_password: "Pa$$w0rD"
      project: storage
    ubuntu22-backup:
      ansible_host: 192.168.122.249
      ansible_port: 22
      ansible_user: ivan
      ansible_ssh_private_key_file: ~/.ssh/id_ed25519
      # ansible_become_password: "Pa$$w0rD"
      project: storage

## GROUPS
debian:
  hosts:
    debian12-vpn:
    debian12-dns:
    debian12-monitoring:
ubuntu:
  hosts:
    ubuntu22-storage:
    ubuntu22-backup:

Не забудьте заменить параметры на свои 😉

Сохраняем, закрываем.

Имейте в виду, что формат YAML отступозависимый. Это значит, что отступы являются частью синтаксиса, и даже один неправильный пробел приведет к ошибке.

Коротко опишу содержимое на примере сервера debian12-vpn:

• debian12-vpn – произвольное имя хоста в файле инвентаризации;
• ansible_host: 192.168.122.93 – адрес хоста (IP или DNS);
• ansible_port: 22 – порт подключения SSH;
• ansible_user: ivan – пользователь SSH, с помощью которого выполняется подключение;
• ansible_ssh_private_key_file: ~/.ssh/id_ed25519 – путь до приватного SSH ключа (переопределяет значение из ansible.cfg);
• Нежелательная альтернатива: ansible_password – пароль подключения по SSH;
• project: vpn – пользовательская переменная для данного хоста.

Также обратите внимание, что после списка хостов идет список групп🖥🖥:

• debian
• ubuntu

которые включают в себя хосты, разделенные по ОС (в моем случае). Группы также формируются произвольно, главное соблюдайте синтаксис.

Весь список доступных параметров подключения для файла inventory смотрите тут: Connecting to hosts: behavioral inventory parameters.

Наш файл инвентаря составлен, давайте посмотрим на его структуру такой командой:

ansible-inventory --graph

Эта визуализация особенно полезна, если у вас большая инфраструктура из сотен серверов, разбитых на группы📊.

Пишем первый плейбук: проверка доступности серверов с помощью модуля ping

В контексте Ansible модуль ping не выполняет ping сервера в классическом понимании🤷‍♂️. Его задача произвести подключение к серверу по SSH, выполнить некоторые проверки (например наличие интерпретатора Python) и вернуть сообщение об успехе/ошибке👀.

Создаем файл плейбука в директории, которую мы обозначили в файле конфигурации:

nvim ~/ansible/playbooks/ping.yml

В самом простом виде плейбук выглядит так:

---

- name: Check connection

  hosts: all
  gather_facts: false
  tasks:
    - name: Ping
      ping:

Где:

• hosts: all – список хостов, на которых требуется выполнить плейбук (в данном примере на всех);
• gather_facts: false – отключает сбор фактов (про них будет ниже);
• tasks – блок со списком задач, выполняемых на управляемых хостах, в данном случае одна задача: ping.

Сохраняем файл и запускаем плейбук:

ansible-playbook ./ansible/playbooks/ping.yml

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

В моем примере доступ до серверов настроен по ключам SSH. Поэтому проверка доступности выполнена успешно😎.

Если вы используете пароль (что не рекомендуется)😳 можете задать его в файле ansible.cfg (параметр ansible_password) или передать интерактивно с помощью ключа --ask-pass (для этого мы устанавливали пакет sshpass):

ansible-playbook ./ansible/playbooks/ping.yml --ask-pass

В случае каких-либо ошибок, Ansible выведет страшного вида красные сообщения⛔️. Например, при недоступности хоста по SSH такое:

Чтобы запустить плейбук на указанной группе серверов, можно их явно указать в команде через параметр -l (limit):

ansible-playbook ./ansible/playbooks/ping.yml -l ubuntu

Для запуска плейбука от имени привилегированного пользователя💪 добавьте ключ -b (become). В моем примере модуль ping запуститься от имени root:

ansible-playbook ./ansible/playbooks/ping.yml -b

В моей конфигурации серверов настроен беспарольный доступ к root через sudo (т.к. у меня тестовый стенд🛠), поэтому все отработало корректно. Но если у вас доступ по паролю, его можно передать в файле ansible.cfg (параметр ansible_become_password, не рекомендуется) или ввести интерактивно, с помощью ключа --ask-become-pass:

ansible-playbook ./ansible/playbooks/ping.yml -b --ask-become-pass

Ну а для безопасной автоматизации передачи паролей используется шифрование с помощью ansible-vault, но это тема для отдельной статьи😉.

Если что, вот документация по модулю ping.

Ansible facts – модули setup и debug

Как уже ранее говорилось, факты Ansible (facts) – это информация об управляемом сервере в виде системных переменных, таких как тип и версия ОС, IP-адрес, версии пакетов и пр., автоматически собираемая Ansible во время выполнения плейбуков (если активирован флаг gather_facts) и команд🤯.

Давайте теперь соберем эти факты, чтобы понять, как они выглядят👨‍🏭. Для этого используется стандартный модуль setup. Выполняем:

ansible all -m setup

all – тут логично представляет всех хостов из файла инвентаря. Тут также можно указать любой хост отдельно, список хостов через запятую или группу.

В зависимости от количества хостов, сбор фактов может занять какое-то время. В выводе команды вы увидите все собранные факты в формате json:

Факты можно фильтровать, например так:

ansible debian12-vpn -m setup -a 'filter=os_family,distribution_version'

Ранее в файле ansible.cfg мы настроили кэширование фактов с помощью fact_caching☝️.

Это значит, что собранные факты будут сохранятся в виде json файлов во временной директории ~/ansible/tmp, которую мы также обозначили в файле конфига:

ls -l ./ansible/tmp/

Часто необходимо получить значения только конкретных фактов или переменных. Это можно сделать с помощью модуля debug🔨 в плейбуках или прямо в терминале.

Вот пример получения информации об OS, объеме диска /dev/sda1, переменной project и выводе shell команды на сервере debian12-vpn в playbook:

nvim ./ansible/playbooks/debug.yml

---

- name: Debug

  hosts: debian12-vpn
  gather_facts: true
  become: true

  tasks:

    - name: Debug 1
      debug:
        msg: "Example to use var: {{ ansible_facts.os_family }}"

    - name: Debug 2
      debug:
        var: ansible_facts.distribution_version

    - name: Debug 3
      debug:
        var: project

    - name: Shell 1
      shell:
        cmd: whoami
      register: user_name

    - name: Debug 4
      debug:
        var: user_name.stdout

И запускаем:

nvim ./ansible/playbooks/debug.yml

Просмотр фактов с помощью команд в терминале:

В этом случае факты будут взяты из кэша.

ansible debian12-vpn -m debug -a 'var=ansible_facts.os_family,ansible_facts.distribution_version'

ansible debian12-vpn -m debug -a 'var=ansible_facts.devices.keys()'

ansible debian12-vpn -m debug -a 'var=ansible_facts.devices.sda.partitions.sda1.size'

Можно было заметить, что обращение к фактам происходит с помощью синтаксиса точки, как в Python (ansible написан на этом языке👌).

Подборную инфу по сбору фактов также смотрите на оф сайте: Discovering variables: facts and magic variables. Инфа по модулю debug тут.

Выполнение shell команд в терминале на нескольких серверах одновременно

С помощью Ansible и стандартного модуля shell можно выполнять удаленные команды сразу на множестве серверов🧑‍💻💻💻💻. Это очень удобно для дебага или выполнения простых операций.

Удаленная команда передается в кавычках с помощью ключа -a. Например, вывести список сетевых интерфейсов их IP адресов:

ansible all -m shell -a 'ip -br a'

Или выполнить команду из нашей Linux викторины🧐, которая выводит uptime сервера в формате Unix time:

ansible debian12-vpn,ubuntu22-storage -m shell -a 'date -d "$(uptime -s)" +%s'

Для запуска команд от имени привилегированного пользователя также используется -b:

ansible all -m shell -a 'whoami' -b

Что такое Ansible console

В комплекте с Ansible идет такой полезные инструмент, как ansible-console😏. Это интерактивная оболочка для выполнения команд на нескольких серверах. Похоже на команды модуля shell, которые мы выполняли ранее, но способ взаимодействия немного другой:

ansible-console

whoami

Для выхода введите exit или нажмите сочетание клавиш Ctrl+d.

Пример использования модуля ping группы debian:

ansible-console debian

ping

Просмотр фактов Ansible:

setup filter=ansible_hostname

Для выполнения привилегированных команды, добавьте ключ -b (но будьте осторожны!):

ansible-console debian -b

whoami

При выполнении удаленных команд ansible-console по умолчанию используется модуль command❗️. Он вызывает команды напрямую, поэтому некоторые shell механизмы тут работать не будут. Для задействования shell укажите его явно:

shell echo $HOME

Документация Ansible прямо в терминале

У Ansible очень хорошая документация (правда на английском🙄) и она доступна даже из консоли с помощью утилиты ansible-doc. Например, чтобы посмотреть описание и примеры использования модуля systemd выполните:

ansible-doc systemd

Вы попадете в режим просмотра less. Обычно примеры использования модулей в плейбуках находятся внизу документации:

Как по мне, это очень удобно!

Пример ansible playbook: правка конфига sshd и копирование SSH ключа

В качестве практики напишем плейбук📝, который:

• на всех серверах:
• изменит номер порта подключения SSH;
• отключит доступ по паролю на сервер по SSH;
• создаст директорию ~/.ssh, если она не существует;
• добавить новый публичный ssh ключ для авторизации по ключу.
• на серверах, у которых переменная “project” равна “vpn”:
• скопирует файл приватного ключа SSH с локальной машины в директорию пользователя на удаленных серверах.

Генерируем новый ключ:

ssh-keygen -t ed25519 -f ~/ansible/id_ed25519_new

Создаем плейбук:

nvim ./ansible/playbooks/sshd_config.yml

Наполняем его:

---

- name: Config sshd service and copy private key   # имя/описание плейбука
  hosts: all                            # применять ко всем хостам
  gather_facts: false                   # не собирать факты (ускоряет выполнение)
  become: true                          # выполнять с повышением привилегий (sudo)
  force_handlers: true                  # выполнять обработчики даже в случае ошибки

  vars:
    - new_ssh_port: 4444                # новый номер порта SSH
    - user_name: "ivan"                 # имя пользователя, для которого добавляем SSH ключ
    - user_ssh_privkey: "/home/ivan/ansible/id_ed25519_new" # путь до приватного SSH ключа для пользователя
    - user_ssh_pubkey: "/home/ivan/ansible/id_ed25519_new.pub" # путь до публичного SSH ключа для пользователя

  tasks:
    - name: Change sshd port number
      lineinfile:
        path: /etc/ssh/sshd_config      # путь к файлу конфигурации SSH
        regexp: "^Port"                 # регулярное выражение для поиска строки с портом
        line: "Port {{ new_ssh_port }}" # изменить порт на значение из переменной
        backup: true                    # создать бэкап файла sshd_config перед изменением
      notify:
        - Restart sshd                  # обработчик для перезапуска SSH при изменении
      tags:
        - ssh_server                      # тег для возможности выборочного запуска задачи
    
    - name: Disable sshd password auth
      lineinfile:
        path: /etc/ssh/sshd_config      # путь к файлу конфигурации SSH
        regexp: '^PasswordAuthentication yes'  # регулярное выражение для поиска строки
        line: 'PasswordAuthentication no'      # отключаем аутентификацию по паролю
      notify:
        - Restart sshd                  # обработчик для перезапуска SSH
      tags:
        - ssh_server                      # тег для задачи SSH сервера

    - name: Create ssh directory if it does not exist
      file:
        path: "/home/{{ user_name }}/.ssh/"  # путь к директории .ssh для пользователя
        state: directory               # создать директорию, если не существует
        owner: "{{ user_name }}"       # задать владельца
        group: "{{ user_name }}"       # задать группу
        mode: 0700                     # права доступа к директории
      tags:
        - ssh_client                   # тег для задач SSH клиента
    
    - name: Add user ssh public key
      lineinfile:
        path: "/home/{{ user_name }}/.ssh/authorized_keys"  # путь к файлу authorized_keys
        line: "{{ lookup('file', '{{ user_ssh_pubkey }}') }}"  # в качестве добавляемой строки использовать содержимое файла публичного ключа
        owner: "{{ user_name }}"       # задать владельца
        group: "{{ user_name }}"       # задать группу
        mode: 0600                     # права доступа к файлу
        backup: true                   # создать бэкап файла перед изменением
        create: true                   # создать новый файл, если он не существует
      tags:
        - ssh_client                   # тег для задач SSH клиента

    - name: Copy user ssh private key
      copy:
        src: "{{ user_ssh_privkey }}"  # путь к файлу на локальной машине
        dest: "/home/{{ user_name }}/.ssh/"  # путь к директории на удаленном сервере, слэш обязателен
        owner: "{{ user_name }}"       # задать владельца
        group: "{{ user_name }}"       # задать группу
        mode: 0600                     # права доступа к файлу
        backup: true                   # создать бэкап файла перед изменением
      when: project == "vpn"           # выполнять только если у хоста переменная project = "vpn"
      tags:
        - ssh_client                   # тег для задач SSH клиента

  handlers:
    - name: Restart sshd
      systemd:
        name: sshd                     # название systemd сервиса SSH
        state: restarted               # перезапуск сервиса

И запускаем:

ВНИМАНИЕ❗️ Данный playbook меняет номер порта демона sshd и отключает парольный доступ к серверу по SSH. Крайне рекомендуется запускать необкатанные плейбуки в тестовых средах. Все действия вы выполняете на свой страх и ответственность. Я вас предупредил)

ansible-playbook ./ansible/playbooks/sshd_config.yml

Если все отработало корректно, то порт доступа SSH на удаленных серверах будет изменен. Не забудьте скорректировать номер порта в файле инвентаризации. Или верните старый номер порта подобной командой:

ansible-playbook ./ansible/playbooks/sshd_config.yml -e 'ansible_port=4444' -e 'new_ssh_port=22'

В ней переопределены переменная ansible_port (из конфига ansible.cfg), используемая для подключения к хостам, и кастомная переменная new_ssh_port (из плейбука sshd_config.yml), определяющая новый номер порта в плейбуке😶‍🌫️.

На всякий случай повторю, что плейбук также добавляет наш новый публичный (~/ansible/id_ed25519_new.pub) ключ на сервера.

Возможно вы обратили внимание🧐, что в плейбуке используются теги🔖. С их помощью можно осуществлять выборочный запуск. Например, выполнить только те задачи, которых есть тег ssh_client (ключ -t или --tags):

ansible-playbook ./ansible/playbooks/sshd_config.yml -t ssh_client

Или наоборот, игнорировать задачи (--skip-tags):

ansible-playbook ./ansible/playbooks/sshd_config.yml --skip-tags ssh_server

Коротко про Ansible roles

Как говорилось в начале статьи, Ansible role – это структура файлов и директорий для удобной организации задач, шаблонов, файлов переменных для Playbook🚜. Создать шаблон роли можно такой командой:

ansible-galaxy init ./ansible/roles/base-config

Краткое описание структуры:

./ansible/roles/base-config/
├── README.md           # документация роли
├── defaults/           # значения переменных по умолчанию (main.yml)
├── files/              # файлы, которые будут копироваться на целевые хосты
├── handlers/           # обработчики для уведомлений (main.yml)
├── meta/               # метаданные роли, включая зависимости (main.yml)
├── tasks/              # основные задачи роли (main.yml)
├── templates/          # шаблоны Jinja2, которые будут рендериться
├── tests/              # тесты для роли (inventory, test.yml)
└── vars/               # переменные роли с более высоким приоритетом (main.yml)

В будущем, мы обязательно будем писать роли Ansible для различных задач!

Но и это уже совсем другая история)

Создаем функцию для удобного запуска плейбуков

Ранее я обещал функцию для удобного выполнения плейбуков. Она довольно проста, но полезна. Выполняем:

echo 'ap() {ansible-playbook ~/ansible/playbooks/"$@"}' >> ~/.profile

source ~/.profile

which ap

Описания команд выше:

• echo – выводит строку (подробнее про вывод текста тут);
• 'ap() {ansible-playbook ~/ansible/playbooks/"$@"}' – строка, которая определяет функцию ap:
• ap() — объявление функции с именем ap (имя произвольное);
• {ansible-playbook ~/ansible/playbooks/"$@"} – тело функции, которая запускает ansible-playbook, передавая ей все аргументы ("$@"), например, ap playbook.yml --become;
• >> ~/.profile – добавляет строку в конец файла ~/.profile, чтобы функция автоматически загружалась при входе в систему (подробнее про перенаправление потоков тут).
• source ~/.profile – загружает изменения из ~/.profile, активируя функцию ap в текущей сессии;
• which ap – если функция определена успешно, это отобразит её как часть текущей оболочки.

Проверяем работу:

ap ping.yml

Отлично!

Послесловие

Вот мы с вами и познакомились с таким крутым и полезным инструментом управления конфигурациями под названием Ansible😎. Базовые знания у нас есть, теперь осталось применить их на практике для решения рутинных задач😌. В планах написать плейбук по базовой настройке сервера Linux, установке и запуску различных сервисов, установке Arch linux на шифрованные разделы и много чего другого🤯.

Все файлы с примерами доступны в моем репозитории на GitHub.

Спасибо, что уделили время 😊. Если появились вопросы – приглашаю в наш дружелюбный Вороний чат 🚶‍♀️🐧🚶🐧🚶‍♂️🐧 в телеге 😅. Также обязательно подписывайтесь на основной телеграм канал: @r4ven_me, уведомления о новых материалах на сайте приходят туда в день публикации.

Удачи!

Полезные источники

• Файлы с примерами из статьи | GitHub
• Конфигурация ansible (EN) | docs.ansible.com
• Список переменных окружения Ansible (EN) | docs.ansible.com
• Составление инвентаризации Ansible | docs.ansible.com
• Список параметров подключения для файла inventory | docs.ansible.com
• Список фактов (ansible facts) | docs.ansible.com
• Документация по модулю debug | https://docs.ansible.com/
• Документация по модулю ping | https://docs.ansible.com/
• SSH – Безопасное подключение к удалённым хостам: введение | Вороний блог
• VIM – Консольный редактор: знакомство | Вороний блог
• ZSH – Интерактивная командная оболочка для Linux + Oh-My-Zsh | Вороний блог

Присоединяйтесь к нашему каналу в телеграм: t.me/r4ven_me, уведомления о новых постах приходят туда в день публикации. А если у вас есть вопросы или просто желание пообщаться по тематике – заглядывайте в чат: t.me/r4ven_me_chat.

Приветствую!

Сегодня в словарике линуксоида🐧 термин – системы управления конфигурациями. Данные системы уже давно являются неотъемлемой частью процесса администрирования IT инфраструктуры🧑‍💻. По традиции дадим определение термину, узнаем какие существуют типы и популярные реализации подобных систем. Ну и коротко про преимущества и недостатки🧐.

Обращаю ваше внимание, что этот теоретический пост📗 предшествует будущим материалам по Ansible🛠. В числе которых: статья по установке и настройке, плейбук по базовой конфигурации Linux сервера, плейбук по развертыванию OpenConnect сервера и клиента и т.д. Идей у меня много😉.

Вместо введения: зачем нужны системы управления конфигурациями?

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

Снижение затрат на администрирование. CM-системы автоматизируют рутинные задачи, снижая нагрузку на администраторов и давая им возможность сконцентрироваться на стратегических задачах.

Контроль версий и повторяемость. CM-инструменты фиксируют историю изменений и позволяют быстро откатываться к прошлым версиям. Это важно при возникновении неполадок или необходимости вернуть предыдущую конфигурацию.

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

бла бла бла😶‍🌫️

Немного из истории CM-систем

Системы управления конфигурациями появились в ответ на потребность автоматизировать повторяющиеся задачи в управлении серверами и снижать нагрузку на системных администраторов. В начале 2000-х годов, с ростом масштабов веб-приложений и данных, администраторы столкнулись с проблемой: инфраструктура увеличивалась, а управление ею вручную стало занимать слишком много времени и человеческих ресурсов. Разработчики и инженеры осознали, что конфигурации серверов, как и код, могут быть зафиксированы в репозиториях, а их изменение и развертывание — автоматизированы. Тут и пошло поехало😳.

Одной из первых таких систем была CFEngine, созданная Марком Берджессом в 1993 году. Она положила начало автоматизированным CM-инструментам, установив базовые принципы, которые до сих пор используются в более современных системах. CFEngine разрабатывалась на фоне UNIX-систем и была построена вокруг идеи поддержания состояния серверов. Со временем её идеи распространились и повлияли на появление других систем, таких как Puppet и Chef.

Про типы CM-систем

CM-системы можно разделить на два типа: push и pull ориентированные. Эти подходы определяют, как именно CM-системы взаимодействуют с управляемыми серверами.

1. Push-ориентированные системы
   В push-системах центральный сервер управления отправляет команды на целевые машины. Этот подход даёт полный контроль над процессом развертывания. Одним из самых известных примеров push-системы является Ansible.
2. Pull-ориентированные системы
   В pull-системах агенты, установленные на целевых машинах, регулярно обращаются к серверу за обновлениями. Это позволяет автоматизировать процесс управления конфигурацией даже в распределённых системах. Примером такой системы является Puppet.

Популярные CM-системы и их особенности

1. Ansible (наше всё🙃)
• Написан на: Python;
• Лицензия: GPL 3.0;
• Преимущества: простота настройки, отсутствие агентов (использует лишь SSH и Python), поддержка YAML для описания конфигураций;
• Недостатки: последовательное выполнение задач может замедлять работу в крупных средах;
• Из истории: Созданная Михаэлом ДеХааном в 2012 году, Ansible развивалась как лёгкое решение для DevOps-задач, и вскоре была приобретена компанией Red Hat. Интересно, что несмотря на свою молодость, Ansible оказалась настолько успешной, что стала одним из стандартов CM.
2. Puppet
• Написан на: Ruby;
• Лицензия: Apache License 2.0;
• Преимущества: зрелый инструмент с большим сообществом, поддерживает декларативный стиль конфигураций, подходит для крупных компаний;
• Недостатки: требует установки агентов, сложен для новичков;
• Из истории: Puppet был разработан в 2005 году Люком Каньесом, когда необходимость в управлении конфигурациями для масштабных сред уже была очевидна. Puppet Labs, компания, стоящая за Puppet, активно участвовала в формировании подходов к DevOps. На основе Puppet строили свои инфраструктуры крупнейшие компании, такие как Google, Oracle, Cisco и др.
3. Chef
• Написана на: на Ruby (клиентская часть) и Erlang (серверная часть);
• Лицензия: Apache License 2.0;
• Преимущества: гибкость, поддержка Ruby и высокая степень кастомизации;
• Недостатки: высокий порог вхождения для тех, кто не знаком с Ruby, необходимость установки агентов;
• Из истории: Chef, созданный в 2009 году, вдохновлялся идеями Puppet, но предоставил больше свободы за счёт возможности использования Ruby для программирования инфраструктуры. Это помогло компании Opscode (ныне Chef) привлечь к инструменту специалистов, ориентированных на программирование. Chef была одной из первых CM-систем, активно поддерживавших идеи DevOps.
4. SaltStack
• Написан на: Python;
• Лицензия: Apache;
• Преимущества: высокая скорость работы, поддержка как push-, так и pull-ориентированной модели;
• Недостатки: может быть сложен в настройке;
• Из истории: SaltStack был выпущен в 2011 году и привлёк внимание благодаря быстрой обработке команд и гибкости. В отличие от других систем, SaltStack предоставляет гибридный подход, что делает его популярным в высоконагруженных средах.

Заключение

Системы управления конфигурациями прошли долгий путь от первых разработок в 1990-х годах до современных решений, таких как Ansible, Puppet, Chef и SaltStack. Каждое из этих решений обладает своими особенностями и преимуществами, которые делают их подходящими для определённых задач и сред. Выбор инструмента, как это часто бывает, зависит от потребностей, инфраструктуры и уровня требований к управлению🤵‍♂️.

В ближайшее время на сайте Вороний блог выйдет вводная заметка по установке и начальной настройке системы управления конфигурациями – Ansible. Предпочтение данной CM отдано по очевидным причинам: описание конфигураций в удобном Yaml, при работе необходим лишь SSH и установленный Python на удаленном сервере. Хотя фактически можно обойтись из без Python, но это больше для гурманов🤪.

Обязательно подписывайтесь на наш телеграм канал @r4ven_me📱, чтобы не пропустить новые посты, а если возникли вопросы или просто есть желание поболтать про Linux и Open source – добро пожаловать в наш чат @r4ven_me_chat💬. У нас там вежливое микросообщество🤓.

Спасибо, что читаете!

Полезные источники

• Конфигурационное управление | Википедия
• Ansible | Википедия
• Puppet | Википедия
• Chef | Википедия
• SaltStack | Википедия
• Управление конфигурациями: Puppet vs. Chef vs. Ansible | Habr

Приветствую!

Заголовок получился кликбейтный😏, но сегодня речь действительно пойдет о моей сборке ПК с двухпроцессорной конфигурацией🧑‍💻. Будет много фоток и мало слов, погнали😉.

Присоединяйтесь к нашему каналу в телеграм: t.me/r4ven_me, уведомления о новых постах приходят туда в день публикации. А если у вас есть вопросы или просто желание пообщаться по тематике – заглядывайте в чат: t.me/r4ven_me_chat.

КРАСНАЯ ПЛАШКА
Пожалуйста, обратите внимание, что данная статья не является рекомендацией. Я лишь делюсь своим мнением и пережитым опытом. Будьте осторожны при покупке Б/У деталей, потому что всегда существует риск приобрести нерабочий экземпляр.

Зачем нужен двухпроцессорный ПК

TLDR: чтобы наблюдать такую радугу в системном мониторе😂:

Если серьезно, то основная причина вот:

Создание лабораторной среды на базе функционального гипервизора для проведения различных тестов и быстрого развертывания образов VM в т.ч. с использованием Cloud init. Тут мой выбор пал на популярное open source решение – Proxmox.

Несмотря на то, что в моем случае proxmox запускает ВМ в режиме паравиртуализации, все работает довольно шустро. Мне для тестов хватает с головой. Возможно в будущем сделаю заметку по этой теме📝.

В результате половину ресурсов получает мое графическое окружение (LMDE6 с Cinnamon), а другая половина отдана Proxmox👌.

Обзор комплектующих

Материнская плата

Atermiter Dual X99 2011-3 – производитель, как шутят мои друзья, цитата: “какое-то ху*ло”😂😂. Если что, то “мать покупалась на али”.

Характеристики:

• Сокет: 2011 v3
• Количество сокетов: 2
• Количество слотов памяти: 8
• Тип памяти: DDR4 DIMM
• Слоты PCI-E: 2 x PCI-E 3.0 x1, 2 x PCI-E 3.0 x16
• USB на плате: 1 x USB 3.2, 1 x USB 2.0
• Разъемы на задней панели: 4 x USB 2.0 Type-A, 4 x USB 3.2 Type-A, LAN RJ-45, PS/2 (клавиатура), PS/2 (мышь)
• Звук: AC’97
• Форм-фактор: EATX
• Слоты накопителей: 8 x SATA 6G, 2 x M.2 NVME (вероятно разных поколений)

ПроцессорЫ (Б/У)

2 штука Intel Xeon E5-2680V3 – не самые мощные для данного сокета, просто продавались в комплекте с мат. платой и памятью. Так было банально дешевле. Есть возможность “доумощниться” при необходимости😎.

Характеристики (на один процессор):

• Количество: 2 шт.
• Тех. процесс: 22 nm
• Ядер: 12
• Потоков: 24
• Базовая частота: 2500 MHz
• Максимальная частота в Turbo Boost:
• 3300 MHz (1-2 ядра)
• 3100 MHz (3 ядра)
• 2900 MHz (4 ядра)
• 2800 MHz (5 и больше ядер)
• Кэш 3-го уровня: 30 Mb
• Поддержка оперативной памяти DDR4: 2133 MHz
• TDP: 120 W

КулерЫ

Тут все просто. 2 китайские башни белого цвета – M-T4 Snowman

• Разъем питания: 4 pin
• Количество тепловых трубок: 4 шт
• Диаметр вентилятора: 120 мм
• Макс. оборотов: 1300 об/мин
• TDP: 150 Вт
• Макс. воздушный поток: 48 CFM

Оперативная память (Б/У)

Память от того же *йло сборщика – Atermiter. Скорее всего от этого вендора тут только радиаторы😁. Память серверная, а чьи чипы – хз.

Характеристики:

• Тип: DDR4
• Форм-фактор: DIMM
• Количество: 4 шт.
• Объем одного модуля: 16GB
• Частота: 3200 MHz (ага, а процессор только 2133)
• Особенности: серверная, ECC REG

Видеокарта (Б/У)

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

Выбор пал на Radeon rx 580 8gb, как самую распространенную и доступную в соотношении цена-качество. Вендор – написано, что XFX.

Характеристики:

• Питание видеокарты: 8 pin
• Видео разъемы: DisplayPort 3 шт., HDMI 1 шт., DVI-D 1 шт.
• Объем видеопамяти: 8192 Мб
• Тип видеопамяти: GDDR5
• Разрядность шины: 256 бит
• Потребляемая мощность: 150 Вт

Накопитель М2

Т.к. на плате есть 2 разъема под M.2 накопители, решил попробовать. Взял один из недорогих: ARDOR GAMING Ally AL1282 на 256 гб под систему. Тесты показывают совсем не те цифры, что заявлены. Но с чьей стороны косяк: материнки или SSD пока не определил.

Характеристики:

• Объем накопителя: 256 Gb
• Ключ разъема: M.2
• Интерфейс: NVMe
• Структура памяти: 3D NAND
• Макс. заявленная скорость чтения: 3000 Мб/сек
• Макс. заявленная скорость записи: 1300 Мб/сек
• Максимальный ресурс записи (TBW): 187.5 ТБ

Блок питания

БП – сердце компьютера, экономить на нем не рекомендую никогда. И уж точно я вас призываю НЕ ПОКУПАТЬ Б/У блоки питания!!! Это все таки ваша безопасность. Для меня тут выбор таков: Chieftec Silicon 850W [SLC-850C]. Мощности хватает с запасом.

Характеристики:

• Мощность (номинал): 850 Вт
• Форм-фактор: ATX
• Тип подключения: модульный
• Сертификат 80 PLUS: Bronze

Корпус

Мой предыдущий ПК тоже был в корпусе от “пумы” с отличной вентиляцией. Вот и в этот раз решил взять от них, только разумеется побольше габаритами из-за высоких кулеров – Cougar Duoface Pro RGB [CGR-5AD1B-RGB]. Ну и конечно “нетрадиционной ориентации” подсветка с множеством цветов. Я изначально хотел белый.

Характеристики:

• Типоразмер корпуса: Mid-Tower
• Вентиляторы в комплекте: 4 x 120 мм
• Тип подсветки: ARGB
• Материал окна: каленое стекло
• Разъемы: Jack 3.5, 2 x USB 3.1, 1 x USB 2.0, 1 x USB Type C (которого на плате нет😔)

Даже есть какой-то кэйбэл мэнэджмэнт по умолчанию😎

Сборка

Начинаем собирать:

И сталкиваемся с такой не приятной ситуацией:

В моем случае это не критично, поэтому “напилингом” я решил не заниматься. Работает и так, но в итоге местами плашки я все же поменял.

Запихиваем все добро в корпус:

Добавляем щепотку специй видеокарту:

Ну, стартуем!!!

И..

Разумеется с первого раза ничего не запустилось😳. Благо на мат. плате есть маленький дисплей отображающий POST коды запуска, которые легко гуглятся. Трабла: Б/Ушная память решила “повыделываться”. Но, имея некоторый опыт, я обратился за квалифицированной помощью к специалисту.

Встречайте:

Перетёр с ним за контакты оперативки и все завелось😁.

После сборки логичным этапом идет установка ОС. Скачал последний Linux Mint Debian Edition 6 и накатил. А пока сей недолгий процесс шел, решил выпить чаю☕️. Еще и скучный интернешнл шел тогда📺.

Итоговый результат

В результате получился вот такой Devil Machine😈😈😈:

Немного Hardinfo уже в ОС:

Что почём?

Вот такой прайс у меня получился в 2024 году:

• Мат. плата + процы + память: 15200 р.
• 2 кулера: 2200 р.
• Видеокарта: 8860 р.
• SSD 256GB: 2850 р.
• Блок питания: 10450 р.
• Корпус: 8500 р.

Итого: 48 060 р.

Скажу, что на сегодня это нормально. Можно сказать экономно💰, даже с учетом рисков (все таки часть деталей Б/У).

Заключение

Мое мнение по итогу: доволен как слон. Конечно при сборке были некоторые нюансы, в основном с оперативкой, но все завелось и работает. Я уже активно пользуюсь поднятым Proxmox для своих задач и различных тестов😎. Надеюсь машинка будет отлично работать и впредь😌. Это был интересный опыт.

Если у вас появились вопросы или желание пообщаться по теме – приглашаю в наш Вороний чат💬 в телеге. И обязательно подписывайтесь на наш канал @r4ven_me📱 там же, чтобы не пропустить новые посты на сайте Вороний блог.

Спасибо, что читаете. Желаю только работающих сборок😉.

Приветствую!

В данной инструкции мы с вами развернем популярную систему мониторинга Zabbix с использованием TimescaleDB – плагина для БД PostgreSQL, позволяющего эффективно работать с “временнЫми рядам”. Все это добро мы завернем внутрь docker контейнеров 🐳. Будет интересно 😉.

Напомню, что в одной из прошлых заметок мы обсуждали, что такое системы мониторинга в IT, какие виды бывают и немного узнали о популярных реализациях на сегодняшний день, среди которых – Zabbix.

Присоединяйтесь к нашему каналу в телеграм: t.me/r4ven_me, уведомления о новых постах приходят туда в день публикации. А если у вас есть вопросы или просто желание пообщаться по тематике – заглядывайте в чат: t.me/r4ven_me_chat.

Сразу прошу обратить внимание на то, что все действия описанные в данном руководстве вы делаете на свой риск и ответственность. Прошу это понимать. Мой блог – лишь площадка, где я рассказываю про свой опыт и делюсь своим мнением по каким-либо вещам и явлениям. Спасибо за понимание.Иван Чёрный

Введение

Особенностью инсталяции, описываемой в этой статье является не только развертывание системы мониторинга Zabbix в docker контейнерах, но и использование ее в связке с базой данных временных рядов – TimescaleDB.

Прежде чем мы начнем, давайте дадим несколько определений в качестве введения.

Zabbix — это открытая платформа для мониторинга сетей и серверов. Для хранения данных использует реляционные СУБД, например: PostgreSQL, MySQL, MariaDB, Oracle, SQLite и т.д.

Временные ряды в базах данных (time series) — это набор данных, упорядоченных по времени, где значения регистрируются через равные или неравные интервалы времени.

Базы данных временных рядов (time series database) — это специализированные базы данных, предназначенные для эффективного хранения, управления и анализа временных рядов. Часто это no sql базы данных.

TimescaleDB (TSDB) — это расширение для PostgreSQL, которое оптимизирует работу с временными рядами в данной СУБД, сохраняя при этом всю мощь и гибкость классических SQL like баз данных. С определенного времени Zabbix научился работать с данной СУБД.

Цитата из официальной документации Zabbix:

Zabbix supports TimescaleDB, a PostgreSQL-based database solution of automatically partitioning data into time-based chunks to support faster performance at scale.Zabbix.com

Для лучшего понимания причины выбора именно такой связки, рекомендую статью на Habr: Zabbix, временные ряды и TimescaleDB.

Прошу вас также обратить внимание на предупреждение из оф. документации Zabbix:

Warning: Currently, TimescaleDB is not supported by Zabbix proxy.Zabbix.com 09.2024

Уверен, что в будущем это поправят. А пока хватит трепа, переходим к делу🤵‍♂️.

Подготовка

Разворачивать Zabbix будем в среде дистрибутива Debian 12 💿 с установленным Docker engine 🐳. Если у вас еще нет готового Linux сервера, то рекомендую мои предыдущие статьи:

• Установка сервера Debian 12 в VirtualBox
• Начальная настройка Linux сервера на примере Debian
• Установка Docker engine на Linux сервер под управлением Debian

Также для дальнейшей работы нам понадобится пользователь с правами root.

Установка необходимых утилит

Сегодня нам понадобятся утилиты для взаимодействия с веб. Открываем терминал и устанавливаем систему контроля версий git и утилиту curl:

sudo apt update && sudo apt install -y git curl

Скачивание файлов проекта

Все файлы проекта находятся в моем репозитории на GitHub. Клонируем его с помощью установленной ранее утилиты git по пути /opt/zabbix:

sudo git clone https://github.com/r4ven-me/zabbix /opt/zabbix

Описание файлов проекта:

docker-compose.yml – файл описания сервисов, запускаемых в docker контейнерах:

Секция NETWORK – определяет две виртуальные сети docker:

• zbx_net_backend – изолированная сеть для взаимодействия контейнеров postgres-server, zabbix-server, zabbix-web и zabbix-agent;
• zbx_net_frontend – сеть с доступом к контейнерам со стороны хостовой ОС: для контейнеров zabbix-server и zabbix-web.

Секция SERVICES – определяет параметры запускаемых сервисов/контейнеров:

• postgres-server – сервис СУБД TimescaleDB;
• zabbix-server – сервис Zabbix сервера;
• zabbix-web – сервис веб интерфейса для Zabbix сервера (под капотом nginx + php-fpm);
• zabbix-agent – сервис агента Zabbix для сбора метрик с самого сервера Zabbix.

Секция SECRETS – определяет файлы, содержащие чувствительную информацию, которые прокидываются внутрь контейнеров postgres-server, zabbix-server и zabbix-web:

• POSTGRES_USER (файл ./env/.POSTGRES_USER) – имя пользователь для базы данных Zabbix в СУБД TimescaleDB;
• POSTGRES_PASSWORD (файл ./env/.POSTGRES_PASSWORD) – соответственно, пароль пользователя.

env – директория с файлами, содержащие переменные окружения, значения которых передаются внутрь контейнера при его запуске:

• .env_db – параметры для postgres-server;
• .env_srv – параметры для zabbix-server;
• .env_web – параметры для zabbix-web;
• .env_agent – параметры для локального zabbix-agent;
• .POSTGRES_PASSWORD – пароль пользователя в БД zabbix;
• .POSTGRES_USER – имя пользователя в БД zabbix.

src – директория с исходными файлами для сборки кастомного контейнера zabbix-server с расширенным функционалом:

• alertscripts – директория с файлами для отправки уведомлений в Telegram:
• docker-entrypoint.sh – скрипт подготовки окружения внутри контейнера (не изменялся);
• Dockerfile – кастомизированный файл описания сборки образа;
• externalscripts – директория со скриптом мониторинга делегирования домена.

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

Создание сервисного пользователя zabbix

В целях безопасности создаем ограниченные в правах группу и сервисного пользователя для запуска контейнеров zabbix:

sudo addgroup --system --gid 1995 zabbix

sudo adduser --system --gecos "Zabbix monitoring system" \
    --disabled-password --uid 1997 --ingroup zabbix  \
    --shell /sbin/nologin --home /opt/zabbix/zabbix_data zabbix

adgroup – команда создания группы;

• --system – помечает группу, как системную и применяет к ней установленные политики;
• --gid 1995 – указывает явный идентификатор группы (GID) – в данном случае 1995 (именно такой GID задают разрабы Zabbix в своих контейнерах);
• zabbix – название создаваемой группы;

adduser – команда создания пользователя

• --system – помечает группу, как системную и применяет к ней установленные политики;
• --gecos – позволяет задать описание пользователя;
• --disabled-password – отключает пароль у пользователя (в таком случае под ним нельзя авторизоваться в системе с помощью пароля);
• --uid 1997 – указывает явный идентификатор пользователя (UID) – в данном случае 1997 (именно такой UID задают разрабы Zabbix в своих контейнерах);
• --ingroup zabbix – добавляет пользователя в созданную ранее группу zabbix;
• --shell /sbin/nologin – в качестве оболочки пользователя устанавливает nologin – под ней невозможно авторизоваться в системе;
• --home /opt/zabbix/zabbix_data – задает домашний каталог пользователя, в нашем случае это директория с файлами сервисов zabbix;
• zabbix – имя создаваемого пользователя.

Создание сервисного пользователя postgres

Теперь аналогичным образом создаем группу и пользователя для запуска контейнера TimescaleDB:

sudo addgroup --system --gid 70 postgres

sudo adduser --system --gecos "PostgreSQL database" \
    --disabled-password --uid 70 --ingroup postgres  \
    --shell /sbin/nologin --home /opt/zabbix/postgres_data postgres

Проверяем наличие всех нужных файлов и папок:

ls -l /opt/zabbix

Отлично, идем дальше 🚶.

Создание пароля для базы данных Postgres

По умолчанию в файле /opt/zabbix/env/.POSTGRES_PASSWORD я задал для БД zabbix одноименный пароль. Но крайне рекомендую сгенерировать новый, например такой командой:

tr -cd "[:alnum:]" < /dev/urandom | head -c 30 \
    | sudo tee /opt/zabbix/env/.POSTGRES_PASSWORD

Команда tr -cd с помощью механизма перенаправления стандартных потоков получает на ввод латинские буквы и цифры (класс символов [:alnum:]), генерируемые псевдоустройством /dev/urandom. Затем команда head, получая данные по конвейеру, с помощью ключа -c отбирает 30 первых символов (байт). И в конце, полученная псевдорандомная строка передается на ввод команде tee, запущенной от имени суперпользователя. Полученные данные tee записывает в указанный файл (/opt/zabbix/env/.POSTGRES_PASSWORD) и дублирует вывод в стандартный поток (stdout).

Не обращайте внимания на символ % в конце строки моего примера. Это особенность командной оболочки ZSH, которая выводит его (или # для root) при отсутствии символа перевода строки.

Запуск Zabbix стека с помощью docker compose

Старт Postgres сервера

Первым запускаем сервер СУБД, такой командой:

sudo docker compose -f /opt/zabbix/docker-compose.yml up -d postgres-server

После загрузки образа и запуска контейнера смотрим его вывод:

sudo docker logs -f postgres-server

При успешном запуске, вы увидите подобное:

При первом старте, внутри контейнера выполняются скрипты подготовки окружения и базовой конфигурации СУБД в зависимости от параметров сервера. В одном из моих тестов такой скрипт выставлял параметр max_connections равным 25 – чего недостаточно даже для импорта схемы БД zabbix и процесс выпадет в ошибку:

FATAL:  sorry, too many clients already

Проверить значение max_connections можно такой командой:

sudo grep 'max_connections' /opt/zabbix/postgres_data/postgresql.conf

Если у вас <=25, то этот параметр необходимо увеличить. Открываем файл на редактирование любым консольным редактором, например, Vim/Neovim 😎:

sudo vim /opt/zabbix/postgres_data/postgresql.conf

Находим там строку:

max_connections = 25

И меняем ее, например, на:

max_connections = 200

Сохраняем файл, выходим из редактора.

Для применения изменений перезапускаем контейнер postgres-server и проверяем текущее значение max_connections:

sudo docker compose -f /opt/zabbix/docker-compose.yml restart postgres-server

sudo docker exec -it postgres-server psql -U zabbix -c "SHOW max_connections;"

Все применилось, переходим к запуску контейнера zabbix-server.

Старт Zabbix сервера

Запускаем его такой командой:

sudo docker compose -f /opt/zabbix/docker-compose.yml up -d zabbix-server

Смотрим вывод контейнера:

sudo docker logs -f zabbix-server

При первом запуске, котейнер запустит создание базы. Это займет некоторое время. Вывод остановится на такой строке:

Creating 'zabbix' schema in PostgreSQL

Обязательно дождитесь завершения процедуры создания БД!

При успешном запуске вы должны увидеть что-то подобное:

Возможно в самом конце будет вывод, подобный этому:

256:20240922:121849.602 Zabbix agent item "system.cpu.util[,system]" on host "Zabbix server" failed: first network error, wait for 15 seconds
225:20240922:121855.944 item "Zabbix server:zabbix[vmware,buffer,pused]" became not supported: No "vmware collector" processes started.
225:20240922:121858.958 item "Zabbix server:zabbix[process,report writer,avg,busy]" became not supported: No "report writer" processes started.
225:20240922:121859.962 item "Zabbix server:zabbix[process,report manager,avg,busy]" became not supported: No "report manager" processes started.
256:20240922:121904.599 Zabbix agent item "system.users.num" on host "Zabbix server" failed: another network error, wait for 15 seconds
256:20240922:121919.602 Zabbix agent item "system.cpu.load[all,avg5]" on host "Zabbix server" failed: another network error, wait for 15 seconds
225:20240922:121928.010 item "Zabbix server:zabbix[connector_queue]" became not supported: connector is not initialized: please check "StartConnectors" configuration parameter
225:20240922:121929.016 item "Zabbix server:zabbix[process,connector manager,avg,busy]" became not supported: No "connector manager" processes started.
225:20240922:121930.021 item "Zabbix server:zabbix[process,connector worker,avg,busy]" became not supported: No "connector worker" processes started.
256:20240922:121934.600 temporarily disabling Zabbix agent checks on host "Zabbix server": interface unavailable

Не обращаем на него внимания.

Проверяем статус запущенных контейнеров:

sudo docker ps

Все ок – идем дальше.

Создание схемы для TimescaleDB

Выводим созданный ранее пароль в терминал, скоро он нам понадобится. Затем подключаемся к оболочке контейнера zabbix-server:

sudo cat /opt/zabbix/env/.POSTGRES_PASSWORD

sudo docker exec -it zabbix-server bash

Теперь импортируем схему TimescaleDB с помощью SQL скрипта, который разработчики Zabbix любезно положили в системные файлы. При вводе команды импорта у нас запросят пароль от БД, который мы вывели на предыдущем шаге:

psql -h postgres-server -U zabbix zabbix < /usr/share/doc/zabbix-server-postgresql/timescaledb.sql

Процесс импорта представляет собой простое перенаправление содержимого SQL скрипта на вводе команды подключения к БД с помощью psql.

Вывод должен быть таким:

Выходим из контейнера zabbix-server и проверяем наличие информации о чанках (chunks) в Postgres:

exit

sudo docker exec -it postgres-server \
    psql -U zabbix -c "SELECT * FROM chunks_detailed_size('history')"

Если вывод у вас такой же, как на скрине выше, то все импортировалось успешно 🥳.

На этом этапе БД Postgres/TimesacleDB и Zabbix сервер готовы 😉.

Старт всего стека TimesacleDB + Zabbix server + Zabbix web + Zabbix agent

Останавливаем запущенные контейнеры и запускаем всю инсталляцию, включая Zabbix web и Zabbix agent:

sudo docker compose -f /opt/zabbix/docker-compose.yml down

sudo docker compose -f /opt/zabbix/docker-compose.yml up -d

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

sudo docker ps

sudo docker compose -f /opt/zabbix/docker-compose.yml logs -f

Отлично. Теперь проверим работу самого Zabbix:

curl -I http://localhost:8080

nc -zv localhost 10051

ss -tulnap | grep -E '8080|10051'

Первой командой мы проверили доступность веб интерфейса из консоли, второй – доступность порта zabbix-server, а третьей вывели порты, прослушиваемые хостовой ОС.

Отлично, все работает 🎉🎉🎉.

Доступ к веб интерфейсу Zabbix

Способ получения доступа к веб интерфейсу Zabbix зависит от условий, в которых вы разворачивали стек. Я опишу несколько очевидных вариантов.

1) Если Zabbix сервер развернут на локальной машине

Просто вбейте в браузере URL 😁😁😁:

http://127.0.0.1:8080/

2) Если Zabbix сервер развернут на удаленном сервере, который находится в локальной или VPN сети

В таком случае отредактируйте настройки сети для сервисов zabbix-server и zabbix-web в docker-compose.yml файле.

Например, внутренний адрес моего сервера в сети VPN: 192.168.122.24. Правлю docker-compose.yml:

sudo vim /opt/zabbix/docker-compose.yml

zabbix-server:

zabbix-web:

Перезапускаю все контейнеры:

sudo docker compose -f /opt/zabbix/docker-compose.yml down

sudo docker compose -f /opt/zabbix/docker-compose.yml up -d

sudo docker ps

На подключенном к VPN сети клиенте открываю в браузере такой URL:

http://192.168.122.24:8080/

3) Если Zabbix сервер развернут на удаленном сервере и не подключен к локальной или VPN сети

При таком раскладе можно прокинуть SSH порт либо открыть доступ напрямую или через обратный прокси, наподобие nginx. Я рассмотрю лишь первый случай, как самый простой. А еще потому, что два других выходят за рамки данной статьи 😜.

На клиенте открываем терминал и выполняем:

ssh -L 8080:127.0.0.1:8080 user@example.com

Где (по порядку):

• -L – ключ перенаправления локального порта;
• 8080 – порт, который будет слушать клиентская машина и перенаправлять его на 8080 порт сервера;
• 127.0.0.1 – адрес сервера, на котором он слушает порт;
• 8080 – соответственно порт, на который перенаправляем;
• user@example.com – пользователь и адрес SSH сервера.

В моём примере команда такая:

Теперь открываем браузер и переходим по адресу: http://127.0.0.1:8080/

Доступ к веб интерфейсу будет пока открыта SSH сессия.

Для авторизации в веб интерфейсе используйте стандартные логин: Admin и пароль: zabbix

Если вы увидели такое:

Мои поздравления 😎! Zabbix сервер с TimescaleDB поднят и готов к работе 👷‍♂️.

Опционально

Чтобы не раздувать статью, ниже приведены ссылки на необязательные, но рекомендованные шаги инструкции 😉 на моем сайте r4ven.me.

• Минимальная начальная настройка Zabbix сервера
• Настройка автозапуска Zabbix стека с systemd
• Установка и запуск Zabbix agent в docker на удаленном хосте
• Настройка отправки уведомлений Zabbix в Telegram с графиком

Заключение

Фух..🤯 это была не самая простая статья. Особенно по объему перелопаченной информации. Но, мне кажется, оно того стоило. В итоге мы получили гибкий и легко переносимый проект системы мониторинга, работающий внутри docker контейнеров. А также мы настроили лаконичные, но информативные уведомления с графиками в Telegram, чтобы всегда быть в курсе состояния нашей инфраструктуры.

Хочется также отметить великолепную работу разработчиков Zabbix. В частности, актуальность и разнообразие docker образов и доступность файлов их сборки. После написания этой статьи, я их зауважал еще больше 👍.

Спасибо, что читаете 😊. Если возникли вопросы – приглашаю вас в Вороний чат, как вы догадались, в телеге 😅. У нас там дружное сообщество 🚶‍♀️🐧🚶🐧🚶‍♂️🐧. И обязательно подписывайтесь на основной телеграм канал: @r4ven_me, чтобы не пропустить публикации новых материалов на сайте.

Желаю успехов и нападающего прода! 😌

Используемые материалы

• Мой репозиторий zabbix сервера | GitHub
• Мой репозиторий zabbix агента | GitHub
• Временной ряд | Википедия
• Zabbix, временные ряды и TimescaleDB | Habr
• Использование TimescaleDB с Zabbix | Zabbix.com (EN)
• Исходные файлы docker, которые я адаптировал | GitHub
• Реестр docker образов TimescaleDB | Dockerhub
• Описание docker образа PostgresSQL | Dockerhub
• Исходные файлы docker образов TimescaleDB | GitHub
• Описание docker образа Zabbix server | Dockerhub
• Описание docker образа Zabbix web | Dockerhub
• Описание docker образа Zabbix agent | Dockerhub
• Исходный Dockerfile для Zabbix server | GitHub
• Исходные файлы Zabbix Notification Telegram | GitHub
• Описание работы скрипта Zabbix Notification Telegram | GitHub
• Инструкция по установке Zabbix Notification Telegram | GitHub

Приветствую!

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

Присоединяйтесь к нашему каналу в телеграм: t.me/r4ven_me, уведомления о новых постах приходят туда в день публикации. А если у вас есть вопросы или просто желание пообщаться по тематике – заглядывайте в чат: t.me/r4ven_me_chat.

Хочу отметить, что этот теоретический пост📕 предшествует будущей статье по развертыванию Zabbix + TimescaleDB в контейнерах Docker🐳.

В статье я буду использовать аббревиатуру СМ – сокр. система мониторинга.

Вместо введения: зачем нужны системы мониторинга?

TLDR: чтобы не делать так 😁

А если серьезно, ниже представлен перечень задач, которые решают СМ📊:

1. Сбор метрик: сбор данных о производительности элементов инфраструктуры, таких как загрузка CPU, RAM, DISK и множество других;
2. Обнаружение неисправностей: своевременная идентификация проблем позволяет администраторам и разработчикам быстрее их устранить;
3. Отправка уведомлений: почти все системы мониторинга, имеет в своем арсенале функционал отправки уведомлений по различным каналам связи (email, мессенджеры, SMS и др.) в случае обнаружения проблем;
4. Расширенная аналитика: СМ собирает и хранит множество данных, анализ которых помогает выявить узкие места и улучшить производительность системы;
5. Снижение времени простоя: очевидно, мониторинг позволяет заранее обнаружить деградацию сервисов и предотвратить серьезные сбои.

Виды систем мониторинга

Теперь немного о том, какие основные виды систем мониторинга существуют📋:

• Мониторинг инфраструктуры – отслеживает состояние серверов, сетевых устройств, баз данных и других компонентов ИТ-инфраструктуры. Примеры СМ: Nagios, Zabbix.
• Мониторинг приложений – следит за состоянием приложений и их производительностью на уровне кода, выявляя узкие места и проблемы в работе ПО. Примеры СМ: New Relic, AppDynamics.
• Мониторинг журналов – анализирует логи приложений и систем для выявления ошибок, сбоев и аномальных действий. Примеры СМ: Elasticsearch, Logstash, Kibana (ELK Stack).
• Мониторинг сетевого трафика – предназначен для отслеживания сетевой активности, анализа пропускной способности и поиска аномалий в сетевом трафике. Пример: SolarWinds, Wireshark.
• Облачный мониторинг – инструменты, специально предназначенные для мониторинга облачных ресурсов и их инфраструктуры. Примеры СМ: Amazon CloudWatch, Google Cloud Monitoring.

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

Теперь рассмотрим некоторые популярные Open source решения из категории СМ, а также коротко пробежимся по их преимуществам и недостаткам.

1. Zabbix

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

Плюсы:

• Бесплатный и с открытым исходным кодом.
• Гибкая настройка под любые нужды (просто комбайн в мире СМ).
• Поддержка большого количества метрик.

Минусы:

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

2. Prometheus

Prometheus — это мощная система для мониторинга и алертинга с открытым исходным кодом, широко используемая в среде DevOps. Она ориентирована на сбор метрик и поддерживает специальный язык запросов PromQL.

Плюсы:

• Высокая скорость обработки данных.
• Идеально подходит для динамических облачных сред.
• Простая интеграция с системами контейнеризации, такими как Kubernetes.

Минусы:

• Ограниченные возможности работы с логами.
• Сложности при хранении данных на длительный срок.

3. Grafana

Grafana — это open source инструмент для визуализации данных из различных источников мониторинга. Часто используется в связке с Prometheus для создания наглядных дашбордов. Также из коробки имеет функционал отправки уведомлений.

Плюсы:

• Поддержка множества источников данных (Prometheus, InfluxDB, ElasticSearch, Zabbix и др.).
• Гибкие и детальные дашборды.

Минусы:

• Самостоятельно не собирает данные (нужен источник).
• Требует навыков настройки графиков/дашбордов.

4. Nagios

Nagios — одна из старейших и наиболее известных систем мониторинга, ориентированная на мониторинг серверов, сетей и приложений. Также имеет открытый исходный код.

Плюсы:

• Широкая поддержка плагинов.
• Подходит для небольших и средних сетей.

Минусы:

• Сложность настройки для начинающих.
• Ограниченная масштабируемость.

Заключение

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

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

Цель данной заметки, дать читателю общее представление о СМ и их назначении. В ближайшем будущем в Вороньем блоге появится статья, по развёртыванию в Docker одной из популярных open source СМ – Zabbix, изначально написанной Алексеем Владышевым.

Чтобы не пропустить новые посты – подписывайтесь на наш телеграм канал @r4ven_me📱, а если возникли вопросы или просто есть желание “перетереть за опенсорс” – заглядывайте в наш чат @r4ven_me_chat💬.

Полезные источники

• Zabbix | Википедия
• Prometheus | ALT Linux Wiki
• Grafana | Википедия
• Nagios | Википедия
• Оригинал статьи | Вороний блог