Préparer un cluster Linux pour le déploiement

Cette page explique comment préparer votre cluster cible pour le déploiement.

Avant de commencer

Ce document suppose que vous avez déjà effectué la migration et que vous disposez des artefacts générés.

Vérifier que le cluster cible dispose d'un accès en lecture au registre Docker

Dans le cadre d'une migration, Migrate to Containers importe des images Docker représentant une VM migrée dans un registre Docker. Ces images Docker représentent les fichiers et répertoires de la VM en cours de migration.

Pour le registre Docker, vous pouvez choisir d'utiliser :

Pour en savoir plus, consultez la page Définir des dépôts de données.

Déployer une charge de travail dans un projet Google Cloud autre que celui utilisé pour la migration

Il s'agit souvent de plusieurs projets Google Cloud dans votre environnement. Si vous effectuez une migration dans un projet Google Cloud, puis que vous souhaitez déployer la charge de travail migrée vers un cluster d'un autre projet, vous devez vous assurer que les autorisations sont correctement configurées.

Par exemple, vous effectuez la migration dans le projet A. Dans ce cas, la charge de travail migrée est copiée dans un bucket Container Registry du projet A. Exemple :

gcr.io/project-a/image_name:image_tag

Vous souhaitez ensuite déployer la charge de travail sur un cluster du projet B. Si vous ne configurez pas les autorisations correctement, le pod de la charge de travail ne parvient pas à s'exécuter, car le cluster du projet B ne dispose pas d'un accès en extraction d'images au projet A. Vous verrez ensuite un événement sur le pod contenant un message sous la forme suivante :

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

Tous les projets qui ont activé l'API Compute Engine disposent d'un compte de service par défaut Compute Engine, qui possède l'adresse e-mail suivante :

PROJECT_NUMBER-compute@developer.gserviceaccount.com

Où PROJECT_NUMBER est le numéro du projet B.

Pour contourner ce problème, assurez-vous que le compte de service par défaut Compute Engine du projet B dispose des autorisations nécessaires pour accéder au bucket Container Registry. Par exemple, vous pouvez utiliser la commande gcloud storage suivante pour activer l'accès :

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

Déployer sur un cluster cible en utilisant Container Registry en tant que registre Docker

Pour vous assurer qu'un cluster cible a accès à Container Registry, créez un secret Kubernetes contenant les identifiants requis pour accéder à Container Registry :

  1. Créez un compte de service pour déployer une migration, comme décrit dans la section Créer un compte de service pour accéder à Container Registry et à Cloud Storage.

    Ce processus vous permet de télécharger un fichier de clé JSON nommé m4a-install.json.

  2. Créez un secret Kubernetes contenant les identifiants requis pour accéder à 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

    où :

    • docker-registry spécifie le nom du secret Kubernetes, gcr-json-key dans cet exemple.
    • docker-server=gcr.io spécifie Container Registry comme serveur.
    • docker-username=_json_key indique que le nom d'utilisateur est contenu dans le fichier de clé JSON.
    • docker-password indique d'utiliser un mot de passe du fichier de clé JSON.
    • docker-email spécifie l'adresse e-mail du compte de service.

  3. Définissez le secret Kubernetes de l'une des manières suivantes :

    • Modifiez la valeur imagePullSecrets par défaut :

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

    • Modifiez le fichier deployment_spec.yaml pour ajouter la valeur imagePullSecrets à la définition spec.template.spec. Lorsque vous utilisez WebSphere traditionnel, le fichier yaml de déploiement est nommé twas_deployment_spec.yaml, liberty_deployment_spec.yaml ou openliberty_deployment_spec.yaml, selon votre cible.

      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

      Remplacez PROJECT_ID par l'ID du projet.

  4. Déployez le secret de la charge de travail, si secrets.yaml existe. Un fichier de secrets existe pour les charges de travail basées sur Tomcat et les charges de travail basées sur WebSphere traditionnel avec Liberty. Le fichier Liberty est nommé liberty-secrets.yaml.

    kubectl apply -f secrets.yaml

Déployer sur un cluster cible en utilisant un registre Docker avec une authentification de base

Si vous utilisez un registre Docker pour stocker des images de migration, celui-ci doit être compatible avec l'authentification de base à l'aide d'un nom d'utilisateur et d'un mot de passe. Dans la mesure où il existe de nombreuses manières de configurer une connexion en lecture seule à un registre Docker, vous devez utiliser la méthode appropriée pour votre plate-forme de cluster et votre registre Docker.

Étapes suivantes