Come distribuire un progetto con tutte le sue dipendenze?

0

Stiamo sviluppando un sistema per un cliente che non vuole consentire l'installazione di pacchetti da repository esterni. Il progetto è in Python e definisce le sue dipendenze tramite setuptools ; la maggior parte di queste dipendenze si trova su PyPI e altre sono reperibili nel repository della nostra azienda. Alcuni di essi richiedono la presenza di librerie di sistema (ad esempio libevent per gevent ). Nessuno di questi può essere installato (come download diretto dal repository) nei server del cliente.

Al momento, stiamo impacchettando il progetto, le sue dipendenze e in modo ricorsivo tutte le dipendenze delle sue dipendenze, in RPM, che raggruppiamo in un unico tarball di distribuzione. Questa operazione richiede molto tempo ed è soggetta a errori. Inoltre, non abbiamo realmente bisogno del controllo delle versioni, dal momento che il progetto è un servizio e il codice cliente non può scegliere quale versione del servizio con cui parla. Dovremmo solo spedire l'ultima versione una volta che sappiamo che è stabile.

L'alternativa principale che ho preso in considerazione è buildout : crea il progetto in una macchina di gestione temporanea con lo stesso sistema operativo e interprete come macchina di produzione, quindi tar l'intera directory e copia nella macchina di produzione. Ma non sono sicuro che questo sarebbe davvero un miglioramento rispetto all'attuale metodo di distribuzione.

Quali altre opzioni ci sono? Quale è stato usato con successo? C'è qualche tipo di best practice per la comunità qui?

    
posta logc 17.02.2016 - 16:26
fonte

1 risposta

0

Esistono due principali approcci alla distribuzione delle applicazioni:

  • Isolare dal sistema / Sandboxing

    Il più possibile è raggruppato, le API di sistema possono essere collegate e reindirizzate nella sandbox. L'app è installata nella propria gerarchia di directory separata. In UNIX, /opt è per questo.

    Pro:

    • Dipendenza minima sull'ambiente host e viceversa, è sufficiente testare l'interfaccia esterna in più ambienti (e nemmeno se è fornita da una terza parte che dovrebbe farlo per te).

    Contro:

    • Non è possibile sfruttare i componenti di sistema e gli aggiornamenti, devono duplicare e gestire autonomamente tutti i componenti di terze parti
      • questo include cose come account utente, vari tipi di dati e sicurezza, compatibilità automatica con altre app
    • È necessario aggiornare l'app nel suo complesso, indipendentemente dalla quantità di modifiche, o scrivere il proprio gestore di pacchetti privato
    • Gli strumenti per testare e eseguire il debug di applicazioni in modalità sandbox sono quasi inesistenti, soprattutto per gli strumenti di virtualizzazione = > difficile testare il risultato finale e diagnosticare i problemi dei clienti
  • Integrazione nel sistema

    L'app utilizza il gestore di pacchetti del sistema e risiede nella gerarchia di directory standard.

    Pro:

    • Devi solo gestire il codice personalizzato dell'app e affidarti alle dipendenze fornite dal sistema per il resto
    • Può riutilizzare le strutture del sistema e ottenere funzionalità secondarie gratuite da quelle incluse gli aggiornamenti di sicurezza e stabilità e l'installazione / aggiornamento stesso
    • Può sviluppare e aggiornare i componenti in modo indipendente

    Contro:

    • Potenziale inferenza di dipendenza, le interfacce devono essere chiaramente definite e testate per l'integrazione, potenzialmente per tutte le combinazioni dichiarate compatibili (per una data interfaccia, quindi nessuna esplosione combinatoria ma potrebbe essere ancora abbastanza).
    • L'app assomiglia a diversi pacchetti per l'utente, può confondere ciò che è tuo e ciò che è fornito dal sistema e / o confuso da installare / gestire. Sinceramente se il gestore dei pacchetti di sistema non esegue il controllo delle dipendenze.
    • Un sacco di possibili ambienti e / o ambienti supportati sono limitati a quelli che hanno le strutture necessarie.
      • I moduli di terze parti e gli aggiornamenti su di essi possono causare problemi imprevisti, devono essere in grado di diagnosticarli (simboli /sorgenti / debug). Ciò include cose come la deprecazione delle interfacce che stai utilizzando.

Pertanto, le app del primo tipo tendono ad essere utilizzate quando l'ambiente è percepito come "ostile" (imprevedibile / inaffidabile / non collaborativo), e il cliente sta bene pagando i costi aggiuntivi (sia per te che per loro) di lavorando in uno e / o con la tua app altrettanto non cooperativa.

    
risposta data 29.05.2018 - 01:28
fonte

Leggi altre domande sui tag