Comments 18
Мощно.
То что искал недавно. А то большинство свободных веб интерфейсов к DockerRegistry — «бедненькие».
Ещё и пример интеграции с Kubernetes имеется.
Жаль ресурсов много хочет. На тестировочном кластере — особо не разгонишься…
Quay же платный, верно? Логичнее было бы вспомнить о GitLab тогда.
CaaS тоже ведь включает в себя понятие PaaS. Т.е. если сама система может билдить и хранить имеджи — то это PaaS, если же нет — то IaaS.
Конкретно Nexus — куда более разносторонний комбайн, что говорит об очевидных плюсах и минусах сразу. Много ли специфики конкретно Docker-образов там учтено? Например, поддерживаются ли те фичи безопасности, на которые сделан упор в последних релизах Harbor?
Так я тоже не говорю, что он единственный и идеальный. Ну то есть это не агитация была, а скорее попытка понять, есть ли что-то такое, чего в нем не хватает. Мне когда вообще встал вопрос со внутренним реестром (в интранете), первое что пришло в голову — это развернуть еще один nexus. Ну и на все про все ушло максимум час — от скачать до создать первый свой docker registry.
>обзор с большим количеством альтернатив
В котором, кстати, нет нексуса, зато есть еще один представитель мира maven — артифактори.
В целом же я думаю, что Nexus куда более разносторонне используемый комбайн. На нем уже с десяток лет строится такое множество репозиториев maven, которое, как я подозреваю, пока не снилось пользователям докера. Да и размеры в общем весьма впечатляющие. О безопасности авторы думают, в этом можно легко убедиться, почитав хотя бы их блог — там большая часть постов на эту тему. Т.е. про аудит репозиториев, например, они уже думали много лет назад. И уж всяко там с аутентификацией и авторизацией все нормально, AD поддерживается, например.
Понятно что у докера есть специфика. Но как вы понимаете, если туда смогли впилить npm, pip, maven и докер одновременно, поддерживать разную специфику Sonatype умеет.
Он там тоже есть: «Sonatype Nexus, which supports hosted and on-premises deployments, is a general-purpose repository. It supports much more than Docker image hosting…».
Про общие фичи (вроде авторизации) вы рассказали — это я под сомнение и не ставил. Но про специфику всё-таки явного ответа не увидел… Ниже в комментариях пользователь Nexus указывает конкретные минусы, заодно отвечая и на вопрос про фичи в безопасности.
Что-то там какая-то урезанная инструкция: «Current deployment does not include Clair and Notary, which are supported in docker-compose deployment. They will be supported in near future, stay tuned.»
Вот вроде бы есть Helm chart: github.com/goharbor/harbor/tree/master/contrib/helm/harbor
Вообще интересная штука. Сейчас пользуемся Нексусом, но надо эту штуку попробовать.
Меня попросили сравнить с Artifactory, так что я прям тут и напишу.
управление доступом на основе ролей
Есть.
пользовательский веб-интерфейс для просмотра репозиториев, поиска по ним, управления проектами;
Есть.
аудит всех операций;
Есть.
REST API для управления.
Есть.
Сканирование уязвимостей.
Есть, причем не только os level, но и вся аппликативная часть, вне зависимости от того, на чем написана.
Подпись образов.
Из коробки нет, но нет никаких проблем вызывать notary из beforeDownload user plugin–a, если надо.
Теперь, о главном. Никто, и вы в том числе не используете в организации только докер. В контейнеры вы заворачиваете код, при написании которого используется дофига всего, всякие джавы, питоны, сишарпы, гошечки, и даже, возможно, джаваскрипт. Весь этот зоопарк тоже требует управиления зависимостями, и если вы смотрите на Харбор, то даже энтерпрайзного уровня. Вы, конечно, можете, притащить для каждого элемента стэка свою балалайку, и даже, допустим, она будет отлично работать, но как вы сможете коррелировать между зависимостями и артифактами аппликативного уровня, образами Докера и чартами Хелма? Как вы сможете сказать "мне в продакшн нужен последний чарт, в образе которого нет никаких уязвимостей, и джавовый код которого прошёл все проверки в своем джавовом пайплайне"?
Ну, и пожалуй спрошу у вас вот еще что, неужели вам бы не хотелось иметь более строгие границы между этапами пайплайна для контейнеров, чем просто директории внутри regisry? Например, отдельные registry для dev и prod? Если да, то может не стоит ставить по registry для каждой среды, а вместо этого пользоваться тулом, в котором можно сделать сколько хочешь таких registry, опять же с promotion и связью между ними?
Ну и напоследок, я не знаю, как в Харборе с такими enterprise фичами как high availibilty, replication и подключаемым любым storage? Потому что это обязательные штуки для того, чтобы называться "registry-сервером корпоративного класса".
Harbor — реестр для Docker-контейнеров с безопасностью «из коробки»