Prepara un cluster Linux per il deployment

Questa pagina descrive come preparare il cluster di destinazione per il deployment.

Prima di iniziare

Questo documento presuppone che tu abbia già completato la migrazione e che tu abbia generati dagli artefatti risultanti.

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

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 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 in 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 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 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 imagePullSecrets:

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

    • Modifica del file deployment_spec.yaml per aggiungere il valore imagePullSecrets alla definizione spec.template.spec. Quando utilizzi 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. Esiste un file secrets per i carichi di lavoro basati su Tomcat e per i carichi di lavoro tradizionali basati su WebSphere con Liberty. Il file Liberty è denominato 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.

Passaggi successivi