Re: [Python] distribuire programmi python
On Sep 6, 2014 8:15 AM, Daniele Varrazzo p...@develer.com wrote: Il programma e' gratis e open. A pagamento hanno dei servizi di centralizzazione, inventari dinamici, cose che neanche ho capito cosa sono onestamente. Daniele, un collega mi ha accennato a Saltstack. Conosci? Qualcun'altro qui? Ciao. Marco. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] distribuire programmi python
On 2014-09-07 17:08, Marco Beri wrote: On Sep 6, 2014 8:15 AM, Daniele Varrazzo p...@develer.com wrote: Il programma e' gratis e open. A pagamento hanno dei servizi di centralizzazione, inventari dinamici, cose che neanche ho capito cosa sono onestamente. Daniele, un collega mi ha accennato a Saltstack. Conosci? Qualcun'altro qui? Io no. Da quanto ho letto implementa grossomodo lo stesso modello di ansible (ovvero senza server remoto, al contrario di chef/puppet). Di default una 0mq invece di ssh come trasporto, che lo rende un po' più veloce ma che ha causato problemi di sicurezza in passato (in ansible è opzionale). Entrambi stanno ricevendo interesse da gente che ha trovato chef/puppet difficili. Esperienza diretta non ne ho. -- Daniele ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] distribuire programmi python
On Sep 7, 2014 10:45 PM, Daniele Varrazzo p...@develer.com wrote: On 2014-09-07 17:08, Marco Beri wrote: Daniele, un collega mi ha accennato a Saltstack. Conosci? Qualcun'altro qui? Io no. Da quanto ho letto implementa grossomodo lo stesso modello di ansible (ovvero senza server remoto, al contrario di chef/puppet). Di default una 0mq invece di ssh come trasporto, che lo rende un po' più veloce ma che ha causato problemi di sicurezza in passato (in ansible è opzionale). Entrambi stanno ricevendo interesse da gente che ha trovato chef/puppet difficili. Esperienza diretta non ne ho. -- Daniele Grazie. Ciao. Marco. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] distribuire programmi python
2014-09-07 19:00 GMT+02:00 Daniele Varrazzo p...@develer.com: Da quanto ho letto implementa grossomodo lo stesso modello di ansible (ovvero senza server remoto, al contrario di chef/puppet). In verità mi pare che sia proprio più simile a chef/puppet che ad ansible, in quanto di default prevede l'installazione di un master e l'installazione di software anche sui minion http://docs.saltstack.com/en/latest/topics/tutorials/quickstart.html#salt-masterless-quickstart è possibile usarlo masterless (proprio come è possible usare chef-solo), ma non è la stessa cosa ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] distribuire programmi python
On 2014-09-06 06:46, Balan Victor wrote: il giorno 06 settembre 2014 04:30, Daniele Varrazzo p...@develer.com ha scritto: devi provare dell'oddio verso il tuo collega .. ahahah Assolutamente no, è un bravissimo ragazzo e una delle persone più pazienti del mondo. Per lui risolvere un bug tipo cambiare l'anno di copyright a fondo pagina oppure stravolgere completamente il sistema sono la stessa cosa. Lo ammiro, io passo sempre per la strada più pigra :) 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 ? Non credo ci trovi niente di più aggiornato di Python 2.4 per questa roba. -- Daniele ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] distribuire programmi python
Il giorno 05/set/2014, alle ore 18:28, enrico franchi enrico.fran...@gmail.com ha scritto: 2014-09-04 23:49 GMT+01:00 Balan Victor balan.vict...@gmail.com: Diciamo cosi', se non hai fatto esplicitamente in modo che sia cosi' e non lo hai provato, ho seri dubbi in proposito. provato con 2.7 e 3.4 Allora, il pacchetto autocontenuto e' molto piu' tipico del mondo windows che del mondo unix. Parliamoci... e' un pacchetto che hai scritto e vuoi distribuire o e' un pacchetto che devi deployare su suddette macchine *di persona*? deployare su server *di persona*, almeno al primo giro. Dal secondo giro in avanti il programma è in grado di auto-aggiornarsi. Il programma non gira su server dedicati quindi non posso pensare di usare roba tipo docker e non voglio nemmeno dipendere dal python installato di default sul sistema. Uhm... poi ovviamente docker non e' che gira su tutta la roba che hai descritto. Chef pero' potresti usarlo... Dal momento che mi sono totalmente 'innamorato' di docker mi potreste dire che tipo di controindicazioni ci vedete ? Grazie :) G ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] distribuire programmi python
On 2014-09-06 12:01, Giovanni Porcari wrote: Il programma non gira su server dedicati quindi non posso pensare di usare roba tipo docker e non voglio nemmeno dipendere dal python installato di default sul sistema. Uhm... poi ovviamente docker non e' che gira su tutta la roba che hai descritto. Chef pero' potresti usarlo... Dal momento che mi sono totalmente 'innamorato' di docker mi potreste dire che tipo di controindicazioni ci vedete ? Penso solo questo: On 2014-09-04 13:51, Balan Victor wrote: Ciao a tutti, ho un programma scritto in python che devo far girare su server linux/aix/hp-ux/unix/solaris e windows. Docker gira solo su Linux moderni. Victor insiste che il suo programma scritto in Py 3.4 deve girare anche sul VIC20... -- Daniele ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] distribuire programmi python
Il giorno 05/set/2014, alle ore 18:28, enrico franchi enrico.fran...@gmail.com ha scritto: 2014-09-04 23:49 GMT+01:00 Balan Victor balan.vict...@gmail.com: Diciamo cosi', se non hai fatto esplicitamente in modo che sia cosi' e non lo hai provato, ho seri dubbi in proposito. provato con 2.7 e 3.4 Allora, il pacchetto autocontenuto e' molto piu' tipico del mondo windows che del mondo unix. Parliamoci... e' un pacchetto che hai scritto e vuoi distribuire o e' un pacchetto che devi deployare su suddette macchine *di persona*? deployare su server *di persona*, almeno al primo giro. Dal secondo giro in avanti il programma è in grado di auto-aggiornarsi. Il programma non gira su server dedicati quindi non posso pensare di usare roba tipo docker e non voglio nemmeno dipendere dal python installato di default sul sistema. Uhm... poi ovviamente docker non e' che gira su tutta la roba che hai descritto. Chef pero' potresti usarlo... Dal momento che mi sono totalmente 'innamorato' di docker mi potreste dire che tipo di controindicazioni ci vedete ? Per quello che posso dirti e' sempre tutto una scuola di pensiero: parlo con un devops e si esalta per docker, lxc e compagnia bella, parlo con un sysadmin o un esperto di distro e gli vengono i brividi freddi. E il bello e' che succede anche il contrario :) Ammetto che il problema delle dipendenze nel mondo UNIX e' da sempre una rottura di scatole (ma questo e' spesso colpa degli sviluppatori che non si curano di chi dovra' usare i loro prodotti, vedi rant di Linus sulle shared libraries), ma dall'altro lato la deduplicazione di file, librerie e binari di sistema che si portano dietro questi sistemi richiedono una grande responsabilita' (qualita' che spesso si costruisce in anni di esperienza da sysadmin e non a colpi di tool 'fashion'). La stessa cosa ad esempio succede con Go, il fatto che sia tutto compilato staticamente (almeno per ora) fa storcere il naso a parecchi... Chi ha ragione ? Boh :) Per come la vedo io il mondo dei container e' una cosa che non si puo' ignorare, e sono contento che Docker abbia avuto successo perche' ha fatto uscire dalle caverne una sfilza di sysadmin intrappolati negli anni 70 convinti che il paradigma UNIX sia perfetto cosi' (ma vaff...) Basta solo ricordarsi che gli aggiornamenti di sicurezza vanno fatti, e vanno fatti per sempre (e se il cliente non vuole pagare per questo servizio NECESSARIO e' meglio che vi firmi qualche bella cartaccia dall'avvocato) -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] distribuire programmi python
Dal momento che mi sono totalmente 'innamorato' di docker mi potreste dire che tipo di controindicazioni ci vedete ? Per quello che posso dirti e' sempre tutto una scuola di pensiero: parlo con un devops e si esalta per docker, lxc e compagnia bella, parlo con un sysadmin o un esperto di distro e gli vengono i brividi freddi. E il bello e' che succede anche il contrario :) Ammetto che il problema delle dipendenze nel mondo UNIX e' da sempre una rottura di scatole (ma questo e' spesso colpa degli sviluppatori che non si curano di chi dovra' usare i loro prodotti, vedi rant di Linus sulle shared libraries), ma dall'altro lato la deduplicazione di file, librerie scusate qui intendevo duplicazione :) -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] distribuire programmi python
Il giorno 06 settembre 2014 13:33, Daniele Varrazzo p...@develer.com ha scritto: On 2014-09-06 12:01, Giovanni Porcari wrote: Dal momento che mi sono totalmente 'innamorato' di docker mi potreste dire che tipo di controindicazioni ci vedete ? Penso solo questo: On 2014-09-04 13:51, Balan Victor wrote: Ciao a tutti, ho un programma scritto in python che devo far girare su server linux/aix/hp-ux/unix/solaris e windows. Docker gira solo su Linux moderni. Victor insiste che il suo programma scritto in Py 3.4 deve girare anche sul VIC20... ahahah ... in realtà mi accontento solo di win e linux tutte le altre piattaforme sono un 'di più' che non fa male ma che se c'è bene se non c'è amen Per come la vedo io il mondo dei container e' una cosa che non si puo' ignorare, e sono contento che Docker abbia avuto successo perche' ha fatto uscire dalle caverne una sfilza di sysadmin intrappolati negli anni 70 convinti che il paradigma UNIX sia perfetto cosi' (ma vaff...) come ho scritto qualche mail sopra il programma deve girare su server dedicati ad altre applicazioni(raccoglie metriche e fa 'query') quindi non posso isolare il programma, e poi almeno la metà dei server è win. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] distribuire programmi python
On 2014-09-06 14:27, Balan Victor wrote: Docker gira solo su Linux moderni. Victor insiste che il suo programma scritto in Py 3.4 deve girare anche sul VIC20... ahahah ... in realtà mi accontento solo di win e linux tutte le altre piattaforme sono un 'di più' che non fa male ma che se c'è bene se non c'è amen Fa male. -- Daniele ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] distribuire programmi python
On 2014-09-06 12:36, Roberto De Ioris wrote: Ammetto che il problema delle dipendenze nel mondo UNIX e' da sempre una rottura di scatole (ma questo e' spesso colpa degli sviluppatori che non si curano di chi dovra' usare i loro prodotti, vedi rant di Linus sulle shared libraries) Link or it didn't happen :) Eh hai ragione, ma mica mi ricordo che intervista era :) Il succo era che si lamentava del fatto che molti sviluppatori di librerie non si curassero di rompere le ABI (non le API) complicando la vita a molti utilizzatori. Me lo ricordo perche' prima di sentirlo non mi ero mai curato di rompere le ABI :) -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] distribuire programmi python
Appoggio anch'io Ansible. Io ed un mio amico fra l'altro ci siamo creati dei playbook per configurare i nostri stessi desktop. Ed anch'io sono dell'idea che la leadership di Ansible sia poco illuminata. Il mio pet peeve è il loro setup.py, che è rotto (python setup.py install fallisce in alcuni contesti) in quanto usano delle feature di setuptools nel setup.py, ma si ostinano ad usare distutils... fra le conseguenze, `setup.py develop` non funziona ma a loro non gliene interessa e rifiutano le PR, tanto hanno il loro hacking/env_setup script... perchè fare le cose nel modo corretto che supporta il workflow di tutti gli altri, quando possiamo riscrivere il codice del setup, in una versione monca? https://github.com/ansible/ansible/pull/3829 2014-09-06 15:48 GMT+02:00 Roberto De Ioris robe...@unbit.it: On 2014-09-06 12:36, Roberto De Ioris wrote: Ammetto che il problema delle dipendenze nel mondo UNIX e' da sempre una rottura di scatole (ma questo e' spesso colpa degli sviluppatori che non si curano di chi dovra' usare i loro prodotti, vedi rant di Linus sulle shared libraries) Link or it didn't happen :) Eh hai ragione, ma mica mi ricordo che intervista era :) Non era uno di questi 2 thread? https://lkml.org/lkml/2012/9/30/108 https://gcc.gnu.org/ml/gcc/2001-02/msg00898.html ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] distribuire programmi python
2014-09-04 23:49 GMT+01:00 Balan Victor balan.vict...@gmail.com: Diciamo cosi', se non hai fatto esplicitamente in modo che sia cosi' e non lo hai provato, ho seri dubbi in proposito. provato con 2.7 e 3.4 Allora, il pacchetto autocontenuto e' molto piu' tipico del mondo windows che del mondo unix. Parliamoci... e' un pacchetto che hai scritto e vuoi distribuire o e' un pacchetto che devi deployare su suddette macchine *di persona*? deployare su server *di persona*, almeno al primo giro. Dal secondo giro in avanti il programma è in grado di auto-aggiornarsi. Il programma non gira su server dedicati quindi non posso pensare di usare roba tipo docker e non voglio nemmeno dipendere dal python installato di default sul sistema. Uhm... poi ovviamente docker non e' che gira su tutta la roba che hai descritto. Chef pero' potresti usarlo... Sono anche nervosetto all'idea dell'auto-aggiornamento. Specie perche' dubito che faccia tutto quello che deve (e.g., avere metriche che allarmano e fanno rollback della nuova versione in automatico... genericamente un sistema del genere ha bisogno di un po' di infrastruttura non banale che se avessi probabilmente risolverebbe anche il problema del deploy). Non dipendere dal python di default e' ovviamente saggio. Boh... se non avessi windows fra le scatole ti suggerirei veramente qualcosa di chef/puppet based che si succhia in qualche modo il python (eventualmente compilandoselo) e poi fa tutto quanto il resto. Non ho idea di come fare su windows. Te lo ho gia' detto che con windows non ci tratto? ;) -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] distribuire programmi python
Uhm... poi ovviamente docker non e' che gira su tutta la roba che hai descritto. Chef pero' potresti usarlo... si lo so. Chef non lo conoscevo, adesso mi sto guardano un po di documentazione Sono anche nervosetto all'idea dell'auto-aggiornamento. Specie perche' dubito che faccia tutto quello che deve (e.g., avere metriche che allarmano e fanno rollback della nuova versione in automatico... genericamente un sistema del genere ha bisogno di un po' di infrastruttura non banale che se avessi probabilmente risolverebbe anche il problema del deploy). L'infrastruttura c'è già. Il programma in fase di starup si connette a un server dedicato che fa da repository/configurator da cui scarica la configurazione da usare, nella configurazione è contenuta anche la versione del sorgente. Una volta che il programma ha la configurazione confronta la versione sul repository con quella locale e se non corrispondono scarica il nuovo sorgente lo sostituisce con quello attuale e poi si auto-restarta. Quindi il problema di aggiornare gli sorgenti non c'è l'ho. Ho il problema di aggiornare python. Avevo pensato di fare in pasto anche la gestione della versione di python al programma però mi troverei di fronte a compilazioni di sorgenti su mondo linux/unix e silent installer su mondo windows ... Non dipendere dal python di default e' ovviamente saggio. Boh... se non avessi windows fra le scatole ti suggerirei veramente qualcosa di chef/puppet based che si succhia in qualche modo il python (eventualmente compilandoselo) e poi fa tutto quanto il resto. Non ho idea di come fare su windows. Te lo ho gia' detto che con windows non ci tratto? ;) come scritto sopra mi sto studiando un po chef per quello che riguarda windows avevo pensato anche a qualcosa come portable python, ma non sono molto convinto. -- Balan Victor ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] distribuire programmi python
On 2014-09-05 18:14, Balan Victor wrote: Uhm... poi ovviamente docker non e' che gira su tutta la roba che hai descritto. Chef pero' potresti usarlo... si lo so. Chef non lo conoscevo, adesso mi sto guardano un po di documentazione Chef e' potente ma fossi in te userei Ansible. Ha questi vantaggi: - 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. Io ci ho passato le ultime due settimane e sono state positive. Ci ho fatto in breve tempo cose piuttosto complesse, per risolvere alcuni problemi mi sono scritto un modulo di estensione mio (e un altro l'ho cherry-pickato dalla prossima versione ancora da rilasciare). Ho mandato patch upstream e mi sono gia' fatto mandare affanculo dagli sviluppatori, e tutto in pochi giorni! Come detto sopra non serve essere uno sviluppatore per usarlo perche' hai solo da scrivere file umani con la descrizione dei passi da fare. Se poi dovesse essere necessario mettere le mani dentro al motore, meglio Python che Ruby (tra l'altro e' scritto in maniera abbastanza semplice). -- Daniele ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] distribuire programmi python
On 2014-09-05 19:04, Francesco Pischedda wrote: Il giorno 05 settembre 2014 20:01, Daniele Varrazzo p...@develer.com ha scritto: Ho mandato patch upstream e mi sono gia' fatto mandare affanculo dagli sviluppatori, e tutto in pochi giorni! LOLissimo! :D molto OT: a quanto sento non sei il primo che si lamenta dell'accoglienza degli sviluppatori di ansible però il progetto è veramente valido A mio avviso hanno fatto una cappellata con la priorita' delle variabili, ma ora e' troppo tardi per tornare indietro perche' ormai ci sono ettolitri di script che fanno affidamento sul comportamento attuale. Il problema e' che loro non dicono si' abbiamo cappellato ma ormai e' cosi', che sarebbe giustificabilissimo. Loro dicono come vuoi fare tu non e' idiomatico. Insomma sbaglio io. Ok, ci puo' anche stare. Pero' googlando vedo che il problema ce l'hanno in molti. Quello che non puoi fare in ansible e' qualcosa tipo (scusate l'ansiblese per chi non lo mastica): - un role webserver definisce un default, tipo http_port = 80 - un role firewall deve poter accedere alla variabile per aprire quella porta - in un inventory vorrei avere la possibilita' di sovrascrivere questo default, ad esempio sull'installazione di test avere http_port=8080. Questo non posso farlo: se usassi include_vars nel firewall la variabile diventa troppo potente e l'inventory non puo' sovrascriverla (un default puo' essere sovrascritto invece). Se introduco una dipendenza esplicita tra i ruoli il webserver mi viene installato anche sulla macchina del firewall, che puo' essere diversa. La mia soluzione e' stata di aggiungere un comando include_defaults che funzioni come include_vars ma con le variabili overridabili. Il comportamento di ansible non cambia e se uno script non usa include_defaults tutto resta come prima. La loro risposta e' che i default condivisi vanno scritti invece... in un file globale (tipo group_vars/all). E che la nuova regola sottoporrebbe gli utenti ad un carico cognitivo eccessivo. Wat™? Insomma nei doc scrivono le variabili di inventory sono potentissime ed e' falso, puoi solo overridarci i default, se una cosa la tiri dentro con include_vars diventa semi-immortale. Dicono i role sono un modo di rendere modulare un playbook e poi ti serve un file globale per passare un default tra due role... A me sembra il caso di invocare Upton Sinclair (it is difficult to get a man to understand something, when his salary depends upon his not understanding it) e tirare avanti. Per fortuna tirare avanti si fa bene, perche' anche se non hanno accettato il nuovo comando upstream e' possibile metterlo nel proprio playbook e Ansible lo usa senza dar fastidio a nessuno. Il che mi sembra grandioso. A chi interessa include_defaults e' disponibile a https://gist.github.com/dvarrazzo/7418a89b7278ff69267c. Quindi si', confermo l'impressione: gli sviluppatori di Ansible sono *molto* opinionati. Ma il progetto e' veramente ben fatto. -- Daniele ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] distribuire programmi python
Il giorno 05 settembre 2014 20:34, Daniele Varrazzo p...@develer.com ha scritto: A chi interessa include_defaults e' disponibile a https://gist.github.com/dvarrazzo/7418a89b7278ff69267c. ti ringrazio per l'analisi del problema e per aver condiviso con noi la soluzione, sono sicuro che mi sarà utile in futuro -- Shipping is a feature. A really important feature. Your product must have it. Rendete ogni cosa il più semplice possibile, ma non di più (Albert Einstein) You are what you choose today, not what you've chosen before Unix IS user friendly. It's just selective about who its friend are ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] distribuire programmi python
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 - 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? 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. 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. X win usare portable python potrebbe essere una buona idea? Activepython l'avete mai usato? -- Balan Victor ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] distribuire programmi python
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
Re: [Python] distribuire programmi python
2014-09-04 13:51 GMT+01:00 Balan Victor balan.vict...@gmail.com: ho un programma scritto in python che devo far girare su server linux/aix/hp-ux/unix/solaris e windows. Il programma è scritto per python 3.4 ma dovrebbe funzionare con tutte le altre versioni precedenti. Diciamo cosi', se non hai fatto esplicitamente in modo che sia cosi' e non lo hai provato, ho seri dubbi in proposito. Qual'è il miglior modo di farlo girare su tutti questi sistemi ? Usare tool come py2exe, pyinstaller o simili? Installare python su ogni sistema e poi far girare il programma(/path/to/python mioprogramma.py) ? Usare ActivePython? Allora, il pacchetto autocontenuto e' molto piu' tipico del mondo windows che del mondo unix. Parliamoci... e' un pacchetto che hai scritto e vuoi distribuire o e' un pacchetto che devi deployare su suddette macchine *di persona*? Poi sul discorso deploy si dovrebbe aprire un lungo discorso (puppet/chef + docker convocati...). Se invece hai scritto il tuo pacchetto e vuoi che altri lo usino: - pip e' probabilmente la cosa piu' comoda. Se non hai codice compilato fra le scatole. - La gente di Unix si aspetta il sorgente, verosimilmente pip, e se proprio vuoi strafare pacchetti per alcune distribuzioni (che e' comunque non inusuale che se prende trazione qualcuno li faccia per te) - La gente di Windows... boh. Immagino che se sono sviluppatori o sistemisti siano contenti con pip. Se no direi che *a loro* interessa un qualche installer. Ma non ti so dire, non ci tratto. Qualcuno ha mai dovuto distribuire programmi python su ambienti diversi? Come avete fatto ? Io pero' non tratto con Windows, come dicevo. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] distribuire programmi python
Diciamo cosi', se non hai fatto esplicitamente in modo che sia cosi' e non lo hai provato, ho seri dubbi in proposito. provato con 2.7 e 3.4 Allora, il pacchetto autocontenuto e' molto piu' tipico del mondo windows che del mondo unix. Parliamoci... e' un pacchetto che hai scritto e vuoi distribuire o e' un pacchetto che devi deployare su suddette macchine *di persona*? deployare su server *di persona*, almeno al primo giro. Dal secondo giro in avanti il programma è in grado di auto-aggiornarsi. Il programma non gira su server dedicati quindi non posso pensare di usare roba tipo docker e non voglio nemmeno dipendere dal python installato di default sul sistema. -- Balan Victor ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
