Свежие заметки

Настройка обратного прокси-сервера для поддержки протокола HTTP/2

Отдельный прокси-сервер может быть полезными, когда на штатном HTTP-сервере нет должной поддержки HTTP/2 или вы, по тем или иным причинам, не можете обновить версию сервера. Я попробовал некоторые из большого списка, существующих на данный момент, серверов.

nghttp2

Проект nghttp2 представляет собой библиотеку для работы с потоками данных и набор инструментов, написанных на базе этой библиотеки.

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

  • nghttp — клиент HTTP/2;
  • nghttpd — сервер;
  • nghttpx — прокси-сервер;
  • h2load — инструмент нагрузочного тестирования.

Клиент по своей функциональности очень напоминает curl, а утилита нагрузочного тестирования — ab.

Прокси-сервер имеет несколько режимов работы и множество настроек. Тем не менее, его настройка в режиме обратного прокси оказалось очень простой.

$ nghttpx --frontend=*,443 \
    --backend=prod.noteskeeper.ru,80 \
    --tls-proto-list=TLSv1.2,TLSv1.1,TLSv1.0 \
    --dh-param-file=/etc/letsencrypt/live/noteskeeper.ru/dhparam.pem \
    /etc/letsencrypt/live/noteskeeper.ru/privkey.pem \
    /etc/letsencrypt/live/noteskeeper.ru/fullchain.pem

Обратный прокси будет слушать порт 443 на всех интерфейсах и передавать запросы на хост prod.noteskeeper.ru. Остальные параметры нужны для настройки TLS.

Ещё, возможно, будет полезен ключ --host-rewrite. Если он будет указан, то прокси заменит заголовок Host в запросе к бекэнду на значение из исходного запроса от клиента. Например, рассмотрим следующую ситуацию. Пусть на одном сервере будет настроен хостинг для моего блога по адресу noteskeeper.ru. На другом сервере я запускаю прокси. Теперь я должен заменить адрес в DNS-записи A на тот, который будет указывать на прокси и добавить ещё одну запись A на сайт, но с другим под-доменом (назовём его prod). Проблема в том, что хостинг знает только о сайте noteskeeper.ru и ничего не знает о prod.noteskeeper.ru. Из-за этого сайт начнёт отвечать ошибками с кодом 404. С таким же успехом мы могли бы в конфигурации бекэнда nghttpx указать просто IP-адрес, но домен всё же удобнее. Тут нам и поможет замена заголовка — клиент будет обращаться по адресу noteskeeper.ru и этот же адрес будет передаваться в запросе на сайт.

Минусом решения на базе nghttpx является то, что вам придётся запустить несколько его экземпляров с разными параметрами чтобы обслуживать запросы с или без www, а так же на 80 порту без шифрования и на 443 с шифрованием.

h2o

Проект h2o развивается как альтернатива Nginx и представляет собой высокопроизводительный веб-сервер с возможностью обратного прокси. Собирается он так же из исходников без каких-либо сложностей. В документации описаны все требуемые условия.

Сервер настраивается с помощью конфигурационного файла. В моём случае он получился вот таким:

hosts:
  "noteskeeper.ru:80":
    listen:
      port: 80
    paths:
      "/":
        redirect: https://noteskeeper.ru/
  "noteskeeper.ru:443":
    listen:
      port: 443
      ssl:
        key-file: /etc/letsencrypt/live/noteskeeper.ru/privkey.pem
        certificate-file: /etc/letsencrypt/live/noteskeeper.ru/fullchain.pem
        dh-file: /etc/letsencrypt/live/noteskeeper.ru/dhparam.pem
    paths:
      "/":
        proxy.reverse.url: "http://prod.noteskeeper.ru:80/"
        proxy.preserve-host: ON

# Включаем компрессию данных.
# Без этой настройки клиент получит данные в не сжатом виде,
# даже если они были сжаты на бекэнде.
gzip: ON

# Передавать быстрее файлы с большим приоритетом.
# Изначально к таким файлам относятся CSS и JS.
http2-reprioritize-blocking-assets: ON

# Включить проверку кешировани для файлов, которые
# были переданы с помощью server push.
http2-casper: ON

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

file.mime.addtypes:
  "application/x-javascript":
    extensions: [".js"]
    is_compressible: yes
    priority: highest

Запускается сервер командой:

$ h2o -c ./noteskeeper.conf

Заключение

Оба сервера, которые я протестировал, понимают заголовки ответа Link со значением rel=preload. Это позволит управлять очередью доставки контента пользователю. Ресурсы, которые вы указали, начнут отсылаться по сети ещё до того как браузер их запросит.

Для поддержки HTTP/2 вам придётся получить SSL-сертификат.

Ни одно из этих решений пока не выпущено в качестве собранного пакета. А это значит нужно будет повозиться с настройкой запуска демона.

Оставте свой комментарий

Конференции, на которых я был в 2015 году

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

В Москве в рамках фестиваля РИТ в этом году проходила большая конференция FrontendConf. Для неё я подготовил доклад «Пакуйте чемоданы. Грузите апельсины» (слайды). Модульная структура JS-приложения и инструменты для сборки уже стали признаком хорошего тона. Я сделал обзорный доклад, в котором рассказал о текущем состоянии технологий и инструментов для работы с JS-модулями.

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

Практически в то же время, когда я подавал заявку на FrontendConf, меня пригласили выступить на UWDC с докладом «От простого к сложному» (слайды). В этом году уклон всей секции был сделал на разработку под мобильные устройства.

Пикантность ситуации заключалась в том, что в четверг и пятницу я был в Москве на FrontendConf, а в субботу уже должен был быть в Челябинске на UWDC. В тщательно продуманный план закралась неопределённость в виде московского метро. Я опоздал на нужный мне рейс аэроэкспресса. Следующий прибывал в аэропорт уже впритык ко времени посадки. Я зарегистрировался через приложение, но у меня не было распечатанного посадочного талона.

Несмотря ни на что, я успел на свой рейс! Эта ситуация меня ещё раз научила тому, что не стоит опускать руки, если ты в силах ещё что-то изменить.

Летом я выступал на митапах ChellyJS в Челябинске и 4front в Минске с докладом «Переходи на HTTPS!». В своё время меня очень заинтересовала эта тема. Казалось, что настройка безопасного соединения подвластна только бородатым сисадминам. Однако, на практике это совсем не так.

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

В сентябре в Екатеринбурге уже традиционно проходит большая конференция FrontTalks. Мне очень нравится формат и подготовка этого мероприятия. Я всегда с удовольствием приезжаю на неё с каким-нибудь докладом. В этом году одним из трендов в веб-разработке стал webpack. В отличии от обзорного доклада, который я делал на FrontendConf, тут я решил рассказать о том, как именно webpack позволяет упростить некоторые рутинные задачи. Мой доклад «Глубокое погружение в webpack» доступен в записи или слайдах. Ведущие так тепло представили меня, что я даже растрогался и немного позабыл о чём хотел рассказать.

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

А в октябре я уже четвёртый год подряд езжу на Fronteers в Амстердам. В этот раз я вёл текстовую трансляцию мероприятия для сообщества «Веб-стандарты». Логи доступны на Гитхабе — первый день, второй день. (Примечание: кликайте по ссылкам на pic.twitter.com — там очень часто я прикреплял несколько картинок, но выгрузились только первые из них).

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

Комментарии к заметке: 2

Обновление сертификата Let’s Encrypt

Сертификаты Let’s Encrypt «живут» всего 90 дней. Такой короткий срок авторы проекта выбрали исходя из того, что выпущенные сертификаты легко обновить. Для этого нужно запустить инсталлятор с теми же параметрами, которые были использованы во время получения сертификата. Инсталлятор обнаружит, что на сервере уже есть сертификат для этих доменов и предложит обновить их.

После успешной загрузки обновлённых сертификатов инсталлятор сообщит дату окончания их действия.

Конфигурационные файлы сервера изменять при этом не нужно. На сервере хранятся все версии выпущенных сертификатов в папке /etc/letsencrypt/archive/, а в папке /etc/letsencrypt/live/ создаются симлинки на актуальные версии.

Запуск инсталлятора можно запланировать в crontab.

Оставте свой комментарий

Как получить сертификат Let’s Encrypt в ручном режиме

На данный момент инсталлятор Let’s Encrypt, со слов авторов проекта, может автоматически исправлять конфигурацию только Apache. Поддержка nginx и других HTTP-серверов находится в разработке. Тем не менее, это не помешает вам получить сертификат.

Если у вас уже работает какой-то веб-сервер, то инсталлятор следует запустить с ключом --webroot. Ключ certonly указывает, что мы только хотим получить сертификат. Ключом -w мы сообщаем расположение корневой папки сайта.

Так же следует перечислить домены, на которых работает сайт, с помощью ключа -d.

Через несколько секунд вы получите сообщение о том, что сертификат получен и его можно использовать.

Работающий веб-сервер нужен инсталлятору, чтобы подтвердить ваше право владения доменом. Если вы ещё не настраивали его, то инсталлятор может сам запустить такой временный сервер на 80 или 443 порту.

Это делается с помощью ключа --standalone.

В отличие от режима webroot, в режиме standalone можно не указывать домены в командной строке.

Инсталлятор запросит их позже в диалоговом окне.

Все генерированные ключи и выпущенные сертификаты лежат в папке /etc/letsencrypt/live/$domain.

  • privkey.pem — приватный ключ. Он должен всё время храниться в секрете. Это тот файл, который указывается в опции SSLCertificateKeyFile у Apache или в опции ssl_certificate_key у nginx.
  • cert.pem – сертификат для домена. Этот файл указывается в опции SSLCertificateFile у Apache.
  • chain.pem — цепочка из промежуточных и корневого сертификатов центра сертификации. Путь до этого файла указывается в опции SSLCertificateChainFile у Apache.
  • fullchain.pem — Все сертификаты в одном файле, включая сертификат для домена. Данный файл нужно указать в опции ssl_certificate у nginx.
Оставте свой комментарий

Настройка сертификатов Let’s Encrypt в Apache

В статье про бесплатные сертификаты для доменов я упомянул, что получить его и настроить сервер с появлением центра сертификации Let’s Encrypt стало очень просто. Покажу все шаги для настройки Apache.

Для начала, нужно загрузить установщик Let’s Encrypt. Если у вас чистая виртуальная машина, то кроме Git ничего не понадобится. Все остальные зависимости будут установлены позже.

apt-get install git

Установка Git

Клонируем репозиторий из Github.

git clone https://github.com/letsencrypt/letsencrypt

Клонирование репозитория Let’s Encrypt из Github

Переходим в папку с инсталятором.

cd letsencrypt

Переходим в папку с Let’s Encrypt

Инсталятор запускается командой:

./letsencrypt-auto

У него много параметров, посмотреть которые можно в справке.

./letsencrypt-auto --help all

Нас интересует получение сертификатов и установка их в Apache.

./letsencrypt-auto --apache

Запускаем установщик, который получит сертификаты и сконфигурирует сервер Apache

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

Если в конфигурации Apache не указаны домены, то установщик запросит их у вас

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

Установщик нашёл сконфигурированные домены

Он так же попросит указать email для обратной связи. Этот адрес электронной почты не будет добавлен в сертификат.

Требуется указать email для обратной связи

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

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

Установщик может добавить правила для перенаправления пользователей с обычной версии сайта на версию с безопасным подключением.

Установщик может добавить правила для перенаправления пользователей с обычной версии сайта на версию с безопасным подключением

Настройка завершена. Инсталлятор предлагает проверить конфигурацию сервера с помощью онлайн сервиса Qualys SSL Lab.

Настройка завершена

Сайт уже можно попробовать открыть в браузере.

Проверяем полученный сертификат в браузере

Инсталлятор скопировал существующую конфигурацию сайта, добавил в оригинальный файл редирект на HTTPS-версию, а в копии указал пути до приватного ключа, сертификата домена и промежуточных сертификатов. Так же он подключил файл с дополнительными настройками для mod_ssl.

Изменения в конфигурационных файлах Apache

Как видите, настройка безопасного соединения для вашего сервера оказалась не такая уж и сложная.

Комментарии к заметке: 8