Production-конфигурация GCP Compute Engine с MIG и OS Login

GCP Compute Engine настройка: где ломается прод

Настройка виртуальных машин в GCP Compute Engine ломается не на старте, а на росте. Первые машины собирают руками: выбирают тип, добавляют диск, прописывают SSH-ключ в метаданные проекта. Пока инстансов пять и их ведёт один инженер, схема держится — а дальше начинается расхождение конфигураций.

Основная причина в том, что шаблон машины живёт отдельно от прода. В группе управляемых инстансов (MIG) хранится один образец, но правила брандмауэра, метки, лимиты и дополнительные диски в него не попадают. Автомасштабирование под нагрузкой поднимает десяток узлов из шаблона — и они приходят другими: без доступа к базе, с диском другого размера, без меток, по которым их находит балансировщик.

Ручные правки в консоли — вторая мина. Ключи в метаданных проекта переживают увольнение и передачу задач: доступ остаётся, а кто им пользуется — непонятно. OS Login закрывает это, но только когда включён на уровне организации и связан с ролями; включать его на отдельном проекте, поверх старых ключей, бессмысленно.

Проблемы конфигурации в проде выглядят одинаково: узел пересоздан, ведёт себя иначе, воспроизвести нечем. Дальше разбираем, как это закрывается — шаблоном как единственным источником правды, версионированием и проверками при пересоздании.

Эффект от управляемой конфигурации: скорость и устойчивость

Когда парк машин описан шаблонами и политиками, а не собран руками по инструкции, меняется экономика эксплуатации. В Google Cloud конфигурация Compute Engine хранится в шаблоне инстанса и группе управляемых инстансов: правку вносят один раз, и при следующем обновлении она расходится по всем машинам без захода на каждую.

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

Устойчивость парка машин держится на группе: она сама проверяет состояние экземпляров и заменяет нерабочий на новый из того же шаблона. Так уходит целый класс отказов — «машина жива, но настроена иначе». Доступ по ключам через единый каталог учётных записей закрывает второй класс: ключи выдаются и отзываются централизованно, а не остаются жить на машинах после ухода инженера.

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

Варианты развёртывания: одиночные машины, группы, шаблоны

Варианты развёртывания в Compute Engine из Google Cloud отличаются не столько типом машины, сколько тем, кто отвечает за восстановление узла. Одиночная виртуальная машина удобна как первый шаг: развернули, настроили, отдали трафик. Но её состояние живёт только на ней — ручные правки накапливаются, а после сбоя узел приходится поднимать по памяти или по устаревшей инструкции.

Группа управляемых экземпляров убирает эту связку: эталон описан в шаблоне машины, а группа держит заданное число узлов и пересоздаёт выпавшие. Автоматическое восстановление экземпляра срабатывает по проверке работоспособности, но работает только там, где приложение не хранит уникальные данные локально.

Что это значит для выбора

Шаблон машины — единица версионирования всей конфигурации. Обновление группы — новая версия шаблона и плановое замещение узлов, откат — возврат к предыдущей версии, которая уже проверена. Поэтому переход от одиночной машины к группе — не переписывание, а перенос уже работающих настроек в шаблон и подключение проверок.

Настройка по шагам: от аудита проекта до передачи регламентов

Настройка Compute Engine идёт от инвентаризации к регламентам: сборка поверх необследованного проекта наследует чужие права, осиротевшие диски и конфигурацию, которую никто не решается трогать. Этапы ниже идут в том порядке, в котором выполняются в проекте — каждый опирается на результат предыдущего, а не на догадки.

1. Аудит облачного проекта. Инвентаризируем инстансы, диски, снапшоты, подсети, правила доступа и учётные записи. Неиспользуемые ресурсы убираем, права, выданные «на время», сужаем до действительно нужных ролей.
2. Схема инфраструктуры. Согласуем число зон, состав групп управляемых инстансов (MIG) и границы между тестовой и промышленной средами — до того, как создан первый ресурс. Схема фиксируется как документ, по которому потом сверяют факт.
3. Сборка шаблона и групп. Шаблон инстанса становится версионируемым артефактом: базовый образ, диски, сетевые метки, состав прав. Доступ по SSH — через OS Login с корпоративными учётными записями вместо ключей, разложенных по метаданным проекта.
4. Проверка отказоустойчивости. Принудительно выводим из строя зону и отдельный инстанс: фиксируем, за какое время группа восстанавливает рабочие узлы и возвращается ли трафик без ручного вмешательства.
5. Обкатка обновлений и отката. Прогоняем поочерёдную замену инстансов с лимитом на недоступные и проверяем возврат на предыдущий шаблон — откат должен занимать минуты, а не требовать пересборки группы.
6. Передача регламентов. Отдаём схему, конфигурации, политики доступа, инструкции по типовым операциям и порядок действий при сбое, разбираем их с командой заказчика.

Что остаётся у вас: шаблоны, политики, схемы, регламенты

Инфраструктура остаётся у вас в виде кода и документов, а не в виде инженера, который помнит, где что нажать. Всё, что мы настраиваем в Google Cloud Compute Engine — шаблоны машин, группы управляемых инстансов, OS Login и политики доступа — лежит в вашем репозитории и разворачивается воспроизводимо.

• Шаблоны машин: образ, тип диска, метаданные, health check и стартовый скрипт описаны декларативно — новая версия проходит ревью как обычный код.
• Политики доступа: роли IAM по сервисным аккаунтам, вход через OS Login вместо статических ключей, разделение прод и стейджа, список исключений с обоснованием.
• Схема инфраструктуры: сеть, подсети, правила файрвола, балансировщик, распределение по зонам и лимиты — в одном файле, читаемом без нас.
• Документация на инфраструктуру: что где живёт, какие переменные задаются на входе, как поднять окружение с нуля и как корректно его снести.
• Регламент эксплуатации: порядок выката новой версии, отката, обновления образов и ротации доступов — с указанием, кто это делает.
• Алерты и дашборды: метрики группы инстансов, доступность сервиса, ошибки на старте — с привязкой к ответственному.
• Журнал проверок: какие сценарии прогнаны (потеря зоны, деградация инстанса, переполнение диска) и что подтверждено на стенде.

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

Кейс: парк машин перестал требовать ручных правок

Парк из шестидесяти машин в трёх зонах обслуживала одна команда, и каждая правка шла руками: образ собирали на месте, доступ выдавали ключами, разложенными по машинам, обновление катили по одной через консоль. Замена упавшего инстанса занимала вечер — поднять из снимка, доправить конфиги, вернуть в балансировщик, проверить приложение. Хуже всего было с дрейфом: через месяц после релиза часть машин в зонах уже отличалась от эталона, и никто не мог сказать, чем именно.

Что изменили: шаблон инстанса стал единственным источником истины и версионируется в репозитории, а сами машины собираются группой управляемых инстансов с распределением по зонам. Политика поочерёдного обновления выводит из работы часть машин за раз, проверки здоровья снимают нездоровый инстанс и пересоздают его вместо ручного лечения. Доступы перевели на вход по корпоративным учётным записям с ролями — ключи на машинах больше не хранятся, а при увольнении сотрудника учётка отключается в каталоге, и доступ исчезает вместе с ней.

Откат теперь тоже инженерная операция, а не поиск «той самой» копии образа: возвращаем предыдущую версию шаблона и запускаем обновление группы. Всё это штатные механизмы Google Cloud, поэтому не появляется самописных надстроек, которые нужно сопровождать. Ручные операции из ежедневной работы ушли в разовые — согласование новой роли или правку шаблона, — и именно это сократило долю ручного труда на порядок.

Чем группа управляемых машин отличается от одиночной?

Одиночная машина — это один экземпляр с фиксированными параметрами, который живёт, пока не остановится сам или не откажет железо. Пока нагрузка ровная, схема работает: предсказуемая конфигурация, минимум движущихся частей, всё видно в одном месте. Проблема в том, что любая перезагрузка, обновление ядра или сбой диска превращается в ручную операцию — поднять, переустановить, вернуть настройки, снова ввести в балансировку.

Группа управляемых машин убирает этот класс работ за счёт шаблона экземпляра и декларации размера. Вы описываете, как должна выглядеть машина, сколько их нужно и каким правилом проверять состояние; дальше автовосстановление само пересоздаёт выпавший узел по шаблону, а не «лечит» его по месту — конфигурация не расходится со временем.

Масштабирование парка работает как продолжение той же логики: при росте очереди или загрузки добавляются узлы, при спаде лишние убираются. Отказоустойчивость достигается не надёжностью отдельного сервера, а тем, что потеря узла не меняет ёмкость группы — трафик перераспределяется на оставшиеся, пока поднимается новый.

Цена решения тоже понятна: нужны шаблон, проверки состояния, доступы через OS Login и стратегия обновлений, чтобы прогон не сносил весь парк разом. Если нагрузка постоянна и простой допустим по регламенту, одиночная машина дешевле в поддержке. Как только появляется требование «сервис не падает на пике», группа окупается на первом же инциденте.

Технические сомнения перед стартом работ

Инженерные сомнения перед стартом — не про доверие, а про риск: сервисы уже работают и обслуживают пользователей, поэтому ошибка в конфигурации видна сразу. Разбираем три вопроса, которые задают чаще всего при переводе на управляемые шаблоны в Google Cloud, и то, как мы на них отвечаем.

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

Какой доступ к проекту вам нужен?

Роли выдаются на уровне проекта, вход — через OS Login по корпоративным учётным записям: постоянные SSH-ключи не храним, каждое действие попадает в журнал. Если политика требует изоляции, работаем в отдельном проекте или через выделенную служебную учётную запись с минимальным набором прав.

Что делать с наследием ручных настроек?

Сначала инвентаризация: что настроено руками, что уже описано кодом. Ручные правки фиксируем и переносим в шаблон, а прямые изменения на работающих машинах закрываем — иначе очередная раскатка их затрёт и расхождение вернётся.

Как проверяем, что ничего не отвалится?

Первым делом поднимаем копию production: на ней прогоняем шаблон, правила доступа и проверки здоровья, сравниваем метрики и логи с текущими. Только после этого запускаем первую волну реальных узлов, не трогая остальные.

Обсудим задачу: что нужно для оценки и плана

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

• Структура проектов и разделение сред: какие окружения существуют отдельно, кто владелец и кто выдаёт доступы.
• Сетевой контур: топология подсетей, выход наружу, балансировщики и правила связности между сервисами.
• Образы и шаблоны инстансов: чем собираются, где хранятся, кто и как обновляет базовый образ.
• Группы инстансов Compute Engine: зональные или региональные, какие метрики управляют масштабированием, как настроены проверки здоровья и порядок замены машин.
• Доступы инженеров: как попадают на хосты, где ведётся учёт ролей и ключей, нужен ли журнал входов для аудита.
• Текущее состояние: что уже описано декларативно, что создано руками, есть ли файл состояния и контроль версий.
• Ограничения: допустимое окно изменений и время простоя, требования к отказоустойчивости и резервному копированию.

Если часть пунктов пока без ответа — это нормально, пробелы тоже войдут в план как отдельные этапы. Опишите задачу словами: что работает сейчас и что должно получиться на выходе. Мы вернёмся с оценкой работ, планом внедрения и списком вопросов, которые нужно закрыть до старта.

Следующий шаг — разговор по делу: сверим ожидания, зафиксируем объём и порядок выката, чтобы первое изменение в production было предсказуемым.