Wow! Moc pěkně popsaný. po 3. 12. 2018 v 19:46 odesílatel Petr Blahoš <p...@blahos.com> napsal: > >> To je na nějakých desktopech? Na Windows nebo tak něčem? >>> >> Ano. Desktopech, a Windows. Ikdyž to podle mě nedělá rozdíl. >> > > Malinkatý rozdíl např. v nástrojích, které lze nebo je vhodné použít :) >
No, tak z tohoto pohledu je to rozdíl zatraceně velkej. > Jde o aktualizaci programů v noci, nebo se fakt musí řešit nějaké >>> HA/nepřerušený běh? >>> >> V noci nestačí, HA/nepřeušený běh se řešit musí. >> >> >>> >>> Asi znáš věci jako Ansible, Chocolatey... V čem konkrétně nevyhovují? >>> >> >> No, jen tak zběžně znám, ale nedovedu si představit, 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. >> Nebo se v něčem nějak škaredě mýlím? >> >> A nechápejte mě špatně, já to umím udělat, ale říkám si, že pip už řeší >> tu otázku, zda >> tohle je novější verze než tamto, a doufal jsem, že ta jeho funkcionalita >> půjde využít. >> > > 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ý. > Já jsem to na začátku neřekl jasně, Chtěl jsem pouze použít ty funkce pipu, které umí vyextrahovat verzi z názvy souboru, a verze porovnat. Protože to číslování verzí, když uvážíme veškeré bety a rc a různé formáty je zatraceně složitý, takže by bylo lepší použít už existující funkce spíš než to psát, a to i přesto, že ty balíčky, o kterých mluvíme jsou moje, takže to jejich schéma verzování znám, a můžu to postavit přímo na ně. > > ...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. >> > > 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í. > > 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čí :) > > 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. > https://uwsgi-docs.readthedocs.io/en/latest/articles/TheArtOfGracefulReloading.html > Já vám ty linuxy docela závidím. > Jak tuto situaci řeším já (v našem případě pro deployment docker > kontejnerů): > - použil bych config management tool (Ansible, Salt apod.), aby na > cílových strojích udržoval aktuální verzi "deployment skriptu" > - ten deployment skript je pak zároveň i spuštěn přes ten config mgmt tool > - deployment skript se podívá, jestli je k dispozici nová verze; pokud ne, > ukončí se > - 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) > - 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?) > - hotovo :) > > 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 :) > > Ten deployment skript může provádět jednu z mnoha strategií: > - dělat hloupý stop + start > - trochu chytřejší stop + start + check + případný rollback > - ještě trochu chytřejší start (nové verze) + check + switch + stop (staré > verze) (aneb blue-green deployment) > - ještě víc ultimátnější start + check + koordinovaný distribuovaný switch > v celém clusteru + stop > > > 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). > Ano, takhle jsem to od začátku myslel, ovšem jak píšeš, že v ideálním případě by se o to neměl starat ten program, ale tooling okolo, je pravda. 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 > 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ě :) > > 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. > > Např. když si do requirements.txt napíšu " > http://cdn.example.com/foobar-1.0.2-py3-none-any.whl", případně " > https://github.com/foo/bar/archive/v.1.0.2.zip#egg=foobar==1.0.2", 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 > > Díky, Petr
_______________________________________________ Python mailing list python@py.cz http://www.py.cz/mailman/listinfo/python Visit: http://www.py.cz