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

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

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

Nell'ambito dell'esecuzione di una migrazione, Migrate to Containers carica Immagini Docker che rappresentano una VM migrata in un Docker Registry. Queste immagini Docker rappresentano i file e le directory della VM di migrazione.

Per il Docker Registry puoi scegliere di utilizzare:

Per ulteriori informazioni, consulta Definizione dei repository di dati.

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

Spesso nel tuo ambiente sono presenti più progetti Google Cloud. Se eseguire una migrazione in un progetto Google Cloud, ma poi eseguire il deployment di un carico di lavoro migrato in un cluster di un progetto diverso, devi assicurarti di che abbiano le autorizzazioni configurate correttamente.

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. In caso contrario e configurare le autorizzazioni correttamente per cui il pod del carico di lavoro non riesce a eseguire perché il cluster nel progetto B non ha accesso al pull delle immagini al 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 abilitato l'API Compute Engine dispongono di un'istanza Compute Engine account di servizio predefinito, che include seguente indirizzo email:

PROJECT_NUMBER-compute@developer.gserviceaccount.com

Dove PROJECT_NUMBER è il numero del progetto B.

Per aggirare il problema, assicurati che il servizio predefinito Compute Engine l'account del progetto B dispone delle autorizzazioni necessarie per accedere Bucket Container Registry. Ad esempio, puoi utilizzare 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 dei carichi di lavoro sul cluster di elaborazione

Puoi eseguire il deployment del carico di lavoro migrato nello stesso cluster che hai eseguito la migrazione, denominata cluster di elaborazione Migrate to Containers. Nella maggior parte delle situazioni non è necessario eseguire altre configurazioni di elaborazione perché il cluster richiede già l'accesso in lettura o scrittura al Docker Registry per eseguire una migrazione.

Esegui il deployment su un cluster di destinazione utilizzando Container Registry come registro 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 eseguire 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 in il 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 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 di imagePullSecrets alla definizione di spec.template.spec. Quando si utilizza WebSphere tradizionale, il file YAML del deployment è denominato 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 esiste secrets.yaml. Un file secret per carichi di lavoro basati su Tomcat e WebSphere tradizionali con la Libertà. Il file Liberty è denominato liberty-secrets.yaml.

    kubectl apply -f secrets.yaml

Esegui il deployment su un cluster di destinazione utilizzando un Docker Registry 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 IIS Windows sono spesso uniti ad Active Directory (AD) per operare utilizzando 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 container all'interno di un un'identità specifica dell'account di servizio. 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 di IIS pool di applicazioni e aggiunge suggerimenti 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 container Windows migrato, devi:

  1. Modificare il piano di migrazione per impostare le proprietà necessarie per configurare il container di cui è stata eseguita la migrazione da utilizzare 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, piuttosto che una configurazione di identità statica all'interno dell'immagine container.

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

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

  2. gMSA configurato per pod e container Windows.

di Gemini Advanced.

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, In entrata, o Cloud Service Mesh come frontend HTTPS per proteggere al container di cui hai eseguito il deployment. Questa opzione ti consente di proteggere comunicazione senza includere certificati all'interno del cluster. Per ulteriori informazioni, vedi Personalizzazione di 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 La proprietà sites può contenere più voci sitename.

    • sslport specifica la porta su cui rimanere in ascolto per le connessioni SSL (in genere 443).

    • pfxpath specifica il percorso del file PFX. Configurala come parte 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, visualizzali nel Gestore 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 in di configurazione del deployment creato nel passaggio 2.
    • M4A_CERT_YAML è una variabile di ambiente impostata sul percorso completo alla i file di configurazione YAML creato nel passaggio 2.
    • secret-name è il nome del secret che hai creato nel passaggio 3.

Configura SSL

Si consiglia di non archiviare le chiavi private dei certificati SSL all'interno di un container dell'immagine in quanto sono accessibili a chiunque le stia leggendo. Migrate to Containers offre diversi modi per gestire il protocollo SSL per Windows.

Utilizza un certificato autofirmato e generato automaticamente

Per impostazione predefinita, a un container Windows con un'associazione HTTPS viene assegnato un modello automaticamente generato al momento dell'inizializzazione container Docker. Questa configurazione consente di testare il carico di lavoro migrato, non possono essere utilizzati in un ambiente di produzione. Il certificato è sia autofirmato e viene rigenerato ogni volta che viene eseguito il 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, In entrata, o Cloud Service Mesh come frontend HTTPS per proteggere l'accesso. Questa opzione consente di proteggere le comunicazioni esterne senza includere all'interno del cluster.

  • Per personalizzare l'associazione, 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

Potrai quindi inoltrare le richieste dal 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 il dell'immagine di deployment del container. Per ulteriori informazioni, vedi Esegui il deployment di un container durante l'archiviazione di certificati SSL come secret di Kubernetes.

Configura 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, Migrate to Containers consente al logging IIS di monitorare i log, e inoltra anche i log degli eventi dell’applicazione o del sistema 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 ulteriori informazioni sulla modifica di LogMonitorConfig.json, consulta Creazione di un file di configurazione.

Impostare gli ACL

Alcune applicazioni IIS richiedono l'impostazione di elenchi di controllo dell'accesso (ACL) specifici autorizzazioni su file e cartelle affinché le applicazioni in modo corretto. 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 di l'immagine generata per la tua specifica applicazione Windows. Migrate to Containers chiama quindi set_acls.bat quando esegui Comando docker build.

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

Lo script utilizza lo strumento Windows icacl 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. Tutte le DLL rilevate vengono copiate contesto e installato come parte della costruzione dell'immagine di destinazione da un'utenza script install_gac.ps1.

Tutti gli assiemi .NET vengono copiati nel contesto Docker nell'elemento m4a\gac . Per rimuovere gli assiemi dall'immagine, eliminali da m4a\gac .

Registrazione DLL di oggetti COM

Le DLL che espongono gli oggetti COM vengono automaticamente scansionate e registrate. 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 si verifica senza input utente. Tuttavia, puoi influenzare 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