#google-cloud-platform #argoproj
#google-облачная платформа #argoproj
Вопрос:
Я рассматривал Argo как систему CD в стиле Gitops. Это выглядит действительно аккуратно. Тем не менее, я не понимаю, как использовать Argo в нескольких проектах GCP. В частности, планируется создание проектов, зависящих от среды (т. Е. prod, stage dev). Похоже, что Argo не предназначен для организации развертывания в кластерах, зависящих от среды, или это так?
Комментарии:
1. Каков идентификатор вашего конвейера Argo? Есть ли у вас учетная запись сервиса?
2. @guillaumeblaquiere Не уверен, что вы имеете в виду под этим. Я новичок в Argo, рассматриваю его как потенциальный вариант CD.
3. Где вы будете запускать свое приложение Argo? на GKE?
4. @guillaumeblaquiere да, на GKE. Я хотел бы объединить из dev -> stg -> master в Github и запустить развертывание версий Argo в соответствующих средах. Возможно, решение состоит в том, чтобы просто развернуть сервер Argo в каждом проекте GCP и сделать так, чтобы все они указывали на отдельные ветви? Может быть, это самый простой подход? Как я могу заставить Argo развертывать приложения в различных средах вместе с конфигурацией, зависящей от среды?
Ответ №1:
Ваш вопрос в основном касается управления безопасностью. У вас есть несколько возможностей и несколько точек зрения / уровней безопасности.
1. Разделение проектов
Самый простой и безопасный способ — запустить Argo в каждом проекте без связи / моста между каждой средой. Отсутствие риска для безопасности или развертывания в неправильном проекте. Достаточно разделения проекта по умолчанию (роли VPC и IAM).
Но это подразумевает развертывание и поддержку одного и того же приложения в нескольких кластерах и оплату нескольких кластеров (Dev, Staging и prod CD не используются с одинаковой частотой)
В целях безопасности вы можете использовать учетную запись службы Compute Engine по умолчанию для авторизации или вы можете полагаться на идентификатор рабочей нагрузки (предпочтительный способ)
2. Разделение пространства имен
Другой способ — иметь только один проект с развернутым на нем кластером и пространством имен kubernetes для каждого проекта доставки. Кстати, вы можете повторно использовать один и тот же кластер для всех проектов в вашей компании.
Вам все равно придется обновлять и поддерживать Argo в каждом пространстве имен, но администрирование кластера упрощается, поскольку узлы одни и те же.
С точки зрения безопасности вы можете использовать идентификатор рабочей нагрузки для каждого пространства имен (и, таким образом, иметь 1 учетную запись службы для каждого пространства имен, авторизованную в проекте доставки) и сохранять отдельные разрешения
Здесь компромиссом является частный IP-доступ. Если вашему развертыванию необходим доступ к частному IP-адресу внутри проекта доставки (для целей тестирования или для доступа к частному K8S master), вам необходимо настроить пиринг VPC (а количество пирингов ограничено 25 на проект) или настроить общий VPC.
3. Разделение учетных записей служб
Не рекомендуется использовать последнее решение, но оно самое простое в обслуживании. У вас есть только один кластер GKE для всей среды и только 1 пространство имен с развернутым в нем Argo. При настройке вы можете указать Argo использовать определенную учетную запись службы для доступа к проекту доставки (с файлами ключей учетной записи службы (не рекомендуемое решение), хранящимися в GKE secrets или в secret manager, или (лучше) с использованием олицетворения учетной записи службы).
Здесь также у вас есть 1 учетная запись службы, авторизованная для каждого проекта доставки. И проблема с пирингом такая же, если в проекте доставки требуется частный IP-доступ.