Nell'ultimo paio di sezioni completiamo il nostro file di configurazione di distribuzione e il nuovo servizio IP cluster
per andare avanti con esso.
Continueremo mettendo insieme altri due file di configurazione quasi identici questa volta centrati attorno
alla nostra Express API o all'immagine del server multis e questa volta garantiremo un servizio
IP cluster molto simile perché noi Non voglio che l'API Express sia direttamente accessibile dal
mondo esterno come normalmente accade con un servizio di porta del nodo.
Ricorda che utilizziamo l'IP del cluster ogni volta che vogliamo rendere un set di pod accessibile solo
ad altre cose all'interno del nostro nodo.
Il servizio di ingresso che alla fine andremo a mettere insieme si qualifica come un'altra cosa all'interno del
nostro nodo.
Tutto ok.
Quindi una cosa rapida che voglio ricordarti qui è che la nostra immagine multis server ascolterà
sempre le richieste in arrivo sulla porta 5000.
E questo era qualcosa che avevamo davvero codificato nell'immagine stessa e nel server
attuale che scorre dentro.
Quindi, quando creiamo il nostro servizio IP cluster, faremo in modo che invii il traffico
a cinquemila porte su ognuno di questi pod diversi.
E di nuovo solo per mantenere ogni porta uguale su entrambi i lati, diremo che è possibile accedere
all'IP del cluster accedendo a 5000 come ho detto in precedenza.
Non c'è davvero una buona ragione a prima vista, per qualche motivo, per cambiare la porta su cui
l'IP del cluster accetta il traffico.
Quindi faremo in modo che sia 5000 in entrambi i casi.
Va bene, andiamo.
Ho bisogno di tornare al mio editor di codice all'interno della mia directory di Kades.
Creerò un nuovo file e chiamerò questa distribuzione Dasch del server.
YAML.
E poi all'interno di qui metteremo insieme una configurazione che sembrerà molto simile a ciò che
abbiamo fatto nella distribuzione dei nostri client solo un momento fa.
Quindi diremo nuovamente che le app della versione API V-1 avremo un tipo di distribuzione per i nostri dati Medhat.
Forniremo un nome per la distribuzione del server e quindi inizieremo ad aggiungere le specifiche che personalizzeranno esattamente come
si comporta questa implementazione.
Quindi, per le repliche delle mie repliche, assicuriamoci che l'ortografia sia corretta.
Di nuovo questo è il numero di pod diversi che andremo a configurare.
Diremo arbitrariamente che vogliamo tre pod che eseguono l'immagine multi server.
Non sappiamo davvero molto su come.
La maggior parte dei poliziotti su scala scala questi gruppi di pod, quindi forse tre è un buon punto di partenza.
Forse non è non lo so.
Scopriremo quando implementeremo questa cosa e inizieremo a testare il nostro cluster con un po
'di traffico.
In seguito andremo a specificare il selettore che verrà utilizzato dalla distribuzione per trovare questi set
di pod che deve controllare.
Quindi stiamo per dire che vogliamo abbinare un set di etichette.
E poi di nuovo faremo un componente.
Questa volta invece di fare il Web come valore per la chiave del componente farò un server come questo e quindi questo è molto
chiaramente indicando che il componente all'interno della nostra applicazione su cui stiamo lavorando proprio qui è
il server che voglio ricordarvi che le etichette che mettiamo insieme possono essere qualsiasi cosa possiate
immaginare.
Così potremmo fare qualcosa come parte dell'API dell'app o qualcosa del genere.
Ma personalmente mi piace questo tipo di componente e quindi pezzo di terminologia dell'applicazione. Penso che
sia piuttosto chiaro cosa indichi questa coppia di valori chiave.
OK, ora che abbiamo messo insieme, riusciamo a rientrare in una rientranza sullo stesso
livello di indentazione del selettore e delle repliche.
E poi metteremo insieme il nostro modello di pod Zyla per cominciare con il nostro Medhat day ma apparentemente con i meta dati
che specificheranno il nostro set di etichette.
E ancora, le etichette che applichiamo al proverbio devono almeno corrispondere a qualsiasi cosa mettiamo all'interno
delle specifiche per la distribuzione stessa.
Quindi per le etichette tutti dicono che il componente server è così perfetto
che ho intenzione di indentare il rientro un po 'di più, così ora sono sullo stesso livello di
indentazione dei metadati.
E forniremo le specifiche che personalizzeranno il comportamento esatto di ciascuno dei
pod creati.
Ora forniremo nuovamente un elenco di contenitori che questo piatto dovrebbe funzionare come prima.
Avremo solo un singolo contenitore all'interno di questo pod.
Non abbiamo altri contenitori che devono funzionare insieme all'immagine multi server.
Quindi darò un nome di server, l'immagine sarà il mio ID docker slash multi server e l'ultima cosa che faremo ora
è aggiungere l'elenco di porte che vogliamo rendere disponibili.
Quindi per i porti ho intenzione di dire che vogliamo avere una porta container accessibile di 5000 come la.
Tutto ok.
Ora voglio darvi un rapido promemoria l'immagine multis server che abbiamo messo insieme
si aspetta di ottenere una manciata di coppie di valori chiave insieme ad essa o variabili d'ambiente che
dice al server multis o all'API Express esattamente come connettersi alla nostra istanza postscripts e anche l'istanza S rossa.
Quindi tutto ciò che abbiamo messo insieme in questo file in questo momento è sicuramente qualcosa che
dobbiamo aggiungere qui.
Ma alla fine torneremo e aggiungeremo una serie di variabili di ambiente
che vogliamo essere inserite nel contenitore creato con questa immagine.
E ricorda l'intero obiettivo che stiamo per dire all'API Express come connettersi ai post
script e leggere restis.
Va bene, quindi torneremo su questo file.
Ma in questo momento voglio concentrarmi solo sul finire questo specifico pezzo della nostra applicazione per Speace in questo
momento e non voglio ancora pensare a come coinvolgere rattus in post
e qui ancora.
Va bene.
Quindi facciamo una breve pausa qui.
Quando torneremo alla prossima sezione, metteremo insieme il nostro file di configurazione per il servizio
IP del cluster.
Quindi una breve pausa e ci vediamo tra un minuto.