Effettua la configurazione di una docker basata su SPA

Question

Effettua la configurazione di una docker basata su SPA

#1 da (2 voti)

0

Ho un'app a singola pagina (Vue JS) creata e rilasciata come immagine mobile. L'immagine della finestra mobile è basata sull'immagine di Docking Nginx e serve la SPA come contenuto statico.

Fino ad ora, c'era solo una singola implementazione non di sviluppo di quella SPA, quindi l'URL dell'API back-end era hard-coded nei parametri di produzione dello SPA. Ora stiamo introducendo più ambienti di staging che ognuno ha bisogno della propria SPA & Implementazione dell'API. Per es.

spa.staging1.example e api.staging1.example
spa.staging2.example e api.staging2.example
...

Ciò significa che l'hard-coding dell'URL dell'API non funziona più. Anche la creazione di più immagini di docker SPA non è un'opzione, poiché ci sono molti ambienti di staging e non tutti sono noti in anticipo. Ciò significa che l'URL dell'API nell'immagine Docker SPA deve essere configurabile, preferibilmente con le variabili di ambiente che vengono passate nel contenitore Docker.

Quali sono le migliori pratiche per configurare le SPA in modo configurabile, quando non esiste un rendering dinamico lato server in loco?

deployment front-end docker configuration single-page-apps

posta theDmi 22.05.2018 - 15:54

fonte

1 risposta

Leggi altre domande sui tag deployment front-end docker configuration single-page-apps

Alternative all'ereditarietà per componenti con comportamenti diversi? Perché "typeof null == object" rimarrà in javascript?

score 2 · Answer 1

Hai tre opzioni:

Crea diversi siti statici su cui ogni backcode è protetto da hardcode. Hai respinto questa soluzione, che è probabilmente la decisione corretta. (Ma se hai siti statici, perché hai bisogno di Docker?)
Utilizza un rendering sul lato server. Per questo compito, anche il più semplice meccanismo di sostituzione del testo sarebbe adeguato. È possibile reindirizzare il codice sorgente tramite tale processore di template.

In alternativa, potresti offrire un URL separato che può essere utilizzato per scoprire l'endpoint, ma sarebbe una soluzione molto insolita.
Cambia il significato di questi nomi di dominio per gli utenti di questi ambienti di gestione temporanea. Cioè consenti loro di utilizzare un server DNS (o un file hosts) che risolva qualsiasi backend hardcode al backend di gestione temporanea corretto. Sebbene tu abbia questa opzione, è una soluzione molto fragile che è difficile da debugare, difficile da configurare e presenta alcune divertenti modalità di errore (come l'esecuzione accidentale contro il backend del tuo prodotto) a meno che tu non disponga di una VLAN separata per gli ambienti di staging.

Di tutte queste soluzioni, l'utilizzo di alcuni modelli sul server è l'approccio meno pazzo. Se configurato correttamente, questo avrà un sovraccarico di runtime pari a zero, poiché è sufficiente eseguire il rendering del modello una sola volta all'avvio e continuare a servire quell'output come file statico. Potrebbe anche essere sufficiente modificare il comando ENTRYPOINT nel Dockerfile con qualcosa di simile:

./fill-in-templates.sh && ./start-nginx