prepara un cluster Windows per il deployment

In questa pagina vengono descritti alcuni scenari che potrebbero richiedere la personalizzazione degli artefatti di migrazione.

Prima di iniziare

Questo documento presuppone che tu abbia completato la migrazione.

Assicurati che il cluster di destinazione abbia accesso in lettura al registro Docker

Nell'ambito di una migrazione, Migrate to Containers carica in un registro Docker le immagini Docker che rappresentano una VM di cui è stata eseguita la migrazione. Queste immagini Docker rappresentano i file e le directory della VM di migrazione.

Per il registro Docker puoi scegliere di utilizzare:

Per ulteriori informazioni, consulta Definizione dei repository di dati.

Esegui il deployment di un carico di lavoro in un progetto Google Cloud diverso da quello utilizzato per la migrazione

Spesso nel tuo ambiente sono presenti più progetti Google Cloud. Se esegui una migrazione in un progetto Google Cloud, ma poi vuoi eseguire il deployment del carico di lavoro di cui è stata eseguita la migrazione a un cluster in un altro progetto, devi assicurarti di aver configurato correttamente le autorizzazioni.

Ad esempio, esegui la migrazione nel progetto A. In questo caso, il carico di lavoro di cui è stata eseguita la migrazione viene copiato in un bucket Container Registry nel progetto A. Ad esempio:

gcr.io/project-a/image_name:image_tag

Poi devi eseguire il deployment del carico di lavoro in un cluster nel progetto B. Se non configuri correttamente le autorizzazioni, il pod del carico di lavoro non verrà eseguito perché il cluster nel progetto B non ha accesso al pull delle immagini per il progetto A. Quindi, vedrai un evento sul pod contenente un messaggio nel modulo:

Failed to pull image "gcr.io/project-a/image_name:image_tag...
pull access denied...
repository does not exist or may acquire 'docker login'...

Tutti i progetti che hanno abilitato l'API Compute Engine hanno un account di servizio predefinito di Compute Engine, che ha il seguente indirizzo email:

PROJECT_NUMBER-compute@developer.gserviceaccount.com

Dove PROJECT_NUMBER è il numero del progetto B.

Per risolvere questo problema, assicurati che l'account di servizio predefinito di Compute Engine per il progetto B disponga delle autorizzazioni necessarie per accedere al bucket Container Registry. Ad esempio, puoi utilizzare il seguente comando gsutil per abilitare l'accesso:

gsutil iam ch serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com:objectViewer gs://artifacts.project-a.appspot.com

Esegui il deployment dei carichi di lavoro sul cluster di elaborazione

Puoi eseguire il deployment del carico di lavoro di cui è stata eseguita la migrazione sullo stesso cluster utilizzato per eseguire la migrazione, definito cluster di elaborazione Migrate to Containers. Nella maggior parte delle situazioni non è necessario eseguire alcuna configurazione aggiuntiva sul cluster di elaborazione perché il cluster richiede già l'accesso in lettura o scrittura al registro Docker per eseguire una migrazione.

Eseguire il deployment su un cluster di destinazione utilizzando Container Registry come registro Docker

Per assicurarti che un cluster di destinazione abbia accesso al Container Registry, crea un secret Kubernetes contenente le credenziali necessarie per accedere a Container Registry:

  1. Crea un account di servizio per eseguire il deployment di una migrazione come descritto in Creazione di un account di servizio per l'accesso a Container Registry e Cloud Storage.

    Questo processo richiede il download di un file di chiave JSON denominato m4a-install.json.

  2. Crea un secret Kubernetes contenente le credenziali necessarie per accedere a Container Registry:

    kubectl create secret docker-registry gcr-json-key \
 --docker-server=gcr.io --docker-username=_json_key --docker-password="$(cat ~/m4a-install.json.json)" \
 --docker-email=account@project.iam.gserviceaccount.com

    dove:

    • docker-registry specifica il nome del secret di Kubernetes, gcr-json-key in questo esempio.
    • docker-server=gcr.io specifica Container Registry come server.
    • docker-username=_json_key specifica che il nome utente è contenuto nel file di chiavi JSON.
    • docker-password specifica di utilizzare una password estratta dal file di chiavi JSON.
    • docker-email specifica l'indirizzo email dell'account di servizio.

  3. Imposta il secret di Kubernetes in uno dei seguenti modi:

    • Modifica del valore predefinito di imagePullSecrets:

      kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "gcr-json-key"}]}'

    • Modifica del file deployment_spec.yaml per aggiungere il valore imagePullSecrets alla definizione di spec.template.spec. Quando utilizzi WebSphere tradizionale, il file YAML di deployment è denominato twas_deployment_spec.yaml, liberty_deployment_spec.yaml o openliberty_deployment_spec.yaml, a seconda del tuo target.

      spec:
  containers:
  - image: gcr.io/PROJECT_ID/mycontainer-instance:v1.0.0
    name: mycontainer-instance
    ...
  volumes:
  - hostPath:
      path: /sys/fs/cgroup
      type: Directory
    name: cgroups
  imagePullSecrets:
  - name: gcr-json-key

      Sostituisci PROJECT_ID con l'ID progetto.

  4. Esegui il deployment del secret del carico di lavoro, se secrets.yaml esiste. Esisterà un file secret per i carichi di lavoro basati su Tomcat e per i carichi di lavoro tradizionali di WebSphere con Liberty. Il file Liberty è denominato liberty-secrets.yaml.

    kubectl apply -f secrets.yaml

Esegui il deployment su un cluster di destinazione utilizzando un registro Docker con autenticazione di base

Se utilizzi un registro Docker per archiviare le immagini di migrazione, questo deve supportare l'autenticazione di base mediante nome utente e password. Poiché esistono molti modi per configurare una connessione di sola lettura a un registro Docker, devi utilizzare il metodo appropriato per la piattaforma del cluster e il registro Docker.

Configura i carichi di lavoro di cui è stata eseguita la migrazione per utilizzare gMSA

I carichi di lavoro delle applicazioni Windows IIS sono spesso uniti ad Active Directory (AD) e gestiti da identità di dominio. Durante la migrazione di queste VM ai container, i container stessi non sono uniti a un dominio, ma piuttosto i nodi cluster Kubernetes host possono essere uniti a un dominio.

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

Migrate to Containers ti aiuta nel processo di trasformazione dei tuoi carichi di lavoro. Migrate to Containers rileva automaticamente la configurazione dei pool di applicazioni IIS e aggiunge suggerimenti al piano di migrazione generato. Puoi quindi valutare questi suggerimenti 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 gMSA, mantiene la configurazione originale del pool di applicazioni. Ad esempio, quando utilizza un tipo di account integrato come ApplicationPoolIdentity, NetworkService, LocalSystem o LocalService.

Per supportare gMSA in un container Windows di cui è stata eseguita la migrazione, devi:

  1. Modifica il piano di migrazione per impostare le proprietà necessarie per configurare il container di cui è stata eseguita la migrazione in modo che utilizzi un gMSA.

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

Configura un cluster di destinazione per supportare gMSA

Devi collegare un gMSA nel cluster Kubernetes come parte della configurazione del pod, anziché come una configurazione dell'identità statica all'interno dell'immagine del container.

Per configurare un cluster che ospita il container Windows di cui è stata eseguita la migrazione in modo che supporti gMSA, devi avere:

  1. Configurato Active Directory per l'aggiunta automatica delle VM a un dominio.

  2. gMSA configurato per pod e container Windows.

Per ulteriori informazioni, consulta le seguenti risorse:

Esegui il deployment di un container durante l'archiviazione dei 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 container di cui hai eseguito il deployment. Questa opzione consente di proteggere la comunicazione esterna senza includere certificati all'interno del cluster. Per ulteriori informazioni, vedi Personalizzazione di un piano di migrazione.

Puoi anche archiviare certificati SSL (Secure Sockets Layer) come secret Kubernetes e montarli nel runtime nel container.

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 su cui ascoltare le connessioni SSL (in genere 443).

    • pfxpath specifica il percorso del file PFX. Configuralo come parte del processo volumeMounts del deployment del pod.

    • password specifica la password per il file PFX.

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

      Get-PfxCertificate -FilePath "path to pfx"

      In alternativa, visualizzali in Gestione certificati di Windows.

  3. Crea il secret di Kubernetes:

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

  4. Crea il montaggio del volume e del volume nel 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 che hai creato nel passaggio 3.

Configura SSL

Non è consigliabile archiviare chiavi private dei certificati SSL all'interno di un'immagine container, in quanto sono accessibili a chiunque legge l'immagine. Migrate to Containers offre diversi modi di gestire SSL per Windows.

Usa un certificato autofirmato generato automaticamente

Per impostazione predefinita, a un container Windows con un'associazione HTTPS viene assegnato un certificato autofirmato generato automaticamente e generato all'inizializzazione del container Docker. Questa configurazione consente di testare il carico di lavoro di cui è stata eseguita la migrazione, ma non può essere utilizzata in un ambiente di produzione. Il certificato è autofirmato e rigenerato a ogni esecuzione del container.

Opzione consigliata: 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 consente di proteggere le comunicazioni esterne senza includere certificati all'interno del cluster.

  • Per personalizzare l'associazione, modifica la definizione di site nel piano di migrazione che rappresenta la migrazione in modo da 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 dal frontend HTTPS al percorso e alla porta HTTP del carico di lavoro Windows.

Archivia 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 archiviare i certificati SSL come secret di Kubernetes e montarli nel runtime nel container.

Per utilizzare i certificati SSL archiviati come secret Kubernetes, devi modificare l'immagine di deployment del container. Per maggiori informazioni, consulta Eseguire il deployment di un container durante l'archiviazione dei certificati SSL come secret Kubernetes.

Configura 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 quindi inoltrati automaticamente a Cloud Logging, che offre una suite di strumenti per monitorare i container.

Per impostazione predefinita, Migrate to Containers abilita il logging IIS per monitorare i log IIS e inoltra i log eventi delle applicazioni o del sistema 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 Creazione di un file di configurazione.

Impostare gli ACL

Alcune applicazioni IIS richiedono la configurazione di autorizzazioni specifiche per gli elenchi di controllo dell'accesso dell'accesso (ACL) su file e cartelle affinché le applicazioni possano funzionare correttamente. Migrate to Containers analizza automaticamente tutte le applicazioni IIS migrate e aggiunge 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 container generata.

Poiché le immagini container Windows non supportano l'impostazione di ACL come parte del comando COPY di Docker, gli ACL vengono impostati in uno script chiamato set_acls.bat. Migrate to Containers crea automaticamente set_acls.bat nella directory dell'immagine generata per la tua specifica applicazione Windows. 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 modificare le autorizzazioni non correlate a utenti IIS specifici e che pertanto non sono state rilevate da Migrate to Containers.

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

Informazioni sulla cache di assemblaggio globale .NET

Migrate to Containers analizza l'immagine di origine .NET Global Assembly Cache (GAC) per individuare risorse .NET installate sulla macchina di origine e non disponibili nelle immagini ufficiali. Qualsiasi DLL rilevata viene copiata nel contesto Docker e installata come parte della creazione dell'immagine di destinazione da uno script di utilità install_gac.ps1.

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

Registrazione DLL dell'oggetto COM

Le DLL che espongono gli oggetti COM vengono analizzate e registrate automaticamente. Durante la fase di estrazione, i file copiati vengono analizzati alla ricerca di DLL registrate come oggetti COM, che vengono poi registrate nel container.

Questo processo avviene senza input utente. Tuttavia, puoi influenzare questo processo aggiungendo altre DLL da copiare. Se necessario, le DLL vengono controllate e registrate.

Passaggi successivi