Docker, microservices e git workflow

Sembra che il tuo problema sia quello di mettere tutti i tuoi microservizi nella stessa "immagine dell'ambiente di sviluppo" che descrivi. Quindi qualsiasi contenitore di servizi può vedere tutti gli altri.

Quello che dovresti fare è creare immagini docker specifiche per ogni microservizio, basandosi su una finestra mobile di immagini di base che contiene i valori predefiniti appropriati e ogni specifico microservizio.

Nuovi servizi possono essere sviluppati da questa immagine di base. Poiché l'immagine di base non contiene nessuno degli altri servizi, non devi preoccuparti del tuo problema.

Potresti anche volere immagini server / client per ciascuna (la tua domanda non è sufficientemente dettagliata per rispondere veramente se questo è importante o meno). Dato che stai chiedendo di un appaltatore esterno, anche questo potrebbe essere utile, ma dipenderà da come funzionano effettivamente i tuoi microservizi.

Uno degli enormi vantaggi della finestra mobile è la possibilità di fare questo genere di cose. Fare un singolo "tutto ciò che usiamo usa la stessa immagine di finestra mobile" significa perdere il punto di finestra mobile.

Se non ti fidi di qualcuno con il tuo codice, non dovresti inviare il tuo codice al loro computer. Periodo.

Docker ha apportato alcuni miglioramenti al networking nelle ultime versioni. Se si configura il proprio sistema in modo da avere un contenitore per microservizio, si dovrebbe essere in grado di comunicare con un server remoto e ambienti di produzione e test sullo stesso host e dal punto di vista del microservizio all'interno del contenitore, l'unico la differenza è un po 'di latenza extra.

Probabilmente potresti aggiungerlo in modo incrementale, se vuoi avere livelli di sviluppatori "fidati" e "non attendibili". Tuttavia, come sottolineato da Enderland, ti manca il punto di finestra mobile usando un solo contenitore. L'utilizzo di più contenitori semplifica operazioni quali l'aggiornamento, il backup o il riavvio di singoli servizi. Lo sviluppo è in genere più rapido perché puoi isolare più facilmente il tuo singolo servizio. Ogni servizio deve solo concordare un'interfaccia, non altri dettagli interni.

Molte volte non hai bisogno del resto del sistema per essere disponibile per testare un microservizio. Puoi semplicemente avviare il proprio contenitore e batterlo con arricciatura , postino , o script di test automatici. Puoi fornire ambienti di sviluppo fittizi che sono più facili da utilizzare per gli sviluppatori e che non contengono informazioni proprietarie.

Potrebbe sembrare più difficile ora dividere in contenitori separati, ma a lungo termine ne varrà la pena.