<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">il giorno 06 settembre 2014 04:30, Daniele Varrazzo <span dir="ltr"><<a href="mailto:piro@develer.com" target="_blank">piro@develer.com</a>></span> ha scritto:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 2014-09-06 01:37, Balan Victor wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Chef e' potente ma fossi in te userei Ansible. Ha questi vantaggi:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
</blockquote>
mmm ... pricing... mmm free trial ... mmm  in ogni caso mi guardo anche<br>
</blockquote>
questo<br>
</blockquote>
<br></span>
Il programma e' gratis e open. A pagamento hanno dei servizi di centralizzazione, inventari dinamici, cose che neanche ho capito cosa sono onestamente.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
- non serve un server sulla macchina remota: basta ssh per usarlo<br>
- non serve conoscere ruby per usarlo (non serve neanche conoscere Python<br>
per usarlo, basta yaml; per Chef invece devi scrivere roba Ruby)<br>
- se ti serve hackarlo, e' scritto in Python, che si suppone tu conosca.<br>
</blockquote>
<br>
sembra un fabric un po più potente .. o sbaglio?<br>
</blockquote>
<br></span>
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.<br></blockquote><div>ottima introduzione XD</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.<br>
<br>
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:<br>
<br>
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ù?")<br>
<br>
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.<br>
<br>
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<br>
<br>
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.<br>
<br>
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.<br></blockquote><div>devi provare dell'oddio verso il tuo collega .. ahahah  </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
...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.<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
e mi sono gia' fatto mandare affanculo dagli sviluppatori, e tutto in<br>
pochi giorni<br>
</blockquote>
<br>
ahahahahah :)<br>
<br>
<br>
Tuttavia il mio problema non è il deploy(e mi rendo conto di aver anche<br>
sbagliato il titolo). Il programma fa 'autodeploy'(dopo la prima<br>
installazione. Per la prima installazione mi potrei arrangiare con fabric x<br>
linux e psexec x win). Una volta che il programma è presente sul server<br>
remoto potrei renderlo in grado di aggiornare lo stesso python o al limite<br>
torno ad arrangiarmi con fabric/psexec.<br>
</blockquote>
<br></span>
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). </blockquote><div>io parlo russo, ma non vendo ancora pillole blu ... chissà in un futuro .. hahahaha</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.</blockquote><div>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à ...</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Il mio dubbio era più su dove installo python? Io pensavo più a qualcosa<br>
del tipo /mio/path o C:\mio\path dove dentro ci sono due directory pythonXX<br>
e mioprogramma. E' una buona prassi? potrei avere dei problemi?. Non voglio<br>
nemmeno 'inquinare' la variabile PATH.<br>
</blockquote>
<br></span>
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).<br></blockquote><div>proverò anche cosi</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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).</blockquote><div>si effettivamente non c'ho minimamente pensato ... </div><div><br></div><div>mai avuto esperienze con python e z/os / mvs ?</div><div><br></div><div><br></div></div>
</div></div>