Здравствуйте, artelk, Вы писали:
A>Это аргумент в пользу того, что сервисы не должны быть слишком большие, т.е. больше, чем одна команда сможет поддерживать и развивать. A>Но у микросервисов декларируемая гранулярность же намного выше.
Гранулярность для сервисов — это не плюс. Скорее минус.
M>только какая то старая версия может пропасть с серверов, тогда надо делать ее копии у себя и тд
Именно так. Как может и не собраться Dockerfile в конкретный момент времени. Пакет устарел, бинарник переложили в другое место или репозиторий временно не работает
Поэтому саму сборку base image не делают частью pipeline. Условно говоря, закэшированный Image + on-demand (GitHub Webhook) image с артифактом, поверх базового.
S>>И правда ведь... Docker — он же не бесплатный по ресурсам, верно? Зачем он, если можно и без него?
M>Без него будет дольше и хуже, чем с ним. Даже несмотря на то, что докер — говно.
M>Ты получаешь одинаковый environment на всех стадиях: в разработке, при тестировании, на staging'е, в production'е. Безо всяких свистоплясток типа «а вот у девелопера будет докер, а вот на тесте развернем ansible'ом, а в проде тоже развернем ansible'ом, но надо еще извернуться, чтобы куда-то security-sensitive ключи засунуть» (хотя докер, естественно, не решает проблему ключей).
M>Получить на dev-машине такой же environment, как на prod'е — бесценно. Остальное — мелочи жизни.
Одинаковость environments при использовании docker слишком преувеличена
Здравствуйте, Cyberax, Вы писали:
S>>Правильно ли я понял что срач разводится в микросервисах проще и быстрее, чем в монолите? C>Нет, микросервисы не проще и не быстрее монолита. Они позволяют масштабироваться для очень больших проектов, над которыми работает сотни человек.
Или библиотеки.
S>Всегда сочувствую тем, кому запрещают логи писать и метрики расставлять.
Ты всерьез думаешь, что другим командам интересно читать твои логи и изучать твои метрики, чтобы создать тикет на тебя?
Нет, если у твоего сервиса постоянные OOM, это должно быть только твоей проблемой. А не тех, кому ты свой код хочешь подсунуть на деплоймент.
C>>>Ну и напоследок, в случае с API обычно легко контролировать кто и как его использует M>>Мммм. Ну, это не совсем так. C>Зависит от реализации. В Амазоне для использования API обычно требовалось, чтобы команда добавила разрешения для конкретных клиентов.
Заморочки Амазона. Далеко не все так заморачиваются.
M>>Получить на dev-машине такой же environment, как на prod'е — бесценно. Остальное — мелочи жизни.
D>Одинаковость environments при использовании docker слишком преувеличена
Здравствуйте, SkyDance, Вы писали:
S>>Всегда сочувствую тем, кому запрещают логи писать и метрики расставлять. SD>Ты всерьез думаешь, что другим командам интересно читать твои логи и изучать твои метрики, чтобы создать тикет на тебя?
А тебе запрещают добавить опции "err,wrn,nfo,dbg"? Владелец бизнеса тоже против?
Здравствуйте, Sheridan, Вы писали:
S>>>Правильно ли я понял что срач разводится в микросервисах проще и быстрее, чем в монолите? C>>Нет, микросервисы не проще и не быстрее монолита. Они позволяют масштабироваться для очень больших проектов, над которыми работает сотни человек. S>Или библиотеки.
Нет, даже близко так не получается.
Здравствуйте, namespace, Вы писали:
N>Скажем, у Скайденса на банковском счету вдруг стало 0 денег, счет за комунальные услуги пришел в двойном размере, а магазинная касса занимается приписками в чеках.
Ну если ему еще и телефон заблокировать, и условно-досрочное освобождение из базы полиции стереть, то почему бы и нет, никто и не заметит такую ошибку.
Здравствуйте, gandjustas, Вы писали:
Б>>Да, например AI может быть написан на python, сервисы на go, интеграция с enterprise на java. G>Но дешевле все сделать на одном языке. На той же java.
Это если ты с код с нуля пишешь, и команда программистов у тебя профессиональная и сплоченная.
А если у тебя весь твой код свинчен из разнородных запчастей, собраных со всего гитхаба, а в программисты ты записал нищих, которых подобрал у ближайшей церкви, то может оказаться, что у тебя и запчасти все на разных языках написаны, и программисты твои каждый умеет немного на своем каком-то языке, и никто не способен изучить другой язык.
Вот тогда у тебя и получится описанная выше каша.
Б>>Ну и упрощение сервисов — маленькую программу написать проще, также как и переписать с нуля при необходимости. G>Написать одну большую программу проще, чем кучу маленьких, в сумме дающих функциональность большой.
Вот это как раз спорный вопрос. Всякие там классы затем и придумали, чтобы запчасти большой системы не рылись в памяти друг у друга. Разнесение на отдельные процессы помогает этой изоляции еще больше.
легендарный Sheridan:
S>И правда ведь... Docker — он же не бесплатный по ресурсам, верно? Зачем он, если можно и без него?
Как раз-таки для разработки и надо, особенно если делать чисты билд. Без малейшей связи с теми библиотеками, что уже "прописались" на компьютере разработчика.
Dockerfile из минималистичного базового image и есть кристаллизованный-чистый билд. Где четко видны зависимости build-time и runtime
Например, "набросал" свой Dockerfile для FreeSwitch. И вся эта куча доп-пакетов не заполоняет мой Linux сервер. И нет никаких личных readme.md, как я вручную собирал бы этот FreeSwitch
Здравствуйте, Vetal_ca, Вы писали:
V_>Поэтому саму сборку base image не делают частью pipeline. Условно говоря, закэшированный Image + on-demand (GitHub Webhook) image с артифактом, поверх базового.
да именно так. и это большой бонус
тру стори — понадобилось собрать проект который 3 года лежал на полке, много библиотек старых версий было недоступно, под новые местами понадобилось переписывать код, одно тянуло другое, в общем убил дня 3. а потом нашел base-image
S>А, тебе слова не понравились. А почему ты решил что "выкачать всё нужное" означает "выкачать самые последние версии всего подряд"? S>ansible это описание деплоя, код. Как напишешь — так и будет.
нужных версий может не оказаться там где они были спустя год-два-три. как писали выше в случае докера как правило используют base-image со стабильным зафиксированным окружением
Здравствуйте, mogadanez, Вы писали:
S>>А, тебе слова не понравились. А почему ты решил что "выкачать всё нужное" означает "выкачать самые последние версии всего подряд"? S>>ansible это описание деплоя, код. Как напишешь — так и будет.
M> нужных версий может не оказаться там где они были спустя год-два-три. как писали выше в случае докера как правило используют base-image со стабильным зафиксированным окружением
Да, ты прав. Грустно когда запрещают делать локальный кеш и писать код исключительно на древних версиях чегототам
Здравствуйте, mogadanez, Вы писали:
S>>Да, ты прав. Грустно когда запрещают делать локальный кеш M>не запрещают, но это надо делать, или оно из коробки бывает в том же ансибле?
А ты свой код так-же из коробки достаёшь?
S>>и писать код исключительно на древних версиях чегототам M>иногда на новой просто не работает а рук переписать не хватает.
Ой вей, надо работать, а пальчики устали. А если учесть предыдущий пункт, то дважды устали. Какая досада.
Здравствуйте, mogadanez, Вы писали:
M>тру стори — понадобилось собрать проект который 3 года лежал на полке, много библиотек старых версий было недоступно, под новые местами понадобилось переписывать код, одно тянуло другое, в общем убил дня 3. а потом нашел base-image
Аааа, вот оно что. Три дня пришлось гуглить? Теперь понятно почему ты не знаешь что такое ansible и как он работает. Это ж неделю гуглить надо, минимум.
Здравствуйте, Shmj, Вы писали:
S>И правда ведь... Docker — он же не бесплатный по ресурсам, верно? Зачем он, если можно и без него?
Рабсила тестировщиков, разработчиков, девопсов и админов она что, бесплатная?
Небольшая команда 5 человек стоит в год, при зп 1000$ на единицу 60000$
Реальная зп и большая команда гораздо выше, потому год разработки от 1КК и выше.
Соответственно, если доккер экономит вагон времени, то сэкономленые деньги можно потратить и на амазоновский план.
