il giorno 06 settembre 2014 04:30, Daniele Varrazzo <p...@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 ?
_______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python