[Python] distribuire programmi python

Sab 6 Set 2014 07:46:33 CEST

il giorno 06 settembre 2014 04:30, Daniele Varrazzo <piro a develer.com> ha
scritto:

> On 2014-09-06 01:37, Balan Victor wrote:
>
>>
>>> Chef e' potente ma fossi in te userei Ansible. Ha questi vantaggi:
>>>
>>>>
>>>>  mmm ... pricing... mmm free trial ... mmm  in ogni caso mi guardo anche
>>>
>> questo
>>
>
> Il programma e' gratis e open. A pagamento hanno dei servizi di
> centralizzazione, inventari dinamici, cose che neanche ho capito cosa sono
> onestamente.
>
>  - non serve un server sulla macchina remota: basta ssh per usarlo
>>> - non serve conoscere ruby per usarlo (non serve neanche conoscere Python
>>> per usarlo, basta yaml; per Chef invece devi scrivere roba Ruby)
>>> - se ti serve hackarlo, e' scritto in Python, che si suppone tu conosca.
>>>
>>
>> sembra un fabric un po più potente .. o sbaglio?
>>
>
> In un certo senso sì: come fabric si connette via ssh ed esegue comandi.
> Però non è imperativo, ma dichiarativo. Ovvero, tu hai un task che dice
> "sulla macchina deve esserci un utente che si chiama 'pippo' e appartiene
> al gruppo 'devs'. Oppure "deve esserci la directory /foo/bar/baz
> proprietario root e permessi 755". "apache deve essere installato almeno
> versione 2.2" ecc. Tu dichiari cosa vuoi ed ansible fa la differenza.
> Ovvero: va sulla macchina, "l'utente c'è? Stapposto". "La directory c'è? Ha
> permessi 700? Cambio i permessi". "Apache c'è? No? apt-get install..."
> Eccetera. Tu descrivi lo stato finale e il programma si incarica di
> verificare che quello stato sia realizzato, oppure se non c'è fa in modo di
> raggiungerlo.
>
ottima introduzione XD

Fabric invece è puramente imperativo: tu gli dici di eseguire "apt-get
> install apache", poi se questo fa qualcosa oppure niente perché apache c'è
> già non sono fatti di fabric. Ma se fai "useradd" e l'utente c'è già
> probabilmente il comando ti darà un errore che dovrai gestire, e se della
> directory vuoi cambiare i permessi devi gestire tipo due casi diversi: se
> non c'è la devi creare, se c'è devi fare chmod. Certo puoi provare a
> rendere idempotenti anche questi comandi (tipo usando mkdir -p che non dà
> errore se la dir c'è già). Ma in generale se il comando che esegui non è
> idempotente allora devi fare prima un controllo delle precondizioni.
>
> E poi sopra questo c'è tutta la gestione delle variabili e la generazione
> di file di configurazione da template. In effetti ansible lo stiamo
> introducendo su un sistema web piuttosto complicato il cui deploy è evoluto
> con:
>
> 1) si fa tutto a mano (ssh mollybox, git checkout, ah, cazz, qui c'è una
> libreria vecchia, pip install sqlalchemy. No a-ri-cazz, il frontend e il
> backend vogliono due versioni diverse... - voce dall'altra parte
> dell'ufficio: "ehi, come mai molly è giù?")
>
> 2) virtualenv, requirements.txt e fabric. Questo sistema almeno il mondo
> python. L'aggiornamento diventa tipo "fab up", che fa il git pull, pip
> install -U -r requirements, stop, start.
>
> Peccato che mentre facevamo questo al sistema si sono aggiunte un paio di
> istanze di redis, un rabbitmq e pure morbid perchè non ci facciamo mancare
> niente, e poi haproxy e dentro redis ci buttiamo roba fatta con capnproto.
> A coordinare questa roba virtualenv non basta. La macchina era piuttosto
> vecchia e lo sviluppatore che aggiungeva questa roba si doveva compilare
> anche il compilatore per compilare pycapnp e non so che versione di redis
> con dentro un interprete lua... Mi sono distratto un attimo (sono stato via
> dal lavoro qualche mese) e quando sono tornato si era anche scritto un
> sistema per
>
> 3) generare i file di configurazione da template (per qualche motivo gli
> era "cresciuto" mentre nel sistema ci buttava dentro anche supervisord).
> Per fortuna non gli è uscito benissimo e alcuni template hanno bisogno di
> un template di partenza, o qualcosa del genere di cui mi sono perso
> volentieri i dettagli.
>
> Insomma, per fortuna la settimana scorsa è andato in ferie lui, altrimenti
> mi riscriveva ansible dentro molly :) Quando si è distratto un attimo ho
> ansibolato tutto, ovvero a) installazione dei package e preparazione del
> sistema, b) installazione del nostro codice e librerie python c)
> generazione dei file di configurazione. Quindi ora in quei playbook di
> ansible c'è già quasi tutta la "conoscenza" del sistema (quando ha migrato
> la macchina vecchia alla nuova dice che c'ha messo una settimana a
> sistemare tutto, a forza di tentativi ed errori, ovviamente. Io ho fatto
> gli stessi errori, ma almeno quello che ho fatto adesso è ripetibile e in
> 10 minuti parte da una VM vuota a un sistema funzionante). Il sistema di
> template è più completo, per cui riesce a gestire le varie casistiche che
> ci dobbiamo smazzare (per esempio che su una macchina girano 3 istanze
> piccole del sito su 3 ip diversi ma quell'altro sito è grande quindi è
> diviso su tre macchine, frontend, backend, database, con 8 nodi frontend, 2
> backend...) che a coprirle tutte con scriptini fatti a mano un po' gli
> saranno tremate le vene e probabilmente qualche scorciatoia l'ha presa.
>
devi provare dell'oddio verso il tuo collega .. ahahah

> ...dov'eravamo? Ah sì: fabric. Sì, ansible gli somiglia, ma ci devi
> aggiungere sopra la gestione delle variabili e la gestione dei template di
> configurazione, che sono i problemi immediatamente successivi a quelli che
> fabric risolve, e che a volerseli risolvere da sè si finisce col riscrivere
> ansible, ma peggio.
>
>
>  e mi sono gia' fatto mandare affanculo dagli sviluppatori, e tutto in
>>> pochi giorni
>>>
>>
>> ahahahahah :)
>>
>>
>> Tuttavia il mio problema non è il deploy(e mi rendo conto di aver anche
>> sbagliato il titolo). Il programma fa 'autodeploy'(dopo la prima
>> installazione. Per la prima installazione mi potrei arrangiare con fabric
>> x
>> linux e psexec x win). Una volta che il programma è presente sul server
>> remoto potrei renderlo in grado di aggiornare lo stesso python o al limite
>> torno ad arrangiarmi con fabric/psexec.
>>
>
> L'auto-aggiornamento è una tecnica tipica di windows, dove non c'è il
> concetto di qualcuno che si collega da remoto per aggiornare i programmi
> sulla tua macchina (o meglio c'è, ma di solito parla russo e vende pillole
> blu ed altri impianti per far bene l'amore).

io parlo russo, ma non vendo ancora pillole blu ... chissà in un futuro ..
hahahaha

Diciamo che *a te* resta difficile collegarti a windows, non al resto del
> mondo. Su linux, soprattutto sui server non si fa. Certo se queste macchine
> non sono raggiungibili via ssh puoi farci poco, ma con gli eseguibili
> autoaggiornanti non è che hai tutta la libertà di fare cambiamenti che hai
> pushando.

psexec è un ottimo ponte per il mondo windows, però si avvicina più a
fabric che ad ansible quindi dovrei, come dici tu, scrivermi ansible ma
peggio ... allora forse rimanere sugli autoaggiornanti. Poi in ogni caso mi
troverei a gestire due tipi di 'deploy' diversi e questo aggiunge
complessità ...

 Il mio dubbio era più su dove installo python? Io pensavo più a qualcosa
>> del tipo /mio/path o C:\mio\path dove dentro ci sono due directory
>> pythonXX
>> e mioprogramma. E' una buona prassi? potrei avere dei problemi?. Non
>> voglio
>> nemmeno 'inquinare' la variabile PATH.
>>
>
> Su windows dovresti fare un programma auto-contenuto, tipo con
> pyinstaller, in modo da non avere problemi di dipendenze da Python esterni,
> avere due passi di installazione separati ecc. Un eseguibile pyinstaller
> non ha nessuna dipendenza esterna e gira ovunque lo metti. Contiene il
> codice python e se contiene delle dll le salva in una directory temporanea
> e le usa da lì... si fa un discreto mazzo per rendere l'eseguibile
> indipendente e secondo me conviene sfruttarlo (tra l'altro è mantenuto dai
> ragazzi della Develer: un po' di anni fa c'ho messo le mani anche io).
>
proverò anche cosi

> Su *nix compila python installandolo in /usr/local/py34 (./configure
> --prefix=/usr/local/py34 && make && sudo make install) e crea un virtualenv
> che utilizzi quell'eseguibile. Puoi avere diverse versioni di Python e non
> si danno minimamente fastidio (ho tutta la collezione dal 2.4 al 3.4 sul
> portatile e sulle macchine di test).

si effettivamente non c'ho minimamente pensato ...

mai avuto esperienze con python e z/os / mvs ?
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20140906/995d8da1/attachment-0001.html>