Nginx *

Авторизация в системах одна из ключевых частей. Можно использовать какие то мощные решения, Firebase например, или что то из множества хороших библиотек. Если хочется уменьшить количество зависимостей или для самообразования - то можно написать свое.

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

В этой статье мы рассмотрим, как настроить реестр образов GitLab Container Registry, находящийся за обратным прокси сервером NGINX. Предполагается, что у вас уже установлен GitLab с помощью пакета Omnibus. Согласно документации, Container Registry можно настроить на том же домене, на котором работает сам GitLab, но в случае работы GitLab за прокси сервером, необходимо завести отдельный домен для реестра образов, чтобы избежать конфликта доменных имен при настройке виртуальных хостов в GitLab Nginx.

Реестр образов будет доступен по адресу: registry.example.com. Добавляем А запись для домена реестра в DNS. Приводим конфиг виртуального хоста на сервере обратного прокси к следующему виду:

Продолжаем цикл статей о возможностях Roxy-WI. Сегодня мы поговорим ещё об одном важном наборе функций, связанных с управлением сервисами (а именно ― HAproxy и Nginx) в docker-контейнерах. Мы старались сделать эту функцию максимально простой и удобной в использовании. О том, что у нас получилось, и пойдёт речь ниже.

Для приготовления виджета Государственного Адресного Реестра, кроме базы, нам также понадобится nginx и его плагины postgres и json. Можно воспользоваться готовым образом.

В базе была определена большая функция gar_select от json и возвращающая json. Вот как раз она и нужна для использования через nginx.

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

В данном туториале мы рассмотрим, как быстро развернуть LEMP-стэк на виртуальный сервер VPS, используя технологию контейнеризации на базе Docker для сайта под управлением CMS DataLife Engine (DLE).

Продолжаем серию публикаций о нашем веб-интерфейс для 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_)