Febbraio 2019
Volume 34 Numero 2
Il presente articolo è stato tradotto automaticamente.
[Azure]
Crea e distribuisci soluzioni a disponibilità e resilienza elevate in Azure
Alcune delle tecnologie illustrate in questo articolo sono disponibili in anteprima. Tutte le informazioni sono soggette a modifiche.
Le organizzazioni oggi avere una presenza globale e si aspettano loro applicazioni mission-critical per raggiungere gli utenti in più aree geografiche. IL personale IT in queste organizzazioni sono sotto pressione per soddisfare le aspettative e il successo dipende dal modo in cui anche le applicazioni e piattaforme sono progettate e compilate per affrontare le complessità intrinseche in tale obiettivo. Microsoft Azure offre numerosi servizi e funzionalità che forniscono un'implementazione quasi pronte all'uso per soddisfare i requisiti rilevanti, se prevedono l'abilitazione della replica geografica dei servizi e i dati, sensibili alla latenza delle richieste degli utenti per il routing di un servizio più vicini agli utenti finali, o che fornisce il failover delle applicazioni senza problemi in altre aree in caso di emergenza. In questo articolo verrà Esaminiamo alcune di tali obiettivi e illustrare come è possibile usare Azure per implementare applicazioni globali resilienti e a disponibile elevata.
Voglio utilizzare una soluzione a tre livelli costituito da un'applicazione MVC e API Web per illustrare gli aspetti principali di compilazione e distribuzione di applicazioni resilienti e a disponibile elevata in Azure. L'applicazione è accessibile da un utente per acquisire le informazioni di base relative alla famiglia, che viene passato per il livello API, che a sua volta rende persistenti i dati in un database di Cosmos DB con replica geografica. L'applicazione viene distribuita Active-Active tra più aree per garantire la resilienza in caso di interruzioni a livello di area. All'interno di un'area viene distribuito tra zone di disponibilità per proteggerti da errori dei Data Center (bit.ly/2zXlRll). Il database è abilitata una funzionalità di scrittura in più aree (bit.ly/2zV6OI0), assicurando che gli utenti possono scrivere e leggere i dati da un database che è vicino al relativo punto di accesso, per ridurre al minimo la latenza (bit.ly/2QRr1Il).
Architettura della soluzione
Figura 1 rappresenta l'architettura della soluzione. Azure Service Fabric ospita i componenti dell'applicazione compresso come contenitori Docker per Linux, offre funzionalità di orchestrazione e assicura la disponibilità e affidabilità dell'applicazione. Sono presenti due cluster di Service Fabric zona distribuito in ognuna delle due aree di Azure, in Asia sud-orientale e Stati Uniti orientali 2. Un Azure Load Balancer con ridondanza della zona viene usato per il round robin le richieste tra le due zone di disponibilità in ogni area.
.png "Architettura della soluzione")
Figura 1 architettura di soluzione
Servizio di ingresso principale di Azure (ancora in anteprima pubblica) indirizza le richieste degli utenti a uno degli endpoint con bilanciamento del carico in due aree, in base al percorso di latenza minima. Fornisce anche resilienza in caso di applicazione o un intero Data Center indisponibile in una delle aree, indirizzando le richieste all'endpoint in altra area.
Il database di Azure Cosmos DB utilizzato nell'applicazione sia con replica geografica tra due aree di Azure e configurato per la scrittura in più aree. Di conseguenza, scritture di dati provenienti dal servizio API in ogni area vengono scritti in una raccolta di Cosmos DB locale per tale area.
DevOps di Azure è il repository del codice sorgente per l'applicazione. Le pipeline di Azure consente di compilare le applicazioni, inserirli come contenitori Docker e caricarle in un registro dell'Hub Docker.
I criteri IT dell'organizzazione che ospita questa soluzione proibire l'accesso amministrativo al cluster di Service Fabric tramite Internet pubblico. Una pipeline di recapito continuo (CD) viene implementata usando Jenkins distribuito all'interno di una rete virtuale di Azure. Effettua il pull i contenitori e pacchetti di distribuzione dal repository Git in DevOps di Azure e Hub Docker, rispettivamente e distribuisce l'applicazione nel cluster di Service Fabric nelle due aree.
Cluster di Service Fabric distribuito in ogni area è costituita da due tipi di nodo. Il tipo di nodo primario esegue i servizi della piattaforma Service Fabric ed espone gli endpoint di gestione utilizza un bilanciamento del carico interno. Il tipo di nodo secondario esegue le applicazioni MVC e API Web incluso nel pacchetto con i contenitori Docker. Un servizio di bilanciamento del carico pubblico instrada le richieste degli utenti finali l'accesso all'applicazione tramite Internet.
Un terzo servizio Azure Load Balancer (non illustrato nel diagramma) viene utilizzato in questa architettura per permettere le chiamate in uscita a Internet dal cluster, per scaricare i componenti della piattaforma Service Fabric. Il servizio di bilanciamento del carico interno configurato non dispone di un endpoint pubblico e non riesce a raggiungere Internet. Senza creare il bilanciamento del carico pubblico aggiuntive per la connettività in uscita, non è possibile configurare il cluster di Service Fabric (bit.ly/2A0VBpp).
Si noti che le SKU di Azure Load Balancer e IP pubblico indirizzo risorse standard autonoma supportano la distribuzione in zone di disponibilità di Azure, escludendo lo SKU basic, che non esiste.
Azure Service Fabric sfrutta la capacità delle risorse sottostanti set di scalabilità macchine virtuali di Azure (VMSS) per la distribuzione di zona.
Sviluppo di applicazioni
Sono disponibili due file di soluzione di Visual Studio 2017 condivisi con questo articolo:
• censusapp.sln: L'applicazione ASP.NET Core 2.0 MVC.
• censusapi.sln: L'applicazione API Web ASP.NET Core 2.0.
Tenere presente che, anche se questa applicazione di esempio è stata creata tramite ASP.NET Core 2.0, può essere molto bene un'applicazione Web creata mediante altre tecnologie, ad esempio Node. js, PHP e così via. Inoltre, l'applicazione di esempio condiviso con questo articolo non implementa tutte le procedure consigliate di codifica. È destinato solo illustrare il dettaglio di implementazione di progettazione selezionare.
L'applicazione MVC implementa l'interfaccia utente che consente agli utenti di inviare dati di censimento e ne visualizza i dati. Usa la funzionalità di individuazione del servizio in Service Fabric per chiamare l'API REST che rende persistenti i dati in Azure Cosmos DB. Il progetto di API Usa il SDK di Cosmos DB per implementare un elenco di percorsi del database a cui connettersi per leggere e scrivere dati in ordine di priorità. L'applicazione che viene distribuito nell'area Asia orientale meridionale aggiungerebbe questa area "priorità 1" e Stati Uniti orientali 2 come "con priorità 2." Per la distribuzione per l'area Stati Uniti orientali 2, sarebbe l'opposto. Di conseguenza, non vi sarà due immagini del contenitore separato per il progetto API Web, una per ogni distribuzione per i rispettivi paesi. L'immagine del contenitore per il progetto MVC sarebbe lo stesso, indipendentemente dall'area di Azure a cui è stato distribuito.
Il frammento seguente illustra come viene aggiunta all'elenco dei percorsi in ordine di priorità per la connessione di Cosmos DB e come configurare le scritture tra più aree nell'applicazione:
ConnectionPolicy policy = new ConnectionPolicy
{
ConnectionMode = ConnectionMode.Direct,
ConnectionProtocol = Protocol.Tcp,
UseMultipleWriteLocations = true,
};
policy.PreferredLocations.Add("East US 2");
policy.PreferredLocations.Add("South East Asia");
DocumentClient client = new DocumentClient(new Uri(this.accountEndpoint),
this.accountKey, policy);
Il progetto API Web Usa il pacchetto NuGet "Bogus" per generare dati fittizi.
Chiavi di accesso e stringa di connessione di Cosmos DB vengono archiviate nel file appSettings. JSON del progetto API Web per motivi di semplicità. Per la produzione possono invece essere archiviati in Azure Key Vault. Fare riferimento al mio articolo, "Secure Your sensibili aziendali informazioni con Azure Key Vault" per informazioni aggiuntive (msdn.com/magazine/mt845653).
Consentendo alle applicazioni Web per contenitori DockerVisual Studio 2017 Tools per Docker fornisce un'implementazione di chiavi in mano per consentire a un'applicazione Web ASP.NET 2.0 per i contenitori Windows e Linux. Selezionando l'opzione pulsante destro del mouse sul progetto in Visual Studio 2017 "abilitare il supporto Docker" aggiunge un file Docker a esso. Se si seleziona l'opzione di pulsante destro del mouse sul progetto per "abilitare il supporto di orchestrazione" create Docker compose file.
Le applicazioni in questa soluzione sono state compresse per i contenitori Docker Linux. Modifiche di lieve entità sono state eseguite per Docker compose file per aggiungere il mapping della porta da usare quando si distribuisce l'applicazione (porta 80 nei nodi VMSS per accedere all'applicazione MVC e 5002 di porta per l'API Web).
Integrazione continua (CI) vengono controllati i file della soluzione di Visual Studio 2017 in un repository Git di DevOps di Azure. Una pipeline di Azure viene creata che sarebbe eseguire Docker compose file per ognuno dei progetti MVC e API Web creati nei passaggi precedenti. Questo modo le applicazioni ASP.NET Core 2.0 e crea le immagini del contenitore Docker.
Nel passaggio successivo nella pipeline, viene usato uno script Bash per contrassegnare le immagini del contenitore ed eseguirne il push nell'Hub Docker. Questo passaggio deve essere eseguita una volta per la distribuzione nell'area di Azure in Asia sud-orientale e una sola volta per la distribuzione in Azure area Stati Uniti orientali 2. Anche in questo caso, il contenitore MVC è lo stesso non questione a quale area di Azure è stato distribuito. Figura 2 Visualizza un'istantanea della pipeline di integrazione continua creata per eseguire questo passaggio.
.png "Azure DevOps Pipeline")
Figura 2 della Pipeline di DevOps di Azure
Creazione di pacchetti di applicazioni per la distribuzione di Service Fabric utilizzassi di Yeoman generatore per Windows generare l'applicazione e il file manifesto del servizio e creare un pacchetto della soluzione. Sono disponibili informazioni usando questo strumento nel percorso bit.ly/2zZ334n.
Un singolo pacchetto dell'applicazione viene creato tale bundle di App MVC e API come tipi di servizio. Nei file manifesto del servizio, immettere i nomi di contenitore caricati nell'Hub Docker nei passaggi precedenti.
Si noti che manifesto del servizio del progetto API Web definisce un nome DNS del servizio che deve corrispondere al valore nel file appSettings. JSON del progetto MVC, da utilizzare nell'individuazione del servizio.
Il numero di istanze di ogni tipo di servizio (vale a dire, i progetti Web e API) nel manifesto è impostato a due. Indica a Service Fabric per avere due istanze di contenitore di quel tipo di servizio sempre in esecuzione nel cluster. Questo numero può essere modificato per soddisfare la distribuzione, o può essere impostato per la scalabilità automatica in un intervallo max e min.
Il manifesto del servizio supporta la nozione di un vincolo di posizionamento. Nel frammento di codice seguente, sul nome del tipo di nodo del cluster di Service Fabric a cui deve essere distribuito il servizio è definito un vincolo di posizionamento. Se non specificato, il pacchetto di codice potrebbe essere distribuito in tutti i tipi di nodo, incluso il tipo di nodo primario, nel cluster di Service Fabric. Tuttavia, intende ospitare solo i servizi Service Fabric piattaforma nel tipo di nodo primario.
<ServiceTypes>
<StatelessServiceType ServiceTypeName="censusapiType"
UseImplicitHost="true">
<PlacementConstraints>(NodeTypeName==nt-sfazvm0) </PlacementConstraints>
</StatelessServiceType>
</ServiceTypes>
Il nome del tipo di nodo nel modello di Azure Resource Manager (ARM) (illustrato più avanti) per distribuire il Cluster di Service Fabric deve corrispondere a quello nel vincolo di posizionamento del manifesto del servizio.
La distribuzione delle applicazioni in Service Fabric
A questo punto è possibile creare il cluster di Service Fabric e quindi distribuire i pacchetti dell'applicazione a esso.
Il primo passaggio è eseguire il provisioning di un database Cosmos DB, che può essere eseguito dal portale di Azure. Iniziare creando un database in Asia sud-orientale e abilitare la replica geografica per l'area Stati Uniti orientali 2. Selezionare l'opzione "Abilita scrittura in più aree" della procedura guidata.
Mantenuta la configurazione di coerenza di sessione, ovvero il valore predefinito per il database di Cosmos DB e l'impostazione che indicizza tutte le proprietà nello schema predefinita. È possibile selezionare solo le proprietà specifiche per l'indicizzazione se si preferisce, in base alle necessità per eseguire query sui dati.
Per gestire i possibili conflitti che si verificano all'esterno di abilitare la scrittura multimaster, ho utilizzato il valore predefinito, il criterio "last-writer-wins, risoluzione dei conflitti".
Successivamente, viene effettuato il provisioning di cluster di Service Fabric usando un modello ARM (bit.ly/2swVkI5 e bit.ly/2rBvFfi). Modello SF-Std-ELB-ZonalDeployment.Json distribuisce due cluster di zona in una rete virtuale esistente. Esistono alcuni prerequisiti per l'esecuzione di questo modello.
In primo luogo, usare un certificato archiviato in Azure Key Vault per la sicurezza da nodo a nodo del cluster. L'URL di identificazione personale, URL di insieme di credenziali delle chiavi e certificati da questo passaggio devono essere immesse nella sezione dei parametri del modello ARM, come illustrato nella figura 3. Questa operazione deve essere eseguita per ognuna delle aree separatamente, perché il cluster di Service Fabric e l'insieme di credenziali chiave di it deve trovarsi nella stessa area.
Figura 3 archiviare l'identificazione personale, Azure la chiave di insieme di credenziali di URL e l'URL certificato
"certificateThumbprint": {
"type": "string",
"defaultValue": "<Certificate Thumb print>
},
"sourceVaultValue": {
"type": "string",
"defaultValue": "/subscriptions/<SubscriptionId>/resourceGroups/
lpvmvmssrg/providers/Microsoft.KeyVault/vaults/<vaultname>”
},
"certificateUrlValue": {
"type": "string",
"defaultValue": "https://<vaultname>.vault.azure.net/secrets/
soloclustercert/<GUID>
}
}
In secondo luogo, viene generato un certificato autofirmato usando Open SSL. L'identificazione personale del certificato viene immesso nella sezione dei parametri del modello ARM:
"clientCertificateStoreValue": {
"type": "string",
"defaultValue": "<Client certificate thumbprint
},
Questo certificato viene usato in Jenkins per la connessione al cluster di Service Fabric per distribuire l'applicazione. Visualizzare bit.ly/2GfLHG0 per altre informazioni.
Si noti che questo articolo usa un certificato autofirmato a scopo illustrativo. Per le distribuzioni di produzione, si utilizzerà le credenziali di Azure per connettersi all'endpoint di gestione in modo sicuro e distribuire l'applicazione.
Per altre informazioni sulla sicurezza di Service Fabric, vedere bit.ly/2CeEzpi e bit.ly/2SR1E73.
I probe di integrità usati nel servizio di bilanciamento del carico per l'applicazione MVC e API Web devono essere configurati per HTTP, con i numeri di porta a destra e il percorso della richiesta, come illustrato nella figura4.
Figura 4, la configurazione di porte e i percorsi di richiesta
{
"name": "SFContainerProbe1",
"properties": {
"protocol": "Http",
"port": 5002,
"requestPath": "/api/family",
"intervalInSeconds": 5,
"numberOfProbes": 2
}
},
{
"name": "SFContainerProbe2",
"properties": {
"intervalInSeconds": 5,
"numberOfProbes": 2,
"port": 80,
"requestPath": "/",
"protocol": " Http "
}
}
Ecco le altre configurazioni più importanti nel modello ARM, specifico per le distribuzioni di zona:
• SKU standard viene scelto per tutti i bilanciamenti del carico usati nel cluster.
• SKU standard viene scelto per la risorsa indirizzo IP pubblico.
• La proprietà di zona di disponibilità deve essere specificata. Poiché si tratta di una distribuzione di zona, una singola zona è specificata nel valore della proprietà. Per la zona SF Cluster 1 in Asia sud-orientale, questo valore sarà "1" e per zona SF Cluster 2 in Asia sud-orientale, il valore sarà "2".
• La proprietà "SinglePlacementGroup" è impostata su "true".
• Per consentire l'individuazione del servizio nel cluster, il DNS di Service Fabric deve essere abilitato.
Figura 5 illustra come questi sono configurati nel modello ARM. Verificare che il modello sia distribuito correttamente e che i servizi illustrati nella figura 5 sono visibili nel portale di Azure.
.png "Risorse VMSS utilizzate nel modello ARM per la distribuzione di zona")
Figura 5 VMSS risorse utilizzate nel modello ARM per la distribuzione di zona
Si noti che le zone di disponibilità di Azure non sono ancora disponibili in tutte le aree di Azure. Inoltre, la funzionalità ha raggiunto la disponibilità generale (GA) in alcune aree, ma è solo disponibile in anteprima in altri.
A questo punto è possibile connettersi al cluster di Service Fabric. L'endpoint di gestione di Service Fabric viene distribuito dietro un servizio di bilanciamento del carico interno. Di conseguenza, per accedere a Service Fabric Explorer per distribuire l'applicazione, distribuire una macchina virtuale finestra di salto (VM) che esegue Windows Server 2016, nella stessa rete virtuale del cluster di Service Fabric o a un altro virtuale di rete che ha eseguito il peering a quella del grappolo.
Copiare il certificato per il client di amministrazione di Service Fabric (il certificato autofirmato che è stato creato in precedenza) all'archivio certificati utente sul salto casella della macchina virtuale. Durante l'avvio di Service Fabric Explorer, selezionare questo certificato quando viene richiesto.
Successivamente, eseguire il provisioning di Jenkins per distribuire l'applicazione. Per lo scenario in questo articolo, utilizzerò un'immagine del contenitore Docker in esecuzione Jenkins e il plug-in Service Fabric. Questa immagine verrà distribuita a una VM Ubuntu in Azure in esecuzione nella stessa rete virtuale del cluster di Service Fabric.
È possibile trovare altre informazioni sui passaggi necessari per scaricare, installare e configurare l'immagine del contenitore in bit.ly/2RRRt1Q.
Per preparare Jenkins per la connessione al cluster di Service Fabric, eseguito i passaggi aggiuntivi seguenti:
• Copiare il certificato per il client di amministrazione di Service Fabric (il certificato autofirmato creato in precedenza) nella directory principale nella VM Jenkins, usando strumenti come WinSCP.
• Avvio il contenitore di Jenkins in questa macchina virtuale ed eseguire il comando "docker exec" per copiare il certificato nella directory principale di Jenkins all'interno del contenitore.
Avviare Jenkins e accedere a http://<Public-IP-of-JenkinsVM>:8080 per configurare il plug-in Service Fabric.
In cui viene descritta la procedura per configurare il plug-in Service Fabric per Jenkins bit.ly/2UBVhWV. La configurazione "Post compilazione azioni" che è stata utilizzata per eseguire la distribuzione dell'applicazione per uno dei cluster di zona è illustrata nel figura 6. Aggiungere un'azione di compilazione Post aggiuntivo per il secondo cluster zona, allo stesso modo.
.png "Plug-in per Jenkins di Service Fabric")
Figura 6 Service Fabric plug-in per Jenkins
Attivare manualmente l'opzione di processo di compilazione in Jenkins e assicurarsi che l'azione post-trigger viene completato correttamente. Dalla VM jumpbox, avviare Service Fabric Explorer per verificare che l'applicazione viene distribuita in entrambi i cluster di zona. Figura 7Mostra Service Fabric Explorer dopo l'applicazione viene distribuita.
.png "L'Endpoint di gestione in Service Fabric Explorer")
Figura 7, l'Endpoint di gestione in Service Fabric Explorer
Ripetere questi passaggi per distribuire nella seconda area di Azure. Verificare che il file manifesto del servizio del progetto API venga modificato in modo che punti all'immagine contenitore del servizio API progettato per questa area. È importante ricordare che le due immagini del contenitore del servizio API hanno una priorità separata area durante la connessione a Cosmos DB e implementare le scritture tra più aree.
Esecuzione dell'applicazione
Per visualizzare l'applicazione distribuita in area 1, avviare i seguenti URL:
• http://<Public-IP-Address-LB Area1 > Avvia l'applicazione MVC
• http://<Public-IP-Address-LB Area1 >: famiglia 5002/api/avvia direttamente l'API Web. Il progetto MVC chiama l'API internamente Usa l'individuazione del servizio.
Un altro set di URL saranno disponibile per area 2.
Figura 8 Mostra la pagina dell'applicazione si accede tramite gli endpoint esposti dal servizio di ingresso principale di Azure. Si noterà una colonna denominata DataOrigin che indica il nome dell'area di scrittura del database Cosmos DB da cui è stato inserito il record, che presenta le funzionalità di scrittura in più aree di Cosmos DB.
.png "Applicazione di esempio Census")
Applicazione di censimento di esempio nella figura 8
Servizio di provisioning Azure ingresso principale
Usare il portale di Azure per effettuare il provisioning del servizio porta principale di Azure e aggiungere gli endpoint pubblici delle applicazioni MVC e API Web come back termina al servizio di ingresso principale.
I probe di integrità configurati nel servizio di ingresso principale verificare che, quando uno degli endpoint back-end non è accessibile, a causa di un'interruzione del servizio nel cui area o quando l'applicazione ottiene non risponde, le successive richieste vengono indirizzate a un altro integro. Impostazioni di configurazione nel figura 9 mostrano come gli endpoint dell'applicazione in due aree sono stati mappati a un singolo endpoint esposto dal servizio di ingresso principale. Anche se è possibile utilizzare Gestione traffico di Azure come alternativa per l'ingresso principale di Azure, ho scelto di implementare il qui quest'ultimo come fornisce Proxy inverso di livello 7, la terminazione SSL e routing delle richieste, che sono necessari in tali applicazioni.
.png "Configurazione di Azure di ingresso principale")
Figura 9 Azure porta d'ingresso configurazione
Troverai altre informazioni sulla creazione di una porta d'ingresso per App Web globali al bit.ly/2QXRkwu.
Conclusioni
In questo articolo ho illustrato come Azure Service Fabric può essere utilizzato per creare un pacchetto e distribuire applicazioni basate su contenitori Docker e implementare funzionalità di individuazione del servizio che sono fondamentali per un'architettura di microservizi e orchestrazione. Con il supporto per le zone di disponibilità in Azure, distribuito 2 dei cluster di Service Fabric di zona che si estendono su più Data Center in un'area per eliminare gli effetti di malfunzionamenti del Data Center.
Per aumentare la portata dell'applicazione, distribuito l'applicazione in più aree di Azure e sfruttare il più aree supporto di scrittura in Azure Cosmos DB, che assicura che non solo sono i livelli di applicazione senza stato con replica geografica, ma è anche il database effettivamente distribuita e replicato. Infine, per garantire che gli utenti di sperimentare la quantità minima di latenza durante l'accesso all'applicazione, ho implementato un singolo servizio di ingresso principale di Azure che indirizza le richieste all'endpoint dell'applicazione a destra. Per mostrare come è possibile implementare questa architettura con la quantità minima di un'interruzione aziendale e per garantire che i criteri di sicurezza vengono rispettati, ho illustrato il modo in cui CI e CD procedure consigliate possono essere implementati usando il servizio DevOps di Azure e Jenkins, rispettivamente e come Questi possono essere eseguiti entro i confini di una rete aziendale.
È possibile scaricare l'applicazione di esempio nella bit.ly/2Lra9Dm. Vedere "Prerequisiti Software" per informazioni sul software necessario per implementare l'applicazione di esempio.
Srikantan Sankaran è principal technical evangelist del team di un Partner commerciale in India, in base all'esterno di Bangalore. Egli funziona con numerosi fornitori di software indipendenti in India e consente di progettare e distribuire le proprie soluzioni in Microsoft Azure. Contattarlo all'indirizzo sansri@microsoft.com.
Grazie per i seguenti esperti Microsoft per la revisione dell'articolo: Sudhanva Huruli, Muni Pulipalyam