Эфемерные среды для экономичных и надежных CI/CD конвейеров с Kubernetes

Узнайте, как оптимизировать ваш CI/CD конвейер, улучшить качество кода и снизить затраты с помощью Kubernetes.

Термины «миграция в облако» и «цифровая трансформация» регулярно используются в корпоративных условиях. Хотя обе фразы могут означать разное, каждая из них движима общим знаменателем: потребностью в изменениях.

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

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

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

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

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

Используя пользовательские ресурсы в Kubernetes, разработчики могут определять конфигурации для этих сред, включая требования к ресурсам, что позволяет быстро и эффективно создавать и удалять такие объекты.

Данный подход способствует гибкой разработке и позволяет командам надежно и уверенно вносить изменения в код.

Kubernetes — это мощная платформа для современных развертываний контейнерных приложений. Существует множество компонентов, которые следует учитывать при построении эффективного конвейера CI/CD с Kubernetes.

Успеху конвейера Kubernetes CI/CD способствуют несколько ключевых компонентов:

Для настройки пайплайна CI/CD с использованием Kubernetes рекомендуется учитывать следующие лучшие практики:

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

Helm упрощает управление пакетами на Kubernetes, предоставляя готовые к использованию пакеты, называемые charts. Это облегчает разработчикам создание повторяемых развертываний, а также позволяет им настраивать свои приложения без необходимости писать дополнительный код или скрипты.

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

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

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

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

• Blue-Green развертывания позволяют переключать трафик между двумя идентичными версиями приложения, чтобы старые службы могли работать до тех пор, пока на этапе тестирования не будут успешно устранены все серьезные ошибки.

Контейнерные образы не должны содержать конфиденциальную информацию, такую как пароли, API ключи или токены. Вместо этого следует хранить данные во внешнем хранилище секретов, таком как AWS Secrets Manager или Hashicorp Vault, и получать их во время развертывания с использованием таких инструментов, как Helm Charts или kubectl.

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

В этом разделе мы рассмотрим два подхода к использованию эфемерных сред на Kubernetes. Первый подход заключается в использовании общего кластера Kubernetes, где каждая эфемерная среда создается в отдельном пространстве имен (namespace), но сам кластер остается единым для всех. Второй подход предусматривает создание отдельного кластера для каждой эфемерной среды.

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

Вы можете найти GitHub репозиторий с примером этого демонстрационного проекта здесь.

В этой демонстрации система будет состоять из двух микросервисов и одной базы данных Mongo для хранения данных. Когда мы откроем Pull Request (PR) для одного из микросервисов, на Kubernetes будет автоматически создана новая среда. Для создания и уничтожения эфемерной среды мы будем использовать инструмент vcluster. После завершения тестирования можно будет легко закрыть или смержить PR, что запустит еще один конвейер для удаления эфемерной среды.

Эти рабочие нагрузки мы развернули локально на кластере Kubernetes. Конвейеры созданы с использованием рабочих процессов GitHub Actions и инструмента kustomize для простого развертывания всей системы.

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

1. Проверка кода
2. Сборка Docker-образа
3. Отправка нового Docker-образа
4. Обновление манифестов Kubernetes
5. Развертывание нового временного окружения
6. Развертывание всей системы в этом окружении
7. Предоставление доступа к этому окружению

Это не окончательный вариант вашего рабочего процесса разработки, а просто демонстрационные шаги.

Мы будем использовать vcluster для создания полностью изолированных окружений Kubernetes. Проверьте файл workflow GitHub Actions ниже:

Шаги этого конвейера создадут образ и отправят его в наш реестр Docker, а также обновят Github новым тегом, после чего развернут виртуальный кластер и предоставят к нему доступ с помощью обычного файла KUBECONFIG.

Вы можете управлять доступом к кластеру по-разному в зависимости от способа авторизации пользователей.

Теперь, выполнив команду vcluster list, мы сможем увидеть вновь созданный эфемерный кластер; имя кластера зависит от SHA-кода коммита GitHub и идентификатора пользователя на GitHub, чтобы избежать создания кластеров с одинаковыми именами.

Теперь давайте проверим развернутые рабочие нагрузки.

Очевидно, что все рабочие нагрузки развернуты в новой среде и только для этой среды.

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

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

Рабочий процесс PR GitHub будет практически таким же, как и в среде разработки, но мы не будем размещать новый тег изображения на GitHub, а развернем его непосредственно в недавно созданной эфемерной среде.

Нам также нужно создать процесс, который будет удалять созданную среду при слиянии или закрытии Pull Request:

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