Comments 13
Отличный пост!
Кстати, есть чат по Nexus https://t.me/ru_nexus_sonatype
Очень жаль, что не рассмотрен containerd. CRI-O решение неплохое, но гораздо менее популярное, конечно.
Что еще мне не понравилось в конфигурации CRI - то, что это нужен полный доступ к узлам. А если дело происходит в облаке и нет возможности менять конфиги на узлах кубернетес кластера?
Еще вариант (идею) - дарю - можно написать mutation webhook, который будет переписывать поле image: во всех pod'ах - в этом случае можно вообще не пользоваться прокси-репо, а попросту переложить все образа к себе.
И еще фактор, который мне в прокси не нравится - он не ускоряет дистрибьюцию образов по узлам (для этого надо использовать решения вроде https://github.com/uber/kraken но я сильно тему не изучал) и второй момент - если образ удалили или подменили в удаленном регистри (например, на докерхабе это достаточно частая проблема), то кэш тут может не помочь...
Еще что добавить хочу - не обязательно покупать платный Artifactory. Разработчики предлагают бесплатную версию на той же кодовой базе, но с ограниченным функционалом ТОЛЬКО для докер образов - https://jfrog.com/container-registry/ Странно, что этот продукт не рассмотрен в обзоре. По идее у него настройка такая же, как у полного JFrog Artifactory, но не нужно выкладывать сотни нефти :-)
А еще меня удивила стрелочка на диаграмме от Flux/Argo к podman. Если в случае kubernetes/openshift + cri-o я понимаю, почему она там есть, то в случае podman не очень, потому что эти решения напрямую не интегрируются. Что я упустил?
https://jfrog.com/container-registry/ Странно, что этот продукт не рассмотрен в обзоре.
Спасибо, ссылку на бесплатный container-registry в статью добавил, а вот рассматривать Artifactory не стал, также как и Quay, я посчитал, что это будет избыточно, достаточно упоминания в сравнении и ссылки на руководство.
для JFrog Artifactory настройка будет похожей и описана в официальной документации
А еще меня удивила стрелочка на диаграмме от Flux/Argo к podman.
А вы внимательный :)
Даже не знаю как она там оказалась, видимо это всё мои мечты под впечатлением новости, что podman теперь умеет не только Pod запускать но и Deployment.
Что еще мне не понравилось в конфигурации CRI - то, что это нужен полный
доступ к узлам. А если дело происходит в облаке и нет возможности
менять конфиги на узлах кубернетес кластера?
Подскажите, а как вы изменяете конфиги containerd на узлах где нет возможности их изменять?
Небольшой дисклеймер - когда я пишу "CRI", то я имею в виду и cri-o, и containerd , и любой другой контейнерный движок.
В случае облака - если нет возможности, то нет возможности. Приходится придумывать обходные пути.
Какие плюс-минус рабочие варианты знаю:
Если есть поддержка своих шаблонов воркеров - можно конфиг вшить туда
Если такого нет, но очень хочется - можно попробовать раскатать daemonset с hostpath, чтобы заменить на узлах файлы конфигурации. Но это уже не так надежно, т.к. влезаешь в логику работы платформы
Если и этого нет, тогда похоже все ) и нужно искать альтернативные способы получить желаемое (не через конфиг)
Не спорю, что в статье приведено нишевое решение, если абстрагироваться от облаков, в случае on-premise решений, особенно в совокупности таких факторов как: закрытый контур, строгая политика ИБ и медленный интернет канал, проксирование очень даже упрощает и ускоряет дистрибьюцию.
если образ удалили или подменили в удаленном регистри, то кэш тут может не помочь
Если подменили, то всё будет хорошо, прокси в первую очередь валидирует метаданные, сверяет их с удаленным реестром контейнеров, и только если изменений нет (или сервер не ответил) мы получим данные из кеша. Касаемо удаления, это вопрос хороший, в Nexus знаю есть отдельная опция для обработки и кеширования 404, а в Distrubution кеш для удаленного образа, скорее всего продолжит своё существование. В любом случае, для кеша полезно делать отдельную задачу в планировщике, для удаления старых и неиспользуемых образов, что от части решает вопрос удаления.
можно написать mutation webhook
А можно не писать, используя CRI-O/Podman и конфигурацию registries.conf :)
Мне кажется идея с mutation webhook для image может нарушить работу keel.sh и подобных решений, но это не точно, нужно проверять на практике.
Если подменили, то всё будет хорошо, прокси в первую очередь валидирует метаданные, сверяет их с удаленным реестром контейнеров, и только если изменений нет (или сервер не ответил) мы получим данные из кеша. Касаемо удаления, это вопрос хороший, в Nexus знаю есть отдельная опция для обработки и кеширования 404, а в Distrubution кеш для удаленного образа, скорее всего продолжит своё существование. В любом случае, для кеша полезно делать отдельную задачу в планировщике, для удаления старых и неиспользуемых образов, что от части решает вопрос удаления.
как раз не хорошо.
Потому что если образ с докерхаба удалили, а мы им пользуемся, то если он исчезнет из кэша - мы получим неработоспособную систему (образа-то нет!)
В случае, если кто-то образ обновил - тоже большой вопрос - хотим ли мы, чтобы софт обновился (например, мы намеренно указали :latest на dev-стенде), но для прода это попросту недоступимо, потому что мы рассчитываем на то, что то, что мы задеплоили, то и будет крутиться, пока мы явно не обновим тег-версию.
Мне кажется идея с mutation webhook для image может нарушить работу keel.sh и подобных решений, но это не точно, нужно проверять на практике.
может быть, но можно это сделать аккуратно :-)
Потому что если образ с докерхаба удалили, а мы им пользуемся, то если он исчезнет из кэша - мы получим неработоспособную систему (образа-то нет!)
Так он и не удалится, если мы не делали ротацию старого кеша или не настроили чего-то дополнительно для обраотки удаленных образов.
Касаемо latest, мне кажется это выбор каждого, и если мы указали postgres:13.5-bullseye за место postgres:13 , значит мы пошли на это осознанно, и кешем стандартный механиз поставки не нарушаем. Иначе могут возникнуть вопросы - "а почему мой latest не latest?".
Для жёсткой фиксации на версии, всегда можно указать конкретный манифест:
postgres:13.5-bullseye@sha256:3f34db7403050a89aecb3e17d3f22c771b76120565d113d5462f673e229c5472
Благодарю за статью, но у вас перевод немного кривой:
При использовании коротких имен всегда существует риск того, что извлекаемое изображение может быть подделано. Если нужный реестр контейнеров не стоит первым в списке поиска, злоумышленник может разместить другое одноименное изображение в публичном реестре, находящемся раньше в списке поиска. Пользователь случайно получит и запустит образ и код злоумышленника, а не ожидаемый контент.
Какое нафиг "изображение"? Может имеется ввиду "образ"?
Прозрачно кешируем несколько Container Registry в CRI-O и Podman