Каждый раз, когда мне приходилось настраивать Nginx для прокси-сервера в контейнерах Docker, не только из-за аспекта безопасности, который, как вы упомянули, является автономным в контейнере Docker, но и для облегчения связи с распределенной системой.
В стандартной архитектуре у вас есть контейнер API, контейнер IDP и контейнер внешнего интерфейса (предположим, что это веб-приложение). Все позади Nginx. IDP, API и интерфейс подвержены внешнему трафику... но тут начинается самое интересное. Допустим, вы хотите, чтобы в другом контейнере работала дополнительная служба (служба геолокации, ETL или что-то еще). Этот контейнер не нужно выставлять на всеобщее обозрение. Только внутренние контейнеры могут говорить с ним.
В предыдущем сценарии запрос попадет на внешний интерфейс, внешний интерфейс отправит запрос (запросы) в API, API проверит токен с помощью IDP (внутренний вызов), если нет авторизации, перенаправит внешний интерфейс на IDP (трехсторонняя аутентификация). или просто верните 403 и повторите аутентификацию пользователя (двухсторонняя аутентификация), снова отправив учетные данные обратно в API. Затем, если пользователю необходимо вызвать какую-либо дополнительную службу, все вызовы будут сначала проходить через API, ИЛИ они могут быть сопоставлены в Nginx для прямого обращения к службе, просто убедитесь, что пользователь прошел аутентификацию/авторизован для использования службы.
Я надеюсь, что это проливает свет на конкретное использование Nginx. Имейте в виду, что это всего лишь «один» вариант использования, но Nginx можно использовать для многих других целей.
11.04.2017