Qual è un buon approccio devops per un singolo sviluppatore che scrive applicazioni Web Python?

Immagino che questa domanda sembrerà incredibilmente banale per alcuni lettori, ma come qualcuno che è uno sviluppatore ma con poca esperienza di distribuzione di app in qualcosa di diverso da un manuale, colpisci e spero in un certo senso, spero che capirai che è piuttosto scoraggiante vedere il numero di approcci e strumenti diversi che ci sono, quindi potrei fare con un po 'di consigli per farmi iniziare nella giusta direzione.

Sono uno sviluppatore, ora solo nel mio tempo libero, che è limitato. Fino ad ora ho lavorato con Java, costruendo webapp e sono stato ragionevolmente felice di distribuire un file di guerra in un ambiente Tomcat che mantiene le cose ben incapsulate.

Ora sto lavorando in Python e Django, ma man mano che mi avvicino al punto in cui devo implementare, voglio impostare un flusso di lavoro devops solido per automatizzare il più possibile e assicurarmi di poterlo implementare in modo affidabile, ma dato che il mio il caso d'uso è relativamente semplice, voglio evitare di imparare un set di strumenti di grandi dimensioni che è troppo ingegnerizzato per le mie esigenze e che richiede un grande investimento di tempo, preferirei usare la codifica della mia app.

Quindi sto cercando una via di mezzo che mi consenta di distribuire e gestire in modo affidabile le mie app senza investire molto tempo nell'impostazione e nell'apprendimento di un grande ecosistema Devops.

Qualche dettaglio in più ...

Contesto

1. Sviluppo su un Mac, usando PyCharm per creare Django 2, Python 3.
2. Uso git (ma non su github) per gestire il controllo delle versioni del software.
3. Sono a mio agio con altre lingue e linguaggi di scripting e ho scritto alcuni script bash (probabilmente abbastanza amatoriali), anche se non mi piace bash. Mi sono anche dilettato con Perl, che mi sono reso conto che in realtà non è una lingua per dilettarsi (cioè devi passare del tempo ad impararlo correttamente)
4. Ho intenzione di distribuire su un ambiente VPS, probabilmente DigitalOcean.
5. La mia app non è mission-critical, ma è importante che io sappia se il sito non funziona e, in caso affermativo, devo avere un modo per ripristinare in modo affidabile, sia che si tratti di riavviare l'app, riavviare il server o passare a un altro server ( o altro).

Requisiti specifici

1. Possibilità di configurare un nuovo ambiente per ricevere l'app.

   Fino ad ora, mentre sto imparando, questo è stato manuale e ogni volta che l'ho fatto ho iniziato da zero con un nuovo Droplet. Vorrei che questo fosse molto più semplice (automatizzato) in modo che se dovessi creare un nuovo ambiente in caso di emergenza, posso farlo in modo affidabile.

2. Capacità di distribuire l'app in un ambiente di staging il più possibile identico a quello live, idealmente come un processo automatizzato innescato da una git push usando un approccio di integrazione continua (che non avevo mai fatto prima).

3. Possibilità di "premere il pulsante" quando sono soddisfatto dell'app in ambiente di gestione temporanea per spingere idealmente automaticamente in un ambiente live.

4. Modo per monitorare il sito (solo un sondaggio per una pagina farà)

5. Modo per passare al sito live su un altro server se ho bisogno di recuperare da un'app o un errore del server sul sito live. Penso che forse un approccio blu-verde avrebbe funzionato per me?

Cosa ho provato o considerato?

• Configurazione manuale dell'ambiente live con l'app Django, quindi copia manualmente la nuova base di codice su di essa quando si verifica una modifica. Questo è soggetto a errori umani e temo di fare un errore in una distribuzione causando un errore irreversibile.

• Docker. Devo ammettere che quando ho scoperto Docker mi è sembrato un sogno diventato realtà, ma dopo un po 'di sperimentazione e ricerca sono spaventato da quanto devo imparare e sapere per farlo funzionare e gestirlo. Può darsi che ne valga la pena perché, una volta che funziona, ha un rischio molto basso, ma al momento sembra un investimento più grande del mio tempo di quanto spero.

• Script Bash. Usali per configurare l'ambiente originale e per attività specifiche come l'aggiornamento dell'app. La mia preoccupazione al riguardo è che gli script saranno codice che deve essere testato e temo che ci vorrebbe molto tempo per costruire un set di strumenti affidabile in questo modo.

• Ho esaminato le opzioni di Digital Ocean per gli indirizzi IP mobili e la possibilità di avere due server per un approccio "blu verde" che sembra abbastanza ragionevole. Se seguo questa strada, devo ancora essere in grado di automatizzare la distribuzione.

Quindi ... sto cercando consigli su un approccio devops che trovi il giusto equilibrio tra minimizzare il rischio (ad es. Il rischio di rompere l'app live con un aggiornamento o il rischio di non riuscire a recuperare da un errore) e minimizzare il tempo investimento che devo fare per impostare gli ambienti e il flusso di lavoro.

Non ho familiarità con lo sviluppo di Python né DigitalOcean, quindi offrirò solo alcuni suggerimenti:

• L'obiettivo è quello di automatizzare. Qualunque cosa. Il modo in cui lo realizzi dipende davvero da te e la creazione dei tuoi strumenti non è inverosimile, molti lo fanno in questo modo. Un frutto concreto e piuttosto basso (ish) appeso è quello di far funzionare un gancio post-ricezione git che distribuisce e riavvia l'ambiente di test. Se lo hai, il resto dovrebbe essere semplice.
• "La mia preoccupazione è che gli script saranno codice che deve essere testato" - questa preoccupazione è infondata. Dopotutto, stai testando questi script ogni volta che esegui la distribuzione nel tuo ambiente di test. Specialmente accoppiato con un approccio blu-verde, andrà bene avere script bash.
• "Non mi piace bash." - Quindi trova un altro linguaggio di scripting che ti piace. Forse prova Ruby? Le librerie di lingua e core sono molto pulite e ben documentate, e direi, piuttosto facili da imparare. O, solo per divertimento, Go (lang), che sembra essere adatto ai compiti degli strumenti di sviluppo. E infine, dato che sembra che ti piaccia Python, puoi certamente fare anche le attività di installazione con quello. Da questi, Go ha il vantaggio di creare file binari autonomi e non necessita di un ambiente complesso installato per primo, quindi il bootstrap può essere più semplice.
• "un ambiente di gestione temporanea che è il più identico possibile al live" - ​​se si dispone di uno script che fa girare un ambiente da zero, ovvero da un'immagine di base più o meno vuota, i tuoi ambienti saranno identici, salvo i delta codificati in la tua sceneggiatura. Questo è il punto di tutto questo.
• "Modo di passare il sito live a un altro server" - l'unica cosa su cui riflettere è cosa succede con i tuoi dati persistenti. Cioè, vorrai farlo in modo da poter collegare le tue applicazioni con diversi volumi / negozi persistenti al volo, per essere in grado di passare avanti e indietro.
• "Docker - scoraggiato" - a dire il vero, non dovrebbe essere così male. Se sai come creare un ambiente da zero con gli strumenti da riga di comando (nessuno strumento GUI), posizionarli in un file Docker dovrebbe essere piuttosto semplice. I dettagli preoccupanti appaiono quando è il momento di sintonizzarsi (cioè ridurre le dimensioni dell'immagine), ma a parte questo non dovrebbe essere troppo male. Prima fallo funzionare in qualche modo , quindi scopri come renderlo bello. La cosa buona è che le conoscenze acquisite verranno trasferite in molti altri ambienti.

In bocca al lupo!

Grazie per l'ottima domanda. Niente è davvero banale la prima volta che lo fai e una volta eravamo tutti nuovi a qualcosa.

La mia prima raccomandazione è di rivisitare la finestra mobile. Prova alcune diverse guide ed esercitazioni. È davvero semplice Hai un file docker che viene "costruito", letteralmente solo i comandi che desideri vengano eseguiti sul "contenitore" o "immagine". Trasmetti quell'immagine in un registro che può essere pubblico o privato. Quindi si esegue quell'immagine su un computer host. Docker è molto importante con node.js e python dove hai molte dipendenze e a volte può essere davvero difficile gestirle. Se stai usando pip, e dovresti esserlo, puoi generare un requirements.txtfile da alimentare al contenitore della finestra mobile.

Ora hai detto che stai usando git, quindi io userei git git locali. È possibile utilizzarli per creare il contenitore della finestra mobile, eseguire test automatici e quindi distribuire il contenitore. Puoi consultare molte diverse guide ed esercitazioni su questo argomento.

Per la gestione della tua infrastruttura useresti Terraform. Terraform è eccezionale perché è possibile creare un ambiente su richiesta ed eliminarlo al termine. La mia raccomandazione sarebbe quella di iniziare in modo semplice e una volta padroneggiato docker e terraform puoi provare le distribuzioni blu / verde.

Ora se stai usando Gitlab o sei disposto a cambiare, offre anche un servizio ci / cd gratuito. Questo include tante funzioni interessanti ed è davvero facile da usare. Lo uso personalmente per tutte le mie app. È possibile saltare completamente i git git locali e testarli nella pipeline di gitlab o conservarli per testare ogni commit localmente e utilizzare gitlab per compilare e distribuire.

Spero che questo sia stato in qualche modo utile.

Le risposte pubblicate sono state molto utili nel permettermi di ripensare il mio problema e vari approcci. Non ho ancora implementato una soluzione, ma ho deciso un approccio, quindi lo sto documentando e selezionandolo come risposta. In sintesi è questo:

Il mio approccio scelto

• Per l'ambiente live userò due macchine virtuali (probabilmente usando goccioline di DigitalOcean) che eseguono Ubuntu e configurate esattamente allo stesso modo.
• Utilizzerò un approccio blu-verde utilizzando la funzione Floating IP all'interno di DO per mantenere i miei due server identici come Live e Pre-Prod / Backup.
• Creerò una VM (probabilmente usando VirtualBox) nel mio sviluppo impostato per l'uso come ambiente di gestione temporanea. Questa macchina virtuale verrà configurata esattamente come i miei due server live.
• Scriverò un singolo script comune in Python per configurare un ambiente da zero e lo userò per configurare il mio ambiente di staging e la mia coppia live / pre-prod.
• Userò git hooks per attivare gli aggiornamenti degli ambienti (probabilmente attivati ​​manualmente).

Considerazioni che hanno guidato questo approccio

• Docker: ho deciso di non farlo. Anche se prendo sul serio le risposte (grazie @Levi e @Dan) che dicono che dovrei visitare di nuovo e non dovrebbe essere così male, ho avuto troppe esperienze in passato di intraprendere qualcosa di nuovo e rendermi conto di essere caduto in una tana del coniglio che consuma tempo e impiega un'età per iniziare. Penso che sarebbe diverso se stessi lavorando anche con un'altra persona, ma come qualcuno che lavora completamente da solo ogni minuto è prezioso.

• Macchine virtuali: non l'avevo davvero preso in considerazione fino a quando non ho iniziato a lavorare con alcune esercitazioni Docker che utilizzano le macchine virtuali per dimostrare la funzionalità di Swarm. L'idea di essere in grado di creare un nuovo ambiente di cui ho il controllo completo è molto interessante.

• Scripting: richiesto dalla risposta utile di @ AnoE, ho fatto un po 'più di ricerca e sembra che Python sia riconosciuto come un'opzione praticabile per lo scripting e dato che è quello in cui sto scrivendo la mia app sembra che ci dovrebbe essere una sinergia (se ho bisogno per imparare qualcosa di nuovo per la mia sceneggiatura sarà conoscenza che potrei usare per scrivere la mia app)

Aggiornerò una volta che avrò fatto qualche progresso in questo e se andrà terribilmente male riconoscerò che forse ho fatto la scelta sbagliata!).

Aggiornamento del 20 ottobre 2018.

Ho deciso di scrivere uno script Python, ma questo spesso comportava l'invocazione di un comando bash da Python e quindi il recupero della risposta e l'ho trovato aggiunto molto al tempo di sviluppo. Dopo un paio di settimane di lenti progressi, ho cercato altrove. Devo ammettere che mi sarei avvicinato a torto, ma avevo bisogno di qualcosa che sarebbe stato più veloce.

Alla fine ho optato per Vagrant / Ansible / VirtualBox e dopo più mesi di quanto mi piacerebbe ammettere, ho ottenuto qualcosa che ha funzionato bene, ma dopo molto lavoro ho imparato alcune nuove abilità (Vagrant e Ansible erano completamente nuove per me). Ho quindi applicato lo script Ansible per eseguire il provisioning di un droplet DigitalOcean e ho scoperto che funzionava davvero bene. Sono diventato un fan di Ansible ma anche se sono d'accordo (con i revisori) che è relativamente facile da usare, è ancora un nuovo paradigma e una curva di apprendimento piuttosto ripida.

Al momento della stesura, ho eseguito il provisioning di due Droplet separati su DigitalOcean in una configurazione blu-verde, usando gli indirizzi IP Floating DO per passare da uno all'altro, e su ciascuno l'applicazione è all'interno di una copia funzionante di git quindi devo solo aggiornare il Master per aggiornare un ambiente.

Sto riscontrando un problema a far funzionare gli IP mobili come mi aspettavo, ma mi aspetto di risolverlo presto e quindi avrò un ambiente DevOps funzionante.

Il grande vantaggio di questo approccio è che il modo in cui funziona Ansible, una volta che hai qualcosa che funziona, è relativamente facile farlo funzionare in un ambiente diverso e questo potrebbe non essere così facile da ottenere con uno script Python (o almeno devi costruire questo in cui è un lavoro extra).

Penso che la grande lezione sia che le cose impiegano più tempo di quanto mi aspetto e l'apprendimento di una nuova tecnologia porta sempre incognite sconosciute. Questa non dovrebbe essere una sorpresa per me - ma lo è sempre e funziona come sviluppatore solitario, questo mi succede molto.