Control de versiones y ciclo de vida de la imagen

En esta página, se describe cómo se numeran las versiones de imágenes de Agent Platform Workbench y cómo las imágenes avanzan en su ciclo de vida, tanto para las imágenes de VM como para las imágenes de contenedor personalizadas.

Para crear una instancia en una versión específica de la imagen de VM, consulta Crea una instancia con una versión de imagen específica.

Para obtener información sobre los cambios en cada versión, consulta Notas de la versión de la imagen.

Control de versiones

Las imágenes de Agent Platform Workbench usan una versión principal y una versión secundaria.

  • Familia de imágenes (versión principal): Usa el control de versiones de calendario (YYMM); por ejemplo, workbench-instances-2603 (2603). Una nueva familia de imágenes marca un cambio significativo en la imagen, como un nuevo sistema operativo, una versión de Python o una línea de base del framework. Un cambio más grande o potencialmente rotundo se envía como una nueva familia de imágenes, mientras que la anterior sigue recibiendo actualizaciones. Esto te da tiempo para migrar en lugar de causar un posible cambio rotundo.
  • Nombre de la imagen (versión secundaria): Usa el control de versiones de fecha en el formato YYYYMMDD-HHMM-rcX, por ejemplo, 20260629-1557-rc0. Un nombre de imagen es una versión puntual dentro de una familia de imágenes, como una corrección de errores o un parche de seguridad.

Cada familia de imágenes apunta a su nombre de imagen más reciente. Para actualizar o cambiar versiones, consulta Administra versiones de imágenes.

Control de versiones de hitos heredados

Las versiones basadas en Debian 11 y versiones anteriores usan el control de versiones de hitos, por ejemplo, m144. Las versiones basadas en Debian 12 y versiones posteriores usan el control de versiones de calendario y fecha que se describió anteriormente.

Frecuencia de actualización

Google actualiza los nombres de imágenes (versiones secundarias) que se mantienen de forma activa con regularidad, aproximadamente una vez por semana. El momento exacto de cualquier versión puede variar, y algunas versiones solo contienen actualizaciones de seguridad o dependencias. Esta frecuencia es aproximada. Para consultar el historial de versiones real, consulta Notas de la versión de la imagen.

Si necesitas un nombre de imagen estable y conocido para una implementación, fíjalo a una versión secundaria específica en lugar de hacer un seguimiento de la familia y actualiza según tu propia programación.

Ciclo de vida

Una imagen de instancias de Agent Platform Workbench pasa por los siguientes estados:

Activa: La familia de imágenes es totalmente compatible y recibe correcciones de seguridad y errores. La familia de imágenes apunta a su nombre de imagen activa más reciente.

Fin de la compatibilidad: La familia de imágenes ya no recibe versiones ni correcciones nuevas. Aún puedes crear instancias a partir de un nombre de imagen obsoleta específico, pero debes actualizar a una familia de imágenes activa.

Cada familia de imágenes tiene dos fechas:

  • Fecha de lanzamiento: Indica cuándo estuvo disponible la versión principal.
  • Fecha de obsolescencia: Es la fecha en que la familia de imágenes se marca como obsoleta. Después de esta fecha, ya no recibe versiones ni correcciones nuevas.

Imágenes de VM

Las imágenes de VM de Agent Platform Workbench son imágenes de arranque compiladas por Google, publicadas en el cloud-notebooks-managed proyecto de imagen en projects/cloud-notebooks-managed/global/images/family/IMAGE_FAMILY. Cada familia de imágenes incluye varios nombres de imágenes, uno por versión. Para ver el historial completo de versiones, consulta Notas de la versión de la imagen. Para enumerar los nombres de imágenes disponibles más recientes, consulta Enumera las imágenes de VM disponibles.

Imágenes de VM activas

En la siguiente tabla, se enumeran las imágenes de VM activas:

Familia de imágenes SO Python Kernels CUDA Fecha de lanzamiento Fin de la compatibilidad
workbench-instances-2603 (26.03) Debian 12 3.12 Kernel único: Python 3.12, TensorFlow 2.21.0, PyTorch 2.12.1 13.0 Marzo de 2026 Marzo de 2028
workbench-instances (heredada) Debian 11 3.10 Kernels múltiples: Python 3.10, TensorFlow 2.11.0, PyTorch 1.13.1 11.8 Julio de 2023 Marzo de 2027

Imágenes de contenedor personalizadas

Un contenedor personalizado se ejecuta en dos imágenes: la imagen de contenedor base que puedes controlar y extender, y la imagen de host de contenedor administrada por Google que la ejecuta.

Imagen de contenedor base

La imagen de contenedor base usa la misma familia de imágenes (principal) y el mismo nombre de imagen (secundario) que las imágenes de VM. La familia de imágenes es un sufijo de fecha en el nombre del contenedor, por ejemplo, workbench-container-2606. La versión del nombre de la imagen es una etiqueta basada en la fecha, por ejemplo, workbench-container-2606:20260629-1557-rc0.

Agent Platform Workbench proporciona imágenes de contenedor base compiladas por Google en dos variantes: estándar y contraída. Obtén más información para crear una instancia de Agent Platform Workbench con un contenedor personalizado.

Familia de imágenes Variant SO Python Kernels CUDA Fecha de lanzamiento Fin de la compatibilidad
workbench-container-2606 Estándar Ubuntu 24.04 3.12 Kernel único: Python 3.12, TensorFlow 2.21.0, PyTorch 2.12.1 12.8.1 Junio de 2026 Junio de 2028
workbench-container-slim-2606 Contraída Ubuntu 24.04 3.12 Kernel único: Python 3.12, TensorFlow 2.21.0, PyTorch 2.12.1 N/A Junio de 2026 Junio de 2028
workbench-container Estándar Ubuntu 24.04 3.10 Kernels múltiples: Python 3.10, TensorFlow 2.11.0, PyTorch 1.13.1 12.8.1 Agosto de 2024 Marzo de 2027
workbench-container-slim Contraída Ubuntu 24.04 3.10 Kernel único: Python 3.10, TensorFlow 2.11.0, PyTorch 1.13.1 N/A Agosto de 2024 Marzo de 2027

Imagen de host de contenedor

El host de contenedor tiene una sola familia de imágenes que realiza un seguimiento de la última versión de Container-Optimized OS (COS) lista para producción. Se publica en la familia workbench-container-host en el proyecto de imagen cloud-notebooks-managed, y cada versión usa una versión de fecha, por ejemplo, 20260701-2130-rc0. No puedes fijar la versión del host cuando creas una instancia. Las instancias nuevas usan la imagen de host más reciente. Para obtener información sobre los cambios en el SO del host, consulta las notas de la versión de Container-Optimized OS.

¿Qué sigue?