Метка: nginx

  • WebP для картинок на сайте

    WebP для картинок на сайте

    В тесте для сайтов Page Speed Insights от Google есть рекомендация перевести все изображения в формат WebP. Формат разработали в Google, он открытый и основан на уже известном кодеке и форматах. Пользователи раньше не любили WebP, потому что не понимали как смотреть сохранённые картинки в устаревших программах.

    В чём же фишка и почему Google рекомендуют переходить на него?
    – JPG, GIF и PNG используют алгоритмы компрессии изображений, разработанные в прошлом веке.
    – WebP основан на эффективном видеокодеке VP8, который разработали для сжатия потоков видео.
    – Кодек пытается предсказать, какого цвета будут следующие пиксели и кодирует только отклонения от предсказания. Он просто старается не записывать информацию обо всех пикселях.
    – Лучше учитывает несовершенство человеческого зрения и делает картинку проще для кодирования с разницей незаметной для зрителя.
    – Поддерживает полупрозрачность, как PNG.
    – Компактнее хранит метаданные и меньше места тратит на технические заголовки файлов.

    Визуально неотличимые файлы получаются на 20-35% меньше, чем традиционные JPG и PNG. На многих сайтах картинки составляют большую часть веса, поэтому эта экономия значительно ускоряет загрузку.

    Чтобы WebP заработал на моём WordPress сайте, нужно проверить несколько вещей:
    – WebP поддерживается веб-сервером — для Caddy ничего делать не нужно, в NGINX или Apache2 я бы проверил поддержку mime-type.
    – WebP поддерживается сайтом — WordPress умеет распознавать WebP-файлы при загрузке.
    – Конвертировать уже загруженные картинки в WebP — я использую плагин EWWW Image Optimizer. Он бесплатно конвертирует все старые JPG прямо на сервере за пару минут.
    – Подменить старые форматы на новый в опубликованных постах. Для этого включаю автозамену картинок в том же плагине.

    Всё, на сайте работает WebP!

  • Попробовал модный веб-сервер Caddy вместо Nginx

    Попробовал модный веб-сервер Caddy вместо Nginx

    Попробовал модный веб-сервер Caddy вместо Nginx.

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

    NGINX (Engine X) — самый популярный веб-сервер (33% рынка), написанный на C. Изначально был написан 20 лет назад программистом из Rambler.
    Раньше Nginx многие использовали как обратный прокси для Apache2, чтобы его ускорить. Nginx занимался статичными файлами (картинки, CSS), а Apache2 запускал PHP-скрипты. Постепенно Apache2 стали убирать и всю работу переносить на Nginx, потому что он быстрее и лучше держит большие нагрузки. Есть большая экосистема дополнений, отличная документация и множество примеров использования. Стабильный продукт, с которым я работаю на всех проектах.

    А тут в инфополе стал мелькать Caddy. Чем же он покоряет разработчиков?
    – Более лёгкая конфигурация SSL-сертификатов. Точнее, её нет, Caddy делает всё сам — пользователю больше не нужно настраивать стандартные сертификаты Let’s Encrypt.
    – Поддержка HTTP/2 и HTTP/3 из коробки.
    – Поддержка компрессии gzip и zstd из коробки.
    – Простой синтаксис конфигурационных файлов. Очень похож на Nginx, но проще и яснее. Конфиги сокращаются в размере, вероятность ошибки ниже.
    – Caddy — это всего один исполняемый файл без зависимостей. Его легко устанавливать и обновлять.
    – Новый плагин можно подключить к Caddy без перезагрузки и простоя в работе.
    – После установки Caddy показал симпатичную страницу по-умолчанию с небольшой инструкцией.

    Есть у него и минус:
    – Caddy на предельной нагрузке может обработать меньше запросов, чем Nginx. Приоритет Caddy на простоте использования и автоматизации. На этом бенчмарке разница начинается от 10 тысяч запросов в секунду, что практически недостижимо для маленьких проектов.

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

    На моём сайте пока что висит статическая заглушка, вот весь конфиг:

    fullstackfounder.ru {  
           root * /var/www/fullstackfounder.ru/public  
           file_server  
           encode zstd gzip  
    }  
      
    www.fullstackfounder.ru {  
           redir https://fullstackfounder.ru{uri} permanent  
    }

    Аналогичный конфиг у Nginx выглядел бы вот так:

    server {
        listen 80;
        server_name fullstackfounder.ru www.fullstackfounder.ru;
    
        # Redirect all HTTP to HTTPS
        return 301 https://$host$request_uri;
    }
    
    server {
        listen 443 ssl http2;
        server_name fullstackfounder.ru;
    
        ssl_certificate     /etc/letsencrypt/live/fullstackfounder.ru/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/fullstackfounder.ru/privkey.pem;
        include             /etc/letsencrypt/options-ssl-nginx.conf;
        ssl_dhparam         /etc/letsencrypt/ssl-dhparams.pem;
    
        root /var/www/fullstackfounder.ru/public;
        index index.html index.htm;
    
        # Enable gzip
        gzip on;
        gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
    
        # Canonical redirect: www → non-www
        if ($host = 'www.fullstackfounder.ru') {
            return 301 https://fullstackfounder.ru$request_uri;
        }
    
        location / {
            try_files $uri $uri/ =404;
        }
    }

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

    Буду запускать на нём WordPress, посмотрим, что из этого выйдет.

  • Почему я выбираю VDS?

    Почему я выбираю VDS?

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

    Вот что я смогу сделать на VDS и не смогу на обычном хостинге:
    – Разместить на одном сервере сколько угодно сайтов и привязать к ним любое количество доменов.
    – Динамически менять ресурсы на сервере.
    – Не переживать, что мой сайт перенесли на другой сервер, поэтому нужно поменять IP-адрес в DNS. На шаред хостингах это могут делать несколько раз в год, нужно следить за уведомлениями, чтобы сайт не перестал работать.
    – Настроить сервер под меня с помощью пары ansible-скриптов.
    – Поставить нужный мне веб-сервер Caddy или кастомную сборку NGINX. Избежать Apache2, который до сих пор часто работает на шаред хостингах.
    – Разместить публичную папку сайта в любой папке, а не только в предварительно за меня выбранной public_html. Для моей сборки WP или Laravel это важно.
    – Установить git, composer, WP-CLI нужных мне версий и обновлять их самому.
    – Поставить любую версию PHP с нужными расширениями и оптимизировать все настройки, включая OpCache.
    – Настроить все параметры для базы данных MySQL.
    – Добавить сборщики для фронта (npm, pnpm).
    – Добавить memcached для кэширования в оперативной памяти — пригодится для ускорения WordPress.
    – Управлять логами, менять их формат, включать дополнительные логи для медленных скриптов и запросов. Размещать логи в нужной мне папке.
    – Поставить CI-агента от GitLab, который будет автоматически обновлять сайты после внесения изменений в Git.
    – Отключить FTP-протокол, чтобы сайт не взломали через утечку FTP-паролей.

    Создал VDS у Beget за 290 рублей в месяц.
    Конфигурация: CPU 1 core, 2 GB RAM, 10 GB NVMe, Ubuntu 24.04.

    Посты по теме:
    – План запуска блога
    – Удобный SSH-доступ
    – Выбор хостинга для сайта

  • Обнови свой HTTP

    Обнови свой HTTP

    Что такое:
    Протокол передачи данных HTTP применяется для всех сайтов в интернете.
    Все самые популярные веб-серверы по умолчанию используют устаревшую версию протокола HTTP/1.1. Apache2, NGINX, Node.js, uWSGI, Gunicorn, Tomcat, Jetty, IIS — все виновны.

    Браузер пытается одновременно скачать с сайта код, десятки картинок и скриптов. На HTTP/1.1 браузер открывает несколько параллельных соединений, в каждом из которых файлы загружаются по очереди. С HTTP/2 открывается одно соединение, по которому одновременно загружаются все файлы. HTTP/3 ещё быстрее и лучше работает в мобильных сетях.

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

    Год выхода стандарта:
    HTTP/1.1 — 1997
    HTTP/2 — 2015
    HTTP/3 — 2022

    Как обновить:
    В большинстве серверов HTTP/2 уже встроен, но его нужно явно включить в конфигурации. В NGINX достаточно добавить слово “http2” в конфигурацию и всё заработает, настолько всё просто.

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

    Как проверить:
    Из консоли любой операционки

    curl -I https://example.com

    На первой же строке ответа будет указана версия протокола: HTTP/1.1, HTTP/2, или HTTP/3

  • Закрывайте тестовые сайты от индексации

    Закрывайте тестовые сайты от индексации

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

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

    Самый простой и надёжный способ — HTTP Basic Auth. При вводе адреса тестового сайта вылезет диалог с логином и паролем. Задаётся всё в конфигурации веб-сервера, работает и для Nginx и для Apache. Девопсы и сисадмины знают, как быстро настроить эту фичу.

    Код проекта не затронут — разработчикам ничего не нужно делать. Поисковые роботы не могут посетить сайт — спокоен SEOшник. И случайные люди не смогут на сайт попасть.

  • Безопасность веб-сервера

    Безопасность веб-сервера

    Безопасность сайта начинается с уменьшения площади возможной атаки.

    Чеклист, который выработал и применяю у себя:
    – IP-адрес реального сервера никогда не был прописан в DNS домена. В DNS попадает proxy или балансер — от Cloudflare, Fortes, Qrator или вашего другого сервера.
    – Отключена возможность зайти под root пользователем. Вначале сделали нового пользователя, дали ему sudo-права, потом запретили вход из-под root.
    – SSH-логин возможен только по ключу, пароли отключены совсем.
    – SSH работает на нестандартном порте — 22-й слишком очевиден, меняем.
    – Стоит и настроен firewall. Закрыты все порты, кроме нужных: 80 и 443 для сайта, порт для SSH, порт под метрики для мониторинга. Мой выбор ufw, его вполне хватает всё перекрыть.
    – Установлен fail2ban — чтобы не донимали сервер брутфорсом.
    – Операционная система и системные программы периодически обновляются.
    – На сервере отключена возможность отправки почты. Совсем. Если взломают — сервер не станет рассадником спама и не нужно будет его IP вычищать из блеклистов. Вся почта отправляется через внешний SMTP.
    – Не ставим или удаляем FTP — протокол устаревший и через него часто ломают серверы.
    – Во всех папках для загрузки файлов через сайт стоит запрет на выполнение кода. В nginx и apache прописывается запрет. WordPress и Битрикс чаще всего ломают именно так — заливают исполняемый PHP-файл в загрузки и запускают по прямой ссылке.
    – PHP позволяет запретить вызов некоторых функций. Вам точно нужен eval()?
    – В идеале — код движка размещён выше корня веб-сервера. Так сделано во всех “взрослых” фреймворках. WP и Битрикс требуют ухищрений, но тоже можно кое-что сделать.
    – Движок обновлён до свежей версии. Тут у клиентов зачастую беда, потому что поддержкой не занимаются.
    – Код сайта в git. Всегда можно посмотреть и откатить любые заражения за одну минуту. git reset --hard и всё почистили.
    – Минимум раз в сутки делается бэкап базы данных и загруженных файлов.
    – На сервере установлены и периодически запускаются руткит-сканеры.

    Это базовые действия. Опытные сисадмины добавят ещё пару десятков пунктов.
    У меня большая часть этих действий происходит автоматически, потому что прописана в ansible-плейбуке. Но и руками делается тоже быстро.

    А что я забыл и вы бы добавили в этот чеклист?