<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">po 3. 12. 2018 v 19:46 odesílatel Petr Blahoš <<a href="mailto:petr@blahos.com">petr@blahos.com</a>> napsal:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>To je na nějakých desktopech? Na Windows nebo tak něčem? </div></div></blockquote><div>Ano. Desktopech, a Windows. Ikdyž to podle mě nedělá rozdíl.</div></div></div></blockquote><div><br></div><div>Malinkatý rozdíl např. v nástrojích, které lze nebo je vhodné použít :)</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Jde o aktualizaci programů v noci, nebo se fakt musí řešit nějaké HA/nepřerušený běh?</div></div></blockquote><div>V noci nestačí, HA/nepřeušený běh se řešit musí.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Asi znáš věci jako Ansible, Chocolatey... V čem konkrétně nevyhovují?</div></div></blockquote><div><br></div><div>No, jen tak zběžně znám, ale nedovedu si představit, jak konkrétně zrovna tohle</div><div>udělat. Já totiž neřeším problém jak na tu stanici něco dostat nebo jak tam něco </div><div>spustit, ale jak co nejjednoduššeji v tom běžícím program poznat, že se má ukončit.</div><div>Nebo se v něčem nějak škaredě mýlím?</div><div><br></div><div>A nechápejte mě špatně, já to umím udělat, ale říkám si, že pip už řeší tu otázku, zda</div><div>tohle je novější verze než tamto, a doufal jsem, že ta jeho funkcionalita půjde využít.</div></div></div></blockquote><div><br></div><div>Pip je package manager. Ty řešíš nějaký řekněme deployment. Takže v tom cítím jistou impedanci :) Pravděpodobně by spíš řešení, které bys chtěl, mohlo někde uvnitř obsahovat pip, než aby to řešil pip samotný.<br></div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>...jak konkrétně zrovna tohle udělat. Já totiž neřeším problém jak na tu stanici něco dostat nebo jak tam něco spustit, ale jak co nejjednoduššeji v tom běžícím program poznat, že se má ukončit.</div></div></blockquote><div><br></div><div>Takže to, jak to na tu stanici dostat, už máš vyřešené? Výborně :) Tak stačí poslat tomu běžícímu procesu SIGTERM, což je standardní cesta, jak nějakému procesu naznačit, že je očekáván jeho graceful shutdown. Ten nový proces lze spustit nějak automaticky nějakým process managementem (na Linuxu systemd, na Windows taky něco bude), nebo ten nový proces lze spustit rovnou a sdělit mu PID toho původního procesu, aby mohl počkat na jeho skončení. </div><div><br></div><div>Nad tímhle bych doporučoval zamyslet se - aby to všechno neřešil dotyčný program, ale spíš tooling okolo a ten dotyčný program by měl umět jenom dvě věci - tu věc, kterou dělá, a korektně se ukončit na příkaz zvenčí :)</div><div><br></div><div>Restart procesu lze řešit i včetně předání resourců (naslouchajícího socketu apod.) nastávajícímu procesu, dělá to např. uwsgi. Ale je to hodně pokročilé a asi to sem nepatří, jen jsem chtěl napsat, že to jde. Řešit toto takhle do hloubky není úplně jednoduchá problematika. <a href="https://uwsgi-docs.readthedocs.io/en/latest/articles/TheArtOfGracefulReloading.html">https://uwsgi-docs.readthedocs.io/en/latest/articles/TheArtOfGracefulReloading.html</a></div><div><br></div><div>Jak tuto situaci řeším já (v našem případě pro deployment docker kontejnerů):</div><div>- použil bych config management tool (Ansible, Salt apod.), aby na cílových strojích udržoval aktuální verzi "deployment skriptu"</div><div>- ten deployment skript je pak zároveň i spuštěn přes ten config mgmt tool</div><div>- deployment skript se podívá, jestli je k dispozici nová verze; pokud ne, ukončí se</div><div>- deployment skript stáhne novou verzi (v našem případě docker registry, ale může to být cokoliv, včetně FTP, S3, nebo se to tam dá natlačit opět tím Ansiblem)</div><div>- deployment skript ukončí předchozí instanci (starou verzi) a spustí novou instanci z nové verze (v našem případě jde o docker kontejnery, ve tvém asi půjde o procesy, nebo nějaké windows services?)</div><div>- hotovo :)</div><div><br></div><div>Mimochodem, zrovna management dockeru zvládají config management tooly (Salt, Ansible) samy o sobě, ale postupem času se mi nastřádaly důvody, proč jsem si to chtěl napsat sám. To už je nad rámec této diskuze :)</div><div><br></div><div>Ten deployment skript může provádět jednu z mnoha strategií:</div><div>- dělat hloupý stop + start</div><div>- trochu chytřejší stop + start + check + případný rollback</div><div>- ještě trochu chytřejší start (nové verze) + check + switch + stop (staré verze) (aneb blue-green deployment)</div><div>- ještě víc ultimátnější start + check + koordinovaný distribuovaný switch v celém clusteru + stop</div><div><br></div><div><br></div><div>Jestli se nějakým "deployment skriptem" vůbec nechceš zabývat, tak si do toho programu udělej jednoduché ukončení sebe sama, pokud se na určitém místě na disku objeví nová verze tohoto programu. No a prostě dostaň na disk novou verzi toho programu. Ale můj point tady je, že v ideálním případě by se o to neměl starat ten program, ale tooling okolo (to je ten deployment skript).</div><div><br></div><div><br></div><div>Docela už jsme se dostali dost daleko od původní otázky "Existuje nějaké API, které je schopné říct mi, jaká je aktuální nainstalovaná verze</div><div>balíčku, a jestli verze na vzdáleném úložišti je novější?", ale přijde mi, že ta původní otázka moc nereflektovala skutečný původní problém. Nebo respektive API, které je schopné ti říct, zda je na vzdáleném úložišti novější balíček, by jaksi mělo poskytovat to vzdálené úložiště, tak se podívej do jeho dokumentace :) Nebo aspoň do zdrojového kódu klienta toho vzdáleného úložiště :)</div><div><br></div><div>Verzi sebe sama by měl program znát. Nebo použiješ např. pip freeze. Verzi .whl souboru by mělo jít získat z názvu toho souboru, myslím, že je toto dokonce i standardizované, ale nejsem si jistý. Nebo používej nějaký pomocný soubor s číslem verze.</div><div><br></div><div>Např. když si do requirements.txt napíšu "<a href="http://cdn.example.com/foobar-1.0.2-py3-none-any.whl">http://cdn.example.com/foobar-1.0.2-py3-none-any.whl</a>", případně "<a href="https://github.com/foo/bar/archive/v.1.0.2.zip#egg=foobar==1.0.2">https://github.com/foo/bar/archive/v.1.0.2.zip#egg=foobar==1.0.2</a>", tak pip z toho dokáže tu verzi odvodit a když znovu spustím "pip install -r requirements.txt", tak už podruhé nic nestahuje. Tak něco podobného můžeš použít</div><div><br></div></div><div>Petr Messner</div></div></div></div></div></div>