Distribuzioni automatizzate per servizio Azure Kubernetes (servizio Azure Kubernetes)

Le distribuzioni automatizzate semplificano il processo di configurazione di un'azione GitHub o di una pipeline di Azure DevOps, semplificando la creazione di una pipeline di distribuzione continua per l'applicazione nel servizio Azure Kubernetes. Dopo la connessione, ogni nuovo commit attiva automaticamente la pipeline, recapitando facilmente gli aggiornamenti all'applicazione. È possibile portare i propri file di distribuzione per una rapida creazione della pipeline o generare Dockerfile e manifesti Kubernetes per containerizzare e distribuire applicazioni non in contenitori con un impegno minimo.

Prerequisiti

• Un account GitHub o un'organizzazione Azure DevOps.
• Un cluster servizio Azure Kubernetes. Se non ne è disponibile uno, è possibile crearne uno seguendo la procedura descritta in Distribuire un cluster del servizio Azure Kubernetes .If you't have one, you can create one using the steps in Deploy an servizio Azure Kubernetes (AKS) cluster.
• Un'istanza di Registro Azure Container. Se non ne è disponibile uno, è possibile crearne uno seguendo la procedura descritta in Integrare Registro Azure Container (ACR) con un cluster servizio Azure Kubernetes (AKS).
• Applicazione da distribuire.

Connettersi al repository del codice sorgente

Creare un flusso di lavoro di distribuzione automatizzato e autorizzarlo a connettersi al repository del codice sorgente desiderato.

1. Nel portale di Azure, passare alla risorsa del cluster del servizio Azure Kubernetes.
2. Nel menu del servizio, in Impostazioni, selezionare Distribuzioni>automatiche Crea.
3. In Dettagli repository immettere un nome per il flusso di lavoro, quindi selezionare GitHub o ADO per il percorso del repository.
4. Selezionare Autorizza l'accesso per connettersi al repository desiderato.
5. Scegliere repository e ramo e quindi selezionare Avanti.

Scegliere la configurazione dell'immagine del contenitore

Per preparare un'applicazione per Kubernetes, è necessario compilarla in un'immagine del contenitore e archiviarla in un registro contenitori. Si usa un Dockerfile per fornire istruzioni su come compilare l'immagine del contenitore. Se il repository del codice sorgente non ha già un Dockerfile, le distribuzioni automatizzate possono generarne una automaticamente. In caso contrario, è possibile usare un Dockerfile esistente.

Senza un Dockerfile esistente

Usare le distribuzioni automatizzate per generare un Dockerfile per molti linguaggi e framework, ad esempio Go, C#, Node.js, Python, Java, Gradle, Clojure, PHP, Ruby, Erlang, Swift e Rust. Il supporto linguistico è basato su ciò che è disponibile in draft.sh.

1. Selezionare Auto-containerize (generate Dockerfile) per la configurazione del contenitore.
2. Selezionare il percorso in cui salvare il Dockerfile generato nel repository.
3. Selezionare l'ambiente dell'applicazione dall'elenco di linguaggi e framework supportati.
4. Immettere la porta dell'applicazione.
5. Specificare il percorso del contesto di compilazione Dockerfile .
6. Selezionare un Registro Azure Container esistente o crearne uno nuovo. Questo registro viene usato per archiviare l'immagine dell'applicazione compilata.

Con un Dockerfile esistente

Se il repository di codice ha già un Dockerfile, è possibile selezionarlo da usare per compilare l'immagine dell'applicazione.

1. Selezionare Dockerfile esistente per la configurazione del contenitore.
2. Seleziona il Dockerfile dal tuo repository.
3. Immettere il contesto di compilazione Dockerfile per passare il set di file e directory al processo di compilazione. Questi file vengono usati per compilare l'immagine e sono inclusi nell'immagine finale, a meno che non vengano ignorati da un .dockerignore file.
4. Selezionare un Registro Azure Container esistente o crearne uno nuovo. Questo registro viene usato per archiviare l'immagine dell'applicazione compilata.

Scegliere la configurazione del manifesto Kubernetes

Annotazioni

L'opzione Genera manifesti supporta anche funzionalità avanzate come l'integrazione di Service Connector, le risorse di ingresso generate automaticamente e i file manifesto Kubernetes più dettagliati e personalizzabili.

Un'applicazione in esecuzione in Kubernetes è costituita da molti componenti primitivi kubernetes. Questi componenti descrivono l'immagine del contenitore da usare, il numero di repliche da eseguire, se è necessario un indirizzo IP pubblico per esporre l'applicazione e così via. Per altre informazioni, vedere la documentazione ufficiale di [Kubernetes][kubernetes-documentation]. Se il repository del codice sorgente non dispone già dei manifesti Kubernetes di base da distribuire, le distribuzioni automatizzate possono generarle automaticamente. In caso contrario, è possibile usare un set di manifesti esistenti. È anche possibile scegliere un grafico Helm esistente.

Usare manifesti Kubernetes esistenti

Se il repository di codice ha già un Dockerfile, è possibile selezionarlo da usare per compilare l'immagine dell'applicazione.

1. Selezionare l'opzione Usa file esistenti di manifesto Kubernetes per la distribuzione per le opzioni di distribuzione.
2. Selezionare il file o la cartella manifest di Kubernetes dal repository.
3. Seleziona Avanti.

Usare un grafico Helm esistente

Se il repository di codice ha già un grafico Helm, è possibile selezionarlo da usare per compilare l'immagine dell'applicazione.

1. Selezionare Usa Helm chart esistente per le opzioni di distribuzione.
2. Selezionare la cartella Percorso dei grafici dal repository.
3. Selezionare il percorso del file Values.yaml dal repository.
4. Facoltativamente, specificare gli override del grafico Helm.
5. Seleziona Avanti.

Generare manifesti

Usare le distribuzioni automatiche per generare un set di file manifesto Kubernetes di base per rendere operativa l'applicazione. Al momento, le distribuzioni automatizzate creano un Deploymentoggetto , un Servicee un oggetto ConfigMap.

I manifesti generati sono progettati per applicare le raccomandazioni di [misure di salvaguardia della distribuzione][misure di sicurezza della distribuzione], ad esempio:

• Generazione automatica di sonde di liveness, disponibilità e avvio [kubernetes-probes].
• Preferenza per [pod anti-affinity][pod-anti-affinity] e [vincoli di diffusione topologica][vincoli di distribuzione della topologia] che distribuiscono le repliche su nodi diversi per migliorare la resilienza.
• Applicazione del RuntimeDefault [profilo di elaborazione sicuro][seccomp-profile] che stabilisce un livello aggiuntivo di protezione dalle vulnerabilità comuni delle chiamate di sistema sfruttate da attori malintenzionati.
• Eliminazione di tutte le funzionalità di Linux, consentendo solo un set limitato in conformità con la baseline [Standard di sicurezza dei pod Kubernetes][kubernetes-pod-security-standards].

I manifesti Kubernetes generati supportano anche l'aggiunta di un connettore di ingresso e di servizio. Queste integrazioni facoltative verranno illustrate di seguito.

Per generare manifesti Kubernetes:

1. Selezionare Genera file di distribuzione dell'applicazione per le opzioni di distribuzione.
2. Immettere la porta dell'applicazione. Questa porta viene usata nell'oggetto generato Service.
3. Selezionare il percorso in cui salvare i manifesti Kubernetes generati nel repository.
4. (Facoltativo) Modificare i valori applicazione e configurazione o servizio nel file manifesto selezionando Cambia.
   1. Se non si vogliono usare le impostazioni predefinite consigliate dal servizio Azure Kubernetes, è possibile modificare vari valori del file manifesto, ad esempio:
      • Richieste di memoria/CPU
      • Limiti di memoria/CPU
      • Probe di idoneità e avvio TCP
      • Numero minimo/massimo di repliche di scala per HPA
      • Utilizzo della memoria/CPU per HPA
      • Porta/porta di destinazione del servizio di bilanciamento del carico
5. Seleziona Avanti.

(Facoltativo) Usare un ingresso gestito e/o Un connettore di servizi

Quando si generano manifesti Kubernetes con distribuzioni automatizzate, è possibile abilitare il routing delle app per configurare un controller di ingresso per l'applicazione. È anche possibile usare Service Connector per creare una nuova connessione o integrare facilmente l'app con un back-end del servizio di Azure esistente.

Esporre l'ingresso

Il routing delle app offre un controller d'ingresso basato su NGINX completamente gestito, completo di crittografia SSL/TLS integrata utilizzando i certificati archiviati in Azure Key Vault e gestione delle zone DNS tramite Azure DNS. Quando si usano distribuzioni automatizzate, il comando esponi ingresso si integra perfettamente con il routing delle app, rendendo più semplice esporre l'applicazione al traffico esterno con un nome DNS sicuro e personalizzato, con una configurazione minima.

1. Selezionare la casella Esponi ingresso .
2. Scegliere tra un controller di ingresso esistente o un nuovo controller di ingresso.
3. Scegliere tra l'uso di un controller di ingress SSL/TLS abilitato o non sicuro.
4. (Facoltativo) Immettere i dettagli del certificato se si sceglie un controller di ingresso abilitato per SSL/TLS .
5. Scegliere tra l'uso di DNS di Azure o di un provider di terze parti.
6. Immettere la zona DNS di Azure e il nome del sottodominio.

Usare Service Connector

Service Connector consente di connettere l'applicazione ad altri servizi di Azure di backup. Configurando le impostazioni di rete e le variabili di connessione appropriate, può inserire automaticamente le credenziali nell'applicazione tramite oggetti segreti Kubernetes senza alcuna configurazione manuale. Per altre informazioni su Service Connector, vedere la documentazione ufficiale.

1. Selezionare una connessione esistente o Crea una connessione.
2. Quando si crea una nuova connessione, assicurarsi di compilare tutti i campi appropriati.

(Facoltativo) Aggiungere variabili di ambiente

Definire le variabili di ambiente per un contenitore in Kubernetes specificando coppie nome-valore. Le variabili di ambiente sono importanti perché consentono di semplificare la gestione delle impostazioni, la gestione sicura delle informazioni riservate e la flessibilità in tutti gli ambienti.

Esaminare la configurazione e la distribuzione

Esaminare la configurazione per l'applicazione e i manifesti kubernetes, quindi selezionare Distribuisci. Verrà generata una richiesta pull sul repository selezionato, quindi non uscire dalla pagina di distribuzione.

Esaminare e unire una richiesta pull

Al termine della distribuzione, selezionare Visualizza richiesta pull per visualizzare i dettagli della richiesta pull generata nel repository di codice.

1. Esaminare le modifiche in File modificate e apportare le modifiche desiderate.
2. Selezionare Merge pull request per unire le modifiche nel repository di codice.

La fusione della modifica avvia il workflow di GitHub Actions che costruisce l'applicazione in un'immagine container, la archivia nel Registro dei Contenitori di Azure e la distribuisce al cluster.

Controllare le risorse distribuite

Al termine della pipeline, è possibile esaminare il kubernetes Service creato nel portale di Azure selezionando Servizi e ingresso nella sezione Risorse Kubernetes del menu del servizio.

Se si seleziona l'indirizzo IP esterno , verrà aperta una nuova pagina del browser con l'applicazione in esecuzione.

Eliminare risorse

Al termine dell'operazione con il cluster, seguire questa procedura per eliminarlo per evitare di incorrere in addebiti di Azure:

1. Nel portale di Azure passare a Distribuzioni automatizzate
2. Selezionare ... nella pipeline di propria scelta.
3. Selezionare Elimina.