Una guía detallada para MLOPS y equipos de datos que desean dejar de quemar tiempo y dinero en opciones de clics.
1. Introducción
Vertex Ai Workbench es un entorno Jupyter administrado en Google Cloud. Se envía con integración nativa con almacenamiento BigQuery y en la nube, admite GPU/TPU y aprovecha el modelo IAM unificado de GCP y las políticas de redes.
Crear instancias Jupyter en Vertex AI Workbench a través de la interfaz de usuario es la forma más easy de comenzar. Pero a medida que su equipo crece, este proceso se vuelve cada vez más laborioso, las auditorías se vuelven más difíciles y los errores de configuración y los problemas de seguridad se vuelven más probables.
Algunos puntos de datos: según Flexera, llega el “desperdicio de nubes” promedio 32% de gasto: casi un tercio de las facturas no pagan por nada; 84% de las organizaciones Nombre del management de costos como su desafío en la nube superior (Flexera) y hasta 21% de los presupuestos infra ardientes en recursos subutilizados, incluidas las GPU inactivas (PR Newswire).
Cuando cada ingeniero crea manualmente su propia instancia de Workbench, la escala de errores con private: regiones aleatorias, atenuaciones de automóviles olvidadas y cuentas de servicio con permisos excesivos.
El objetivo de este artículo es mostrar cómo minimizar el trabajo guide, hacer que las configuraciones sean reproducibles y reducir los desechos inactivos utilizando un módulo Terraform con CI Pipeline para Vertex AI Workbench.
2. ¿Por qué Vertex Ai Workbench
Si su infraestructura ya vive en el ecosistema de Google Cloud, Workbench ofrece ventajas prácticas sobre Databricks, Sagemaker, Jupyterhub y otros:
- Usted permanece dentro de GCP y se conecta de forma nativa a BigQuery, GCS, Pipelines de AI Vertex, Registro de artefactos, Secret Supervisor a través de las bibliotecas estándar de Google, sin puentes o conectores de terceros.
- No hay planos de management adicionales o consolas de administración: acceso, redes, secretos, auditoría y facturación permanecen en sus barandillas GCP existentes.
- Workbench hereda las políticas de su organización: roles IAM, segmentación de VPC, Join de servicio privado, controles de servicio VPC, CMEK y auditoría centralizada en el registro de nubes, sin duplicar políticas en otro lugar.
- Facturación clara y management de costos: un solo proveedor y etiquetas consistentes le permiten reutilizar alertas de presupuesto e informes de costo-centro sin dividir facturas en todas las plataformas.
En pocas palabras: Si su infra y sus datos ya están en GCP, Vertex AI Workbench minimiza la integración y la sobrecarga operativa, aplica políticas de seguridad consistentes y le brinda un camino rápido hacia la automatización con Terraform.
3. Invactos de la UI en la práctica
Veamos los problemas típicos que alcanza al crear instancias de Workbench a través de la interfaz de usuario:
- Nombres y etiquetas inconsistentes. Los usuarios establecen nombres/etiquetas arbitrarios, haciendo que la propiedad, la atribución de proyectos/costos y las devoluciones de contradías no sean confiables.
- Región/zona deriva. Las instancias aparecen en diferentes regiones/zonas sin un estándar, aumentando la latencia y complicando las redes.
- Quemadura inactiva. Auto-shutdown a menudo se olvida; Las paradas manuales son inconsistentes. Las máquinas inactivas, especialmente con las GPU, son desechos directos.
- Permisos de SA excesivos. Confiar en las cuentas de servicio predeterminadas viola el menor privilegio y aumenta el riesgo de seguridad/cumplimiento.
- Sin historial de cambio o reproducibilidad. Las capturas de pantalla y los pasos manuales no se pueden revisar o difundir el código; Probar el cumplimiento o la restauración de la configuración durante los incidentes es difícil.
Terraform aborda estos problemas: las configuraciones son revisadas por código y ci-verificadas; terraform plan da una diferencia clara; Un módulo codifica estándares (nombres, etiquetas, regiones, auto-shutdown, roles SA) y los aplica de manera uniforme a cada caso.
4. Un modelo de madurez de gestión de cuaderno
Nivel 0 – UI guide
Las instancias y sus parámetros se establecen a mano. La (única) ventaja es la configuración inicial rápida. Descubra: sin estándares, Drift de configuración, atribución de costos desordenados y auditorías pesadas. Funciona tolerablemente con <5 usuarios.
Nivel 1 – Terraform (aplicación native)
Configuraciones en vivo como código; terraform plan/apply se ejecuta localmente. Fácil de escalar y reproducir entornos, hacer revisiones de código y estandarizar la creación. Pero la aplicación sigue siendo guide, dejando espacio para el error humano. Se adapta a 5–20 usuarios con incrustación infrecuente.
Nivel 2 – Terraform + CI/CD
plan/apply Se ejecuta en una tubería (GITLAB CI/CD o comparable) con verificaciones automatizadas de política/seguridad/costos. Requiere práctica básica de DevOps (estado remoto, OIDC/WIF, aislamiento de env). Con> 20 usuarios y incorporación common, este enfoque se vuelve esencial para evitar la deuda guide de trabajo y auditoría/cumplimiento.
5. Enfoque de Terraform
Necesitarás:
- Terraform (≥ 1.3)
- Auth GCP (por ejemplo,
gcloud auth application-default logino una cuenta de servicio) challenge,area/zoney elgoogleproveedor (≥ 4.0)
Podríamos crear instancias directamente con google_workbench_instancepero eso conduce rápidamente a la duplicación (VPC/crimson, cuenta de servicio, etiquetas, política de cambio automático, región/zona, and so forth.). Cualquier cambio se convierte en una actualización masiva de bloques similares, lo que complica la revisión y la auditoría.
En su lugar, usaremos un módulo para encapsular los parámetros comunes y exponer solo las entradas mínimas que realmente necesitan realmente.
Por conveniencia, aquí hay un enlace al repositorio con una estructura de proyecto de ejemplo:
Implementación del módulo
vertexai-workbench-module/foremost.tf:
useful resource "google_workbench_instance" "occasion" {
for_each = var.notebook_instances
challenge = var.project_id
location = coalesce(every.worth.zone, var.default_zone)
title = every.key
instance_owners = every.worth.instance_owners
labels = var.labels
gce_setup {
machine_type = coalesce(every.worth.machine_type, var.default_machine_type)
dynamic "accelerator_configs" {
for_each = every.worth.accelerator_configs != null ? [each.value.accelerator_configs] : []
content material {
kind = accelerator_configs.worth.kind
core_count = accelerator_configs.worth.core_count
}
}
disable_public_ip = true
shielded_instance_config {
enable_secure_boot = true
enable_vtpm = true
enable_integrity_monitoring = true
}
service_accounts {
e-mail = var.service_account_email
}
boot_disk {
disk_size_gb = var.default_boot_disk_size_gb
disk_type = "PD_SSD"
}
data_disks {
disk_size_gb = coalesce(every.worth.data_disk_size_gb, var.default_data_disk_size_gb)
disk_type = "PD_SSD"
}
metadata = {
terraform = "true",
idle-timeout-seconds = var.idle_timeout_seconds,
post-startup-script = var.post_startup_script,
report-event-health = "true",
report-dns-resolution = "true"
}
network_interfaces {
community = var.network_name
subnet = var.subnet_name
}
}
}
Ahora declare las variables requeridas en vertexai-workbench-module/variables.tf:
variable "notebook_instances" {
description = "Configuration for every pocket book occasion"
kind = map(object({
zone = non-obligatory(string)
machine_type = non-obligatory(string)
instance_owners = checklist(string)
data_disk_size_gb = non-obligatory(quantity)
accelerator_configs = non-obligatory(object({
kind = string
core_count = quantity
}))
}))
}
variable "labels" {
description = "occasion labels"
kind = map(string)
}
variable "default_zone" {
kind = string
description = "Zone like us-central1-a"
validation {
situation = can(regex("^[a-z0-9-]+-[a-z0-9]+[0-9]-[a-z]$", var.default_zone))
error_message = "Use a zone format, e.g., us-central1-a."
}
}
variable "service_account_email" {
description = "E mail of the service account"
kind = string
}
variable "default_boot_disk_size_gb" {
description = "Default measurement in GB for boot disks if not specified."
kind = quantity
default = 150
}
variable "default_data_disk_size_gb" {
description = "Default measurement in GB for knowledge disks if not specified."
kind = quantity
default = 150
}
variable "default_machine_type" {
description = "Default machine kind if not specified."
kind = string
default = "e2-standard-2"
}
variable "project_id" {
description = "The challenge ID"
kind = string
}
variable "network_name" {
description = "The title of the community"
kind = string
}
variable "subnet_name" {
description = "The title of the subnet"
kind = string
}
variable "idle_timeout_seconds" {
kind = quantity
description = "Idle timeout in seconds"
validation {
situation = var.idle_timeout_seconds >= 0
error_message = "idle_timeout_seconds have to be >= 0."
}
}
variable "post_startup_script" {
description = "The publish startup script"
kind = string
}
Ejemplo de uso
Crear varias instancias:
module "vertex_instances" {
supply = "./vertexai-workbench-module"
project_id = var.project_id
network_name = google_compute_network.my_network.title
subnet_name = google_compute_subnetwork.my_subnetwork.title
service_account_email = google_service_account.vertexai-workbench-sa.e-mail
post_startup_script = "" # Optionally available path in gcs to script to run on occasion startup. Instance gs://your-bucket/init.sh
idle_timeout_seconds = 7200
labels = {
instance_type = "vertexai_workbench"
}
notebook_instances = {
"workbench-instance-analytics-team-user1" = {
instance_owners = ["[email protected]"]
},
"workbench-instance-analytics-team-user2" = {
instance_owners = ["[email protected]"]
machine_type = "n1-standard-8"
},
"workbench-instance-ml-team1-user3" = {
zone = "us-central1-a"
machine_type = "n1-highmem-8"
instance_owners = ["[email protected]"]
data_disk_size_gb = 500
accelerator_configs = {
kind = "NVIDIA_TESLA_T4"
core_count = 1
}
},
}
}
Consejos de parámetros del módulo
- Parámetros para todas las instancias del módulo:
project_id,network_name,subnet_name,service_account_email,post_startup_script(útil para inicializar el entorno),idle_timeout_seconds,labels. - Requerido por instancia: la clave del mapa (se convierte en nombre de instancia) y
instance_owners. - Parámetros opcionales con valores predeterminados definidos en
variables.tf:zone,machine_type,data_disk_size_gb,accelerator_configs.
Por lo tanto, obtienes varias ventajas sobre la creación basada en la interfaz de usuario.
- Valores predeterminados y estándares unificados: redes, un SA menos privilegiado, auto-shutdown, etiquetas, VM blindada.
- Escalabilidad easy: creación a granel de 10–15 cuadernos o implementar un cambio de política en un solo MR.
- Cambios predecibles:
terraform planProporciona una diferencia transparente, fácil de revisar y retroceder. - Preparación de auditoría: toda la configuración está en código; Las etiquetas e IAM están unificadas.
- Management de costos: las etiquetas requeridas y una política inactiva unificada reducen el gasto inactivo; Las alertas de presupuesto son fáciles de conectar.
- Encapsulación de complejidad: los usuarios de módulos trabajan solo con los parámetros necesarios (nombre, tamaño, GPU), todo lo demás está oculto.
6. Creación de cuadernos a través de Terraform + CI/CD
La siguiente mejora es una tubería que hace que cada cuaderno MR pase por plan → Revisión → Aplicar sin implementación guide. A continuación se muestra un ejemplo de gitlab en el que puede pararse en un dash y luego endurecer con políticas y cheques.
Prerrequisitos: un estado remoto de Terraform y acceso GCP. El punto de partida más rápido es una clave JSON para una cuenta de servicio almacenada como una variable de archivo GITLAB SA_KEYcon roles como Notebooks Admin para Workbench y Usuario de objetos de almacenamiento en el cubo GCS específico que contiene el estado.
Imagen de corredor
Construir una imagen liviana con gcloud y Terraform, empújalo a su registro y referirlo en picture::
FROM google/cloud-sdk:slim
RUN apt-get replace && apt-get set up -y --no-install-recommends
wget
&& rm -rf /var/lib/apt/lists/*
RUN wget -O- | gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
&& echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] $(lsb_release -cs) foremost" | tee /and so forth/apt/sources.checklist.d/hashicorp.checklist
&& apt replace && apt set up terraform
Configuración mínima de Gitlab CI/CD
Dos etapas: plan escribe un artefacto de plan; apply aplica ese plan exacto después de fusionarse a la rama predeterminada. plan También se ejecuta para la SRS para validar la configuración y la sintaxis.
default:
picture: "your-image:newest" # your picture with put in gcloud cli and terraform
before_script:
- gcloud auth activate-service-account --key-file="$SA_KEY"
- export GOOGLE_APPLICATION_CREDENTIALS="$SA_KEY"
variables:
TF_INPUT: "false"
levels:
- plan
- apply
plan-job:
stage: plan
script:
- terraform init -input=false
- terraform plan -out $CI_PROJECT_DIR/planfile --target=module.vertex_instances -compact-warnings | grep -v -e "Buying state lock" -e "Refreshing state"
artifacts:
paths:
- planfile
expire_in: 1 week
guidelines:
- if: $CI_PIPELINE_SOURCE == 'merge_request_event' || $CI_COMMIT_REF_NAME == "$CI_DEFAULT_BRANCH"
modifications:
- "vertexai-workbench-instances.tf"
apply-job:
stage: apply
script:
- terraform init -input=false
- terraform validate
- terraform apply -auto-approve -input=false $CI_PROJECT_DIR/planfile
guidelines:
- if: $CI_COMMIT_REF_NAME == "$CI_DEFAULT_BRANCH"
modifications:
- "vertexai-workbench-instances.tf"
dependencies:
- plan-job
Lo que obtienes
- Planear como un artefacto (
planfileMantenido durante una semana) y en MR Logs – fácil de revisar. - Aplicación determinista: utiliza el mismo archivo de planos, reduciendo el riesgo de deriva.
- Reglas/cambios: los trabajos se activan solo cuando cambia la configuración del cuaderno.
--target=module.vertex_instanceses útil en un monorepo; Retírelo si desea una convergencia completa.
Cómo busca un ingeniero
- En una rama de características, agregue un bloque de módulo (por ejemplo,
title,machine_type,disk_size_gb) envertexai-workbench-instances.tf. - Abrir un MR desencadena el trabajo del plan que ejecuta la verificación y el plan de sintaxis.
- Después de la aprobación y la fusión, se aplican ejecuciones de CI y la instancia aparece en GCP con las etiquetas correctas, la crimson y el auto-shutdown.
A continuación, a medida que su equipo madura, considera mudarse a OIDC o Federación de identidad de carga de trabajo en lugar de SA_KEY. Agregar verificaciones de políticas y puertas de costos, proyectos divididos/estados/espacios de trabajo para dev/stage/prod e implementar propietarios de códigos.
7. Conclusión
Pasar de la interfaz de usuario guide a un módulo Terraform y CI/CD resuelve tres problemas básicos para Vertex AI Workbench: configuraciones reproducibles, management de costos transparentes y preparación de auditoría. El módulo oculta la complejidad de crimson/IAM/inactividad y expone solo los parámetros que necesitan los ingenieros. La tubería estandariza los cambios y captura la historia.
El resultado: menos pasos manuales, menos deriva de configuración, costos más predecibles y un modelo operativo que escala con su equipo.
