ага и жизнь гавно, если так судить.

вот именно

Кроме пчел

да тут чат почитаешь — вообще все хуита

индустрия в говне, etc

да потому что так и есть

аналог хельма который "не гавно" подскажи пожалуйста.

И аналог терраформ тоже

аналог хельма который "не гавно" подскажи пожалуйста.

возможно https://github.com/flant/dapp

возможно https://github.com/flant/dapp

Дапп деплоит через HELM

аналог хельма который "не гавно" подскажи пожалуйста.

я б не сказал что хелм говно. непонятно просто на кой хер ему тиллер и полный игнор изменений, сделанных мимо него, которые ты руками сделал. ну и чарты все еще имеют множество проблем, даже "stable"

я б не сказал что хелм говно. непонятно просто на кой хер ему тиллер и полный игнор изменений, сделанных мимо него, которые ты руками сделал. ну и чарты все еще имеют множество проблем, даже "stable"

в 4-й версии от тиллера же отказываются

возможно https://github.com/flant/dapp

хахахаха

или в 3-й, хз, не помню

в 4-й версии от тиллера же отказываются

да да, ждем, lua и тиллеропиздец

Ну есть у него куча проблем, но так в принципе это лучше чем руками раскатывать и дропать ресурсы самописными костылями

хахахаха

что хахаха? тестил? расскажи - а лучше статью на хабр запили

Запускайте поды конкретного приложения в отдельно неймспейсах илли генерируйте роль с конкретными именами подов, https://metacontroller.app/ вам в помощь

Может есть како йто рабочий пример? А то что-то чую там Ж какая то

миллионы хельмофанов не могут ошибаться, да

что хахаха? тестил? расскажи - а лучше статью на хабр запили

работаю с даппом с версии 0.0.1 - отличный сборщик. Деплоем не пользовался пока, но судя что коллеги рассказывают, то вполне хорошо деплоит. Использует для деплоя helm. Всё остальное у флантов на хабре в статьях описано и разжёвано.

что хахаха? тестил? расскажи - а лучше статью на хабр запили

никакого профита не увидел, если честно. ну они аутсорсеры, им нужно шуметь как то, опенсорсить, подсаживать там

неплохая идея оберунть в свои костыли у клиента, это ж золотая жила

никакого профита не увидел, если честно. ну они аутсорсеры, им нужно шуметь как то, опенсорсить, подсаживать там

Подсаживать на свои костыли это не этично

но бизнес то требует!

кого волнует этика когда речь заходит про бабки

кого волнует этика когда речь заходит про бабки

А потом саусбридж ноет, что не всем оказывается нужен куб

Подсаживать на свои костыли это не этично

Скажи это редхату и ещё куче контор

Это бизнес

неплохая идея оберунть в свои костыли у клиента, это ж золотая жила

Профит в стандартизации сборок, уменьшении количества файлов пописаний сбррок до 1 ну и + выкат этим же инструментом. Сборщик там зачётный. То что кое как в Docker Build появилось недавно, там было давно реализовано. У меня тут под боком пример как сделана сборка на Docker build и на dapp Dapp приятней и понятней. А Docker build обёрнут в отдельныйе скрипты, чтобы собрать несколько образов. Т.

Скажи это редхату и ещё куче контор

хотелось бы узнать полный список контор у которых костыли, а не "апстрим солюшен" типа хельма

Скажи это редхату и ещё куче контор

Это не делает редхат лучше

Профит в стандартизации сборок, уменьшении количества файлов пописаний сбррок до 1 ну и + выкат этим же инструментом. Сборщик там зачётный. То что кое как в Docker Build появилось недавно, там было давно реализовано. У меня тут под боком пример как сделана сборка на Docker build и на dapp Dapp приятней и понятней. А Docker build обёрнут в отдельныйе скрипты, чтобы собрать несколько образов. Т.

показывайте. мож откроете глаза наконец

хотелось бы узнать полный список контор у которых костыли, а не "апстрим солюшен" типа хельма

99% рынка наверное

показывайте. мож откроете глаза наконец

Что показывать? На хабре статьи, соберите несколько приложений, все вопросы в канал даппа - там парни ответят и помогут. Для меня простота сборок очевидна. У Dapp есть ещё киллер фича - когда тестируешь сборку, то можешь попасть в момент ошибки команды или до неё. И там исследовать причину и поправить сборку. Пробуйте, все мои слова это просто мои впечатления. Сами разберётесь там сравнить сможете.

Что показывать? На хабре статьи, соберите несколько приложений, все вопросы в канал даппа - там парни ответят и помогут. Для меня простота сборок очевидна. У Dapp есть ещё киллер фича - когда тестируешь сборку, то можешь попасть в момент ошибки команды или до неё. И там исследовать причину и поправить сборку. Пробуйте, все мои слова это просто мои впечатления. Сами разберётесь там сравнить сможете.

прям как в circleci

я не хочу пробовать просто так

я не хочу пробовать просто так

я не настаиваю, вам мучиться с костылями.

я почитал описание, примеры, но не увидел профита, зато вижу проблему - чей то велосипед поселится в ci

я почитал описание, примеры, но не увидел профита, зато вижу проблему - чей то велосипед поселится в ci

Велосипед давно уже не велосипед. Он больше 2-х лет в разработке и абсолютно большую часть проблем, которые реально мешали работать, уже исправили. А вот писать собственные костыли для сборок это именно тот самый велосипед.

Что показывать? На хабре статьи, соберите несколько приложений, все вопросы в канал даппа - там парни ответят и помогут. Для меня простота сборок очевидна. У Dapp есть ещё киллер фича - когда тестируешь сборку, то можешь попасть в момент ошибки команды или до неё. И там исследовать причину и поправить сборку. Пробуйте, все мои слова это просто мои впечатления. Сами разберётесь там сравнить сможете.

Вы работаете с flant?)

Вы работаете с flant?)

Я там работал. Уже год как нет. Но с даппом знаком и есть с чем сравнить. Видел кучу велосипедов. До сих пор убеждён, что замены даппу нет.

судя по https://flant.github.io/dapp/how_to/build_run_and_push.html оно запускает ансибл внутре

почти как ansible-container, только на руби

мощно

судя по https://flant.github.io/dapp/how_to/build_run_and_push.html оно запускает ансибл внутре

можно ансибл, можно shell, можно chef

почти как ansible-container, только на руби

усиленно на Go переписывают насколько я в курсе

Велосипед давно уже не велосипед. Он больше 2-х лет в разработке и абсолютно большую часть проблем, которые реально мешали работать, уже исправили. А вот писать собственные костыли для сборок это именно тот самый велосипед.

ну все что пишется - dockerfile + helm chart values. зачем еще одна прослойка тут, что она решает, сокращает число команд? типовой docker build\push & helm upgrade?

усиленно на Go переписывают насколько я в курсе

ваще не показатель качества =)

усиленно на Go переписывают насколько я в курсе

почти как buildah, неплохо

может и докерсокет скоро не понадобится

и можно запускать более-менее безопасно, как Source2Image

ну все что пишется - dockerfile + helm chart values. зачем еще одна прослойка тут, что она решает, сокращает число команд? типовой docker build\push & helm upgrade?

Давай собери мне 3 контейнера так чтобы это не вызвало зубной скрежет от мега скриптов и не пришлось ждать во 2-ю и последующие сборки по 10 минут.

вы про multistage?

и всё это в одном докерфайле

но ведь образы разные, docker такое не поддерживает жеж

А дапп поддерживает

звучит как что-то странное

ну собираешь один, потом из него второй, вообще сколько угодно, число docker build по числу образов

Сколько докерфайлов будет? Как артефакты будешь собирать? Как передавать их между образами?

сек

Сколько докерфайлов будет? Как артефакты будешь собирать? Как передавать их между образами?

это называется multistage ARG PARENTIMAGE FROM $PARENTIMAGE as base FROM some:anothershit COPY --from=base /path/to/shared/shit /shit

почти как buildah, неплохо

Щупал его?

Сколько докерфайлов будет? Как артефакты будешь собирать? Как передавать их между образами?

че то я не понял. Вы вот про это? FROM python:2.7-alpine3.7 as price_server_base ENV PYZMQ_VERSION="==16.0.2" ENV ZEROMQ_VERSION="4.2.2" RUN apk add --no-cache python python-dev build-base git libtool pkgconfig autoconf automake wget ca-certificates && \ ...... FROM price_server_base as prod ## Possible values: true , false ARG DEVELOPMENT_MODE=false ARG REPO_ENDPOINT= ARG SET_PBR_VERSION= ..... FROM price_server_base as test ## Possible values: true , false ARG DEVELOPMENT_MODE=false ARG REPO_ENDPOINT= ARG SET_PBR_VERSION= RUN [ "$DEVELOPMENT_MODE" != "true" ] || apk add --no-cache libxml2-dev libxslt-dev ```

?

Щупал его?

удолил докер с системы полгода назад, buildah + podman решают

че то я не понял. Вы вот про это? FROM python:2.7-alpine3.7 as price_server_base ENV PYZMQ_VERSION="==16.0.2" ENV ZEROMQ_VERSION="4.2.2" RUN apk add --no-cache python python-dev build-base git libtool pkgconfig autoconf automake wget ca-certificates && \ ...... FROM price_server_base as prod ## Possible values: true , false ARG DEVELOPMENT_MODE=false ARG REPO_ENDPOINT= ARG SET_PBR_VERSION= ..... FROM price_server_base as test ## Possible values: true , false ARG DEVELOPMENT_MODE=false ARG REPO_ENDPOINT= ARG SET_PBR_VERSION= RUN [ "$DEVELOPMENT_MODE" != "true" ] || apk add --no-cache libxml2-dev libxslt-dev ```

+

Сколько докерфайлов будет? Как артефакты будешь собирать? Как передавать их между образами?

докерфайлов будет по числу образов. артефакты перадаются через COPY файлов другого образа

че то я не понял. Вы вот про это? FROM python:2.7-alpine3.7 as price_server_base ENV PYZMQ_VERSION="==16.0.2" ENV ZEROMQ_VERSION="4.2.2" RUN apk add --no-cache python python-dev build-base git libtool pkgconfig autoconf automake wget ca-certificates && \ ...... FROM price_server_base as prod ## Possible values: true , false ARG DEVELOPMENT_MODE=false ARG REPO_ENDPOINT= ARG SET_PBR_VERSION= ..... FROM price_server_base as test ## Possible values: true , false ARG DEVELOPMENT_MODE=false ARG REPO_ENDPOINT= ARG SET_PBR_VERSION= RUN [ "$DEVELOPMENT_MODE" != "true" ] || apk add --no-cache libxml2-dev libxslt-dev ```

Наверное. Только мультистейдж появился в дапп два года назад, а в докере недавно.

ну ок. Но в таком случае, я надеюсь что они счас используют docker multistage под копотом

Наверное. Только мультистейдж появился в дапп два года назад, а в докере недавно.

Multi-stage builds are a new feature requiring Docker 17.05 or higher on the daemon and client

ну ок. Но в таком случае, я надеюсь что они счас используют docker multistage под копотом

Я знаю, что по скорости сборки dapp и dockerbuild практически не отличаются. Что они используют я хз. Мне нравится сама структура dappfile - не нужно ничего придумывать, всё уже придумано и отшлифовано.

ну ок. Но в таком случае, я надеюсь что они счас используют docker multistage под копотом

можете в #dapp_ru поинтересоваться )

Я знаю, что по скорости сборки dapp и dockerbuild практически не отличаются. Что они используют я хз. Мне нравится сама структура dappfile - не нужно ничего придумывать, всё уже придумано и отшлифовано.

Ага, год прошёл с 17.05 а про мультистейдж люди толком и не знают.

Ага, год прошёл с 17.05 а про мультистейдж люди толком и не знают.

их проблемы, чо

их проблемы, чо

Не спорю. Но нужно продвигать. Удобная штука.

??

Я знаю, что по скорости сборки dapp и dockerbuild практически не отличаются. Что они используют я хз. Мне нравится сама структура dappfile - не нужно ничего придумывать, всё уже придумано и отшлифовано.

да отличаются конкретно в некоторых кейсах, не в пользу dapp. Есть бенчмарк даже мой (может что поменялось что за месяц).

да отличаются конкретно в некоторых кейсах, не в пользу dapp. Есть бенчмарк даже мой (может что поменялось что за месяц).

насколько я помнб, там различия на секунды. В любом случае удобство dappfile для меня это не отменяет.

насколько я помнб, там различия на секунды. В любом случае удобство dappfile для меня это не отменяет.

у меня в том самом кейсе отличия в 3 раза. 6 минут vs 2 минуты сейчас без dapp

у меня в том самом кейсе отличия в 3 раза. 6 минут vs 2 минуты сейчас без dapp

что-то пересобирается по 10 раз?

что-то пересобирается по 10 раз?

js фронт и go

js фронт и go

Обычно это всё в артифакты выносится и артифакт пересобирается по триггеру изменения файлов.

Обычно это всё в артифакты выносится и артифакт пересобирается по триггеру изменения файлов.

npm install из кеша почти всегда, а вот npm build нужно вызывать каждый раз и тут нет кэша. Одна правка, полная пересборка.

npm install из кеша почти всегда, а вот npm build нужно вызывать каждый раз и тут нет кэша. Одна правка, полная пересборка.

Ну тут вряд ли зависит от типа сборщика. Значит что-то недонастроено. Если и там и там одинаковые команды запускаются.

npm install из кеша почти всегда, а вот npm build нужно вызывать каждый раз и тут нет кэша. Одна правка, полная пересборка.

nmp build - что собирается? Что правилось при этом?

nmp build - что собирается? Что правилось при этом?

весь проект целиком. Фронт по другому особо не собирают.

весь проект целиком. Фронт по другому особо не собирают.

Пока не скажу, давно сервиса на ноде не было. Возможно скоро появится, посмотрю.

Пока не скажу, давно сервиса на ноде не было. Возможно скоро появится, посмотрю.

у меня есть бенчмарк, если вдруг кому нужно. Кейс: мультирепа с фронтами, собрать все после изменения 1 файла в 1 проекте (обычный комит каждодневный).

у меня есть бенчмарк, если вдруг кому нужно. Кейс: мультирепа с фронтами, собрать все после изменения 1 файла в 1 проекте (обычный комит каждодневный).

можно попадробней мультирепа - это git submodules?

можно попадробней мультирепа - это git submodules?

5 проектов в одной репе. yarn workspaces

можно дурацкий вопрос? Разворачиваю тестовый kubernetes на нескольких виртуалках, раньше с ним дела не имел. В существующих hello-world'ах подобный вариант не описан. Как правильнее всего настроить одну виртуалку под мастер и остальные в качестве слейвов? И чтобы добавлять-удалять их можно было тоже по желанию. Т.е. конфигурация, в общем-то максимально приближенная к боевой (по факту уже боевая - только слейвы в облаке добавляй, а на месте удаляй). в мануалах рекомендуется начать с minikube или kubernetes-dind, но это не очень удобно (да и незачем, наверное).

вообще есть смысл на стадии изучения сразу пытаться построить если не продакшен, то максимально близкую к нему систему?

более-менее с юниксами знаком, с сопутствующей инфраструктурой тоже. Просто вот мимо меня весь этот девопс прошёл, навёрстываю упущенное :)

вообще есть смысл на стадии изучения сразу пытаться построить если не продакшен, то максимально близкую к нему систему?

лучше начать с написания deployment/service/ingress под какой-то свой проект. Потом уже думать про уровень ниже.

это в общем-то уже есть

скорее всего на этом всём и буду тестировать

можно дурацкий вопрос? Разворачиваю тестовый kubernetes на нескольких виртуалках, раньше с ним дела не имел. В существующих hello-world'ах подобный вариант не описан. Как правильнее всего настроить одну виртуалку под мастер и остальные в качестве слейвов? И чтобы добавлять-удалять их можно было тоже по желанию. Т.е. конфигурация, в общем-то максимально приближенная к боевой (по факту уже боевая - только слейвы в облаке добавляй, а на месте удаляй). в мануалах рекомендуется начать с minikube или kubernetes-dind, но это не очень удобно (да и незачем, наверное).

https://docs.platform9.com/support/disallowing-workloads-on-kubernetes-master-nodes/ например