docker images | grep golang

нет

в том и трабл

полностью пересобирал ось

недавно

хотя...

на сервере в реджестри лежит старый образ)

хм, может свой потереть, и оттуда загрузить

с локал реджестри

А зачем в контейнере с Go бинарём нужна ось?

ну если либы какие запускать, то вообще нужно

Либы запускать? это как?

хм, может свой потереть, и оттуда загрузить

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

Либы запускать? это как?

то, что неслинковано статически

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

у меня в реджестри лежит перетегированный

А зачем в контейнер линковать не статически?

то, что неслинковано статически

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

то что на го не хочется писать но есть на Си

А, понятно, и тем у кого проблемы с контейнрами - именно такие либы нужны?

мне нет

у меня в качеств базы образ golang используется

на чем он собран не помню

это из офф репы

мен нужнабыла компияцияв контейнере

ну и ресурсы на "сколько весит контейнер" были

какая разница что в базе если ресрс есть...

У нас пока не попадается необходимость для Go делать как-то иначе чем,  FROM scratch

ну я как бы туда же иду)

вот пытался вытащить компиляцию из сервиса

проявилсь текущая трабла

с утечкой памяти

сейчас решаю , изолирую

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

я так то тоже за scratch

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

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

и в случае с alpine оно кушать не просит

Кроме как в продакшин есть рутовый доступ в контейнер 🙂

А так кушать не просит

между 1.7 и 1.9.1 есть нарушение обратной совместимости

не в них,

в либах рядом

чет с контекстом мутили в 1.9.1

и под них переписаны либы

сейчас просто пробую стартовать на старом образе и снова эти ошибки в обратку,

чет с контекстом мутили в 1.9.1

мб в 1.9? 1.9.1 это вроде бы как фикс для smtp и еще чего-то там, уже подзабыл

недавно вышел

ну да

у меня просто 1.9.1

поэтому говорю точно))

так то 1.9 да

сейчас просто пробую стартовать на старом образе и снова эти ошибки в обратку,

что за ошибки то?

там последовательность аргументов и наличие отсутствие contex среди них. это банальная фигня которую убрали в последней версии либы

не серьезное

а что за либа?

да ща холивар будет)

страшно писать

😂 GopherJS???) ну можно в ЛС тогда

go-kit

вот уж не думал... ну ладно, буду знать

не думал о чем?)

не думал о чем?)

что go-kit может вызывать какие-то проблемы, хотя мб не в нём дело

контекст, если я не ошибаюсь в 1.7 как раз запилили (перенсли из /x/net)

это старый сервис, в качестве обвязки был взят go-kit, но вот сейчас он мешает только. Чтобы запустить на новой версии go пришлось код править и зависимости в вендор фолдер. Теперь для запуска на старой версии над откатывать все. Да есть Git но сейчас не могу запускать со старой ревизии сервис...

ну у меня 1.6 на машине была и думаю тоже самое в контейнере

1.6+

в одно время собирал

и качал образ

Так, если здесь пишут про go kit, хотел спросить для работы с dB идеологически надо делать отдельный микросервис или же можно вкрячить работу с ней прямо внутрь сервиса?

но контейнер 10 месяцев отроду

Так, если здесь пишут про go kit, хотел спросить для работы с dB идеологически надо делать отдельный микросервис или же можно вкрячить работу с ней прямо внутрь сервиса?

что подразумевается под работой

что подразумевается под работой

Например сервис должен сохранять определённые данные в бд.

ну в целом зависит от архитектуры... у вас db под каждый сервис?

или warehouse

Так, если здесь пишут про go kit, хотел спросить для работы с dB идеологически надо делать отдельный микросервис или же можно вкрячить работу с ней прямо внутрь сервиса?

насколько я понимаю идеологию go-kit, то микросервис должен предоставлять handler, внутри которого и "запечатана" вся магия, включая работу с бд. А потом этот handler уже можно вызывать в любом месте (по любому транспорту)

ну в целом зависит от архитектуры... у вас db под каждый сервис?

У нас один сервис :)

Пока что

Вот и думаем как лучше, сделать общее хранилище или под каждый сервис отдельно

насколько я понимаю идеологию go-kit, то микросервис должен предоставлять handler, внутри которого и "запечатана" вся магия, включая работу с бд. А потом этот handler уже можно вызывать в любом месте (по любому транспорту)

Искал в примерах, но не нашёл ничего с бд, что можно было бы подсмотреть.

Вот и думаем как лучше, сделать общее хранилище или под каждый сервис отдельно

по идее это не важно, сервис должен быть так оформлен, чтобы можно было легко свапнуть эти 2 опции

не