Интересный поворот, как раз нашим жаловался чего у них жс одним блобом. Классика "сделай проще, надёжней работать будет" оказалась актуальной :) как это решают вне куба?

это проблема контейнеров в целом и js чанков, много раз натыкался. Файлопомойка/js логика или вот новый путь хочу попробовать, чероз proxy_cache

у него видимо не по хешу

у меня по хешу....

proxy_cache - не "новый путь", а костыль, который может взорваться в непредсказуемый момент

Если в новом контейнере js/css будут названы как в старом (например по хэшу) разве потеряет?

мы про этот стали говорить

ну загружай с контейнера в CDN например

proxy_cache - не "новый путь", а костыль, который может взорваться в непредсказуемый момент

на этот случай останется js логика. Которая будет покрывать редкие взрывы и ладно.

Задача просто пережить 1-2 часа без явного старого js. proxy_cache решит.

да сложи на cdn

ну загружай с контейнера в CDN например

с CDN таже проблема что и с assets помойками. Это нужно следить, выгребать и тп.

или забить? :)

ну, хочется декларативности, как yml. apply а остальное делает кто-то другой. proxy_cache сам чистит.

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

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

(или нет)

это проблема контейнеров в целом и js чанков, много раз натыкался. Файлопомойка/js логика или вот новый путь хочу попробовать, чероз proxy_cache

В порядке бреда:каждая версия приложения деплоит свой уникальный ассет (свой deployment, ingress, service) + один общий ingress , который будет перезаписывается каждым следующим деплоем. Эдакий green/blue но только со всеми цветами радуги и старые версии долго не удаляем

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

так он сам будет заполняться и отваливаться по ttl

ключевое слово: предсказуемо

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

и может случиться так что часть уже отвалилась, а часть ещё лежит в кеше

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

я так и жду. Подходит.

вероятность того, что ни один пользователь за 24 часа не загрузит второй чанк крайне мала. А отвалится сначала основной.

это проблема контейнеров в целом и js чанков, много раз натыкался. Файлопомойка/js логика или вот новый путь хочу попробовать, чероз proxy_cache

Вторая мысль: можно все ассеты пихать в клиента по http2 server push, оно в фоне подзагрузится и осядет в Кеше браузера

Вторая мысль: можно все ассеты пихать в клиента по http2 server push, оно в фоне подзагрузится и осядет в Кеше браузера

это service worker задача, который у js

это service worker задача, который у js

Я не совсем в теме, но что это меняет? Оно в обход кэша браузера код загружает?

Я не совсем в теме, но что это меняет? Оно в обход кэша браузера код загружает?

он по командам может ложить в кэш, что скажут

*заранее.

и сказать, что это можно взять даже в offline и будет ок.

смотри карочи, у тебя index.html грузится с приложения бекенда, а статика с соседних контейнеров, так?

В порядке бреда:каждая версия приложения деплоит свой уникальный ассет (свой deployment, ingress, service) + один общий ingress , который будет перезаписывается каждым следующим деплоем. Эдакий green/blue но только со всеми цветами радуги и старые версии долго не удаляем

Colorful deployments как раз таки здравая мысль - https://opensource.com/article/17/5/colorful-deployments например

нет, я сейчас кладу assets рядом с беком там, где всплывает такой кейс. SSR и тп.

Ну я про то, что ваш nginx может тоже в кеш браузера положить что хочет заранее , т.е. задачу можно решить не привлекая жс программистов воообще

нет, я сейчас кладу assets рядом с беком там, где всплывает такой кейс. SSR и тп.

в одном поде или как?

ну он отдаёт статику в надежде, что nginx сверху разрулит нагрузку эту.

что такое "кладу ассетс рядом с беком"?

на истио в чистом k8s это проще делать, ну и велосипеды конечно же

что такое "кладу ассетс рядом с беком"?

что бек http сервис и может раздать статику немного, пока nginx не начнет кешить

Colorful deployments как раз таки здравая мысль - https://opensource.com/article/17/5/colorful-deployments например

Ого, интересно. Почитаю

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

тогда норм будет

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

ага. И кэш будет жив, даже если старый бек отвалится.

s/если/когда/

http://brandon.dimcheff.com/2018/02/rainbow-deploys-with-kubernetes/ если совсем кратко

блять, мимо

лол

тогда норм будет

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

можно server snipet (вроде) написать на ingress кажется и проксить самого себя. Но хотелось бы volume монтировать под это.

можно кастом шаблон для ингресса всегда сделать

http://brandon.dimcheff.com/2018/02/rainbow-deploys-with-kubernetes/ если совсем кратко

Ха , и правда: As a bonus, since the first six characters of a git sha are also a valid hex color, the name still makes sense. :) Можно красивую (бесполезную) визуализацию сделать со спектром и интенсивностью от времени деплоя

https://github.com/kubernetes/ingress-nginx/issues/739 вон тут предлагают так и сделать

Ха , и правда: As a bonus, since the first six characters of a git sha are also a valid hex color, the name still makes sense. :) Можно красивую (бесполезную) визуализацию сделать со спектром и интенсивностью от времени деплоя

ы!

и цвет прямо в графану выводить!

@alexesDev https://stackoverflow.com/questions/47135256/kubernetes-nginx-ingress-controller-caching-static-assets

Ха , и правда: As a bonus, since the first six characters of a git sha are also a valid hex color, the name still makes sense. :) Можно красивую (бесполезную) визуализацию сделать со спектром и интенсивностью от времени деплоя

Active deployment: seroburomalinovy

https://github.com/kubernetes/ingress-nginx/issues/739 вон тут предлагают так и сделать

о, я думал как бы volume подцепить, а можно redis. Не знал. Звучит круто, буду копать.

кажется не очень сложно

о, я думал как бы volume подцепить, а можно redis. Не знал. Звучит круто, буду копать.

А что с http2 server push? :) Выглядит проще, работает даже лучше

(в теории)

нужно тестить, до конца не понимаю

При отдаче страницы по http2 сервер передаст браузеру и другие ассеты , они осядут в кэше и когда понадобятся к серверу никто не пойдет

угу, только бекенд должен как-то сообщить что надо пушить в клиента

Прям в ингресс контроллере можно, значение взять из аннотаций

а он откуда узнает?

ну смысле оно же может быть разное для разных урлов

(Имхо nginx не поддерживает http2 до бекендов , так что вряд ли получится этим с бекенда рулить)

ваще не очень понимаю как этот пуш работает

ну смысле оно же может быть разное для разных урлов

через config-snippet аннлтацию из Ingress приложения

у тебя в одном урле один набор ассетов, а в другом - другой

а потом новая версия приложения вышла и всё поменялось

ты каждый раз будешь ингресс перенастраивать?

ты каждый раз будешь ингресс перенастраивать?

Ну приложение деплоит свой Ingress, там и прописывает

(ingress != Ingress controller если вдруг о разных вещах говорим)

https://nginx.org/en/docs/http/ngx_http_v2_module.html#http2_push

как всё было просто во времена сайтиков с пхп

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

Они и не должен ничего знать. CI пайплайн сам все может сделать

Понять что это деплой с ассетами, заглянуть в контейнер взять имена, прописать в ingress аннотации

ну технически это конечно возможно

чтобы всё само

да, ты прав, вполне норм тема

пойду в прод хуярить :)

Можно попросить разработчиков при билде оставлять артефакт с именами ассеты. Можно http2_push_preload заюзать тогда nginx вообще все сам

(но тогда это будет работать только на первом уровне, т.е. со страницы index.html)

А не, оно же через header (https://blog.cloudflare.com/http-2-server-push-with-multiple-assets-per-link-header/) вообще отлично - nginx с ассетами сам может сказать что предзагрузить

Т.е. можно рулить с бекенда

Т.е. CI пайплайн даже трогать не надо

PXE boot + CoreOS . Можно посмотреть на typhoon как сделано

а что вы думаете по поводу Kubespray?

Бодрый день, впрос такой - а python использует cgroups для определения лимитов, когда бегает в k8s?

сталкивался кто?

Написал, чем пользуюсь :) kubespray не пользуюсь , для меня показательно, что у них до недавнего времени тейнты на нодах не работали, потому что они scheduler запускали со своим древним конфигом зачем-то. С другой стороны баги есть везде и кто знает сколько всего не работает в моей наколенной поделке? :)

Бодрый день, впрос такой - а python использует cgroups для определения лимитов, когда бегает в k8s?

О каких лимитах речь? Вроде только JVM и то последний умеет из cgroups информацию брать для дефолтов

Народ, кто нибуть юзал вот этот мануал, для починки Helm? https://medium.com/@valercara/helm-stuck-in-pending-update-and-how-to-fix-it-13c4b2eaf9f7

О каких лимитах речь? Вроде только JVM и то последний умеет из cgroups информацию брать для дефолтов

Как я понимаю по дефолту под показывает информацию о ноде на которой бегает (грубо говоря: free -h покажет данные ноды)

Вообщем бегают у меня с 10 jyputer'ов, и я не могу сообразить - понимает ли питон лимиты пода в котором бегает

если он cgroups не поддерживает - то получается что не понимает, и радостно жрет оперативку как не в себя