Леонид,
а вам не подходит вариант с auth_request и дополнительным скриптом? что-то
такое:
location / {
auth_request /auth-proxy;
add_header X-Client-Cert $ssl_client_cert;
proxy_pass http://backend;
proxy_set_header X-Client-Cert
Илья Шипицин wrote:
Ansible и подобные утилиты хороши для "развёртки" продуктов.
вы, конечно, извините, но следуя вашей же логике ... рассылка по nginx
касается, собственно, nginx. а у вас задача распространения файлов.
Обновление конфигурации nginx касается nginx непосредственно.
8 августа 2017 г., 17:00 пользователь leonid_belkind <
nginx-fo...@forum.nginx.org> написал:
> Ansible и подобные утилиты хороши для "развёртки" продуктов.
>
вы, конечно, извините, но следуя вашей же логике ... рассылка по nginx
касается, собственно, nginx. а у вас задача распространения файлов.
Выкатка нового CLR по хостам разве не похожа на задачу деплоя?
8 августа 2017 г., 15:00 пользователь leonid_belkind <
nginx-fo...@forum.nginx.org> написал:
> Ansible и подобные утилиты хороши для "развёртки" продуктов.
> Оне не предназначены для использования как часть бэк-энда продукта. Это
>
Ansible и подобные утилиты хороши для "развёртки" продуктов.
Оне не предназначены для использования как часть бэк-энда продукта. Это
конечно можно сделать, но это просто не правильно.
В нашем продукте, certificate revokation это часть стандартного функционала.
Задача не автоматизировать
> Если работать с файлами, то нужно будет их копировать на все хосты, и
потом перезагружать конфигурацию NGINX
для такого рода задач давно придумали ansible и т.п. утилиты. В чем
проблема?
2017-08-08 11:40 GMT+03:00 leonid_belkind :
> Уважемые коллеги,
>
> Мы
Уважемые коллеги,
Мы пытаемся создать конфигурацию NGINX для проверки сертификатов
"клиентов".
Кофигурация работает, но единственный способ передать информацию об
отозванном сертификате это CRL файл.
В нашем случае это очень проблематично, поскольку у нас прокси разбросан в
контейнерах