Манифесты

Манифесты#

На этом шаге необходимо подготовить манифесты для установки всех требуемых объектов и развертывания платформы в кластере Kubernetes.

../../../_images/day0-model-green.svg ../../../_images/day0-ws-green.svg ../../../_images/day0-topology-green.svg ../../../_images/day0-tls-green.svg ../../../_images/day0-offline-green.svg ../../../_images/day0-conf-blue.svg

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

Терминология#

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

  • Ресурс (resource) – это точка доступа (endpoint) в API, например, Pod или Deployment. Его название может быть представлено в API в единственном (для управления одним объектом) и множественном (для управления списком) числе. С помощью ресурса можно создавать множество объектов (objects), где каждый объект является описанием состояния некой сущности, которой может быть компонент, например Pod, или какой-либо контроллер Kubernetes, например Service. Название ресурса используют при управлении объектами через параметр kind манифестов, в командах kubectl и прямых запросах к API.

  • Собственный (специальный) ресурс (CR, Custom Resource) – расширение API путем создания еще одной точки доступа. Например, после создания CR, названного AstraAutomation, в Kubernetes API появляется точка доступа с этим названием.

  • Определение собственного ресурса (CRD, Custom Resource Definition) – это особый ресурс, то есть точка доступа в Kubernetes API, названная CustomResourceDefinition, которую используют для создания CR. Для создания CR применяют манифест, в котором описывают API требуемого ресурса в стандарте OpenAPI, задавая на верхнем уровне манифеста kind: CustomResourceDefinition.

Ресурсы платформы#

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

  • собственные ресурсы приложения (CR), описанные в манифестах операторов с помощью нескольких CRD;

  • ресурсы типа Secret, используемые компонентами Astra Automation для обеспечения взаимодействия с внешними компонентами:

    • TLS secret – приватный ключ и сертификат для HTTPS, используемый контроллером Ingress для защиты данных;

    • реквизиты для доступа к хранилищу S3;

    • реквизиты для доступа к базам данных во внешней СУБД PostgreSQL (топология уровня предприятия);

    • encryption secrets – ключи шифрования данных в СУБД (топология уровня предприятия);

    • image pull secret – реквизиты для доступа к репозиторию образов контейнеров;

    • EE image pull secret – реквизиты для доступа к репозиторию образов для среды исполнения;

    • пароль пользователя admin для доступа к Platform Gateway.

Подготовка секретов#

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

Секрет для TLS#

Для обеспечения доступа к Platform Gateway по протоколу HTTPS необходимо предоставить для контроллера Ingress секрет, содержащий приватный ключ и сертификат TLS. Подготовка этого ресурса включает следующие шаги:

  1. Подготовьте серверный сертификат для доменного имени Ingress и соответствующий приватный ключ.

  2. Создайте в каталоге /tmp/aa-kubernetes-bundle/examples/kubernetes/enterprise/secrets/ (если пакет распакован в каталог /tmp/aa-kubernetes-bundle/ согласно инструкции) манифест секрета в виде отдельного файла со следующим содержимым:

    ---
apiVersion: v1
kind: Secret
metadata:
  name: aa-tls-secret
  namespace: astra-automation
data:
  tls.crt: <base64-encoded-cert-chain>
  tls.key: <base64-encoded-key>
type: kubernetes.io/tls

    Здесь:

    • <base64-encoded-cert-chain> – сертификат, закодированный в формате Base64, например, с помощью команды base64 -w 0 tls.crt;

    • <base64-encoded-key> – приватный ключ, закодированный в формате Base64, например, с помощью команды base64 -w 0 tls.key.

Секрет для доступа к хранилищу S3#

Подготовка манифеста секрета Kubernetes с реквизитами доступа к хранилищу S3 состоит из следующих шагов:

  1. Убедитесь, что имеется S3 bucket в публичном облаке.

  2. Создайте манифест для секрета в виде отдельного файла со следующей структурой (для примера приведены реквизиты для Yandex Cloud):

    ---
apiVersion: v1
kind: Secret
metadata:
  name: pah-s3-credentials-secret
  namespace: astra-automation
stringData:
  s3-access-key-id: "YC********************" # <-- Access key ID
  s3-secret-access-key: "YC****************" # <-- Secret key
  s3-bucket-name: "aa**********************" # <-- Bucket name
  s3-region: ru-central1
  s3-endpoint: "https://storage.yandexcloud.net"

В файле манифеста подставьте собственные значения параметров:

  • s3-access-key-id – идентификатор ключа доступа;

  • s3-secret-access-key – ключ доступа;

  • s3-bucket-name – название, заданное для хранилища S3 bucket.

Секреты для доступа к базам данных#

При использовании внешней СУБД необходимо создать секреты Kubernetes для всех требуемых баз данных. Создайте манифест секретов с помощью следующих шагов:

  1. Убедитесь, что для всех компонентов Astra Automation созданы базы данных и сохранены реквизиты доступа к ним.

  2. Создайте манифест секретов в виде отдельного файла со следующим содержимым:

    ---
apiVersion: v1
kind: Secret
metadata:
  name: ac-external-pg-secret
  namespace: astra-automation
stringData:
  host: "pg-ha.example.com" # Stable writer endpoint of external PostgreSQL
  port: "5432" # TCP port of external PostgreSQL
  database: "awx" # DB name
  username: "awx" # DB user name with privileges on creation and migration
  password: "ctrlDBpaS$123456" # DB user password
  sslmode: "prefer" # SSL mode (disable, require, etc.)
  type: "unmanaged" # Using external DBMS
type: Opaque
---
apiVersion: v1
kind: Secret
metadata:
  name: pah-external-pg-secret
  namespace: astra-automation
stringData:
  host: "pg-ha.example.com"
  port: "5432"
  database: "automationhub"
  username: "automationhub"
  password: "hUbPa55I2345b"
  sslmode: "prefer"
  type: "unmanaged"
type: Opaque
---
apiVersion: v1
kind: Secret
metadata:
  name: eda-external-pg-secret
  namespace: astra-automation
stringData:
  host: "pg-ha.example.com"
  port: "5432"
  database: "automationedacontroller"
  username: "automationedacontroller"
  password: "edapassword"
  sslmode: "prefer"
  type: "unmanaged"
type: Opaque
---
apiVersion: v1
kind: Secret
metadata:
  name: aa-external-pg-secret
  namespace: astra-automation
stringData:
  host: "pg-ha.example.com"
  port: "5432"
  database: "automationgateway"
  username: "automationgateway"
  password: "gateDBpaS$12345"
  sslmode: "prefer"
  type: "unmanaged"
type: Opaque

    Предупреждение

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

Особого внимания требуют параметры sslmode и type: Opaque.

Параметр sslmode определяет режим использования TLS при подключении к внешней базе данных PostgreSQL. Этот параметр переносится в настройки клиента и задает политику работы с шифрованными соединениями:

  • disable – подключение происходит без использования TLS, данные передаются в открытом виде.

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

  • require – соединение с сервером возможно только в защищенном режиме. При отсутствии поддержки шифрования соединение не устанавливается.

  • verify-ca – дополнительная проверка сертификата TLS, нацеленная на то, чтобы клиент удостоверился, что цепочка сертификатов ведет к корневому сертификату CA.

  • verify-full – дополнительный режим для максимальной безопасности, аналогичный предыдущему, но с проверкой того, что доменное имя или IP-адрес сервера совпадает с тем, что записано в сертификате TLS.

Поле type: Opaque используется в описании Kubernetes secret для указания того, что данные секрета представлены как произвольные строки, закодированные в формате Base64.

Примечание

В поле host каждого секрета для подключения к внешней СУБД необходимо указывать стабильную точку подключения к основному (primary) узлу PostgreSQL, а не IP-адрес отдельного узла. Если все компоненты платформы используют один и тот же внешний кластер PostgreSQL, их секреты должны ссылаться на одну и ту же стабильную точку подключения. В таком случае при отказе основного узла PostgreSQL в его кластере происходит автоматическая замена этого узла (failover). При этом не требуется изменять в манифесте Kubernetes secrets поле host, так как указанный адрес ведет на новый главный узел.

Секреты для шифрования#

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

  1. Для каждой базы данных, включая базу для Private Automation Hub (PAH), сгенерируйте ключ шифрования (всего четыре ключа) с помощью следующей команды и сохраните все ключи:

    openssl rand -base64 32

  2. Создайте манифест для секретов в виде отдельного файла со следующим примерным содержимым:

    # Секреты с ключами шифрования компонентов Astra Automation.
# Ключи -- обычный текст в секции stringData: Kubernetes кодирует их самостоятельно.
---
apiVersion: v1
kind: Secret
metadata:
  name: ac-encryption-secret
  namespace: astra-automation
stringData:
  secret_key: I6ysP1VTPjPatlOCrqekaur/aIoAMmRkjXrXRm2R9yM= # Ключ, сгенерированный командой openssl rand -base64 32
type: Opaque
---
apiVersion: v1
kind: Secret
metadata:
  name: eda-encryption-secret
  namespace: astra-automation
stringData:
  secret_key: zPCDRo1qS+SgdPKXU6aTc+vsUVTaBmPkBvc+44NMHMg= # Ключ, сгенерированный командой openssl rand -base64 32
type: Opaque
---
apiVersion: v1
kind: Secret
metadata:
  name: aa-encryption-secret
  namespace: astra-automation
stringData:
  secret_key: pBOnxFzTFyYhswCJ4ejenomvuzZCBOxVFMJxmfFzO8M= # Ключ, сгенерированный командой openssl rand -base64 32
type: Opaque
---
apiVersion: v1
kind: Secret
metadata:
  name: pah-encryption-secret
  namespace: astra-automation
stringData:
  database_fields.symmetric.key: e2ZskB6yfBU27V472qN63z1YUkhHI3vaZ6NpEK6DBss= # Ключ, сгенерированный командой openssl rand -base64 32
type: Opaque

    Предупреждение

    Вставьте вывод команды в секцию stringData без изменений. Не помещайте ключи в секцию data: ее значения Kubernetes декодирует при передаче в поды, поэтому фактическим ключом станет набор двоичных данных вместо текстовой строки. Такой ключ приводит к отказу в запуске Event-Driven Automation в кластерах с containerd версии 2.0 и выше. Если секреты уже созданы таким образом, воспользуйтесь процедурой восстановления.

Секрет для доступа к Platform Gateway#

Для обеспечения доступа к Platform Gateway через веб-интерфейс или API с помощью учетной записи администратора необходимо подготовить пароль для нее путем создания соответствующего секрета Kubernetes. Создайте манифест секрета с помощью следующих шагов:

  1. Подготовьте пароль, например aa-demo-enterprise-password, и закодируйте его методом Base64:

    echo -n 'aa-demo-enterprise-password' | base64

  2. Создайте манифест секрета в виде отдельного файла со следующим примерным содержимым:

    ---
apiVersion: v1
kind: Secret
metadata:
  name: aa-demo-admin-password
  namespace: astra-automation
data:
  password: YWEtZGVtby1lbnRlcnByaXNlLXBhc3N3b3Jk # Base64 encoded
type: Opaque

Секрет для доступа к репозиторию образов#

Для загрузки образов компонентов платформы и операторов из приватного репозитория кластеру необходимы учетные данные. Создайте секрет типа docker-registry с реквизитами доступа к репозиторию:

kubectl -n astra-automation create secret docker-registry aa-operators-pull-secret \
   --docker-server=<registry> \
   --docker-username=<username> \
   --docker-password=<password>

Здесь:

  • <registry> – адрес репозитория образов контейнеров;

  • <username> и <password> – реквизиты доступа к репозиторию.

Примечание

Название секрета должно совпадать со значением поля image_pull_secrets в манифесте AstraAutomation.

Секрет для доступа к образам среды исполнения#

Для загрузки образов среды исполнения (EE) Automation Controller использует отдельный секрет, название которого указывается в поле ee_pull_credentials_secret секции controller манифеста AstraAutomation. Создайте секрет типа Opaque с реквизитами доступа к репозиторию:

kubectl -n astra-automation create secret generic ac-ee-pull-secret \
   --from-literal=url=<registry> \
   --from-literal=username=<username> \
   --from-literal=password=<password> \
   --from-literal=ssl_verify=True

Здесь:

  • <registry> – адрес репозитория образов для среды исполнения;

  • <username> и <password> – реквизиты доступа к репозиторию;

  • ssl_verify – проверка сертификата TLS при подключении к репозиторию.

Важно

Этот секрет должен иметь тип Opaque (создается командой kubectl create secret generic). Если создать его как docker-registry, Automation Controller не завершит согласование ресурсов (reconcile).

Манифесты приложения#

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

Общими для манифестов являются следующие ключевые моменты:

  • Создание объекта aa-demo с помощью специального ресурса (CR) AstraAutomation, создаваемого с помощью операторов Kubernetes.

  • Использование пространства имен, созданного оператором, – metadata.namespace: astra-automation.

  • Перевод компонентов Astra Automation в активное состояние:

    • spec.controller.disabled: false;

    • spec.hub.disabled: false;

    • spec.eda.disabled: false.

  • Импорт контента (EE и DE) в Private Automation Hub при развертывании без доступа к интернету.

Базовая топология#

Пример манифеста для базовой топологии:

---
apiVersion: aa.astra-automation.ru/v1alpha1
kind: AstraAutomation
metadata:
  name: aa-demo
  namespace: astra-automation
spec:
  controller:
    disabled: false
    name: ac-demo
    ee_pull_credentials_secret: "ac-ee-pull-secret"
    image_pull_secrets: ["aa-operators-pull-secret"]
  hub:
    disabled: false
    name: pah-demo
    storage_type: S3
    object_storage_s3_secret: pah-s3-credentials-secret
    image_pull_secrets: ["aa-operators-pull-secret"]
  eda:
    disabled: false
    name: eda-demo
    image_pull_secrets: ["aa-operators-pull-secret"]
  # dashboard:
  #   disabled: false
  #   name: dashboard-demo
  #   ingress_type: ingress
  #   ingress_class_name: nginx
  image_pull_secrets: ["aa-operators-pull-secret"]
  ingress_type: Ingress
  ingress_class_name: nginx
#  ingress_tls_secret: aa-tls-secret
#  public_base_url: https://aa-demo.example.com
#  hostname: aa-demo.example.com

---
apiVersion: aa.astra-automation.ru/v1alpha1
kind: AstraAutomation
metadata:
  name: aa-demo
  namespace: astra-automation
spec:
  controller:
    disabled: false
    name: ac-demo
    ee_pull_credentials_secret: "ac-ee-pull-secret"
    default_ee_image: "aa-demo.example.com/aa-2.1/aa-full-ee:latest"
    control_plane_execution_environment: "aa-demo.example.com/aa-2.1/aa-control-ee:latest"
    control_plane_ee_image: registry.astra.ru/aa/aa-control-ee:2.1
  hub:
    disabled: false
    name: pah-demo
    storage_type: S3
    object_storage_s3_secret: pah-s3-credentials-secret
    offline_content_loader:
      enabled: true
      image_name: registry.astra.ru/aa/k8s-hub-content-importer:2.1
      namespace: aa-2.1
  eda:
    disabled: false
    name: eda-demo
    default_de_image: "aa-demo.example.com/aa-2.1/aa-full-de:latest"
  # dashboard:
  #   disabled: false
  #   name: dashboard-demo
  #   ingress_type: ingress
  #   ingress_class_name: nginx
  ingress_type: Ingress
  ingress_class_name: nginx
#  ingress_tls_secret: aa-tls-secret
#  public_base_url: https://aa-demo.example.com
#  hostname: aa-demo.example.com

Перед использованием примера манифеста необходимо раскомментировать и заполнить следующие параметры публикации сервиса через Ingress:

ingress_tls_secret:
public_base_url:
hostname:

Требования к параметрам:

  • ingress_tls_secret – название секрета Kubernetes, содержащего сертификат TLS и приватный ключ для HTTPS. Секрет должен быть предварительно создан согласно документации выше.

  • hostname – FQDN, используемое для публикации Platform Gateway. Например: aa-demo.example.com.

  • public_base_url – URL, по которому пользователи и внешние системы будут обращаться к Platform Gateway через веб-интерфейс или API. В качестве названия узла необходимо использовать тот же FQDN, который указан в параметре hostname. Например: https://aa-demo.example.com.

Вариант манифеста для развертывания без доступа в интернет дополнительно содержит следующие параметры:

  • default_ee_image – образ для записи среды исполнения «Default execution environment» в Automation Controller;

  • control_plane_execution_environment – образ для записи среды исполнения «Control Plane Execution Environment» в Automation Controller;

  • control_plane_ee_image – образ служебных контейнеров плоскости управления: контейнера awx-ee пода контроллера, init-контейнеров и переходных узлов Mesh Ingress;

  • default_de_image – образ для записи среды принятия решений «Default Decision Environment» в компоненте Event-Driven Automation;

  • offline_content_loader – настройки импорта образов сред исполнения и принятия решений в Private Automation Hub:

    • image_name – образ импортера контента;

    • namespace – пространство имен в Private Automation Hub (aa-2.1), в которое импортер помещает образы.

Реестром в ссылках на образы записей служит доменное имя шлюза платформы – значение параметра hostname: контроллер и Event-Driven Automation загружают эти образы из Private Automation Hub через шлюз. Если параметры default_ee_image, control_plane_execution_environment и default_de_image не заданы, операторы регистрируют записи с образами из публичного реестра hub.astra-automation.ru, недоступного в изолированном сегменте. Параметр control_plane_ee_image, напротив, указывает на образ из комплекта поставки, а не из Private Automation Hub: под контроллера запускается раньше, чем импортер контента наполняет Private Automation Hub. На запись «Control Plane Execution Environment» этот параметр не влияет. Состав создаваемых записей приведен в описании проверки сред исполнения и принятия решений.

Примечание

Явно заданный в манифесте список ee_images заменяет запись «Default execution environment», а список decision_environments – запись «Default Decision Environment». Для сохранения этих записей включите их в соответствующий список вместе с собственными средами, например:

ee_images:
  - name: "Default execution environment"
    image: "aa-demo.example.com/aa-2.1/aa-full-ee:latest"
  - name: "custom-ee"
    image: "aa-demo.example.com/custom/custom-ee:latest"

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

Если в процессе развертывания Astra Automation необходимо также установить Automation Dashboard, добавьте блок dashboard в spec манифеста приложения на одном уровне с блоками controller, hub и eda:

dashboard:
  disabled: false
  name: dashboard-demo
  ingress_type: ingress
  ingress_class_name: nginx

Здесь dashboard-demo – название создаваемого ресурса Dashboard. Значение ingress_class_name должно соответствовать классу Ingress, который используется в кластере. После развертывания пользователи смогут открыть интерфейс Automation Dashboard через Platform Gateway по пути /dashboard.

Если требуется добавить Automation Dashboard после развертывания платформы, используйте инструкцию.

Если в качестве хранилища используется файловое (а не S3), то необходимо выполнить следующие действия в манифесте приложения:

  1. Измените значение параметра storage_type:

    hub:
  storage_type: File

  2. Добавьте параметр file_storage_size:

    hub:
  file_storage_size: "100Gi"

    Параметр определяет размер Persistent Volume Claim (PVC), выделяемого для хранения данных Private Automation Hub. Для производственной среды рекомендуется использовать значение не менее 100Gi.

  3. Явно укажите StorageClass, добавив параметр file_storage_storage_class:

    hub:
  file_storage_storage_class: longhorn

  4. Удалите параметр object_storage_s3_secret:

    hub:
  object_storage_s3_secret: ...

Топология уровня предприятия#

Рассмотрим на примерах манифесты приложения и внутренних переходных узлов.

Манифест приложения#

Пример манифеста приложения для топологии уровня предприятия:

---
apiVersion: aa.astra-automation.ru/v1alpha1
kind: AstraAutomation
metadata:
  name: aa-demo
  namespace: astra-automation
spec:
  controller:
    disabled: false
    name: ac-demo
    database_secret: ac-external-pg-secret
    secret_key_secret: ac-encryption-secret
    ee_pull_credentials_secret: "ac-ee-pull-secret"
    image_pull_secrets: ["aa-operators-pull-secret"]
    replicas: 3
  hub:
    disabled: false
    name: pah-demo
    storage_type: S3
    object_storage_s3_secret: pah-s3-credentials-secret
    database_secret: pah-external-pg-secret
    db_fields_encryption_secret: pah-encryption-secret
    image_pull_secrets: ["aa-operators-pull-secret"]
    api:
      replicas: 3
    web:
      replicas: 3
    content:
      replicas: 3
    worker:
      replicas: 3
    resource_manager:
      replicas: 3
  eda:
    disabled: false
    name: eda-demo
    database_secret: eda-external-pg-secret
    db_fields_encryption_secret: eda-encryption-secret
    image_pull_secrets: ["aa-operators-pull-secret"]
    api:
      replicas: 3
    event_stream:
      replicas: 3
    ui:
      replicas: 3
    default_worker:
      replicas: 3
    activation_worker:
      replicas: 3
    worker:
      replicas: 3
    scheduler:
      replicas: 3
  # dashboard:
  #   disabled: false
  #   name: dashboard-demo
  #   ingress_type: ingress
  #   ingress_class_name: nginx
  #   dashboard:
  #     replicas: 3
  database:
    database_secret: aa-external-pg-secret
  api:
    replicas: 3
  redis_mode: cluster
  image_pull_secrets: ["aa-operators-pull-secret"]
  ingress_type: Ingress
  ingress_class_name: nginx
  ingress_tls_secret: aa-tls-secret
  db_fields_encryption_secret: aa-encryption-secret
  public_base_url: https://aa.demo.example.com
  hostname: aa.demo.example.com
  admin_password_secret: aa-demo-admin-password

---
apiVersion: aa.astra-automation.ru/v1alpha1
kind: AstraAutomation
metadata:
  name: aa-demo
  namespace: astra-automation
spec:
  controller:
    disabled: false
    name: ac-demo
    database_secret: ac-external-pg-secret
    secret_key_secret: ac-encryption-secret
    ee_pull_credentials_secret: "ac-ee-pull-secret"
    replicas: 3
    default_ee_image: "aa.demo.example.com/aa-2.1/aa-full-ee:latest"
    control_plane_execution_environment: "aa.demo.example.com/aa-2.1/aa-control-ee:latest"
    control_plane_ee_image: registry.astra.ru/aa/aa-control-ee:2.1
  hub:
    disabled: false
    name: pah-demo
    storage_type: S3
    object_storage_s3_secret: pah-s3-credentials-secret
    database_secret: pah-external-pg-secret
    db_fields_encryption_secret: pah-encryption-secret
    offline_content_loader:
      enabled: true
      image_name: registry.astra.ru/aa/k8s-hub-content-importer:2.1
      namespace: aa-2.1
    api:
      replicas: 3
    web:
      replicas: 3
    content:
      replicas: 3
    worker:
      replicas: 3
    resource_manager:
      replicas: 3
  eda:
    disabled: false
    name: eda-demo
    database_secret: eda-external-pg-secret
    db_fields_encryption_secret: eda-encryption-secret
    default_de_image: "aa.demo.example.com/aa-2.1/aa-full-de:latest"
    api:
      replicas: 3
    event_stream:
      replicas: 3
    ui:
      replicas: 3
    default_worker:
      replicas: 3
    activation_worker:
      replicas: 3
    worker:
      replicas: 3
    scheduler:
      replicas: 3
  # dashboard:
  #   disabled: false
  #   name: dashboard-demo
  #   ingress_type: ingress
  #   ingress_class_name: nginx
  #   dashboard:
  #     replicas: 3
  database:
    database_secret: aa-external-pg-secret
  api:
    replicas: 3
  redis_mode: cluster
  ingress_type: Ingress
  ingress_class_name: nginx
  ingress_tls_secret: aa-tls-secret
  db_fields_encryption_secret: aa-encryption-secret
  public_base_url: https://aa.demo.example.com
  hostname: aa.demo.example.com
  admin_password_secret: aa-demo-admin-password

По сравнению с базовым вариантом включает следующие настройки:

  • репликация подов;

  • секреты для установления соединений с базами данных на внешней СУБД;

  • настройка балансировщика Ingress;

  • наличие доменного имени для балансировщика Ingress.

Если в процессе развертывания Astra Automation необходимо также установить Automation Dashboard, добавьте блок dashboard в spec манифеста приложения. Чтобы компонент соответствовал отказоустойчивой топологии, задайте несколько реплик Automation Dashboard:

dashboard:
  disabled: false
  name: dashboard-demo
  ingress_type: ingress
  ingress_class_name: nginx
  dashboard:
    replicas: 3

Здесь dashboard-demo – название создаваемого ресурса Dashboard. Значение ingress_class_name должно соответствовать классу Ingress, который используется в кластере. Вложенный блок dashboard задает параметры развертывания самого компонента: оператор передает его в ресурс Dashboard, где параметр replicas определяет количество реплик. Если требуется добавить Automation Dashboard после развертывания платформы, используйте инструкцию.

Примечание

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

Если в качестве хранилища используется файловое (а не S3), то необходимо выполнить те же действия, что и для настройки такого хранилища в базовой топологии.

Манифесты переходных узлов#

Для повышения масштабируемости рекомендуется установить переходные узлы (hop nodes) в Kubernetes, которые принимают запросы от вновь добавляемых исполняющих узлов (execution nodes) на установление соединения с Automation Controller согласно топологии. Для каждого запланированного переходного узла подготовьте отдельный манифест. Эти манифесты отличаются только параметрами metadata.name и spec.external_hostname, например:

---
apiVersion: ac.astra-automation.ru/v1alpha1
kind: AutomationControllerMeshIngress
metadata:
  name: ac-demo-mesh
  namespace: astra-automation
spec:
  deployment_name: ac-demo
  external_hostname: aa.demo.mesh.example.ru
  ingress_class_name: nginx
  ingress_controller: nginx
  ingress_type: Ingress

Здесь external_hostname – доменное имя для создаваемой точки доступа, к которой будут подключаться внешние исполняющие узлы.

Примечание

Каждый объект на основе ресурса AutomationControllerMeshIngress должен быть создан в одном единственном экземпляре. Эти объекты нельзя реплицировать в Kubernetes.