По умолчанию, метрики в Prometheus попадают методом pull — система обращается к агентам (exporter) и забирает данные. Это рекомендованный способ, но мы можем настроить получение метрик методом push с помощью Pushgateway.
Схема работы следующая: метрика отправляется скриптом на сервер с помощью Pushgateway, а Prometheus забирает данные уже с него.
Предполагается, что у нас уже установлен сервер Prometheus.
Установку Pushgateway можно выполнить на тот же сервер, что и Prometheus, либо на выделенный. В этой инструкции установим на тот же и под управлением CentOS 7.
2. Установка Pushgateway.
Сервис может быть запущен в качестве контейнера Docker. Однако, в данном руководстве, будет вариант со скачиванием бинарного файла и созданием юнита для его автозапуска.
Переходим на официальную страницу загрузки Pushgateway.
-A INPUT -p tcp -m tcp --dport 9091 -m state --state NEW -j ACCEPT
Перезапускаем iptables:
# sudo systemctl restart iptables
Проверяем, что метрики отдаются:
# curl 'localhost:9091/metrics'
Открываем браузер и вводим адрес:
# http://<IP-адрес сервера pushgateway>:9091
Вы должны увидеть меню портала:
Pushgateway готов к работе.
Переходим к настройке Prometheus.
3. Настройка Prometheus.
Необходимо добавить задание в Prometheus для подключения к серверу Pushgateway и получения с него метрик. Это делается по такому же принципу, что и получение метрик с экспортеров.
Удалите все метрики во всех группах (требуется включить API администратора с помощью флага командной строки --web.enable-admin-api в конфигурации systemd):
# curl -X PUT http://localhost:9091/api/v1/admin/wipe
5. Отправка метрик методом скрипта на Python.
В качестве примера, рассмотрим скрипт, написанный на Python.
Для начала, необходимо установить модуль prometheus_client:
В данном примере мы отправим в Prometheus через Pushgateway метрику temperature_metrics со значением 22 и job-тегом temperature_lobby.
6. Практическое применение Pushgateway.
Для операционной системы CentOS 7 есть отличная утилита hddtemp — инструмент для измерения температуры жестких дисков. Она проста в использовании и установке.
В предыдущей статье мы настраивали Prometheus Server. Пришло время настроить красивое графическое отображение с помощью Grafana Server.
1. Установка программы.
Белые классические графики — это классика, а хочется, чтоб всё было как на приборной панели современного самолёта! Чтоб приборчики всякие и экраны красивые.
За такую красоту отвечает графическая оболочка Grafana Server. Его сейчас и поставим.
Официальная ссылка на руководство по установке и настройке Grafana от разработчика Prometheus: prometheus.io.
Всё можно поставить вручную или через репозиторий.
Установим файловый менеджер и текстовый редактор в одном лице — Midnight Commander:
# yum -y install mc
1.1. Установка через репозиторий.
Ссылка на установку репозитория от разработчика Grafana: grafana.com.
Если вы устанавливаете вручную с помощью YUM, то вам нужно будет вручную обновить Grafana для каждой новой версии.
Заходим на сайт разработчика Grafana: grafana.com.
В разделе установки этой графической оболочки ищем копируем ссылку на закачку пакета установщика с программой. В инструкции есть уже команда на закачку с правильной ссылкой. Используем ее.
Переместимся в папку пользователя под которым работаем:
# cd ~
Скачаем данный пакет установщика на сервер CentOS 7, в локальную папку пользователя:
Дополнительную информацию смотрите в руководстве по установке Centos 7. Кому привычнее ставить из репозитория, то имеется официальный репозиторий пакетов YUM от разработчика Grafana. Ссылки на подробные ресурсы упоминались выше по тексту инструкции.
2. Запуск системной службы.
Чтобы запустить службу и убедиться, что она запущена:
Настройка Grafana Server для запуска при загрузке CentOS 7:
# systemctl enable grafana-server.service
Убедимся, что всё стартовало успешно:
# systemctl status grafana-server
Ответ:
3. Основные компоненты.
Основные компоненты, которые могут пригодиться:
Бинарные файлы:
/usr/sbin/grafana-server
/usr/sbin/grafana-cli
Копии init.d скрипта:
/etc/rc.d/init.d
Конфигурационный файл:
/etc/grafana/grafana.ini
Сервис systemd с именем:
grafana-server
Расположение log-файла по умолчанию:
/var/log/grafana/grafana.log
Расположение sqlite3 database файла по умолчанию:
/var/lib/grafana/grafana.db
Теперь можно переходить к настройке Grafana Server в web-интерфейсе.
4. Открытие 3000 порта.
Web-интерфейс расположен по адресу http://localhost:3000/. Если вам потребуется сменить 3000 порт на свой, то это можно будет сделать в файлах конфигурации позднее.
-A INPUT -p tcp -m tcp --dport 3000 -m state --state NEW -j ACCEPT
Перезапускаем iptables:
# systemctl restart iptables
5. Отключение регистрации и анонимного доступа.
Grafana предоставляет параметры, позволяющие посетителям создавать собственные учетные записи и просматривать панели мониторинга без регистрации. Поскольку Grafana доступна в Интернете, это может повлечь риски для безопасности. Однако если Grafana недоступна в Интернете или не работает с конфиденциальными данными, вы можете не блокировать эти функции.
Если директива имеет значение true, она добавляет на экран входа в систему кнопку Sign Up, что позволяет пользователям регистрироваться и получать доступ к Grafana.
Значение false удаляет кнопку Sign Up и повышает безопасность и конфиденциальность Grafana.
Если вы не хотите разрешать анонимным посетителям регистрироваться, раскомментируйте эту директиву, удалив точку с запятой в начале строки, а затем установите значение false.
Значение true в этой директиве дает незарегистрированным пользователям возможность получить доступ к вашим панелям мониторинга. Значение false ограничивает доступ, и панели мониторинга смогут использовать только зарегистрированные пользователи.
Если вы не хотите разрешать анонимный доступ к панелям мониторинга, раскомментируйте эту директиву, а затем установите значение false.
Чтобы убедиться, что все работает, проверьте состояние Grafana:
# systemctl status grafana-server
Как и раньше, в выводе вы увидите active (running).
Если это не так, просмотрите сообщения терминала для получения дополнительной справки.
На данный момент Grafana полностью настроена и готова к использованию.
6. Grafana Server web-интерфейс.
Проследуем:
# http://IP-адрес:3000/
Если вы видите кнопку Sign Up или можете анонимно войти в систему, повторите предыдущие действия, чтобы устранить проблему, прежде чем продолжить работу.
Если кнопки Sign Up нет, то можете смело продолжать настройку дальше.
По умолчанию логинadmin и пароль тоже admin.
После первого успешного ввода технического пароля и логина, Grafana Server предложит вам придумать и ввести свои рабочий пароль.
Воспользуемся этим и поменяем пароль на свой.
Внимание! Потом не забудьте поменять логин администратора Grafana Server и настроить анкету учетной записи администратора, настроить электронную почту, название организации и прочие мелочи.
Проходим дальше и попадаем в графическую инструкцию тех шагов, которые потребуется выполнить, чтобы начать пользоваться Grafana. Обратите внимание на верхнюю строку с пиктограммами, там отображается путь того, что нужно настроить для успешного ввода в эксплуатацию графической оболочки Grafana Server.
Чтобы начать что-то мониторить, нам нужен источник данных. Нажимаем Add data source.
Попадаем в меню выбора источников данных Grafana Server. Так как у нас уже установлен Prometheus Server, то пришло время их связать вместе в единый комплекс.
Примечание: Каждый сервер Prometheus – отдельный источник данных. Чтобы добавить несколько серверов Prometheus, нужно повторить инструкции данного раздела.
Здесь же в анкете есть вкладка Dashboards — это заранее сделанные для нас панели мониторинга от разработчиков Grafana. Позднее вы сами можете добавить или разработать свои панели мониторинга. Добавлять то, что предлагается в настройке по умолчанию не надо. Далее по инструкции мы добавим отличную панель Node Exporter Full.
Вернемся в анкету Settings, которую следует заполнить согласно тем параметрам, которые мы указывали для Prometheus Server по тексту инструкции выше. Возвращаемся на вкладку Settings и нажимаем кнопку зеленую кнопку Save & Test. Если все параметры введены верно, то тест будет пройден исправно и сохранение параметров засчитывается.
6.1. Создание панели мониторинга.
Для начала мониторинга, логично, создадим Панель мониторинга:
1. Нажмите кнопку Home —> New dashboard.
2. Нажмите кнопку Add Query. Grafana создает базовую графическую панель со сценарием Random Walk. Заполним анкету запросов по образцу из картинки. Источником Query выберем наш Prometheus Server. В качестве запроса используем запрос node_memory_MemFree_bytes.
Сохраните приборную панель. Щелкните значок дискетки Save dashboard в верхнем правом углу экрана.
Важно! Нажмите кнопку Save в верхнем меню, чтобы сохранить новый дашборд в Grafana. В противном случае дашборд исчезнет из настроек после обновления браузера.
Поздравляю, вы начали что-то измерять с Grafana! У вас есть панель мониторинга и отображаются результаты. Не стесняйтесь экспериментировать с тем, что вы построили, продолжать добавлять другие источники данных.
Если вы знаете что вам нужно, создайте свою панель мониторинга. Если еще не знаете, предлагаю подключить готовые.
6.2. Подключение готовой панели мониторинга.
Для Grafana есть специальный портал, где можно бесплатно скачать готовые панели мониторинга под любые нужды и под любые запросы.
Среди них есть она очень полезная панель. Называется она Node Exporter Full. В ней есть мониторинг всех важных параметров сервера.
Проследуем по ссылке на портале до Node Exporter Full: grafana.com.
Скачаем файл последней ревизии с панелью мониторинга Node Exporter Full. После скачивания файл будет называться node-exporter-full_rev16.json.
Теперь этот файл импортируем в Grafana.
Выходим на Главную страницу приветствия —> нажимаем Home:
Выбираем импорт панели Import dashboard:
Переходим в окно импорта и нажимаем Upload .json file и импортируем файл node-exporter-full_rev16.json.
Заполняем анкету панели своими данными и подключаем свой сервер для мониторинга по аналогии:
Нажимаем Import и панель мониторинга начинает отображать метрики нашего Prometheus Server:
Внимание! Панель мониторинга может минут 5 ничего не отображать или отображать что-то частично. Ничего страшного. Просто подождите пока все метрики наработают свою базу данных, чтобы вам что-то начать показывать на графиках. Через некоторое время зайдите в панель мониторинга и все панельки будет отображать информацию исправно.
Слева у каждой подпанели есть значок «птичка-галочка» (слева от начала заголовка каждой вкладки) за который можно свернуть или развернуть нужную вкладку общей панели мониторинга.
После всего этого нажимаем значок дискеты Сохранить (1) и наша панель мониторинга будет сохранена и привязана к Prometheus Server. Пометим ее в закладки значком Звездочки (2). Выйдем на Главную страницу (3) экрана приветствия Grafana Server.
Теперь у нас организован мониторинг основных параметров сервера на котором развернуты Prometheus Server с графической оболочкой Grafana Server.
Как ботать дальше с этими системами можно легко узнать в Интернете. Информации очень много. Системы достаточно популярные.
Если что-то появится интересное, то я обязательно добавлю эти готовые решения на свой сайт и ссылку на них в эту инструкцию.
7. Grafana Server через Nginx.
Если на сервере установлен Nginx и имеется доменное имя, можно пробросить пробросить через него вход в интерфейс Grafana Server.
Как его модифицировать и усилить вы можете почитать в руководствах для Nginx.
Перезапустим Nginx:
# systemctl restart nginx
Заходим в браузере:
# https://grafana-server.name.ru
8. Сброс до заводских настроек.
Для того, чтобы сбросить Grafana Server до заводских настроек, достаточно удалить файл grafana.db, в каталоге /var/lib/grafana.
После этого нужно будет заново настраивать администратора, учетные записи и источники данных. Вы получите полностью голую и чистую систему.
# rm -Rf /var/lib/grafana/grafana.db
Перезапустите Grafana:
# sudo systemctl restart grafana-server
Теперь при входе в Grafana Server вы должны будете проходить все этапы настройки заново.
9. Смена порта программы по умолчанию.
По умолчанию программа использует 3000 порт. Но его можно легко поменять в главном файле настроек программы grafana.ini в каталоге /etc/grafana.
Откройте главный конфигурационный файл Grafana:
# mcedit /etc/grafana/grafana.ini
Найдите директиву http_port под заголовком [server].
[server]
...
# The http port to use
;http_port = 3000
...
Расскоментируйте ее и внесите правки номера своего порта:
[server]
...
# The http port to use
http_port = 3333
...
Сохраните и закройте файл.
Перезапустите Grafana:
# sudo systemctl restart grafana-server
Чтобы убедиться, что все работает, проверьте состояние Grafana:
# sudo systemctl status grafana-server
Как и раньше, в выводе вы увидите active (running).
Прежде чем переходить в web-интерфейс Grafana по новому порту не забудьте открыть новый порт, а так же внести правки в конфигурацию Nginx, иначе web-интерфейс будет недоступен.
Проследуем:
# http://IP-адрес:3333/
10. Список доступных метрик.
Список доступных метрик можно найти по ссылке:
# http://<your_server_ip>:9090/metrics
Все эти метрики можно скопировать и вставить в редактор запросов Grafana.
Чтобы изменения настроек вступили в силу, нужно сохранить дашборд.
Задача: организовать мониторинг серверов и микросервисов, в режиме реального времени нужно отслеживать как состояние отдельных компонентов, так и состояние системы в целом.
2. Описание программ.
Prometheus server — центральное звено.Prometheusявляется открытой time series СУБД, написанной на языке Go и изначально разработанной в компании SoundCloud. Другими словами, эта штука хранит ваши метрики. Интересной особенностью Prometheus является то, что он сам тянет метрики с заданного множества сервисов (делает pull). За счет этого у Prometheus не могут забиться какие-то там очереди или вроде того, а значит мониторинг никогда не станет узким местом системы. Также проект интересен тем, что он принципиально не предлагает какого-либо горизонтального масштабирования или high availability. Дескать, третье тысячелетие на дворе — в случае чего просто возьмите машину помощнее, не выпендривайтесь.
Агенты, собирающие метрики и предоставляющие их в понятном для Prometheus’а виде. В зависимости от контекста называются экспортерами (exporter) или таргетами (target). Устанавливаются на целевые машины. Типичный представитель — Node Exporter — собирает данные о вычислительных ресурсах: загрузку процессора, памяти, диска и так далее. Есть куча других экспортеров. Например, cadvisor собирает данные о контейнерах. Есть экспортеры для Postgres’а, для Nginx’а и прочих сервисов. С точки зрения самого Prometheus’а они ничем принципиально не отличаются друг от друга, просто каждый собирает какие-то свои метрики. Можно писать свои экспортеры, если ничего из готового вам не подходит.
Node Exporter — сервис, задача которого заключается в экспорте информации о машине в формате, понятном Prometheus’у. Вообще, для Prometheus написано множество готовых exporter’ов практически под все существующие системы — всякие там web-серверы, СУБД, очереди сообщений, и так далее. В рамках этой заметки мы будем использовать только Node Exporter. Настройка других exporter’ов вряд ли будет сильно отличаться.
Alertmanager — менеджер уведомлений. Ни один инструмент мониторинга немыслим без компонента для рассылки уведомлений. В Prometheus для этой цели используется Alertmanager.
Grafanaпредставляет собой открытый web-frontend к различным time series СУБД, таким, как Graphite, InfluxDB, Prometheus. В общем, Grafana рисует для вас красивые графики, используя информацию из Prometheus. Характерно, что у Prometheus есть и собственный web-интерфейс. Однако он предельно прост и довольно неудобен. Поэтому даже сами разработчики Prometheus рекомендуют использовать Grafana.
Важно! Настройки, связанные с безопасностью, в рамках этого поста не рассматриваются. За информацией о том, как настроить firewall, поднять Nginx для какой-нибудь аутентификации, а также настроить TLS, обращайтесь к соответствующим более ранним заметкам. Обращаю ваше внимание на то, что по умолчанию Prometheus слушает все сетевые интерфейсы без какой-либо аутентификации и шифрования. Grafana имеет кое-какую аутентификацию, но также слушает все интерфейсы и не имеет шифрования.
Вы можете найти более полный список официальных экспортеров и экспортеров сообщества на веб-сайте Prometheus.
Выполним настройку службы синхронизации времени по действиям. Если этого не сделать, если не синхронизировать время, то позднее в работе Prometheus будут ошибки или вообще работать не будет.
Внимание! В CentOS 7 данная утилита уже идет в комплекте даже при минимальной комплектации установщика. Устанавливать отдельно в CentOS 7 утилиту chrony не надо.
Для проверки статуса chrony используется следующая команда.
# systemctl status chronyd
Проверяем, нормально ли запустился:
Все в порядке, сервис настроен и работает. После запуска он автоматически синхронизирует время. Теперь наши часы будут автоматически синхронизироваться с сервером времени в интернете.
# timedatectl status
Чтобы проверить, синхронизирован ли chrony на самом деле. Как и у ntp, у chrony есть интерфейс командной строки chronyc. Мы будем использовать его программу командной строки chronyc, которая имеет опцию отслеживания для предоставления соответствующей информации.
# chronyc tracking
Чтобы проверить информацию об источниках chrony, можно выполнить следующую команду:
# chronyc sources
С временем закончили. Всё работает. Идем дальше!
5. Получение и запуск Prometheus Service.
Установим текстовый редактор mc, download-менеджер wget, архиватор tar:
# yum -y install mc wget tar
Зайдем на страничку разработчика системы Prometheus и скопируем ссылку на скачивание архива с программой:
Важно! Конфигурационный файл Prometheus использует формат YAML, который строго запрещает табуляцию и требует двух пробелов для отступов. Prometheus не удастся запустить, если конфигурационный файл некорректно отформатирован.
В глобальных настройках (раздел global) задайте интервал по умолчанию для сбора метрик. Обратите внимание, что Prometheus будет применять эти настройки для каждого экспортера, если только глобальные переменные не переопределяются индивидуальными настройками отдельного экспортера.
Согласно этому значению scrape_intervalPrometheus будет собирать метрики своих экспортеров каждые 15 секунд, что достаточно для большинства экспортеров.
global:
scrape_interval: 15s
Теперь добавьте Prometheus в список экспортеров, чтобы собирать его метрики. Для этого используйте директиву scrape_configs:
С помощью job_namePrometheus маркирует экспортеры в запросах и графах, потому тут лучше выбрать описательное имя.
Поскольку Prometheus экспортирует важные данные о себе, которые используются для мониторинга производительности и отладки, можно переопределить глобальную директиву scrape_interval с 15 секунд до 5 секунд, чтобы данные обновлялись чаще.
С помощью директив static_configs и targetsPrometheus определяет, где запускать экспортеры. Поскольку этот конкретный экспортер запущен на том же сервере, что и Prometheus, можно использовать localhost вместо IP-адреса и порт по умолчанию — 9090 порт.
Внимание! В последних версиях Prometheus конфигурационный файл уже идет в комплекте и теперь его особо модифицировать не требуется. Все и так хорошо работает!
Настроим конфигурационный файл Prometheus /etc/prometheus/prometheus.yml под наши нужды, но перед этим копируем его, на всякий случай:
Добавим в него следующие строки по смыслу синтаксиса файла конфигурации:
# my global config
global:
scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
# scrape_timeout is set to the global default (10s).
# Alertmanager configuration
alerting:
alertmanagers:
- static_configs:
- targets:
# - alertmanager:9093
# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
# - "first_rules.yml"
# - "second_rules.yml"
# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
# The job name is added as a label `job=` to any timeseries scraped from this config.
- job_name: 'prometheus_server'
scrape_interval: 5s
metrics_path: /metrics
static_configs:
- targets: ['localhost:9090']
Создадим конфигурационный файл службы Prometheus Service:
# mcedit /etc/systemd/system/prometheus.service
Этот файл сообщает systemd, что Prometheus нужно запускать в качестве пользователя prometheus, его конфигурационный файл находится в каталоге /etc/prometheus/prometheus.yml, а данные и метрики хранятся в каталоге /var/lib/prometheus.
Также нелишним будет знать некоторые особенности устройства Prometheus. В частности, по умолчанию все данные хранятся в течение 15 дней, метрики собираются раз в 5-15 секунд, а одна метрика в среднем занимает два байта на сэмпл. Обладая этой информацией, и зная количество метрик, можно прикинуть, сколько дискового пространства вам понадобится для их хранения.
Внимание! Хранилище Prometheus не позиционируется, как супер надежное. Если у вас очень ценные метрики, рекомендуется сохранять их куда-то еще через адаптеры. Ещё со временем метрики Prometheus из разных источников будут занимать приличное количество места на диске, поэтому заранее продумайте, где будете хранить большие объемные файлы, которые будут расти и расти!
Если что, то можно сделать потом ссылку на каталог, который фактически будет храниться в другом, более удобном месте.
Вывод описывает состояние Prometheus, основной идентификатор процесса (PID), использование памяти и так далее.
Внимание! Бывает, что всё сделано правильно, но ничего упорно не стартует. Сверьтесь с писком возможных ошибок с вашей стороны.
1. Иногда бывает, что у пользователя prometheus теряется доступ к /usr/local/bin/prometheus. Заново выдайте права 700 на /usr/local/bin/prometheus и запустите службу снова. Пару раз так было так на других дистрибутивах Linux, хотя визуально всё хорошо и права стоят на все операции.
2. Вы отредактировали файл etc/prometheus/prometheus.yml и сохранили его не в кодировке UTF-8. Файл существует, но не считывается. Меняйте кодировку на UTF-8.
3. Если вы получили сообщение об ошибке, убедитесь, что не допустили ошибок в синтаксисе YAML в файле конфигурации, а затем следуйте инструкциям на экране, чтобы устранить проблему. Синтаксис этого файла очень капризный, даже один лишний пробел или перенос строки, которые вы не заметили, могут не позволять запустить службу. Не расстраивайтесь и проверьте всё внимательно.
Если состояние сервиса не active, следуйте предыдущим инструкциям на экране и повторите предыдущие действия, чтобы устранить проблему, прежде чем продолжить. Возможно у вас просто опечатка в файле конфигурации оказалась.
-A INPUT -p tcp -m tcp --dport 9090 -m state --state NEW -j ACCEPT
Перезапускаем iptables:
# sudo systemctl restart iptables
Проверяем, что Prometheus отдает свои собственные метрики:
# curl 'localhost:9090/metrics'
Теперь можно установить дополнительный экспортер для создания метрик о ресурсах сервера.
6. Prometheus Server web-интерфейс.
Зайдем в web-интерфейс по адресу:
# http://Server-IP:9090/graph
Если всё было сделано правильно и проброшен порт 9090, вас встретит страница приветствия:
7. Получение и запуск Node Exporter (localhost).
Первым делом настроим Prometheus node exporter на Prometheus Server.
Чтобы расширить стандартные возможности Prometheus, установите дополнительный экспортер под названием Node Exporter. Node Exporter предоставляет подробную информацию о системе, включая использование процессора, диска и памяти.
Скопируем ссылку на соответствующий модуль с сайта разработчиков:
Коллекторы определяют, какие метрики генерирует Node Exporter. Полный список коллекторов Node Exporter, включая включенные по умолчанию и устаревшие, можно найти в файле README для Node Exporter.
Чтобы переопределить список коллекторов, используйте флаг --collectors.enabled.
В таком случае Node Exporter будет генерировать метрики, используя только коллекторы meminfo, loadavg и filesystem. Вы можете использовать столько коллекторов, сколько вам нужно, но обратите внимание, что при перечислении коллекторов пробелов перед запятыми или после них нет.
Перезагрузим системные службы systemd service.
# systemctl daemon-reload
Стартуем Prometheus service:
# systemctl start node_exporter
Прописываем в автозапуск CentOS 7:
# systemctl enable node_exporter
Проверим успех запуска:
# systemctl status node_exporter
Здесь вы увидите состояние Node Exporter, основной идентификатор процесса (PID), использование памяти и так далее.
Внимание! Иногда бывает, что у пользователя nodeusr нет доступа к /usr/local/bin/node_exporter, хотя визуально всё хорошо и права стоят на все операции. Заново выдайте права 700 на /usr/local/bin//node_exporterи запустите службу снова. Было так на других дистрибутивах Linux.
Если состояние сервиса не active, следуйте инструкциям на экране и повторите предыдущие действия, чтобы устранить проблему, прежде чем продолжить.
-A INPUT -p tcp -m tcp --dport 9100 -m state --state NEW -j ACCEPT
Перезапускаем iptables:
# sudo systemctl restart iptables
Проверяем, что метрики отдаются:
# curl 'localhost:9100/metrics'
8. Node Exporter web-интерфейс.
Зайдем в web-интерфейс по адресу:
# http://IP-Address:9100/metrics
Если всё было сделано правильно и проброшен порт 9100, вас встретит страница приветствия с большим количеством различных строк:
9. Настройка взаимодействия Prometheus и Node Exporter.
Добавим конфигурацию Node Exporter задачи для Prometheus Server.
Prometheus собирает только метрики экспортеров, указанных в разделе scrape_configs его конфигурационного файла. Добавьте в этот файл экспортер Node Exporter.
Зайдем на Prometheus Server и модифицируем prometheus.yml в каталоге /etc/prometheus/.
Редактируем файл:
# mcedit /etc/prometheus/prometheus.yml
Добавляем в файл конфигурации в блок scrape config в самый конец раздела:
Поскольку этот экспортер работает на том же сервере, что и Prometheus, можно использовать localhost вместо IP-адреса и порт по умолчанию Node Exporter — это 9100 порт.
Весь файл конфигурации должен выглядеть так:
# my global config
global:
scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
# scrape_timeout is set to the global default (10s).
# Alertmanager configuration
alerting:
alertmanagers:
- static_configs:
- targets:
# - alertmanager:9093
# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
# - "first_rules.yml"
# - "second_rules.yml"
# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
# The job name is added as a label `job=` to any timeseries scraped from this config.
- job_name: 'prometheus_server'
scrape_interval: 5s
metrics_path: /metrics
static_configs:
- targets: ['localhost:9090']
- job_name: 'node_exporter_prometheus'
scrape_interval: 5s
metrics_path: /metrics
static_configs:
- targets: ['localhost:9100']
Чтобы настройки активировались, перезапустим службу:
# systemctl restart prometheus
Проверим успех запуска:
# systemctl status prometheus
Если состояние сервиса не active, следуйте инструкциям на экране и повторите предыдущие действия, чтобы устранить проблему, прежде чем продолжить.
Внимание! Если вы получили сообщение об ошибке, убедитесь, что не допустили ошибок в синтаксисе YAML в файле конфигурации, а затем следуйте инструкциям на экране, чтобы устранить проблему. Синтаксис этого файла очень капризный, даже один лишний пробел или перенос строки, которые вы не заметили, могут не позволять запустить службу. Не расстраивайтесь и проверьте всё внимательно.
Зайдем в web-оболочку Prometheus Server и проверим targets.
Зайдем в web-интерфейс по адресу:
# http://IP-Address:9090/targets
Примерный вид в браузере:
10. Получение и запуск MySQL Exporter (localhost).
Создадим служебного пользователя сбора метрик MySQL Server базы данных.
Войдите в свою базу данных и выполните следующие команды:
# mysql -u root -p
> CREATE USER 'mysqld_exporter'@'localhost' IDENTIFIED BY 'password' WITH MAX_USER_CONNECTIONS 3;
> GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'mysqld_exporter'@'localhost';
> FLUSH PRIVILEGES;
> exit
Добавим в него строки, которые будут содержать строки вашего логина и пароля из примера по созданию служебного пользователя сбора метрик MySQL Server базы данных:
[client]
user=mysqld_exporter
password=password
Сохраним и выйдем из файла.
Добавим права на каталог для пользователя mysqld_exporter:
-A INPUT -p tcp -m tcp --dport 9104 -m state --state NEW -j ACCEPT
Перезапускаем iptables:
# sudo systemctl restart iptables
Проверяем, что метрики отдаются:
# curl 'localhost:9104/metrics'
11. MySQL Exporter web-интерфейс.
Зайдем в web-интерфейс по адресу:
# http://IP-Address:9104/metrics
Если всё было сделано правильно и проброшен порт 9104, вас встретит страница приветствия с большим количеством различных строк:
12. Настройка взаимодействия Prometheus и MySQL Exporter.
Добавим конфигурацию MySQL Exporter задачи для Prometheus Server.
Prometheus собирает только метрики экспортеров, указанных в разделе scrape_configs его конфигурационного файла. Добавьте в этот файл экспортер MySQL Exporter.
Зайдем на Prometheus Server и модифицируем prometheus.yml в каталоге /etc/prometheus/.
Редактируем файл:
# mcedit /etc/prometheus/prometheus.yml
Добавляем в файл конфигурации в блок scrape config в самый конец раздела:
Поскольку этот экспортер работает на том же сервере, что и Prometheus, можно использовать localhost вместо IP-адреса и порт по умолчанию MySQL Exporter — это 9104 порт.
Весь файл конфигурации должен выглядеть так:
g# my global config
global:
scrape_interval: 5s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
evaluation_interval: 5s # Evaluate rules every 15 seconds. The default is every 1 minute.
# scrape_timeout is set to the global default (10s).
# Alertmanager configuration
alerting:
alertmanagers:
- static_configs:
- targets:
# - alertmanager:9093
# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
# - "first_rules.yml"
# - "second_rules.yml"
# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
# The job name is added as a label `job=` to any timeseries scraped from this config.
- job_name: 'abiturientu_ru'
scrape_interval: 5s
metrics_path: /metrics
static_configs:
- targets: ['localhost:9090']
- job_name: 'node_exporter_abiturientu_ru'
scrape_interval: 5s
metrics_path: /metrics
static_configs:
- targets: ['localhost:9100']
- job_name: 'mysql_exporter_abiturientu_ru'
scrape_interval: 5s
metrics_path: /metrics
static_configs:
- targets: ['localhost:9104']
Чтобы настройки активировались, перезапустим службу:
# systemctl restart prometheus
Проверим успех запуска:
# systemctl status prometheus
Если состояние сервиса не active, следуйте инструкциям на экране и повторите предыдущие действия, чтобы устранить проблему, прежде чем продолжить.
Если вы получили сообщение об ошибке, убедитесь, что не допустили ошибок в синтаксисе YAML в файле конфигурации, а затем следуйте инструкциям на экране, чтобы устранить проблему. Синтаксис этого файла очень капризный, даже один лишний пробел или перенос строки, которые вы не заметили, могут не позволять запустить службу. Не расстраивайтесь и проверьте всё внимательно.
Зайдем в web-оболочку Prometheus Server и проверим targets.
Теперь можно будет получать метрики MySQL Exporter и использовать их в Grafana.
13. Проверка работы Prometheus Server.
# http://Server-IP:9090/graph
Для начала проверьте статус Prometheus и Node Explorer, открыв меню Status в верхней части экрана, а затем выбрав Targets.
Нажимаем Status —> Targets:
Поскольку Prometheus собирает и свои данные и другие метрики, в состоянии UP вы должны увидеть все цели, которые ему ставили.
Если экспортера нет или вы видите сообщение об ошибке, проверьте состояние сервисов с помощью следующих команд:
# systemctl status prometheus
# systemctl status node_exporter
# systemctl status mysql_exporter
В выводе должна быть строка Active: active (running). Если это не так, или активный сервер работает некорректно, вернитесь на несколько шагов обратно по инструкции, чтобы исправить ошибки.
Чтобы убедиться, что экспортеры работают правильно, выполните несколько выражений Node Exporter.
Вы можете щелкнуть Graph и запросить любые метрики сервера, а затем нажать кнопку выполнить, чтобы показать выходные данные. Он покажет вывод консоли.
Браузер запросов. Для примера запросим вручную параметр node_memory_MemAvailable_bytes.
В ответ получаем график метрики node_memory_MemAvailable_bytes.
Наведите указатель мыши на график, чтобы получить дополнительную информацию о какой-либо конкретной точке вдоль осей X и Y.
Если вы хотите проверить результаты, выполните команду free в терминале. Флаг -h отображает вывод free в удобочитаемом формате и выводит сумму в мегабайтах.
# free -h
Этот вывод содержит сведения об использовании памяти, включая доступную память в столбце available.
Небольшая разница в результатах обусловлена, что сервер CentOS 7 работает в своем рабочем режиме и пока я работал с консолью состояние могло измениться. В целом метрика и запрос не врут и не противоречат друг другу.
Помимо базовых операторов язык запросов Prometheus также предоставляет множество функций для агрегирования результатов.
В нашей инструкции мы рассмотрим процесс установки и настройки Grafana Loki в качестве сервера сбора логов. Есть несколько способов ее установки — Helm chart, в качестве контейнера Docker, скачать готовый бинарник или собрать его из исходника. Мы выполним установку из последнего на систему Linux. Также, в качестве примера, мы прочитаем лог веб-сервера nginx и сделаем его вывод в Grafana.
Подготовка
Прежде чем устанавливать Loki, подготовим наш сервер для работы.
Установка пакетов
Для загрузки исходников нам понадобиться загрузить некоторые файлы. Для этого в системе должны быть установлены соответствующие пакеты. В зависимости от типа системы процесс установки будет незначительно отличаться.
а) на системах Red Hat:
yum install git wget
б) для систем на основе Debian:
apt-get install git wget
Установка Go
Для компиляции исходника, нам необходимо установить Golang. Для этого переходим на страницу загрузки и копируем ссылку на архив с его последней версией:
Воспользовавшись ссылкой, скачиваем архив на наш сервер:
* данная команда добавит правило на разрешение порта 3100 (на котором, по умолчанию, запускается Grafana Loki).
2. SELinux
Как правило, в системах на базе Red Hat активирована дополнительная система безопасности. В нашей инструкции мы ее отключаем командами:
setenforce 0
sed -i 's/^SELINUX=.*/SELINUX=disabled/g' /etc/selinux/config
* первая команда вводится до разового отключения SELinux. Вторая не дает ему запуститься после перезагрузки.
Установка
Установка Grafana Loki сводится к загрузке готового бинарника или исходника с последующей компиляцией. Также мы настроим юнит в systemd для работы приложения в качестве сервиса.
Копирование бинарника и конфигурационного файла
Переходим в каталог:
cd /usr/src/
Загружаем исходные файлы проекта:
git clone https://github.com/grafana/loki
Переходим в каталог loki:
cd loki/
Запускаем компиляцию бинарника:
go build ./cmd/loki
В текущем каталоге появится файл loki — перенесем его в каталог /usr/local/bin:
mv loki /usr/local/bin/
Создадим каталог:
mkdir /etc/loki
… и перенесем в него конфигурационный файл:
mv cmd/loki/loki-local-config.yaml /etc/loki/
В конфиге, который идет в исходнике в качестве рабочего каталога для Grafana Loki используется /tmp — мы это исправим двумя командами:
sed -i 's//tmp/wal//opt/loki/wal/g' /etc/loki/loki-local-config.yaml
* первой командой мы меняем настройку dir для wal (журнала предзаписи).
sed -i 's//tmp/loki//opt/loki/g' /etc/loki/loki-local-config.yaml
* в данном примере мы заменили путь для storage_config, working_directory и ruler storage на /opt/loki.
Открываем браузер и переходим по адресу http://192.168.0.15:3100/metrics, где 192.168.0.15 — IP-адрес нашего сервера Grafana Loki. Мы должны увидеть страницу с метриками:
Значит наш сервис запустился и нормально работает. Можно прервать его работу на сервере комбинацией клавиш Ctrl + С и продолжать настройку.
Автозапуск
Чтобы сервис мог автоматически запускаться при старте системы, добавим его в systemd.
Для начала, создадим пользователя, под которым будет работать сервис:
useradd --no-create-home --shell /bin/false loki
* данной командой мы создадим пользователя loki. Ему нельзя будет входить в систему в качестве интерактивного пользователя, также для него не будет создана домашняя директория.
Делаем владельцем loki бинарник для запуска сервиса:
Проверить, что он запустился и работает можно командой:
systemctl status loki
Установка серверной части завершена.
Отправка логов на сервер
В нашем примере мы передадим логи веб-сервера NGINX в нашу Grafana Loki. Для этого переходим на сервер с NGINX и выполним следующие действия.
Установка Promtail
Promtail — агент, который читает и отправляет логи на сервер. Его установка во многом напоминает установку сервера — получаем бинарник и добавляем его в автозагрузку. В нашем примере мы загрузим уже скомпилированный файл для запуска.
Для начала, установим следующие пакеты:
yum install unzip wget
* unzip нужен для распаковки архива с бинарником; wget — для скачивания архива.
* в нашем примере загружается бинарник на систему 64-бит. На странице https://github.com/grafana/loki/releases можно скачать файлы для установки под Linux и Windows.
Распаковываем скачанный архив:
unzip promtail-linux-amd64.zip
Переносим бинарник в каталог /usr/local/bin:
mv promtail-linux-amd64 /usr/local/bin/promtail
* обратите внимание, что мы его сразу переименовали в promtail.
Создаем каталог для конфигурационных файлов promtail:
На клиенте в настройки брандмауэра добавляем правило на разрешение порта 9080.
а) если используем iptables (Debian, Ubuntu):
iptables -I INPUT 1 -p tcp --dport 9080 -j ACCEPT
apt-get install iptables-persistent
netfilter-persistent save
б) если используем firewalld (CentOS, Red Hat):
firewall-cmd --permanent --add-port=9080/tcp
firewall-cmd --reload
После установки promtail открываем браузер и переходим на страницу http://192.168.0.25:9080/targets, где 192.168.0.25 — IP-адрес клиентского компьютера с NGINX. Мы должны увидеть страницу:
Promtail работает. Можно приступать к сбору логов.
job — метка для имени задания. Важный параметр для выборки данных.
__path__ — путь до файлов с логами.
Перезапускаем сервис promtail:
systemctl restart promtail
Снова заходим по адресу http://192.168.0.25:9080/targets — мы должны увидеть настроенное нами задание:
Сбор логов настроен.
Настройка Grafana
Переходим к серверу с Grafana. Он может быть установлен на отдельном сервере или на том же сервере с Loki.
Заходим в веб-интерфейс и переходим в Configuration — Data Sources:
Добавляем новый источник, кликая по Add data source:
Среди списка возможных источников выбираем Loki:
В настройках задаем имя и указываем IP-адрес сервера Loki:
* в нашем примере задается имя Loki и подключение к серверу 192.168.0.15.
Нажимаем на Save & Test:
Если мы увидели сообщение «Data source connected and labels found.»:
… значит подключение выполнено и можно двигаться дальше.
Переходим в раздел Create — Dashboard:
Кликаем по кнопке Add new panel:
В открывшемся окне выбираем в качестве источника данных Loki, затем кликаем по Log labels — выбираем job и nginxlogs:
Мы увидим Unable to graph data (так как логи представляют из себя данные, на основе которых нельзя постоить график) — кликаем по Switch to table view:
Мы должны увидеть строки из логов:
Логи NGINX отображаются в Grafana.
Парсинг лога
Мы увидели логи в графане, но они представленны в неудобном для отбора и фильрации виде. Попробуем это исправить с помощью парсинга логов на стороне promtail.
* обратите внимание, что к имеющейся настройки мы добавили pipeline_stages:
selector — тег для отбора логов, которые нужно парсить.
expression — регулярное выражение для парсинга логов.
labels — список тегов, которые мы будем передавать в loki. Обратите внимание, что названия данных тегов соответствую названиям, которые мы задали в expression.
Перезапускаем сервис для promtail:
systemctl restart promtail
Идем в Grafana — в Log labels мы должны увидеть новые критерии для фильтра по тегам:
Пробуем добавить, например, фильтр по статусу ответа веб-сервера:
Готовые кластеры в облаке, например AWS, Google Cloud, Yandex Cloud и так далее.
Использовать одну из готовых реализаций — быстрый и надежный способ развертывания системы оркестрации контейнеров Docker. Однако, мы рассмотрим ручное создание кластера Kubernetes из 3-х нод — один мастер (управление) и две рабочие ноды (запуск контейнеров).
Подготовка системы
Данные действия выполняем на всех узлах будущего кластера. Это необходимо, чтобы удовлетворить программные системные требования для нашего кластера.
Настройка системы
1. Задаем имена узлам. Для этого выполняем команды на соответствующих серверах:
hostnamectl set-hostname k8s-master1.dmosk.local
hostnamectl set-hostname k8s-worker1.dmosk.local
hostnamectl set-hostname k8s-worker2.dmosk.local
* в данном примере мы зададим имя k8s-master1 для мастера и, соответственно, k8s-worker1 и k8s-worker2 — для первого и второго рабочих нод. Каждая команда выполняется на своем сервере.
Необходимо, чтобы наши серверы были доступны по заданным именам. Для этого необходимо на сервере DNS добавить соответствующие А-записи. Или на каждом сервере открываем hosts:
* net.bridge.bridge-nf-call-iptables контролирует возможность обработки трафика через bridge в netfilter. В нашем примере мы разрешаем данную обработку для IPv4 и IPv6.
Применяем параметры командой:
sysctl --system
Брандмауэр
Для мастер-ноды и рабочей создаем разные наборы правил.
По умолчанию, в Ubuntu брандмауэр настроен на разрешение любого трафика. Если мы настраиваем наш кластер в тестовой среде, настройка брандмауэра не обязательна.
* для нас является важной настройкой cgroupdriver — она должна быть выставлена в значение systemd. В противном случае, при создании кластера Kubernetes выдаст предупреждение. Хоть на возможность работы последнего это не влияет, но мы постараемся выполнить развертывание без ошибок и предупреждений со стороны системы.
И перезапускаем docker:
systemctl restart docker
Установка Kubernetes
Установку необходимых компонентов выполним из репозитория. Добавим его ключ для цифровой подписи:
deb https://apt.kubernetes.io/ kubernetes-xenial main
Обновим список пакетов:
apt-get update
Устанавливаем пакеты:
apt-get install kubelet kubeadm kubectl
* где:
kubelet — сервис, который запускается и работает на каждом узле кластера. Следит за работоспособностью подов.
kubeadm — утилита для управления кластером Kubernetes.
kubectl — утилита для отправки команд кластеру Kubernetes.
Нормальная работа кластера сильно зависит от версии установленных пакетов. Поэтому бесконтрольное их обновление может привести к потере работоспособности всей системы. Чтобы этого не произошло, запрещаем обновление установленных компонентов:
По-отдельности, рассмотрим процесс настройки мастер ноды (control-plane) и присоединения к ней двух рабочих нод (worker).
Настройка control-plane (мастер ноды)
Выполняем команду на мастер ноде:
kubeadm init --pod-network-cidr=10.244.0.0/16
* данная команда выполнит начальную настройку и подготовку основного узла кластера. Ключ —pod-network-cidr задает адрес внутренней подсети для нашего кластера.
Выполнение займет несколько минут, после чего мы увидим что-то на подобие:
...
Then you can join any number of worker nodes by running the following on each as root:
kubeadm join 192.168.0.15:6443 --token f7sihu.wmgzwxkvbr8500al
--discovery-token-ca-cert-hash sha256:6746f66b2197ef496192c9e240b31275747734cf74057e04409c33b1ad280321
* данную команду нужно вводить на worker нодах, чтобы присоединить их к нашему кластеру. Можно ее скопировать, но позже мы будем генерировать данную команду по новой.
В окружении пользователя создаем переменную KUBECONFIG, с помощью которой будет указан путь до файла конфигурации kubernetes:
export KUBECONFIG=/etc/kubernetes/admin.conf
Чтобы каждый раз при входе в систему не приходилось повторять данную команду, открываем файл:
vi /etc/environment
И добавляем в него строку:
export KUBECONFIG=/etc/kubernetes/admin.conf
Посмотреть список узлов кластера можно командой:
kubectl get nodes
На данном этапе мы должны увидеть только мастер ноду:
NAME STATUS ROLES AGE VERSION
k8s-master.dmosk.local NotReady <none> 10m v1.20.2
Чтобы завершить настройку, необходимо установить CNI (Container Networking Interface) — в моем примере это flannel:
Копируем его и используем на двух наших узлах. После завершения работы команды, мы должны увидеть:
Run 'kubectl get nodes' on the control-plane to see this node join the cluster.
На мастер ноде вводим:
kubectl get nodes
Мы должны увидеть:
NAME STATUS ROLES AGE VERSION
k8s-master1.dmosk.local Ready control-plane,master 18m v1.20.2
k8s-worker1.dmosk.local Ready <none> 79s v1.20.2
k8s-worker2.dmosk.local Ready <none> 77s v1.20.2
Наш кластер готов к работе. Теперь можно создавать поды, развертывания и службы. Рассмотрим эти процессы подробнее.
Pods
Поды — неделимая сущность объекта в Kubernetes. Каждый Pod может включать в себя несколько контейнеров (минимум, 1). Рассмотрим несколько примеров, как работать с подами. Все команды выполняем на мастере.
Создание
Поды создаются командой kubectl, например:
kubectl run nginx --image=nginx:latest --port=80
* в данном примере мы создаем под с названием nginx, который в качестве образа Docker будет использовать nginx (последнюю версию); также наш под будет слушать запросы на порту 80.
Чтобы получить сетевой доступ к созданному поду, создаем port-forward следующей командой:
* в данном примере запросы к кластеру kubernetes на порт 8888 будут вести на порт 80 (который мы использовали для нашего пода).
Команда kubectl port-forward является интерактивной. Ее мы используем только для тестирования. Чтобы пробросить нужные порты в Kubernetes используются Services — об этом будет сказано ниже.
Можно открыть браузер и ввести адрес http://<IP-адрес мастера>:8888 — должна открыться страница приветствия для NGINX.
Просмотр
Получить список всех подов в кластере можно командой:
kubectl get pods
Например, в нашем примере мы должны увидеть что-то на подобие:
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 3m26s
Посмотреть подробную информацию о конкретном поде можно командой:
kubectl describe pods nginx
Запуск команд внутри контейнера
Мы можем запустить одну команду в контейнере, например, такой командой:
kubectl exec nginx -- date
* в данном примере будет запущена команда date внутри контейнера nginx.
Также мы можем подключиться к командной строке контейнера командой:
kubectl exec --tty --stdin nginx -- /bin/bash
Удаление
Для удаления пода вводим:
kubectl delete pods nginx
Использование манифестов
В продуктивной среде управление подами выполняется с помощью специальных файлов с описанием того, как должен создаваться и настраиваться под — манифестов. Рассмотрим пример создания и применения такого манифеста.
* в данном примере будет создан под с названием web-srv; в данном поде будет развернуто 3 контейнера — nginx, php-fpm и mariadb на основе одноименных образов.
Для объектов Kubernetes очень важное значение имеют метки или labels. Необходимо всегда их описывать. Далее, данные метки могут использоваться для настройки сервисов и развертываний.
Чтобы применить манифест выполняем команду:
kubectl apply -f manifest_pod.yaml
Мы должны увидеть ответ:
pod/web-srv created
Смотрим поды командой:
kubectl get pods
Мы должны увидеть:
NAME READY STATUS RESTARTS AGE
web-srv 3/3 Ready 0 3m11s
* для Ready мы можем увидеть 0/3 или 1/3 — это значит, что контейнеры внутри пода еще создаются и нужно подождать.
Deployments
Развертывания позволяют управлять экземплярами подов. С их помощью контролируется их восстановление, а также балансировка нагрузки. Рассмотрим пример использования Deployments в Kubernetes.
Создание
Deployment создаем командой со следующим синтаксисом:
kubectl create deploy <название для развертывания> --image <образ, который должен использоваться>
В данном примере Kubernetes будет создавать от 5 до 10 экземпляров контейнеров — добавление нового экземпляра будет происходить при превышении нагрузки на процессор до 75% и более.
Посмотреть созданные параметры балансировки можно командой:
kubectl get hpa
Редактирование
Для нашего развертывания мы можем изменить используемый образ, например:
kubectl set image deploy/web-set nginx=httpd:latest --record
* данной командой для deployment web-set мы заменим образ nginx на httpd; ключ record позволит нам записать действие в историю изменений.
Если мы использовали ключ record, то историю изменений можно посмотреть командой:
kubectl rollout history deploy/web-set
Перезапустить deployment можно командой:
kubectl rollout restart deploy web-set
Манифест
Как в случае с подами, для создания развертываний мы можем использовать манифесты. Попробуем рассмотреть конкретный пример.
* в данном манифесте мы создадим deployment и autoscaling. Итого, мы получим 5 экземпляров подов для развертывания web-deploy, которые могут быть расширены до 10 экземпляров. Добавление нового будет происходить при превышении нагрузки на процессор более чем на 75% или потреблением оперативной памяти более чем на 80%.
Чтобы создать объекты с помощью нашего манифеста вводим:
kubectl apply -f manifest_deploy.yaml
Мы должны увидеть:
deployment.apps/web-deploy created
horizontalpodautoscaler.autoscaling/web-deploy-autoscaling created
Объекты web-deploy и web-deploy-autoscaling созданы.
Удаление
Для удаления конкретного развертывания используем команду:
kubectl delete deploy web-set
Для удаления всех развертываний вместо названия deployment указываем ключ —all:
kubectl delete deploy --all
Удалить критерии autoscaling для конкретного развертывания можно командой:
kubectl delete hpa web-set
Удалить все критерии autoscaling можно командой:
kubectl delete hpa --all
Удалить объекты, созданные с помощью манифеста можно командой:
kubectl delete -f manifest_deploy.yaml
Services
Службы позволяют обеспечить сетевую доступность для развертываний. Существует несколько типов сервисов:
ClusterIP — сопоставление адреса с deployments для подключений внутри кластера Kubernetes.
NodePort — для внешней публикации развертывания.
LoadBalancer — сопоставление через внешний балансировщик.
ExternalName — сопоставляет службу по имени (возвращает значение записи CNAME).
Мы рассмотрим первые два варианта.
Привязка к Deployments
Попробуем создать сопоставления для ранее созданного развертывания:
* где web-deploy — deployment, который мы развернули с помощью манифеста. Публикация ресурса происходит на внутреннем порту 80. Обращаться к контейнерам можно внутри кластера Kubernetes.
Для создания сопоставления, с помощью которого можно будет подключиться к контейнерам из внешней сети выполняется командой:
* данная команда отличается от команды выше только типом NodePort — для данному deployment будет сопоставлен порт для внешнего подключения, который будет вести на внутренний (в нашем примере, 80).
Просмотр
Чтобы посмотреть созданные нами службы, вводим:
kubectl get services
Мы можем увидеть что-то на подобие:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
web-deploy NodePort 10.111.229.132 <none> 80:30929/TCP 21s
* в данном примере указано, что у нас есть служба типа NodePort, а к сервису можно подключиться по порту 30929.
Можно попробовать открыть браузер и ввести http://<IP-адрес мастера>:30929 — мы должны увидеть нужную нам страницу (в наших примерах, либо NGINX, либо Apache).
Посмотреть список сервисов с указанием селектором можно командой:
kubectl get services -o wide
Удаление
Удаляем созданную службу командой:
kubectl delete services web-deploy
* в данном примере будет удалена служба для развертывания web-deploy.
Удалить все службы можно командой:
kubectl delete services --all
Манифест
Как в случае с подами и развертываниями, мы можем использовать манифест-файлы. Рассмотрим небольшой пример.
* в данном примере мы создадим службу, которая будем связываться с развертыванием по лейболу project: myweb.
Ingress Controller
В данной инструкции не будет рассказано о работе с Ingress Controller. Оставляем данный пункт для самостоятельного изучения.
Данное приложение позволяет создать балансировщик, распределяющий сетевые запросы между нашими сервисами. Порядок обработки сетевого трафика определяем с помощью Ingress Rules.
Существует не маленькое количество реализаций Ingress Controller — их сравнение можно найти в документе по ссылке в Google Docs.
Для установки Ingress Controller Contour (среди множества контроллеров, он легко устанавливается и на момент обновления данной инструкции полностью поддерживает последнюю версию кластера Kubernetes) вводим:
Веб-интерфейс позволяет получить информацию о работе кластера в удобном для просмотра виде.
В большинстве инструкций рассказано, как получить доступ к веб-интерфейсу с того же компьютера, на котором находится кластер (по адресу 127.0.0.1 или localhost). Но мы рассмотрим настройку для удаленного подключения, так как это более актуально для серверной инфраструктуры.
Переходим на страницу веб-интерфейса в GitHub и копируем ссылку на последнюю версию файла yaml:
* на момент обновления инструкции, последняя версия интерфейса была 2.1.0.
* где https://raw.githubusercontent.com/kubernetes/dashboard/v2.1.0/aio/deploy/recommended.yaml — ссылка, которую мы скопировали на портале GitHub.
Открываем на редактирование скачанный файл:
vi recommended.yaml
Комментируем строки для kind: Namespace и kind: Secret (в файле несколько блоков с kind: Secret — нам нужен тот, что с name: kubernetes-dashboard-certs):
* нам необходимо закомментировать эти блоки, так как данные настройки в Kubernetes мы должны будем сделать вручную.
Теперь в том же файле находим kind: Service (который с name: kubernetes-dashboard) и добавляем строки type: NodePort и nodePort: 30001 (выделены красным):
* таким образом, мы публикуем наш сервис на внешнем адресе и порту 30001.
Для подключения к веб-интерфейсу не через локальный адрес, начиная с версии 1.17, обязательно необходимо использовать зашифрованное подключение (https). Для этого нужен сертификат. В данной инструкции мы сгенерируем самоподписанный сертификат — данный подход удобен для тестовой среды, но в продуктивной среде необходимо купить сертификат или получить его бесплатно в Let’s Encrypt.
И так, создаем каталог, куда разместим наши сертификаты:
* можно не менять параметры команды, а так их и оставить. Браузер все-равно будет выдавать предупреждение о неправильном сертификате, так как он самоподписанный.
Создаем namespace:
kubectl create namespace kubernetes-dashboard
* это та первая настройка, которую мы комментировали в скачанном файле recommended.yaml.
Теперь создаем настройку для secret с использованием наших сертификатов:
* собственно, мы не использовали настройку в скачанном файле, так как создаем ее с включением в параметры пути до созданных нами сертификатов.
Теперь создаем остальные настройки с помощью скачанного файла:
kubectl create -f recommended.yaml
Мы увидим что-то на подобие:
serviceaccount/kubernetes-dashboard created
service/kubernetes-dashboard created
secret/kubernetes-dashboard-csrf created
secret/kubernetes-dashboard-key-holder created
configmap/kubernetes-dashboard-settings created
role.rbac.authorization.k8s.io/kubernetes-dashboard created
clusterrole.rbac.authorization.k8s.io/kubernetes-dashboard created
rolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created
clusterrolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created
deployment.apps/kubernetes-dashboard created
service/dashboard-metrics-scraper created
deployment.apps/dashboard-metrics-scraper created
Теперь открываем браузер и переходим по ссылке https://<IP-адрес мастера>:30001 — браузер покажет ошибку сертификата (если мы настраиваем по инструкции и сгенерировали самоподписанный сертификат). Игнорируем ошибку и продолжаем загрузку.
Kubernetes Dashboard потребует пройти проверку подлинности. Для этого можно использовать токен или конфигурационный файл:
На сервере вводим команду для создания сервисной учетной записи:
Для совместной работы с документами в облачном сервисе Nextcloud/Owncloud есть несколько популярных программных продуктов, например, ONLYOFFICE, LibreOffice Online и Collabora Online. Последний может быть развернут локально и использоваться бесплатно.
Рассмотрим процесс установки Collabora Online на одном сервере с Nextcloud без привязки к конкретной системе Linux (это может быт CentOS, Ubuntu, Debian и так далее). Предполагается, что Nextcloud установлен, иначе, можно воспользоваться инструкцией
Подготовка системы
Для работы Collabora используется TCP-порт 9980, чтобы его добавить в Linux вводим команды, в зависимости от используемой утилиты управления netfilter.
а) если firewalld:
firewall-cmd --permanent --add-port=9980/tcp
firewall-cmd --reload
б) если iptables:
iptables -A INPUT -p tcp --dport 9980 -j ACCEPT
netfilter-persistent save
Установка и запуск сервера Collabora
На практике лучше работает Collabora, установленная в качестве docker-контейнера.
Для начала необходимо установить docker. В зависимости от используемой системы Linux, действия будут немного отличаться. Подробнее процесс описан в инструкции Установка Docker на Linux.
После готов, как мы установили и запустили Docker, для получения нужного нам контейнера вводим команду:
docker pull collabora/code
Процесс загрузки займет несколько минут — в итоге мы должны увидеть:
Status: Downloaded newer image for collabora/code:latest
Для запуска контейнера нам нужен правильный сертификат, полученный на домен. Его можно купить или запросить бесплатно в Let’s Encrypt. Предположим, что мы сохранили наш сертификат по пути /etc/letsencrypt/live/collabora.dmosk.ru.
Команда для запуска контейнера с сервером collabora следующая:
* в итоге, наш контейнер будет слушать сетевые запросы на порту 9980 (параметр -p); мы добавим для разрешения имени nextcloud.dmosk.ru (нашего сервера Nextcloud) IP-адрес 192.168.1.15 (—add-host); в контейнер добавим файлы сертификатов (-v); в конфигурацию collabora добавим запрет на создание нового сертификата, добавим наш сервер nextcloud для разрешения подключаться к серверу; используем русский и английские языки; задаем логин и пароль для администратора nextcloud.
Настройка Nextcloud
В данной инструкции мы рассмотрим пример связки Collabora с Nextcloud. Для Owncloud действия будут похожи.
Для интеграции Collabora с Nextcloud заходим на веб-интерфейс последней и заходим в настройки:
В меню слева кликаем по Collabora Online Development Edition:
В поле URL-адрес (и порт) сервера документов Collabora Online добавляем адрес нашего сервера collabora:
* важно, чтобы запрос был на доменное имя. Таким образом, домен должен быть зарегистрирован в DNS. Если у нас есть недочеты с сертификатом (например, нет полной цепочки) ставим галочку Отключить проверку сертификата (небезопасно).
Переходим к папкам и файлам на облачном сервисе. Пробуем открыть любой документ docx или создать новый — он должен открыться в Collabora:
