Preparare un cluster Windows per il deployment

Questa pagina descrive come preparare il cluster Windows per il deployment.

Prima di iniziare

Scegli e configura il tuo registry Docker

Nell'ambito del deployment, crei e carichi l'immagine Docker del tuo container in un registry Docker.

Per il registry Docker puoi scegliere di utilizzare:

  • Artifact Registry

  • Qualsiasi registry Docker che supporta l'autenticazione di base

La soluzione consigliata è utilizzare Artifact Registry nello stesso progetto del cluster di deployment. GKE può accedere al registry per impostazione predefinita. Per ulteriori informazioni, consulta i requisiti per l'integrazione con GKE.

Se vuoi utilizzare un registro Docker privato, scopri come configurarlo.

Configura i workload di cui è stata eseguita la migrazione in modo che utilizzino gMSA

I carichi di lavoro delle applicazioni Windows IIS sono spesso uniti ad Active Directory (AD) e operano utilizzando le identità di dominio. Durante la migrazione di queste VM ai container, i container stessi non sono uniti al dominio, ma i nodi del cluster Kubernetes di cui sono host possono essere uniti al dominio.

Quando esegui il deployment dei contenitori di cui è stata eseguita la migrazione in un cluster, puoi utilizzare un account servizio gestito di gruppo (gMSA). Utilizza gMSA per eseguire il contenitore all'interno di un'identità dell'account di servizio specifico. Collega un gMSA nel cluster Kubernetes come parte della configurazione del pod anziché come configurazione di identità statica all'interno dell'immagine del contenitore.

Migrate to Containers ti aiuta nella procedura di trasformazione dei carichi di lavoro. Migrate to Containers rileva automaticamente la configurazione dei pool di applicazioni IIS e aggiunge consigli al piano di migrazione generato. Puoi quindi valutare questi consigli e modificarli in base al tuo ambiente e ai tuoi requisiti specifici.

Se Migrate to Containers determina che la configurazione di un pool di applicazioni non richiede un account gMSA, mantiene la configurazione del pool di applicazioni originale. Ad esempio, quando utilizza un tipo di account integrato come ApplicationPoolIdentity, NetworkService, LocalSystem o LocalService.

Per supportare gMSA in un contenitore Windows sottoposto a migrazione, devi:

  1. Modifica il piano di migrazione per impostare le proprietà necessarie per configurare il contenitore sottoposto a migrazione in modo che utilizzi un gMSA.

  2. Configura il cluster di destinazione che ospita il contenitore di cui è stato eseguito il deployment.

Configura un cluster di destinazione per supportare gMSA

Collega un gMSA nel cluster Kubernetes come parte della configurazione del pod, piuttosto che come configurazione di identità statica all'interno dell'immagine container.

Per configurare un cluster che ospita il contenitore Windows sottoposto a migrazione per supportare gMSA, devi disporre di:

  1. Active Directory è stato configurato per consentire alle VM di partecipare automaticamente a un dominio.

  2. gMSA configurato per pod e container Windows.

Per ulteriori informazioni, consulta le seguenti risorse:

Esegui il deployment di un contenitore quando archivi i certificati SSL come secret di Kubernetes

Ti consigliamo di utilizzare Cloud Load Balancing, Ingress o Cloud Service Mesh come frontend HTTPS per proteggere l'accesso esterno al tuo container di cui è stato eseguito il deployment. Questa opzione ti consente di proteggere le comunicazioni esterne senza includere certificati all'interno del cluster. Per saperne di più, consulta la sezione Personalizzare un piano di migrazione.

Puoi anche archiviare i certificati Secure Sockets Layer (SSL) come secret Kubernetes e montarli in fase di esecuzione nel contenitore.

Per utilizzare i secret di Kubernetes:

  1. Crea un file PFX con il certificato e la password.

  2. Crea un file YAML di configurazione che definisce l'accesso al sito:

    sites:
 - sitename: "sitename"
   sslport: 443
   pfxpath: c:\sslconfig\pfx
   password: "password"
   thumbprint: "3e858d0551fc0536f52d411dad92b680a4fad4da"

    Dove:

    • sitename specifica il nome del sito configurato per l'utilizzo di SSL. La proprietà sites può contenere più voci sitename.

    • sslport specifica la porta da ascoltare per le connessioni SSL (in genere 443).

    • pfxpath specifica il percorso del file PFX. Configuralo nell'ambito del volumeMounts del deployment del pod.

    • password specifica la password per il file PFX.

    • thumbprint specifica l'impronta SHA-1 del file PFX che può essere recuperata utilizzando il comando PowerShell:

      Get-PfxCertificate -FilePath "path to pfx"

      In alternativa, visualizzalo in Gestore dei certificati di Windows.

  3. Crea il secret Kubernetes:

    kubectl create secret generic secret-name --from-file=pfx=path-to-pfx --from-file=config=path-to-config

  4. Crea il volume e il relativo montaggio durante il deployment dell'immagine:

    apiVersion: v1
kind: Pod
metadata:
 name: iis-pod
 labels:
   app: iis-server-simple
 spec:
   nodeSelector:
     kubernetes.io/os: windows
   containers:
   - name: iis-server
     image: your-image-url
     volumeMounts:
     - name: ssl-secret
       mountPath: c:\sslconfig
     env:
     - name: M4A_CERT_YAML
       value: c:\sslconfig\config
   volumes:
   - name: ssl-secret
     secret:
       secretName: secret-name

    Dove:

    • mountPath è lo stesso percorso specificato da pfxpath nel file di configurazione creato nel passaggio 2.
    • M4A_CERT_YAML è una variabile di ambiente impostata sul percorso completo del file YAML di configurazione che hai creato nel passaggio 2.
    • secret-name è il nome del secret creato nel passaggio 3.

Configura SSL

Ti consigliamo di non memorizzare le chiavi private dei certificati SSL all'interno di un'immagine contenitore, in quanto sono accessibili a chiunque le legga. Migrate to Containers offre diversi modi per gestire SSL per Windows.

Utilizza un certificato autofirmato generato automaticamente

Per impostazione predefinita, a un contenitore Windows con un'associazione HTTPS viene assegnato un certificato autofirmato generato automaticamente all'inizializzazione del contenitore Docker. Questa configurazione ti consente di testare il tuo carico di lavoro sottoposto a migrazione, ma non può essere utilizzata in un ambiente di produzione. Il certificato è autofirmato e rigenerato ogni volta che viene eseguito il contenitore.

Consigliato: utilizza Cloud Load Balancing, Ingress o Cloud Service Mesh

Puoi personalizzare le associazioni nel piano di migrazione in modo che utilizzino HTTP. Quindi, utilizza Cloud Load Balancing, Ingress o Cloud Service Mesh come frontend HTTPS per proteggere l'accesso esterno. Questa opzione ti consente di proteggere la comunicazione esterna senza includere alcun certificato all'interno del cluster.

  • Per personalizzare il vincolo, modifica la definizione di site nel piano di migrazione che rappresenta la migrazione per impostare protocol su http:

    sites:
  site:
  - applications:
    - path: /
      virtualdirectories:
        - path: /
          physicalpath: '%SystemDrive%\inetpub\wwwroot'
          bindings:
          - port: 8080
            protocol: http
          name: Default Web Site

Puoi quindi inoltrare le richieste dall'interfaccia frontend HTTPS al percorso e alla porta HTTP del carico di lavoro Windows.

Memorizza i certificati SSL come secret Kubernetes

Ti consigliamo di utilizzare Cloud Load Balancing, Ingress o Cloud Service Mesh come frontend HTTPS per proteggere l'accesso esterno. Tuttavia, puoi anche memorizzare i certificati SSL come secret Kubernetes e montarli in fase di esecuzione nel contenitore.

Per utilizzare i certificati SSL archiviati come secret di Kubernetes, devi modificare l'immagine di deployment del contenitore. Per ulteriori informazioni, consulta Eseguire il deployment di un contenitore quando si archiviano i certificati SSL come secret di Kubernetes.

Configurare il logging in Cloud Logging

Migrate to Containers utilizza lo strumento LogMonitor per estrarre i log da un container Windows e inoltrarli al tuo cluster GKE. Questi log vengono poi inoltrati automaticamente a Cloud Logging, che fornisce una suite di strumenti per monitorare i contenitori.

Per impostazione predefinita, Migrate to Containers attiva la registrazione di IIS per monitorare i log di IIS e inoltra anche i log degli eventi di sistema o dell'applicazione a Cloud Logging.

Configurazione logging

L'espansione del file artifacts.zip generato crea diverse directory, tra cui la directory m4a. La directory contiene una cartella per ogni immagine. Nella directory m4a è incluso il file LogMonitorConfig.json che puoi modificare per controllare il logging.

Per saperne di più sulla modifica di LogMonitorConfig.json, consulta Creare un file di configurazione.

Impostare gli ACL

Alcune applicazioni IIS richiedono di impostare autorizzazioni specifiche per gli elenchi di controllo dell'accesso dell'accesso (ACL) su file e cartelle affinché le applicazioni funzionino correttamente. Migrate to Containers esegue automaticamente la scansione di tutte le applicazioni IIS migrate e aggiunge eventuali autorizzazioni specifiche definite nella VM di origine che si applicano agli account IIS (l'account IUSR e il gruppo IIS_IUSRS) e le applica ai file e alle directory copiati nell'immagine del contenitore generata.

Poiché le immagini container di Windows non supportano l'impostazione delle ACL nell'ambito del comando COPY di Docker, le ACL vengono impostate in uno script denominato set_acls.bat. Migrate to Containers crea automaticamente set_acls.bat nella directory dell'immagine generata per la tua applicazione Windows specifica. Migrate to Containers chiama quindi set_acls.bat quando esegui il comando docker build.

Modifica set_acls.bat per aggiungere o rimuovere autorizzazioni personalizzate oppure modifica le autorizzazioni che non sono correlate a utenti IIS specifici e che pertanto non sono state rilevate da Migrate to Containers.

Lo script utilizza lo strumento integrato di Windows icacls per impostare le autorizzazioni.

Informazioni sulla cache assembly globale di .NET

Migrate to Containers esegue la scansione della cache assembly globale .NET (GAC) dell'immagine di origine per le risorse .NET installate sulla macchina di origine e non disponibili nelle immagini ufficiali. Qualsiasi DLL rilevata viene copiata nel contesto Docker e installata nell'ambito della creazione dell'immagine di destinazione da uno script di utilità install_gac.ps1.

Tutti gli assembly .NET vengono copiati nel contesto Docker nella directory m4a\gac. Per rimuovere gli assembly dall'immagine, eliminali dalla directory m4a\gac.

Registrazione della DLL dell'oggetto COM

Le DLL che espongono oggetti COM vengono analizzate e registrate automaticamente. Durante la fase di estrazione, i file copiati vengono analizzati per rilevare le DLL registrate come oggetti COM, che vengono poi registrate nel contenitore.

Questo processo avviene senza input utente. Tuttavia, puoi influire su questo processo aggiungendo altre DLL da copiare. Se necessario, queste DLL vengono controllate e registrate a loro volta.

Passaggi successivi