Container Registry est obsolète et son abandon est planifié. Depuis le 15 mai 2024, Artifact Registry héberge les images du domaine gcr.io dans les projets qui n'ont pas encore utilisé Container Registry. Après le 18 mars 2025, Container Registry sera arrêté.

Pour commencer à gérer des conteneurs sur Google Cloud, utilisez Artifact Registry. Si vous utilisez Container Registry, découvrez comment passer à Artifact Registry pour gérer vos conteneurs sur Google Cloud.

Pour en savoir plus sur l'abandon et l'arrêt, consultez la page sur les abandons et les notes de version.

Cette page a été traduite par l'API Cloud Translation.

Migrer des conteneurs à partir d'un registre tiers

Si vous extrayez directement certaines images de conteneurs à partir de registres tiers afin de les déployer dans des environnements Google Cloud tels que Google Kubernetes Engine ou Cloud Run, les limites de débit sur les extractions d'images ou les pannes tierces peuvent perturber vos builds et vos déploiements. Cette page explique comment identifier ces images et les copier un registre dans Google Cloud pour une image de conteneur consolidée et cohérente gestion de la sécurité.

Vous pouvez également profiter d'autres fonctionnalités, comme la sécurisation de votre chaîne d'approvisionnement logicielle grâce à l'analyse des failles et l'application des règles de déploiement avec l'autorisation binaire.

Choisir un registre

Artifact Registry est le service recommandé pour stocker et gérer les images de conteneurs et d'autres artefacts de compilation dans Google Cloud.

Si vous n'utilisez pas Container Registry, migrer des images vers Artifact Registry à la place. Artifact Registry offre plus de flexibilité et de contrôle, stocker des images dans une région plutôt qu'à un emplacement multirégional, avec un accès plus précis et la prise en charge d'autres formats d'artefacts.
Si vous utilisez Container Registry, vous pouvez passer à Artifact Registry.

Présentation de la migration

La migration de vos images de conteneurs comprend les étapes suivantes :

Configurer les prérequis.
Identifier les images à migrer.
- Rechercher les références à des registres tiers dans vos fichiers Dockerfile et vos fichiers manifestes de déploiement.
- Déterminer la fréquence d'extraction des images depuis des registres tiers à l'aide de Cloud Logging et BigQuery.
Copier les images identifiées dans Container Registry.
Vérifier que les autorisations d'accès au registre sont correctement configurées, en particulier si Container Registry et votre environnement de déploiement Google Cloud se trouvent dans des projets différents.
Mettre à jour les fichiers manifestes pour vos déploiements.
Redéployer vos charges de travail.
(Facultatif) Bloquer les déploiements d'images provenant de sources tierces.

Container Registry ne surveille pas les registres tiers pour les mises à jour des images que vous copiez dans Container Registry. Si vous souhaitez intégrer une version plus récente d'une image dans votre pipeline, vous devez la transférer vers Container Registry.

Avant de commencer

Vérifiez vos autorisations. Vous devez disposer du rôle IAM Propriétaire ou Éditeur dans les projets dans lesquels vous migrez des images vers Container Registry.
Accéder à la page de sélection du projet
1. Sélectionnez le projet Google Cloud dans lequel vous souhaitez utiliser Container Registry.
2. Dans la console Google Cloud, accédez à Cloud Shell.
3. Recherchez votre ID de projet et définissez-le dans Cloud Shell. Remplacez YOUR_PROJECT_ID par l'ID de votre projet :
```
gcloud config set project YOUR_PROJECT_ID
```

Exportez les variables d'environnement suivantes :

  export PROJECT=$(gcloud config get-value project)

Activez les API BigQuery, Container Registry et Cloud Monitoring à l'aide de la commande suivante :

gcloud services enable \
containerregistry.googleapis.com \
stackdriver.googleapis.com \
logging.googleapis.com \
monitoring.googleapis.com

Vérifiez que Go version 1.13 ou ultérieure est installé.
- Vérifiez la version d'une installation Go existante à l'aide de la commande suivante :
```
go version
```
- Si vous devez installer ou mettre à jour Go, consultez la documentation d'installation de Go.

Coûts

Ce guide utilise les composants facturables suivants de Google Cloud :

Identifier les images à migrer

Recherchez dans les fichiers que vous utilisez pour créer et déployer vos images de conteneurs des références à des registres tiers, puis vérifiez à quelle fréquence vous extrayez les images.

Identifier les références dans les fichiers Dockerfile

Effectuez cette étape dans un emplacement où sont stockés vos fichiers Dockerfile. Il peut s'agir de l'emplacement où votre code est extrait localement, ou dans Cloud Shell si les fichiers sont disponibles sur une VM.

Dans le répertoire contenant vos fichiers Dockerfile, exécutez la commande suivante :

grep -inr -H --include Dockerfile\* "FROM" . | grep -i -v -E 'docker.pkg.dev|gcr.io'

Le résultat ressemble à l'exemple suivant :

./code/build/baseimage/Dockerfile:1:FROM debian:stretch
./code/build/ubuntubase/Dockerfile:1:FROM ubuntu:latest
./code/build/pythonbase/Dockerfile:1:FROM python:3.5-buster

Cette commande recherche tous les fichiers Dockerfile de votre répertoire et identifie la ligne "FROM". Ajustez la commande selon vos besoins pour qu'elle corresponde à la manière dont vous stockez vos fichiers Dockerfile.

Identifier les références dans les fichiers manifestes

Effectuez cette étape dans un emplacement où sont stockés vos fichiers manifestes GKE ou Cloud Run. Il peut s'agir de l'emplacement où votre code est extrait localement, ou dans Cloud Shell si les fichiers sont disponibles sur une VM.

Dans le répertoire contenant vos fichiers manifestes GKE ou Cloud Run, exécutez la commande suivante :
```
grep -inr -H --include \*.yaml "image:" . | grep -i -v -E 'docker.pkg.dev|gcr.io'
```
Exemple de résultat :
```
./code/deploy/k8s/ubuntu16-04.yaml:63: image: busybox:1.31.1-uclibc
./code/deploy/k8s/master.yaml:26:      image: kubernetes/redis:v1
```
Cette commande examine tous les fichiers YAML de votre répertoire et identifie la ligne image:, puis procède aux ajustements nécessaires en fonction du stockage des fichiers manifestes.
Pour répertorier les images actuellement exécutées sur un cluster, exécutez la commande suivante :
```
  kubectl get all --all-namespaces -o yaml | grep image: | grep -i -v -E 'docker.pkg.dev|gcr.io'
```
Cette commande renvoie tous les objets s'exécutant dans le cluster Kubernetes actuellement sélectionné et obtient leurs noms d'image.

Exemple de résultat :
```
- image: nginx
  image: nginx:latest
    - image: nginx
    - image: nginx
```

Exécutez cette commande pour tous les clusters GKE de tous les projets Google Cloud pour une couverture totale.

Identifier la fréquence d'extraction depuis un registre tiers

Dans les projets qui extraient à partir de registres tiers, utilisez les informations sur la fréquence d'extraction d'image pour déterminer si votre utilisation est proche ou supérieure aux limites de débit appliquées par le registre tiers.

Collecter les données des journaux

Créez un récepteur de journaux pour exporter des données vers BigQuery. Un récepteur de journaux inclut une destination, ainsi qu'un filtre qui sélectionne les entrées de journal à exporter. Vous pouvez créer un récepteur en interrogeant des projets individuels, ou utiliser un script pour collecter des données entre différents projets.

Pour créer un récepteur pour un seul projet, procédez comme suit :

Ces instructions concernent l'interface de prévisualisation de Logging.

Accéder à l'explorateur de journaux
Choisissez un projet Google Cloud.
Dans l'onglet Générateur de requête, saisissez la requête suivante :
```
  resource.type="k8s_pod"
  jsonPayload.reason="Pulling"
```
Modifiez le filtre d'historique en passant de Dernière heure à 7 derniers jours.
Cliquez sur Exécuter la requête.
Après avoir vérifié que les résultats s'affichent correctement, cliquez sur Actions > Créer un récepteur.
Dans la liste des récepteurs, sélectionnez Ensemble de données BigQuery, puis cliquez sur Suivant.
Dans le panneau "Modifier le récepteur", procédez comme suit :
- Dans le champ Nom du récepteur, saisissez image_pull_logs.
- Dans le champ Destination du récepteur, créez un nouvel ensemble de données ou choisissez un ensemble de données de destination dans un autre projet.
Cliquez sur Créer un récepteur.

Pour créer un récepteur pour plusieurs projets, procédez comme suit :

Ouvrez Cloud Shell.

Exécutez les commandes suivantes dans Cloud Shell :

PROJECTS="PROJECT-LIST"
DESTINATION_PROJECT="DATASET-PROJECT"
DATASET="DATASET-NAME"

for source_project in $PROJECTS
do
  gcloud logging --project="${source_project}" sinks create image_pull_logs bigquery.googleapis.com/projects/${DESTINATION_PROJECT}/datasets/${DATASET} --log-filter='resource.type="k8s_pod" jsonPayload.reason="Pulling"'
done

Où :

PROJECT-LIST est une liste d'ID de projet Google Cloud, séparés par des espaces. Par exemple, project1 project2 project3.
DATASET-PROJECT est le projet dans lequel vous souhaitez stocker l'ensemble de données.
DATASET-NAME est le nom de l'ensemble de données, par exemple image_pull_logs.

Après la création d'un récepteur, le transfert des données dans les tables BigQuery prend du temps, en fonction de la fréquence à laquelle les images sont extraites.

Requête pour la fréquence d'extraction

Une fois que vous disposez d'un exemple représentatif d'extractions d'images effectuées par vos builds, exécutez une requête pour la fréquence d'extraction.

Accédez à la console BigQuery.

Exécutez la requête suivante :

SELECT
  REGEXP_EXTRACT(jsonPayload.message, r'"(.*?)"') AS imageName,
  COUNT(*) AS numberOfPulls
FROM
      `DATASET-PROJECT.DATASET-NAME.events_*`
GROUP BY
      imageName
ORDER BY
      numberOfPulls DESC

Où :

DATASET-PROJECT est le projet qui contient votre ensemble de données.
DATASET-NAME est le nom de l'ensemble de données.

L'exemple suivant montre le résultat de la requête. Dans la colonne imageName, vous pouvez consulter la fréquence d'extraction pour les images qui ne sont pas stockées dans Container Registry ou Artifact Registry.

Copier les images vers Container Registry

Une fois que vous avez identifié des images provenant de registres tiers, vous pouvez les copier dans Container Registry. L'outil gcrane vous aide avec le processus de copie.

Créez un fichier texte images.txt dans Cloud Shell avec le nom des images que vous avez identifiées. Exemple :
```
ubuntu:18.04
debian:buster
hello-world:latest
redis:buster
jupyter/tensorflow-notebook
```

Téléchargez gcrane.

  GO111MODULE=on go get github.com/google/go-containerregistry/cmd/gcrane

Créez un script nommé copy_images.sh pour copier votre liste de fichiers.

Remarque : Ce script et les instructions de cette page partent du principe que vous copiez des images vers gcr.io. Si vous souhaitez utiliser un hôte multirégional différent, tel que eu.gcr.io, vous devez mettre à jour les exemples de configuration et les scripts en conséquence.
```
#!/bin/bash

images=$(cat images.txt)

if [ -z "${GCR_PROJECT}" ]
then
    echo ERROR: GCR_PROJECT must be set before running this
    exit 1
fi

for img in ${images}
do
    gcrane cp ${img} gcr.io/${GCR_PROJECT}/${img}
done
```
Rendez le script exécutable :
```
  chmod +x copy_images.sh
```
Exécutez le script pour copier les fichiers :
```
GCR_PROJECT=${PROJECT}
./copy_images.sh
```

Vérifier les autorisations

Par défaut, les services CI/CD de Google Cloud ont accès à Container Registry dans le même projet Google Cloud.

Cloud Build peut transférer et extraire des images.
Les environnements d'exécution tels que GKE, Cloud Run l'environnement flexible App Engine et Compute Engine peut extraire des images.

Si vous devez transférer ou extraire des images de plusieurs projets, ou si votre pipeline utilise des outils tiers qui doivent accéder à Container Registry, assurez-vous que les autorisations sont correctement configurées avant de mettre à jour et de redéployer vos charges de travail.

Pour en savoir plus, consultez la documentation sur le contrôle des accès.

Mettre à jour les fichiers manifestes pour référencer Container Registry

Mettez à jour vos fichiers Dockerfile et vos fichiers manifestes pour faire référence à Container Registry plutôt qu'au registre tiers.

L'exemple suivant illustre un fichier manifeste référençant un registre tiers :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Cette version mise à jour du fichier manifeste pointe vers l'image dans Container Registry :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: gcr.io/<GCR_PROJECT>/nginx:1.14.2
        ports:
        - containerPort: 80

Pour un grand nombre de fichiers manifestes, utilisez sed ou un autre outil capable de gérer des mises à jour dans de nombreux fichiers texte.

Redéployer des charges de travail

Redéployez les charges de travail avec vos fichiers manifestes mis à jour.

Effectuez le suivi des nouvelles extractions d'images en exécutant la requête suivante dans la console BigQuery :

SELECT`

FORMAT_TIMESTAMP("%D %R", timestamp) as timeOfImagePull,
REGEXP_EXTRACT(jsonPayload.message, r'"(.*?)"') AS imageName,
COUNT(*) AS numberOfPulls
FROM
  `image_pull_logs.events_*`
GROUP BY
  timeOfImagePull,
  imageName
ORDER BY
  timeOfImagePull DESC,
  numberOfPulls DESC

Toutes les nouvelles extractions d'images doivent provenir de Container Registry et contenir la chaîne gcr.io.

(Facultatif) Bloquer les images extraites des registres tiers

Pour les clusters GKE utilisant l'autorisation binaire, la règle que vous définissez bloque automatiquement les extractions de sources non approuvées. Assurez-vous que vos images migrées ne sont pas bloquées par la règle en les ajoutant à la liste des exceptions. Ces instructions expliquent comment spécifier une exception pour toutes les images stockées dans Container Registry au sein de votre projet.

Lors de la mise à jour initiale de la stratégie, envisagez d'activer le mode de simulation. Au lieu de bloquer les images, l'autorisation binaire crée des entrées de journal d'audit qui vous permettent d'identifier les images en attente provenant de registres tiers que vous devez migrer vers Container Registry.

Pour en savoir plus sur la configuration des stratégies de déploiement, consultez la documentation sur l'autorisation binaire.

Accédez à la page "Autorisation binaire"
Cliquez sur Modifier la règle.
Sous Règle par défaut du projet, activez le Mode de simulation.
Sous Images exclues des règles de déploiement, laissez l'option Approuver toutes les images système fournies par Google sélectionnée.
Développez les Chemins d'accès des images.
Ajoutez le chemin d'accès à vos images en tant qu'exception à la règle de projet par défaut :
1. Au bas de la liste des images, cliquez sur Ajouter des images.
2. Saisissez le chemin d'accès de l'image pour votre projet Google Cloud. Par exemple, gcr.io/my-project/* exclut toutes les images du projet my-project.
Répétez l'étape précédente pour les autres projets contenant des images que vous souhaitez déployer.

Examinez les événements de simulation dans Logging pour vos déploiements. Migrez toutes les images restantes extraites régulièrement à partir de registres tiers. Une fois toutes vos images migrées, vous pouvez modifier la stratégie pour désactiver le mode de simulation et bloquer les images provenant de sources non approuvées.