Nginx *

Предистория

Одним прекрасным днём мне понадобилось развернуть среду разработки для своего проекта. Vagrant уже порядком поднадоел и хотелось иметь единую среду разработки для всех участников проекта которая была бы идентичной production серверу. Соответственно наслушавшись информации про хипстерский docker, я решил начать с ним разбираться. Далее я постараюсь максимально подробно описать все шаги начиная от установки докера на локалке вплоть до разворачивания продуктива на KVM.

Исходный стек технологий:

— Docker
— Symfony 4
— nginx
— php-fpm
— postgresql
— elasticsearch
— rabbitmq
— jenkins

Железо:

— ноутбук под ОС Ubuntu 16.04
— продакшн сервер на хостинге KVM

Почему кроме технологического стека я перечислил ещё и стек железа?

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

Первый и наверно самый важный аспект при начале работы с докером — это операционная система вашего ноутбука. Проще всего работать с докером именно на linux системах. Если вы работаете на Windows или Mac то у вас 100 % будут некоторые сложности, но эти сложности не будут являться критическими и при желании «нагуглить» как это исправляется не составит никаких проблем.

Второй вопрос — это хостинг. Зачем нужен Hosting именно с типом виртуализации KVM? Причина в том, что виртуализация VPS разительно отличается от KVM и установить сам docker на VPS у вас попросту не выйдет, так как VPS распределяет ресурсы сервера динамически.

Подитог: для самого быстрого старта на докере резоннее всего выбирать Ubuntu в качестве локальной операционки и KVM хостинг (либо собственный сервер). Далее рассказ пойдёт опираясь именно на эти две составляющие.

njs — это JavaScript-интерпретатор в легковесном веб-сервере, с помощью которого можно создавать новые nginx-переменные и обработчики стадий запроса. Чем njs хорош? Чего не умеет? И зачем вообще его сделали? На эти и другие вопросы ответит Дмитрий Волынцев (xeioex), разработчик nginx и основной разработчик интерпретатора njs.

— Дмитрий, зачем понадобился скриптинг в конфигах nginx?

— Первая причина — директива if. Люди, которые первый раз ее увидели, думают, что можно использовать ее императивно. На самом деле это не так — конфигурация nginx является декларативной. В примере ниже можно подумать, что в ответе будут два header: X-First и X-Second. Но в ответ попадет только второй header, потому что так устроен nginx: если мы напишем две if-директивы, то выберется самая последняя.

location /only-one-if {
    set $true 1;

    if ($true) {
        add_header X-First 1;
    }

    if ($true) {
        add_header X-Second 2;
    }

«Команда @Cloudflare только что внесла изменения, которые значительно улучшили производительность нашей сети, особенно для самых медленных запросов. Насколько стало быстрее? Мы оцениваем, что экономим интернету примерно 54 года времени в день, которое иначе было бы потрачено на ожидание загрузки сайтов». — твит Мэтью Принса, 28 июня 2018 года

10 миллионов сайтов, приложений и API используют Cloudflare, чтобы ускорить загрузку контента для пользователей. В пике мы обрабатываем более 10 миллионов запросов в секунду в 151 дата-центре. За годы мы внесли много изменений в нашу версию Nginx, чтобы справиться с ростом. Эта статья об одном из таких изменений.

Работая над несколькими open-source проектами, в один прекрасный день я решил упростить себе жизнь и разработал Upstream-модуль для nginx, который помог мне убрать громоздкие слои многослойной архитектуры. Это был забавный опыт, которым я хочу поделиться в этой статье. Мой код лежит в открытом доступе тут: github.com/tarantool/nginx_upstream_module. Его можно поднять с нуля или скачать Docker-образ по этой ссылке: hub.docker.com/r/tarantool/tarantool-nginx.

На повестке дня:

• Введение и теория.
• Как использовать эти технологии.
• Оценка производительности.
• Полезные ссылки.

В web-сервере Nginx есть замечательный код ответа 444, который «закрывает» соединение без отправки данных. Данный функционал весьма полезен при фильтрации паразитного трафика — если мы уверены, что клиент по каким-то критериям не является валидным, то нет необходимости его уведомлять, например, 403-м ответом. Эффективнее просто прекратить передачу данных, что, зачастую, позволяет существенно снизить нагрузку на сервер.

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

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

В это статье будет сделан обзор возможностей модуля Nchan веб-сервера nginx, который заменил deprecated модуль NGiNX_HTTP_Push_Module. Модуль Nchan поддерживает основные технологии отправки сообщений Websocket, EventSource (Server-Sent Events), Long-Polling. Для горизонтального масштабирования используется кластер серверов redis.

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

И вот мы решили ускорять то, что и так работает быстро и, заодно, поделиться опытом того, что получилось в итоге. Конечно же я расскажу о граблях, о том где не надо HTTP/2, о том почему мы покупаем 7,6Tb NVMe SSD вместо 8x1Tb SATA SSD и много другой узкоспециализированной информации.

Давайте сразу договоримся что хранение и раздача контента это 2 разные задачи и говорить мы будем только про раздачу (продвинутый кеш)

Начнем с железа…

Для web-сервера Apache существует множество инструкций, в том числе и на Хабре, как стилизовать стандартный листинг файлов и директорий. Однако, как сделать также для сервера nginx, в русскоязычном интернете не найти. Порывшись на просторах интернета я нашел один репозитарий, где как раз и решается этот вопрос. Но для кириллических наименований файлов и папок потребовалась небольшая работа "напильником".

Когда я расположил приложение в Docker-контейнере и попробовал отправить email на почтовый сервер в другом Docker-контейнере, столкнулся с непредвиденной проблемой. Почтовый сервер postfix по умолчанию отправляет почту на произвольный домен получателя только от локального клиента. Все остальные домены нужно прописывать в параметре relay_domains, и если параметр mynetwors настроен правильно, то почта будет отправляться на перечисленные в параметре relay_domains домены с клиента из mynetwors.

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

Всем привет!

В этой статье я опишу как мы решали проблему централизованного обновления сертификатов Let's Encrypt и управления инфраструктурой с помощью ansible.

В нашем решении мы будем использовать:

• ansible
• rsync, rsyncd
• inotify, incron
• certbot
• nginx

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

Теория

Ресурс работы SSD накопителя теоретически не ограничен, если не превышать количество циклов перезаписи в ячейку.

Задача

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

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

Несколько дней назад зарелизилась новая версия Nginx — 1.13.10. Главная фича данного релиза — это нативная поддержка проксирования HTTP/2, и, как следствие, gRPC.

Доброго времени суток. В данной заметке хочу рассказать о простой аутентификации с помощь nginx и lua-скриптов.

На просторах интернета не нашел единого рецепта по установке и настройке такого, довольно нестандартного сервера. Решил написать свой рецепт.

Принцип работы следующий:


Статические данные (файлы) отдает Nginx, а динамикой занимается Apache.

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

В связи с ростом количества корпоративных клиентов, было принято решение дать доступ к учетной системе внешним пользователям. Для самостоятельного оформления заказов и отслеживания их состояний. Реализация была создан web интерфейс с необходимым функционалом и доступом. Тут же стал вопрос безопасности, кроме стандартных пользователь-пароль было решено еще усилить безопасность, для этого применили OpenVPN, но появились клиенты, для которых нельзя применять OpenVPN (политики безопасности, нежелания и.д.), тут на глаза попались статьи про доступ по ssl сертификату.

Чем является статья

Статья является набором простых, понятных инструкций и советов для пользователей Docker под Windows. Статья поможет разработчикам на PHP быстро поднять проект. Описываются проблемы и их решения. Статья полезна тем, кто не обладает бесконечным ресурсом времени, чтобы глубоко копаться в проблемах докера под Windows. Автор был бы бесконечно признателен, если бы ему ранее встретилась подобная статья и автор бы съэкономил бы много сил и времени. Текст может содержать ошибки и неточности.

Алгоритм выбора location обязателен к знанию при настройке nginx. Тем не менее, на официальном сайте nginx (на 2018 год) не сказано ни слова про алгоритм выбора в случаях, когда какие-то location'ы вложены друг в друга, а в статьях в интернете приводятся в корне неверные алгоритмы. В статье также будет дан пример уязвимого конфига.

В статье на Хабре обсуждался «docker way»(TM), который гласит: один контейнер — один процесс.Следование этому принципу при докеризации nginx чревато двумя последствиями. Настроить взаимодействие nginx и php-fpm в разных процессах через unix сокет немного сложнее, чем может показаться. И ротация логов, которая при обычной установке идет «из коробки», не может осуществляться в принципе, т.к. требует отправки сигнала USR1 nginx, для чего нужен ещё один процесс.

В контейнеры, в наше время, можно установить множество интересных систем
но под катом вы сможете найти лишь относительно стандартную инструкцию по установке asterisk+freepbx. Скуку слегка развеет то, что версии всего ПО «последние стабильные», есть шифрование, вместо apache — nginx, а вся установка под недавно «повзрослевший» lxc. На выходе получится достаточно мобильная, компактная и современная IP-АТС, потребляющая в покое 200-300 Мб ОЗУ

Статистика DDoS-атак показывает неизменный рост и смещение вектора с сетевого уровня на уровень приложений.



Если у Вас есть небольшой сайт на сервере с минимальными характеристиками, то положить его можно любым вполне легальным средством стресс-тестирования. (Не рекомендую этого никому делать т.к. IP-адрес легко вычисляется и экспериментатор может влететь на возмещение ущерба.) Поэтому сайт без защиты от DDoS очень скоро будет выглядеть так же дико, как компьютер с Windows-98 без анивирусника.