Ребзи, кто деплоил микросервисы на амазон?

make делает много простых вещей и делает их хорошо и долго. Зачем изобретать уже сделанное?

кросс-платформенности и независимости от make ради?

https://play.golang.org/p/JsKqPxYKlHB тут красивее)

Да уже увидел. ))

Ребзи, кто деплоил микросервисы на амазон?

да вся школота тут депроила :) А зачем тебе?

вообще, любая система сборки будет для go чужая и вредная

кросс-платформенности и независимости от make ради?

что-то есть типа make на go

потому как код должен быть готов к использованию сразу после git clone, который делает go get

Ребзи, кто деплоил микросервисы на амазон?

все?

да вся школота тут депроила :) А зачем тебе?

ну, я вроде уже к школоте не отношусь, но деплоил

сконвертить с pcre в golang

А Гугл молчит?

вообще, любая система сборки будет для go чужая и вредная

а я make юзаю. потому что мне надо иногда и собрать по-разному, и deb сделать, если что... Что же, руками это делать все?

А Гугл молчит?

да, чёт застрял

родина нам дала dockerfile

родина нам дала dockerfile

и х— бы с ним

но даже и докерфайл тоже так себе решение

а я не фанат. я люблю рыбалку :)

короче - да, руками, пока не завезут штатную систему сборки

make тот же у меня обычно отсутствует на машине

https://play.golang.org/p/JsKqPxYKlHB тут красивее)

Хотя так еще лучше. ?

ну, make все же хорошо умеет делать то, что он делает...

Ребзи, кто деплоил микросервисы на амазон?

У меня задача задеплоить приложение, у него есть воркеры к которым он обращается по хттп и получает результат, каждый воркер это докер контейнер. Я не врублюсь как сделать так чтобы приложение знало о том какие сервисы сейчас запущены и куда за ними обращаться, потом еще нужен load balancing, и т.д. и т.п.

make - лютое говно, и Makefile еще хуже

чем make не штатная система сборки чего не попадя в *NIX?

но, главное - кто его запустит после go get?

Make — огонь. А если у кого его нет — можно собирать в докере, где он есть.

https://magefile.org/ недавно пробегал

У меня задача задеплоить приложение, у него есть воркеры к которым он обращается по хттп и получает результат, каждый воркер это докер контейнер. Я не врублюсь как сделать так чтобы приложение знало о том какие сервисы сейчас запущены и куда за ними обращаться, потом еще нужен load balancing, и т.д. и т.п.

Откуда приложение будет знать ip воркера, и что это за воркер

Понятно что нужен какой-то service discovery, но хз как оно вяжется с автоматическими системами типа terraform или k8s, и как всю эту архитектуру описать в одном конфиге

Понятно что нужен какой-то service discovery, но хз как оно вяжется с автоматическими системами типа terraform или k8s, и как всю эту архитектуру описать в одном конфиге

В кубернетесе оно из коробки есть.

К8с сложным показался :(

и pcre биндинг есть

это как?

Make — огонь. А если у кого его нет — можно собирать в докере, где он есть.

еще раз - у нас некому этот make запускать

это как?

как обычно, через CGO. я бы рекомендовал воздерживаться до последней возможности

как обычно, через CGO. я бы рекомендовал воздерживаться до последней возможности

а что делать?

еще раз - у нас некому этот make запускать

Если некому, то может и проект собирать не надо, а просто go run делать.

go run обычно стартует в 10 раз дольше, чем сама программа работает в итоге :)

а то и в 100 раз

go run обычно стартует в 10 раз дольше, чем сама программа работает в итоге :)

мы тут вроде сервисы пишем, демонизированные. они вроде как работают до тех пор пока не остановят

ну... тогда можно раз в полгода и go run сказать - да :)

а я бы, подумав, все равно не стал. демонизированные - это через systemd? А оно надо этих лишних чилдренов? Проще уж собрать и пускать процесс работать.

а я бы, подумав, все равно не стал. демонизированные - это через systemd? А оно надо этих лишних чилдренов? Проще уж собрать и пускать процесс работать.

да хоть как. я про то что мы все-таки реже пишем утилиты имеющие цикл работы пару секунд

да хоть как. я про то что мы все-таки реже пишем утилиты имеющие цикл работы пару секунд

Везука вам тогда, вы - умные! :)

потому как код должен быть готов к использованию сразу после git clone, который делает go get

да но если кодогенерация например...?

да но если кодогенерация например...?

результат кодогенерации должен быть запушен в репу, конечно а для запуска кодогенерации (и всего остального подготовительного) есть go generate

и make!

:)

результат кодогенерации должен быть запушен в репу, конечно а для запуска кодогенерации (и всего остального подготовительного) есть go generate

я вот почему кодо-ген. не люблю так потому-что после изменении образа на каком нибудь DSL из которого генерится .go код - нужно ещё вручную кодо-ген запускать... практически можно изменить исходники (учитывая что генерированные файлы это не исходники), запушать их в репу но забыть прогенерить новый код... а это рассинхрон. если бы это можно было сделать автоматически перед каждой компиляцией то это бы избегать ручную генерацию. В идеале конечно же с кешированием.

я вот почему кодо-ген. не люблю так потому-что после изменении образа на каком нибудь DSL из которого генерится .go код - нужно ещё вручную кодо-ген запускать... практически можно изменить исходники (учитывая что генерированные файлы это не исходники), запушать их в репу но забыть прогенерить новый код... а это рассинхрон. если бы это можно было сделать автоматически перед каждой компиляцией то это бы избегать ручную генерацию. В идеале конечно же с кешированием.

по-хорошему это стоит делать на ci

по-хорошему - это надо пушить в репу

по-хорошему - это надо пушить в репу

сначала пушить, а потом ещё на ci повторять

во избежание "забыл"

хотя...

it depends впрочем, как всегда

сначала пушить, а потом ещё на ci повторять

чтоб CI создавал комиты?!

ну нахер...

нет, чтобы он имел свежий результат кодгена

кстати, ещё один вариант теста - git status после генерации на ci

Ну это такое себе

потому что ci - это всё таки немного из другой оперы

потому что можно без всякого ci разрабатывать, и тогда придётся самому следить за кодогенерацией

ci - это команда из RCS? ;)

нет, чтобы он имел свежий результат кодгена

проблема в том, что на CI то он может сгенерить себе код и скомпилить и показать зелёный знак... а пользователь может `go get`нуть пакет и забыть прокрутить кодоген повторяемости билда ради... а девелопер мог забыть прокрутить кодоген до пуша... так и получится что CI говорит всё окей а у тебя либо не билдится либо в самом худшем случае билдится с багами

потому что можно без всякого ci разрабатывать, и тогда придётся самому следить за кодогенерацией

не спорю, но я все же за автоматизацию)

проблема в том, что на CI то он может сгенерить себе код и скомпилить и показать зелёный знак... а пользователь может `go get`нуть пакет и забыть прокрутить кодоген повторяемости билда ради... а девелопер мог забыть прокрутить кодоген до пуша... так и получится что CI говорит всё окей а у тебя либо не билдится либо в самом худшем случае билдится с багами

потому и говорю про проверку отличий после кодгена на ci

"изменил DSL - прогенерь код!" забыл прогенерить код перед пушем? сломал софт...

проблема в том, что на CI то он может сгенерить себе код и скомпилить и показать зелёный знак... а пользователь может `go get`нуть пакет и забыть прокрутить кодоген повторяемости билда ради... а девелопер мог забыть прокрутить кодоген до пуша... так и получится что CI говорит всё окей а у тебя либо не билдится либо в самом худшем случае билдится с багами

чеклисты помогут?

если после генерации что - то изменилось (забыл сгенерить вручную) - билд упал

ERROR: S client not available

не спорю, но я все же за автоматизацию)

я вообще говорю про то, что упомянутая задача - это вообще то этап сборки (вообще, а не в ci)

я вообще говорю про то, что упомянутая задача - это вообще то этап сборки (вообще, а не в ci)

окей, ничто не мешает юзать make или что угодно ещё

коллеги, хватит, пожалуйста

это не дискуссионный вопрос

окей, ничто не мешает юзать make или что угодно ещё

да! Чем проще, тем лучше!

окей, ничто не мешает юзать make или что угодно ещё

ну это немного странно кстати

результат кодогенерации должен быть запушен в репу

точка

чеклисты помогут?

найн, найн, найн, найн, найн лучше всего генерить код ДО каждого билда, а ради ускорения использовать некий механизм кеширования, чтоб генератор сам распознавал что нынешний сгенеренный код уже соответствует DSL (чемсуммы или ещё как там...)

результат кодогенерации должен быть запушен в репу

я ни капли не спорю, а выступаю за максимум проверок

то есть ci тут уже не поможет точно, не будет же ci запускать кодогенерацию и пушить сгенерированный код

найн, найн, найн, найн, найн лучше всего генерить код ДО каждого билда, а ради ускорения использовать некий механизм кеширования, чтоб генератор сам распознавал что нынешний сгенеренный код уже соответствует DSL (чемсуммы или ещё как там...)

why

результат кодогенерации должен быть запушен в репу

"должен" не учитывает worst case люди много чего должны но на людей нельзя 100% полагаться, даже на самого себя, люди не алгоритмы, люди имеют свойство ошибаться

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

why

уже описал выше, главная причина: нет гарантированной синхронизации DSL и генерированного запушенного кода

чтобы не искать виноватого по всей цепочке

Вообще эта штука может выполняться автоматически при компиляции (с кешированием конечно же). Но не выполняется. Вот суть претензий. То есть фактически на программиста возложена та задача, которая явно не должна быть на него возложена.

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

но такое

нет гарантированной синхронизации - это не проблема

я говорил, и повторю

Вообще эта штука может выполняться автоматически при компиляции (с кешированием конечно же). Но не выполняется. Вот суть претензий. То есть фактически на программиста возложена та задача, которая явно не должна быть на него возложена.

кодогенерация - это написание кода. эта задача возложена на программиста.

Вообще эта штука может выполняться автоматически при компиляции (с кешированием конечно же). Но не выполняется. Вот суть претензий. То есть фактически на программиста возложена та задача, которая явно не должна быть на него возложена.

то слово на Г которое нельзя здесь произносить - например, и есть кешированная кодогенерация до каждой компиляции

кодогенерация - это написание кода. эта задача возложена на программиста.

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

кодогенерация кодогенерации рознь

самое плохое в генериках то, что их притягивают за уши туда, где им совсем не место

еще раз - это не дискуссионный вопрос

у себя делайте, как хотите

кодогенерация кодогенерации рознь

и дженерики дженикам - тоже рознь

кодогенерация - это написание кода. эта задача возложена на программиста.

Кодогенерация - это не написание кода. А его генерация. Ваш кэп. И ответственность за запуск этой самой генерации просто опасно возлагать на такое часто ошибающееся существо как человек.

если отдаете наружу - помните, что все, что пользователь сделает, это go get

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

можно, репродуцируемых компиляций ради