Благодарю! Когда-то очень давно слышал про него, а потом напрочь вылетело из головы.
Насколько я понял из беглого прочтения README, если запускать через Maven-плагин или через CLI, наверное ему всё равно нужен доступный docker daemon. Да, с моим подходом можно заменить docker cli на jib cli, например, в первом образе.
Возможно, в течении пары недель попробую собрать им и посмотреть на разницу в итоговом образе со сборкой моим Dockerfile-ом.
Пару лет пользовался Rainbow brackets, но в последней версии IDEA заметил, что он тормозит, постоянно нагрузка на CPU. Выключил, Идея [относительно] полетела.
Всё равно в светлой теме от него не сильно проку :(
Так это в таком примере простом размер commited такой, потому что поток ничего кроме записи в консоль не делает. В реальной жизни большая вложенность стека, в том числе куча проксей, и в методах может быть куча аллоцированных на стеке данных.
Я лично в своих проектах (джава 15, к слову) уменьшаю Xss до 512 кб, потому что уменьшать дальше страшновато. То, что commited != max это понятно и замечательно.
Была похожая задача, по запросу API отдавали .xlsx, формируемый POI. В какой-то момент данных стало в разы больше, решили поменять формат на .csv. Из БД streamAllBy...(), тоже с какими-то хинтами (mysql), апачевский csv writer пишет в цикле сразу в httpResponse-овый outputStream. Ну да, у бизнеса нет форматирования колонок, им норм:) Зато быстро работает, не ограничен размером сверху и временных файлов на диске не требует.
Увы приходится. Продакшен, деньги, вот это вот все.
Конечно, я не знаю конкретно вашей ситуации, но в моей (аутсорс, финтех) тоже есть продакшен, от которого зависит и финансовое положение и репутационное заказчика. Обновляемся каждый раз до свежего релиза уже 2+ года спустя примерно месяц после его выхода.
неLTS это именно беты. Там в каждой есть критические баги.
Можно примеры таких багов?
Единственный баг, который реально словили за всё время — описан в этой статье (сами с ним не разобрались, а просто на бою накинули ресурсов). При этом наверняка были какие-то тонкости, которые время от времени решали, но это было быстро и незаметно.
Поэтому я всё-таки склонен считать, что релизы это именно релизы. Для достаточной уверенности можно не использовать preview features (я использую), и подождать хотя бы первого Update.
А вот как обосновать хотя бы пару недель два раза в год для пересаживания на неLTS с учетом потенциальных багов в ней я не знаю.
Ваши "2 недели 2 раза в год" — как-то очень завышено. В среднем это от 1 часа до 1 дня. Иногда (12 -> 13 и 13 -> 14) уходило по 5 минут на Find & Replace. Как раз то, что даже можно не пропихивать бизнесу, а просто взять и сделать, потому что обсуждать дольше (естественно, речь про один среднего размера проект на единицы микросервисов, а не "целый банк").
Единственное, что меня реально пугало бы в любом отдельно взятом проекте — миграция с 8 на 9+.
Обоснований куча. Для меня это шанс обновляться маленькими шагами, а не огромным скопом. Плюс возможность иметь фишки раньше. Не надо относиться к неLTS как к бетам.
Как только будут готовы "все" инструменты — в том числе починят ломбок, выпустят "совместимые" версии — в прошлый раз прошло недели две. Я обычно с этого момента уже еду на тестовые :) Пару недель там, и к месяцу на проде. С 13, 14, 15 было именно так :)
Поддержу. Имхо, всегда лучше стараться исключить сервере время как таковое: использовать или время по UTC (Instant), или локальное по отношению к клиенту/источнику запроса/т.п.
К сожалению, я не пишу на питоне, и не увижу каких-то дополнительных подводных камней, но в своих Java и JS проектах я использую другой подход. Делюсь:
Вместо того, чтобы запускать с помощью CI сборку докером, а докером запускать сборку питоном, можно всё это дело "вынести вверх". Сделать свой образ для сборки, $CI_REGISTRY_IMAGE/tooling:latest, установить в него все нужные для сборки инструменты и docker cli (чтобы не запускать dind). Докерфайл для его сборки положить в корень в папку tooling и джобу запускать при only.changes в ней. Пушим в регистри.
Далее уже выполняем сборку приложения джобой, у которой image: $CI_REGISTRY_IMAGE/tooling:latest. Тут уже можно легко использовать кеширование зависимостей, например у меня и maven и gradle целиком сохраняют все свои пакеты между запусками. После выполнения основного скрипта собираем докером образ из полученных артефактов и пушим, куда надо.
Благодарю! Когда-то очень давно слышал про него, а потом напрочь вылетело из головы.
Насколько я понял из беглого прочтения README, если запускать через Maven-плагин или через CLI, наверное ему всё равно нужен доступный docker daemon. Да, с моим подходом можно заменить docker cli на jib cli, например, в первом образе.
Возможно, в течении пары недель попробую собрать им и посмотреть на разницу в итоговом образе со сборкой моим Dockerfile-ом.
Люди делятся на два типа :))
Хипстеры и луддиты. Не важно, разработчики они или сисадмины, или кто-то ещё :) По каждую из сторон баррикад есть и те, и те.
П.с. Хипстеры 4евер!
Пару лет пользовался Rainbow brackets, но в последней версии IDEA заметил, что он тормозит, постоянно нагрузка на CPU. Выключил, Идея [относительно] полетела.
Всё равно в светлой теме от него не сильно проку :(
Так это в таком примере простом размер commited такой, потому что поток ничего кроме записи в консоль не делает. В реальной жизни большая вложенность стека, в том числе куча проксей, и в методах может быть куча аллоцированных на стеке данных.
Я лично в своих проектах (джава 15, к слову) уменьшаю Xss до 512 кб, потому что уменьшать дальше страшновато. То, что commited != max это понятно и замечательно.
Какие-то странные у Вас потоки, по 16 кб. А стек по умолчанию на 1 мб/поток?
Была похожая задача, по запросу API отдавали .xlsx, формируемый POI. В какой-то момент данных стало в разы больше, решили поменять формат на .csv. Из БД streamAllBy...(), тоже с какими-то хинтами (mysql), апачевский csv writer пишет в цикле сразу в httpResponse-овый outputStream. Ну да, у бизнеса нет форматирования колонок, им норм:) Зато быстро работает, не ограничен размером сверху и временных файлов на диске не требует.
Так у них полноценная поддержка, а не расширенная :)
Альфа и бета подразумевают нестабильность. Это полноценные релизы.
Для Вас это слишком быстро, несколько новых языковых фич за несколько лет?
Спасибо за ответы.
Конечно, я не знаю конкретно вашей ситуации, но в моей (аутсорс, финтех) тоже есть продакшен, от которого зависит и финансовое положение и репутационное заказчика. Обновляемся каждый раз до свежего релиза уже 2+ года спустя примерно месяц после его выхода.
Можно примеры таких багов?
Единственный баг, который реально словили за всё время — описан в этой статье (сами с ним не разобрались, а просто на бою накинули ресурсов). При этом наверняка были какие-то тонкости, которые время от времени решали, но это было быстро и незаметно.
Поэтому я всё-таки склонен считать, что релизы это именно релизы. Для достаточной уверенности можно не использовать preview features (я использую), и подождать хотя бы первого Update.
Ваши "2 недели 2 раза в год" — как-то очень завышено. В среднем это от 1 часа до 1 дня. Иногда (12 -> 13 и 13 -> 14) уходило по 5 минут на Find & Replace. Как раз то, что даже можно не пропихивать бизнесу, а просто взять и сделать, потому что обсуждать дольше (естественно, речь про один среднего размера проект на единицы микросервисов, а не "целый банк").
Единственное, что меня реально пугало бы в любом отдельно взятом проекте — миграция с 8 на 9+.
Обоснований куча. Для меня это шанс обновляться маленькими шагами, а не огромным скопом. Плюс возможность иметь фишки раньше. Не надо относиться к неLTS как к бетам.
Really? O_o
А можно подробности? У меня не такой случай (Xmx=Xms), но ваше заявление очень интересно. Спасибо.
Возможно, хаб Java тут лишний?
Действительно, my fault. Исправил.
(2021 — 1995) / 16 = новая версия каждые ~1.5 года, неплохо идёт! :))
Как только будут готовы "все" инструменты — в том числе починят ломбок, выпустят "совместимые" версии — в прошлый раз прошло недели две. Я обычно с этого момента уже еду на тестовые :) Пару недель там, и к месяцу на проде. С 13, 14, 15 было именно так :)
IDEA уже поддерживает, ждём тонкие образы от Bellsoft, проверяем работоспособность спринга, ломбока, прочих инструментов, да едем в прод :)
Поддержу. Имхо, всегда лучше стараться исключить сервере время как таковое: использовать или время по UTC (Instant), или локальное по отношению к клиенту/источнику запроса/т.п.
К сожалению, я не пишу на питоне, и не увижу каких-то дополнительных подводных камней, но в своих Java и JS проектах я использую другой подход. Делюсь:
Вместо того, чтобы запускать с помощью CI сборку докером, а докером запускать сборку питоном, можно всё это дело "вынести вверх". Сделать свой образ для сборки, $CI_REGISTRY_IMAGE/tooling:latest, установить в него все нужные для сборки инструменты и docker cli (чтобы не запускать dind). Докерфайл для его сборки положить в корень в папку tooling и джобу запускать при only.changes в ней. Пушим в регистри.
Далее уже выполняем сборку приложения джобой, у которой image: $CI_REGISTRY_IMAGE/tooling:latest. Тут уже можно легко использовать кеширование зависимостей, например у меня и maven и gradle целиком сохраняют все свои пакеты между запусками. После выполнения основного скрипта собираем докером образ из полученных артефактов и пушим, куда надо.