.Pirátská strana » Technické oddělení

Ještě jsem nad tím trochu přemýšlel a jako kompletní řešení mi připadá:

1. Udělat nějaký server, kam se dá nahrávat user content, ideálně aby to mělo nějaký přehled mnou nahraných souborů (user spaces). To by možná mohla umět CDNka? https://redmine.pirati.cz/issues/10599
2. Na tenhle server nahrávat content, při nahrání by to mělo vrátit ID daného souboru. Na nahrávání souborů buď udělat nějaký commandline tool, nebo ideálně UI na CDNce.
3. Vystavit imaging service.
4. Vystavit nějakou jednoduchou službu (napsanou třeba v Node.js, páč hezky umí streamy), která vezme ID souboru (ověří že je validní -- že existuje na CDN), URL parametry pro resize, doplní signature requestu a pošle to dál na tu službu.
5. Před Node.js službu vystavit Nginx caching reverse proxy, která vyřeší cache aby se to při opětovných requestech vzalo z ní a nedělalo se to pořád dokola.

Jediná služba, která vypadá, že umí requesty podepisovat nějakým secretem se zdá být imgproxy. Ten podpis mi přijde důležitej abychom zamezili nějakýmu bombení z venku.

Co myslíte?

U mne by vyhrali imgproxy a imaginary. Od mikroservisy na Go bych ocekaval docela pekny vykon. Thumbor za sebou tahne mongodb, a co vsechno navic jsem nestudoval.

Samotný nápad samozřejmě OK, vidím tam následující úskalí:

• uživatelským nahráváním bude vznikat velký objem dat, který bude obtížné řídit (nebude například možné poznat, zda je obrázek někde použit); za nějaký čas budeme mít desítky GB obrázků, se kterými nebudeme moci nic udělat, ale budeme je muset udržovat dostupné forever
• umístění obrázku bude složitější, i když návod vypadá jednoduše, pro uživatele to znamená použít službu navíc
• jak to bude s verzováním souborů? Bude možné obrázek přepsat? Pak se změní všude, může to mít nechtěné vedlejší efekty
• ztratí se možnost provozovat web lokálně (resp. offline), protože obrázky nebudou jeho součástí
• používat git pro binární soubory není ideální, na druhou stranu existuje např. git LFS
• skutečně se to provádí crop/resize každém buildu? není možné nakonfigurovat, případně prosadit do upstreamu možnost, aby se tak dělo jen u změněných souborů?

• ty desitky (spis jednotky GB obrazku se kterymi nebudeme moct nic delat) nam vzniknou za kazdych okolnosti, i kdybychom zadny imaging service neprovozovali - ty desitky webu ktere se nam mnozi je budou potrebovat, a nejhorsi je, v situaci kdy nemame centralni kontrolu za jednotlivymi weby, ze budou pribyvat nejake mrtvoly u kterych nebudeme vedet ze uz neziji, ale nebudeme si moct dovolit neco vycistit. Mozna by to chtelo, dle vzoru wikimedia, sledovat kde vsude nejaky obrazek pouzity, a pravidelne delat nejake cistky.
• moznost provozovat web lokalne neni az tak kriticka, verzi pro lokalni pouziti by nebylo problemem vygenerovat stazenim externich komponent.
• potrebu provadet strojovy crop/resize (nejen pri rebuildu) take zpochybnuji. obzvlast ten crop - sice ty systemy maji nejake prvky umele inteligence, ale kvalitni crop rozhodne neni prace pro stroj, jsou pripady kdy obycejny orez pohybuje na urovni umeleckeho dila :)
  
• klicovym (a jedinym nezbytnym) prvkem imaging service vidim moznost prohlizeni nahledu, vyhledavani, tagovani, kategorizace. nikoliv strojove upravy - ty jen podporuji snizeni kvalifikace grafika/webmastera.

Stanislav Štipl napsal:

Samotný nápad samozřejmě OK, vidím tam následující úskalí:

• uživatelským nahráváním bude vznikat velký objem dat, který bude obtížné řídit (nebude například možné poznat, zda je obrázek někde použit); za nějaký čas budeme mít desítky GB obrázků, se kterými nebudeme moci nic udělat, ale budeme je muset udržovat dostupné forever
• umístění obrázku bude složitější, i když návod vypadá jednoduše, pro uživatele to znamená použít službu navíc
• jak to bude s verzováním souborů? Bude možné obrázek přepsat? Pak se změní všude, může to mít nechtěné vedlejší efekty
• ztratí se možnost provozovat web lokálně (resp. offline), protože obrázky nebudou jeho součástí
• používat git pro binární soubory není ideální, na druhou stranu existuje např. git LFS
• skutečně se to provádí crop/resize každém buildu? není možné nakonfigurovat, případně prosadit do upstreamu možnost, aby se tak dělo jen u změněných souborů?

Ne nutně.

V prvé řadě je potřeba si uvědomit, že udržovat musíme pouze originály fotek. Resizované/cropované verze žijí pouze v NGINX cachi, která dostane nějaký fixní alokovaný prostor (třeba 20 GB) a staré/nepoužívané verze se za pomoci LRU postupně samy odstraňují.

V druhé řadě do hry vstupují user spaces, takže poznáme, co všechno je naživu. Kdykoliv se bude vytvářet např. nový oblastní web, dostane nový user space. Když budeme nějaký web rušit, user space se zase může pohodlně smazat (tj. všechny originály používané tím webem). Dá se to samozřejmě dál optimalizovat monitoringem toho, co se používá a nějak provádět cleanupy (to už by bylo složitější samozřejmě), ale to nevnímám jako prioritu pro první verzi téhle služby.

Andrej Ramašeuski napsal:

• moznost provozovat web lokalne neni az tak kriticka, verzi pro lokalni pouziti by nebylo problemem vygenerovat stazenim externich komponent.

Možnost provozovat web lokálně se nijak nezhoršuje oproti aktuálnímu stavu. Už teď je nutný funkční internet (protože se z googleapis a dalších CDN stahují některé fonty a JS fily -- ne všude ale na velké části webů ano) a nic jiného nutné nebude ani nadále.

• potrebu provadet strojovy crop/resize (nejen pri rebuildu) take zpochybnuji. obzvlast ten crop - sice ty systemy maji nejake prvky umele inteligence, ale kvalitni crop rozhodne neni prace pro stroj, jsou pripady kdy obycejny orez pohybuje na urovni umeleckeho dila :)
  

Dovolím si nesouhlasit. Tohle není služba pro uchovávání obrázků, které tvoří páteř vizuálního stylu dané služby - ty nadále má smysl držet v GITu, protože jako takové jsou součástí technického řešení. Zde se jedná především o fotky k článkům a jednotlivým stránkám, které typicky nepřipravuje grafik nebo designér, nýbrž content editor. Pro takového člověka je auto crop/resize typicky zcela dostačující, speciálně když se zahrne automatická detekce "zajímavé oblasti" pro cropping. Je totiž velmi komplikované na větších webech uhlídat veškeré potřebné formáty a bylo by velmi nepraktické chtít po každém, kdo přidává článek napsaný v markdownu, aby ještě připravoval fotku v pěti různých formátech. Podobný stav je tu teď a je velmi náchylné k chybám a extrémně nepohodlné pro přispěvatele.

• klicovym (a jedinym nezbytnym) prvkem imaging service vidim moznost prohlizeni nahledu, vyhledavani, tagovani, kategorizace. nikoliv strojove upravy - ty jen podporuji snizeni kvalifikace grafika/webmastera.

Tohle naopak já vnímám jako kompetenci jiné služby. Navrhovaná služba se totiž stará právě jen o resize/crop. To co popisuješ ty je nějaký fotokatalog. Což by klidně mohl být ten prvek, kde se drží ty originály. Není to ale nezbytně nutné pro fungování imaging service jako takové.

Stanislav Štipl napsal:

• jak to bude s verzováním souborů? Bude možné obrázek přepsat? Pak se změní všude, může to mít nechtěné vedlejší efekty

Verzování souborů bych vůbec nezaváděl. Chceš jinou verzi fotky? Nahraješ další soubor. Verzování do toho jen vnáší další úroveň komplexity, ale nepřináší žádné zásadní výhody.

• skutečně se to provádí crop/resize každém buildu? není možné nakonfigurovat, případně prosadit do upstreamu možnost, aby se tak dělo jen u změněných souborů?

Nevyjádřil jsem se úplně přesně. jekyll-assets samozřejmě drží vlastní cache a negeneruje všechno znovu. I přesto to ale je problém, protože ten build musí každému proběhnout aspoň jednou a měl jsem i pár problémů, kdy bylo prostě jediné řešení tu cache smazat a pustit to celé načisto. Většinou se to stávalo, když jsem chtěl vyzkoušet production build místo dev buildu. Navíc, jekyll-assets je nepochybně o několik řádů pomalejší než navrhované imaging služby. Doporčuji k přečtení tenhle článek, kde se o asset filech taky mluví: https://mademistakes.com/articles/using-jekyll-2017/. Tohle je problém u webů, které mají hodně fotek a hodně stránek. Dokážu si snadno představit, že úvodní build pirati.cz bude trvat třeba 15 minut na nějakém průměrném železe.

Jen dodám, že jekyll-assets minimálně musí při rebuildu každý file projít a spočítat k němu hash (aby zjistil, jestli to má v cachi). Což sice je mnohem levnější než samotný crop/resize, ale i tak to znamená s větším množstvím fotek čím dál tím větší zpomalení. Tohle při použití imaging service odpadá.

Napadá mě, že jako storage originálů fotek by možná mohl sloužit plánovaný pirátský NextCloud.

Ještě jsem našel, že podobná funkce jde dělat přímo jen pomocí NGINX. Plus samozřejmě nějaká storage někde.

https://www.endpoint.com/blog/2016/05/25/caching-resizing-reverse-proxying-image-server-nginx

Další důvod proč tohle udělat je kvalita, resp. spíš nekvalita jekyll-assets. Je to zabugovaný a má to pár pro nás naprosto nesmyslných závislostí. Alternativně si můžeme napsat nějakej vlastní plugin do jekyllu na resizing. Nic jinýho než jekyll-assets, co by bylo nějak při životě, totiž zdá se neexistuje.

Chápu správně, že se toto vyřešilo pomocí Build serveru a Jekyll Assets ?

mysli si ze se nevyresilo. ale delal bych to az pro zprpovozneni CDN

Nějaký názorový posun v tomto ?

asi by nekdo mel zkusit sepsat navod a rozsirit mezi spravci webu