Сборка rpm-пакета nginx. как сделать свой установочный пакет в centos

Сценарии настройки

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

1. Backend на https

Предположим, что наши внутренние серверы отвечают по SSL-каналу. Таким образом, нам нужно отправлять запрос по порту 443. Также схема проксирования должна быть https.

Настройка сайта:

server {
…
location / {
proxy_pass https://dmosk_backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
…
}

* обратите внимание на 2 момента:

Мы в схеме подключения proxy_pass указали https. В противном случае при подключении NGINX будет возвращать ошибку 400.
Мы задали дополнительные опции proxy_set_header, которых не было в примерах выше.

Настройка upstream:

upstream dmosk_backend {
server 192.168.10.10:443;
server 192.168.10.11:443;
server 192.168.10.12:443;
}

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

2. Разные бэкенды для разных страниц

Нам может понадобиться разные страницы сайта переводить на разные группы внутренних серверов.

Настройка сайта:

server {
…
   location /page1 {
   proxy_pass http://backend1;
   }
   location /page2 {
   proxy_pass http://backend2;
   }
…
}

* при такой настройке мы будем передавать запросы к странице page1 на группу backend1, а к page2 — backend2.

Настройка upstream:

upstream backend1 {
server 192.168.10.10;
server 192.168.10.11;
}
upstream backend2 {
server 192.168.10.12;
server 192.168.10.13;
}

* в данном примере у нас есть 2 апстрима, каждый со своим набором серверов.

3. На другой хост

Может быть необходимым делать обращение к внутреннему ресурсу по другому hostname, нежели чем будет обращение к внешнему. Для этого в заголовках проксирования мы должны указать опцию Host.

Настройка сайта:

server {
…
location / {
proxy_pass https://dmosk_backend;
proxy_set_header Host internal.domain.com;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
…
}

* в данном примере мы будем проксировать запросы на бэкенды, передавая им имя хоста internal.domain.com.

4. TCP-запрос

Рассмотрим, в качестве исключения, TCP-запрос на порт 5432 — подключение к базе PostgreSQL.

Настройка сайта:

server {
listen 5432;
proxy_pass tcp_postgresql;
}

* в данном примере мы слушаем TCP-порт 5432 и проксируем все запросы на апстрим tcp_postgresql.

Настройка upstream:

upstream tcp_postgresql {
server 192.168.10.14:5432;
server 192.168.10.15:5432;
}

* запросы будут случайным образом передаваться на серверы 192.168.10.14 и 192.168.10.15.

5. UDP-запрос

Рассмотрим также и возможность балансировки UDP-запросов — подключение к DNS по порту 53.

Настройка сайта:

server {
listen 53 udp;
proxy_pass udp_dns;
proxy_responses 1;
}

* в данном примере мы слушаем UDP-порт 53 и проксируем все запросы на апстрим udp_dns. Опция proxy_responses говорит о том, что на один запрос нужно давать один ответ.

Настройка upstream:

upstream udp_dns {
server 192.168.10.16:53;
server 192.168.10.17:53;
}

* запросы будут случайным образом передаваться на серверы 192.168.10.16 и 192.168.10.17.

Зачем уменьшать размер HTML-страницы

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

Пользователи не будут ждать долгой загрузки, максимум, который они ждут — 2-3 секунды на десктопе или 3-4 на мобильном устройстве. Если сайт так и не загрузился, пользователь закроет страницу — для поисковиков это будет значить, что сайт не удовлетворяет задачи пользователей. Поисковики стимулируют веб-мастеров ускорять и облегчать сайты. Обновление
Google Speed Update занижает позиции очень медленных сайтов, к тому же Google переводит сайты в Mobile-first index — это значит, что mobile-friendly сайты получат преимущество, десктопная выдача будет строиться на основе мобильной, где особенно важен вес страницы.

Иногда незначительные задержки скорости не критичны, если посетители целенаправленно хотят получить услуги, товары или информацию с конкретного сайта. К примеру, по данным инструмента
Google PageSpeed Insights, у сайта amazon.com довольно низкая скорость загрузки с мобильных устройств, но Amazon востребован: пользователи готовы ждать, чтобы делать выгодные заказы.

Анализ amazon.com

Скорее всего Amazon рассчитывает на то, что пользователи со смартфонов будут скачивать мобильное приложение, поэтому не работает над скоростью мобильной версии сайта.

Измерить скорость загрузки своего сайта и сравнить с конкурентными можно с помощью инструментов
Google PageSpeed Insights или Проверка скорости сайта от PR-CY.

Фрагмент результатов проверки

Если хотите ускорить загрузку страницы, то рекомендуем уменьшить ее размер.

Совместимость с серверным сжатием важна

Каждый раз, когда мы загружаем файл из браузера, браузер запрашивает сервер, какой тип сжатия он поддерживает, через заголовок. Например, если браузер поддерживает gzip и deflate для распаковки. Он добавит эти параметры в свой заголовок Accept-Encoding:

Accept-Encoding=”deflate, gzip”

Следовательно, браузеры, которые не поддерживают эти форматы, не будут включать их в заголовок. Когда сервер отвечает контентом, он сообщает браузеру о формате сжатия через заголовок Content-Encoding. Следовательно, если он поддерживает gzip, то заголовок выглядит так:

Content-Encoding=”gzip”

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

Accept-Encoding=”deflate, gzip, br”
Content-Encoding=”gzip, br”

Следовательно, если браузер использует лучший формат сжатия, а веб-сервер – нет, это бесполезно, поскольку веб-сервер не будет отправлять обратно файлы с предпочтительным алгоритмом сжатия. Вот почему так важно установить модуль сжатия для веб-сервера

Получаем сертификаты

Ввиду лимитов на обращения сначала попробуем получить сертификат для основного домена в режиме «сухого прогона»:

Этот вызов должен завершиться без сообщений об ошибках.

Если так, то получим сертификат уже в самом деле.

Символические ссылки на сертификаты Certbot помещает в каталоги с разбивкой по доменам.

Проверим полученные сертификаты.

Команда должна вывести список доменов для каждого из имеющихся сертификатов.

Чтобы не занимать в голове место порядком ключей для , добавим обёртку для него.

Использовать её очень просто.

Добавить поддомен в сертификат

Можно добавить до сотни доменов и поддоменов в существующий сертификат.

Это полезно, если вы забыли добавить поддомен www.

Поддержка старых клиентов

Если вам критически важна поддержка старых клиентов без SNI (напр. IE в WinXP, устаревшие версии Java и Python), то стоит зафиксировать список доменов для сертификата .

В этом случае получение сертификатов происходит без явного указания доменов.

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

Потому лучше без него.

Сборка rpm пакета nginx с поддержкой brotli и tls 1.3

Для сборки rpm пакета все готово. Нам нужно скачать исходники openssl и модуля brotli, которые мы будем использовать. На момент написания статьи, последняя версия openssl — 1.1.1a. Ее и будем использовать. Для этого идем на сайт https://www.openssl.org и копируем ссылку на загрузку из раздела Download.

Сразу же распакуем:

Скачиваем модуль brotli через git.

Для сборки rpm все готово. Теперь укажем в параметрах сборки нашу версию openssl и модуль brotli.

Добавляем в строку, начинающуюся с %define BASE_CONFIGURE_ARGS в самый конец к списку параметров:

Запускаем сборку rpm:

Устанавливаем собранный пакет:

Использовать кэш браузера для ускорения

Ускорить загрузку страницы помогает кэширование в браузере пользователя. При первой загрузке страницы файлы помещаются в кэш браузера с меткой времени, а при повторных посещениях они загружаются из кэша, а не с хостинга. Когда указанный промежуток времени пройдет, файлы обновятся с хостинга. Для кэширования подойдут файлы, которые изменяются не постоянно, иначе пользователь не увидит важных изменений. Статические объекты можно кэшировать от года и дольше.

Google рекомендует настроить сервер так, чтобы он возвращал ответ с HTTP-заголовком Cache-Control, например:

Cache-Control: max-age=31536000

Директива «max-age» указывает, как долго браузер должен кэшировать ресурс в секундах. Значение 31536000 соответствует году: 60 секунд * 60 минут * 24 часа * 365 дней = 31536000 секунд.

Google советует применять «no-cache» для объектов, которые могут обновляться: тогда браузер по-прежнему будет кэшировать ресурс со значением «no-cache», но сначала проверит актуальность на сервере.

Кэширование для Nginx

Для сервера Nginx подходит модуль expires в файле конфигурации. Нужно перечислить форматы файлов для кэширования и указать время хранения кэша:

location ~* \.(js|css|png|jpg|jpeg|gif)$ {
 expires 86400s;
 log_not_found off;
 }

Время можно указать в любом формате: секунды — s, часы — h, дни — d и месяцы — m, обозначение «max» указывает на кэширование навсегда.

Вместо времени хранения файла можно указать дату следующего обновления файла в кэше:

expires Fri, 24 Nov 2017 01:01:01 GMT;

Строка log_not_found off нужна для снижения нагрузки на сервер, она отключает ведение лога сообщений с ошибкой 404 для перечисленных файлов.

Метод Cache-Control

Метод позволяет указать для кэширования файлы конкретных форматов. В файле .htaccess в конструкции FilesMatch нужно указать расширения файлов для кэширования и время сохранения файла в кэше в секундах:

# 1 Month for most static assets
    <filesmatch ".(flv|gif|jpg|jpeg|png|ico|swf|js|css|pdf)$"="">
     Header set Cache-Control "max-age=2592000"
    </filesmatch>

С помощью другого кода можно запретить кэшировать какие-то отдельные файлы по форматам, обычно это используют для динамических файлов. Для этого в файл .htaccess нужно вставить заголовок и форматы файлов, кэширование которых запрещено:

  <filesmatch ".(pl|php|cgi|spl|scgi|fcgi)$"="">
     Header unset Cache-Control
    </filesmatch>

Кэширование по времени

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

 ## EXPIRES CACHING ##
    <ifmodule mod_expires.c="">
    ExpiresActive On
    ExpiresByType image/jpg "access 1 year"
    ExpiresByType image/jpeg "access 1 year"
    ExpiresByType image/gif "access 1 year"
    ExpiresByType image/png "access 1 year"
    ExpiresByType text/css "access 1 month"
    ExpiresByType text/html "access 1 month"
    ExpiresByType application/pdf "access 1 month"
    ExpiresByType text/x-javascript "access 1 month"
    ExpiresByType application/x-shockwave-flash "access 1 month"
    ExpiresByType image/x-icon "access 1 year"
    ExpiresDefault "access 1 month"
    </ifmodule>
    ## EXPIRES CACHING ##

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

После сохранения нужно обновить страницу.

Проверить кэширование в Google Chrome можно с помощью веб-инспектора Chrome DevTools. Столбец Size в Chrome DevTools поможет убедиться, что ресурс в кэше:

Столбец Size в Chrome DevTool. Источник —

Вкладка Headers покажет, как установлен Cache-Control:

Проверка заголовка Cache-Control. Источник — Google

Perfect Forward Secrecy

Если вы переживаете что Certbot может утащить ключи от вашего сертификата не смотря на открытые исходные коды, а значит, в теории, какие-то злодеи смогут расшифровать весь трафик, то спешу вас успокоить. Если для соединения с вашим сайтом используются шифры из семейств DHE и ECDHE, то утечка ключа не позволит расшифровать трафик. В этих шифрах ключ сертификата используется только для подтверждения подлинности, и не используется в качестве ключа для шифрования. Все современные браузеры поддерживают эти шифры.

Если для ECDHE на эллиптических кривых ничего не нужно делать, то для DHE нужно использовать усиленные параметры. Сначала создадим их:

Потом пропишем в одной строкой:

Добавление модуля

Как говорилось выше, мы добавим модуль SPNEGO в нашу сборку. Для примера, мы будем использовать динамическое подключение данного модуля.

В моем примере необходимо клонировать проект из GIT-репозитория. Для этого необходимо установить одноименную утилиту:

yum install git

Теперь заходим под ранее созданным пользователем builder:

su — builder

Переходим в каталог для сборки. В нашем случае, это домашняя директория:

$ cd ~

Клонируем исходник модуля в директорию /tmp:

$ git clone https://github.com/stnoonan/spnego-http-auth-nginx-module.git /tmp/spnego-http-auth-nginx-module

Ранее мы уже скачивали исходники nginx, поэтому сразу открываем файл nginx.spec:

$ vi rpmbuild/SPECS/nginx.spec

Находим:

%define BASE_CONFIGURE_ARGS …

После последнего —with-… добавим:

—add-dynamic-module=/tmp/spnego-http-auth-nginx-module

Находим

%description

После него добавляем:

Сжать фотографии, иллюстрации и другую графику

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

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

Как оптимизировать картинки для сайта:

Подберите разрешение.
Незачем загружать изображение в большом разрешении, если оно будет отображаться в маленьком без увеличения по клику.
Подберите формат.
JPEG подходит для фотографий, PNG для дизайнерской графики, SVG для вектора. Google также индексирует формат WebP, который весит меньше, но не все браузеры его поддерживают. Яндекс не индексирует SVG и изображения в скриптах.
Уменьшайте количество цветов.
Изображения, где нет сложных градиентов, требуют меньшего количества цветов. Можно оптимизировать картинку без потери качества, выбрав палитру меньше, тогда изображение будет хранить меньшее количество битов на пиксель.Слева направо: 32 бита (16M цветов), 7 бит (128 цветов), 5 бит (32 цвета)

Пропишите параметры в CSS.
Укажите размеры в коде или в редакторе изображений CMS. Для разных экранов и дисплеев с матрицей Retina нужны дополнительные варианты изображения разных размеров, чтобы браузер загружал нужное для устройства.

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

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

Минифицируйте.
Удаляйте XML-разметку с лишними метаданными, она появляется при работе с картинками в некоторых графических приложениях. EXIF — информацию о геоданных, дате съемки, фотокамере тоже можно удалить.

Используйте алгоритмы сжатия.
Настройте на сервере gzip-сжатие для SVG-графики.

Инструменты и сервисы для оптимизации изображений на сайте:

CompressJPEGСервис для сжатия JPEG и PNG без потерь качества.
PunyPNG
Инструмент сжимает PNG, JPEG и GIF.
TinyPNGИнструмент для оптимизации изображений в PNG и JPEG.
JpegtranИнструмент для оптимизации JPEG-изображений.
OptipngИнструмент для оптимизации PNG без потерь.
PngquantИнструмент сжимает PNG-изображения.

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

Общие принципы

Многие команды для настройки в скрипте обернуты в условия (if) для идемпотентности: скрипт можно запускать несколько раз без риска изменения настроек, которые уже готовы.
Скрипт старается устанавливать ПО из репозиториев, так что вы можете применять обновления системы в одну команду ( для Ubuntu).
Команды стараются определить, что они запускаются в контейнере, чтобы изменить соответствующим образом свои настройки.
Для того, чтобы задать число запускаемых процессов\потоков в настройках, скрипт пробует угадать автоматические параметры настройки для работы в контейнерах, виртуальных машинах, «железных» серверах.
При описании настроек всегда думаем в первую очередь об автоматизации, которая, как мы надеемся, станет основой для создания вашей собственной инфраструктуры как кода.
Все команды запускаются от пользователя root, потому что они изменяют основные системные настройки, но непосредственно WordPress работает от обычного пользователя.

Компиляция модуля

Мы будем использовать команду make для создания папки модулей внутри каталога nginx-1.18.0.

andreyex@ubuntu:~$ sudo make modules

Мы используем команду cp для копирования файлов ngx_http_brotli * .so из папки nginx-1.18.0/objs в папку модулей.

andreyex@ubuntu:~$ cd /nginx-1.18.0/objs/
andreyex@ubuntu:~$ sudo cp  <strong>ngx_http_brotli*.so </strong>/usr/share/nginx/modules

Теперь перечислите содержимое файлов с помощью команды ls. Вы заметите, что он состоит из двух разных файлов модулей, то есть:

andreyex@ubuntu:~$ ls ngx_http_brotli*.so

ngx_http_brotli_filter_module.so
ngx_http_brotli_static_module.so

Обычный модуль Brotli: модуль ngx_http_brotli_filter_module.so сжимает все файлы на лету и, следовательно, требует больше вычислительных ресурсов.
Статический модуль Brotli: модуль ngx_http_brotli_static_module.so позволяет ему обслуживать предварительно сжатые статические файлы, следовательно, менее ресурсоемкие.

Теперь используйте свой любимый редактор, чтобы открыть файл /etc/nginx/nginx.conf, чтобы добавить модули загрузки Brotli, чтобы начать настройку Brotli, включив следующие строки:

andreyex@ubuntu:~$ sudo vim /etc/nginx/nginx.conf

# Load module section
load_module "modules/ngx_http_brotli_filter_module.so";
load_module "modules/ngx_http_brotli_static_module.so";

Мы также включим пути к папкам конфигурации /etc/nginx/conf.d/*.conf

и /usr/share/nginx/modules/*.conf в указанном выше файле, например:

http {
# Include configs folders
include /etc/nginx/conf.d/*.conf;
include /usr/share/nginx/modules/*.conf;
}

Чтобы добавить конфигурацию Brotli, откройте /etc/nginx/conf.d/brotli.conf

в редакторе vim и включите Brotli, установив следующие директивы конфигурации:

brotli     on;
brotli_static        on;
brotli_comp_level          6;
brotli_types         application/rss+xml application/xhtml+xml
text/css text/plain;

Значение «brotli off|on» включает или отключает динамическое сжатие содержимого или сжатие «на лету».

Параметр ‘brotli_ static on’ позволяет серверу Nginx проверять, существуют ли предварительно сжатые файлы с расширениями .br или нет. Мы также можем включить этот параметр в параметр « выключено» или « всегда». Значение always позволяет серверу отправлять предварительно сжатый контент без подтверждения, поддерживает его браузер или нет. Поскольку Brotli является ресурсоемким, этот модуль лучше всего подходит для уменьшения количества узких мест.

В «brotli_comp_level 6» устанавливает динамический уровень качества сжатия до 6. Это может быть в диапазоне от 0 до 11.

Наконец, включите динамическое сжатие для определенных типов MIME, тогда как ответы text/html всегда сжимаются. Синтаксис по умолчанию для этой директивы – brotli_types . Вы можете найти больше о директиве конфигурации на Github .

Сохраните изменения, перезапустите службу Nginx, набрав «sudo service restart nginx», и все готово.

Other Brotli (ngx_brotli) directives

Apart from the ones mentioned before, there are many other brotli nginx directives that can be used to configure your compression. For example:

brotli_comp_level = sets brotli compression levels between 0 to 11, default level is 6.
brotli_window = used to set Brotli windows size. Values are: 1k, 2k, 4k, 8k, 16k, 32k, 64k, 128k, 256k, 512k, 1m, 2m, 4m, 8m and 16m
brotli_buffers = lets you specify size and number of buffers used during the compression process, default value is 32 4k|16 8k.
brotli_min_length = configure a minimum length in order to have the requst compressed, determined by the Content-Length field in the HTTP headers.

Подготовка системы

1. Устанавливаем необходимые пакеты:

yum install wget rpm-build rpmdevtools gcc make

* где:

wget — утилита для загрузки файлов по сети.
rpm-build — включает в себя утилиту rpmbuild, с помощью которой будет выполняться сама сборка установочного пакета.
rpmdevtools — позволит нам использовать утилиту rpmdev-setuptree, с помощью которой мы сможем создать рабочую среду в виде каталогов для сборки.
gcc — компилятор СИ. Необходим для сборки.
make — утилита для сборки исходников.

2. Устанавливаем зависимости:

yum install openssl-devel zlib-devel pcre-devel

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

3. Создаем пользователя.

Делать готовые установочные сборки пакетов очень опасно от пользователя root. Если мы допустим ошибку с путями, файлы могут перетереть или удалить важные для работы директории. Стоит создать отдельного пользователя и работать под ним.

Выполняем команду:

useradd builder -m

* в данном примере мы создадим пользователя builder. Опция -m сразу создаст домашний каталог для пользователя.

Теперь заходим под данным пользователем — последующие команды мы будем выполнять от него:

su — builder

Изменение конфигурационного файла NGINX

Перед сборкой мы можем изменить конфигурационный файл веб-сервера, который уже попадет в наш установочный пакет. Так как мы рассматриваем пример работы с модулем spnego, внесем настройки для него.

Открываем файл:

$ vi rpmbuild/SOURCES/nginx.conf

Внесем следующие изменения:

user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;include /etc/nginx/modules/*.conf;
events {
…

* в нашем примере внесено всего 2 изменения:

worker_processes, который отвечает за распределение нагрузки по ядрам уже давно рекомендуется выставлять в значение auto.
Также мы дописали строку include /etc/nginx/modules/*.conf, которая укажет нашему веб-серверу подгружать все конфигурационные файлы из каталога modules.

Также активируем для сайта по умолчанию опцию для модуля spnego. Открываем файл:

$ vi rpmbuild/SOURCES/nginx.vh.default.conf

Это файл, который будет находиться по пути /etc/nginx/conf.d/default.conf. Внесем в него изменения:

location / {
root /usr/share/nginx/html;
index index.html index.htm;
auth_gss on;
auth_gss_realm DMOSK.RU;
auth_gss_keytab /etc/http.keytab;
auth_gss_service_name HTTP/test.dmosk.ru;
}

Пересобираем RPM:

$ rpmbuild -bb rpmbuild/SPECS/nginx.spec

Выполняем установку новых пакетов на целевом сервере. В нашем примере мы можем переустановить пакеты командами:

rpm -Uvh —force nginx-1.19.3-1.el7.ngx.x86_64.rpm

rpm -Uvh —force nginx-module-spnego-1.19.3-1.el7.ngx.x86_64.rpm

* напоминаю, что у нас используется версия 1.19.3. Чтобы данные команды отработали, необходимо находиться в каталоге, где лежат наши установочные файлы.

Мы должны увидеть изменения в конфигах, которые сделали до сборки.

Настройка logstash на прием логов микротик

В конфиге /etc/logstash/conf.d/input.conf добавляем секцию для приема syslog логов. Вместе с логами от beats конфиг будет выглядеть вот так:

input {
    beats {
	port => 5044
    }
    syslog {
	port => 5045
	type => syslog
    }
}

В конфиге с фильтрами filter.conf я разделил с помощью тэгов логи обычных роутеров, свитчей и wifi точек доступа по ip адресам. Получилось примерно так:

    else if  == "10.1.4.19" or  == "10.1.5.1" {
        mutate {
            add_tag => 
        }
    }
    else if  == "10.1.4.66" or  == "10.1.3.110" or  == "10.1.3.111" {
        mutate {
            add_tag => 
        }
    }
    else if  == "10.1.4.14" or  == "10.1.5.33" {
        mutate {
            add_tag => 
	}
    }

Это простой случай, когда устройств мало. Если у вас много устройств, то лучше наверно придумать что-то другое, чтобы не нагружать logstash лишними правилами. Да и в ручную править конфиг неудобно. Как лучше поступать в таком случае — не знаю, не продумывал тему. Наверно имеет смысл разделить потоки по разным портам и на этом основании принимать решение о дальнейшей обработке.

Отправляем полученные логи в elasticsearch, настроив конфиг output.conf:

    else if "mikrotik" in  {
        elasticsearch {
            hosts     => "localhost:9200"
            index    => "mikrotik-%{+YYYY.MM}"
        }
    }

Я просто складываю все логи с тэгом mikrotik в один индекс с разбивкой по месяцам. На типы gateway, switch и wifi не разделяю, хотя можно это сделать. Тэги я добавил просто для удобства просмотра логов. С помощью тэгов можно будет быстро группировать логи по типу устройств.

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

Подготовка среды

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

$ pwd

Мы должны увидеть что-то на подобие:

/home/builder

Перейти в домашний каталог пользователя можно командой:

$ cd ~

Создадим структуру каталогов для сборки:

$ rpmdev-setuptree

В нашей текущем каталоге должна появиться папка rpmbuild — а в ней:

BUILD — содержит все файлы, которые появляются при создании пакета.
RPMS — сюда будут складываться готовые пакеты.
SOURCES — для исходников, из которых и будут собираться RPM-пакеты.
SPECS — для файлов с описанием процесса сборки.
SRPMS — для исходников RPM-файлов.

Мы готовы к загрузке исходника и его подготовке.

Подготовка к сборке своего rpm пакета

Для начала поставим все, что нам понадобится для самостоятельной сборки своего rpm пакета.

# yum groupinstall "Development Tools" && yum install rpmdevtools yum-utils wget git

Подключим репозитории nginx mainline ветки для СentOS 7

Обращаю внимание, что используется не стабильная версия stable, а основная — mainline. Она достаточно надежная, в ней все свежие обновления

# mcedit /etc/yum.repos.d/nginx.repo

name=nginx repo
baseurl=http://nginx.org/packages/mainline/centos/7/$basearch/
gpgcheck=0
enabled=1


name=nginx source repo
baseurl=http://nginx.org/packages/mainline/centos/7/SRPMS/
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

Обновите репозитории:

# yum update

Перейдем в домашний каталог и создадим там структуру каталогов.

# cd ~
# rpmdev-setuptree

У nginx в репозитории уже есть все в готовом виде для сборки из исходников. Загрузим пакет с исходниками и установим его.

# yumdownloader --source nginx
# rpm -Uvh nginx*.src.rpm

Если работаете от root, то получите пачку предупреждений.

Для сборки пакетов рекомендуется использовать отдельного пользователя. Но это не критично.

Устанавливаем зависимости, необходимые для сборки.

# yum-builddep nginx

Заключение

Получилась простая статья по сбору логов. Для тех, кто уже работал с ELK Stack тут ничего нового нет. По сути, никакого анализа и графиков нет, а именно это чаще всего интересует при использовании elk. Я просто не придумал, что может быть полезного в логах микротика, что требует какого-то детального разбора и построения дашбордов. Если у кого-то есть идеи или примеры grok фильтров, прошу поделиться.

Напоминаю, что данная статья является частью единого цикла статьей про Mikrotik.

Онлайн курс «DevOps практики и инструменты»

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

Проверьте себя на вступительном тесте и смотрите программу детальнее по .

Онлайн курсы по Mikrotik

Если у вас есть желание научиться работать с роутерами микротик и стать специалистом в этой области, рекомендую пройти курсы по программе, основанной на информации из официального курса MikroTik Certified Network Associate. Помимо официальной программы, в курсах будут лабораторные работы, в которых вы на практике сможете проверить и закрепить полученные знания. Все подробности на сайте .

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

Знания, ориентированные на практику;
Реальные ситуации и задачи;
Лучшее из международных программ.