Здравствуйте, Pauel, Вы писали:

P>Я говорю совершенно другое — поскольку депенденсы могут отсутствовать, собранный релиз в докер имедже гораздо надежнее.
Чем это отличается от хранения в докере всего, что надо чтоб одной кнопкой всё собрать?

P>Ты издержки в терабайтах меряешь Нужно мерить и сравнивать суммарную стоимость владения.
Издержки на хранение данных меряются как ни странно в объёмах данных, которые надо хранить. От этого всё дальше танцуется.

P>Во первых, терабата мало.
Возьми петабайт

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

P>И нам нужно городить вокруг этого инфраструктуру, которая будет заботливо сохранять все используемые версии всех используемых депенденсов.
Называется git

P>Элементарно — билды на фичи-баги-секюрити требуют зависимостей.
Ну т.е. это не версионированный билд, это TOT.

P>Потому, что ты работаешь в узенькой нише.
Эта узенькая ниша как раз занимается хранением всякого вашего говна.

P> Веб-приложений разного масштаба в тысячи раз бОльше.
P> Полная сборка проекта из исходников с деплойментом занимает часы, из которых бОльшую времени работает компилятор и идут тесты.
Ты точно щас про веб?

P>Щас ты наверное скажешь "а я веб-приложениями не занимаюсь" ?
И слава богам, ибо помойка там страшная.

P>Тесты можно и отключить, но тогда проблемы с интеграцией будешь ловить в отладке.
А тебе точно надо гонять тесты для того, что уже было зафиксировано как срез годного билда?

P>То есть, в случае с хранением исходников:
P>0. подкинуть нужные переменные окружения — где гарантия что они будут теми же, что и в прошлый раз? Есть ответ?
P>1. откопать тот самый пайплайн на дженкинсе или еще где, который умеет работать с билдами той самой версии и пускануть его
P>2. скачать нужную версию исходников по тегу
P>3. скачать все зависимости, коих обычно больше чем исходников, при чем намного
Вы это что, всё врукопашную до сих пор делаете?

P>И тут мы выясняем, что здесь ажно 8-10 разных шагов, каждый из которых время от времени отваливается по разными причинам — например
P> закончилось место на агенте, надо чпокать опсов
P> поменялся энвайрмент агента, надо чпокать опсов
P> протухли креденшиалы, надо чпокать опсов
P> отвалились пермишны, снова надо чпокать опсов
P> поменялась конфигурация сети, снова надо чпокать опсов или админов
P> итд итд, и каждый раз чпокаем опсов, админов, итд по списку
P>И самое забавное — пункт 0 — где гарантия, что ты подкинешь те самые переменные, что были использованы в первый раз?
Какой бардак!
Это впрочем многое объясняет.

Здравствуйте, Sinclair, Вы писали:

P>>>С ними все гораздо проще.
CC>>Да то же самое по сути, только вид в профиль.
S>Нет. Докер математически эквивалентен идее "вот я собрал версию 3.1.1333.666 своего приложения — и теперь храню рядом с ним бинари всех зависимостей для этой версии".
Это всё верно, вот только не спасает жеж нифига. Годится для бинарного поиска в каком релизе сломали и в общем то всё.
А когда вылазит какое нить говно то надо всё равно подымать тот самый снапшот кода, чтоб детально разобраться (бывает ещё и инструментировать приходится) и потом патч выкатывать.

Здравствуйте, CreatorCray, Вы писали:
CC>Это всё верно, вот только не спасает жеж нифига. Годится для бинарного поиска в каком релизе сломали и в общем то всё.
Ну, так в основном этого и требуется. Воспроизведение — половина починки.
CC>А когда вылазит какое нить говно то надо всё равно подымать тот самый снапшот кода, чтоб детально разобраться (бывает ещё и инструментировать приходится) и потом патч выкатывать.
Ну так свой-то код, естественно, вы держите со всей историей. Поэтому взяли нужную клиенту базовую версию, воспроизвели проблему, собрали патченую версию, докатили её в новый докер-образ на основе того, на котором воспроизвели, и отдали. Всё.

Здравствуйте, CreatorCray, Вы писали:

P>>Я говорю совершенно другое — поскольку депенденсы могут отсутствовать, собранный релиз в докер имедже гораздо надежнее.
CC>Чем это отличается от хранения в докере всего, что надо чтоб одной кнопкой всё собрать?

Я тебе привел цельный список. В твоей схеме надо
1 хранить чуть не все возможные версии всех депенденсов
2 тратить чудовищное время на билд в силу естественных причин
3 приседать с переменными билда-деплоя каждый раз когда понадобится

P>>Ты издержки в терабайтах меряешь Нужно мерить и сравнивать суммарную стоимость владения.
CC>Издержки на хранение данных меряются как ни странно в объёмах данных, которые надо хранить. От этого всё дальше танцуется.

И всё равно надо считать суммарную стоимость владения. Например, каждый доп-сервис это плюс некоторый процент на ЗП опсов и админов.

Каждый билд — это время. Например, на предыдущем проекте включить старую версию на стг это дело секунд.

P>>Во первых, терабата мало.
CC>Возьми петабайт

Нужно считать не байты, а суммарную стоимость владения в деньгах.

P>> Во вторых, сюда нужно добавить зп опсов которые будут заниматься всеми подобными вопросами
CC>Они уже должны быть полюбас.

А капасити опсов по твоему неограничена?

P>>И нам нужно городить вокруг этого инфраструктуру, которая будет заботливо сохранять все используемые версии всех используемых депенденсов.
CC>Называется git

Еще один велосипед предлагаешь? Репозитории под артефакты уже давно изобрели.
Гит как хранилище артефактов работает плохо, его крайне трудно использовать, если у нас проекты разных сортов и депенденсы у всех разные, а размеры чудовищные.

P>>Элементарно — билды на фичи-баги-секюрити требуют зависимостей.
CC>Ну т.е. это не версионированный билд, это TOT.

Бывает по всяком, смотря какие задачи.

P>>Потому, что ты работаешь в узенькой нише.
CC>Эта узенькая ниша как раз занимается хранением всякого вашего говна.

Тем не менее, это узенькая ниша. Скажем, если собирать драйвер, десктоп приложение, или плагин к такому приложения, то тут билды падают раз в год, в основном когда заканчивается место на диске или протухают сертификаты.
Но если на том же агенте запускать стабильный билд стабильной версии веб-приложения и все будет иначе — и по времени, и по частоте сбоев.

P>> Веб-приложений разного масштаба в тысячи раз бОльше.
P>> Полная сборка проекта из исходников с деплойментом занимает часы, из которых бОльшую времени работает компилятор и идут тесты.
CC>Ты точно щас про веб?

Именно. Твое удивление говорит о том, что ты про веб-приложения только читал

P>>Щас ты наверное скажешь "а я веб-приложениями не занимаюсь" ?
CC>И слава богам, ибо помойка там страшная.

Не работал, но мнение имеешь

P>>Тесты можно и отключить, но тогда проблемы с интеграцией будешь ловить в отладке.
CC>А тебе точно надо гонять тесты для того, что уже было зафиксировано как срез годного билда?

Точно. Часть зависимостей в рантайме, соответсвенно я заранее и не знаю, годные они или нет. Небольшая мелочь может повалить всю цивилизацию, например — те самые переменные билда.

P>>То есть, в случае с хранением исходников:
P>>0. подкинуть нужные переменные окружения — где гарантия что они будут теми же, что и в прошлый раз? Есть ответ?

Забавно, что ответа от тебя не поступило. Гы!

P>>1. откопать тот самый пайплайн на дженкинсе или еще где, который умеет работать с билдами той самой версии и пускануть его
P>>2. скачать нужную версию исходников по тегу
P>>3. скачать все зависимости, коих обычно больше чем исходников, при чем намного
CC>Вы это что, всё врукопашную до сих пор делаете?

Где сказано, что это врукопашную? Все эти скачивания требуют времени и в силу того, что любая сеть принципиально ненадежка, именно на этом скачивании билд чаще всего и валится.

CC>Какой бардак!

Это обычное веб-приложение. Забавно, что ты не смог ничего выдать про переменные билда. Каким чудом собираешься обеспечить идентичность переменных?
А то потерял кое что, и твое приложение работать чуточку иначе. Что делать?

Здравствуйте, Вумудщзук, Вы писали:

В>всё прочее, что от мелкомягких, что от самого яблока — хождение кругами в суровой и беспощадной гонке гигагерц и мегапикселей

ну нет, примерно на стыке 19-20 года произошел резкий скачок в качестве фоток телефонных, по сути приблизивший для обывателя качество до уровня зеркалок.
Примерно в то время (и только изза этого факта) я и купил для фоток себе один телефон, а для видео жене айфон, и в наши экспедиции мы перестали брать наконецто эти все здоровые бандуры зеркалки, с объяективами, штативами, и прочим трехомудьем.

Здравствуйте, Sheridan, Вы писали:

S>В остальных случаях использование докеров — звоночек в некотором тяпляпстве разработчиков. Значит что они не смогли разрулить зависимости и просто запихнули нужное окружение в контейнер.

Так а если я не хочу разруливать зависимости? Просто хочу стабильное окружение, одинаковое при разработке и в проде.

Здравствуйте, vsb, Вы писали:

vsb>Типичный скрипт сборки может ссылаться и на версии 3.2.0, которые по сути теги, такие же как :latest, которые так же можно изменить в будущем. Чтобы нельзя было изменить — нужно прописывать хеши, а не ревизии. Но кто это делает (кроме меня, лол).

Тогда и хеши не панацея, подменить может и сложно, а вот удалить соответствующий образ, обломав все — запросто.

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, alpha21264, Вы писали:

A>>>>Ничто не мешало Биллигейцу запилить свою реализацию Иксов на своём железе.
CC>>>Таки мешало. Потому как SW бизнес и HW бизнес это ОЧЕНЬ разные вещи.
A>>При чём здесь это?
CC>биллигейц (tm) не делал железо, он делал софт, который должен был работать на том хламе, что есть у юзера.

Ну и? В чём проблема? Вот пусть и работали бы "на том хламе, который есть у Юзера".
Тем более, что сторонние фирмы таки сделали X-клиент, который работал именно на том самом хламе, да ещё и поверх Виндов.

A>> Ты понимаешь, что такое X-Window? Это программа такая.
CC>Это протокол для remote graphical user interface
CC>Нахрена кому в локальной винде были навороты из зоопарка mainframes?

Здря ты выделяешь слово "remote". Ну да, remote и что?
Кто мешал Билли-Гейцу сделать свою реализацию Xlib хоть с ремоте, хоть без?
Это же просто протокол, по которому программа может иметь графику.
А нужно это для того, чтобы можно было переносить программы туда-сюда.
Не говорите, что это не нужно. Это нужно. Для этого даже Qt написали.

Здравствуйте, alpha21264, Вы писали:

A>Тем более, что сторонние фирмы таки сделали X-клиент, который работал именно на том самом хламе, да ещё и поверх Виндов.
Да на здоровье! МС то нафига было завязываться на иксы и все их болячки?

A>Зря ты выделяешь слово "remote". Ну да, remote и что?
А то, что это сильно ограничивает в том, как можно это всё ускорить, когда remote нафиг не надо.

A>Кто мешал Билли-Гейцу сделать свою реализацию Xlib хоть с ремоте, хоть без?
А зачем? Вот серьёзно, зачем вообще им всрались иксы если можно написать с нуля без всего этого груза легаси?

A>А нужно это для того, чтобы можно было переносить программы туда-сюда.
Им это было совсем не нужно. Им было нужно чтоб проги писали под их ОС, а не переносили туда обратно.
И таки по результатам видим что они всё тогда сделали правильно — выкатили новый API, который работал по факту куда лучше. Сделали упор на поддержку девелоперов и как итог — захватили рынок. Подавляющее большинство клиентского софта писалось под винду. Это потом уже начали просирать старые заслуги.

A>Не говорите, что это не нужно. Это нужно. Для этого даже Qt написали.
И? Всё равно по факту всем насрать, никто перекомпилировать не будет, нужный виндовый софт запускаем в wine.

Здравствуйте, Pauel, Вы писали:

P>В твоей схеме надо
P>1 хранить чуть не все возможные версии всех депенденсов
Нет. Ровно только то, что было использовано в билде.

P>2 тратить чудовищное время на билд в силу естественных причин
Зависит от use case, в большинстве случаев когда надо за каким то хреном полезть в старьё — один фиг надо его исходники и весь environment, да и патч надо на том же сабсете делать, так что сборка одиг фиг нужна.

P>3 приседать с переменными билда-деплоя каждый раз когда понадобится
Никакой рукопашки, всё это уже должно быть в самом проекте.

P>А капасити опсов по твоему неограничена?
Чем вынуть тэг из архива и собрать его принципиально отличается от собрать один из текущих тэгов?

P> Еще один велосипед предлагаешь? Репозитории под артефакты уже давно изобрели.
Это потому что ты мыслишь только в готовых бинарях.

P>Но если на том же агенте запускать стабильный билд стабильной версии веб-приложения и все будет иначе — и по времени, и по частоте сбоев.
Т.е. ты щас сам признался что даже "стабильный билд стабильной версии веб-приложения" глючит всеми цветами радуги

CC>>Ты точно щас про веб?
P>Именно. Твое удивление говорит о том, что ты про веб-приложения только читал
Удивление?

CC>>А тебе точно надо гонять тесты для того, что уже было зафиксировано как срез годного билда?
P>Точно. Часть зависимостей в рантайме, соответсвенно я заранее и не знаю, годные они или нет. Небольшая мелочь может повалить всю цивилизацию, например — те самые переменные билда.
В этом то и проблема что у тебя никогда нет стабильного билда. И не будет.
Говно и палки, печаль!

P>>>0. подкинуть нужные переменные окружения — где гарантия что они будут теми же, что и в прошлый раз? Есть ответ?
P>Забавно, что ответа от тебя не поступило. Гы!
Ответ был ниже.

CC>>Вы это что, всё врукопашную до сих пор делаете?
P>Где сказано, что это врукопашную? Все эти скачивания требуют времени и в силу того, что любая сеть принципиально ненадежка, именно на этом скачивании билд чаще всего и валится.
Да потому что всё это должно работать автоматически.

P>Забавно, что ты не смог ничего выдать про переменные билда.
Забавно что для тебя "переменные билда" это нечто, что надо "подкидывать" без "гарантий что они будут теми же, что и в прошлый раз".
Это лютый бардак, говно и палки.

P> Каким чудом собираешься обеспечить идентичность переменных?
Суть проблемы вообще не понятна. Что значит "собираешься обеспечить"? У тебя что, сборка врукопашную делается, набирая команды в терминале по памяти?

P>А то потерял кое что, и твое приложение работать чуточку иначе. Что делать?
Делать чтобы ВЕСЬ билд собирался одной кнопкой. Чтоб не надо было думать какие там переменные надо ручонками выставить.
Впрочем с подходом "каждый раз тянется зоопарк из интернетов" такую элементарную вещь как повторяемый билд сделать нельзя, да. Ибо никто не знает какое говно скачается в следующий раз.

Здравствуйте, Sinclair, Вы писали:

CC>>Это всё верно, вот только не спасает жеж нифига. Годится для бинарного поиска в каком релизе сломали и в общем то всё.
S>Ну, так в основном этого и требуется.
Готовые бинари хранить — да, только для того и нужны. А вот для всего остального надо таки иметь возможность повторить полный билд.

S>Ну так свой-то код, естественно, вы держите со всей историей.
Зависимости этого кода надо держать там же, иначе можно получить "ой" когда выяснится что нужной версии какой нить странной либы больше нигде нету.

Здравствуйте, CreatorCray, Вы писали:

P>>В твоей схеме надо
P>>1 хранить чуть не все возможные версии всех депенденсов
CC>Нет. Ровно только то, что было использовано в билде.

Ну так билды идут постоянно, и депенденсы обновляются, а раз так, то получаем "чуть не все возможные версии всех депенденсов"

P>>2 тратить чудовищное время на билд в силу естественных причин
CC>Зависит от use case, в большинстве случаев когда надо за каким то хреном полезть в старьё — один фиг надо его исходники и весь environment, да и патч надо на том же сабсете делать, так что сборка одиг фиг нужна.

Это только один из use case. А когда нужен bisect, необходимость билдовать убивает весь бенефит.

P>>3 приседать с переменными билда-деплоя каждый раз когда понадобится
CC>Никакой рукопашки, всё это уже должно быть в самом проекте.

Ну вот есть сотня вариантов сборки-деплоймента. Каким образом будешь выбирать нужный? Будешь собирать всю сотню и тыкать наугад или таки переменную подкидывать?
Кроме того, инфраструктура/сеть в норме меняется постоянно.
1 Твои урлы которые ты вбил в конфиг могут протухнуть по естественным причинам — сервисы депрекейтнулись
2 сертификаты могут так же протухнуть
3 переменные могут стать уже невалидным
4 админы в норме вносят изменения по причинам секюрити, непрерывно, и это время от времени влияет на сборку, тесты, скачивание депенденсов, и даже на работу самих депенденсов. Самый простой пример — приложение теперь должно использовать другой коннекшн стринг к базе. Гы-гы.

Т.е. сеть принципиально а) нестабильна б) постоянно в изменениях. Это из букваря по веб-приложениям.

P>>А капасити опсов по твоему неограничена?
CC>Чем вынуть тэг из архива и собрать его принципиально отличается от собрать один из текущих тэгов?

Ты добавляешь дополнительный сервис, который нужно мейнтейнить.

P>> Еще один велосипед предлагаешь? Репозитории под артефакты уже давно изобрели.
CC>Это потому что ты мыслишь только в готовых бинарях.

Мы здесь про депенденсы. Ты что, собираешься и депенденсы пересобирать?

P>>Но если на том же агенте запускать стабильный билд стабильной версии веб-приложения и все будет иначе — и по времени, и по частоте сбоев.
CC>Т.е. ты щас сам признался что даже "стабильный билд стабильной версии веб-приложения" глючит всеми цветами радуги

Стабильный билд — пусканули пять раз подряд, всё зелено. Но это не гарантирует, что и через погода будет так же. Например, за эти полгода админы точно применять десяток или сотню фиксов секюрити, закроют то или это именно по причинам секюрити.
Например — запретили basic http, а вместо этого oidc client_credentials grant.
Твой билдец накрылся, потому что грейс период был три месяца, а прошло полгода.


CC>>>Ты точно щас про веб?
P>>Именно. Твое удивление говорит о том, что ты про веб-приложения только читал
CC>Удивление?

Так я вижу. Ты путаешь кейс нативного приложения типа дривер или близко к этому, и веб приложение. Веб приложение как правило распределенное, иначе не бывает. Из букваря мы знаем, что в таком случае есть одна единственная константа — это постоянные изменения в инфраструктуре/сети итд.

Инфраструктура сейчас и полгода назад это две разные инфраструктуры. И далеко не факт, что твой билд-скрипт может работать с любой из них.

P>>Точно. Часть зависимостей в рантайме, соответсвенно я заранее и не знаю, годные они или нет. Небольшая мелочь может повалить всю цивилизацию, например — те самые переменные билда.
CC>В этом то и проблема что у тебя никогда нет стабильного билда. И не будет.
CC>Говно и палки, печаль!

Стабильный билд это когда мы пусканули его сейчас раз пять или десять подряд. Зато через полгода, когда админы закрыли basic-http, твой стабильно зеленый билд станет стабильно красным. Ты же по тегу выкачиваешь — а там старая версия которая продолжает слать basic-http а грейс период уже тю-тю.

CC>>>Вы это что, всё врукопашную до сих пор делаете?
P>>Где сказано, что это врукопашную? Все эти скачивания требуют времени и в силу того, что любая сеть принципиально ненадежка, именно на этом скачивании билд чаще всего и валится.
CC>Да потому что всё это должно работать автоматически.

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

P>>Забавно, что ты не смог ничего выдать про переменные билда.
CC> Забавно что для тебя "переменные билда" это нечто, что надо "подкидывать" без "гарантий что они будут теми же, что и в прошлый раз".
CC>Это лютый бардак, говно и палки.

Цитирую себя

Сеть а) принципиально ненадежна б) постоянно в изменениях (секюрити, миграции, апгрейды железа, итд итд)

Следствие из этого — все конфиги рано или поздно протухают.

P>> Каким чудом собираешься обеспечить идентичность переменных?
CC>Суть проблемы вообще не понятна. Что значит "собираешься обеспечить"? У тебя что, сборка врукопашную делается, набирая команды в терминале по памяти?

Цитирую себя:

Сеть а) принципиально ненадежна б) постоянно в изменениях (секюрити, миграции, апгрейды железа, итд итд)

Следствие из этого — все конфиги рано или поздно протухают.
На новых конфигах приложение работает трохи иначе. Упс!

P>>А то потерял кое что, и твое приложение работать чуточку иначе. Что делать?
CC>Делать чтобы ВЕСЬ билд собирался одной кнопкой. Чтоб не надо было думать какие там переменные надо ручонками выставить.

Спасибо, капитан! Вот пусканул ты старый билд, а с тех пор админы запретили basic-http, по которому стучится твой билд. Твои действия?

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

Дело даже не в интернетах, сеть в каждой конторе меняется постоянно, инфраструктура — меняется, имена меняются, секюрити фиксы идут непрерывным потоком.
Заюзал ты функцию "скачаю я с локального сервера вон то", а в следующий раз этот локальный сервис скажет "этот запрос со вчерашного дня не секюрный, делай запрос секюрно"

Здравствуйте, CreatorCray, Вы писали:

S>>Ну так свой-то код, естественно, вы держите со всей историей.
CC>Зависимости этого кода надо держать там же, иначе можно получить "ой" когда выяснится что нужной версии какой нить странной либы больше нигде нету.

Ты что, собираешься в репу коммитать mysql? бинарниками или в исходном коде ?

Вместо "патч под вон ту версию" выпускаем текущую патч версию, т.е. 3.8.19. Нам нужно гарантировать, что эта патч версия обратно совместима с той, что у юзера (3.8.10).
соответсвенно, у нас есть бранча support/3.8/master и в ней делаем фикс и запускаем обычный билд.
Поэтому все нужные зависимости у нас есть. Если чтото исчезло прямо сейчас — туда ему и дорога. Обновляем зависимости, фиксим, запускаем билд и отдаём юзеру 3.8.19
В релиз нотах указываем "депендеси x обновилась с 7.0.1 на 7.0.9"

Где нам может понадобиться версия — 3.8.10 или 3.8.11 — например, траблшутинг, bisect, итд, что бы люди могли за секунды вернуться на старый/новый вариант
И вот здесь нам нужен артефакт сразу, а не после n часов сборки, приседания "а что же админы поменяли на прошлой неделе"

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

Здравствуйте, Sheridan, Вы писали:

S>И как там с гуём?

Гуй не нужен, консолька с командами по 15 строк, и нигде не документированные конфиги в vi — наше все. Ну еще курим маны, от чего глаза краснеют, а мозги студенеют.

Здравствуйте, ути-пути, Вы писали:

УП>Так а если я не хочу разруливать зависимости? Просто хочу стабильное окружение, одинаковое при разработке и в проде.
Ну так обновляйся раз в месяц-два и будет всё как ты говоришь.