[python] Je k dispozici novější verze?

Petr Blahoš petr na blahos.com
Úterý Prosinec 4 08:11:51 CET 2018


Wow! Moc pěkně popsaný.

po 3. 12. 2018 v 19:46 odesílatel Petr Blahoš <petr na 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
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://www.py.cz/pipermail/python/attachments/20181204/d4b4fdff/attachment.html>


Další informace o konferenci Python