Настройка nginx proxy 1с
Обновлено: 03.07.2024
Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужно пройти .
Введение
Просто настроить gitlab за nginx в режиме proxy_pass не представляет никакой сложности. Трудности возникают именно тогда, когда вы хотите использовать встроенный Container Registry. Я несколько раз подходил к этой задаче и каждый раз отступал, либо отказываясь от registry, либо от nginx proxy.
Без прокси неудобно, так как чаще всего, если у вас есть какая-та инфраструктура, а не одиночный сервер, смотреть напрямую в интернет у вас будет какой-то шлюз, а не сам сервис. Так удобно разграничивать доступ, контролировать и перенаправлять подключения, следить за сертификатами, балансировать нагрузку и т.д. В общем, я использую его всегда, когда это возможно и оправдано (почти всегда).
С registry не получалось корректно настроить работу за прокси. Я перепробовал все советы, что только нашел в интернете. Перечитал всю документацию, но так ничего не получилось. Команда docker login успешно отрабатывала на сервере, а вот запушить образ в реджистри gitlab никак не получалось. Получал ошибку.
Проблему я в итоге решил, когда залез во внутренности gitlab и разобрался, как там все устроено. Когда все понял, придумал рабочее решение, которым с вами делюсь.
Gitlab и proxy nginx
На самом сервере с gitlab в /etc/gitlab/gitlab.rb измените параметры.
И после этого дайте команду на переконфигурацию системы.
После этого gitlab будет нормально работать за nginx proxy. Дальше рассказываю, что надо сделать, чтобы включить и нормально запустить в работу Container Registry за reverse proxy.
Настройка Gitlab registry за reverse nginx proxy
На первый взгляд никаких особенных сложностей быть не должно. Делаем по аналогии настройки, только для registry_nginx и пробуем работать с registry. Но ничего не получится. Будет приведенная выше ошибка. Я покопался в настройках gitlab и понял, в чем проблема.
Если у вас используется одинаковый url для web интерфейса gitlab и registry, то корректная работа за nginx proxу невозможна. Я посмотрел конфигурацию nginx, входящего в состав gitlab. Она живет тут - /var/opt/gitlab/nginx/conf. Там отдельный конфиг для web интерфейса и для registry. Если используются одинаковые доменные имена, то все запросы попадают на конфигурацию веб интерфейса и проксируются на gitlab-workhorse.
Это происходит, потому что директива server_name в обоих конфигах одинаковая. Обрабатывается первым то, что стоит раньше в конфигурации. Я заподозрил это еще раньше, когда 404 ошибки обращений к registry обнаруживал в лог файлах /var/log/gitlab/nginx/gitlab_access.log, тогда как gitlab_registry_access.log были пустые.
Я сделал для registry отдельный домен. Настроил для него проксирование, примерно так.
Дальше в gitalb.rb добавил параметры, отвечающие за работу registry.
Я не уверен, что нужны все эти параметры. Привожу пример с реально работающего сервера и чтобы случайно чего-то не забыть, привожу сразу все, что на нем сейчас активно из настроек. Думаю, заголовки указывать не обязательно. Без них тоже заработает.
После этого перечитывайте конфигурацию gitlab и nginx и проверяйте работу.
Проверка работы gitlab registry
Теперь проверим работу Gitlab Container Registry. Для этого создаем любой проект через web интерфейс. Идем в раздел Packages -> Container Registry. Там увидите краткую инструкцию по работе с реджистри.
Идем на сервер, где будем собирать образы docker. Настраиваем подключение к registry, указав логин с паролем.
Создадим тестовый докер образ из Dockerfile.
Собираем образ и загружаем его в registry.
Указанный образ будет загружен в Registry данного проекта.
Часто задаваемые вопросы по теме статьи (FAQ)
В моем примере запросы с прокси на рабочий сервер идут в рамках закрытой непубличной инфраструктуры, где вероятность перехвата трафика минимальна. Нет смысла тратить ресурсы и время на настройку и обновления сертификатов не только на nginx proxy, но и рабочем сервере.
Возможно ли настроить подобное проксирование со шлюза на рабочий сервер через интернет? Можно ли таким же способом проксировать запросы к встроенным gitlab pages или mattermost?Да, настраивается это примерно так же. Необходимо создать поддомен для каждого сервиса и по аналогии с приведенным примером настроить перенаправление запросов с nginx на gitlab.
У вас есть подробный материал, где рассказано о том, как настроить и начать работать с gitlab?Заключение
Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!На этом все по работе gitlab за nginx proxy. Настройка очень простая, продуктом пользоваться удобно. Настроить типовой ci/cd на базе докера очень просто. В будущем опишу такой пример. Так что рекомендую Gitlab для совместной работы команды. Минус у него только один - очень требователен к ресурсам.
Настройка веб-сервера Nginx
Для развертывания клиентской транслирующей части необходимо взять отдельный сервер под управлением семейства операционных систем Linux. Nginx также существует для Windows, но в нем не реализована поддержка в виде службы, что не подходит под условия данной статьи.
1. Установка Nginx под Linux
Итак, предполагается, что есть только что установленная операционная система Ubuntu 18.04 LTS без графического интерфейса пользователя.
Перед тем как продолжить, нужно проверить доступные версии программного обеспечения дистрибутива. Выполняем команду:
В выводе результата команды можно увидеть, что доступны обновления. Рекомендуются их обновить с помощью команды (подсказка "Run ‘apt list –upgradable’"):
По завершению обновления пакетов приложений можно приступить к установке непосредственно веб-сервера.
Нужно выполнить команду команду:
Необходимо дождаться окончание выполнения команды и убедиться, что в момент установки никаких ошибок не возникло. В данном случае установка прошла без проблем.
Далее нужно проверить, что помимо самой установки, веб-сервер запустился и готов обрабатывать запросы (для данной команды использование sudo не обязательно):
В ответ можно увидеть, что состояние службы active (running). Это значит, что веб-сервер работает в штатном режиме, и можно переходить к настройке трансляции запросов либо к генерации самоподписанного сертификата (если в этом есть необходимость).
2. Выпуск самоподписанного сертификата (необязательно)
После установки Nginx в операционной системе уже должен быть установлен openssl. Поэтому можно сразу приступить к генерации сертификата.
Первоначально нужно перейти в директорию хранилища сертификатов с помощью команды:
После чего требуется ввести команду генерации сертификата, где вместо <SERVER> нужно подставить имя компьютера, на котором планируется размещен Apache:
Во время выполнения команды будет задано несколько вопросов. Для "Common Name (e.g. server FQDN or Your bane)" нужно также указать имя сервера. Остальные поля заполняются произвольно (кроме "Country name" - здесь можно оставить по умолчанию).
3. Привязка сертификата и переадресация запросов
После того как сертификаты были получены и размещены в директорию сертификатов, нужно перейти в директорию публикаций сайтов Nginx:
Предполагается, что уже есть две базы опубликованные на веб-серверах с Apache и IIS (см. Настройка веб-сервера IIS и 3. Установка Apache под Linux).
Веб-сервер Apache расположен на компьютере <ИМЯ СЕРВЕРА APACHE> , а веб-сервер IIS расположен на компьютере <ИМЯ СЕРВЕРА IIS> .
На веб-сервере Apache опубликована информационная база с именем <ИМЯ ПУБЛИКАЦИИ APACHE> , а на веб-сервере IIS опубликована информационная база с именем <ИМЯ ПУБЛИКАЦИИ IIS> .
После этого нужно сохранить и перезапустить службу nginx.
4. Проверка публикации
Для проверки корректной работы нужно открыть страницу в браузере и перейти по ссылке, которая состоит из двух частей:
Для каждого из видов подключения нужна своя аутентификация и отдельный набор ролей доступа. При одной публикации доступ пересекается, стандартные "грабли": при подключении телефонии тонкий клиент на автомате подключается под сервисным пользователем телефонии.
Разнесение на отдельные публикации
Так же остается проблема если нужна Basic аутентификация на уровне кода сервиса.
Вариант решения
Использовать обратный прокси перед основным web сервером и на его уровне настроить ограничения доступа.
Подготовка
- для тестов организовал DNS запись test.malikov.pro
- основная машина на win 10,
- сервер 1С на основной машине c apache 2.4 (IP 192.168.57.2) на порту 8080
- конфигурация УТ 11.4.11.100
- в качестве ОС использую Ubuntu,
- подключаюсь к ubuntu через SSH, (клиент), отправляю файлы через WinSCP(
Публикация клиента 1C
Проверяю корректность публикации
Настраиваю обратный прокси для /ut_demo_cl
По нормальному нужно в sites-available + добавить ссылку в sites-enabled, пока тестирую пишу напрямую в sites-enabled
Проверяю конфигурацию через SSH "nginx -t", перезагружаю конфигурацию "service nginx reload".
Реализовано через расширение, публикация с указанием сервисного пользователя (
Настраиваю обратный прокси для /api_vpbx
Перезагружаю конфигурацию, проверяю работоспособность
При обращении к сервису с basic аутентификацией идет перехват и замена пользователя по умолчанию на пользователя из запроса
Для обхода этой ситуации использую замену заголовка
Ограничение доступа по IP
Для телефонии известны IP адреса серверов (пример Манго-Офис,
Проверяю, получаю 403 ответ
Ограничение на количество запросов
Если API ресурсоёмкое, то имеет смысл поставить ограничение по количеству запросов с IP адреса
Добавляю в основную конфигурацию зону
Расширяю описание блока "/api_v1"
Проверяю, при частом запросе получаю 503.
Добавляю в настройки настройки для "/"
- Добавил репозиторий "sudo add-apt-repository ppa:certbot/certbot"
- Установил certbot "sudo apt install python-certbot-nginx"
- Запустил установку сертификата "sudo certbot --nginx -d test.malikov.pro"
- Для варианта настройки выбрал "2: Redirect"
В результате успешно получил сертификат. Проверяю работоспособность
Использование Web интерфейса для настройки
Если лезть и разбираться в конфигах и командах не очень хочется то можно поставить "Nginx Proxy Manager"
Запускается как докер контейнер
В базе на сколько понимаю работает в SQLite, можно подключить к Mysql.
Благодарю Алексея Лустина за информацию.
Применение в облачных средах
В kubernetes есть Ingress - механизм, обеспечивающий маршрутизацию входящего трафика на уровне приложения (L7), предоставляемый через Ingress-контроллер. В основе которого базово используется Nginx.
Благодарю за внимание.
Специальные предложения
Столько вопросов
Как сделать несколько подключений с разными правами через ВЕб
Вот оно ))
Кеширование через Nginx не пробовал?
(1) Статику кешировать относительно просто.
Хотел расширить по аутентификации, чтобы отсекало перед 1С и IPS приделать (Snort).
Пишите задачу, если получится, то дополню статью.
сколько пользователей потянет веб сервер при публикации файловой базы ?может подсказать. ? (3) При файловой базе больше проблема в блокировке файла чем в web сервере. Из моего опыта 3-5 пользователей работают нормально, далее уже сервер МИНИ и далее, видел информацию что запускали данный вариант на 10+ пользователей.
(4)
до двадцати есть вариант ?
или публикация на разных адресах
для пяти клиентов на адрес и четыре адреса ?
Автор, объясни, пожалуйста, у меня не совсем пазл сошёлся в одном вопросе.
Ведь можно же было сделать просто разные (несколько) публикаций на IIS (Apache)?
Для чего тут ngnix?
Не докопаться ради, а ликбез для меня и таких как я.
Заранее спасибо за ответ!
(8) По простому: для меня проще настроить сертификаты letsencrypt на ubuntu c nginx, чем на win+IIS.
Если копнуть в web то обычно ставят прокси/балансировщик, а за ними уже сервера приложений, на уровень прокси можно навесить системы защиты, мониторинга. Удобно по настройке доступа, ограничения ставлю в одном месте.
На практике у меня на прокси приходит публичный траффик с одного IP и его распределяю исходя из доменных имен (из того что вижу у коллег раскидано на разные порты).
Из минусов, у меня нормально не запустился nextcloud+onlyoffice т.к. они в докере, в сборке перед ними свой прокси и между ними передается локальное имя, по хорошему нужно прокачать знание docker и по нормальному настроить.
Разберём, что такое Reverse Proxy. А также я покажу как настроить Nginx в качестве Reverse Proxy (обратного прокси сервера).
Теоретическая часть
Иногда бывает нужно чтобы различные url запросы обрабатывались на разных серверах, но первоначально приходили на один сервер. Например вы пробросили порт на своем роутере на один веб-сервер в вашей внутренней сети. Но хотите чтобы каталог /xxx открывался на втором веб-сервере, а /yyy открывался на третьем, и не хотите пробрасывать порты на каждый web-сервер. Получается вот такая схема:
То что мы хотим сделать из сервера web1, называется reverse proxy (обратный прокси).
В то время как forward proxy (прямой прокси) работают от имени клиентов, то есть нам нужно настраивать браузер (клиент), чтобы тот ходил через прямой прокси сервер. Обратные же прокси работают от имени серверов, то есть клиент не знает, что он обращается на прокси сервер.
Reverse proxy принимает запросы от клиентов для того чтобы проксировать их на проксируемые web-сервера (как показано на рисунке).
В качестве обратного прокси сервера для веб серверов может выступать apace или nginx. Есть и другие решения, но в этой статье разберём настройку nginx. На официальном сайте nginx есть небольшой раздел, посвящённый reverse proxy.
Схема нашей лаборатории
Я буду использовать операционную систему Devuan, это облегченный вариант Debian без systemd. Про установку Devuan я уже писал здесь.
У нас будет три сервера:
- proxy – reverse proxy (ip 192.168.5.82) – установлен nginx;
- web1 – backend web server (ip 192.168.5.84) – установлен apache2;
- web2 – backend web server (ip 192.168.5.83) – установлен apache2;
Практическая часть
Настраиваем nginx
Устанавливаем nginx на сервере proxy:
У меня установился nginx такой версией:
Для настройки прокси создадим новый виртуальный хост:
Разбор конфига
На основных настройках я не буду заострять внимание, потому как они не относятся к настройке reverse proxy. Если вкратце там мы указали какие порты слушает наш сервер, корень сайта, индексные страницы и имя сервера.
А следующие строки отвечают за настройку работы буферной памяти для проксируемой информации:
- proxy_buffering on; – включаем буфер для прокси сервера;
- proxy_buffer_size 8k; – размер буфера для первой части ответа получаемого от проксируемого сервера, такая часть ответа включает в себя только заголовки и хранится отдельно от остальной информации;
- proxy_buffers 8 8k; – число и размер буферов для одного соединения, а вот сюда помещается ответ от проксируемого сервера.
Теперь разберем часть где мы указываем что проксировать и куда проксировать:
Отключим конфиг “default“, включим созданный нами конфиг “proxy” и перезагрузим службу сервера:
Настраиваем backend сервера
На обоих серверах проделаем одно и тоже! Во-первых установим apache2, затем создадим новый каталог /var/www/html/test. В этом каталоге сделаем индексную страничку index.html в которую запишем имя сервера. Вдобавок поменяем владельца нового каталога на www-data.
Проделываем следующее на обоих серверах:
Проверка
Используя адрес прокси сервера, откроем xxx:
Используя адрес прокси сервера, откроем yyy:
Как видим у нас открылись разные странички, которые лежат на разных серверах:
Резервирование серверов
Теперь сделаем так, чтобы один и тот же запрос ходил по следующим правилам:
Для этого поправим наш конфиг /etc/nginx/sites-enabled/proxy и перед блоком server добавим блок upstream:
В этом блоке указываем оба web-сервера. При этом webбудет основным сервером. Но если proxy в течении 120 секунд получит три ошибки при обращении к web1, то на 120 секунд все запросы пойдут на web2.
Ниже в блоке server, где мы указывали что на что проксировать (блоки location), поменяем записи. Вместо ip-адреса web-сервера укажем название апстрима, которое мы придумали выше (backend). Второй блок (location /yyy) – удаляем. Получится так:
Полностью конфиг будет выглядеть так:
Проверка резервирования
В браузере, используя адрес прокси сервера, открываем /xxx:
Затем отключаем сервер web1 и обновляем страничку:
Как видим мы перешли на второй сервер. Теперь включим обратно первый сервер и обновим страничку еще раз:
Теперь мы вернулись на первый сервер.
Таким образом вы можете создать два одинаковых веб сайта и в случае неисправности первого сервера, ваш сайт продолжит работать на втором сервере. Клиенты могут даже ничего не заметить.
Что такое обратный прокси?
Прокси-сервер действует как посредник между клиентом и другим сервером.
Он получает ресурсы с сервера, к которому вы хотите подключиться, и отправляет его вам для просмотра. Обратный прокси-сервер работает так же, за исключением того, что роль меняется на противоположную.
Когда вы запрашиваете информацию с сервера, обратный прокси-сервер получает запрос и отправляет его на соответствующий внутренний сервер.
Это позволяет системному администратору использовать сервер для нескольких приложений, а также обеспечивать более плавный поток трафика между клиентом и сервером.
Теперь давайте сделаем более общий вариант настройки 🙂
Преимущества обратного прокси
В зависимости от вашего приложения у вас могут быть разные варианты использования обратного прокси.
Настройка Nginx в качестве обратного прокси
Для начала стоит сказать, что можно воспользоваться услугами прокси, не настраивая все самому.
Чтобы настроить Nginx в качестве обратного прокси-сервера, мы будем использовать параметр proxy_pass в файлах конфигурации Nginx.
Примечание. В этом руководстве предполагается, что вы немного знакомы с Nginx и уже установили и настроили Nginx на своем сервере.
Поскольку может быть только одна служба, прослушивающая порт 80 или 443, ваше приложение должно будет прослушивать другой порт, например порт 8081.
Самая простая конфигурация будет выглядеть примерно так:
Дополнительные настройки
Помимо директивы proxy_pass, есть несколько других директив, которые вы можете использовать для более сложной настройки.
Например, посмотрите следующую конфигурацию:
Вы можете установить необходимый заголовок прокси-сервера для передачи приложению, чтобы оно знало IP-адрес и удаленный адрес запроса и выводило правильное содержимое для сайта запроса.
Если ваше приложение отправляет большой кусок файла, то вы можете отключить proxy_buffers:Резюме
Самое приятное в нем то, что его конфигурация проста, проста в использовании и все же позволяет масштабироваться для более сложных сценариев.
Для получения более подробной информации вы можете ознакомиться с документацией по прокси-модулю Nginx или примерами конфигурации.
Читайте также: