В начале года я рассказывал, как мы запустили программу подготовки DevOps-инженеров для вузов. Готовили материалы, обучали преподавателей, предоставляли доступ к нашей платформе, чтобы вырастить специалистов, которые нужны рынку, а не просто умеют делать пет-проекты по вечерам.

Сейчас в программе участвуют почти 40 вузов, через курс прошли тысячи студентов. Некоторые выпускники уже работают в моей команде. Успех? Успех. Кажется, процессы отлажены, материалы написаны, нужно только их поддерживать. Однако прошлый год преподнес сюрприз. Обычно мы запускаем три потока обучения в год, но тогда партнеры решили иначе: один поток, но с тройным количеством участников. Больше ста преподавателей вузов, которым нужно получить актуальные знания, обновленные материалы и доступ к стенду. А у нас немного устаревший курс и мало людей на сопровождение. В общем, есть место для подвига.

Год = эпоха

За время, прошедшее с последней записи курса, изменилось буквально все. Закрылись доступы к зарубежным ресурсам (привет, DockerHub), ужесточились требования регуляторов, да и наши продукты заметно развились. В итоге, прежние материалы можно было отнести к историческим реликвиям — они показывали студентам-преподавателям мир, которого больше не существует.

Отчасти мы это предсказали: говорили студентам, что золотой век Docker катится к закату и он перестал быть доминирующей средой выполнения контейнеров, что фокус сместится на ИБ и процессы безопасной разработки. Так и вышло. Сейчас у нас все выстраивается с оглядкой на РБПО, а в нашем курсе об этом — лишь упоминания.

Но визионерства на все не хватило. Мы сделали упор на Docker, Podman упомянули вскользь, не дали альтернатив вживую. А главное — практически не раскрыли Terraform и Ansible, хотя сегодня это критически важные инструменты. У нас теперь это отдельный проект — Basis Automation Tools, с собственным провайдером Terraform, модулями для Ansible, SDK. А в курсе об этом можно узнать только из беглых комментариев.

Ситуацию нужно было менять, и мы стали искать варианты. Для начала удвоили количество консультаций – вебинаров, на которых преподаватели задают вопросы, — чтобы закрыть зазор между тем, что было прежде, и текущей технологической реальностью. Добавили практику по Terraform и Ansible — полноценные задания, которые преподаватели могут использовать на занятиях со своими студентами.

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

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

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

Проблем подкинул и SMS-шлюз для авторизации — работал с перебоями. Я предположил, что он не выдерживает нагрузки, когда сто человек одновременно пытаются зарегистрироваться, но даже если моя догадка была верна, повлиять на шлюз мы никак не могли. Нужно было искать альтернативу и не столкнуться с теми же проблемами.

Путь самурая

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

Путь первый: локально. Некоторые задания преподаватели могли выполнить на собственных компьютерах или лабораторном стенде вуза. Для тех, кто мог развернуть окружение локально (K3D, Docker), подготовили инструкции и продвинутые задания. Некоторым вузам, вроде Бауманки, повезло — у них своя инсталляция нашего продукта, ее можно было использовать.

Путь второй: онлайн-песочницы. Собрали список ресурсов для практики: Play with Docker, Killercoda и другие. В текущих реалиях использование зарубежных ресурсов выглядит иронично, но если инструмент работает и помогает учиться, то грех не воспользоваться.

Путь третий: офлайн-образ. Самый важный. Дать преподавателям возможность работать непосредственно внутри нашего стенда, но без доступа в интернет.

Самым эффективным решением проблемы был третий путь, и для него нужно было изобрести то, что изобретено давно — автономное DevOps-окружение. Бинарники, утилиты, предзагруженные образы Docker, Kubernetes, Helm, скрипты для настройки — все, что обычно тянется из сети в процессе обучения, нужно было упаковать внутрь. Однако я с таким напрямую не сталкивался и руками делал нечто подобное едва ли не в прошлом веке. Пришлось тряхнуть стариной.

Сборка офлайн-образа оказалась отдельной инженерной задачей, и лично для меня более сложной, чем просто подготовить виртуальную машину и “сохранить состояние”. Основная проблема была не в Docker или Kubernetes, а в том, чтобы полностью убрать даже неочевидные сетевые зависимости на всех этапах: от кастомизации до первого запуска.

В качестве основы использовался стандартный образ, который в дальнейшем приходилось дорабатывать через инструменты кастомизации. На этом этапе в дело вступили virt-customize, qemu-img и связанный с ними стек. И почти сразу выяснилось, что многие привычные сценарии предполагают наличие сети по умолчанию.

Например, virt-customize на этапе сборки при кастомизации использовал сетевой стек libguestfs, что в закрытом контуре приводило к падению сетевых операций , после чего запускал стандартные шаги инициализации. В нормальных условиях это незаметно, но в закрытом контуре такие попытки приводили к падению установки: обновления пакетов и установки внутри кастомизации просто не работали.

Отдельным источником сюрпризов для меня стал cloud-init. Даже если он формально не нужен для учебного окружения, его хуки и дефолтные сценарии инициализации все равно пытались выполнить сетевые действия. Пришлось либо отключать часть логики, либо выполнять шаги заранее, чтобы при первом старте образ не пытался стучаться во внешний мир.

В какой-то момент стало понятно, что от онлайн-установки нужно отказаться полностью. Все зависимости пришлось собирать заранее и упаковывать в офлайновый комплект. Его подключали к образу вручную, без попыток что-либо скачать или обновить в процессе сборки. Казалось бы, дальше все просто – распаковать архив и продолжить. Но и здесь нашлись подводные камни. Некоторые инструменты ожидали zstd, другие – gzip, третьи путались между форматами и отказывались распаковывать данные. Несколько итераций ушло просто на то, чтобы подобрать формат, который корректно переживает весь пайплайн сборки.

Дополнительной болью стал размер образа. По мере добавления зависимостей он разрастался очень быстро, и на этапе подготовки регулярно всплывало “no space left on device”. Пришлось вручную увеличивать виртуальный диск, а затем отдельно растягивать файловую систему, иначе дальнейшая кастомизация просто ломалась.

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

Финальный критерий был простой и жесткий: после развертывания среды, ни Docker, ни Kubernetes, ни Helm, ни cloud-init не должны даже пытаться сходить в интернет. Если где-то появлялся сетевой запрос, значит, образ считался неготовым. Рабочий вариант получился не с первого и даже не с пятого раза, но в итоге все же получился.

Готовый образ я сжал и передал технической поддержке, инженеры залили его на ученический стенд, проверили и раздали студентам. Образ развернулся без проблем, студенты получили доступ к виртуальным машинам с полностью готовым окружением. Можно было выполнять 99% заданий курса в «запечатанной» среде, без интернета.

Единственный минус: некоторые шаги мне пришлось предвыполнить — по-другому образ было не сделать. Не все студентам в ходе выполнения работы эти шаги оказались понятны, а методичка по понятным причинам помочь им не могла, пришлось объяснять «вручную». Но в целом образ сработал. Да, в нем нельзя показать живую работу с внешними реестрами, обновления образов или реальный жизненный цикл инфраструктуры. Зато он снимает главную учебную боль закрытого контура: все сетевые зависимости зафиксированы заранее. Docker-образы загружены локально, версии инструментов зацементированы, Kubernetes и Helm не пытаются сходить в интернет ни на одном шаге выполнения заданий. Студенты могут сосредоточиться на самих практиках вместо борьбы с pull, install и недоступными внешними сервисами.

Уже после внедрения офлайн-образа стало понятно, что недостаточно просто написать в общий чат “вот, всё - делайте так и так”. Когда в обучении участвуют больше ста преподавателей, нельзя рассчитывать на то, что все будут внимательно читать чат, следить за апдейтами и держать в голове последние изменения. До самого конца обучения часть преподавателей продолжала ориентироваться на старую методичку – не потому, что они что-то делали не правильно, а потому, что именно она была для них основным и самым надежным источником информации.

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

Результаты

Обучение прошло, настало время подводить итоги. Проблемы, которые возникли внезапно — отключенный интернет, барахлящий SMS-шлюз — были по нашему профилю. Мы справились с первого раза, не собрав негатива. Образ заработал, консультации прошли отлично, методичку обновили. Мы знаем, что нужно исправить к следующему запуску, как минимум, нужно найти альтернативу SMS-шлюзу и еще раз обновить методички. Главное, договорились, что DevOps-обучение больше не нужно строить с неявным предположением о наличии интернета. Даже если доступ формально есть, он может быть нестабильным, ограниченным или полностью закрытым.

Любой курс, завязанный на Docker, Kubernetes, Helm или Terraform, рано или поздно упрется в вопрос: какие шаги требуют сети, какие можно выполнить офлайн, а какие стоит сделать заранее. Если на этот вопрос нет ответа, обучение может сломаться в самый неподходящий момент.

При подготовке обучения для закрытого контура полезно заранее закладывать:

• предзагруженные образы Docker без динамических тегов;

• Helm-чарты и Kubernetes-манифесты, не тянущие зависимости в рантайме;

• офлайн-альтернативы шагам инициализации;

• сценарии аутентификации, не завязанные на внешние API;

• методички, которые описывают конечное состояние среды, а не путь к нему через интернет.

Это не заменяет полноценную платформу, но позволяет обучению состояться там, где иначе оно бы просто не началось.

Чтобы не перегружать свой рассказ, все технические подробности, как именно «запечатать» Kubernetes, Docker и Helm в один образ, с какими ошибками я столкнулся и как их решал, я оформил в отдельную статью.