Gestion des versions et cycle de vie des images

Cette page décrit comment les versions d'image Agent Platform Workbench sont numérotées et comment les images évoluent au cours de leur cycle de vie, pour les images de VM et les images de conteneurs personnalisées.

Pour créer une instance sur une version d'image de VM spécifique, consultez Créer une instance avec une version d'image spécifique.

Pour savoir ce qui a changé dans chaque version, consultez les notes de version des images.

Gestion des versions

Les images Agent Platform Workbench utilisent une version majeure et une version mineure.

  • Famille d'images (version majeure) : utilise la gestion des versions calendaires (YYMM). Exemple : workbench-instances-2603 (2603). Une nouvelle famille d'images marque une modification importante de l'image, telle qu'un nouveau système d'exploitation, une nouvelle version de Python ou une nouvelle référence de framework. Une modification plus importante ou potentiellement destructrice est fournie sous la forme d'une nouvelle famille d'images, tandis que la précédente continue de recevoir des mises à jour. Vous disposez ainsi de temps pour migrer au lieu de provoquer une modification potentiellement destructrice.
  • Nom de l'image (version mineure) : utilise la gestion des versions par date au format YYYYMMDD-HHMM-rcX, par exemple 20260629-1557-rc0. Un nom d'image est une version ponctuelle au sein d'une famille d'images, telle qu'un correctif de bug ou un correctif de sécurité.

Chaque famille d'images pointe vers le nom de sa dernière image. Pour mettre à niveau ou modifier des versions, consultez Gérer les versions d'image.

Gestion des versions intermédiaires héritée

Les versions basées sur Debian 11 et les versions antérieures utilisent la gestion des versions intermédiaires, par exemple m144. Les versions basées sur Debian 12 et les versions ultérieures utilisent la gestion des versions calendaires et par date décrite précédemment.

Cadence de lancement

Google met à jour régulièrement les noms d'images (versions mineures) activement gérés, environ une fois par semaine. Le calendrier exact d'une version donnée peut varier, et certaines versions ne contiennent que des mises à jour de sécurité ou de dépendances. Cette cadence est approximative. Pour consulter l'historique des versions, consultez les notes de version des images.

Si vous avez besoin d'un nom d'image stable et connu pour un déploiement, bloquez une version mineure spécifique au lieu de suivre la famille, et effectuez la mise à niveau selon votre propre calendrier.

Cycle de vie

Une image d'instances Agent Platform Workbench passe par les états suivants :

Active : la famille d'images est entièrement compatible et reçoit des correctifs de sécurité et de bugs. La famille d'images pointe vers le nom de sa dernière image active.

Fin de la période de compatibilité : la famille d'images ne reçoit plus de nouvelles versions ni de correctifs. Vous pouvez toujours créer des instances à partir d'un nom d'image obsolète spécifique, mais vous devez passer à une famille d'images active.

Chaque famille d'images comporte deux dates :

  • Date de disponibilité : date à laquelle la version majeure est devenue disponible.
  • Date d'obsolescence : date à laquelle la famille d'images est marquée comme obsolète. Après cette date, elle ne reçoit plus de nouvelles versions ni de correctifs.

Images de VM

Les images de VM Agent Platform Workbench sont des images de démarrage créées par Google, publiées dans le cloud-notebooks-managed projet d'image à projects/cloud-notebooks-managed/global/images/family/IMAGE_FAMILY. Chaque famille d'images inclut plusieurs noms d'images, un par version. Pour consulter l'historique complet des versions, consultez les notes de version des images. Pour afficher la liste des noms d'images disponibles les plus récents, consultez la section Lister les images de VM disponibles.

Images de VM actives

Le tableau suivant répertorie les images de VM actives :

Famille d'images OS Python Noyaux CUDA Date de disponibilité Fin de la période de compatibilité
workbench-instances-2603 (26.03) Debian 12 3.12 Noyau unique : Python 3.12, TensorFlow 2.21.0, PyTorch 2.12.1 13 Mars 2026 Mars 2028
workbench-instances (Ancien) Debian 11 3,10 Plusieurs noyaux : Python 3.10, TensorFlow 2.11.0, PyTorch 1.13.1 11.8 Juillet 2023 Mars 2027

Images de conteneurs personnalisées

Un conteneur personnalisé s'exécute sur deux images : l'image de conteneur de base, que vous pouvez versionner et étendre, et l'image d'hôte de conteneur gérée par Google qui l'exécute.

Image de conteneur de base

L'image de conteneur de base utilise la même gestion des versions de famille d'images (majeure) et de nom d'image (mineure) que les images de VM. La famille d'images est un suffixe de date sur le nom du conteneur, par exemple workbench-container-2606. La version du nom de l'image est un tag basé sur la date, par exemple workbench-container-2606:20260629-1557-rc0.

Agent Platform Workbench fournit des images de conteneurs de base créées par Google en deux variantes : standard et fine. Découvrez comment créer une instance Agent Platform Workbench à l'aide d'un conteneur personnalisé.

Famille d'images Variante OS Python Noyaux CUDA Date de disponibilité Fin de la période de compatibilité
workbench-container-2606 Standard Ubuntu 24.04 3.12 Noyau unique : Python 3.12, TensorFlow 2.21.0, PyTorch 2.12.1 12.8.1 Juin 2026 Juin 2028
workbench-container-slim-2606 Fine Ubuntu 24.04 3.12 Noyau unique : Python 3.12, TensorFlow 2.21.0, PyTorch 2.12.1 N/A Juin 2026 Juin 2028
workbench-container Standard Ubuntu 24.04 3,10 Plusieurs noyaux : Python 3.10, TensorFlow 2.11.0, PyTorch 1.13.1 12.8.1 Août 2024 Mars 2027
workbench-container-slim Fine Ubuntu 24.04 3,10 Noyau unique : Python 3.10, TensorFlow 2.11.0, PyTorch 1.13.1 N/A Août 2024 Mars 2027

Image d'hôte de conteneur

L'hôte de conteneur possède une seule famille d'images qui suit de près la dernière version de Container-Optimized OS (COS) prête pour la production. Elle est publiée sous la famille workbench-container-host dans le projet d'image cloud-notebooks-managed, et chaque version utilise une version de date, par exemple 20260701-2130-rc0. Vous ne pouvez pas bloquer la version de l'hôte lorsque vous créez une instance. Les nouvelles instances utilisent la dernière image d'hôte. Pour connaître les modifications apportées à l'OS hôte, consultez les notes de version de Container-Optimized OS.

Étape suivante