Nginx Proxy Manager в Docker контейнере

Привет. Сегодня поднимаем панельку и по совместительству reverse-proxy Nginx Proxy Manager внутри докер контейнера. Ну и немного потренируемся для закрепления результата.

Необходимые требования

Чтобы всё получилось нам понадобится:

• Сервер с Root доступом. Рекомендую вот этот
• Установленный Docker + Docker-Compose
• 20 - 30 минут времени

В двух словах о Nginx Proxy Manager

NPM является обратным прокси(reverse proxy), основанным на Nginx. Имеет приятный и интуитивно понятный веб интерфейс.

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

Привязывать (проксировать) домены можно двумя разными способами

По порту - самый простой способ при этом есть минус в качестве торчащего наружу порта.

По хостнейму - более продвинутый способ, для которого нужно открыть только 3 порта 80, 443 и порт управления панелькой NPM. Порты всех остальных проксированных контейнеров не будут торчать наружу.

В пределах этого поста рассмотрим оба варианта проксирования.

Помимо проксирования в панельке предусмотрена работа с TLS(SSL) сертификатами. В рамках этого поста затронем несколько способов получения бесплатных SSL сертификатов:

• Бесплатный самообновляющийся сертификат от Lets Encrypt
• Бесплатный самообновляющийся wildcard сертификат от Lets Encrypt
• Бесплатный origin сертификат от CloudFlare на 15 лет

NPM в автоматическом режиме будет продлевать самообновляющийся сертификаты каждые 3 месяца за нас.

В NPM присутствуют специальные правила ACL для предоставления/ограничения доступа к вашим приложениям. На основе ip адреса, пароля, либо и того и того одновременно.

Ещё NPM умеет работать с редиректами и стримами, но их касаться в пределах этой статьи мы не будем.

Подготовка

Как и в предыдущих статьях про докер контейнеры мы будем придерживаться правила - хранить все контейнеры в одном месте. Создаём директорию под NPM

sudo mkdir -p /app/NPM

Сделаем нашего пользователя (не root !) владельцем этой директории

sudo chown -R $USER:$USER /app/NPM

Конфигурация и запуск

Перейдём в директорию, которую мы создавали выше

cd /app/NPM

Создадим фаил docker-compose.yml

nano docker-compose.yml

С таким содержанием.

На всякий случай оставлю конфиг под aarch64, оффсайт и dockerhub

Стартуем контейнер NPM

sudo docker-compose up -d

Настройка Nginx Proxy Manager

В браузере открываем нашу панельку NPM. Порт будет либо 81 либо тот который вы замапили на 81. Я советую на всякий случай замапить какой нибудь нестандартный порт например 43013

http://ip.адрес.вашего.сервера:порт

Выполняем вход с такими данными

Email: admin@example.com
Password: changeme

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

После этого откроется диалог смены пароля - вписываем стандартный changeme и ставим свой сложный пароль.

Обновляем записи DNS

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

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

Первым делом я предлагаю проксировать саму панельку на поддомен npm.example.com. Для этого в CloudFlare переходим в раздел DNS и создаём A-запись в поле Name вписываем npm, а в поле IPv4 address вписываем ip адресс сервера. Нажимаем save. Ждём какое то время, обычно около 5-10 минут иногда быстрее иногда дольше.

Proxy status то есть проксирование - выключаем.

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

Вариант 1: Проксируем приложение через NPM по порту

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

Возвращаемся в нашу Веб-панель NPM. В ней открываем Proxy Hosts и кликаем Add Proxy Host. И добавляем наш хост.

Вписываем имя домена или поддомена, ip адрес сервера, порт на котором у нас запущена админка NPM - по стандарту 81, я всё таки советую сменить на что нибудь неприметное наподобие 43013

Сразу добавим наш хост нажатием кнопки Save. Он появится в списке проксируемых хостов. В данный момент он должен открываться по протоколу http проверяем кликнув по хосту в панельке. В результате нам должен открыться сайт http://npm.example.com

Если всё хорошо и необходимый сайт открылся - переходим к следующему шагу - добавление SSL сертификата. Для этого нажимаем на три точки справа от хоста и нажимаем Edit. Переходим на вкладку SSL и запрашиваем новый SSL сертификат нажав на кнопку Save.

Снова кликаем по нашему хосту и проверяем что у нас автоматически редиректнуло на https://npm.example.com и что теперь у домена установлен вилидный SSL сертификат. Об этом сигнализирует знак замка в адресной строке.

Работает.

По мере добавления новых хостов, панелька будет выглядеть вот так.

Важно - для IDN-доменов нужно вписывать только punnycode!
Например для домена домен.com нужно вписать xn--d1acufc.com (при этом вписывать домен.com не нужно!).

Вариант 2: Проксируем приложение через хостнейм

Со временем понимаешь что все эти торчащие наружу порты никчему. И мы можем от них избавиться. Оставим открытыми только 80 и 443 порты, а всё остальное будет проксироваться с помощью магии докера.

Для сначала нужно создать отдельную сеть. В эту сеть мы добавим NPM а также все контейнеры, которые хотим проксировать. Создаём сеть

sudo docker network create -d bridge evilcorp

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

sudo docker network connect evilcorp portainer

Но лучше описать эту сеть в самом docker-compose.yml в таком случае мы избавимся он необходимости каждый раз добавлять контейнеры через CLI.

Я подготовил специальный фаил docker-compose.yml для NPM. В нём уже добавлены все необходимые параметры.

Отредактируйте старый фаил docker-compose.yml заменив его новым и перезагрузите контейнер

sudo docker-compose up -d --force-recreate

Посмотрим что было добавлено

У каждого контейнера появились директивы container_name:

container_name: nginx-proxy-manager-...

У каждого контейнера появились директивы networks:

networks:
  - default

В самом конце была добавлена определяющая директива

networks:
  default:
    external: true
    name: evilcorp

Мы прямо в docker-compose.yml указали что оба контейнера NPM: app(главное приложение) и db(база данных) находятся в одной сети evilcorp.

Ещё раз все последующие хосты которые мы будем проксировать следует добавлять в эту сеть. В моих фаилах docker-compose.yml это уже будет. Но если вы будете добавлять какой то новый сервис сами - не забудьте его добавить в сеть evilcorp!

Дополнительно мы назначили container_name для каждого контейнера и теперь мы можем обращаться к ним по имени как по DNS, внутри этой сети.

Возвращаемся в нашу панель и добавляем или редактируем хост npm

В графу Forward Hostname / IP* вписываем имя нашего контейнера nginx-proxy-manager-app

А в графу порт вписываем 81

И нажимаем кнопку Save.

В результате мы получим вот это

Но почему мы вписали порт 81, а не 43013? Дело в том что мы обращаемся к контейнеру из внутренней сети. Представьте что оба контейнера это 2 отдельных компьютера. На одном поднято само приложение, а на другом база данных. Находясь внутри этой сети вы будете обращаться к приложениям по внутреннему порту, который в docker обычно располагается справа. А не по внешнему порту, который располагается слева.

А раз теперь у нас всё общение происходит через внутреннюю сеть, то и порт выставлять наружу нам просто незачем. Поэтому ещё раз заходим в docker-compose.yml и комментируем строку

ports:
  - '80:80'
  # - '43013:81'
  - '443:443'

После чего вновь пересоздадим контейнер

sudo docker-compose up -d

В результате у нас открыты только 2 порта 80 и 443, а всё остальное проксируется средствами NPM. И нету больше никаких торчащих наружу портов.

Защищаем наши хосты NPM

В Nginx Proxy Manager есть встроенный механизм Access-control list(ACL), который позволит улучшить безопасность проксируемых приложений. Создадим для примера такое правило.

Переходим в пункт Access Lists и создаём новое правило Add Access List

Далее у нас будут 2 варианта валидации хорошего пользователя по Login + Password и по ip адресу.

Satisfy Any в выключенном состоянии означает что для успешной авторизации мы должны проходить сразу по двум правилам: Login + Password и по ip адресу. Если же мы включим Satisfy Any то для авторизации будет достаточно выполнения любого из условий.

Переходим на вкладку Authorization

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

Переходим на вкладку Access

Тут мы перечисляем списки ip адресов, которым хотим разрешить доступ. Поддерживаемый формат просто ip xxx.zzz.ccc.vvv и/или ip+подсеть xxx.zzz.ccc.vvv/24

Вводим данные и сохраняем по кнопке save. Появляется наше правило.

Возвращаемся к нашим хостам в Dashboard > Proxy Hosts

Выбираем хост к которому хотим применять только что созданные правила. Нажимаем справа на три точки и Edit попадаем в редактирование хоста. Выбираем только что созданный нами ACL.

Проверим что у нас получилось. Все проверки настоятельно рекомендую делать в браузере в режиме инкогнито.

В FireFox активируем сочетанием клавиш CTRL + SHIFT + P

В Chrome активируем сочетанием клавиш CTRL + SHIFT + N

Отправляемся по адресу где живёт нашё приложение и видим там

Введя валидные данные мы попадаем в наше приложение.

Для эксперимента я зашел туда же через VPN, ip адрес которого не в списке разрешённых и в результате получил такой результат

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

Бесплатный SSL сертификат от cloudflare на 15 лет

Бесплатные SSL/TLS сертификаты выдаёт не только Letsencrypt но и Cloudflare. Причём у CF его можно взять сразу на 15 лет. Но не спешите радоваться, помимо плюсов есть и минусы. Например для таких сертификатов нужно включить обязательное проксирование. То самое которое вместо вашего реального ip адреса выдаёт ip адреса Cloudflare. Это не всегда нужно, а в некоторых случаях вообще не нужно. Во всех остальных случаях это скорее плюс, т.к. улучшает нашу безопасность подменяя настоящий ip.

Основной минус проксирования состоит в том что там есть ограничение на размер передаваемого/загружаемого фаила при включенной проксификации. На бесплатном тарифе он равен 100 MB и срабатывает когда вы что то загружаете на сервер. Какие то виды П.О. разбивают загружаемые фаилы на чанки, тем самым обходя это ограничение, например Nextcloud так делает. А вот в каком то П.О. это не предусмотрено. Например File Browser так не делает и в результате фаилы больше 100 MB не загружаются. В таких случаях можно использовать сертификат от Letsencrypt при этом отключить проксирование на конкретный поддомен.

С минусами разобрались. Теперь переходим непосредственно к получению. Логинимся в свой аккаунт Cloudflare. У вас должен быть уже привязан домен, можно бесплатный от freenom. Отправляемся в раздел SSL/TLS > Origin Server. Изначально там будет пусто.

Нажимаем на кнопку Create Certificate. Попадаем в раздел создания сертификата. Там будет указано его название и в самом низу время на которое мы хотим получить этот сертификат. Указываем 15 лет и нажимаем ok.

Нас перекинет на специальную страницу. Сохраняем содержимое полей так как это указано на скриншоте в фаилы example.com.pem и example.com.key

Просто скопируйте содержимое и вставьте в блокнот, сохранив в фаил с необходимым именем. Обратите внимание что фаил не должен содержать пустых строк ни в начале ни в конце. Обязательно сохраните оба фаила. Если вы по какой то причине не сохранили оба фаила сразу то придётся перевыпускать сертификат, потому что во зайдя во второй раз на ту же самую страницу вы не увидите там example.com.key!

Нажав ок мы вернёмся в раздел SSL/TLS > Origin Server на этот раз в графе Hosts будет наш только что созданный сертификат.

Теперь переходим в раздел SSL/TLS > Overview. Тут необходимо выставить режим Full strict либо Full. Работать будет в обоих случаях но режим Full strict предпочтительнее.

Отправляемся в раздел DNS. Добавляем домен либо поддомен с включённой проксификацией.

Далее весь процесс будет происходить в NPM. Идём в раздел SSL Certificates и добавляем новый Custom SSL сертификат.

В появившемся окне заполняем

• Name * - любое имя для сертификата
• Certificate Key* - путь до фаила example.com.key
• Certificate* - путь до фаила example.com.pem

Последний пункт Intermediate Certificate необязательный поэтому его не заполняем. У меня фаил домена для примера называется example.com у вас же будет ваш домен поэтому заполняйте с учётом названия вашего домена. После чего нажимаем Save.

Мы добавили новый сертификат в NPM

Идём в раздел Hosts > Proxy Hosts

Добавляем новый домен/хост. Я добавлю хост для самого NPM

Переходим в раздел SSL и выбираем наш кастомный сертификат

Выставляем для него необходимые настройки и применяем

В итоге получаем рабочий хост с SSL/TLS сертификатом на 15 лет

С CloudFlare всё.

Получаем бесплатный wildcard сертификат от letsencrypt

Wildcard сертификат от letsencrypt это отличная альтернатива сертификату cloudflare, т.к. для этого сертификата не обязательно включать проксирование. На некоторых сервисах принудительное проксирование ограничивает нас в загрузке фаилов не больше чем 100 mb, а тут у нас получается развязаны руки - хотим включаем проксирование не хотим не включаем.

К сожалению этот сертификат нельзя получить для freenom доменов(.cf .tk .gq .ga .ml).

На главной странице Overview прокручиваем в самый низ до раздела API и нажимаем справа Get your API token.

На этой странице создаём новый токен нажав на Create Token.

Нас перекинет на страницу где уже содержатся разнообразные шаблоны.

В самом низу в разделе Create Custom Token создаём свой шаблон. Нажав на соответствующую кнопку Get started.

Придумываем ему название, я написал туда NginxProxyManager, можете написать любое угодное Вам название.

В разделе Permissions в выпадающем списке выбираем Zone. Во втором выпадающем списке выбираем DNS. В третьем Edit.

Всё остальное оставляем по умолчанию и нажимаем Continue to summary.

Попадаем на страницу где нам ещё раз показывают какими правами будет наделён наш токен, соглашаемся нажав по кнопке Create Token.

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

Так же на этой странице будет строка для проверки curl'ом можно протестировать в терминале, но это не обязательно.

Возвращаемся в NPM, идём в пункт SSL Certificates и добавляем сертификат Let's Encrypt

В поле Domain Names * вписываем *.example.com и example.com (подставьте свой домен вместо example.com). Можно по желанию также вписать сюда и основной домен, я не стал вписывать.

Нажимаем на радио-кнопки Use a DNS Challenge и I Agree to the Let's Encrypt Terms of Service

В разделе DNS Provider выбираем Cloudflare

В появившемся поле вместо 0123456789abcdef0123456789abcdef01234567 вписываем свой токен и нажимаем Save.

Раздел Propagation Seconds можно не заполнять.

Ожидаем несколько минут, обычно около 1 минуты, и получаем готовый wildcard сертификат.

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

Как сделать 301 и 302 редирект

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

Чтобы сделать такие редиректы открываем NPM далее идём в Proxy Hosts выбираем необходимый домен, справа нажимаем на троеточие и выбираем пункт Edit. В открывшемся окне выбираем пункт Advanced

Остаётся только вписать ваши редиректы. Делается это с помощью синтаксиса NGINX

rewrite ^/old-page$ /new-page permanent;

Приведу пару примеров

rewrite ^/blog/$ /blog.html permanent;
rewrite ^/drugaya_forma\.html$ /different-shape.html permanent;
rewrite ^/deleted\.html$ /404.html permanent;

Ура всё работает!!! Mission Completed!

Tags Docker Docker-Ready Docker-Ready-ReverseProxy Nginx