Nginx

Всем привет! Друзья, уже 21 февраля у нас стартует курс «Backend разработчик на PHP». В преддверии запуска курса хотим поделиться с вами переводом одного интересного материала. Приятного прочтения!

В октябре на конференции NGINX Conf 2018 мы анонсировали новый модуль управления API для контроллера NGINX. С этим продуктом мы укрепляем свои позиции в качестве самого развернутого шлюза API в отрасли — миллионы сайтов уже используют NGINX Open Source и NGINX Plus для обеспечения безопасной передачи трафика между серверными приложениями и потребителями API, предоставляемыми этими приложениями.



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

Цель: Предоставить конфигурацию виртуального сервера Nginx для работы Битрикс-cms в связке Nginx+PHP-FPM. Который в прочем подойдёт и для связки Nginx+Apache2, с небольшими доработками.

Целевая аудитория: Администраторы серверов, продвинутые администраторы сайтов, программисты.

Cтатей на эту тему достаточно, но если смотреть не официальные, то там как правило содержатся ошибки, а в официальных полно if которые в Nginx использовать не желательно. Надеюсь после того как я выложу данный конфиг к связке Nginx+PHP-FPM станут относиться серьёзнее.

Вот официальный конфиг для работы композитного кэша с отдачей через nginx.

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

Привет, Хабр!

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

Одна из самых популярных интеграций — с open-source системой Nextcloud, которая позволяет создать свое облачное хранилище. К примеру, у вас есть документы, таблицы и презентации, которыми вы хотите поделиться с другими пользователями, и сервер (как вариант — тачка в DigitalOcean). Вы устанавливаете туда Nextcloud (или ownCloud, от которого он, собственно, форкнулся), подключаете редакторы документов и получаете возможность работать с этими документами совместно.

Большинство вариантов интеграции описаны у нас в документации. Но иногда всплывают интересные пользовательские кейсы. Например такой: как сконфигурировать прокси-сервер для Nextcloud и ONLYOFFICE в случае, если все три сервиса установлены на разных серверах (Nextcloud, редакторы, прокси). Такое может произойти, если существует сложная система, где и редакторы документов, и система управления документами являются частью бОльшей системы с множеством сервисов.

Всем привет!

Сегодня мы хотим рассказать о том, как команда сервиса бронирования отелей Ostrovok.ru решала проблему роста микросервиса, задачей которого является обмен информацией с нашими поставщиками. О своем опыте рассказывает undying, DevOps Team Lead в Ostrovok.ru.

В этой статье представлена инструкция по установке динамического модуля ModSecurity на веб-сервер NGINX в качестве межсетевого экрана веб-приложения (WAF). NGINX работает в режиме обратного прокси-сервера. Работу выполнено на дистрибутиве Linux – CentOS 7. Модуль установлено в качестве «динамического», что бы сервис оставался гибким в настройке. Использовано официальное руководство NGINX по установке.

Приложения ASP.NET Core по-настоящему кросс-платформенны и могут запускаться в «никсах», а соответственно, и в Docker. Посмотрим, как их можно упаковать, чтобы развертывать на Linux и использовать в связке с Nginx. Подробности под катом!

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

Даже те, кто пока только мечтают о тысячах пользователей на своём сайте, наверняка задавались вопросом: “А сколько же пользователей мой сайт выдержит, если они зайдут одновременно?” Сразу вспоминается известное выражение “Хабраэффект” – явление отказа сайта, который оказался не готов к многочисленным переходам на него после появления в интернете ссылки.

Я не админ, но иногда возникают задачи, которые проще (и интереснее) решать самому чем кому-то делегировать.

Изредка у нас появляется необходимость «поднять» servlet контейнер (чаще всего Apache Tomcat) и настроить для него проксирование, ssl termination (а проще говоря https) и все это прикрыть firewall'ом (оставив наружу только ssh и http/https).

Так получилось, что за последнюю неделю я эту задачу решал трижды (так стали звезды, а до этого — года два назад) и этот опыт трансформировался в сей небольшой опус.

Прошлые посты в корпоративном блоге не содержали ни одной консольной команды, и мы решили наверстать упущенное.

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

Так выглядит тестовый сайт на каждом сервере виртуального хостинга

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

Но что делать, когда ваш код “идеален”, все тяжелые запросы вынесены в фон, все, что можно, было закэшировано, а сервер все так же не дотягивает до нужных нам показателей SLA? Если есть возможность, то конечно можно докупить новых машин, распределить часть трафика и забыть о проблеме еще на некоторое время.

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