Вы знали, что php в своём составе имеет собственный веб сервер? Для быстрого запуска php скриптов в браузере не нужно ничего, кроме непосредственно php на сервере. Покажу сразу на примере.
Допустим, вам нужно временно запустить phpmyadmin, но не хочется для него настраивать веб сервер. Его может не быть, либо просто не хочется что-то менять в работе уже настроенного. Нет ничего проще.
Устанавливаем php и модуль mysqli для работы с mysql:
Качаем и распаковываем phpmyadmin:
Запускаем веб сервер:
Идём по адресу http://172.27.50.130:8080 и видим веб интерфейс phpmyadmin. Если он ещё не настроен, то надо зайти в директорию /setup/ и выполнить начальную настройку подключения. Как минимум, адрес сервера указать. Если это не первое подключение, то сразу же подключаемся к базе.
Когда закончите работу, просто остановите веб сервер, завершив его работу в консоли. В ней же, кстати, будет информация обо всех запросах. Подобным образом можно запустить любой php скрипт. Для phpmyadmin этот подход наиболее актуален, так как веб панель нужна не часто, а оставлять её открытой для постоянно доступа не рекомендуется. Для личных нужд проще запустить, всё сделать и закрыть.
#php #webserver
Допустим, вам нужно временно запустить phpmyadmin, но не хочется для него настраивать веб сервер. Его может не быть, либо просто не хочется что-то менять в работе уже настроенного. Нет ничего проще.
Устанавливаем php и модуль mysqli для работы с mysql:
# apt install php php-mysqliКачаем и распаковываем phpmyadmin:
# wget https://files.phpmyadmin.net/phpMyAdmin/5.2.1/phpMyAdmin-5.2.1-all-languages.tar.gz# tar xzvf phpMyAdmin-5.2.1-all-languages.tar.gzЗапускаем веб сервер:
# cd phpMyAdmin-5.2.1-all-languages# php -S 172.27.50.130:8080Идём по адресу http://172.27.50.130:8080 и видим веб интерфейс phpmyadmin. Если он ещё не настроен, то надо зайти в директорию /setup/ и выполнить начальную настройку подключения. Как минимум, адрес сервера указать. Если это не первое подключение, то сразу же подключаемся к базе.
Когда закончите работу, просто остановите веб сервер, завершив его работу в консоли. В ней же, кстати, будет информация обо всех запросах. Подобным образом можно запустить любой php скрипт. Для phpmyadmin этот подход наиболее актуален, так как веб панель нужна не часто, а оставлять её открытой для постоянно доступа не рекомендуется. Для личных нужд проще запустить, всё сделать и закрыть.
#php #webserver
Популярный вопрос к моим статьям и заметкам по настройке проксирования HTTP запросов с Nginx куда-то на backend. Нужно ли настраивать HTTPS и как вообще правильно это сделать. Поясню, о чём идёт речь.
Допустим, у вас есть какой-то сервер Nginx, работающий в режиме proxy_pass и раскидывающий соединения к разным доменам по разным серверам или контейнерам. Либо это один большой сайт с несколькими бэкендами. Очевидно, что соединение клиента с этим Nginx настроено по HTTPS. А от Nginx до остальных серверов нужно ли настраивать по HTTPS?
В общем случае я такие соединения пускаю по HTTP. Не вижу смысла использовать в этом случае шифрование, которое усложняет настройку, потому что надо сертификаты передавать на все сервера. Так оно ещё и ресурсы дополнительные тратит. На небольших нагрузках это не особо заметно, а вот на тысячах запросах в секунду будет заметно.
Исключение делаю тогда, когда проксируемое приложение или сервис начинают работать некорректно при такой схеме. Это бывает нередко. Приходится либо настройки сайта крутить, либо дополнительные заголовки добавлять, либо что-то ещё делать. Если простых способов решить проблемы нет, то приходится настраивать всю цепочку соединений по HTTPS.
Некоторые примеры подобных ошибок и их решения я публиковал на сайте (phpmyadmin, wordpress). Точно надо что-то делать с Bitrix, если проксируешь его по HTTP. Сейчас уже не помню, что именно. Не записывал. Каждый раз по месту разбираюсь.
А вы как считаете? Нужно ли в этом случае настраивать HTTPS, при условии, что запросы гуляют по нашей внутренней сети, которая считается доверенной? Если речь идёт про проксирование через сторонний сервис, тот же Cloudflare, или другую систему защиты от DDOS, то HTTPS я всегда настраиваю.
#nginx #webserver
Допустим, у вас есть какой-то сервер Nginx, работающий в режиме proxy_pass и раскидывающий соединения к разным доменам по разным серверам или контейнерам. Либо это один большой сайт с несколькими бэкендами. Очевидно, что соединение клиента с этим Nginx настроено по HTTPS. А от Nginx до остальных серверов нужно ли настраивать по HTTPS?
В общем случае я такие соединения пускаю по HTTP. Не вижу смысла использовать в этом случае шифрование, которое усложняет настройку, потому что надо сертификаты передавать на все сервера. Так оно ещё и ресурсы дополнительные тратит. На небольших нагрузках это не особо заметно, а вот на тысячах запросах в секунду будет заметно.
Исключение делаю тогда, когда проксируемое приложение или сервис начинают работать некорректно при такой схеме. Это бывает нередко. Приходится либо настройки сайта крутить, либо дополнительные заголовки добавлять, либо что-то ещё делать. Если простых способов решить проблемы нет, то приходится настраивать всю цепочку соединений по HTTPS.
Некоторые примеры подобных ошибок и их решения я публиковал на сайте (phpmyadmin, wordpress). Точно надо что-то делать с Bitrix, если проксируешь его по HTTP. Сейчас уже не помню, что именно. Не записывал. Каждый раз по месту разбираюсь.
А вы как считаете? Нужно ли в этом случае настраивать HTTPS, при условии, что запросы гуляют по нашей внутренней сети, которая считается доверенной? Если речь идёт про проксирование через сторонний сервис, тот же Cloudflare, или другую систему защиты от DDOS, то HTTPS я всегда настраиваю.
#nginx #webserver
Многие, наверное, уже слышали, что некоторое количество бывших разработчиков Nginx создали форк и начали его развивать под названием Angie. Я видел эту новость давно, но не вникал в подробности. Сейчас решил разобраться и посмотреть, что в итоге получилось. Событие необычное.
Разработчики организовали ООО "Веб-Сервер", создали сайт и репозиторий нового веб сервера. Первое, что мне бросилось в глаза - сайт компании на тильде, где даже иконку не поменяли со стандартной тильдовской. Может это и не значит ничего, но лично мне кажется, что если компания решила заняться серьезной коммерческой деятельностью, то хотя бы иконку на сайте она бы сделала в соответствии со своим логотипом.
Вообще, Angie появился примерно год назад в виде open source проекта. А весной 2023 года появилась коммерческая версия Angie Pro. Он имеет сертификаты совместимости с отечественными операционными системами РЕД ОС, Astra Linux Special Edition и Альт Сервер 10. Авторы говорят про него: "Angie PRO – единственный коммерческий веб-сервер разработка которого локализована в России."
Насколько я понял, пока каких-то принципиальных технических отличий от оригинального Nginx нет. Тем не менее реализованы некоторые дополнительные возможности, в том числе фичи из платных редакций. Например, привязка сеанса пользователя к конкретному бэкенду. Если не ошибаюсь, в бесплатном Nginx такого нет. Изменения перечислены в новостях на сайте компании. Обещают важное обновление – поддержку шифрования по ГОСТ. На текущий момент этот продукт может быть интересен тем, у кого стоит вопрос импортозамещения на софт из реестра отечественного ПО.
При этом никто не мешает вам уже сейчас начать использовать Angie. Он доступен на операционных системах Alma Linux 8 и 9 версий, Alpine 3.18, Centos 7, 8 и 9 версий, Debian 12 и Ubuntu 23.04. Для них подготовлены репозитории от разработчиков. Я установил на Debian 12:
По конфигам тот же самый Nginx, но уже видны некоторые различия в именованиях директорий. На сайте Angie заявлено, что им можно подменить Nginx без каких-либо правок конфигурации.
Судя по публичному репозиторию, работа над веб сервером активно ведётся. Как по мне, новость отличная. Веб сервер с полной локализацией в РФ лишним точно не будет. Тем более, что разработку начали не с нуля, а взяли готовый продукт, над которым работают его же бывшие разработчики.
Помимо обычного веб сервера, разработчики работают над Angie Ingress Controller (ANIC) для Kubernetes. Его, как Angie Pro, можно приобрести с услугой внедрения и технической поддержки.
#отечественное #nginx #webserver
Разработчики организовали ООО "Веб-Сервер", создали сайт и репозиторий нового веб сервера. Первое, что мне бросилось в глаза - сайт компании на тильде, где даже иконку не поменяли со стандартной тильдовской. Может это и не значит ничего, но лично мне кажется, что если компания решила заняться серьезной коммерческой деятельностью, то хотя бы иконку на сайте она бы сделала в соответствии со своим логотипом.
Вообще, Angie появился примерно год назад в виде open source проекта. А весной 2023 года появилась коммерческая версия Angie Pro. Он имеет сертификаты совместимости с отечественными операционными системами РЕД ОС, Astra Linux Special Edition и Альт Сервер 10. Авторы говорят про него: "Angie PRO – единственный коммерческий веб-сервер разработка которого локализована в России."
Насколько я понял, пока каких-то принципиальных технических отличий от оригинального Nginx нет. Тем не менее реализованы некоторые дополнительные возможности, в том числе фичи из платных редакций. Например, привязка сеанса пользователя к конкретному бэкенду. Если не ошибаюсь, в бесплатном Nginx такого нет. Изменения перечислены в новостях на сайте компании. Обещают важное обновление – поддержку шифрования по ГОСТ. На текущий момент этот продукт может быть интересен тем, у кого стоит вопрос импортозамещения на софт из реестра отечественного ПО.
При этом никто не мешает вам уже сейчас начать использовать Angie. Он доступен на операционных системах Alma Linux 8 и 9 версий, Alpine 3.18, Centos 7, 8 и 9 версий, Debian 12 и Ubuntu 23.04. Для них подготовлены репозитории от разработчиков. Я установил на Debian 12:
# curl -o /etc/apt/trusted.gpg.d/angie-signing.gpg \ https://angie.software/keys/angie-signing.gpg# echo "deb https://download.angie.software/angie/debian/ `lsb_release -cs` main" \ | tee /etc/apt/sources.list.d/angie.list > /dev/null# apt update && apt install angieПо конфигам тот же самый Nginx, но уже видны некоторые различия в именованиях директорий. На сайте Angie заявлено, что им можно подменить Nginx без каких-либо правок конфигурации.
Судя по публичному репозиторию, работа над веб сервером активно ведётся. Как по мне, новость отличная. Веб сервер с полной локализацией в РФ лишним точно не будет. Тем более, что разработку начали не с нуля, а взяли готовый продукт, над которым работают его же бывшие разработчики.
Помимо обычного веб сервера, разработчики работают над Angie Ingress Controller (ANIC) для Kubernetes. Его, как Angie Pro, можно приобрести с услугой внедрения и технической поддержки.
#отечественное #nginx #webserver
После моей недавней заметки про Angie, в комментариях появился один из разработчиков этого продукта и дал более конкретную информацию. Так как комментарии читают не все, я хочу зафиксировать основную информацию отдельным сообщением.
1️⃣ Angie это не пересборка Nginx для перепродажи в России. Над развитием продукта работают разработчики. Изменения вносятся в том числе в open source версию и это будет продолжаться. Angie Pro не копия Nginx Plus. Это другой продукт.
2️⃣ Другой сайт будет. То, что сейчас на Тильде, это временно. Сейчас фокус на сам продукт, его код и другие организационные моменты.
3️⃣ У Angie есть свой Telegram канал - https://t.me/angie_software.
4️⃣ На сайте после моей заметки появилась обзорная статья: Сходства и различия Angie и nginx. (nginx почему-то с маленькой буквы, а Angie с большой 😁) Основные моменты оттуда (что-то в сокращении):
🔹в Angie нет кода NGINX Plus, закрытой коммерческой версии nginx; более того, у нас нет цели сделать наш платный веб-сервер, Angie PRO, стопроцентной функциональной копией NGINX Plus
🔹Angie сознательно ориентируется на платформы, для которых “официальный” nginx будет собираться еще нескоро: это такие сертифицированные в России ОС, как ALT Linux, Astra Linux SE и РЕД ОС, а также процессоры “Байкал” и “Эльбрус”.
🔹Мы решили упростить их жизнь и ведем единообразную сборку готовых пакетов для целого ряда таких модулей в своих репозиториях, используя свой опыт и знания.
Последнее прокомментирую, так как это важно. Разработчики Angie решили сами собирать популярные динамические модули веб сервера, чтобы упростить жизнь пользователям. Недавно у меня была публикация, где я рассказывал, как собрать Nginx с нужными модулями. А здесь разработчики озаботились и решили эту проблему сами. Список готовых модулей можно посмотреть на сайте. Там всё наиболее популярное присутствует (brotli, lua, geoip и т.д.) Не нашёл только vts. Думаю, разработчикам имеет смысл обратить на него внимание тоже. Все модули собраны в пакеты и доступны из репозитория. Вообще, это существенный плюс в пользу того, чтобы поставить Angie вместо Nginx, если тебе нужен какой-то модуль.
🔹Следующий фактор, на который мы обращаем внимание в своей работе, — ускорение работы самого веб-сервера за счет устранения лишних задержек. Мы:
◽добавили API-интерфейс динамической конфигурации и средства адаптивной DNS-адресации;
◽реализовали механизм привязки пользовательских сессий к проксируемому серверу;
◽внедрили активные проверки работоспособности проксируемых серверов, уменьшающие вероятность отправки реального запроса на неработающий сервер;
◽создали возможность сегментировать прокси-кэш, тем самым более эффективно задействуя все ресурсы сервера.
🔹Еще одна область, в которой мы хотим добиться улучшений, — это гибкость и удобство настройки веб-сервера. Мы:
◽добавили для групп проксируемых серверов упомянутый выше API-интерфейс динамической конфигурации;
◽предоставили ряд других настроек, менее масштабных, но весьма полезных.
🔹Наконец, важным для нас аспектом развития Angie является мониторинг состояния самого веб-сервера и проксируемых серверов. Мы:
◽реализовали в API-интерфейсе возможность получения базовой информации о веб-сервере, а также статистики по всем основным аспектам его функционирования в популярных современных форматах;
◽внедрили уже упомянутые активные проверки проксируемых серверов, самостоятельно следящие за их работоспособностью;
◽добавили семейство настроек для сбора статистики по сессиям передачи данных и запросам разрешения адресов.
Спасибо за подробные комментарии и описание отличий. Все эти изменения выглядят очень привлекательно для эксплуатации. Наглядно видно развитие и фокус внимания на реальные потребности пользователей. Обязательно попробую этот веб сервер в деле.
#webserver #nginx #angie #отечественное
1️⃣ Angie это не пересборка Nginx для перепродажи в России. Над развитием продукта работают разработчики. Изменения вносятся в том числе в open source версию и это будет продолжаться. Angie Pro не копия Nginx Plus. Это другой продукт.
2️⃣ Другой сайт будет. То, что сейчас на Тильде, это временно. Сейчас фокус на сам продукт, его код и другие организационные моменты.
3️⃣ У Angie есть свой Telegram канал - https://t.me/angie_software.
4️⃣ На сайте после моей заметки появилась обзорная статья: Сходства и различия Angie и nginx. (nginx почему-то с маленькой буквы, а Angie с большой 😁) Основные моменты оттуда (что-то в сокращении):
🔹в Angie нет кода NGINX Plus, закрытой коммерческой версии nginx; более того, у нас нет цели сделать наш платный веб-сервер, Angie PRO, стопроцентной функциональной копией NGINX Plus
🔹Angie сознательно ориентируется на платформы, для которых “официальный” nginx будет собираться еще нескоро: это такие сертифицированные в России ОС, как ALT Linux, Astra Linux SE и РЕД ОС, а также процессоры “Байкал” и “Эльбрус”.
🔹Мы решили упростить их жизнь и ведем единообразную сборку готовых пакетов для целого ряда таких модулей в своих репозиториях, используя свой опыт и знания.
Последнее прокомментирую, так как это важно. Разработчики Angie решили сами собирать популярные динамические модули веб сервера, чтобы упростить жизнь пользователям. Недавно у меня была публикация, где я рассказывал, как собрать Nginx с нужными модулями. А здесь разработчики озаботились и решили эту проблему сами. Список готовых модулей можно посмотреть на сайте. Там всё наиболее популярное присутствует (brotli, lua, geoip и т.д.) Не нашёл только vts. Думаю, разработчикам имеет смысл обратить на него внимание тоже. Все модули собраны в пакеты и доступны из репозитория. Вообще, это существенный плюс в пользу того, чтобы поставить Angie вместо Nginx, если тебе нужен какой-то модуль.
🔹Следующий фактор, на который мы обращаем внимание в своей работе, — ускорение работы самого веб-сервера за счет устранения лишних задержек. Мы:
◽добавили API-интерфейс динамической конфигурации и средства адаптивной DNS-адресации;
◽реализовали механизм привязки пользовательских сессий к проксируемому серверу;
◽внедрили активные проверки работоспособности проксируемых серверов, уменьшающие вероятность отправки реального запроса на неработающий сервер;
◽создали возможность сегментировать прокси-кэш, тем самым более эффективно задействуя все ресурсы сервера.
🔹Еще одна область, в которой мы хотим добиться улучшений, — это гибкость и удобство настройки веб-сервера. Мы:
◽добавили для групп проксируемых серверов упомянутый выше API-интерфейс динамической конфигурации;
◽предоставили ряд других настроек, менее масштабных, но весьма полезных.
🔹Наконец, важным для нас аспектом развития Angie является мониторинг состояния самого веб-сервера и проксируемых серверов. Мы:
◽реализовали в API-интерфейсе возможность получения базовой информации о веб-сервере, а также статистики по всем основным аспектам его функционирования в популярных современных форматах;
◽внедрили уже упомянутые активные проверки проксируемых серверов, самостоятельно следящие за их работоспособностью;
◽добавили семейство настроек для сбора статистики по сессиям передачи данных и запросам разрешения адресов.
Спасибо за подробные комментарии и описание отличий. Все эти изменения выглядят очень привлекательно для эксплуатации. Наглядно видно развитие и фокус внимания на реальные потребности пользователей. Обязательно попробую этот веб сервер в деле.
#webserver #nginx #angie #отечественное
Продолжу тему веб серверов, которую недавно начал. В свете последних новостей про Angie она заиграла новыми красками. Есть один популярный модуль, который часто используют и включают в различные сборки Nginx, типа nginx-more и не только. Речь пойдёт про модуль Headers More.
С помощью этого модуля можно очень гибко управлять добавлением или редактированием заголовков (headers). Стандартно Nginx позволяет добавлять заголовки только с помощью
В базовой сборке Nginx этого модуля нет. Чтобы добавить, нужно собрать его самостоятельно из исходников. Эту задачу существенно упростили разработчики Angie, собрав все популярные модули в своих репозиториях в виде пакетов. Так что дальше я покажу примеры с установкой и использованием модуля в этом веб сервере. Установить его сразу с нужным модулем проще простого. Показываю на примере Debian:
Установили веб сервер Angie с модулем headers-more. Чтобы подключить модуль, достаточно в конфиг
После этого можно управлять заголовками. Я покажу пару примеров, чтобы вы поняли суть. Для начала заменим стандартный заголовок Server, где веб сервер указывает свою версию, на что-то своё. Для этого в
Теперь сервер будет представляться как my_secret_server. Причём вы можете в разных виртуальных хостах указывать разное значение. Модуль headers-more позволяет управлять заголовками глобально для всего веб сервера, отдельно для каждого виртуального хоста или даже отдельного location. А также добавлять различные условия.
Например, вы можете добавить отдельный заголовок в какой-то виртуальный хост для всех запросов, которые будут отдавать 404-й код ответа. Делается это так:
Новый заголовок Error со значением 404 будет добавлен только к 404-м ошибкам. Через пробел можно добавить разные коды в одну настройку:
В заголовках можно и тип документа изменить. Например, отдадим страницу с 404 ошибкой в виде plain text, а не html, которая отдаётся по умолчанию:
Пример синтетический, чтоб показать возможности модуля. Если будете его тестировать, то на таких примерах легко проверить работу и разобраться в принципе работы.
В заголовки можно добавлять переменные, использовать условия, очищать или перезаписывать заголовки и т.д. Более подробно всё это можно посмотреть в описании модуля на github.
В ванильном Nginx всё это настраивается точно так же 1 в 1.
#webserver #angie #nginx
С помощью этого модуля можно очень гибко управлять добавлением или редактированием заголовков (headers). Стандартно Nginx позволяет добавлять заголовки только с помощью
add_header. Модуль Headers More существенно расширяет эту функциональность. Примеры я покажу ниже. В базовой сборке Nginx этого модуля нет. Чтобы добавить, нужно собрать его самостоятельно из исходников. Эту задачу существенно упростили разработчики Angie, собрав все популярные модули в своих репозиториях в виде пакетов. Так что дальше я покажу примеры с установкой и использованием модуля в этом веб сервере. Установить его сразу с нужным модулем проще простого. Показываю на примере Debian:
# curl -o /etc/apt/trusted.gpg.d/angie-signing.gpg \https://angie.software/keys/angie-signing.gpg# echo "deb https://download.angie.software/angie/debian/ `lsb_release -cs` main" \| tee /etc/apt/sources.list.d/angie.list > /dev/null# apt update && apt install angie angie-module-headers-moreУстановили веб сервер Angie с модулем headers-more. Чтобы подключить модуль, достаточно в конфиг
/etc/angie/angie.conf добавить в основную секцию main:load_module modules/ngx_http_headers_more_filter_module.so;После этого можно управлять заголовками. Я покажу пару примеров, чтобы вы поняли суть. Для начала заменим стандартный заголовок Server, где веб сервер указывает свою версию, на что-то своё. Для этого в
/etc/angie/angie.conf, в секцию http добавляем свой заголовок:more_set_headers "Server: my_secret_server";Теперь сервер будет представляться как my_secret_server. Причём вы можете в разных виртуальных хостах указывать разное значение. Модуль headers-more позволяет управлять заголовками глобально для всего веб сервера, отдельно для каждого виртуального хоста или даже отдельного location. А также добавлять различные условия.
Например, вы можете добавить отдельный заголовок в какой-то виртуальный хост для всех запросов, которые будут отдавать 404-й код ответа. Делается это так:
more_set_headers -s '404' 'Error: 404';Новый заголовок Error со значением 404 будет добавлен только к 404-м ошибкам. Через пробел можно добавить разные коды в одну настройку:
more_set_headers -s '404 500 502' 'Status: Not OK';В заголовках можно и тип документа изменить. Например, отдадим страницу с 404 ошибкой в виде plain text, а не html, которая отдаётся по умолчанию:
more_set_headers -s '404' -t 'text/html' 'Content-Type: text/plain' 'Error: 404 txt';Пример синтетический, чтоб показать возможности модуля. Если будете его тестировать, то на таких примерах легко проверить работу и разобраться в принципе работы.
В заголовки можно добавлять переменные, использовать условия, очищать или перезаписывать заголовки и т.д. Более подробно всё это можно посмотреть в описании модуля на github.
В ванильном Nginx всё это настраивается точно так же 1 в 1.
#webserver #angie #nginx
Постоянно приходится заниматься вопросами сбора и анализа логов веб серверов. Решил сделать подборку инструментов для этих целей от самых навороченных, типа ELK, до одиночных консольных утилит.
✅ Сам я чаще всего использую именно ELK, потому что привык к нему, умею настраивать, есть все заготовки и понимание, как собрать необходимые дашборды. Минусов у этого решения два:
◽ELK очень прожорливый.
◽Порог входа довольно высокий. Но тем не менее, ничего запредельного там нет. У меня знакомый с нуля по моей статье за несколько дней во всём разобрался. Немного позадавал мне вопросов, чтобы побыстрее вникнуть в суть. А дальше сам. В итоге всю базу освоил, логи собрал, дашборды сделал. В общем, было бы желание, можно и без дорогих курсов разобраться с основами. Сразу плюс к резюме и будущей зарплате.
Про #elk я много писал как здесь, так и на сайте есть разные статьи.
🟢 Альтернатива ELK - Loki от Grafana. Сразу скажу, что опыта с ним у меня нет. Так и не собрался, нигде его не внедрил. Всё как-то лениво. Использую привычные и знакомые инструменты. Плюсы у Loki по сравнению с ELK существенные, а конкретно:
◽кушает меньше ресурсов;
◽проще настроить и разобраться.
Из минусов — меньше гибкости и возможностей по сравнению с ELK, но во многих случаях всего этого и не надо. Если бы сейчас мне нужно было собрать логи веб сервера и я бы выбирал из незнакомых инструментов, начал бы с Loki.
🟢 Ещё один вариант — облачный сервис axiom.co. У него есть бесплатный тарифный план, куда можно очень быстро настроить отправку и хранение логов общим объёмом до 500 ГБ!!! Зачастую этого хватает за глаза. В него можно отправить распарсенные grok фильтром логи, как в ELK и настроить простенькие дашборды, которых во многих случаях хватит для простого анализа. Мне понравился этот сервис, использую его как дубль некоторых других систем. Денег же не просит, почему бы не использовать.
Далее упомяну системы попроще, для одиночных серверов. Даже не системы, а утилиты, которых иногда может оказаться достаточно.
🟡 Классная бесплатная утилита goaccess, которая умеет показывать статистику логов веб сервера в режиме онлайн в консоли. Либо генерировать статические html страницы для просмотра статистики в браузере. Устанавливается и настраивается очень легко и быстро. Подробности есть в моей заметке. Интересная программа, рекомендую. Пример html страницы.
🟡 Ещё один вариант консольной программы — lnav. Он заточен не только под веб сервер, но понимает и его формат в виде базовых настроек access логов.
Перечислю ещё несколько решений по теме для полноты картины, с которыми я сам не работал, но знаю про них: Graylog, OpenSearch.
❗️Если забыл что-то известное, удобное, подходящее, дополните в комментариях.
#logs #webserver #подборка
✅ Сам я чаще всего использую именно ELK, потому что привык к нему, умею настраивать, есть все заготовки и понимание, как собрать необходимые дашборды. Минусов у этого решения два:
◽ELK очень прожорливый.
◽Порог входа довольно высокий. Но тем не менее, ничего запредельного там нет. У меня знакомый с нуля по моей статье за несколько дней во всём разобрался. Немного позадавал мне вопросов, чтобы побыстрее вникнуть в суть. А дальше сам. В итоге всю базу освоил, логи собрал, дашборды сделал. В общем, было бы желание, можно и без дорогих курсов разобраться с основами. Сразу плюс к резюме и будущей зарплате.
Про #elk я много писал как здесь, так и на сайте есть разные статьи.
🟢 Альтернатива ELK - Loki от Grafana. Сразу скажу, что опыта с ним у меня нет. Так и не собрался, нигде его не внедрил. Всё как-то лениво. Использую привычные и знакомые инструменты. Плюсы у Loki по сравнению с ELK существенные, а конкретно:
◽кушает меньше ресурсов;
◽проще настроить и разобраться.
Из минусов — меньше гибкости и возможностей по сравнению с ELK, но во многих случаях всего этого и не надо. Если бы сейчас мне нужно было собрать логи веб сервера и я бы выбирал из незнакомых инструментов, начал бы с Loki.
🟢 Ещё один вариант — облачный сервис axiom.co. У него есть бесплатный тарифный план, куда можно очень быстро настроить отправку и хранение логов общим объёмом до 500 ГБ!!! Зачастую этого хватает за глаза. В него можно отправить распарсенные grok фильтром логи, как в ELK и настроить простенькие дашборды, которых во многих случаях хватит для простого анализа. Мне понравился этот сервис, использую его как дубль некоторых других систем. Денег же не просит, почему бы не использовать.
Далее упомяну системы попроще, для одиночных серверов. Даже не системы, а утилиты, которых иногда может оказаться достаточно.
🟡 Классная бесплатная утилита goaccess, которая умеет показывать статистику логов веб сервера в режиме онлайн в консоли. Либо генерировать статические html страницы для просмотра статистики в браузере. Устанавливается и настраивается очень легко и быстро. Подробности есть в моей заметке. Интересная программа, рекомендую. Пример html страницы.
🟡 Ещё один вариант консольной программы — lnav. Он заточен не только под веб сервер, но понимает и его формат в виде базовых настроек access логов.
Перечислю ещё несколько решений по теме для полноты картины, с которыми я сам не работал, но знаю про них: Graylog, OpenSearch.
❗️Если забыл что-то известное, удобное, подходящее, дополните в комментариях.
#logs #webserver #подборка
Увидел недавно в комментариях в ВК упоминание сборки XAMPP. Для тех, кто не в курсе, поясню, что это сборка локального веб-сервера, содержащая Apache, MariaDB, интерпретатор скриптов PHP, язык программирования Perl и большое количество дополнительных библиотек, позволяющих запустить полноценный веб-сервер. Подобные сборки были очень популярны лет 15-20 назад.
Среди подобных сборок наиболее популярны были Denver, позже появилась OSPanel, параллельно существовал и XAMPP. Я думал, что все эти панели уже отжили своё и исчезли. Оказывается, нет. Полностью устарел и давно не обновляется Denver. У OSPanel последнее обновление год назад, так что весь софт довольно свежий (PHP 8.1, MariaDB 10.8, MongoDB 6.0, Redis 7 и т.д.)
А живее всех живых оказался XAMPP. Он регулярно обновляется. Свежая версия на базе PHP 8.2.4. Удобство всех этих панелей в том, что не нужно разбираться с настройками серверной части. Запустил установщик и он всё сделал за тебя. То есть они ориентированы на разработчиков и служат только для локальной работы. Хотя некоторые не очень разумные люди использовали их и для прода.
Не знаю, кому сейчас это будет актуально. Все разработчики, кого я знаю последние 5-7 лет, худо бедно умеют настраивать локально или удалённо базовый стек веб сервера, с которым работают. Кто руками, кто скриптами, кто докером. Но раз уж справки навёл, поделился с вами. Может кому-то пригодится.
⇨ XAMPP: https://www.apachefriends.org (Windows, Linux, OSX)
⇨ OSPanel: https://ospanel.io (только Windows)
#webserver
Среди подобных сборок наиболее популярны были Denver, позже появилась OSPanel, параллельно существовал и XAMPP. Я думал, что все эти панели уже отжили своё и исчезли. Оказывается, нет. Полностью устарел и давно не обновляется Denver. У OSPanel последнее обновление год назад, так что весь софт довольно свежий (PHP 8.1, MariaDB 10.8, MongoDB 6.0, Redis 7 и т.д.)
А живее всех живых оказался XAMPP. Он регулярно обновляется. Свежая версия на базе PHP 8.2.4. Удобство всех этих панелей в том, что не нужно разбираться с настройками серверной части. Запустил установщик и он всё сделал за тебя. То есть они ориентированы на разработчиков и служат только для локальной работы. Хотя некоторые не очень разумные люди использовали их и для прода.
Не знаю, кому сейчас это будет актуально. Все разработчики, кого я знаю последние 5-7 лет, худо бедно умеют настраивать локально или удалённо базовый стек веб сервера, с которым работают. Кто руками, кто скриптами, кто докером. Но раз уж справки навёл, поделился с вами. Может кому-то пригодится.
⇨ XAMPP: https://www.apachefriends.org (Windows, Linux, OSX)
⇨ OSPanel: https://ospanel.io (только Windows)
#webserver
Если у вас есть желание максимально быстро и без лишних телодвижений проанализировать логи веб сервера, то можно воспользоваться типичной windows way программой http Logs Viewer. Скачиваете, устанавливаете, открываете в ней свой лог.
Программа платная, но базовые возможности доступны в бесплатной версии. После открытия лога она автоматом парсит значения из него в виде типовых полей: url, код ответа, IP адрес и т.д. Для IP адреса сразу же определяет страну. Можно тут же сделать сортировку по странам, кодам ответа, урлу и прочим записям в логе.
Если загрузить большой лог, то можно по всем распознанным значениям посмотреть статистику за разные промежутки времени. Тут уже начинается платная функциональность. Бесплатно доступен очень ограниченный набор отчётов.
Программа удобная и простая. Кто привык тыкать мышкой, а не грепать в консоли, будет прям кайфово. Нашёл, отсортировал, скопировал, выгрузил и т.д. Всё наглядно с привычным скролом для больших списков. И никаких вам ELK.
⇨ Сайт
#webserver #logs
Программа платная, но базовые возможности доступны в бесплатной версии. После открытия лога она автоматом парсит значения из него в виде типовых полей: url, код ответа, IP адрес и т.д. Для IP адреса сразу же определяет страну. Можно тут же сделать сортировку по странам, кодам ответа, урлу и прочим записям в логе.
Если загрузить большой лог, то можно по всем распознанным значениям посмотреть статистику за разные промежутки времени. Тут уже начинается платная функциональность. Бесплатно доступен очень ограниченный набор отчётов.
Программа удобная и простая. Кто привык тыкать мышкой, а не грепать в консоли, будет прям кайфово. Нашёл, отсортировал, скопировал, выгрузил и т.д. Всё наглядно с привычным скролом для больших списков. И никаких вам ELK.
⇨ Сайт
#webserver #logs
Сегодня вышло крупное обновление веб сервера Angie 1.3.0. Кто не читал, посмотрите две мои предыдущие заметки про него (1, 2). Изменения затронули open source версию, так что попробовать и оценить их сможет каждый.
Перечислю наиболее заметные нововведения.
1️⃣ В конфигурации location теперь можно использовать одновременно несколько шаблонов uri. Это упрощает конфигурацию location с одинаковыми настройками. То есть можно сделать примерно вот так:
Сейчас у меня то же самое записано вот так:
Там есть нюанс, что между модификатором и uri не допускается пробел. Немного синтаксис другой получается, не как у одиночных шаблонов. Я возможно что-то с синтаксисом напутал, но идею, думаю, вы поняли. Чуть позже обновится документация и можно будет уже точно смотреть, как это настраивается.
2️⃣ Angie научился самостоятельно экспортировать свою статистику в формате Prometheus, что явно упростит настройку мониторинга. Не нужен отдельный exporter для этих целей. Было бы неплохо сразу и шаблон для Zabbix сделать, не дожидаясь, пока кто-то из энтузиастов это реализует. Достаточно распарсить вывод для Prometheus.
3️⃣ Отдельной настройкой можно включить возможность экспорта содержимого конфигурационных файлов запущенной версии веб сервера через API.
Остальные изменения:
◽детальная информация и метрики по группам проксируемых stream-серверов в интерфейсе статистики, предоставляемом директивой "api"
◽опция "resolve" директивы "server" в блоке "upstream" модуля "stream", позволяющая отслеживать изменения списка IP-адресов, соответствующего доменному имени, и автоматически обновлять его без перезагрузки конфигурации
◽опция "service" директивы "server" в блоке "upstream" модуля "stream", позволяющая получать списки адресов из DNS-записей SRV, с базовой поддержкой приоритета
◽отображение номера поколения конфигурации в именах процессов, что позволяет с помощью утилиты "ps" отслеживать успех перезагрузок конфигурации и количество поколений рабочих процессов с предыдущими версиями конфигурации.
Согласитесь, изменения существенные, которые повышают удобство использования веб сервера. История с мониторингом особенно нравится. Плюс, не забываем, про готовые собранные наиболее популярные модули для веб сервера, которые можно ставить из собранных пакетов разработчиков и подключать в конфигурации. В бесплатной версии Nginx всего этого нет, что требует дополнительные телодвижения при настройке.
#webserver #angie
Перечислю наиболее заметные нововведения.
1️⃣ В конфигурации location теперь можно использовать одновременно несколько шаблонов uri. Это упрощает конфигурацию location с одинаковыми настройками. То есть можно сделать примерно вот так:
location =~/.git ~*^/(\.ht|xmlrpc\.php)${ return 404;}Сейчас у меня то же самое записано вот так:
location ~ /.git {return 404;}location ~* ^/(\.ht|xmlrpc\.php)$ { return 404;}Там есть нюанс, что между модификатором и uri не допускается пробел. Немного синтаксис другой получается, не как у одиночных шаблонов. Я возможно что-то с синтаксисом напутал, но идею, думаю, вы поняли. Чуть позже обновится документация и можно будет уже точно смотреть, как это настраивается.
2️⃣ Angie научился самостоятельно экспортировать свою статистику в формате Prometheus, что явно упростит настройку мониторинга. Не нужен отдельный exporter для этих целей. Было бы неплохо сразу и шаблон для Zabbix сделать, не дожидаясь, пока кто-то из энтузиастов это реализует. Достаточно распарсить вывод для Prometheus.
3️⃣ Отдельной настройкой можно включить возможность экспорта содержимого конфигурационных файлов запущенной версии веб сервера через API.
Остальные изменения:
◽детальная информация и метрики по группам проксируемых stream-серверов в интерфейсе статистики, предоставляемом директивой "api"
◽опция "resolve" директивы "server" в блоке "upstream" модуля "stream", позволяющая отслеживать изменения списка IP-адресов, соответствующего доменному имени, и автоматически обновлять его без перезагрузки конфигурации
◽опция "service" директивы "server" в блоке "upstream" модуля "stream", позволяющая получать списки адресов из DNS-записей SRV, с базовой поддержкой приоритета
◽отображение номера поколения конфигурации в именах процессов, что позволяет с помощью утилиты "ps" отслеживать успех перезагрузок конфигурации и количество поколений рабочих процессов с предыдущими версиями конфигурации.
Согласитесь, изменения существенные, которые повышают удобство использования веб сервера. История с мониторингом особенно нравится. Плюс, не забываем, про готовые собранные наиболее популярные модули для веб сервера, которые можно ставить из собранных пакетов разработчиков и подключать в конфигурации. В бесплатной версии Nginx всего этого нет, что требует дополнительные телодвижения при настройке.
#webserver #angie
Ко мне как то раз обратился человек за помощью в настройке веб сервера. Суть была вот в чём. У него есть контентный сайт, где он пишет хайповые статьи для сбора ситуативного трафика. Монетизируется, соответственно, показами различной рекламы. Чем больше показов, тем больше доход.
И как-то раз одна его статья очень сильно выстрелила, так что трафик полился огромным потоком с различных агрегаторов новостей и ссылок с других статей. В итоге сайт у него начал падать. У него был некий админ-программист, который занимался сайтом. Он с самого начала потока трафика предпринимал какие-то действия, что помогало не очень. Кардинально решить проблему не мог. Сайт всё равно тормозил и часто отдавал 502 ошибку.
Я отказался помогать, потому что в принципе не занимаюсь разовыми задачами, тем более уже в условиях катастрофы, тем более без запланированного заранее времени. Да ещё на сервере, где непонятно кем и как всё настраивалось. Но для себя пометочку сделал, как лучше всего оперативно выкрутиться в такой ситуации. Сейчас с вами поделюсь примерным ходом решения этой задачи.
Проще всего в такой ситуации поднять прокси сервер на Nginx и тупо всё закэшировать. Причём настроить кэш так, что если сам сайт лёг, то кэш будет отдавать статические страницы, которые он предварительно сохранил, несмотря на то, что сам сайт динамический. Когда нам во что бы то ни стало надо показывать контент, такой вариант сойдёт. При этом сам прокси сервер можно разместить где угодно, создав виртуалку с достаточными ресурсами. Пока будут обновляться DNS записи, такую же прокси можно воткнуть прямо там же на виртуалке с сайтом, а кэш разместить в оперативной памяти.
Настройка простая и быстрая, так что если ранее вы тестировали такой вариант и сохранили конфиг, то всё настроить можно буквально за 5 минут. Ставим на сервер Nginx, если его ещё нет, и добавляем в основной конфиг, в секцию http:
Создаём директорию
Теперь открываем настройки виртуального хоста и добавляем туда в секцию server и location примерно следующее:
Я не буду описывать эти параметры, так как заметка большая получается. Они все есть в документации Nginx на русском языке.
Основной веб сервер живёт по адресу http://10.20.1.36:81, туда мы проксируем все соединения. Весь кэш складываем в директорию
Я вот прямо сейчас всё это протестировал на тестовом стенде. Поднял в Docker контейнерах сайт на Wordpress, который на php. В качестве веб сервера использовал Apache. И тут же на хосте поднял проксирующий Nginx. Походил по страницам сайта, закешировал их. Убедился, что в директории
Важно понимать, что такое грубое кэширование - это крайний случай. Подойдёт только для полностью статических сайтов, которых сейчас почти нет. Для динамического сайта решать вопросы постоянного кэширования придётся другими методами. Но в случае внезапной нагрузки можно поступить и так. Потом этот кэш отключить. Самое главное, что рабочую инфраструктуру можно не трогать при этом. Просто ставим на вход прокси. Когда она не нужна, отключаем её и работаем как прежде.
#nginx #webserver
И как-то раз одна его статья очень сильно выстрелила, так что трафик полился огромным потоком с различных агрегаторов новостей и ссылок с других статей. В итоге сайт у него начал падать. У него был некий админ-программист, который занимался сайтом. Он с самого начала потока трафика предпринимал какие-то действия, что помогало не очень. Кардинально решить проблему не мог. Сайт всё равно тормозил и часто отдавал 502 ошибку.
Я отказался помогать, потому что в принципе не занимаюсь разовыми задачами, тем более уже в условиях катастрофы, тем более без запланированного заранее времени. Да ещё на сервере, где непонятно кем и как всё настраивалось. Но для себя пометочку сделал, как лучше всего оперативно выкрутиться в такой ситуации. Сейчас с вами поделюсь примерным ходом решения этой задачи.
Проще всего в такой ситуации поднять прокси сервер на Nginx и тупо всё закэшировать. Причём настроить кэш так, что если сам сайт лёг, то кэш будет отдавать статические страницы, которые он предварительно сохранил, несмотря на то, что сам сайт динамический. Когда нам во что бы то ни стало надо показывать контент, такой вариант сойдёт. При этом сам прокси сервер можно разместить где угодно, создав виртуалку с достаточными ресурсами. Пока будут обновляться DNS записи, такую же прокси можно воткнуть прямо там же на виртуалке с сайтом, а кэш разместить в оперативной памяти.
Настройка простая и быстрая, так что если ранее вы тестировали такой вариант и сохранили конфиг, то всё настроить можно буквально за 5 минут. Ставим на сервер Nginx, если его ещё нет, и добавляем в основной конфиг, в секцию http:
http { ... proxy_cache_path /var/cache/nginx keys_zone=my_cache:10m inactive=1w max_size=1G; ...}Создаём директорию
/var/cache/nginx и делаем владельцем пользователя, под которым работает веб сервер. Теперь открываем настройки виртуального хоста и добавляем туда в секцию server и location примерно следующее:
server { ... proxy_cache my_cache; ... location / { proxy_set_header Host $host; proxy_pass http://10.20.1.36:81; proxy_cache_key $scheme://$host$uri$is_args$query_string; proxy_cache_valid 200 30m; proxy_cache_bypass $arg_bypass_cache; proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504 http_429; }}Я не буду описывать эти параметры, так как заметка большая получается. Они все есть в документации Nginx на русском языке.
Основной веб сервер живёт по адресу http://10.20.1.36:81, туда мы проксируем все соединения. Весь кэш складываем в директорию
/var/cache/nginx, можете сходить туда и убедиться. Если используется gzip, то там будут сжатые файлы. Теперь, даже если веб сервер 10.20.1.36:81 умрёт, прокси сервер всё равно будет отдавать статические страницы. Я вот прямо сейчас всё это протестировал на тестовом стенде. Поднял в Docker контейнерах сайт на Wordpress, который на php. В качестве веб сервера использовал Apache. И тут же на хосте поднял проксирующий Nginx. Походил по страницам сайта, закешировал их. Убедился, что в директории
/var/cache/nginx появились эти страницы. Отключил контейнер с Wordpress, сайт продолжил работать в виде закэшированной статики на прокси. Важно понимать, что такое грубое кэширование - это крайний случай. Подойдёт только для полностью статических сайтов, которых сейчас почти нет. Для динамического сайта решать вопросы постоянного кэширования придётся другими методами. Но в случае внезапной нагрузки можно поступить и так. Потом этот кэш отключить. Самое главное, что рабочую инфраструктуру можно не трогать при этом. Просто ставим на вход прокси. Когда она не нужна, отключаем её и работаем как прежде.
#nginx #webserver
