Nginx с человеческим лицом: обзор Nginx Proxy Manager

[OFrol]

не пишите конфиги руками, если это можно не делать

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

По существу вопроса: если у вас уже и так есть docker, то логично его использовать в качестве service discovery. Например, можно поставить Traefik или Caddy, и конфигурировать эндпоинты и https для сервисов в самих сервисах.

Всё что вам нужно, это поднять один контейнер с Traefik или Caddy и настроить их на получение конфигурации из соседних docker-контейнеров.

Например, вот docker-compose.yml для какого-то сервиса MY_SUPER_SERVICE, обратите внимание на labels:

services:
  MY_SUPER_SERVICE:
    image: ...

    labels:
      - traefik.enable=true
      - traefik.http.routers.MY_SUPER_SERVICE.rule=Host(`SERVICE.example.com`)
      - traefik.http.routers.MY_SUPER_SERVICE.entrypoints=https
      - traefik.http.routers.MY_SUPER_SERVICE.tls.certresolver=letsencrypt
      - traefik.http.services.MY_SUPER_SERVICE.loadbalancer.server.port=8080

    networks:
      - traefik

networks:
  traefik:
    external:
      name: traefik

Это единственная конфигурация, которую вам нужно будет сделать для каждого нового сервиса. Traefik сам обнаружит появление нового контейнера, сам получит для него LE-сертификат для домена SERVICE.example.com и сам будет этот сертификат обновлять когда требуется. И так же сам всё подчистит, когда вы этот контейнер удалите.

Никаких веб-интерфейсов и ручного труда - вы просто делаете docker compose up -d для своего сервиса и через несколько десятков секунд получаете работающий эндпоинт с https

[baldr]

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

Это ок если вы один - можно всё запомнить. А вот как только появяется в команде хотя бы ещё один человек - то сразу возникают вопросы - кто, что, когда и как поменял?

Он, конечно, все настройки сохраняет в стандартный конфиг nginx, и можно его оттуда в git закачивать. Но где вы это будете делать - на продакшен-сервере? (на всех?).

Вызывает некоторое уважение список из 851 открытых issue на Github, а также 88 висящих pull-requests. Первая страница багов - только в течение последнего месяца. Встречаются совсем глупые, которые бы должны тестироваться вовремя. Есть серьёзные уязвимости безопасности, которые не чинятся годами. В общем, я бы не спешил это ставить себе.

[mgis]

Полностью с вами согласен, использование Traefik/Caddy с Docker labels — это более правильный подход для автоматизации. Мой подход в статье скорее ориентирован на тех, кто только начинает знакомство с self-hosted решениями или кому психологически проще контролировать процесс через GUI на этапе прототипирования. Но ваш пример с docker-compose.yml — отличное дополнение к материалу, спасибо!

[UnstoppableRage]

Если так уж сильно хочется гуйни для энжа, то я бы посоветовал обратить внимание на Nginx UI. В нем есть возможность редактировать блоки конфигов ручками просто через текстовый редактор. Если по какой то причине подрубаться по ssh кажется неудобным, то это неплохой вариант. Плюс умеет acme и даже делать записи в разных провайдерах dns серверов.

[mgis]

Впервые слышу про такой инструмент. По ощущениям что то очень близкое, к тому что я искал.

[UnstoppableRage]

Я какое-то время назад так же искал инструмент который будет браузерным, но при этом позволит редактировать конфиг "по старинке". И перебрав несколько штук остановился именно на этом. И в целом, в данный момент использую его в домашней лабе для управления сервисами внутри своей сети. Даже терминал встроенный есть. В целом штука достаточно удобная для человека который понимает что делает, но вот для новчика возможно будет не так удобно.

[Sigest]

Поддерживаю. Мне он показался удобнее.

[corporate-sellout]

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

[Funkub]

Ну на мой взгляд NPM отлично подходит для хомлаба и например какого то быстрого тестового проекта, где надо 1-2 домена использовать, без автоматизации и вот этого вот всего, а для продакшена логично использовать более защищенные/автоматизированные/узкопрофильные инструменты.

[OFrol]

У меня абсолютно противоположный опыт: если забивавать на ansible и любую другую автоматизацию, то хомлаба очень быстро превращается неподдерживаемое непотребство, в котором уже через год невозможно ничего понять. Никто (включая автора) уже не будет знать для какого проекта что и в каком конфиге было поменяно и зачем.

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

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

[Funkub]

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

[dimka511]

Я на своей хомлабе перешёл с npm на traefik + mantrae

Мне кажется это лучше

[ritorichesky_echpochmak]

https://github.com/nginx-proxy/nginx-proxy/

services:
    nginx-proxy:
        container_name: nginx-proxy
        image: nginxproxy/nginx-proxy:1.8.0
        ports:
          - "80:80"
          - "443:443/tcp"
          - "443:443/udp"          
        volumes:
            - vhost.d:/etc/nginx/vhost.d
            - ./certs:/etc/nginx/certs:ro
            - html:/usr/share/nginx/html
            - /var/run/docker.sock:/tmp/docker.sock:ro
        environment:
          - ENABLE_HTTP3=true
          - TRUST_DOWNSTREAM_PROXY=false
        restart: always
        networks:
          - default

    nginx-proxy-letsencrypt:
        container_name: nginx-proxy-letsencrypt
        image: nginxproxy/acme-companion:2.5.2
        volumes:
            - acme:/etc/acme.sh
            - vhost.d:/etc/nginx/vhost.d
            - ./certs:/etc/nginx/certs:rw
            - html:/usr/share/nginx/html
            - /var/run/docker.sock:/var/run/docker.sock:ro  
        environment:
            - NGINX_PROXY_CONTAINER=nginx-proxy
        depends_on:
            - nginx-proxy
        restart: always
        networks:
          - default

networks:
    default:
      external: true
      name: network

volumes:
    vhost.d:
    html:
    acme:

во всех остальных петах просто добавляется

serivices:
  my_service:
    environment:
      - VIRTUAL_HOST=${VIRTUAL_HOST}
      - LETSENCRYPT_HOST=${VIRTUAL_HOST}
      - LETSENCRYPT_EMAIL=admin@${VIRTUAL_HOST}

networks:
  default:
    external:
      name: network

если хочется чтобы это был не хост, а как бы подраздел хоста, добавить

environment:
  - VIRTUAL_PATH=/rss-bridge/
  - VIRTUAL_DEST=/

Всё. Хочешь в git суй, хочешь бэкапь, хочешь через ansible разворачивай, хочешь - переноси куда хочешь, все CLI тулы работают.

[baldr]

Ну, во-первых, NPM - это не цель, а средство. Цель - настроить nginx, верно? И именно его конфигурацию хочется бэкапить и переносить. Переезжаете вы на новый сервер - как всё перенести?

Во-вторых, доступ к /var/run/docker.sock - это сразу красный флаг. Это, практически, вы даёте доступ приложению к хосту с root-правами. Нужно, хотя бы, какие-то прокси для ограничения доступа ставить. Если в приложении находят уязвимости с произвольным выполнением команд, то это реальная проблема. Вы же не хотите майнер на хосте найти как-нибудь?

Ну и вообще, nginx - это не просто vhost/location/certificate - там много чего может быть. Начиная от банального .htaccess, до немного более сложного auth_request или просто error_page..

[ritorichesky_echpochmak]

Ага, NPM не цель, а средство, которое мордой в Интернет торчит и не умеет в auto discovery. И да, его как раз тут и продают как "поменьше nginx настраивать". Отлично конфигурация в docker-compose.yml бэкапится и переносится.

Во-вторых, как по вашему все остальные делают service discovery? Выше вы что-то на траефик не агрились, nginx то чем не угодил? Волшебства не случилось. Лучше будет один открытый понятный сервис на базе достаточно надёжного ПО смотреть в docker-sock, чем разброд и шатания настроенные левой пяткой и торчащие бесконтрольно в мир. Ну и да, очень странно тащить что попало, а потом надеяться что изоляция докера достаточно надёжна и всё это не протечёт в систему)))) Может поэтому у меня майнеров никогда не водилось...

.htaccess там или ещё что - зависит от конечного контейнера, который для внешнего брокера выглядит как какой-то ещё один сервис до которого нужно пробросить трафичек в соответствии с правилами. Брокер в душе не чает какое там на эндпоинте приложение вам error_page возвращает потому что вы не смогли CORS забороть))) Но это вот вообще не про NPM речь.