Nginx *

Продолжаем серию публикаций о нашем веб-интерфейс для HAProxy. Сегодня мы поговорим о специализированном сервис под названием Checker,

предназначенном для мониторинга сервисов HAProxy и Nginx, а также бэкендов HAProxy. Если один из сервисов падает, то Checker рассылает уведомления через Telegram или Slack.

Это очень удобно: не нужно "прикручивать" сторонний инструмент мониторинга, да и умеет Checker (причём из коробки) гораздо больше. Впрочем, обо всём по порядку.

Как-то я болтала с приятелем о том, как было бы здорово, если бы был такой сайт-песочница, где бы можно было просто скопировать-вставить конфиг Nginx-а и протестировать его. И я поняла, что это не так уж сложно сделать, поэтому погрузилась в тему и сделала: nginx-playground.wizardzines.com.

О том, как написать Web GUI для HAProxy, мы уже говорили в двух статьях (1 и 2). С момента публикации последней статьи прошёл год; сейчас, по прошествии времени, очевидно, что о многих вещах (важных и полезных) мы так и не рассказали подробно.  Сегодня мы возвращаемся на Хабр - и постараемся публиковать статьи на более или менее регулярной основе. В этих статьях мы подробно расскажем о специфике работы c Roxy-WI, о возможностях и преимуществах нашего решения. Начнём с набора функций, о котором мы в предыдущих статьях упоминали, но мало. Речь идёт о работе с конфигурационными файлами.

Zimbra Proxy - очень важный элемент Zimbra OSE, который выполняет целый ряд функций, связанных с безопасностью и быстродействием почтовой инфраструктуры. Именно на узле Zimbra Proxy происходит централизованная аутентификация пользователей и их перенаправление на соответствующий почтовый сервер, а также централизованный сбор логов. Кроме того, Zimbra Proxy выполняет функции балансировщика нагрузки и обратного прокси - скрывает от пользователей топологию и характеристики узлов инфраструктуры Zimbra OSE, что затрудняет проведение разного рода кибератак. Также на узле Zimbra Proxy происходит терминация SSL-соединения, что снижает нагрузку на остальные серверы инфраструктуры Zimbra OSE, и кэширование. Но главная ценность Zimbra Proxy заключается в том, что этот узел позволяет обеспечивать централизованный доступ к другим узлам инфраструктуры Zimbra OSE.

На самом сервере Zimbra Proxy устанавливаются такие компоненты как Nginx и memcached. Также на почтовых серверах Zimbra OSE устанавливаются обработчики маршрутизации запросов, который позволяет Zimbra Proxy корректно находить почтовый сервер при подключении пользователя. Всё это нужно для обеспечения централизованного доступа пользователей к серверам Zimbra OSE. Суть его заключается в том, что при подключении пользователя к узлу Zimbra Proxy он самостоятельно определяет, к какому почтовому серверу относится его учетная запись и перенаправляет подключение на нужный почтовый сервер, чтобы пользователь в итоге попал в свой почтовый ящик. То, что со стороны пользователя работает как магия, на самом деле является довольно сложным механизмом со множеством различных нюансов. О них мы расскажем в данной статье. 

В современном мире уже просто неприлично использовать HTTP, но не все веб приложения можно легко развернуть на HTTPS, некоторые вообще могут не поддерживать такую схему работы. Сегодня мы получим SSL сертификат бесплатно без регистрации и смс и настроим HTTPS на примере TeamCity.

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

Наследование директив в nginx - это классная штука. Именно наследование позволяет писать простые и понятные конфиги. При слиянии конфигураций значение директивы и её функциональность переходит из вышестоящего контекста в текущий. Логично, что наследование не происходит от параллельных контекстов, например от соседнего location или if.

Вроде бы всё хорошо. Пока не возникают исключения.

N.B.: Здесь и далее описывается работа с nginx версии 1.21.1 (если не указано иное). Всё сказанное основывается лишь на опыте и ошибках автора. Вместе с тем автор не является разработчиком nginx и даже его маститым сварщиком, поэтому не стоит принимать слова автора как догму, а, наоборот, подвергать сомнению и самостоятельному тестированию.

Привет всем! Я Руслан Абдуллаев, DevOps-инженер Технократии. Хочу рассказать про наш проект из 2020. В тексте будет немного моей боли, признание ошибок архитектуры, переход к ansible и minio, и финальная форма покемона без единого даунтайма.

Самое страшное зло в Nginx - это if в location. Об этом написано много, в том числе на nginx.com. Процитируем кусочек:

The only 100% safe things which may be done inside if in a location context are:
- return ...;
- rewrite ... last;

Казалось бы, если использовать конструкцию вида

location / {
if ( $condition ) {
return 418;
}
...
}

то ничего страшного не произойдет, однако, при определенном "умении", можно сломать даже то, что должно работать на 100%. Но будет ли виноват в нашей поломке if?

Статья подготовлена на основе уроков из открытой темы "Установка LEMP стека с помощью Ansible" курса по Ansible от Слёрм. Автор – Всеволод Севостьянов, Lead Engineer в Vene.io (Affiliate marketing solution). Первые две темы курса доступны на Youtube.

Материал этого урока будет интересен тем, кто разобрался с установкой Ansible и готов написать свой первый плейбук. Результатом будет плейбук, устанавливающий nginx на удалённой машине.

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

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

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

Хабру катастрофически не хватает такого формата постов как "продолжение" или "дополнение". После написания статьи зачастую появляется материал, который хотелось бы добавить к сказанному, но update'ить статью, с её сроком жизни в 1-2 дня, бессмысленно, а писать в комментариях невозможно из-за объёма материала. В то же время этого материала может быть недостаточно для новой статьи, да и, в силу того, что он сильно перекликается с предыдущей статьёй, придется либо постоянно её цитировать, либо оставлять пробелы, подразумевая, что читатель понимает о чем идет речь.

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

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

ISPConfig - бесплатная панель управления хостингом с открытым исходным кодом c возможностью управлять несколькими серверами из одной панели управления. Это один из лучших вариантов для веб-студий, хостинг-компаний, а так же для всех, кто ищет бесплатную панель управления хостингом с широким функционалом. В данной статье мы рассмотрим как выполнить установку Ispconfig3 с nginx, php-fpm и mysql на ubuntu 20.04.

Эта статья родилась случайно. Слоняясь по книжному фестивалю и наблюдая, как дочка пытает консультантов, заставляя их искать Иэна Стюарта, мой глаз зацепился за знакомые буквы на обложке: "Nginx".

Надо же, на полках нашлось целых три книги - не полистать их было бы преступлением. Первая, вторая, третья... Ощущение, будто что-то не так. Ну вроде страниц много, текст связный, но каково содержание? Установка nginx, список переменных и модулей, а дальше docker, ansible. Открываем вторую: wget, лимиты запросов и памяти, балансировка, kubernetes, AWS. Третья: GeoIP, авторизация, потоковое вещание, puppet, Azure. Ребята, а где про то, как вообще работает nginx? На кого рассчитаны ваши книги? На состоявшегося админа, который и так знает архитектуру этого веб-сервера? Да он вроде с базовыми настройками и сам справится. На новичка, который не знает как пользоваться wget? Вы уверены, что ему знание о существовании ngx_http_degradation_module и тем паче "облака" важнее порядка прохождения запроса?

Итак. О чем не пишут в книгах.
(здесь и дальше мы говорим только о NGX_HTTP_)

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

Однажды мне понадобилось 1Tb облачного хранилища и выбор пал на Nextcloud, который и было решено развернуть на собственном домашнем сервере

В данной статье я опишу как быстро и безболезненно установить и настроить облако Nextcloud и облачный редактор Onlyoffice

Статья предполагает, что у вас уже установлен и настроен Ubuntu.

Все действия были проверены на Ubuntu Server 20.04

Что будем делать:

1. Установим Nginx, PHP и MariaDB
2. Добавим бесплатный SSL-сертификат Let's Encrypt
3. Развернем NextCloud
4. Произведем тонкие настройки сервера
5. Установим Onlyoffice

Acme.sh - скрипт, позволяющий без особых проблем получать let's encrypt сертификаты очень разными способами. В данной статье разберу как получать сертификаты через DNS api, но этим уже никого не удивишь, поэтому расскажу про метод DNS alias, он свежий (всего 3 года) и интересный. А так же про автоматизацию на Ansible и немного про мониторинг сертификатов.

Под катом гифки и видео версия.

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

Привет, Хабр! Я Алексей Кашавкин, инженер отдела облачных операций в G-Core Labs, последние пять лет занимаюсь администрированием OpenStack. Сегодня расскажу о костыле нестандартном использовании технологий или о том, как посадить брокеры Kafka за Nginx, используя протокол HTTPS. Если у вас почему-то нет другого способа принимать сообщения — эта заметка как раз для вас.

Давно ничего не писал, поэтому разбавим конец пятницы простыми, но не всегда очевидными изысканиями в Nginx.

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