Статью подготовил Брюханов Константин, руководитель курса «CI/CD». В ней Константин раскрыл ряд проблемных моментов, связанных доставкой развертыванием кода программного продукта в IT-компаниях, и собрал рекомендации из числа лучших международных практик.
В айти-эксплуатации самым востребованным направлением является именно наладка и обеспечение непрерывной доставки и развертывания. Технологии и методологии постоянно развиваются, совершенствуются инструменты. В связи с этим последние требования к доставке и развертыванию включают в себя готовность и непрерывность тестирования изменений, подготовку и настройку тестовой среды для команды обеспечения качества.
Технологический прорыв и свободно-распространяемое ПО привели к тому, что подход к организации процессов CI/CD значительно изменился. Переход на новые принципы сильно повлиял на корпоративную культуру, востребованные навыки сотрудников и сами принципы работы в организациях, что привело к масштабным переменам в мире разработки ПО.
Облачные решения становятся все более приоритетными. Для непрерывной поставки ПО необходимо эффективное взаимодействие групп разработки, тестирования и эксплуатации, а облачная среда отлично подходит для такого взаимодействия.
Однако этап развертывания, выполняемый в сложной распределенной топологии, подвержен ошибкам и, как правило, требует ручного поиска и устранения неисправностей. Этап развертывания продуктов в рамках процесса непрерывной поставки часто создает узкие места и отрицательно влияет на эффективность процесса DevOps.
Непрерывная поставка позволяет достичь автоматизации тестирования инкрементальных изменений ПО и оперативного развертывания обновлений максимально эффективными и безопасными методами. Такой подход дает пользователям уверенность, что в производственной среде используется самая свежая версия кода, и изменения, вносимые программистами, могут попадать к клиентам за считанные часы или даже минуты.
Рассмотрим наиболее общий сценарий реализации CI/CD в проекте:
- Команда разработки выпускает новую версию продукта (новый функционал или исправление ошибок предыдущего релиза).
- Сервис непрерывной интеграции (CI) проверяет новый код рядом тестов, включающих несколько уровней тестирования, такие как синтаксические, модульные и регрессионные тесты.
- В случае успеха сервис непрерывной интеграции готовит новую сборку программного продукта и совершает системный вызов к сервису, осуществляющему непрерывную доставку (CD).
- Совместно с сервисом непрерывного развертывания (часто, этот функционал выполняет один и тот же сервис) автоматическим образом поднимается сущность, отвечающая за промежуточное развертывание (staging), где в условиях близких к производственным проводятся дополнительные интеграционные, дымовые и нагрузочные тесты.
- После успешного проведения stage-тестов система CI/CD доставляет новую версию продукта на производственные мощности, где выполняется бесшовное развертывание параллельной инсталляции продукта.
- Пользовательский трафик переключается на новую версию ПО.
Данный сценарий является наиболее общим и покрывает большинство нужд команд разработки и эксплуатации, но всё же имеет некоторые проблемы, например:
- Замена файлов. Зачастую требуется обновление или замена конфигурационных файлов или перегенерация какого-то статичного контента. В этом случае пользователи могут получать ошибки, пока не произошло переключения трафика со старой версии ПО на новую. В случае же, когда развертывание закончилось неудачей, есть риск несовместимости файлов.
- Обновление системных ресурсов. Предположим, ваша система конфигурируется под самообслуживание, настраиваются планировщики и системные демоны. Во время развертывания новой версии у вас могут заменяться команды и префиксы для системных вызовов. Однако существует вероятность, что какие-то из этих функций потребуются для работающей сейчас версии приложения, из-за чего оно не будет должным образом обслужено и работа сервера нарушится.
- Конфигурирование баз данных. Изменения конфигурации базы данных порождают наиболее сложные проблемы. Обновление решения приводит к изменениям структуры таблиц, пользовательских полномочий, сохраненных данных и т.д. При выполнении развертывания база данных может стать недоступна для работающего приложения на время применения новых миграций. Также существует вероятность ошибки развертывания, из-за чего база данных уже не будет соответствовать требуемой для нормальной работы приложения, и даже повторное развертывание прежней версии не решит проблему, т.к. потребуется разработка специальных обратных миграций.
Стоит заметить, что перечисленные выше проблемы могут возникнуть даже в близкой к идеальной среде, но одна из основных сложностей внедрения методологии DevOps состоит в том, что нет единой картины, как должен выглядеть процесс непрерывной доставки и развертывания продукта. Многие IT-компании знают о DevOps слишком мало, иногда и вовсе не понимают этой методологии, в других же уже есть исторически сложившиеся решения, поверх которых приходится выстраивать новые процессы. С учетом высоких требований к квалификации Devops-специалистов, и их нехваткой на рынке труда работодатель зачастую вынужден использовать уже имеющиеся у него ресурсы и отдавать Devops-задачи начинающим инженерам. Как итог, в системе получается еще больше слабых мест.
При использовании CI/CD без правильного понимания методологии, без аналитического подхода к построению инфраструктуры и методов доставки кода вытекают следующие проблемы:
1. Человеческий фактор. Первый и самый существенный риск связан с человеческим фактором. Представим себе ситуацию, когда необходимо настроить ещё несколько серверов, аналогичных существующим. Если специалист, который производил предыдущие установки или настройки в данный момент недоступен по каким-либо причинам (болен, уволился и т.д.) и не подготовил подробных инструкций, то ситуация значительно осложняется. В этом случае каждый новый специалист должен изучить весь процесс настройки сервера полностью, при этом у него нет права на ошибку. А кроме того, нельзя точно оценить, сколько времени уйдет на настройку, и гарантировать ее успех.
Сюда же относятся риски связанные с тем, что автор метода допустил ошибку, забыл покрыть тестами процессы или просто-то что-то не учел, а его преемник этого не заметил.
Не стоит также забывать, что нередко в компаниях разрабатываются несколько проектов, а отдел IT-эксплуатации обычно один, и один инженер эксплуатации обслуживает несколько проектов. Если нет единой схемы и концепции, то процессы в разных командах будут выстроены по-разному, что значительно затруднит последующее развитие Devops в компании и сделает высокий порог вхождения инженера эксплуатации в другой проект, где уже используются процессы, отличные от тех, с которыми он работал ранее.
2. Неидемпотентные сценарии. Идемпотентность является важнейшим атрибутом сценариев непрерывной доставки и развертывания кода особенно в условиях развертывания инфраструктуры. Инженер должен быть уверен, что каждый раз при выполнении сценариев результат будет однозначно гарантированным, ожидаемым и неизменным при повторном проигрывании того же сценария. Зачастую при внедрении Devops в компании инженеры стараются разработать бизнес-решение и могут не учесть идемпотентность или же просто не знать об этом требовании. В этом случае компания получает бомбу замедленного действия, т.к. существует вероятность доставить на производственные мощности неожидаемый код. Например, если кто-то обновил модуль системы управления конфигурациями для одного проекта, и тем самым повлиял на остальные, где этого не ожидают.
3. Хранение чувствительных данных и организация доступа. Один из самых важных моментов в Devops-подходе к хранению секретных данных, ограничению прав, организации сетевого и пользовательского доступа. До сих пор нет единых принятых практик и инструментов, позволяющих решить эту проблему, и инженерам приходится каждый раз проводить исследования в зависимости от текущей организации инфраструктуры и принятых методов ограничения доступа. По этой причине внедрение методологии Devops на предприятии усложняется тем, что нельзя однозначно найти решение под свой частный случай, а применение чужих практик не всегда гарантирует безопасность.
4. Определенная модель бюджетирования, более подходящая для Waterfall методологии.
5. Высокие требования к безопасности. Следовательно, невозможно разместить инфраструктуру национальных IT-проектов в зоне ответственности коммерческих, иностранных компаний, например, Amazon, Microsoft.
6. Большой объем «legacy code», «legacy infrastructure», которые необходимо поддерживать. Необходимость интеграции с большим количеством устаревших систем.
Таким образом процесс построения Devops на предприятии может сопровождаться рядом проблем и не всегда решать задачи, для которых создан.
Первым важным шагом является отказ от отношения к серверам, как трудно настраиваемому, уникальному элементу инфраструктуры, переход от ручной настройки сервера к автоматизированному, централизованному управлению инфраструктурой. Процесс настройки каждого сервера должен быть описан в виде конфигурации, легко читаемой, изменяемой, и готовой к многократному безопасному переиспользованию, обеспечивающему однозначный гарантированный результат. Примерами промышленных систем-оркестраторов являются Chef или Ansible. Данные системы позволяют управлять большим количеством серверов с минимальными затратами.
Следующим важным шагом является применение автоматизированного тестирования, чтобы для как можно большего покрыть функционал разрабатываемого кода (как программного, так и инфраструктурного). Иначе говоря, имея развернутую инфраструктуру, но без автоматизированного тестирования, узким местом процесса разработки будет своевременная проверка функционала. Автоматизирование процесса тестирования должно начинаться с собственно написания кода ПО (модульное тестирование), применения первичных тестов на сервере, который отвечает за сборку ПО, а также тест конфигурации серверов. Это позволит снизить нагрузку на команду обеспечения качества ПО и значительно снизит время прохождения ПО на конвейере.
Заключительным логичным шагом является централизованный сбор и анализ лог-файлов со всех серверов для своевременного оповещения всех заинтересованных лиц и проактивном наблюдении за состоянием инфраструктуры в целом.
Приведенные выше рекомендации позволят построить устойчивую масштабируемую инфраструктуру, способную работать в интенсивном процессе разработки. Внедрение DevOps требует вовлеченности в процесс каждого участника от отделов тестирования и разработки до менеджеров и отдела эксплуатации. На каждом этапе требуется постоянный ретроспективный анализ процесса, ведь в результате случайных ошибок при изменении конфигурации полностью останавливается работа систем. Необходимо улучшать телеметрию, чтобы эффективнее обнаруживать ошибки и осуществлять восстановление, а так же для защиты конвейера развертывания и достижения целей по изменению управления. Это позволит получать максимальную поддержку со стороны руководства при внедрении инициатив DevOps, создать более оживленную и дружелюбную рабочую среду, чтобы любой участник смог учиться в течение всего времени — это не только поможет каждому исполнителю достичь целей, но и приведет организацию к успеху.
За 3 месяца на нашем онлайн-курсе «CI/CD» вы сформируете понимание архитектуры облачных провайдеров, изучите автоматизацию анализа кода и поиска уязвимостей и научитесь настраивать процессы сборки, тестирования и установки приложения от трех крупнейших провайдеров. Программа рассчитана на специалистов с опытом администрирования — специальный вступительный тест поможет сориентироваться, хватит ли вам подготовки для обучения.