Ли Цинван - Инженер по разработке программного обеспечения, Cisco
введение
Привет всем, меня зовут Ли Цинван, инженер по разработке программного обеспечения из Cisco. Наша команда уже почти три года использует Apache DolphinScheduler для создания собственной платформы планирования больших данных. Начиная с первоначальной версии 2.0.3 и до настоящего времени, мы росли вместе с сообществом. Технические идеи, которыми мы сегодня поделились, являются вторичными разработками на основе версии 3.1.1, в которых добавлены некоторые новые функции, не включенные в версию сообщества.
Сегодня я расскажу, как мы используем Apache DolphinScheduler для создания платформы больших данных, а также отправки и развертывания наших задач в AWS. Некоторые проблемы, возникшие в ходе этого процесса, и наши решения.
Проектирование и корректировка архитектуры
Изначально все наши сервисы развертываются в Kubernetes (K8s), включая API, Alert и такие компоненты, как Zookeeper (ZK), Master и Worker.
Задачи обработки больших данных
Мы провели вторичную разработку на таких задачах, как Spark, ETL и Flink:
ETL-задачи: Наша команда разработала простой инструмент перетаскивания, с помощью которого пользователи могут быстро генерировать задачи ETL.
Поддержка Искры : Ранняя версия поддерживала работу только Spark на Yarn, а мы сделали так, чтобы она поддерживала работу на K8 посредством вторичной разработки. Последняя версия сообщества в настоящее время поддерживает Spark на K8s.
*Флинк вторичного развития: Аналогичным образом мы добавили задачи потоковой передачи Flink на K8s, а также поддержку задач SQL и задач Python на K8s.
Поддержка задания на AWS
Поскольку бизнес расширяется и требуются политики в отношении данных, мы сталкиваемся с проблемой необходимости запускать задачи обработки данных в разных регионах. Это требует от нас создания архитектуры, которая сможет поддерживать несколько кластеров. Ниже приведено подробное описание нашего решения и процесса внедрения.
Наша текущая архитектура состоит из конечной точки централизованного управления — одной службы Apache DolphinScheduler, которая управляет несколькими кластерами. Эти кластеры распределены в разных регионах, например в ЕС и США, в целях соблюдения местных политик данных и требований изоляции.
Архитектурная корректировка
Чтобы удовлетворить этот спрос, мы внесли следующие изменения:
Обеспечьте централизованное управление службой Apache DolphinScheduler.: Наша служба DolphinScheduler по-прежнему развернута в собственном контроллере домена Cisco Webex, обеспечивая централизацию и согласованность управления.
Поддержка кластера AWS EKS : В то же время мы расширили возможности нашей архитектуры для поддержки нескольких кластеров AWS EKS. Таким образом, можно удовлетворить новые бизнес-требования к задачам, выполняемым в кластере EKS, не влияя на работу и изоляцию данных других кластеров Webex DC.
Благодаря такой конструкции мы можем гибко реагировать на различные потребности бизнеса и технические проблемы, обеспечивая при этом изоляцию данных и соответствие политикам.
Далее мы расскажем, как обрабатывать техническую реализацию и зависимости ресурсов Apache DolphinScheduler при выполнении задач в Cisco Webex DC.
Зависимости ресурсов и хранилище
Поскольку все наши задачи выполняются в Kubernetes (K8s), для нас крайне важно:
Докер-образ
место хранения: Раньше все наши образы Docker хранились в репозитории Docker в Cisco.
Управление изображениями: эти образы предоставляют необходимую операционную среду и зависимости для различных служб и задач, которые мы выполняем.
Файлы ресурсов и зависимости
Jar-пакеты, файлы конфигурации и т. д.: Мы используем Amazon S3 Bucket в качестве центра хранения ресурсов для хранения пользовательского пакета Jar и возможных зависимых файлов конфигурации.
Управление ресурсами безопасности: включая пароли базы данных, информацию о шифровании Kafka, ключи, зависящие от пользователя, и т. д. Эта конфиденциальная информация хранится в службе Cisco Vault.
Безопасный доступ и управление правами
Для доступа к S3 Bucket нам необходимо настроить учетные данные AWS и управлять ими:
Конфигурация учетной записи IAM
Управление учетными данными: мы используем учетные записи IAM для управления доступом к ресурсам AWS, включая ключи доступа и секретные ключи.
Интеграция K8s: эти учетные данные хранятся в секрете Kubernetes и на них ссылается служба API для безопасного доступа к корзине S3.
Контроль разрешений и изоляция ресурсов: С помощью учетных записей IAM мы можем реализовать детальный контроль разрешений, чтобы обеспечить безопасность данных и соблюдение требований бизнеса.
Проблемы со сроком действия и меры противодействия ключам доступа к учетной записи IAM
В процессе использования учетных записей IAM для управления ресурсами AWS мы сталкиваемся с проблемой истечения срока действия ключа доступа. Вот подробнее о том, как мы решаем эту проблему.
Проблема с истечением срока действия ключа доступа
ключевой период: Срок действия ключа AWS учетной записи IAM обычно истекает каждые 90 дней, что позволяет повысить безопасность системы.
влияние миссии: По истечении срока действия ключей все задачи, которые используют эти ключи для доступа к ресурсам AWS, не смогут выполняться, что требует от нас своевременного обновления ключей для обеспечения непрерывности бизнеса.
В ответ на эту ситуацию мы настраиваем регулярные перезапуски задачи и настраиваем соответствующий мониторинг. Если до истечения срока действия возникает проблема с учетной записью AWS, нам необходимо уведомить наших соответствующих разработчиков о необходимости выполнения некоторой обработки.
Поддержка AWS EKS
По мере расширения нашего бизнеса на AWS EKS нам необходимо внести ряд корректировок в существующую архитектуру и меры безопасности.
Например, как и упомянутый только что образ Docker, мы ранее поместили его в собственный репозиторий Docker Cisco, поэтому теперь нам нужно поместить образ Docker в ECR.
Поддержка нескольких сегментов S3
Из-за децентрализованного характера кластеров AWS и требований различных предприятий к изоляции данных нам необходимо поддерживать несколько корзин S3 для удовлетворения потребностей в хранении данных различных кластеров:
Соответствие между кластером и сегментом: каждый кластер будет иметь доступ к соответствующему сегменту S3, чтобы обеспечить локальность данных и соответствие требованиям.
Изменить стратегию: Нам необходимо скорректировать нашу политику доступа к хранилищу для поддержки чтения и записи данных из нескольких корзин S3. Разным компаниям необходим доступ к соответствующим корзинам S3.
Изменения в инструментах управления паролями
Чтобы повысить безопасность, мы перешли с собственного сервиса Vault от Cisco на AWS Secrets Manager (ASM):
Использование АСМ: ASM предоставляет более интегрированное решение для управления паролями и ключами для ресурсов AWS.
Мы приняли метод использования роли IAM и учетной записи службы для повышения безопасности Pod:
Создание роли и политики IAM: сначала создайте роль IAM и привяжите к ней необходимые политики, чтобы обеспечить предоставление только необходимых разрешений.
Привязать сервисную учетную запись K8s: затем создайте учетную запись службы Kubernetes и свяжите ее с ролью IAM.
Интеграция разрешений подов: при запуске модуля, связав его с учетной записью службы, модуль может получить необходимые учетные данные AWS непосредственно через роль IAM, тем самым получив доступ к необходимым ресурсам AWS.
Эти изменения не только улучшают масштабируемость и гибкость нашей системы, но и укрепляют общую архитектуру безопасности, обеспечивая эффективность и безопасность работы в среде AWS. В то же время это также позволяет избежать предыдущей проблемы автоматического истечения срока действия ключей и необходимости перезагрузки.
Оптимизировать процессы управления ресурсами и хранения
Чтобы упростить процесс развертывания, мы планируем отправить образ Docker непосредственно в ECR вместо вторичного транзита:
нажать напрямую: Измените текущий процесс упаковки так, чтобы образ Docker передавался непосредственно в ECR после сборки, сокращая временные задержки и потенциальные ошибки.
Изменить реализацию
Корректировки уровня кода: Мы изменили код DolphinScheduler, чтобы он мог поддерживать несколько клиентов S3, и добавили управление кэшем для нескольких клиентов S3.
Изменения пользовательского интерфейса управления ресурсами: позволяет пользователям выбирать разные имена корзин AWS для операций через интерфейс.
доступ к ресурсам: Модифицированный сервис Apache DolphinScheduler теперь может получать доступ к нескольким корзинам S3, что обеспечивает гибкое управление данными между различными кластерами AWS.
Изоляция управления и разрешений ресурсов AWS
Интегрируйте AWS Secrets Manager (ASM)
Мы расширили Apache DolphinScheduler для поддержки AWS Secrets Manager, что позволяет пользователям выбирать секреты в разных типах кластеров:
Функциональная интеграция ASM
Улучшения пользовательского интерфейса: В пользовательский интерфейс DolphinScheduler добавлены функции отображения и выбора разных типов секретов.
Автоматическое управление ключами: Сопоставляет путь к файлу, в котором сохраняется выбранный пользователем секрет, с фактической переменной среды Pod во время выполнения, обеспечивая безопасное использование ключа.
Служба динамической конфигурации и инициализации ресурсов (Init Container)
Чтобы более гибко управлять ресурсами AWS и инициализировать их, мы внедрили сервис под названием Init Container:
Привлечение ресурсов: Контейнер инициализации автоматически извлечет ресурсы S3, настроенные пользователем, и поместит их в указанный каталог перед выполнением модуля.
Управление ключами и конфигурациями: В соответствии с конфигурацией Init Container проверит и извлечет информацию о пароле в ASM, затем сохранит ее в файле и сопоставит с переменными среды для использования Pod.
Применение Terraform для создания и управления ресурсами
Мы автоматизировали процесс настройки и управления ресурсами AWS через Terraform, упростив распределение ресурсов и настройку разрешений:
Автоматическая настройка ресурса: используйте Terraform для создания необходимых ресурсов AWS, таких как S3 Bucket и ECR Repo.
Политика IAM и управление ролями: автоматически создавайте политики и роли IAM, чтобы обеспечить каждому бизнес-подразделению доступ по требованию к необходимым ему ресурсам.
Изоляция разрешений и безопасность
Мы используем сложные стратегии изоляции разрешений, чтобы гарантировать, что различные бизнес-подразделения работают в независимых пространствах имен, избегая конфликтов доступа к ресурсам и рисков безопасности:
Детали реализации
Создание и привязка Сервисного аккаунта: Создайте независимую учетную запись службы для каждого бизнес-подразделения и привяжите ее к роли IAM.
Изоляция пространства имен: каждая операция учетной записи службы получает доступ к соответствующим ресурсам AWS через роль IAM в указанном пространстве имен.
Улучшения в поддержке кластеров и управлении разрешениями.
Расширения типа кластера
Мы добавили новое поле cluster type, для поддержки различных типов кластеров K8S, которые включают не только стандартные кластеры Webex DC и кластеры AWS EKS, но также поддерживают определенные кластеры с более высокими требованиями к безопасности:
Управление типами кластеров
Поле типа кластера: Представленоcluster typeполя, мы можем легко управлять и расширять поддержку различных кластеров K8S.
Настройка уровня кода: Основываясь на уникальных потребностях конкретных кластеров, мы можем вносить изменения на уровне кода, чтобы обеспечить соблюдение требований безопасности и конфигурации при выполнении заданий в этих кластерах.
Расширенная система контроля разрешений (система аутентификации)
Мы разработали систему аутентификации специально для детального контроля разрешений, включая управление разрешениями между проектами, ресурсами и пространствами имен:
Функция управления правами
Разрешения на проект и ресурсы: пользователи могут управлять разрешениями через измерение проекта. Получив разрешения проекта, они получают доступ ко всем ресурсам проекта.
контроль разрешений пространства имен: убедитесь, что конкретная группа может выполнять задания своего проекта только в указанном пространстве имен, тем самым обеспечивая изоляцию рабочих ресурсов.
Например, команда A может запускать определенные задания проекта только в своем пространстве имен A. Например, пользователь B не может запускать задания в пространстве имен пользователя A.
Приложение для управления ресурсами и разрешениями AWS
Мы используем систему аутентификации и другие инструменты для управления разрешениями и контролем доступа к ресурсам AWS, что делает распределение ресурсов более гибким и безопасным:
Поддержка нескольких учетных записей AWS: в системе аутентификации вы можете управлять несколькими учетными записями AWS и привязывать различные ресурсы AWS, такие как S3 Bucket, ECR, ASM и т. д.
Приложение для сопоставления ресурсов и разрешений: пользователи могут сопоставлять существующие ресурсы AWS и подавать заявки на разрешения в системе, чтобы они могли легко выбирать ресурсы, к которым им необходим доступ при выполнении задания.
Управление учетной записью службы и привязка разрешений
Чтобы лучше управлять учетными записями служб и их разрешениями, мы реализовали следующие функции:
Привязка и управление сервисной учетной записью
Единственная разница между учетной записью службы: привяжите учетную запись службы к определенному кластеру, пространству имен и имени проекта, чтобы обеспечить ее уникальность.
Интерфейс привязки разрешений: пользователи могут привязать учетную запись службы к определенным ресурсам AWS, таким как S3, ASM или ECR, на интерфейсе, чтобы обеспечить точный контроль разрешений.
Упрощение операций и синхронизации ресурсов
Я только что сказал много, но фактическая операция относительно проста для пользователей. Весь процесс применения на самом деле является одноразовой задачей. Чтобы еще больше улучшить взаимодействие с пользователем Apache DolphinScheduler в среде AWS, мы предприняли ряд действий. меры по упрощению операционных процедур и расширению возможностей синхронизации ресурсов.
Позвольте мне подвести итог для вас:
Упрощенный пользовательский интерфейс
В DolphinScheduler пользователи могут легко настроить конкретный кластер и пространство имен, в котором выполняются их задания:
Выбор кластера и пространства имен
Выбор кластера: при отправке задания пользователи могут выбрать кластер, на котором они хотят, чтобы задание выполнялось.
конфигурация пространства имен: В зависимости от выбранного кластера пользователю также необходимо указать пространство имен, в котором выполняется задание.
Учетная запись службы и выбор ресурсов
Отображение учетной записи службы: на странице автоматически отобразится соответствующая учетная запись службы на основе выбранного проекта, кластера и пространства имен.
Настройка доступа к ресурсам: пользователи могут выбрать сегмент S3, адрес ECR и ключ ASM, связанные с учетной записью службы, через раскрывающийся список.
прогноз на будущее
Что касается текущего дизайна, есть еще некоторые области, которые можно оптимизировать и улучшить, чтобы улучшить представление данных пользователями и облегчить эксплуатацию и обслуживание:
Оптимизация отправки изображений: рассмотрите возможность пропуска процесса транзитной упаковки Cisco и отправки пакета непосредственно в ECR, особенно для модификаций образа, специфичных для EKS.
Функция синхронизации в один клик: Мы планируем разработать функцию синхронизации одним щелчком мыши, которая позволит пользователям загружать пакет ресурсов в корзину S3 и устанавливать флажок для автоматической синхронизации его с другими корзинами S3, чтобы уменьшить работу по повторным загрузкам.
Автоматически сопоставляться с системой аутентификации: после того, как ресурсы Aws будут созданы с помощью Terraform, система автоматически сопоставит эти ресурсы с системой управления разрешениями, чтобы пользователи не вводили ресурсы вручную.
Оптимизация контроля разрешений: Благодаря автоматизированному управлению ресурсами и разрешениями операции пользователей становятся проще, что снижает сложность настройки и управления.
Мы надеемся, что благодаря этим улучшениям пользователи смогут более эффективно развертывать свои задания и управлять ими с помощью Apache DolphinScheduler, будь то на Webex DC или EKS, одновременно повышая эффективность и безопасность управления ресурсами.
