Comments 8
Ну вот фича-то полезная (docker_endpoint), однако снова сделана немного наспех. То же самое было в Traefik v3.
Как я понимаю, Angie только читает из docker-сокета, следовательно, ему не нужен полный доступ. Чтобы его не давать - используются различные прокси-сервисы с авторизацией. Однако, авторизация здесь не поддерживается.
у пользователя, под которым запускается Angie, должны быть права чтения и записи для этого сокета
А запись-то ему зачем?
@VBart, планируется ли добавить хотя бы Basic авторизацию в эту директиву? `http://username:password@host:port ?
А запись-то ему зачем?
Потому, что Docker API работает по HTTP-протоколу. И чтобы прочитать какой-то ответ из сокета - туда сперва нужно записать запрос. Но даже если бы было иначе, то в Linux просто даже для подключения к Unix-сокету уже нужны права на write.
@VBart, планируется ли добавить хотя бы Basic авторизацию в эту директиву? `
http://username:password@host:port?
В директиву - нет. Но авторизация поддерживается уже сейчас. Через настройки блока client {} можно добавить какие угодно заголовки авторизации к запросу или даже клиентский сертификат, пользуясь обычными директивами модуля http proxy.
Самым нормальным способом была бы возможность в самом докере создавать дополнительные unix-сокеты с перенастроенным ограниченным доступом к API.
О, спасибо, блок client, вроде бы, вполне подходит. Я не помню такой фичи в nginx - это специфический блок, добавленный только в Angie?
Потому, что Docker API работает по HTTP-протоколу. И чтобы прочитать какой-то ответ из сокета - туда сперва нужно записать запрос.
Да, я понял ваш ответ, спасибо. А если я вместо сокета даю http ссылку на какой-то эндпоинт - ему достаточно GET запросов же? Хотелось бы в документации видеть список методов, которые нужны из API, чтобы только минимум разрешить.
Для докера - вы периодически читаете весь список контейнеров заново или подписываетесь на события? Судя по документации - второе. В таком случае - поддерживается ли Docker Swarm? Насколько я помню (не 100%) - там нет эвентов, они только для хоста.
Что если проксируемый сервис имеет более одного порта? Непонятно как метками управлять в данном случае. А если каждый порт - в отдельную docker-сеть? (этот случай - это уже что-то сложное, я не ожидаю что вы это поддерживаете, но интересно).
Как в конфиге управлять роутингом на разные порты сервиса? `location /abc/` на порт 8080, а `location /xxx/` на порт 9090 - так можно?
А можно задавать конфигурацию сервисов не через labels, а через конфиг? hot reload поддерживается же, так что можно конфиг подсовывать наживую.
У меня это всё реальные примеры. У меня Docker Swarm и сейчас у меня стоит Traefik, но он мне очень не нравится и мне бы хотелось его чем-то заменить.
Я не помню такой фичи в nginx - это специфический блок, добавленный только в Angie?
Да, вот выше в новости, как раз, предпоследним пунктом в списке изменений.
А если я вместо сокета даю http ссылку на какой-то эндпоинт - ему достаточно GET запросов же?
Да
Хотелось бы в документации видеть список методов, которые нужны из API, чтобы только минимум разрешить.
Ок. Добавим.
GET /version
GET /vX.Y/containers/json"
GET /vX.Y/containers/ID/json"
GET /vX.Y/events?filters=...
Для докера - вы периодически читаете весь список контейнеров заново или подписываетесь на события?
Подписываемся на события.
В таком случае - поддерживается ли Docker Swarm?
В текущей версии не поддерживается. Добавим ли поддержку позже - да, возможно.
Что если проксируемый сервис имеет более одного порта? Непонятно как метками управлять в данном случае.
Добавить метки с портами, которые будут добавляться в разные usptream-группы.
Пример:- "angie.http.upstreams.web.port=80"- "angie.stream.upstreams.mqtt.port=1883"
А если каждый порт - в отдельную docker-сеть? (этот случай - это уже что-то сложное, я не ожидаю что вы это поддерживаете, но интересно).
Такое скорее всего сейчас не получится настроить. Но я завтра уточню у автора функциональности.
Как в конфиге управлять роутингом на разные порты сервиса?
location /abc/на порт 8080, аlocation /xxx/на порт 9090 - так можно?
Вот в примере выше адреса добавятся в разные группы upstream с названиями: web и mqtt, причем даже разных модулей - http и stream. Можно добавить в разные upstream-группы в http, а там уже должны на них смотреть разные location.
А можно задавать конфигурацию сервисов не через labels, а через конфиг? hot reload поддерживается же, так что можно конфиг подсовывать наживую.
Не совсем понял, что имеется в виду, можно чуть подробнее с примером?
Не совсем понял, что имеется в виду, можно чуть подробнее с примером?
Ну вот вся функциональность из labels, но только описаная в конфиге. И отключать конфигурацию из labels. Сервисы группировать либо по именам, либо по тем же labels (просто имена).
Пример конфига красивый придумать не смогу, но, вероятно, тоже что-то типа блока docker_service.
Да, будет более статическая конфигурация, но иногда это и надо. Например, никакие новые неизвестные сервисы не добавятся, конфигурация хранится и управляется в одном месте.
Правильно ли я понял, что это как если бы в блоке upstream в директивах server вместо IP-адреса можно было бы имена контейнеров указать?
Ну вот здесь уже возможны варианты. Контейнеров может быть разное количество и имена у них могут автоматически назначаться, однако кто-то может захотеть жёстко гвоздями прибить конфигурацию на именах контейнеров. Может и я захочу потом.
Лично мне нужны будут имена сервисов (как в compose или Swarm), либо, может быть, hostname - но с ними могут возникнуть сложности (особенно с разными сетями). Сервис может иметь несколько инстансов контейнеров.
Очевидно что у вас нет цели поддерживать все фичи докера, спасибо даже на тех что уже есть. В принципе, мои задачи для Swarm может решить даже обыный docker-резолвер, который в последних версиях nginx доделали.
Спасибо, ознакомился (͡°͜ʖ͡°)
Вышел веб-сервер Angie 1.10.0, созданный бывшей командой Nginx