​​Продолжу тему веб серверов, которую недавно начал. В свете последних новостей про Angie она заиграла новыми красками. Есть один популярный модуль, который часто используют и включают в различные сборки Nginx, типа nginx-more и не только. Речь пойдёт про модуль Headers More.

С помощью этого модуля можно очень гибко управлять добавлением или редактированием заголовков (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 #подборка

​​Увидел недавно в комментариях в ВК упоминание сборки 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

​​Если у вас есть желание максимально быстро и без лишних телодвижений проанализировать логи веб сервера, то можно воспользоваться типичной windows way программой http Logs Viewer. Скачиваете, устанавливаете, открываете в ней свой лог.

Программа платная, но базовые возможности доступны в бесплатной версии. После открытия лога она автоматом парсит значения из него в виде типовых полей: url, код ответа, IP адрес и т.д. Для IP адреса сразу же определяет страну. Можно тут же сделать сортировку по странам, кодам ответа, урлу и прочим записям в логе.

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

Программа удобная и простая. Кто привык тыкать мышкой, а не грепать в консоли, будет прям кайфово. Нашёл, отсортировал, скопировал, выгрузил и т.д. Всё наглядно с привычным скролом для больших списков. И никаких вам ELK.

⇨ Сайт

#webserver #logs

​​Сегодня вышло крупное обновление веб сервера Angie 1.3.0. Кто не читал, посмотрите две мои предыдущие заметки про него (1, 2). Изменения затронули open source версию, так что попробовать и оценить их сможет каждый.

Перечислю наиболее заметные нововведения.

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:

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

​​Расскажу про систему построения отказоустойчивого сервиса из подручных средств по цене аренды железа. Я её когда-то придумал, протестировал и использовал некоторое время для одного сайта. Не могу сказать, что мне понравилось, как всё это работало, но там были частности в виде репликации СУБД, у которой может быть разное решение, которое на саму схему не влияет.

Допустим, у вас условно есть 2 виртуалки в разных датацентрах. Это могут быть и полноценные сервера, и группы серверов. В данном случае это не принципиально. И вы хотите разместить на них сайт, чтобы в случае недоступности одной виртуальной машины, все клиенты автоматом обращались ко второй с минимальным простонем и без какого-либо участия человека, то есть полностью автоматически.

Реализовать это можно следующим образом. На каждой виртуалке настраиваем DNS сервер, например, bind (named). Поднимаем там зону своего сайта, указывая в A записи IP адрес своей виртуалки. То есть каждый DNS сервер резолвит имя сайта в свой IP адрес. TTL записи ставим как можно меньше, в зависимости от того, как быстро вы хотите переключить клиентов. Думаю, имеет смысл поставить 1-2 минуты.

У регистратора сайта в качестве NS серверов указываем 2 своих DNS сервера. Когда клиент будет резолвить адрес сайта, регистратор выдаст ему один из NS серверов, который отрезолвит свой IP адрес и клиент попадёт на сайт. Если один из NS серверов станет недоступен, то клиент снова обратится к регистратору и тот автоматически будет отдавать другой NS сервер, который, если доступен, будет резолвить свой IP адрес. В итоге все запросы будут автоматически попадать на активный NS сервер, и, соответственно, на работающий веб сервер.

Если на одной из виртуалок погасить bind, то весь трафик с него в течении нескольких минут уедет на второй сервер. И можно проводить профилактику.

У такой схемы есть масса нюансов. Первое и самое главное. Если используется СУБД, то вам нужна Master-Master репликация, так как в обычном режиме, когда работают оба сервера, запросы на чтение и запись идут на оба параллельно. Я использовал MySQL и там куча нюансов с репликацией, так что нельзя сказать, что всё работало автоматически. С репликацией приходилось разбираться вручную после аварий, так что полной автоматики не получалось.

Но это, как я уже сказал, частности конкретной реализации. Можно использовать прокси для MySQL на обоих машинах и запись вести с обоих серверов в одну СУБД, которая будет синхронизироваться со второй, а в случае аварии эти прокси переключаются на запись в другую живую СУБД.

С файлами всё проще. Их синхронизация - дело техники. Для статики можно использовать внешнее S3 хранилище или синхронизироваться тем же rsync или csync2. Если хостов больше двух, то вариантов ещё больше. Можно и ceph развернуть. Отдельный вопрос с сессиями пользователей. Это уже нужно решать на уровне приложения.

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

Конечно, всё намного проще, когда есть какой-то внешний арбитр, который управляет трафиком. Это может быть какой-то готовый сервис. Но он и будет основной точкой отказа. Ляжет он, ляжет всё остальное. А тут независимая схема, которая, если всё аккуратно настроить, будет работать сама по себе без внешнего арбитра.

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

#webserver

​​В предпоследнем обновлении веб сервера Angie, которое я из-за занятости пропустил, была анонсирована удобная веб панель наблюдения за сервером - Console Light. Только в последнем обновлении заметил это и решил навести справки.

Сразу покажу как поставить, потому что сам это проделал для того, чтобы оценить. Пример для 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 angie-console-light

Добавляем в конфиг виртуального хоста:
  location /console {
    #allow 127.0.0.1;
    #deny all;

    alias /usr/share/angie-console-light/html;
    index index.html;

    location /console/api/ {
      api /status/;
    }
  }

Доступ лучше ограничить списком адресов. Я убрал ограничение для локального теста. Набор доступных виджетов и метрик в них зависит от настроек панели. К примеру, если хотите видеть через веб интерфейс конфигурационные файлы Angie с красивым форматированием и подсветкой синтаксиса, добавьте в location /console/api/ параметр api_config_files:

    location /console/api/ {
      api /status/;
      api_config_files on;
    }

Удобное новшество. Можно быстро оценить всю рабочую конфигурацию, собранную из всех присоединённых файлов. Очень удобно для окружения Bitrix, где этих конфигов десятки.

На тестовом сервере смотреть особо не на что, кроме базовых метрик по соединениям. Оценить функциональность панели можно в публичном демо:
⇨ https://console.angie.software

Статья с подробным описанием этой панели и всего мониторинга в целом есть на хабре:
⇨ Многогранный мониторинг Angie
И там же свежее интервью с руководителем отдела разработки:
⇨ Интервью с Валентином Бартеневым: как бывшие сотрудники Nginx разрабатывают отечественный веб-сервер Angie

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

Мне немного лениво работающие сервера переводить на Angie, но если что-то новое придётся настраивать, буду делать на нём. Плюсы относительно Nginx очевидны и наглядны. Готовый мониторинг и веб панель - это прям самый сок.

#angie #webserver #отечественное

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

Сторонним разработчикам, нанятым незадолго до НГ, нужна была копия сайта для разработки. Пока с ними договаривались (не я), обсуждали детали, наметили план, наступило 28-е, четверг. В пятницу я уже не успел ничего сделать и благоразумно отложил решение всех вопросов на рабочие дни после праздников, так как не предполагал, что в праздники кто-то будет что-то делать. Но разработчики очень попросили всё сделать заранее, так как планировали начать работы уже 2-го января. Вот ещё категория трудоголиков, которая любит работать в праздники.

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

Основная проблема в том, что сайт относительно большой, а свободных мощностей у компании мало. Все арендованные и дорогие. Нужно порядка 400 Гб места на дисках под сам сайт и база данных mysql примерно 10 гигов. Да ещё и сайт планировали с php 7.4 перенести на 8.0, так что нужна была отдельная виртуалка, где можно будет обновлять пакеты и будет полный доступ у разработчиков. Я перед началом работ прикинул и понял, что развернуть копию на длительное время тупо негде.

Что-то докупать или заказывать в праздники не получится, потому что нужно согласовывать расходы, оплачивать и заказывать. Начал искать варианты. У сайта есть директория с пользовательскими прикреплёнными файлами. Для разработки они не нужны, так что решил поднимать без них. Нашёл сервер, где было немного свободного места. Развернул там виртуалку, скопировал сайт без лишних файлов. Начал разворачивать базу, не хватает места. И сам дамп большой, и во время разворачивания надо много места.

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

Решил таким образом. Все данные таблицы в дампе располагаются между строк Dumping data for table нужной таблицы и Table structure, где начинается новая таблица. Вывел все такие строки в отдельный текстовый файл:

# grep -n 'Table structure\|Dumping data for table' dump.sql > tables.txt

Нашёл там нужную таблицу и номера первой и второй указанных строк. И потом вырезал всё, что между ними с помощью sed. Первое число — номер строки Dumping data for table, которую нужно удалить и всё, что за ней. Второе — номер строки, предшествующей записи Table structure, так как эту строку нужно оставить. Она относится к структуре новой таблицы.

# sed '22826,26719 d' dump.sql > cleanup.sql

Таким образом можно очистить все ненужные таблицы, оставив только их структуру.

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

❓Кто ещё работает в праздники? Чем занимаетесь? Я обычно что-то обновляю, переношу, пока никто не мешает. Но на этот НГ ничего не планировал. Столько лет всегда что-то делаю, что решил в этот раз отдохнуть.

#webserver

​​Я уже много раз упоминал про использование простейшего http сервера на базе python:

# python3 -m http.server 8000

Я его постоянно использую, когда надо быстро откуда-то забрать файлы без лишних телодвижений. Просто перехожу в нужную директорию, запускаю веб сервер, скачиваю файлы, открыв их по ip адресу сервера и завершаю работу веб сервера.

Мне понадобилось для проверки одного приложения запустить https сервер, так как по http оно не работает. Было лень настраивать для этого Nginx. Подумал, что наверное его так же можно быстро поднять с помощью python. Быстро нашёл решение.

Генерируем самоподписный ключ и сертификат в один файл:

# openssl req -new -x509 -keyout localhost.pem -out localhost.pem -days 365 -nodes

Создаём файл webserver.py следующего содержания:

import http.server, ssl

server_address = ('172.20.0.210', 8000)
httpd = http.server.HTTPServer(server_address, http.server.SimpleHTTPRequestHandler)
httpd.socket = ssl.wrap_socket(httpd.socket,server_side=True,certfile='localhost.pem',ssl_version=ssl.PROTOCOL_TLSv1_2)
httpd.serve_forever()

Запускаем веб сервер:

# python3 webserver.py

Идём по адресу https://172.20.0.210:8000 и видим содержимое директории или какой-то сайт, если в ней лежит index.html.

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

#webserver #python

​​Обращаю ваше внимание на сервис по генерации конфигов для Nginx. Я когда-то давно уже о нём рассказывал, но с тех пор прошло много лет.

⇨ https://www.digitalocean.com/community/tools/nginx

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

Указанный сервис очень удобен. Видно, что развивается. Раньше немного не так работал. Через форму на сайте указываете все нужные параметры и на выходе получается готовый набор конфигурационных файлов, разбитых по смыслу на части: отдельно общий конфиг, конфиг по безопасности, конфиг для специфических настроек wordpress, если укажите, что делаете конфигурацию для этой cms, отдельно настройки для letsencrypt и так далее.

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

◽генерации файла dhparam.pem, нужного для работы https с параметром ssl_dhparam:
◽создания каталога letsencrypt для подтверждения сертификатов;
◽инструкции по настройке certbot.

Я создал типовой для меня конфиг и сверился со своим. Увидел некоторые опции, которые раньше не использовал. Например:

▪ log_not_found - разрешает или запрещает записывать в error_log ошибки о том, что файл не найден. По умолчанию в nginx параметр включён и в error_log пишутся эти ошибки, сервис предлагает по умолчанию отключать. В принципе, смысл в этом есть. На практике error_log реально забивается этими записями, хотя чаще всего они не нужны, так как на работающий сайт постоянно кто-то стучится по несуществующим урлам. К себе тоже добавил этот параметр глобальноlog_not_found off; Раньше отключал только по месту для отдельных location, типа /favicon.ico или /robots.txt

▪ ssl_ciphers - обновил себе набор шифров. Я не вникаю в подробности набора, так как не особо в этом разбираюсь, да и не вижу большого смысла. Только учтите, что этот набор должен согласовываться с параметром ssl_protocols, где вы указываете список поддерживаемых версий TLS. Сейчас считается, что ниже TLSv1.2 использовать небезопасно.

▪ отдельно глобально вынесена блокировка всего, что начинается с точки, кроме директории .well-known, которую использует letsencrypt, и подключается ко всем виртуальным хостам:
location ~ /\.(?!well-known) {
  deny all;
Я обычно в каждом виртуальном хосте сначала разрешал .well-known, а потом блокировал всё, что начинается с точки:
location ~ /\.well-known\/acme-challenge {
  allow all;
}
location ~ /\. {
deny all;
  return 404;
}
То, как предлагает сервис, сделано удобнее. Тоже забрал себе.

Ну и так далее. Не буду всё расписывать, так как у каждого свои шаблоны. В общем, сервис удобный и полезный. Рекомендую не просто забрать в закладки, но и провести аудит своих конфигов на предмет улучшения. А если настраиваете nginx редко, то просто пользуйтесь этим сервисов. Он рисует абсолютно адекватные и качественные конфиги.

#nginx #webserver

​​Для получения бесплатных TLS сертификатов от Let's Encrypt существуют два набора скриптов: certbot и acme.sh. Может ещё какие-то есть, но эти самые популярные. Certbot написан на python, acme.sh полностью на bash.

Я всегда использовал certbot. Просто привычка. Начал с него и всегда пользуюсь именно им. Много раз слышал, что acme.sh более удобен и функционален. Плюс, не привязан к версии python. Он вообще не нужен, хотя для базовых систем это не принципиально. Python обычно есть на всех полноценных системах Linux.

Решил я посмотреть на acme.sh и сравнить с certbot. Устанавливается он просто:

# curl https://get.acme.sh | sh -s email=my@example.com

Обязательно измените email. С указанным доменом example потом ничего выпустить не получится. Установщик делает 3 вещи:

1️⃣ Копирует скрипт acme.sh и некоторые конфиги в домашнюю директорию ~/.acme.sh/
2️⃣ Подключает в .bashrc окружение из ~/.acme.sh/acme.sh.env. По сути просто делает алиас alias acme.sh="/root/.acme.sh/acme.sh".
3️⃣ Добавляет в cron пользователя задачу на ежедневную попытку обновления сертификатов.

После этого можно сразу пробовать получить сертификат. Acme.sh поддерживает разные CA, поэтому надо явно указать letsencrypt:

# acme.sh --issue --server letsencrypt -d 329415.simplecloud.ru -w /var/www/html

Если всё прошло без ошибок, то в директории ~/.acme.sh появится папка с именем домена, где будет лежать сертификат, ключ и некоторые настройки для этого домена. Теперь можно куда-то скопировать этот сертификат с ключом и перезапустить веб сервер. Например, в директорию /etc/nginx/certs/. Можно это сделать вручную, а можно через тот же acme.sh:

acme.sh --install-cert -d 329415.simplecloud.ru \
--key-file    /etc/nginx/certs/key.pem \
--fullchain-file /etc/nginx/certs/cert.pem \
--reloadcmd   "service nginx force-reload"

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

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

# apt install certbot
а не так:
# curl https://get.acme.sh | sh -

Если кто-то пользуется acme.sh и знает его явные преимущества, прошу поделиться информацией.

⇨ Исходники

#webserver

​​Как быстро и малыми усилиями попытаться выяснить, почему что-то тормозит в php коде сайта? Расскажу, с чего уместнее всего начать расследование, если вы используете php-fpm. Если нет каких-то особых требований, то лично я всегда исользую именно его.

У него есть две простые настройки, которые можно применить в нужном пуле, когда проводите расследование:

slowlog = /var/log/php-fpm/site01.ru.slow.log
request_slowlog_timeout = 1s

Таймаут выставляете под свои требования. Если сайт в целом тормозной (bitrix, админка wordpress), то 1 секунда слишком малый интервал, но в идеале хочется, чтобы весь код выполнялся быстрее этого времени.

Далее необходимо перезаустить php-fpm и идти смотреть лог:

# systemctl restart php8.0-fpm

В логе запросов будет не только информация о скрипте, который долго выполняется, но и его трассировака. Она будет включать в себя все инклюды и функции. То, что было вызвано сначала, будет внизу трейса, последняя функция - в самом верху. Причём верхней функцией будет та, что выполнялась в момент наступления времени, указанного в request_slowlog_timeout. Часто именно она и причина тормозов.

Разобраться во всём этом не такая простая задача, но в целом выполнимая даже админом. Самое главное, что иногда можно сразу получить подсказку, которая ответит на ворос о том, что именно томозит. Бывает не понятно, какой именно запрос приводит к выполнению того или иного скрипта. Нужно сопоставить по времени запрос в access.log веб сервера и slowlog php-fpm. 

Очень часто тормозят какие-то заросы к внешним сервисам. Они могут делаться, к примеру, через curl_exec. И вы это сразу увидите в slowlog в самом верху трейса. Нужно будет только пройтись по функуциям и зависимостям, и найти то место, откуда функция с curl вызывается. Также часто в самом верху трейса можно увидеть функцию mysqli_query или что-то в этом роде. Тогда понятно, что тормозят запросы к базе.

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

#php #webserver #perfomance

У сайтов на Bitrix существует одна особенность. Специально выделил жирным, потому что это такая особенность, что всем особенностям особенность. В админке можно править исходники сайта прямо наживую, в том числе и служебные файлы .htaccess. Любой, кто имеет доступ к админке, может грохнуть сайт. И это время от времени случается.

Вчера грохнули сайт по похожей схеме. Сеошник добавлял редиректы правкой .htaccess через админку. Редиректов там сотни. Сайт очень старый. Его развивали и поддерживали за последние лет 10 несколько разных компаний и программистов. Правку файлов тоже на постоянной основе делают несколько человек - как минимум сеошник и контент менеджер.

Из-за ошибки в .htaccess апач на каждый запрос отдавал 500-ю ошибку. Это я уже потом узнал. Сначала зашёл на сервер, сразу посмотрел изменения за последние сутки:

# find /home/bitrix/ext_www/site01 -mtime -1 -ls

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

# sdiff /root/restored/.htaccess /home/bitrix/ext_www/site01/.htaccess

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

⇨ http://www.htaccesscheck.com (полезный, стоит сохранить)

Забавное вступительное слово у сервиса:

"Sick of one silly typo in a .htaccess file causing your entire site to be broken?" - "Устали, что банальная опечатка в .htaccess, роняет весь сайт?"

Это такая фишка Апача. И плюс, и минус одновременно.

Сервис показал ошибку. Один url, куда был направлен 301 редирект, был некорректный по формату. Из-за этого Apache на все запросы возвращал 500-ю ошибку. Я удивился от этого. Не припоминаю, что сталкивался с этим раньше. Как-то нелогично. Одно дело давать ошибку на конкретный редирект, а другое руинить всю свою работу из-за него.

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

#bitrix #webserver #apache

​​Один подписчик поделился со мной информацией о необычном и полезном программном продукте. Изначально он обратился ко мне с просьбой подсказать, какой веб сервер под Windows можно использовать для быстрого запуска локально с флешки размещённого там небольшого проекта. Первое, что мне пришло в голову - Caddy. Это максимально простой веб сервер, состоящий из одного бинарника на Go, который всю конфигурацию хранит в едином конфиге. Версия под Windows тоже есть.

Он в итоге нашёл для себя вариант ещё проще и лучше - Small HTTP server. Пошёл, посмотрел, что это такое. Очень заинтересовала программа. Раньше про неё не слышал. Она из далёкого прошлого. Написана изначально была под Windows 95 и NT, но развивается до сих пор. Свежий релиз от 24.03.24. Код, как я понял, написан на С++ и очень хорошо оптимизирован. Установщик занимает примерно 1 мегабайт (❗️). При этом программа имеет следующие возможности:

◽HTTP сервер. Поддерживает CGI и FastCGI интерфейсы для скриптов (запуск исполняемых файлов; Perl, PHP, и других внешних интерпретаторов), ISAPI (Internet Server API — API для веб-сервера IIS) интерфейс, виртуальные хосты и каталоги.

◽Почтовый сервер POP3 и SMTP. Анти-спам фильтры. Белый, чёрный, и серый списки общие для всех и персональные для каждого пользователя. Переотправка и возможности запускать скрипты для входящих сообщений. Запуск внешнего антивируса.

◽FTP сервер с виртуальными каталогами.

◽HTTP proxy сервер. Поддерживаются HTTP, FTP, HTTPS запросы
Сохранение большого объема трафика, быстрый доступ. Внутренняя докачка при разрывах соединения. Сервер может запрашивать сжатый контент и распаковывать ответ на лету (с использованием внешней Zlib библиотеке).

◽DNS сервер. 🔥Опция динамической проверки сервиса на удаленном хосту и если сервис не работает, автоматическая замена одного IP адреса на другой во всех запросах. Рекурсивный поиск имен от корневых DNS серверов или от DNS серверов провайдера. Кеширование. Опция автоматического ответа на запросы IPv6 адреса. (для сетей, не использующих Internet по IPv6). DNSBL сервер (работает совместно с SMTP). DNS через HTTP(S) известный как DoH (RFC8484).

◽DHCP сервер.

◽HTTP TLS VPN сервер и клиент! Используется OpenVPN Windows TAP драйвер. Описание, как это работает и для чего.

Всё это собрано под Windows и Linux, в том числе ARM. Для Debian есть готовый пакет. Хорошее решение для маломощных одноплатников.

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

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

Предлагаю автору накидать звёздочек в github и подписаться на Telegram канал. Думаю, ему будет приятно. Программа реально интересная и необычная. Не знаю, что за мотивация у человека столько лет её развивать и поддерживать.

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

⇨ Сайт / Исходники / TG канал

#webserver #dns #dhcp #ftp

​​Сейчас без HTTPS не хотят работать многие сервисы. А даже если и работают, то браузеры не дадут спокойно пользоваться. Поэтому приходится получать и настраивать сертификаты, даже если большой нужды в этом нет. Особенно если ты работаешь с ним один в локальной сети, либо вообще поднимаешь временно. Я обычно получаю сертификаты let's encrypt и копирую на нужный сервер, если к нему не проброшен доступ из интернета.

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

Будем выпускать сертификат для доменного имени zabbix.internal и IP адреса 172.30.245.222. Будет работать и так, и эдак.

Выпускаем ключ и сертификат для своего CA:

# mkdir ~/tls && cd ~/tls
# openssl ecparam -out myCA.key -name prime256v1 -genkey
# openssl req -x509 -new -nodes -key myCA.key -sha256 -days 9999 -out myCA.crt

Вам зададут серию вопросов. Отвечать можно всё, что угодно. В данном случае это не важно. Выпускаем ключ и сертификат для сервера:

# openssl genrsa -out zabbix.internal.key 2048
# openssl req -new -key zabbix.internal.key -out zabbix.internal.csr

Тут тоже зададут похожие вопросы. Отвечать можно всё, что угодно. Готовим конфигурационный файл:

# mcedit zabbix.internal.ext

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
IP.1 = 172.30.245.222
DNS.1 = zabbix.internal

Генерируем сертификат на его основе:

# openssl x509 -req -in zabbix.internal.csr -CA myCA.crt -CAkey myCA.key \
-CAcreateserial -out zabbix.internal.crt -days 9999 -sha256 -extfile zabbix.internal.ext

Копируем сертификат и ключ в директорию веб сервера:

# mkdir /etc/nginx/certs
# cp zabbix.internal.crt /etc/nginx/certs/.
# cp zabbix.internal.key /etc/nginx/certs/.

Создаём файл dhparam, который понадобится для конфигурации Nginx:

# openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

Добавляем в конфиг Nginx в целевом виртуальном хосте:

listen     443 http2 ssl;
server_name   zabbix.internal 172.30.245.222;
ssl_certificate /etc/nginx/certs/zabbix.internal.crt;
ssl_certificate_key /etc/nginx/certs/zabbix.internal.key;
ssl_dhparam /etc/ssl/certs/dhparam.pem;

Перезапускаем Nginx:

# nginx -t
# nginx -s reload

Передаём на свой компьютер файл myCA.crt и добавляем его в хранилище корневых доверенных центров сертификации. Настройка будет зависеть от операционной системы. Если нужно тут же, локально на сервере с Debian 12 настроить доверие этому CA, то делаем так:

# cp myCA.crt /usr/local/share/ca-certificates/.
# update-ca-certificates

Теперь можно браузером заходить по доменному имени или IP адресу, будет работать самоподписанный сертификат на 9999 дней без каких-либо предупреждений.

Получилась готовая инструкция для копипаста, которую можно сохранить и пользоваться.

#webserver

​​Существует эффективный стандарт сжатия zstd. Не так давно современные браузеры стали его поддерживать, так что можно использовать в веб серверах. Разработчики Angie подсуетились и подготовили модуль для своего веб сервера, так что включить сжатие zstd максимально просто и быстро. Достаточно установить модуль в виде deb пакета и добавить настройки в конфигурацию, которые идентичны настройкам gzip, только название меняется на zstd.

По этому поводу вышел очень информативный ролик на ютубе:

⇨ Zstd (Zstandard): новый стандарт сжатия текста. Полный тест

Автор не только показал, как настроить zstd на веб сервере, но и сравнил его эффективность с привычными gzip и brotli. Результаты тестирования в динамическом сжатии получились очень любопытные. Zstd оказался лучше всех. Но если разница с brotli не сильно заметна, то вот gzip на фоне остальных выглядит очень медленным. Буквально в разы в некоторых случаях.

Я решил провести свои тесты, чтобы убедиться в такой большой разнице. Сразу скажу, что если не настроено https, то браузеры не будут использовать ни brotli, ни zstd. Не знаю, с чем это связано, но я потратил некоторое время, пока не разобрался с тем, почему не работает ничего, кроме gzip. И второй момент. Если на веб сервере настроены все 3 типа сжатия, то разные браузеры выбирают разное сжатие: либо brotli, либо zstd. Gzip не выбирает никто.

Тестировал так же, как и автор ролика. Установил Angie и оба модуля сжатия:

# 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-zstd angie-module-brotli

Подключил оба модуля в angie.conf:

load_module modules/ngx_http_zstd_static_module.so;
load_module modules/ngx_http_zstd_filter_module.so;
load_module modules/ngx_http_brotli_static_module.so;
load_module modules/ngx_http_brotli_filter_module.so;

И добавил для них настройки:

  gzip on;
  gzip_static on;
  gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript image/x-icon image/svg+xml application/x-font-ttf;
  gzip_comp_level 4;
  gzip_proxied any;
  gzip_min_length 1000;
  gzip_vary on;

  brotli on;
  brotli_static on;
  brotli_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript image/x-icon image/svg+xml application/x-font-ttf;
  brotli_comp_level 4;

  zstd on;
  zstd_static on;
  zstd_min_length 256;
  zstd_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript image/x-icon image/svg+xml application/x-font-ttf;
  zstd_comp_level 4;

Если использовать ванильный Nginx, то придётся самостоятельно собирать его с нужными модулями 🤷‍♂️

Тестировал с помощью ab, передавая ему метод компрессии через заголовок:

# ab -n 1000 -k -c 1 -H "Accept-Encoding: zstd" https://10.20.1.36/scripts.js

Не буду приводить свои результаты, так как они получились примерно такие же, как у автора ролика, только разница между zstd и brotli с компрессией 4 поменьше. Zstd по rps (247) быстрее всех. Brotli чуть лучше жмёт в плане объёма, то есть трафик будет ниже, но и rps (211) немного меньше, чем у zstd.

В Angie очень легко настроить и brotli, и zstd, и gzip, так что имеет смысл это сделать. Клиент пусть сам выбирает, какой тип сжатия он будет использовать.

Один важный момент, который я вынес из этой темы. Не нужно ставить сжатие выше 3 или 4. Дальше идёт очень существенное падение производительности при незначительном уменьшении размера файлов. Я раньше бездумно ставил 9 и думал, что современные процессоры и так нормально вытягивают, если сервер не нагружен в потолок. Это не так. Смысла в высокой компрессии нет.

#webserver #angie

​​Для управления веб сервером есть множество готовых веб панелей. Основная проблема их использования - дополнительный вектор атаки сервера через эту веб панель. Причём, случается это довольно часто. В идеале, доступ к веб панели управления хостингом должен быть ограничен. Второй момент - часто веб панели раскидывают конфиги в нестандартные места, переписывают их после перезапуска службы управления. Это часто делает невозможным изменение конфигов вне веб панели, а иногда хочется, так как их возможности ограничены.

Есть промежуточные варианты автоматизации и упрощения управления веб хостингом. Набор консольных инструментов для управления. Наглядным примером подобного продукта является Bitrixenv. Это инструмент для автоматической настройки и управления веб хостингом для размещения сайтов на движке Битрикс.

Для сайтов на Wordpress есть похожий продукт - WordOps. Он позволяет автоматически разворачивать готовое окружение для сайтов на базе Wordpress, а так же любых других статических или php сайтов.

Установить WordOps можно автоматически прямо на сервер:

# wget -qO wo wops.cc && bash wo

Скрипт установки выполняет несколько простых шагов:
◽устанавливает необходимые системные пакеты
◽создаёт директории
◽устанавливает WordOps через pip
◽устанавливает acme.sh и WP-CLI

Всё это можно проделать и вручную. После установки становятся доступны консольные команды для управления хостингом. Создадим сайт Wordpress на php81 с сертификатом от Let's Encrypt:

# wo site create 330693.simplecloud.ru --wp --php81 -le

Эта команда выполнит следующие действия:
▪️ добавит репозитории Nginx, Php, MySQL в систему
▪️ установит все необходимые пакеты
▪️ создаст конфигурации Nginx и Php-fpm
▪️ получит tls сертификаты для домена
▪️ установит последнюю версию wordpress
▪️ создаст и настроит подключение к базе данных

В консоли вы получите адрес созданного сайта и учётную запись админа. При этом в директории /etc/nginx/sites-enabled будет создана конфигурация для сайта. Причём довольно навороченная. Там сразу будут лимиты на wp-cron.php и wp-login.php, ограничение доступа белым списком к xmlrpc.php, блокировка доступа к некоторым другим внутренностям Wordpress. В директории /var/www/330693.simplecloud.ru будут лежать исходники сайта, логи и некоторые настройки. В рутовском кроне /var/spool/cron/crontabs будут добавлены задания на обновление сертификатов и некоторые другие действия. Все конфигурации в стандартном формате и на своих местах. Искать ничего не надо.

Помимо Wordpress сайтов, можно создать обычный html или php:

# wo site create site.tld --html
# wo site create site.tld --mysql --php81

Из минусов сразу отмечу, то все сайты одной версии php создаются общим пулом php-fpm. Лучше было бы их разделять между собой.

Помимо управления сайтами, у WordOps есть и другие команды, с помощью которых, к примеру, можно:
● обновить системные пакеты
● настроить некоторые параметры ssh
● установить phpMyAdmin, Adminer, Dashboard, Netdata, MySQLTuner, eXtplorer Filemanager, Fail2ban, proftpd и некоторые другие программы
● посмотреть логи служб

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

Про WordOps узнал случайно. Увидел упоминание в комментариях. Сам никогда не пользовался, но мне понравилось, как всё сделано - просто и удобно. Меняются системные конфигурации, при этом всё остаётся на своих местах. Можно руками что-то подправить и это ничего не сломает. Панель просто помогает выполнить настройку.

Подобный инструмент существенно упрощает и ускоряет настройку веб сервера. Желательно им пользоваться, если вы уже умеете настраивать всё это вручную сами. Либо вы далеки от темы настройки веб серверов, а вам его нужно поднять. Для веб разработчиков это отличный инструмент, чтобы поставить на какой-нибудь свой тестовый сервер для разработки.

В документации с примерами показано, как всем этим управлять. Например, добавляем FTP пользователя или используем удалённый mysql сервер.

⇨ Сайт / Исходники

#webserver

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

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

Сразу покажу на практике, в чём заключается удобство Traefik и в каких случаях имеет смысл им воспользоваться. Для примера запущу через Traefik 2 проекта test1 и test2, состоящих из nginx и apache и тестовой страницы, где будет указано имя проекта. В этом примере будет наглядно виден принцип работы Traefik.

Запускаем Traefik через docker-compose.yaml:

# mkdir traefik && cd traefik
# mcedit docker-compose.yaml

services:
  reverse-proxy:
    image: traefik:v3.0
    command: --api.insecure=true --providers.docker
    ports:
      - "80:80"
      - "8080:8080"
    networks:
      - traefik_default
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
networks:
    traefik_default:
      external: true

# docker compose up

Можно сходить в веб интерфейс по ip адресу сервера на порт 8080. Пока там пусто, так как нет проектов. Создаём первый тестовый проект. Готовим для него файлы:

# mkdir test1 && cd test1
# mcedit docker-compose.yaml

services:
  nginx:
    image: nginx:latest
    volumes:
    - ./app/index.html:/app/index.html
    - ./default.conf:/etc/nginx/conf.d/default.conf
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.nginx-test1.rule=Host(`test1.server.local`)"
      - "traefik.http.services.nginx-test1.loadbalancer.server.port=8080"
      - "traefik.docker.network=traefik_default"
    networks:
    - traefik_default
    - test1

  httpd:
    image: httpd:latest
    volumes:
    - ./app/index.html:/usr/local/apache2/htdocs/index.html
    networks:
      - test1

networks:
  traefik_default:
    external: true
  test1:
    internal: true

# mcedit default.conf 

server {
    listen 8080;
    server_name _;

    root /app;
    index index.php index.html;

    location / {
        proxy_pass http://httpd:80;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

# mcedit app/index.html

It's Container for project test1

Запускаем этот проект:

# docker compose up

В веб интерфейсе Traefik, в разделе HTTP появится запись:

Host(`test1.server.local`) http nginx-test1@docker  nginx-test1

Он по меткам в docker-compose проекта test1 автоматом подхватил настройки и включил проксирование всех запросов к домену test1.server.local в контейнер nginx-test1. При этом сам проект test1 внутри себя взаимодействует по своей внутренней сети test1, а с Traefik по сети traefik_default, которая является внешней для приёма запросов извне.

Теперь можно скопировать проект test1, изменить в нём имя домена и имя внутренней сети на test2 и запустить. Traefik автоматом подцепит этот проект и будет проксировать запросы к test2.server.local в nginx-test2. Работу этой схемы легко проверить, зайдя откуда-то извне браузером на test1.server.local и test2.server.local. Вы получите соответствующую страницу index.html от запрошенного проекта.

К Traefik легко добавить автоматическое получение TLS сертификатов от Let's Encrypt. Примеров в сети и документации много, настроить не составляет проблемы. Не стал показывать этот пример, так как не уместил бы его в формат заметки. Мне важно было показать суть - запустив один раз Traefik, можно его больше не трогать. По меткам в контейнерах он будет автоматом настраивать проксирование. В некоторых ситуациях это очень удобно.

#webserver #traefik #devops