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

Безопасность облачной среды

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

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

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

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

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

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

Что такое облачная безопасность?

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

Типы облачных сред

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

Публичные облачные сервисы

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

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

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

CI/CD конвейеры предоставляют прозрачный и отслеживаемый процесс разработки, что способствует лучшему взаимодействию между членами команды. Разработчики могут легко отслеживать изменения, определять участников и поддерживать целостность процесса разработки.

Эфемерные среды: гибкое тестирование и беспроблемное развертывание

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

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

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

Ключевые компоненты Kubernetes CI/CD конвейера

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

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

1

Контейнеры

Самодостаточные программные единицы, которые упаковывают код и зависимости, способствуют быстрому и стабильному развертыванию приложений в различных средах.
2

Кластеры рабочих узлов

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

Система управления версиями (VCS)

Обеспечивает управление изменениями исходного кода, позволяя разработчикам без проблем вносить обновления в общие репозитории.
4

Управление конфигурацией

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

Регистр образов

Централизованные репозитории для хранения образов контейнеров, оптимизирующие доступ в ходе процессов CI/CD.
6

Безопасность

Защита данных на всех этапах CI/CD конвейера, от репозиториев исходного кода до развертывания на продакшн.
7

Непрерывный мониторинг и Observability

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

CI/CD и Kubernetes: лучшие практики

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

1) Используйте GitOps:

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

2) Используйте Helm для упаковки приложений:

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

3) Следуйте лучшим практикам безопасности:

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

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

4) Используйте паттерны развертывания Canary и Blue-Green:

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

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

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

5) Не размещайте конфиденциальные данные в контейнерах:

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

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

Настройка и практическое применение:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

Источник: https://medium.com/@seifeddinerajhi/ephemeral-environments-for-cost-effective-and-reliable-ci-cd-pipelines-with-kubernetes-d6a3ee797a94*

* - просмотр доступен через подключение VPN-соединения

Не пропустите последние новости. Подписывайтесь!