Pull to refresh

Comments 18

Пасиб за статью!
Мощно.
То что искал недавно. А то большинство свободных веб интерфейсов к DockerRegistry — «бедненькие».
Ещё и пример интеграции с Kubernetes имеется.

Жаль ресурсов много хочет. На тестировочном кластере — особо не разгонишься…
> Казалось бы, уже есть Docker Registry  (или, скажем, Quay от CoreOS)

Quay же платный, верно? Логичнее было бы вспомнить о GitLab тогда.
Gitlab вообще прекрасен в плане CI и как docker registry, не вижу особых причин использовать что-то другое.
Хотя здесь наверное дело в масштабах…
Ну в докер реджистри вообще нет никакой веб-админки.
Вот, к слову, обзор разных registries. Он уже староват, но хотя бы всех упоминает.

У gitlab нет функционала для лимитов на каждый проект.

> PaaS (Platform as a Service) или CaaS (Containers as a Service)

CaaS тоже ведь включает в себя понятие PaaS. Т.е. если сама система может билдить и хранить имеджи — то это PaaS, если же нет — то IaaS.
А почему например не Nexus? Он же умеет быть реестром даже в OSS версии. При этом заодно и репозиторием maven, npm, и для pip тоже.
Никто не говорит, что Harbor — единственное решение, а выше в комментариях приведена ссылка на (лаконичный, но хороший в плане охвата) обзор с большим количеством альтернатив.

Конкретно Nexus — куда более разносторонний комбайн, что говорит об очевидных плюсах и минусах сразу. Много ли специфики конкретно Docker-образов там учтено? Например, поддерживаются ли те фичи безопасности, на которые сделан упор в последних релизах Harbor?
>Конкретно Nexus — куда более разносторонний комбайн

Так я тоже не говорю, что он единственный и идеальный. Ну то есть это не агитация была, а скорее попытка понять, есть ли что-то такое, чего в нем не хватает. Мне когда вообще встал вопрос со внутренним реестром (в интранете), первое что пришло в голову — это развернуть еще один 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 указывает конкретные минусы, заодно отвечая и на вопрос про фичи в безопасности.
Nexus не умеет сканировать на уязвимости и подписывать образы. И High Availability у него только в платной версии.
> Там же можно найти ссылки на инструкции по установке Harbor и его деплою в Kubernetes.
Что-то там какая-то урезанная инструкция: «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-сервером корпоративного класса".

Sign up to leave a comment.