Questa pagina fornisce una panoramica su come eseguire il deployment delle app .NET su Google Cloud e indicazioni su come scegliere l'approccio di deployment giusto per la tua app.
Introduzione
Il framework Microsoft .NET fornisce un ricco insieme di strumenti e librerie per lo sviluppo di app. Con l'avvento del supporto di Docker su Windows e la possibilità di eseguire app .NET su Linux, le app .NET ora possono supportare anche una serie di target di deployment.
Per uno sviluppo e test efficienti, puoi automatizzare il deployment dell'app e renderlo parte di una pipeline di integrazione continua e distribuzione continua (CI/CD). Tuttavia, per scegliere gli strumenti giusti e creare una pipeline CI/CD, devi prima identificare come eseguire l'app in produzione e quale approccio di deployment vuoi adottare.
Non esiste un modo migliore per eseguire il deployment di un'app .NET su Google Cloud. Le opzioni di deployment migliori per te dipendono dall'app e dai tuoi requisiti. Ad esempio, se la tua app richiede .NET Framework completo o deve essere eseguita su IIS, il deployment si baserà su Windows. D'altra parte, se la tua app può essere eseguita con la funzionalità supportata da .NET, hai la possibilità di eseguire il deployment in Linux.
Questa pagina esamina i vari modi in cui puoi eseguire app .NET e implementarle su Google Cloud, incluse le condizioni in cui ogni opzione è adatta. Alla fine, le opzioni di deployment vengono riepilogate in un albero decisionale per aiutarti a decidere quali Google Cloud componenti e approcci sono più adatti per la tua app .NET.
Modelli di deployment
Esistono due modi di base per eseguire il deployment automatico di un'app. Il pacchetto di deployment viene trasferito ai server delle app oppure i server delle app estraggono il pacchetto dell'app da una posizione nota. Le sezioni seguenti illustrano le differenze tra questi due modelli.
Deployment basati sul push
In un deployment basato sul push, l'artefatto di deployment, un file zip, un pacchetto NuGet o un altro artefatto, è inizialmente disponibile solo per un server di deployment. Il server di deployment può essere una macchina dedicata o un ruolo assunto dal sistema CI.
Per eseguire un deployment, un processo sul server di deployment si connette a un server delle app, copia l'artefatto di deployment e ne avvia l'installazione. Se è presente più di un server delle app, questo processo viene ripetuto in parallelo o, più comunemente, in sequenza in modo che gli artefatti vengano distribuiti a tutti i server delle app.
Il seguente diagramma illustra questo flusso.
Sono disponibili diversi strumenti di gestione della configurazione che ti consentono di automatizzare i deployment in questo modo. Alcuni di questi strumenti seguono un approccio imperativo in cui la sequenza dei passaggi di deployment è definita in modo simile a uno script. Sebbene questo approccio sia intuitivo, è soggetto a deriva della configurazione, ovvero dopo un certo periodo di tempo, gli stati di più macchine potrebbero non essere identici e potrebbero non riflettere completamente lo stato previsto. Molti strumenti, pertanto, ti consentono di definire lo stato che vuoi ottenere, lasciando allo strumento il compito di capire i passaggi necessari per realizzarlo.
Su Windows, gli strumenti comunemente utilizzati per questo modello di deployment includono:
- Microsoft Web Deploy, uno strumento senza costi progettato per eseguire il deployment remoto di app web sui server IIS.
- Octopus Deploy, software commerciale che consente di orchestrare le implementazioni in modo flessibile su flotte di macchine.
- Microsoft Team Foundation Server o agenti Azure Pipelines, che si integrano direttamente con la funzionalità di gestione delle release di TFS o Azure Pipelines.
- Windows PowerShell Desired State Configuration (DSC), una funzionalità integrata di Windows Server 2012 R2 e versioni successive.
Gli strumenti open source più utilizzati includono Ansible, Chef Infra e Puppet. Sebbene questi strumenti siano destinati principalmente a Linux, sono anche in grado di eseguire il deployment di destinazioni Windows.
Sicurezza
Affinché il server di deployment possa eseguire il push di un deployment su un server delle app, deve essere disponibile un canale secondario. Ad esempio, Web Deploy e Octopus Deploy utilizzano un protocollo e una porta personalizzati per questa attività, mentre Ansible utilizza SSH.
Indipendentemente dal protocollo utilizzato dallo strumento, è fondamentale che la comunicazione sia sicura per impedire agli autori di attacchi di utilizzare il canale secondario per distribuire app dannose. Ancora più importante, la comunicazione sicura richiede che il server di deployment sia in grado di autenticarsi con il server delle app.
SSH può utilizzare l'autenticazione a chiave pubblica. Se utilizzi una configurazione IAM appropriata, puoi consentire a Google Cloud di occuparsi automaticamente della distribuzione della chiave pubblica utilizzata per SSH ai server delle app. Tuttavia, se non utilizzi IAM, Google Cloud non può gestire la chiave per te e devi gestire questa attività autonomamente.
Un'opzione è Active Directory. Se sia il server di deployment che il server delle app eseguono Windows e sono membri di un dominio Active Directory, l'autenticazione viene gestita utilizzando Kerberos. Tuttavia, l'esecuzione di un ambiente Active Directory tollerante agli errori richiede almeno due istanze VM aggiuntive per eseguire i domain controller. Se la configurazione utilizza la scalabilità automatica, anche tutti i server devono essere uniti dinamicamente al dominio, il che rallenta il processo di avvio di un server. La scalabilità automatica può anche portare all'accumulo di oggetti computer obsoleti nella directory, richiedendo una logica di scavenging aggiuntiva. Se utilizzi Active Directory in un ambiente basato su cloud, devi tenere conto di questi fattori aggiuntivi.
In assenza di Active Directory, l'autenticazione deve essere gestita utilizzando NTLM o con altri mezzi, ad esempio l'autenticazione di base HTTP. Entrambi gli approcci richiedono che le credenziali vengano mantenute sincronizzate tra il server di deployment e i server delle app e che vengano archiviate in modo sicuro. Entrambe queste attività possono rivelarsi difficili.
Indipendentemente dal fatto che utilizzi Linux o Windows, la protezione della comunicazione tra i server di deployment e delle app richiede meccanismi separati da IAM. Tuttavia, l'utilizzo di più meccanismi per controllare l'accesso ai sistemi aumenta la complessità complessiva e quindi il rischio di errori di configurazione accidentali.
Aggiornamenti del sistema operativo
È importante poter eseguire il deployment in modo efficiente di nuove versioni di pacchetti di app sui server delle app, ma è anche fondamentale gestire il sistema operativo sottostante su questi server. Ciò significa installare patch di sicurezza. Per i parchi server più grandi, devi automatizzare questo processo in modo da ridurre al minimo il rischio e il numero di server non disponibili durante l'aggiornamento.
Puoi anche utilizzare un approccio push per gli aggiornamenti del sistema operativo, in cui il server di deployment attiva un aggiornamento del sistema operativo sui server delle app. Su Linux, è comune utilizzare SSH per eseguire da remoto i comandi di aggiornamento. Su Windows, PowerShell remoting (che si basa su WinRM) è una scelta comune. Per entrambi i meccanismi, devi essere in grado di autenticarti in modo sicuro e di archiviare le credenziali in modo sicuro.
Scalabilità automatica
In un ambiente statico in cui il numero di server delle app non cambia, il server di deployment conosce in anticipo tutte le destinazioni di deployment. In un ambiente cloud, spesso è utile scalare automaticamente il numero di server delle app. Ciò crea due sfide quando utilizzi implementazioni basate sul push:
- Quando viene aggiunto un nuovo server delle app, registralo con il server di deployment per assicurarti che venga incluso nei deployment futuri.
- Il nuovo server deve ricevere il deployment iniziale.
Un evento di scalabilità automatica non viene avviato dal server di deployment. Viene invece avviato dal gruppo di istanze gestite sottostante, che funziona a un livello inferiore a quello del server di deployment.
La nuova istanza del server delle app deve registrarsi con il server di deployment e attivare un deployment prima che possa gestire le richieste. Il seguente diagramma illustra questo processo.
Affinché questo approccio funzioni, non è sufficiente che il server di deployment possa contattare e autenticarsi con i server delle app. Anche i server delle app devono contattare il server di deployment ed eseguire l'autenticazione.
Infine, il server appena lanciato deve disporre anche delle patch di sicurezza del sistema operativo più recenti. L'avvio di un aggiornamento durante il processo di scalabilità automatica ritarderebbe in modo significativo il processo. Pertanto, l'immagine da cui viene creata la VM server delle app deve avere già installato gli aggiornamenti. Puoi gestire questa impostazione in due modi:
- Utilizza le immagini pubbliche fornite da Google Cloud, che vengono mantenute aggiornate da Google. Poiché queste immagini contengono solo il sistema operativo, devi gestire qualsiasi personalizzazione (il codice dell'app, le utilità e le configurazioni del sistema operativo) utilizzando script di avvio o nell'ambito del deployment dell'app.
- Mantieni un'immagine del sistema operativo personalizzata e aggiornala. In questo modo puoi applicare personalizzazioni all'immagine, ma aumenta la complessità complessiva della gestione delle implementazioni.
L'esecuzione di deployment basati sul push è intuitiva, ma può comportare una complessità sostanziale se si prendono in considerazione sicurezza, aggiornamenti del sistema operativo e scalabilità automatica. La sezione successiva tratta i deployment basati sul pull, che sono il modo più cloud-native per affrontare i deployment.