Preparare un cluster Windows per il deployment

Questa pagina illustra alcuni scenari in cui potrebbe essere necessario personalizzare gli elementi della migrazione.

Prima di iniziare

In questo documento si presuppone che tu abbia completato la migrazione.

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

Nell'ambito dell'esecuzione di una migrazione, Migrazione a contenitori carica le immagini Docker che rappresentano una VM di cui è stata eseguita la migrazione in un registry Docker. Queste immagini Docker rappresentano i file e le directory della VM di cui viene eseguita la migrazione.

Per il registry 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 hai più progetti Google Cloud nel tuo ambiente. Se esegui una migrazione in un progetto Google Cloud, ma poi vuoi eseguire il deployment del carico di lavoro sottoposto a migrazione in un cluster di un altro progetto, devi assicurarti di avere configurato correttamente le autorizzazioni.

Ad esempio, esegui la migrazione nel progetto A. In questo caso, l'oggetto il carico di lavoro viene copiato in un bucket Container Registry progetto A. Ad esempio:

gcr.io/project-a/image_name:image_tag

Poi vuoi eseguire il deployment del carico di lavoro in un cluster nel progetto B. Se non configurerai 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 del progetto A. Poi vedrai un evento sul pod contenente un messaggio nel formato:

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 attivato l'API Compute Engine dispongono di un account di servizio predefinito Compute Engine con il seguente indirizzo email:

PROJECT_NUMBER-compute@developer.gserviceaccount.com

dove PROJECT_NUMBER è il numero del progetto B.

Per risolvere il 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 gcloud storage per abilitare l'accesso:

gcloud storage buckets add-iam-policy-binding gs://artifacts.project-a.appspot.com --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com --role=roles/storage.objectViewer

Esegui il deployment in un cluster di destinazione utilizzando Container Registry come registry Docker

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

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

    In questo processo devi scaricare un file chiave JSON denominato m4a-install.json.

  2. Crea un secret Kubernetes contenente le credenziali necessarie per accedere 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 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 della chiave JSON.
    • docker-password specifica di utilizzare una password del file di chiavi JSON.
    • docker-email specifica l'indirizzo email dell'account di servizio.

  3. Imposta il secret Kubernetes:

    • 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 di imagePullSecrets alla definizione di spec.template.spec. Quando utilizzi WebSphere tradizionale, il file YAML di deployment si chiama twas_deployment_spec.yaml, liberty_deployment_spec.yaml o openliberty_deployment_spec.yaml, a seconda del 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. Un file secret per carichi di lavoro basati su Tomcat e WebSphere tradizionali con la Libertà. Il file Liberty si chiama liberty-secrets.yaml.

    kubectl apply -f secrets.yaml

Esegui il deployment in un cluster di destinazione utilizzando un registry Docker con autenticazione di base

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

Configura i carichi di lavoro migrati per utilizzare gMSA

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

Quando esegui il deployment dei container di cui hai eseguito la migrazione in un cluster, puoi utilizzare Account di servizio gestito (gMSA). Utilizza gMSA per eseguire il contenitore all'interno di un'identità dell'account di servizio specifica. Collega un gMSA al cluster Kubernetes nell'ambito della configurazione dei pod anziché come una 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 degli pool di applicazioni IIS e aggiunge consigli al piano di migrazione generato. Tu puoi valutare questi consigli e modificarli per il tuo ambiente e requisiti di sicurezza.

Se Migrate to Containers determina che la configurazione di un'applicazione non richiede un gMSA, quindi mantiene il pool di applicazioni originale configurazione. Ad esempio, quando usa 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 container di cui è stato eseguito il deployment.

Configura un cluster di destinazione per supportare gMSA

Colleghi un gMSA nel cluster Kubernetes come parte della configurazione del pod, anziché una 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. Configurazione di Active Directory per l'aggiunta automatica a un dominio delle VM.

  2. gMSA configurato per pod e container Windows.

Per ulteriori informazioni, consulta le seguenti risorse:

Esegui il deployment di un container durante l'archiviazione di 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 ulteriori informazioni, consulta Personalizzare un piano di migrazione.

Puoi anche archiviare i certificati SSL (Secure Sockets Layer) i secret di Kubernetes e montarli in fase di 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 da ascoltare per le connessioni SSL (in genere 443).

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

    • password specifica la password del file PFX.

    • thumbprint specifica l'impronta digitale SHA-1 del file PFX che può essere recuperate 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 montaggio 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

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. Migrazione a Containers offre diversi modi per gestire SSL per Windows.

Utilizza un certificato autofirmato e 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 consente di testare il carico di lavoro migrato, non possono essere utilizzati in un ambiente di produzione. Il certificato è autofirmato e rigenerato ogni volta che viene eseguito il contenitore.

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 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.

Archivia i certificati SSL come secret di Kubernetes

Ti consigliamo di utilizzare Cloud Load Balancing, In entrata, o Cloud Service Mesh come frontend HTTPS per proteggere l'accesso. Tuttavia, puoi anche archiviare i certificati SSL come secret montarle in fase di runtime nel container.

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 Strumento LogMonitor per estrarre i log da un container Windows e inoltrarli al tuo cluster GKE. Questi log vengono quindi inoltrati automaticamente Cloud Logging, che offre una suite di strumenti per monitorare dei container.

Per impostazione predefinita, Migrazione ai container 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, inclusa la directory m4a. La directory contiene una cartella per ogni immagine. Nella directory m4a è incluso il file LogMonitorConfig.json che hai modificare per controllare il logging.

Per scoprire 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 (ACL) su file e cartelle affinché le applicazioni funzionino correttamente. Migrate to Containers analizza automaticamente tutti gli IIS di cui è stata eseguita la migrazione applicazioni e aggiunge eventuali autorizzazioni specifiche definite nella VM di origine si applicano agli account IIS (l'account IUSR e il gruppo IIS_IUSRS) e le applica ai file e alle directory copiati nel container generato dell'immagine.

Poiché le immagini container Windows non supportano l'impostazione di ACL come parte Docker COPY, gli ACL sono impostati 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 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 Esegui la migrazione ai contenitori.

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

Informazioni su .NET Global Assembly Cache

Migrate to Containers analizza la cache globale Assembly .NET (GAC) dell'immagine di origine per le risorse .NET installate sulla macchina di origine e non disponibili come parte delle 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 assiemi .NET vengono copiati nel contesto Docker nell'elemento m4a\gac . Per rimuovere gli assembly dall'immagine, eliminali dalla directory m4a\gac.

Registrazione DLL di oggetti COM

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

Questo processo avviene senza input dell'utente. Tuttavia, puoi influire su questo processo aggiungendo altre DLL da copiare. Se necessario, queste DLL vengono ha fatto il check-in a turno e ha effettuato la registrazione.

Passaggi successivi