Как развернуть вершину AI Workbench с Terraform - без боли в пользовательском интерфейсе
machine-learning cicd devops terraform google-cloud-platform gcp mlops cloud-cost-optimization vertexai

Как развернуть вершину AI Workbench с Terraform - без боли в пользовательском интерфейсе

15 августа 2025 г.

Подробное руководство для MLOPS и Data Teams, которые хотят прекратить сжигать время и деньги на Click-Ops.

1. Введение

Vertex AI Workbench - это управляемая среда Юпитера в Google Cloud. Он поставляется с собственной интеграцией с BigQuery и облачным хранилищем, поддерживает GPU/TPU и использует унифицированную модель IAM GCP и сетевые политики.

Создание экземпляров Jupyter в вершине AI Workbench через пользовательский интерфейс - самый простой способ начать работу. Но по мере того, как ваша команда растет, этот процесс становится все более трудоемким, аудит становится все труднее, а ошибки конфигурации и проблемы безопасности становятся более вероятными.

Несколько точек данных: согласноFlexera, средние «облачные отходы» достигают32%расходов - почти треть счетов ничего не платят;84%организации назвали контроль затрат как их главная облачная задача (Flexera) и до21%о инфра бюджетах сжигают недостаточно используемые ресурсы, в том числе простальные графические процессоры (PR Newswire)

Когда каждый инженер вручную создает свой собственный экземпляр Workbench, ошибки масштабируются с помощью численности Head Head: случайные регионы, забытые автоматические смены и сервисные учетные записи с чрезмерными разрешениями.

Цель этой статьи состоит в том, чтобы показать, как минимизировать ручную работу, сделать конфигурации воспроизводимыми и уменьшить холостые отходы, используя модуль Terraform с CI Pipeline для Vertex AI Workbench.

2. Почему вершина AI Workbench

Если ваша инфраструктура уже живет в экосистеме Google Cloud, Workbench предоставляет практические преимущества по сравнению с Databricks, Sagemaker, Jupyterhub и другими:

  • Вы остаетесь в GCP и подключаетесь к BigQuery, GCS, Vertex AI Pipelines, реестру артефактов, секретным менеджером через стандартные библиотеки Google-без мостов или сторонних разъемов.
  • Нет дополнительных плоскостей управления или консолей администратора: доступ, сети, секреты, аудит и выставление счетов, остаются в ваших существующих ограждениях GCP.
  • Workbench наследует ваши политики ORG: IAM -роли, сегментация VPC, частная служба Connect, управление сервисом VPC, CMEK и централизованный аудит в области регистрации облаков - без дублирования полисов в других местах.
  • Чистый счет выставления счетов и контроля затрат: единый провайдер и последовательные этикетки позволяют повторно использовать бюджетные оповещения и отчетность по центру затрат без разделения счетов на платформах.

Итог:Если ваша инфраю и данные уже находятся в GCP, Vertex AI Workbench сводит к минимуму интеграцию и эксплуатационные накладные расходы, обеспечивает постоянные политики безопасности и дает вам быстрый путь к автоматизации с Terraform.

3. Недостатки пользовательского интерфейса на практике

Давайте посмотрим на типичные проблемы, которые вы сталкиваетесь при создании экземпляров Workbench через пользовательский интерфейс:

  • Несоответствующие имена и этикетки. Пользователи устанавливают произвольные имена/теги, создавая право собственности, атрибуцию проекта/затрат и возвратные возвраты.
  • Область/зона дрейф. Примеры появляются в разных регионах/зонах без стандарта, увеличивая задержку и усложняют сеть.
  • Холодный ожог. Автоматическая смену часто забывают; Ручные отключения несовместимы. Машины бездействия - особенно с графическими процессорами - являются прямыми отходами.
  • Чрезмерные разрешения SA. Полагаться на учетные записи услуг по умолчанию нарушает наименьшую привилегию и увеличивает риск безопасности/соответствия.
  • Нет истории или воспроизводимости. Скриншоты и ручные шаги не могут быть рассмотрены кодом или разнообразными; Доказать соблюдение или восстановление конфигурации во время инцидентов сложно.

Terraform решает эти проблемы: конфигурации рецензируются и проверены CI;terraform planдает четкую разницу; Модуль кодирует стандарты (именование, этикетки, регионы, автоматическое смену, роли SA) и применяет их равномерно к каждому экземпляру.

4. Модель зрелости управления ноутбуком

Уровень 0 - ручной пользовательский интерфейс

Экземпляры и их параметры установлены вручную. (Единственное) преимущество - быстрая начальная настройка. Недостатки: нет стандартов, дрейф конфигурации, грязного атрибуции затрат и тяжелых аудитов. Работает сносно с <5 пользователями.

Уровень 1 - Terraform (местный применение)

Конфигурации в прямом эфире как код;terraform plan/applyзапускается локально. Легко масштабируйте и воспроизводите среды, выполняйте обзоры кода и стандартизируют создание. Но применить все еще ручной, оставляя место для человеческой ошибки. Подходит 5–20 пользователей с нечастого борьбы.

Уровень 2 - Terraform + CI/CD

plan/applyЗапускается в трубопроводе (Gitlab CI/CD или аналогичный) с автоматическими проверками политики/безопасности/затрат. Требуется основная практика DevOps (удаленное состояние, OIDC/WIF, Env Isolation). Благодаря> 20 пользователям и регулярным адаптацией, этот подход становится важным, чтобы избежать ручного труда и долга по аудиту/соответствию.

5. Terraform подход

Вам нужно:

  • Терраформ(≥ 1,3)
  • Gcp auth (например,,gcloud auth application-default loginили учетная запись обслуживания)
  • projectВregion/zoneиgoogleпоставщик (≥ 4,0)

Мы могли бы создать экземпляры напрямую сgoogle_workbench_instance, но это быстро приводит к дублированию (VPC/Network, Service Account, метки, политику автоматического сокращения, регион/зона и т. Д.). Любое изменение становится массовым обновлением аналогичных блоков, что усложняет проверку и аудит.

Вместо этого мы будем использовать модуль для инкапсуляции общих параметров и обнародовать только минимальные входы, которые фактически нуждаются, инженерам.

Для удобства, вот ссылка на хранилище с примером структуры проекта:https://github.com/timonovid/vertexai-workbench-terraform-with-ciПолем

Реализация модуля

vertexai-workbench-module/main.tf:

resource "google_workbench_instance" "instance" {
  for_each = var.notebook_instances

  project         = var.project_id
  location        = coalesce(each.value.zone, var.default_zone)
  name            = each.key
  instance_owners = each.value.instance_owners
  labels          = var.labels

  gce_setup {
    machine_type = coalesce(each.value.machine_type, var.default_machine_type)
    dynamic "accelerator_configs" {
      for_each = each.value.accelerator_configs != null ? [each.value.accelerator_configs] : []

      content {
        type       = accelerator_configs.value.type
        core_count = accelerator_configs.value.core_count
      }
    }

    disable_public_ip = true

    shielded_instance_config {
      enable_secure_boot          = true
      enable_vtpm                 = true
      enable_integrity_monitoring = true
    }

    service_accounts {
      email = 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(each.value.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 {
      network = var.network_name
      subnet  = var.subnet_name
    }
  }
}

Теперь объявите необходимые переменные вvertexai-workbench-module/variables.tf:

variable "notebook_instances" {
  description = "Configuration for each notebook instance"
  type = map(object({ 
    zone          = optional(string)
    machine_type      = optional(string)
    instance_owners   = list(string)
    data_disk_size_gb = optional(number)
        accelerator_configs = optional(object({
      type       = string
      core_count = number
    })) 
  }))
}

variable "labels" {
  description = "instance labels"
  type        = map(string)
}

variable "default_zone" {
  type        = string
  description = "Zone like us-central1-a"
  validation {
    condition     = 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 = "Email of the service account"
  type        = string
}

variable "default_boot_disk_size_gb" {
  description = "Default size in GB for boot disks if not specified."
  type        = number
  default     = 150
}

variable "default_data_disk_size_gb" {
  description = "Default size in GB for data disks if not specified."
  type        = number
  default     = 150
}

variable "default_machine_type" {
  description = "Default machine type if not specified."
  type        = string
  default     = "e2-standard-2"
}

variable "project_id" {
  description = "The project ID"
  type        = string
}

variable "network_name" {
  description = "The name of the network"
  type        = string
}

variable "subnet_name" {
  description = "The name of the subnet"
  type        = string
}

variable "idle_timeout_seconds" {
  type        = number
  description = "Idle timeout in seconds"
  validation {
    condition     = var.idle_timeout_seconds >= 0
    error_message = "idle_timeout_seconds must be >= 0."
  }
}

variable "post_startup_script" {
  description = "The post startup script"
  type        = string
}

Пример использования

Создайте несколько экземпляров:

module "vertex_instances" {
  source = "./vertexai-workbench-module"

  project_id            = var.project_id
  network_name          = google_compute_network.my_network.name
  subnet_name           = google_compute_subnetwork.my_subnetwork.name
  service_account_email = google_service_account.vertexai-workbench-sa.email
  post_startup_script   = "" # Optional path in gcs to script to run on instance startup. Example gs://your-bucket/init.sh
  idle_timeout_seconds  = 7200
  labels = {
    instance_type = "vertexai_workbench"
  }

  notebook_instances = {
    "workbench-instance-analytics-team-user1" = {
      instance_owners = ["user1@example.com"]
    },

    "workbench-instance-analytics-team-user2" = {
      instance_owners = ["user1@example.com"]
      machine_type    = "n1-standard-8"
    },

    "workbench-instance-ml-team1-user3" = {
      zone              = "us-central1-a"
      machine_type      = "n1-highmem-8"
      instance_owners   = ["user2@example.com"]
      data_disk_size_gb = 500
      accelerator_configs = {
        type       = "NVIDIA_TESLA_T4"
        core_count = 1
      }
    },
  }
}

Советы по параметрам модуля

  • Параметры для всех случаев модуля:project_idВnetwork_nameВsubnet_nameВservice_account_emailВpost_startup_script(полезно для инициализации среды),idle_timeout_secondsВlabelsПолем
  • Требуется на экземпляр: ключ карты (становится именем экземпляра) иinstance_ownersПолем
  • Дополнительные параметры с по умолчанию, определенные вvariables.tf: zoneВmachine_typeВdata_disk_size_gbВaccelerator_configsПолем

Таким образом, вы получаете несколько преимуществ по сравнению с созданием на основе пользовательского интерфейса

  • Объединенные значения по умолчанию и стандарты: сеть, наименее привилегическое SA, Auto-Shutdown, метки, экранированная виртуальная машина.
  • Простая масштабируемость: объемное создание 10–15 ноутбуков или развертывание изменения политики в одном MR.
  • Предсказуемые изменения:terraform planОбеспечивает прозрачную дифференциацию, простые в просмотре и откат.
  • Готовность аудита: вся конфигурация находится в коде; Ярлыки и IAM объединены.
  • Контроль затрат: требуемые этикетки и единая политика в одиночестве сокращают расходы на простоя; Бюджетные оповещения легко подключить.
  • Инкапсуляция сложности: пользователи модуля работают только с необходимыми параметрами (имя, размер, графический процессор), все остальное скрыто.

6. Создание ноутбуков через Terraform + CI/CD

Следующее улучшение - это трубопровод, который делает каждую ноутбук MR, проходя через план → Обзор → применить без ручного развертывания. Ниже приведен пример Gitlab, который вы можете встать в спринте, а затем затвердеть с политикой и проверками.

Предварительные условия: удаленное состояние терраформ и доступ GCP. Самая быстрая отправная точка - это ключ JSON для учетной записи службы, хранящейся в виде файловой переменной GitlabSA_KEY, с такими ролями, как ноутбуки Admin для рабочей кости и пользователя объекта хранения на конкретном ведре GCS, удерживающем состояние.

Изображение бегуна

Создайте легкий изображение сgcloudи Terraform, подтолкните его к своему реестру и ссылайтесь наimage::

FROM google/cloud-sdk:slim

RUN apt-get update && apt-get install -y --no-install-recommends \
    wget \
    && rm -rf /var/lib/apt/lists/*

RUN wget -O- https://apt.releases.hashicorp.com/gpg |  gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg \
    && echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" |  tee /etc/apt/sources.list.d/hashicorp.list \
    && apt update &&  apt install terraform

Минимальная конфигурация Gitlab CI/CD

Два этапа:planпишет артефакт плана;applyПрименяет этот точный план после слияния в филиал по умолчанию.planТакже работает для MRS для проверки конфигурации и синтаксиса.

default:
  image: "your-image:latest" # your image with installed 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"

stages:
  - 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 "Acquiring state lock" -e "Refreshing state"
  artifacts:
    paths:
      - planfile
    expire_in: 1 week
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event' || $CI_COMMIT_REF_NAME == "$CI_DEFAULT_BRANCH"
      changes:
        - "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
  rules:
    - if: $CI_COMMIT_REF_NAME == "$CI_DEFAULT_BRANCH"
      changes:
        - "vertexai-workbench-instances.tf"
  dependencies:
    - plan-job

Что ты получаешь

  • План как артефакт (planfileхранятся в течение недели) и в г -на Logs - легко просмотреть.
  • Детерминированное применение - использует тот же файл плана, снижая риск дрейфа.
  • Правила/изменения - задания запускается только при изменении конфигурации ноутбука.
  • --target=module.vertex_instancesудобен в монорепо; Удалите его, если вы хотите полную сходимость.

Как это ищет инженера

  1. В филиале функции добавьте блок модуля (например,nameВmachine_typeВdisk_size_gb) вvertexai-workbench-instances.tfПолем
  2. Открытие MR Triggers задание плана, которое запускает синтаксисную проверку и планируйте.
  3. После одобрения и слияния CI-прогоны применяются, и экземпляр появляется в GCP с правильными метками, сетью и автоматическим сменой.

Далее, когда ваша команда созревает, рассматривает возможность перехода на OIDC или федерацию идентификации рабочей нагрузки вместоSA_KEYПолем Добавьте контрольные проверки и затраты на ворота, разделенные проекты/штаты/рабочие пространства дляdev/stage/prodи реализовать владельцев кодов.

7. Заключение

Переход от ручного пользовательского интерфейса к модулю Terraform и CI/CD решает три основных задачи для Vertex AI Workbench: воспроизводимые конфигурации, прозрачный контроль затрат и готовность аудита. Модуль скрывает сложность сети/IAM/IAM и раскрывает только параметры, которые нуждаются инженерами. Трубопровод стандартизирует изменения и отражает историю.

Результат: меньше ручных шагов, меньше дрейфа конфигурации, более предсказуемых затрат и операционная модель, которая масштабируется с вашей командой.

Оригинал

Recent Post

Categories

PREVIOUS ARTICLE
NEXT ARTICLE