Dove memorizzare standalone.xml e altri file in modo che sia accessibile nel mio server CI?

Naviga le tue risposte
1

Sono abbastanza nuovo per JavaEE, quindi ho ancora alcuni concetti mancanti. Sto imparando Docker per usarlo nei nostri ambienti DEV / CI Build. Potrei farlo funzionare sulla mia macchina. Ma perché funzioni nel server CI, il mio attuale approccio sarebbe quello di memorizzare docker-compose.yml e dockerfiles in git e, nel server CI, scaricarlo, creare le immagini e avviarlo.

Per impostare l'immagine della finestra mobile per il contenitore web (Wildfly) ho dovuto aggiungere:

  • Driver DB (file .jar)
  • Standalone.xml (file .xml)
  • Moduli che usiamo (mix di file .xml e .jar)

Ma questi file non sono presenti nel server CI. Potrei scaricare i driver DB durante la creazione dell'immagine, ma i moduli e standalone.xml non sono disponibili online.

Questo approccio è ragionevole? In tal caso, dove memorizzerebbero questi file in modo che vengano aggiornati quando necessario e che il Server CI sia in grado di scaricarli per creare l'immagine?

    
posta JSBach 28.01.2016 - 09:56
fonte

2 risposte

2

Per i punti 1. e 3. È possibile creare un repository Ivy privato e recuperare i driver ei moduli DB da esso tramite lo strumento di compilazione (supporto di Mvn, Ant, Gradle per ottenere le dipendenze dai repository Ivy) durante la creazione dell'app.

E per i file .xml - puoi avere repository git per i file di configurazione dell'ambiente di test. Oppure crearli crittografati nel repository delle app e configurare lo script CI per crittografare quei file con la chiave che verrà incorporata in quello script CI. (crittografati, quindi le persone con accesso git alla tua app non otterranno la password per il tuo DB di test)

    
risposta data 28.01.2016 - 14:40
fonte
1

Hai bisogno di una build riproducibile - questo significa che non vuoi che il tuo server CI scarichi cose da Internet su richiesta. È necessario scaricarli e raccogliere altrimenti tutto il necessario per la compilazione e memorizzarlo da qualche parte accessibile al server CI.

Ora il modo più semplice e più a prova di futuro è quello di archiviare queste cose nel proprio repository controllato da fonti. Quindi è possibile aggiornarlo o creare un nuovo set da diverse configurazioni con facilità. Puoi anche creare una versione storica se necessario.

Quindi: crea un nuovo repository per la tua configurazione Docker, metti quello che ti serve e il tuo server CI afferra sia la configurazione docker che i file dell'applicazione da entrambi i repository al momento della creazione. Puoi anche inserire la finestra di dialogo nel repository di origine in una directory diversa se ha più senso per te.

In alternativa, è possibile memorizzare queste cose sul server CI direttamente come un'installazione di strumenti di compilazione (ad esempio, è già necessario installare un JDK) e mantenerlo semplicemente come un pre-requisito noto per configurare il sistema. La decisione su quale utilizzare di solito si riduce alla dimensione dei file.

    
risposta data 28.01.2016 - 16:51
fonte

Leggi altre domande sui tag

Qual è la ragione storica di includere lo stub DOS nelle immagini PE? Come dovrei esprimere la complessità di due loop annidati su dataset diversi nella notazione Big O?