Utilizzo di Ansible, Jenkins e finestra mobile per creare ambienti di test rapidi

Question

Sto pianificando di creare un ambiente di test utilizzando ansible, jenkins e docker insieme. Il piano è come questo.

Creare playbooks ansible per ogni strumento che si sta utilizzando nel proprio ambiente e memorizzarli su git. Utilizzo di jenkins per creare un lavoro per creare contenitori docker sul server di sviluppo e utilizzare i playbook ansibili per il provisioning dei contenitori di finestra mobile. I lavori Jenkins verranno creati in modo che l'utente abbia l'opzione di selezionare i libri di gioco che desidera utilizzare con i contenitori docker e i contenitori verranno creati di conseguenza.

l'intero concetto può essere riepilogato come mostrato sotto l'immagine.

I vantaggi che vedo sono

replica automatica di ambienti di produzione esatte.
Ridimensiona l'ambiente di test secondo i requisiti.
Fornire piattaforme diverse per il test delle applicazioni su un singolo server.
Test di integrazione più rapidi.
Promuovere la metodologia agile.
Libertà di sviluppare e personalizzare l'ambiente di test.
Gli sviluppatori e i tester possono creare ambienti autonomamente anche se non conoscono nulla per quanto riguarda il sistema operativo, la configurazione.
Verificare la distribuzione dell'app in un ambiente pulito, una nuova build.

Qualcuno ha implementato tale tipo di architettura ambientale, vorrei discutere la fattibilità effettiva dei benefici della stessa.

Answer 1

Sto usando un approccio simile, ma diverso:

• Definire Dockerfiles o chef/burattino/ansible/provisioning sale. Come nel tuo approccio.

• Inserimento di queste descrizioni nel controllo di versione. Come nel tuo approccio.

• Utilizzo di immagini da Jenkins A a CI- e Nightly Building e caricamento in un registro. Al fine di gestire diverse versioni e conservare le vecchie immagini. Questo introduce un registro immagini nel tuo diagramma.

• Estensione di quelle immagini con gli schiavi di Jenkins-Swarm. Ciò consente la distribuzione ad-hoc nel tuo ambiente Jenkins.

Qui separo tra la costruzione del software e la costruzione degli schiavi stessi.

• Distribuisco un Jenkins B per costruire il software sugli ambienti.

• Ora scelgo tra il contenitore che voglio distribuire in modo permanente e creare i contenitori che voglio distribuire su richiesta.

  • I contenitori permanenti, che sono pesantemente utilizzati dai lavori di costruzione, vengono avviati come sciami di sciami e scambiati giornalmente con build notturni.
  • I contenitori ad-hoc sono gestiti da Jenkins-Docker-Plugin.
  • Per configurazioni di ambiente più complesse, utilizzo la finestra mobile-compose per gestire la disponibilità ad hoc.
  • Per ambienti ad hoc, ovvero macchine virtuali per l'esecuzione di tali configurazioni, utilizzo docker-swarm.

Diagramma:

Answer 2

Se si desidera verificare un'immagine finestra mobile che ha l'ultima versione disponibile di un determinato pacchetto su un dato sistema operativo con, allora avete bisogno di impostazione dell'immagine notte finestra mobile ricostruisce . Ho un progetto molto piccolo e semplice che può farti funzionare con le ricostruzioni di immagini di docker notturne allo https://github.com/zbeekman/nightly-docker-rebuild. Lo uso per ricostruire il trunk GCC dal sorgente, ma lo si può usare altrettanto facilmente per installare/aggiornare i pacchetti da un gestore di pacchetti o gestire qualsiasi altra dipendenza build/runtime che potrebbe essere aggiornata a monte e avere un potenziale impatto sul progetto . In questo modo puoi prendere i problemi in anticipo, prima che i clienti/utenti li incontrino.