откуда качать зависимости — это часть билда, не metadata. Какие плагины в каком порядке запускать — это часть билда, не metadata.
Metadata это то, что выдает в pom, например gradle – id, url, cms, authors, description, зависимости. Всё.
Как строить (не важно, в коде это описано, или в XML) – это часть скрипта.
И в Gradle с метаднными, конечно, намного лучше. Ты просто генеришь их в том формате, в котором захочешь — pom.xml, ivy.xml, и публицируешь сместе с артифактами. Полное разделение от скрипта, как и должно быть.
Меня попросили сравнить с Artifactory, так что я прям тут и напишу.
управление доступом на основе ролей
Есть.
пользовательский веб-интерфейс для просмотра репозиториев, поиска по ним, управления проектами;
Есть.
аудит всех операций;
Есть.
REST API для управления.
Есть.
Сканирование уязвимостей.
Есть, причем не только os level, но и вся аппликативная часть, вне зависимости от того, на чем написана.
Подпись образов.
Из коробки нет, но нет никаких проблем вызывать notary из beforeDownload user plugin–a, если надо.
Теперь, о главном. Никто, и вы в том числе не используете в организации только докер. В контейнеры вы заворачиваете код, при написании которого используется дофига всего, всякие джавы, питоны, сишарпы, гошечки, и даже, возможно, джаваскрипт. Весь этот зоопарк тоже требует управиления зависимостями, и если вы смотрите на Харбор, то даже энтерпрайзного уровня. Вы, конечно, можете, притащить для каждого элемента стэка свою балалайку, и даже, допустим, она будет отлично работать, но как вы сможете коррелировать между зависимостями и артифактами аппликативного уровня, образами Докера и чартами Хелма? Как вы сможете сказать "мне в продакшн нужен последний чарт, в образе которого нет никаких уязвимостей, и джавовый код которого прошёл все проверки в своем джавовом пайплайне"?
Ну, и пожалуй спрошу у вас вот еще что, неужели вам бы не хотелось иметь более строгие границы между этапами пайплайна для контейнеров, чем просто директории внутри regisry? Например, отдельные registry для dev и prod? Если да, то может не стоит ставить по registry для каждой среды, а вместо этого пользоваться тулом, в котором можно сделать сколько хочешь таких registry, опять же с promotion и связью между ними?
Ну и напоследок, я не знаю, как в Харборе с такими enterprise фичами как high availibilty, replication и подключаемым любым storage? Потому что это обязательные штуки для того, чтобы называться "registry-сервером корпоративного класса".
Во-первых, я любя :)
Во-вторых, человеки ленивые. Говоришь кошмарно-неправильный термин, и сразу сэкономил пару предложений объяснений, кого ты имел ввиду.
В целом, у нас с тобой полное согласие по вопросу терминологии, конечно.
Ну зачем же так? Простейший Artifactory решает же.
Our job here is done.
SUUUQAH!!! Чур меня, чур!
Ну кто же ожидает хэпиенд у трагедии?
Они вообще не собирали никаких бинарников. Node.js жи, написали код, прогнали тесты на CI, и вперёд, исходники в облако на прод.
Если бы вы знали, сколько маленьких стартапов так и делают. Всегда же можно откатиться на предыдущий комммит!
Не было никакого Docker registry. Artifactory появился только на следующем этапе же.
откуда качать зависимости — это часть билда, не metadata. Какие плагины в каком порядке запускать — это часть билда, не metadata.
Metadata это то, что выдает в pom, например gradle – id, url, cms, authors, description, зависимости. Всё.
Как строить (не важно, в коде это описано, или в XML) – это часть скрипта.
И в Gradle с метаднными, конечно, намного лучше. Ты просто генеришь их в том формате, в котором захочешь — pom.xml, ivy.xml, и публицируешь сместе с артифактами. Полное разделение от скрипта, как и должно быть.
НАКОНЕЦ-ТО!!! Наконец-то до них дошло, что build script и artifact metadata это разные артифакты и смешивать их нельзя!!!
Фух. Самое время закурить сигарету "после". Я это слышал раза 3, но всё равно, насладился как в первый раз.
В опросе нет опции "Я спикер, если я не пойду, мне 23derevo выпишет звиздюлей".
Меня попросили сравнить с Artifactory, так что я прям тут и напишу.
Есть.
Есть.
Есть.
Есть.
Есть, причем не только os level, но и вся аппликативная часть, вне зависимости от того, на чем написана.
Из коробки нет, но нет никаких проблем вызывать notary из beforeDownload user plugin–a, если надо.
Теперь, о главном. Никто, и вы в том числе не используете в организации только докер. В контейнеры вы заворачиваете код, при написании которого используется дофига всего, всякие джавы, питоны, сишарпы, гошечки, и даже, возможно, джаваскрипт. Весь этот зоопарк тоже требует управиления зависимостями, и если вы смотрите на Харбор, то даже энтерпрайзного уровня. Вы, конечно, можете, притащить для каждого элемента стэка свою балалайку, и даже, допустим, она будет отлично работать, но как вы сможете коррелировать между зависимостями и артифактами аппликативного уровня, образами Докера и чартами Хелма? Как вы сможете сказать "мне в продакшн нужен последний чарт, в образе которого нет никаких уязвимостей, и джавовый код которого прошёл все проверки в своем джавовом пайплайне"?
Ну, и пожалуй спрошу у вас вот еще что, неужели вам бы не хотелось иметь более строгие границы между этапами пайплайна для контейнеров, чем просто директории внутри regisry? Например, отдельные registry для dev и prod? Если да, то может не стоит ставить по registry для каждой среды, а вместо этого пользоваться тулом, в котором можно сделать сколько хочешь таких registry, опять же с promotion и связью между ними?
Ну и напоследок, я не знаю, как в Харборе с такими enterprise фичами как high availibilty, replication и подключаемым любым storage? Потому что это обязательные штуки для того, чтобы называться "registry-сервером корпоративного класса".
Смотря кого, ты имеешь ввиду. Часто DevOps-ом называют SRE, часто tooling teams.
Во-первых, я любя :)
Во-вторых, человеки ленивые. Говоришь кошмарно-неправильный термин, и сразу сэкономил пару предложений объяснений, кого ты имел ввиду.
В целом, у нас с тобой полное согласие по вопросу терминологии, конечно.
Сейчас придет bsideup и будет порицать нас за "DevOps инженеров". Вычитывали-вычитавали, да не вычитали.
Обнимашки!
Гуглить event gamification.
Неистово орал всю дорогу.
Это не "деньги смешные", это "у вас не огромный пул серверов".
Его уже переубедили, и он уже извинился. Вот за EO он еще не извинился, за это можно ругать.
Я три дня гналась за вами, чтобы сказать, как вы мне безразличны ©
Я вижу, пролистать ленту дальше не удалось?