Манифесты

Манифесты#

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

../../../_images/day0-model-green.svg ../../../_images/day0-ws-green.svg ../../../_images/day0-topology-green.svg ../../../_images/day0-offline-green.svg ../../../_images/day0-conf-blue.svg ../../../_images/day0-model-green.svg ../../../_images/day0-ws-green.svg ../../../_images/day0-topology-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. Закажите ключ и сертификат от удостоверяющего центра или создайте само-подписанный сертификат и ключ к нему.

  2. Закодируйте каждый из них в формате Base64.

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

    ---
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-encoded-key> – приватный ключ, закодированный в формате Base64.

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

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

  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: "X.X.X.X" # <-- IP address or domain name 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: "awx" # <-- 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: "X.X.X.X"
  port: "5432"
  database: "automationhub"
  username: "automationhub"
  password: "automationhub"
  sslmode: "prefer"
  type: "unmanaged"
type: Opaque
---
apiVersion: v1
kind: Secret
metadata:
  name: eda-external-pg-secret
  namespace: astra-automation
stringData:
  host: "X.X.X.X"
  port: "5432"
  database: "automationedacontroller"
  username: "automationedacontroller"
  password: "automationedacontroller"
  sslmode: "prefer"
  type: "unmanaged"
type: Opaque
---
apiVersion: v1
kind: Secret
metadata:
  name: aa-external-pg-secret
  namespace: astra-automation
stringData:
  host: "X.X.X.X"
  port: "5432"
  database: "automationgateway"
  username: "automationgateway"
  password: "automationgateway"
  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.

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

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

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

    openssl rand -base64 32

    Для базы данных PAH требуется более длинный ключ, генерируемы следующей командой:

    openssl rand -base64 32 | base64

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

    ---
apiVersion: v1
kind: Secret
metadata:
  name: ac-encryption-secret
  namespace: astra-automation
data:
  secret_key: I4AD8TR/zsoBEBXNPcQ4jxCixveTepfHg1KvItBVKf4= # Base64 encoded
type: Opaque
---
apiVersion: v1
kind: Secret
metadata:
  name: eda-encryption-secret
  namespace: astra-automation
data:
  secret_key: f4lj4+FpOWMRY6l2e5p5eE/lz8JdR3gTNqtWkcXvDq8= # Base64 encoded
type: Opaque
---
apiVersion: v1
kind: Secret
metadata:
  name: aa-encryption-secret
  namespace: astra-automation
data:
  secret_key: 61a260kWBPmPX89TMPZGbLTsaLmnWBnTShX0S3NyFns= # Base64 encoded
type: Opaque
---
apiVersion: v1
kind: Secret
metadata:
  name: pah-encryption-secret
  namespace: astra-automation
data:
  database_fields.symmetric.key: clpsTGdYVG1PUmcxNmxNQmEwdENaQVVoVGtEblltekJaNUdxWS9ISVNjdz0K # Base64 encoded
type: Opaque

Секрет для доступа к 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

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

При создании собственных манифестов для развертывания 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

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

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

---
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"]
  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
    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
  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

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

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

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

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

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

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

---
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 – доменное имя для создаваемой точки доступа, к которой будут подключаться внешние исполняющие узлы.