Re: Кэширование репозиториев maven/pypi/npm - proxy_cache или proxy_store

2023-11-23 Пенетрантность Илья Шипицин 
я передумал ))

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

чт, 23 нояб. 2023 г. в 15:25, Eugene Prokopiev :

> Нету там POST - даже у самого замороченного npm, а у maven/pypi и
> метаданных-то толком нет - это примитивные файлопомойки, которые даже
> на S3 держать тожно
>
> чт, 23 нояб. 2023 г. в 16:24, Илья Шипицин :
> >
> > есть же прямо специализированные кеширующие прокси для, какой смысл
> кулибинствовать на уровне http ?
> > тем более, что там куча POST запросов, которые не могут кешироваться
>
> --
> WBR,
> Eugene Prokopiev
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Кэширование репозиториев maven/pypi/npm - proxy_cache или proxy_store

2023-11-23 Пенетрантность Vladislav Shabanov 
Ну, как устроена реальная жизнь:

День 1: программисты хотят 10 пакетов, вместе с зависимостями это, допустим, 
182 штуки. Во время «вместе с зависимостями» было сколько-то обращений к 
оглавлению за метаданными. Допустим, они все GET и настолько простые, что их 
можно закэшировать не вникая. Закэшировали запросы к метаданным и сами 
10+182=192 пакета.

День N: программисты захотели ещё 1 пакет добавить. Мигрировать на свежие 
версии предыдущих 10 пакетов (или предыдущих 192, если вместе с зависимостями) 
не хотят, это отдельное упражнение. 

Опять пошли GET-запросы к метаданным, наш новый пакет хочет ещё 5 штук новых и 
12 штук из тех, предыдущих 182, но в более свежих версиях, хотя старые тоже 
подошли бы. Если смогли так обмануть исходный репозиторий, чтобы эти запросы 
выдали 12 старых пакетов именно в закэшированных версиях, то повезло. А если 
протокол обращения к репозиторию к этому не пригоден, то не повезло, придётся 
тащить все 12 новых версий пакетов тоже. Начинается субботник. В JS он частично 
лечится через packages-lock, в питоне надо немного повозиться, в других языках 
тоже обязательно надо повозиться.

День M: захотели ещё пакет, наш кэш усердно обманывает, чтобы при ходьбе по 
зависимостям выдавать, что более свежих версий наших 182 пакетов нету. Но вот 
новый пакет активно хочет более свежую версию, у него в метаданных прописана 
совместимость >= n.m.k. Тут новый вид попадалова, когда кэши надо всё-таки 
выкинуть и всё скачать заново. Причём в этом «всё скачать» исходный репозиторий 
вам присунет все 182 обновлённых пакета, и ещё пару десятков новых пакетов. А 
вы хотели выборочно обновить только то, что действительно нужно, а глобальный 
субботник снова хотели «на потом».

Короче, идея просто кэшировать постепенно превращается в 
https://www.youtube.com/watch?v=V5RQh5tNcbo 


Вообще, всё от постановки задачи зависит. Если «хочу чтоб в военное время можно 
было кэшированными версиями пакетов сервер залить, понимаю, что новых версий 
после начала войны брать из-за океана не буду», то простого кэширования 
достаточно. Если «хочу сам, выборочно вбирать в себя новшества, читая диффы, 
откладывая на потом странные обновления и втаскивая полезные», то не вникая в 
логику репозитория этого не сделать.

Влад


> 23 нояб. 2023 г., в 17:24, Eugene Prokopiev  
> написал(а):
> 
> Ну так оглавление, ссылающееся на новые файлы ( а старые при этом
> остаются доступными) - это кажется фичей, а не багом, разве нет?
> 
> Другие варианты смотрел, но с монстрами типа artifactory/sonatype
> связываться не хочется (там еще и куча ограничений в свободных
> версиях), а с зоопарком reposilite/devpi/verdaccio тоже
> 
> чт, 23 нояб. 2023 г. в 15:22, Vladislav Shabanov :
>> 
>> Без знания семантики кэшировать непросто. Оглавление начинает ссылаться на 
>> новые файлы. Даже если вы кэшируете сами пакеты, метаданные кэшировать 
>> сложнее.
>> Посмотрите:
>> 
>> https://verdaccio.org/docs/best
>> https://www.sonatype.com/products/sonatype-nexus-oss-download
>> 
>> Владислав
>> 
>> 23 нояб. 2023 г., в 14:31, Eugene Prokopiev  
>> написал(а):
>> 
>> Здравствуйте!
>> 
>> Есть задача кэширования репозиториев maven/pypi/npm для разработки - и
>> гуглится куча примеров, как это сделать
>> 
>> Но смущает, что во всех примерах используются директивы proxy_cache*,
>> а мне более удобным кажется proxy_store - в этом случае кэш
>> раскладываются по файлам аналогично оригиналу, понятно где, что и
>> сколько места занимает, легко вручную удалить часть кэша и т.д.
>> 
>> Расскажите, какие минусы у этого подхода, чем proxy_store хуже (или
>> лучше?) proxy_cache*?
>> 
>> --
>> WBR,
>> Eugene Prokopiev
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>> 
>> 
> 
> 
> -- 
> WBR,
> Eugene Prokopiev

___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Кэширование репозиториев maven/pypi/npm - proxy_cache или proxy_store

2023-11-23 Пенетрантность Eugene Prokopiev 
Нету там POST - даже у самого замороченного npm, а у maven/pypi и
метаданных-то толком нет - это примитивные файлопомойки, которые даже
на S3 держать тожно

чт, 23 нояб. 2023 г. в 16:24, Илья Шипицин :
>
> есть же прямо специализированные кеширующие прокси для, какой смысл 
> кулибинствовать на уровне http ?
> тем более, что там куча POST запросов, которые не могут кешироваться

-- 
WBR,
Eugene Prokopiev
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Кэширование репозиториев maven/pypi/npm - proxy_cache или proxy_store

2023-11-23 Пенетрантность Eugene Prokopiev 
Ну так оглавление, ссылающееся на новые файлы ( а старые при этом
остаются доступными) - это кажется фичей, а не багом, разве нет?

Другие варианты смотрел, но с монстрами типа artifactory/sonatype
связываться не хочется (там еще и куча ограничений в свободных
версиях), а с зоопарком reposilite/devpi/verdaccio тоже

чт, 23 нояб. 2023 г. в 15:22, Vladislav Shabanov :
>
> Без знания семантики кэшировать непросто. Оглавление начинает ссылаться на 
> новые файлы. Даже если вы кэшируете сами пакеты, метаданные кэшировать 
> сложнее.
> Посмотрите:
>
> https://verdaccio.org/docs/best
> https://www.sonatype.com/products/sonatype-nexus-oss-download
>
> Владислав
>
> 23 нояб. 2023 г., в 14:31, Eugene Prokopiev  
> написал(а):
>
> Здравствуйте!
>
> Есть задача кэширования репозиториев maven/pypi/npm для разработки - и
> гуглится куча примеров, как это сделать
>
> Но смущает, что во всех примерах используются директивы proxy_cache*,
> а мне более удобным кажется proxy_store - в этом случае кэш
> раскладываются по файлам аналогично оригиналу, понятно где, что и
> сколько места занимает, легко вручную удалить часть кэша и т.д.
>
> Расскажите, какие минусы у этого подхода, чем proxy_store хуже (или
> лучше?) proxy_cache*?
>
> --
> WBR,
> Eugene Prokopiev
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>


-- 
WBR,
Eugene Prokopiev
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Кэширование репозиториев maven/pypi/npm - proxy_cache или proxy_store

2023-11-23 Пенетрантность MihaKot 
Согласен.
Зачем использовать nginx для кеширования npm пакетов?
Есть вполне рабочее ПО для этого. Мы у себя используем Nexus, которые умеет
кешировать и проксировать много чего.

чт, 23 нояб. 2023 г. в 16:24, Илья Шипицин :

> есть же прямо специализированные кеширующие прокси для, какой смысл
> кулибинствовать на уровне http ?
> тем более, что там куча POST запросов, которые не могут кешироваться
>
> чт, 23 нояб. 2023 г. в 12:29, Eugene Prokopiev  >:
>
>> Здравствуйте!
>>
>> Есть задача кэширования репозиториев maven/pypi/npm для разработки - и
>> гуглится куча примеров, как это сделать
>>
>> Но смущает, что во всех примерах используются директивы proxy_cache*,
>> а мне более удобным кажется proxy_store - в этом случае кэш
>> раскладываются по файлам аналогично оригиналу, понятно где, что и
>> сколько места занимает, легко вручную удалить часть кэша и т.д.
>>
>> Расскажите, какие минусы у этого подхода, чем proxy_store хуже (или
>> лучше?) proxy_cache*?
>>
>> --
>> WBR,
>> Eugene Prokopiev
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>


-- 
P.S. Сохраняйте переписку в теле письма.
___
Best regards, Konstantin @MihaKot@ Aksarin.
Phone: +7 921 74 66 818
Skype: mihakot
E-mail: miha...@gmail.com
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Кэширование репозиториев maven/pypi/npm - proxy_cache или proxy_store

2023-11-23 Пенетрантность Илья Шипицин 
есть же прямо специализированные кеширующие прокси для, какой смысл
кулибинствовать на уровне http ?
тем более, что там куча POST запросов, которые не могут кешироваться

чт, 23 нояб. 2023 г. в 12:29, Eugene Prokopiev :

> Здравствуйте!
>
> Есть задача кэширования репозиториев maven/pypi/npm для разработки - и
> гуглится куча примеров, как это сделать
>
> Но смущает, что во всех примерах используются директивы proxy_cache*,
> а мне более удобным кажется proxy_store - в этом случае кэш
> раскладываются по файлам аналогично оригиналу, понятно где, что и
> сколько места занимает, легко вручную удалить часть кэша и т.д.
>
> Расскажите, какие минусы у этого подхода, чем proxy_store хуже (или
> лучше?) proxy_cache*?
>
> --
> WBR,
> Eugene Prokopiev
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Кэширование репозиториев maven/pypi/npm - proxy_cache или proxy_store

2023-11-23 Пенетрантность Vladislav Shabanov 
Без знания семантики кэшировать непросто. Оглавление начинает ссылаться на 
новые файлы. Даже если вы кэшируете сами пакеты, метаданные кэшировать сложнее.
Посмотрите:
https://verdaccio.org/docs/best 
https://www.sonatype.com/products/sonatype-nexus-oss-download 

Владислав

> 23 нояб. 2023 г., в 14:31, Eugene Prokopiev  
> написал(а):
> 
> Здравствуйте!
> 
> Есть задача кэширования репозиториев maven/pypi/npm для разработки - и
> гуглится куча примеров, как это сделать
> 
> Но смущает, что во всех примерах используются директивы proxy_cache*,
> а мне более удобным кажется proxy_store - в этом случае кэш
> раскладываются по файлам аналогично оригиналу, понятно где, что и
> сколько места занимает, легко вручную удалить часть кэша и т.д.
> 
> Расскажите, какие минусы у этого подхода, чем proxy_store хуже (или
> лучше?) proxy_cache*?
> 
> -- 
> WBR,
> Eugene Prokopiev
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru

___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Кэширование репозиториев maven/pypi/npm - proxy_cache или proxy_store

2023-11-23 Пенетрантность Eugene Prokopiev 
Здравствуйте!

Есть задача кэширования репозиториев maven/pypi/npm для разработки - и
гуглится куча примеров, как это сделать

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

Расскажите, какие минусы у этого подхода, чем proxy_store хуже (или
лучше?) proxy_cache*?

-- 
WBR,
Eugene Prokopiev
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru