Перенесли платформу в облако и обеспечили стабильный доступ для студентов из России
Karpov.Courses: перенесли платформу в российские облака и перешли на GitOps
Клиент: Karpov.Courses
Ниша: онлайн-образование, EdTech
Услуга: DevOps, миграция инфраструктуры, GitOps
За шесть лет инфраструктура онлайн-академии Karpov.Courses прошла путь от нескольких сервисов на виртуальных машинах до multi-cloud-архитектуры в Kubernetes. Ниже история о том, как мы провели последний этап этой трансформации: перенесли платформу в VK Cloud и Yandex Cloud без прерывания учебного процесса и перевели управление приложениями на GitOps.
Результаты
Перенесли около 3000 томов данных с ноутбуками, датасетами и результатами заданий без потерь
Сократили цикл «коммит → применение в кластере» с десятков минут до секунд после перехода на GitOps
Контекст
На старте инфраструктура была простой: виртуальные машины у провайдера Hetzner, сервисы в Docker-контейнерах, Ansible для конфигураций и CI/CD-пайплайн в GitLab для доставки изменений. Нагрузка была предсказуемой, сервисов немного, и один инженер контролировал всё от сетей до деплоя.
Позже часть сервисов перенесли в managed Kubernetes к облачному провайдеру DigitalOcean, который взял на себя поддержку кластера-оркестратора контейнеров. Terraform — инструмент, который описывает облачную инфраструктуру как код — отвечал за облачные ресурсы и Helm-релизы. В Kubernetes тогда работало около 5 сервисов.
Почему потребовалась миграция
С 2022 года зарубежная инфраструктура стала риском для бизнеса. Платежи в Hetzner и DigitalOcean проходили с перебоями и дорожали из-за курса. Началась веерная блокировка IP-адресов: часть студентов из России просто не могла зайти на платформу. Добавились вопросы и к юридической возможности хранения данных за рубежом.
Распределение инфраструктуры по разным провайдерам тоже не добавляло удобства. Если ломались два экземпляра одного и того же сервиса, сценарии их восстановления могли отличаться. Системы мониторинга были разными, расходились SLA. Подобные тонкости требовали от инженеров дополнительной экспертизы и ручной работы.
В этой точке к проекту подключились мы.
Задача
Задача была шире, чем миграция на облако провайдера в российской юрисдикции. Нужно было в сжатые сроки обеспечить прогнозируемую доступность платформы и подготовить инфраструктуру к росту. Для бизнеса важны были три вещи:
- Доступность платформы. Если студент не может зайти, он не учится, не сдаёт задания и не проходит курс.
- Миграция без переписывания продукта. Предстояло перенести сервисы в новое облако, затронув только инфраструктурный слой.
- Управляемость при масштабировании. Сервисов и инженеров стало больше, поэтому управление через Terraform-пайплайны начинало замедлять изменения и провоцировать ручные обходы через kubectl и helm.
Что сделали
Мы перенесли основную инфраструктуру в VK Cloud, развели сервисы по требованиям к доступности, вынесли критичный для учебы JupyterHub в отдельный контур в Yandex Cloud и перевели управление приложениями на GitOps.
Перенесли основную инфраструктуру в VK Cloud
Из российских провайдеров мы выбрали VK Cloud. Ключевыми факторами стали наличие managed Kubernetes, баз данных и балансировщиков нагрузки при подходящей стоимости вычислительных ресурсов.
При миграции из DigitalOcean в VK Cloud мы переписали только cloud-layer: заменили Terraform-провайдер и адаптировали ресурсы под API VK Cloud. Переезд стал поводом заодно модернизировать схему развертывания: в Kubernetes оказалось около 20 сервисов вместо прежних 5.
Чтобы переезд не задел бизнес-логику приложений, мы заранее разделили инфраструктурный код на два слоя:
- Cloud-layer описывает облачные ресурсы: сети, Kubernetes-кластеры, балансировщики и DNS. Он зависит от конкретного провайдера.
- App-layer описывает конфигурацию приложений: Helm-чарты, переменные окружения, секреты и ingress-правила — он от облака не зависит.
Подготовка к переезду была непростой. Kubernetes-платформа VK Cloud в тот период была на этапе активного развития, и не все её возможности соответствовали ожиданиям инженеров. Мы открыли более 50 тикетов в поддержку на разные темы: от багов в Terraform-провайдере до нестабильного поведения отдельных managed-сервисов.
Стоит отдать должное команде VK Cloud: часть проблем мы разобрали напрямую с архитекторами, и их исправили в следующих версиях платформы провайдера. Исправили проблемы, не архитекторов.
Развели сервисы по требованиям к доступности
В VK Cloud мы развернули два Kubernetes-кластера с разными требованиями к доступности:
Преподавательский кластер с внутренними инструментами. Доступ есть у узкого круга сотрудников, требования к отказоустойчивости стандартные, допустим кратковременный даунтайм.
Студенческий кластер с инструментами для обучающихся. К нему требования жёстче: отказоустойчивость на уровне зоны доступности, несколько master-нод для устранения единой точки отказа и автоскейлинг worker-нод под пиковые нагрузки. Больше всего студентов пользуются платформой в моменты запуска новых потоков и перед дедлайнами, и инфраструктура сама подстраивается под ажиотаж.
Собрали отдельный контур для JupyterHub в Yandex Cloud
JupyterHub — критичный учебный сервис, ведь в нём студенты работают с кодом. Там хранятся ноутбуки, датасеты и результаты заданий. Ему нужна была отдельная модель хранения данных, входа и восстановления, поэтому мы вынесли его в отдельный контур в Yandex Cloud.
Мы перенесли около 3000 томов с данными студентов в Object Storage без потерь. Сами JupyterHub теперь работают в нескольких зонах доступности, но вход для студентов организован через единый URL: путаницы с доступами нет, а нагрузку на разные бэкенды автоматически распределяет балансировщик.
После миграции мы имитировали отказ зоны доступности и убедились, что сервис продолжает работать, а трафик переключается корректно.
Перевели управление приложениями на GitOps
После миграции продукт продолжил расти, и к старым сервисам добавлялись новые. Terraform-пайплайны стали узким местом.
Инженеры могли выкатывать изменения только по одному, поэтому к пайплайну выстраивалась очередь. Когда сроки давили, часть приходилось вносить вручную в обход Terraform, и в результате код потихоньку разъезжался с реальным состоянием кластера.
Мы перестроили управление деплоем по подходу GitOps. У команды есть единый реестр изменений, которые применяются автоматически. В основе такой автоматизации лежит ArgoCD. Инженер фиксирует любое изменение в Git, а система сама приводит платформу к заданному описанию. Этот же механизм исключает любые ручные правки в обход процесса: система все равно откатит их к состоянию из Git.
При таком подходе изменения доходят до платформы за секунды вместо десятков минут, а деплой застрахован от сбоев из-за необъявленных ручных правок.
Что получилось
- Karpov.Courses перешла от разнородной инфраструктуры к более зрелой и управляемой модели.
- Основная часть платформы работает в VK Cloud, JupyterHub развернуты в отдельном контуре в Yandex Cloud. Terraform отвечает за облачный слой, ArgoCD — за управление приложениями, а Git фиксирует состояние и историю изменений.
- Платформа стала устойчивой, независимой от зарубежных провайдеров и готовой принимать новые сервисы без перестройки процессов.