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
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
