[Python] distribuire programmi python

[Daniele Varrazzo]

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.

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.

...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). 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.

> 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).

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).


> X win usare portable python potrebbe essere una buona idea?
> Activepython l'avete mai usato?

Portable mai. Activepython più di 10 anni fa; non so cosa cambi 
rispetto al Python originale. Secondo me qualunque cosa non sia 
autocontenuta non è una buona idea.


-- Daniele