S🛸
Да, какая разница где докерфайл лежит?
Size: a a a
2020 April 15
S🛸
Нашёл, нужно использовать префикс $PWD
i
Нашёл, нужно использовать префикс $PWD
Это не относительно compose файла
i
можно запустить docker-compose -f ./compose/docker.compose.yml up и все сломается
S🛸
Ну это лучше чем ничего
i
olli Олли
Почитал про то что предлагают для docker registry для окружений с single sign on.
Для тех у кого частный случай есть список рецептов: https://docs.docker.com/registry/recipes/ , апач у нас в конторе не популярен у админов и отаётся nginx: https://docs.docker.com/registry/recipes/nginx/ .
"this model gives you the ability to use whatever authentication backend you want through the secondary authentication mechanism implemented inside your proxy"
"it also requires that you move TLS termination from the Registry to the proxy itself."
Предлагают они использовать свой проксирующий web-сервис с поддержкой token authentication:
https://docs.docker.com/registry/spec/auth/token/
V1 registry у нас я думаю не рассматриваются, так что
"Under the Registry V2 workflow, clients should contact the registry first. If the registry server requires authentication it will return a 401 Unauthorized response with a WWW-Authenticate header detailing how to authenticate to this registry."
То есть подружить это с каким нибудь keycloak вполне реально.
Всё это замечательно, но хотелось бы делить доступ к образам пофайлово. На текущий момент резюме одного из админов - docker registry не умеет пофайловый доступ.
Да, не умеет, но насколько сложно это реализовать и не сделал ли кто уже такое в open source?
Например мне думается, что проксирующий (для организации аутентификации) nginx мог бы направлять http запросы авторизованных (для работы с регистри) пользователей на некое приложение, которое по тегу образа могло бы инструктировать nginx отдавать registry клиенту 401 Unauthorized при попытках скачать конкретный образ из репозитория (на основе его тега или имени).
Возможно ли такое?
Контекст вопроса в том, что мы эксплуатирующая некую web платформу организация и если вводить на каждого разработчика по reggitry этих регистри станет слишком много, это станет неудобно обслуживать. С другой стороны, если модуль платформы передадут в разработку от одной програмистской конторы к другой, то придётся переделывать кучу сборок и, скорее всего, вручную.
Вопрос архитектора звучал так - кто нибудь задумывался над best practice в такой ситуации или читал об этом?
Для тех у кого частный случай есть список рецептов: https://docs.docker.com/registry/recipes/ , апач у нас в конторе не популярен у админов и отаётся nginx: https://docs.docker.com/registry/recipes/nginx/ .
"this model gives you the ability to use whatever authentication backend you want through the secondary authentication mechanism implemented inside your proxy"
"it also requires that you move TLS termination from the Registry to the proxy itself."
Предлагают они использовать свой проксирующий web-сервис с поддержкой token authentication:
https://docs.docker.com/registry/spec/auth/token/
V1 registry у нас я думаю не рассматриваются, так что
"Under the Registry V2 workflow, clients should contact the registry first. If the registry server requires authentication it will return a 401 Unauthorized response with a WWW-Authenticate header detailing how to authenticate to this registry."
То есть подружить это с каким нибудь keycloak вполне реально.
Всё это замечательно, но хотелось бы делить доступ к образам пофайлово. На текущий момент резюме одного из админов - docker registry не умеет пофайловый доступ.
Да, не умеет, но насколько сложно это реализовать и не сделал ли кто уже такое в open source?
Например мне думается, что проксирующий (для организации аутентификации) nginx мог бы направлять http запросы авторизованных (для работы с регистри) пользователей на некое приложение, которое по тегу образа могло бы инструктировать nginx отдавать registry клиенту 401 Unauthorized при попытках скачать конкретный образ из репозитория (на основе его тега или имени).
Возможно ли такое?
Контекст вопроса в том, что мы эксплуатирующая некую web платформу организация и если вводить на каждого разработчика по reggitry этих регистри станет слишком много, это станет неудобно обслуживать. С другой стороны, если модуль платформы передадут в разработку от одной програмистской конторы к другой, то придётся переделывать кучу сборок и, скорее всего, вручную.
Вопрос архитектора звучал так - кто нибудь задумывался над best practice в такой ситуации или читал об этом?
А как делить доступ пофайлово? Учитывая, что каждый образ - много файлов и у разных образов они могут пересекаться?
oО
так тег же? Имеется ввиду пообразно. Пофайлово я некорректно написал походу.
i
Ну по тегам кмк тоже смысла нет
i
Обычно делят по репам
i
Типа вася может скачать образ:tag1, петя образ:tag2, а маша образ:tag3. При этом tag3 = latest, но маша его скачать не может, а tag2 и tag 1 одинаковые
oО
разработчикам сказать, что согласно административным договорённостям вы можете в регистри пушить только с тегами вида devcompany_module_something , соответственно отказывать в загрузке образов не в формате и отказывать группе юзеров (token auth из keycloack по ldap группе выдаваемый, например) скачивать или пушить всё что не матчит их ^devcompany_module_* .
oО
регистри приватное. Есть dev/stage/predprod/prod. Хотите участвовать - вот вам правила.
Но это так - в порядке размышлений пока.
Но это так - в порядке размышлений пока.
i
Все эти параметры есть в запросе, можно сделать миддлварь на которой проверять
i
Но главный вопрос - а нахрена это?
oО
ну чтобы не плодить стопятьсот регистри.. системному архитектору это не очень нравится. Мне просто интересно - не хотите per company registry - может есть такая мидлварь или её достаточно просто написать и выложить в opensource например.
oО
насколько я тебя понял best practice считается всё же по регистри на разрабатывающую компанию?
i
olli Олли
насколько я тебя понял best practice считается всё же по регистри на разрабатывающую компанию?
Ну да
i
Разрабатывающая компания - именно компания или команда?
oО
компания.
https://habr.com/en/company/flant/blog/465131/ - архитектор смотрит в сторону кубера, а конкретный инструмент для docker registry который я хотел уже запилили (что я и предполагал):
https://github.com/SUSE/Portus
https://habr.com/en/company/flant/blog/465131/ - архитектор смотрит в сторону кубера, а конкретный инструмент для docker registry который я хотел уже запилили (что я и предполагал):
https://github.com/SUSE/Portus
oО
телега как обычно в preview поставила не самый правильный url )