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 le 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:
Qualsiasi registro Docker che supporti l'autenticazione di base
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 esegui una migrazione in un progetto Google Cloud, ma poi vuoi eseguire il deployment del carico di lavoro di cui è stata eseguita la migrazione in un cluster di un progetto diverso, devi assicurarti di aver configurato correttamente le autorizzazioni.
Ad esempio, esegui la migrazione nel progetto A. In questo caso, il carico di lavoro migrato viene copiato in un bucket Container Registry nel 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 configuri correttamente le autorizzazioni, il pod del carico di lavoro non può essere eseguito 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 in cui è abilitata l'API Compute Engine dispongono di un account di servizio predefinito di Compute Engine, con 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 migrato sullo stesso cluster che hai utilizzato per eseguire la migrazione, denominato cluster di elaborazione Migrate to Containers. Nella maggior parte delle situazioni non è necessario eseguire configurazioni aggiuntive sul cluster di elaborazione poiché 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, crea un secret Kubernetes contenente le credenziali necessarie per accedere a Container Registry:
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.
In questo processo devi scaricare un file chiave JSON denominato
m4a-install.json
.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 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.
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 valoreimagePullSecrets
alla definizione dispec.template.spec
. Quando si utilizza WebSphere tradizionale, il file YAML di deployment viene denominatotwas_deployment_spec.yaml
,liberty_deployment_spec.yaml
oopenliberty_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.
Esegui il deployment del secret del carico di lavoro, se esiste
secrets.yaml
. Esisterà un file secret per i carichi di lavoro basati su Tomcat e per i carichi di lavoro basati su WebSphere tradizionali con Liberty. Il file Liberty è denominatoliberty-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 registro Docker per archiviare le immagini di migrazione, il registro deve supportare l'autenticazione di base utilizzando un nome utente e una 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 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) e operano utilizzando identità di dominio. Durante la migrazione di queste VM ai container, i container non sono uniti a un dominio, ma i loro nodi cluster Kubernetes host possono essere uniti al dominio.
Quando esegui il deployment dei container di cui hai eseguito la migrazione in un cluster, puoi utilizzare un account di servizio gestito di gruppo (gMSA). Utilizza gMSA per eseguire il container all'interno dell'identità di un account di servizio specifico. Puoi collegare un gMSA al 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 del pool di applicazioni originale. ad esempio se viene usato un tipo di account integrato come
ApplicationPoolIdentity
, NetworkService
, LocalSystem
o LocalService
.
Per supportare gMSA in un container Windows migrato, devi:
Modifica il piano di migrazione per impostare le proprietà necessarie per configurare il container migrato in modo che utilizzi un gMSA.
Configura il cluster di destinazione che ospita il container di cui è stato eseguito il deployment.
Configura un cluster di destinazione per supportare gMSA
Puoi collegare un gMSA nel cluster Kubernetes come parte della configurazione del pod, anziché come una configurazione dell'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:
Per ulteriori informazioni, consulta le seguenti risorse:
- Crea gMSA per i container Windows.
- Crea un account di servizio gestito di gruppo.
- Utilizzo di gMSA nella documentazione di Google Cloud.
- Configura la tua app per utilizzare gMSA nella documentazione Microsoft.
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 container di cui hai eseguito il deployment. Questa opzione consente di proteggere le comunicazioni esterne 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) come secret di Kubernetes e montarli in fase di runtime nel container.
Per utilizzare i secret di Kubernetes:
Crea un file PFX con il certificato e la password.
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ù vocisitename
.sslport
specifica la porta da ascoltare per le connessioni SSL (in genere 443).pfxpath
specifica il percorso del file PFX. Configuralo come parte dellavolumeMounts
del deployment del pod.password
specifica la password del file PFX.thumbprint
specifica l'impronta digitale SHA-1 del file PFX, che può essere recuperata utilizzando il comando PowerShell:Get-PfxCertificate -FilePath "path to pfx"
In alternativa, visualizzali nel Gestore certificati di Windows.
Crea il secret Kubernetes:
kubectl create secret generic secret-name --from-file=pfx=path-to-pfx --from-file=config=path-to-config
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 dapfxpath
nel file di configurazione creato nel passaggio 2.M4A_CERT_YAML
è una variabile di ambiente impostata sul percorso completo del file YAML di configurazione creato nel passaggio 2.secret-name
è il nome del secret che hai creato nel passaggio 3.
Configura SSL
Ti consigliamo di non archiviare le chiavi private dei certificati SSL all'interno di un'immagine container in quanto sono accessibili a chiunque legga l'immagine. 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 certificato autofirmato, generato automaticamente all'inizializzazione del container Docker. Questa configurazione consente di testare il carico di lavoro migrato, 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 per impostareprotocol
suhttp
: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 di 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 in fase di runtime nel container.
Per utilizzare i certificati SSL archiviati come secret di Kubernetes, devi modificare l'immagine di deployment del container. Per ulteriori informazioni, consulta Eseguire 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 lo strumento LogMonitor per estrarre i log da un container Windows e inoltrarli al cluster GKE. Questi log vengono quindi inoltrati automaticamente a Cloud Logging, che fornisce una suite di strumenti per monitorare i container.
Per impostazione predefinita, Migrate to Containers consente al logging IIS di monitorarne i log e inoltra anche i log degli eventi delle applicazioni o di sistema 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 puoi 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 autorizzazioni specifiche per gli elenchi di controllo dell'accesso dell'accesso (ACL) su file e cartelle affinché le applicazioni funzionino correttamente. Migrate to Containers analizza automaticamente tutte le applicazioni IIS migrate e aggiunge eventuali autorizzazioni specifiche definite nella VM di origine applicabili agli account IIS (l'account IUSR
e il gruppo IIS_IUSRS
) e le applica ai file e alle directory copiati nell'immagine container generata.
Poiché le immagini container Windows non supportano l'impostazione di ACL come parte del comando 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 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 pertanto non sono state rilevate
da Migrate to Containers.
Lo script utilizza lo strumento icacl integrato di Windows per impostare le autorizzazioni.
Informazioni su .NET Global Assembly Cache
Migrate to Containers analizza la cache .NET Global Assembly Cache (GAC) dell'immagine di origine per trovare risorse .NET installate sulla macchina di origine e non disponibili come parte delle immagini ufficiali. Tutte le DLL rilevate vengono copiate nel contesto Docker e installate come parte 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 assiemi dall'immagine, eliminali dalla directory 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 individuare le DLL registrate come oggetti COM e poi registrate nel container.
Questo processo si verifica senza input utente. Tuttavia, puoi influenzare il processo aggiungendo altre DLL da copiare. Se necessario, le DLL vengono controllate a turno e registrate.