Что нового в конвейерах доставки программного обеспечения CI/CD
Непрерывная интеграция и непрерывное развертывание — это главное в сфере доставки программного обеспечения. Организации разного размера внедрили конвейеры CI/CD, чтобы удовлетворить требования клиентов и обеспечить минимально возможное время выхода на рынок. Сфера CI/CD постоянно развивается, и в результате организации могут выбрать множество инструментов и сервисов для совершенствования своих рабочих нагрузок CI/CD. Давайте взглянем на некоторые тенденции в сфере CI/CD за последнее время.
1. Создание шаблонного ресурса с помощью Helm
Helm — это система упаковки, которая предоставляет конфигурацию Kubernetes командам DevOps без необходимости самим создавать несколько файлов конфигурации. Каждый раз, когда служба развертывается в среде K8s, ей требуется набор с отслеживанием состояния, секреты, пользователи K8s с соответствующими разрешениями и карта конфигурации. Создание разных файлов YAML, содержащих эту информацию, может занять много времени и приведет только к более медленному развертыванию. С помощью Helm пользователи могут создавать пакеты таких файлов YAML и загружать их в общедоступные или частные репозитории Helm для других пользователей, которым они нужны. Эти пакеты называются диаграммами Helm и могут быть легко использованы повторно.
Еще одна важная особенность Helm заключается в том, что он также действует как механизм шаблонов. Давайте рассмотрим пример нескольких микросервисов, которые необходимо развернуть в одном кластере. Все эти микросервисы немного отличаются друг от друга, но без Helm вам придется создавать несколько файлов YAML для всех этих микросервисов, что может занять много времени. У разработчиков нет времени создавать все эти файлы вручную. Здесь вы можете использовать шаблоны диаграмм Helm, где вам нужно всего лишь создать один файл YAML с заполнителями, заменяющими различные значения для разных микросервисов. У вас может быть отдельный файл YAML, содержащий все значения для разных микросервисов.
Еще одна функция Helm, которая помогает ускорить конвейер CI/CD, — это единая фиксация для развертывания сервисов в разных средах без разных наборов файлов YAML. Разработчики могут создавать свои собственные диаграммы Helm, которые они могут использовать для одновременного развертывания сервисов во всех своих различных средах.
2. GitOps для совместной работы и декларативных операций
Настройка инфраструктуры каждый раз, когда вы начинаете работать над рабочей нагрузкой, может быть утомительной, если вы выберете маршрут вручную. Традиционно для создания инфраструктуры требуется, чтобы команды вручную создавали серверы, сети, конфигурации и кластеры K8s.
Инфраструктура как код помогает командам DevOps определить все эти компоненты своей инфраструктуры в коде, чтобы ее можно было создавать и повторно развертывать. Это позволяет повторно использовать вашу инфраструктуру так же, как ваши модернизированные рабочие нагрузки. С помощью IaC вы можете объединить все различные спецификации инфраструктуры в код Terraform, код Ansible, файлы манифеста K8s и дополнительные файлы YAML. Команды DevOps могут создавать эти файлы локально и отправлять эти файлы в репозиторий git для контроля версий и совместной работы членов команды. Однако, поскольку все эти файлы создаются командой DevOps локально и могут быть созданы или обновлены кем угодно, трудно отслеживать все изменения. Из-за того, что тестирование здесь проводится вручную, некоторые непроверенные файлы могут оказаться в рабочей среде, а ошибки могут долгое время оставаться незамеченными. Здесь на помощь приходит GitOps. 
С GitOps вы указываете ряд шагов для оптимизации процесса публикации изменений, который начинается с репозитория Git, содержащего ваш код. Здесь каждый раз, когда пользователь отправляет запрос на внесение изменений в основную ветку, эти изменения не сливаются с основной веткой. Вы выполняете серию шагов, чтобы протестировать изменения и утвердить их.
После утверждения изменений, внесенных членом команды DevOps, эти изменения объединяются с основной ветвью. После этого агент GitOps замечает изменения и развертывает эти изменения в рабочей среде. Это происходит автоматически без ручного вмешательства.
Агент установлен в среде, которая постоянно проверяет фактическое состояние ваших рабочих нагрузок и проверяет репозиторий Git на предмет желаемого состояния. Если между двумя состояниями есть разница, он извлекает изменения из репозитория git и применяет эти изменения к среде. Этот автоматизированный процесс обеспечивает большую прозрачность и повышенную безопасность, поскольку утверждающая команда намного меньше, чем количество членов команды, которые могут предлагать изменения в коде инфраструктуры.
3. Безопасность, охватывающая плагины, контейнеры, среды, удостоверения
В рабочих нагрузках CI/CD безопасность нельзя откладывать на второй план. Безопасность должна быть встроена в рабочую нагрузку с самого начала. Команды DevOps и группы безопасности должны сотрудничать на каждом этапе жизненного цикла разработки программного обеспечения (SDLC), чтобы ни одна уязвимость не осталась незамеченной.
Модель доставки CI/CD требует, чтобы команды не только были в курсе всех передовых методов обеспечения безопасности, но и делали это быстро, чтобы не повлиять на время выхода на рынок. Из-за сложности конвейеров CI/CD невозможно вручную протестировать безопасность всех компонентов. Рабочие нагрузки CI/CD представляют огромную поверхность для атак. Команды безопасности должны настроить различные плагины и инструменты, используемые в конвейерах CI/CD, чтобы они не использовались в качестве бэкдоров для рабочих нагрузок организации.
Стадия сборки в рабочих нагрузках CI/CD также весьма уязвима, поскольку представляет собой слепое пятно. Злоумышленники могут изменить код, чтобы использовать его позже, когда он будет развернут в рабочей среде. Бриджи на этапе сборки недавно попали в заголовки и привели к утечке большого количества личных данных. Злоумышленники не атакуют организации напрямую. Если они смогут проникнуть в ваши рабочие нагрузки с помощью инструментов, которые вы используете для реализации конвейеров CI/CD, они смогут постепенно повышать свои уровни доступа и привилегии.
Поэтому для организаций важно обеспечить безопасность, которая помещает каждый компонент CI/CD в единую плоскость и обеспечивает сквозную видимость ваших сложных рабочих нагрузок, чтобы вы могли выявлять риски и устранять их до того, как они действительно нанесут какой-либо ущерб.. На рынке доступны инструменты, которые подключаются к вашим существующим рабочим нагрузкам CI/CD и предоставляют группам безопасности лучший обзор ваших рабочих нагрузок.
4. Модель внутренней платформы для создания масштабируемых сред
Традиционные корпоративные модели не масштабируются. Сегодня в организациях есть несколько команд, работающих над различными продуктами, которые используют разные стеки инфраструктуры и инструменты. С этим может стать чрезвычайно сложно справиться, когда дело доходит до управления затратами и соблюдением требований. Здесь может помочь модель внутренней платформы.
Вместо того, чтобы ваши команды DevOps беспокоились о развертывании новых ресурсов и инфраструктуры для разных продуктов, отдельные группы платформы могут позаботиться об инфраструктуре, создав унифицированный стек инфраструктуры, используемый различными продуктами в организации. Это позволяет разработчикам сосредоточиться на разработке продукта, а не на управлении инфраструктурой, тем самым экономя время и усилия.
Существует крутая кривая обучения, которую иногда упускают из виду организации, решившиеся на Kubernetes. С помощью модели внутренней платформы команда DevOps может поставлять продукты без необходимости постоянно заботиться о безопасности и конфигурациях, связанных с различными ресурсами, поскольку они обрабатываются командой платформы. Разработчики также могут быстро раскрутить любой ресурс, который им нужен, не дожидаясь эксплуатации, что сокращает время выхода на рынок. Безопасность также обеспечивается более эффективно в различных продуктах, поскольку она жестко запрограммирована командой платформы в средах и ресурсах.
Наконец, пространство CI/CD процветает благодаря постоянным инновациям. Организации, желающие окунуться в CI/CD, должны изучить все возможные варианты и внедрить конвейер, который подходит для их сценариев использования. Эти новые тенденции лишь подготавливают почву для появления новых вещей, которые сделают CI/CD менее пугающим и позволят большему количеству организаций использовать возможности непрерывной интеграции и непрерывного развертывания.