Руководство по системному администрированию#

Сценарии администрирования#

Публикация health-метрик Batch Tasks для Prometheus#

Работоспособность сервиса Пакетная обработка задач (Batch Tasks) может быть определена с помощью health-метрик на графиках системы мониторинга.

Для этого сервис Batch Tasks выполняет публикацию дополнительной readiness-метрики batch_availability_readiness в формате Prometheus, которая отображает общую готовность сервиса обрабатывать запросы. Метрика Prometheus в actuator/prometheus синхронизирована с health-метрикой /actuator/health/readiness и отражает следующие состояния:

• "UP" = 1.0 — если все смежные сервисы работают корректно;

• "DOWN" = 0.0 — в других случаях.

Конфигурирование интеграции с сервисом OTT#

Сервис One-Time Password (OTP) / OTT (далее — OTT) как инструмент контроля доступа решает следующие задачи:

• разграничение доступа для сервисов Платформы с помощью токенов;

• авторизация;

• аутентификация.

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

Конфигурирование интеграции с OTT#

Сервис Batch Tasks может быть развернут как с возможностью интеграции с сервисом OTT, так и без нее:

• описание действий по подготовке дистрибутива Batch Tasks и настройке интеграции с сервисом OTT приведено в Руководстве по установке в разделе «Настройка интеграции с OTT»;

• описание действий по подготовке namespace в Kubernetes или OpenShift (далее — среда контейнеризации) для настройки OTT приведено в Руководстве по установке в разделе «Настройка OTT».

Отключение интеграции с OTT#

Для отключения интеграции OTT для сервиса Batch Tasks удалите настройки OTT из развернутых в среде контейнеризации схем развертывания egressgateway-batch-tasks и ingressgateway-batch-tasks в последовательности, указанной ниже:

1. Удалите следующие строки:

   - name: ott-uds-socket
     emptyDir:
        medium: Memory
   - name: ott-ingress-logback
     configMap:
        name: batch-tasks-ott-ingress-logback
        defaultMode: 420
   - name: ott-certs
     secret:
        secretName: batch-tasks-ott-certs
        defaultMode: 420

   - name: ott-uds-socket
     mountPath: /mnt/ott-uds-socket

   volumeMounts:
      - name: ott-certs
        readOnly: true
        mountPath: /mnt/secrets
      - name: ott-uds-socket
        mountPath: /mnt/ott-uds-socket
      - name: ott-ingress-logback
        readOnly: true
        mountPath: /app/config

2. Нажмите кнопку Save.

3. Удалите оставшуюся часть настроек OTT и нажмите кнопку Save.

   - name: ott-sidecar
     image: '{{OTT_CLIENT_SIDECAR_IMAGE_REGISTRY_PATH}}/${batch.tasks.docker.image.ott-client-sidecar}'
     envFrom:
        - secretRef:
             name: batch-tasks-ott-passwords
        - configMapRef:
             name: batch-tasks-ott-ingress-settings
     resources:
        limits:
           cpu: {{OTT_SIDECAR_CPU_LIMIT}}
           memory: {{OTT_SIDECAR_MEMORY_LIMIT}}
        requests:
           cpu: {{OTT_SIDECAR_CPU_REQUEST}}
           memory: {{OTT_SIDECAR_MEMORY_REQUEST}}
     env:
        - name: JAVA_TOOL_OPTIONS
          value: '-Dlogback.configurationFile=/app/config/logback.xml'
        terminationMessagePath: /dev/termination-log
     terminationMessagePolicy: File
     imagePullPolicy: IfNotPresent

4. В консоли среды контейнеризации перейдите в раздел Home → Search.

5. В выпадающем списке Resources выберите EnvoyFilter.

6. Найдите конфигурационный файл batch-tasks-egress-ott-auth-filter и удалите его.

Контроль доступа к сервису#

В сервисе Batch Tasks авторизация и работа пользователей реализована с разграничением доступа на основе атрибутов справочника ABAC (Attribute — Based Access Control).

Функциональность ABAC реализована в компоненте Объединенный сервис авторизации продукта Platform V IAM (далее — SPAS, CliPAS) и требует включения настройки (abacEnabled=true) в конфигураторе для этого экземпляра SPAS.

Структура атрибутов#

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

Модель позволяет разграничивать пользовательские права на 3 категории:

• просмотр (Get);

• редактирование (Edit);

• удаление (Delete).

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

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

Пример атрибутного разграничения прав#

В приведенной таблице столбцы представляют собой справочники атрибутов, строки — различные тенанты, которые хранятся во всех справочниках.

Например, наличие у пользователя атрибута с именем tenant-2 из справочника Edit разрешает пользователю редактирование данных tenant-2. Отсутствие атрибута tenant-4 из справочника Get запрещает пользователю доступ на чтение к tenant-4.

Подробное описание разграничения доступа приведено в документации на SPAS.

Конфигурирование поставки политики авторизации#

Политика авторизации должна быть размещена на узлах SPAS в определенной папке, которая задается с помощью настройки SPAS policyBasePath. В дистрибутиве политика хранится в папке /other/abac.

Копирование политики из дистрибутива на узлы SPAS осуществляется с помощью отдельного шага Install_EIP, который конфигурируется на этапе подготовки дистрибутива в файлах конфигурации Install_EIP: actions.xml и system.conf (см. Руководство по установке).

Управление контролем доступа к сервису#

Назначение, удаление и просмотр атрибутов пользователя#

Просмотр и/или изменение пользовательских прав (добавление/удаление атрибутов) выполняются администратором сервиса следующим образом:

1. Перейдите в UI SPAS.

2. Просмотрите атрибуты пользователя:

   1. Перейдите на страницу Пользователи.

   2. Выберите пользователя.

   3. Нажмите кнопку Атрибуты пользователя.

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

3. Чтобы добавить атрибут:

   1. Перейдите на страницу Пользователи.

   2. Выберите пользователя.

   3. Нажмите кнопку Атрибуты пользователя.

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

   5. Нажмите кнопку >>.

   6. В открывшемся окне нажмите кнопку Да, чтобы подтвердить назначение атрибута пользователю.

   В результате успешного добавления атрибута пользователю отобразится информационное окно. Нажмите кнопку ОК.

4. Чтобы удалить атрибут:

   1. Перейдите на страницу Пользователи.

   2. Выберите пользователя.

   3. Нажмите кнопку Атрибуты пользователя.

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

   5. Нажмите кнопку <<.

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

   В результате успешного удаления атрибута пользователя отобразится информационное окно. Нажмите кнопку ОК.

Примечание

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

Подключение сервиса к ABAC и загрузка справочника атрибутов#

При установке сервиса Batch Task подключение модуля к ABAC и загрузка справочника атрибутов выполняются администратором следующим образом:

1. Перейдите в UI SPAS.

2. Создайте модуль:

   1. Перейдите на страницу Модули → Подключить модуль.

   2. Введите название модуля.

3. Назначьте администратору (например, текущему пользователю, под которым сейчас выполнен вход) роль "Администратор модуля ${moduleId}":

   1. Перейдите на страницу Пользователи.

   2. Выберите пользователя.

   3. Нажмите кнопку Роли.

   4. Нажмите кнопку Добавить.

   5. Выберите роль из списка.

   6. Нажмите кнопку >>.

   7. Нажмите кнопку Добавить.

   8. Нажмите кнопку Сохранить, чтобы сохранить внесенные изменения.

4. Подключите созданный модуль к ABAC:

   1. Перейдите на страницу Модули.

   2. Выберите модуль.

   3. Нажмите кнопку Подключить модуль к ABAC.

5. Загрузите справочник атрибутов:

   1. Перейдите на страницу Справочники ABAC.

   2. Выберите модуль.

   3. Нажмите кнопку Загрузить из файла.

   4. Выберите файл.

   5. Нажмите кнопку Загрузить, чтобы загрузить выбранный справочник атрибутов.

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

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

Пример шаблона справочника для добавления нового тенанта#

В шаблоне справочника атрибутов для task-server требуется заменить плейсхолдер ${tenantId} на имя нового tenant и загрузить полученный файл в SPAS:

{
    "attrName": "sbrf:pprb:namespace:d:i", // Корневой атрибут. Описывает элемент предопределенного справочника модулей
    "values": [
        "task-server"                      // Единственное значение корневого атрибута — имя модуля, для которого загружается справочник атрибутов
    ],
    "child": [
        {
            "attrName": "sbrf:pprb:batch:tasksServer:get:d", // Справочник тенанта для операции get. К справочникам добавляется суффикс ":d"
            "values": [
                "items"                                      // Единственное значение справочника — константа "items"
            ],
            "child": [
                {
                    "attrName": "sbrf:pprb:batch:tasksServer:get:d:i", // Элемент справочника тенанта. К элементам справочника добавляется суффикс ":d:i"
                    "values": [
                        "${tenantId}"                                  // Элементы справочника
                    ]
                }
            ]
        },
        {
            "attrName": "sbrf:pprb:batch:tasksServer:edit:d",           // Список тенантов можно уместить в одном атрибуте, а можно разбить на несколько
            "values": [
                "items"
            ],
            "child": [
                {
                    "attrName": "sbrf:pprb:batch:tasksServer:edit:d:i",
                    "values": [
                        "${tenantId}"
                    ]
                }
            ]
        },
        {
            "attrName": "sbrf:pprb:batch:tasksServer:delete:d",
            "values": [
                "items"
            ],
            "child": [
                {
                    "attrName": "sbrf:pprb:batch:tasksServer:delete:d:i",
                    "values": [
                        "${tenantId}"
                    ]
                }
            ]
        }
    ]
}

Использование режима ReadOnly для Batch Tasks UI#

Обзор#

Режим ReadOnly при работе через Batch Tasks UI позволяет только просматривать Задачи, Очереди и их статус. Все операции по изменению, запуску и остановке Очереди/Задачи или списка Очередей/Задач через Batch Tasks UI недоступны.

Режим работы ReadOnly необходим при отсутствии интеграций с системами аутентификации и авторизации (SPAS, СУДИР).

Сервис Batch Tasks предоставляет режим инсталляции с доступом к UI в режиме ReadOnly с помощью конфигурации развертывания.

При входе в Batch Tasks UI после авторизации отображается предупреждение:

Настройка режима ReadOnly#

Для активации режима ReadOnly для Batch Tasks UI установите во всех манифестах дистрибутива параметы:

tasks/server/access/enabled = false
tasks/server/access/read-only = true

Добавление нового тенанта#

Под словом тенант понимаются хост и порт, которые могут вызываться Задачами. Если из Задач могут вызываться несколько разных пар хост+порт, то добавьте их все в соответствии с описанием ниже. Добавление нового тенанта в конфигурацию сервиса Batch Tasks может выполняться при следующих исходных данных:

• Ранее использовалась конфигурация с одним тенантом.

• В конфигурации сервиса уже два и более тенант.

В зависимости от исходных данных действия по добавлению нового тенанта будут отличаться.

Список параметров#

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

• ${tenant_name} — произвольное название тенанта. Допускаются буквы, цифры, дефис. Для разных тенантов значения должны отличаться. Пример: "http-target";

• ${tenant_host} — целевой хост, без протокола (HTTP/HTTPS) и порта;

• ${tenant_port} — целевой порт. Для HTTPS — 443, для HTTP — 80, если явно не требуется указать другой;

• ${tenant_inner_port} — внутренний PORT, на который httpTarget будет отправлять запросы. Пример значения: 22000;

• ${tenant_egress_port} — вспомогательный промежуточный порт. У разных тенантов должны отличаться. Рекомендуется использовать различные значения из одного диапазона, например, 21000–21999;

• ${egress_name} — наименование Egress деплоймента;

• ${tenant_inner_port} — внутренний порт, на который сервисы Batch будут делать вызовы. Рекомендуется использовать значение 80 для всех тенантов;

• ${tenant_protocol} — протокол. Если целевой API вызывается по HTTPS, используется значение "tls", если по HTTP — "http";

• ${tenant_tls_mode} — режим TLS. Если целевое API вызывается по HTTPS, используется значение "MUTUAL", если по HTTP — "DISABLE";

• ${distrib_release_version} — версия сервиса.

Примечания

• Если целевой API вызывается по HTTP, то для service-entry-egress-tenant.yml в качестве параметра ${tenant_inner_port} укажите уникальный, не использующийся в других настройках порт, например из диапазона 22000–22999. В virtual-service-egress-tenant.yml используйте значение 80.

• Если целевой API вызывается по HTTPS, то используйте значение 80 и в service-entry-egress-tenant.yml, и в virtual-service-egress-tenant.yml.

Ручное добавление нового тенанта#

Для добавления нового тенанта создайте новые конфигурационные файлы:

• destination-rule-egress-tenant.yml;

• envoy-filter-ott-egress-tenant.yml;

• gateway-egress-tenant.yml;

• service-egress-tenant.yml;

• service-entry-egress-tenant.yml;

• virtual-service-egress-tenant.yml.

Пример заполненного файла destination-rule-egress-tenant.yml:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: schd-dr-egress-${tenant_name}-${distrib.release.version}
spec:
  host: ${tenant_host}
  exportTo: [.]
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
    portLevelSettings:
      - port:
        number: ${tenant_port}
      tls:
        caCertificates: /etc/istio/egressgateway-ca-certs/ca-chain.cert.pem
        clientCertificate: /etc/istio/egressgateway-certs/tls.crt
        privateKey: /etc/istio/egressgateway-certs/tls.key
        mode: ${tenant_tls_mode}
        sni: ${tenant_host}

Пример заполненного файла envoy-filter-ott-egress-tenant.yml:

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: schd-ev-ott-egress-auth-filter-${tenant_name}-${distrib.release.version}
spec:
  configPatches:
  - applyTo: HTTP_FILTER
  match:
    context: GATEWAY
    listener:
      filterChain:
        filter:
          name: envoy.http_connection_manager
      portNumber: ${tenant_egress_port}
  patch:
    operation: INSERT_BEFORE
    value:
      name: envoy.ext_authz
      config:
        failure_mode_allow: false
        grpc_service:
          google_grpc:
            stat_prefix: ext_authz
            target_uri: 'unix:/mnt/ott-uds-socket/ott.socket'
        timeout: {{OTT_TIMEOUT}}
      with_request_body:
        allow_partial_message: true
        max_request_bytes: 8192
  workloadSelector:
    labels:
      app: ${egress_name}

Для плейсхолдера указать значение 2s (данное значение принято для корректной работы с OTT и при необходимости может быть изменено).

Пример заполненного файла gateway-egress-tenant.yml:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: schd-gw-egress-${tenant_name}-${distrib.release.version}
spec:
  selector:
    istio: ${egress_name}
  servers:
    - hosts:
        - '*'
      port:
        name: tcp-${tenant_egress_port}-${tenant_name}
        number: ${tenant_egress_port}
        protocol: HTTPS
      tls:
        mode: ISTIO_MUTUAL

Пример заполненного файла service-egress-tenant.yml:

kind: Service
apiVersion: v1
metadata:
  name: schd-svc-egress-${tenant_name}-${distrib.release.version}
  labels:
    app: ${egress_name}
    istio: ${egress_name}
spec:
  ports:
    - name: tcp-15021-status
      protocol: TCP
      port: 15021
      targetPort: 15021
    - name: tcp-${tenant_egress_port}
      protocol: TCP
      port: ${tenant_egress_port}
      targetPort: ${tenant_egress_port}
  selector:
    app: ${egress_name}
    istio: ${egress_name}
  sessionAffinity: None
  type: ClusterIP

Пример заполненного файла service-entry-egress-tenant.yml:

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: schd-se-egress-se-${tenant_name}-${distrib.release.version}
spec:
  exportTo:
    - .
  hosts:
    - ${tenant_host}
  location: MESH_EXTERNAL
  ports:
    - name: ${tenant_protocol}-${tenant_port}
      number: ${tenant_port}
      protocol: ${tenant_protocol}
    - name: http-${tenant_inner_port}-mesh
      number: ${tenant_inner_port}
      protocol: HTTP
  resolution: DNS

Пример заполненного файла virtual-service-egress-tenant.yml:

# пример использования для направления трафика на заранее известный хост ${tenant_host} через OTT сайдкар
# порт ${tenant_egress_port} на Egress

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: schd-vs-egress-${tenant_name}-${distrib.release.version}
spec:
  exportTo:
    - .
  gateways:
    - schd-gw-egress-${tenant_name}-${distrib.release.version}
    - mesh
  hosts:
    - ${tenant_host}
  http:
    - match:
        - gateways:
            - mesh
          port: ${tenant_inner_port}
      rewrite:
        authority: >-
          ${tenant_host}
      route:
        - destination:
            host: schd-svc-egress-${tenant_name}-${distrib.release.version}
            port:
              number: ${tenant_egress_port}
      timeout: ${tenant_timeout}
    - match:
        - gateways:
            - schd-gw-egress-${tenant_name}-${distrib.release.version}
          port: ${tenant_egress_port}
      rewrite:
        authority: >-
          ${tenant_host}
      route:
        - destination:
            host: ${tenant_host}
            port:
              number: ${tenant_port}
          weight: 100
      timeout: ${tenant_timeout}

Добавление нового тенанта, изменение конфигурации одного тенанта с использованием Install_EIP#

Для добавления нового тенанта в конфигурацию сервиса Batch Tasks, в случае когда ранее использовался только один тенант, выполните следующие действия:

1. Создайте блок uniqueParams в os_namespaces.yml (параметры одного тенанта могут храниться в os_props.conf, поэтому в os_namespaces.yml может не быть блока uniqueParams):

   projects:
   - name: "dev"
     openShiftNamespace: "ci00641491-edevgen2-serverless-batch-dev"
     openShiftURL: api.dev-gen2.ххххх.ru:6443
     oc_token: batchtasks_dev_token
     os_props: "os_props.conf"
     deleteResources: true
     validateDeploy: false
     rollback:
     - needToRollback: true
     uniqueParams:
       destination-rule-egress-tenant.yml:
         TENANT_NAME:
           -
         TENANT_HOST:
           -
         TENANT_PORT:
           -
         TENANT_TLS_MODE:
           -
       envoy-filter-ott-egress-tenant.yml:
         TENANT_NAME:
           -
         TENANT_EGRESS_PORT:
           -
       gateway-egress-tenant.yml:
         TENANT_NAME:
           -
         TENANT_HOST:
           -
         TENANT_EGRESS_PORT:
           -
       service-egress-tenant.yml:
         TENANT_NAME:
           -
         TENANT_EGRESS_PORT:
           -
       service-entry-egress-tenant.yml:
         TENANT_NAME:
           -
         TENANT_HOST:
           -
         TENANT_PORT:
           -
         TENANT_PROTOCOL:
           -
         TENANT_INNER_PORT:
           -
       virtual-service-egress-tenant.yml:
         TENANT_NAME:
           -
         TENANT_HOST:
           -
         TENANT_PORT:
           -
         TENANT_INNER_PORT:
           -
         TENANT_EGRESS_PORT:
           -

2. Добавьте соответствующие значения параметров из файла os_props.conf в качестве первого значения для каждого плейсхолдера os_namespaces.yml, чтобы получить следующий вид файла:

   projects:
   - name: "dev"
     openShiftNamespace: "ci00641491-edevgen2-serverless-batch-dev"
     openShiftURL: api.dev-gen2.xxxxx.ru:6443
     oc_token: batchtasks_dev_token
     os_props: "os_props.conf"
     deleteResources: true
     validateDeploy: false
     rollback:
     - needToRollback: true
     uniqueParams:
       destination-rule-egress-tenant.yml:
         TENANT_NAME:
           - httptarget-http
         TENANT_HOST:
           - tgt-ingress-ci00641491-edevgen-custodian-devops-sandbox.apps.dev-gen.xxxxx.ru
         TENANT_PORT:
           - 80
         TENANT_TLS_MODE:
           - DISABLE
       envoy-filter-ott-egress-tenant.yml:
         TENANT_NAME:
           - httptarget-http
         TENANT_EGRESS_PORT:
           - 21080
       gateway-egress-tenant.yml:
         TENANT_NAME:
           - httptarget-http
         TENANT_HOST:
           - tgt-ingress-ci00641491-edevgen-custodian-devops-sandbox.apps.dev-gen.xxxxx.ru
         TENANT_EGRESS_PORT:
           - 21080
       service-egress-tenant.yml:
         TENANT_NAME:
           - httptarget-http
         TENANT_EGRESS_PORT:
           - 21080
       service-entry-egress-tenant.yml:
         TENANT_NAME:
           - httptarget-http
         TENANT_HOST:
           - tgt-ingress-ci00641491-edevgen-custodian-devops-sandbox.apps.dev-gen.xxxxx.ru
         TENANT_PORT:
           - 80
         TENANT_PROTOCOL:
           - http
         TENANT_INNER_PORT:
           - 22080
       virtual-service-egress-tenant.yml:
         TENANT_NAME:
           - httptarget-http
         TENANT_HOST:
           - tgt-ingress-ci00641491-edevgen-custodian-devops-sandbox.apps.dev-gen.xxxxx.ru
         TENANT_PORT:
           - 80
         TENANT_INNER_PORT:
           - 22080
         TENANT_EGRESS_PORT:
           - 21080

3. Добавьте значения параметров нового тенанта после значений первого тенанта (os_namespaces.yml):

   projects:
   - name: "dev"
     openShiftNamespace: "ci00641491-edevgen2-serverless-batch-dev"
     openShiftURL: api.dev-gen2.xxxxx.ru:6443
     oc_token: batchtasks_dev_token
     os_props: "os_props.conf"
     deleteResources: true
     validateDeploy: false
     rollback:
     - needToRollback: true
     uniqueParams:
       destination-rule-egress-tenant.yml:
         TENANT_NAME:
           - httptarget-http
           - httptarget-https
         TENANT_HOST:
           - tgt-ingress-ci00641491-edevgen-custodian-devops-sandbox.apps.dev-gen.xxxxx.ru
           - tgt-ingress-tls-ci00641491-edevgen-custodian-devops-sandbox.apps.dev-gen.xxxxx.ru
         TENANT_PORT:
           - 80
           - 443
         TENANT_TLS_MODE:
           - DISABLE
           - MUTUAL
       envoy-filter-ott-egress-tenant.yml:
         TENANT_NAME:
           - httptarget-http
           - httptarget-https
         TENANT_EGRESS_PORT:
           - 21080
           - 21443
       gateway-egress-tenant.yml:
         TENANT_NAME:
           - httptarget-http
           - httptarget-https
         TENANT_HOST:
           - tgt-ingress-ci00641491-edevgen-custodian-devops-sandbox.apps.dev-gen.xxxxx.ru
           - tgt-ingress-tls-ci00641491-edevgen-custodian-devops-sandbox.apps.dev-gen.xxxxx.ru
         TENANT_EGRESS_PORT:
           - 21080
           - 21443
       service-egress-tenant.yml:
         TENANT_NAME:
           - httptarget-http
           - httptarget-https
         TENANT_EGRESS_PORT:
           - 21080
           - 21443
       service-entry-egress-tenant.yml:
         TENANT_NAME:
           - httptarget-http
           - httptarget-https
         TENANT_HOST:
           - tgt-ingress-ci00641491-edevgen-custodian-devops-sandbox.apps.dev-gen.xxxxx.ru
           - tgt-ingress-tls-ci00641491-edevgen-custodian-devops-sandbox.apps.dev-gen.xxxxx.ru
         TENANT_PORT:
           - 80
           - 443
         TENANT_PROTOCOL:
           - http
           - tls
         TENANT_INNER_PORT:
           - 22080
           - 22443
       virtual-service-egress-tenant.yml:
         TENANT_NAME:
           - httptarget-http
           - httptarget-https
         TENANT_HOST:
           - tgt-ingress-ci00641491-edevgen-custodian-devops-sandbox.apps.dev-gen.xxxxx.ru
           - tgt-ingress-tls-ci00641491-edevgen-custodian-devops-sandbox.apps.dev-gen.xxxxx.ru
         TENANT_PORT:
           - 80
           - 443
         TENANT_INNER_PORT:
           - 22080
           - 22443
         TENANT_EGRESS_PORT:
           - 21080
           - 21443

4. Удалите блок с параметрами для единственного тенанта из os_props.conf:

   ## Конфигурирование параметров тенанта

   ### Наименование тенанта
   TENANT_NAME=batch-qa-https

   ### HOST внешнего сервиса
   TENANT_HOST=ingress-ci00641491-edevgen-edevgen2-serverless-batch-qa.apps.dev-gen.ххххх.ru

   ### PORT внешнего сервиса
   TENANT_PORT=443

   ### PORT внешнего сервиса
   TENANT_EGRESS_PORT=21000

   ### Внутренний PORT, на который httpTarget будет отправлять запросы
   TENANT_INNER_PORT=22000

   ### Используемый протокол: tls/http
   TENANT_PROTOCOL=tls

   ### MUTUAL/DISABLE в зависимости от протокола: MUTUAL для TLS, DISABLE для HTTP
   #### Примечание: для сервисов, обращение к которым выполняется через HTTPS, вызов от сервиса до Egress выполняется по HTTP, а от Egress до интегрируемого сервиса проксируется через HTTPS
   TENANT_TLS_MODE=MUTUAL

5. Выполните повторный запуск Jenkins Job Install_EIP сервиса Batch согласно инструкции в документации сервиса Install_EIP.

Добавление второго нового и более тенанта с использованием Install_EIP#

Для добавления нового тенанта в конфигурацию сервиса Batch Tasks, в случае когда ранее использовались два и более тенанта, выполните следующие действия:

1. Добавьте в os_namespaces.yml значения параметров нового тенанта после значений последнего добавленного тенанта:

   projects:
   - name: "dev"
     openShiftNamespace: "ci00641491-edevgen2-serverless-batch-dev"
     openShiftURL: api.dev-gen2.xxxxx.ru:6443
     oc_token: batchtasks_dev_token
     os_props: "os_props.conf"
     deleteResources: true
     validateDeploy: false
     rollback:
     - needToRollback: true
     uniqueParams:
       destination-rule-egress-tenant.yml:
         TENANT_NAME:
           - httptarget-http
           - httptarget-https
           - httptarget-https
         TENANT_HOST:
           - tgt-ingress-ci00641491-edevgen-custodian-devops-sandbox.apps.dev-gen.xxxxx.ru
           - tgt-ingress-tls-ci00641491-edevgen-custodian-devops-sandbox.apps.dev-gen.xxxxx.ru
           - tgt-ingress-tls-ci00888888-edevgen-custodian-devops-sandbox.apps.dev-gen.xxxxx.ru
         TENANT_PORT:
           - 80
           - 443
           - 888
         TENANT_TLS_MODE:
           - DISABLE
           - MUTUAL
           - MUTUAL
       ...
       // Внимание! Внесите данные нового тенанта в каждый .yml в блоке uniqueParams.

2. Выполните повторный запуск Jenkins Job Install_EIP сервиса Batch согласно инструкции в документации сервиса Install_EIP.

Дополнительная информация. Использование плейсхолдера в шаблонах#

Благодаря тому, что в шаблонах файлов, приведенных в блоке uniqueParams, в параметре name присутствует плейсхолдер {{TENANT_NAME}}, принимающий уникальные значения из os_namespaces.yml, параметры каждого тенанта будут размещены в отдельных файлах после отработки Jenkins Job Instal_EIP.

destination-rule-egress-tenant.yml:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: batch-tasks-egress-dr-{{TENANT_NAME}}
  ...

Дополнительная информация. Перенаправление запроса через внутренний порт#

Отдельное внимание стоит уделить параметрам TENANT_INNER_PORT. Они могут быть как различными для разных тенантов, так и одинаковыми. Значение TENANT_INNER_PORT определяет внутренний порт сервиса, на который httpTarget будет выполнять запрос. Вся цепочка выполнения запроса будет выглядеть следующим образом:

1. Запрос выполняется на внутренний HTTP-порт (TENANT_INNER_PORT).

2. Запрос перенаправляется на внутренний порт Egress (TENANT_EGRESS_PORT).

3. Запрос проходит через OTT-sidecar и выполняется шифрование.

4. Запрос отправляется на реальный HOST:PORT (TENANT_HOST, TENANT_PORT).

Рекомендации по установке и использованию пароля#

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

Пароли должны:

• содержать не менее восьми символов;

• содержать буквы разного регистра, цифры и спецсимволы.

Пароли не должны:

• содержать последовательно идущие символы;

• являться персональной информацией (имена, адреса, дата рождения, телефон и т.д.);

• применяться в открытых сервисах.

Рекомендуется изменять пароль раз в 30—90 дней в зависимости от среды. Это станет гарантией того, что злоумышленники не смогут взломать пароль подбором. Убедитесь, что в новом пароле не повторяется более трех символов старого пароля подряд.

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

Конфигурирование подключения сервиса к СУБД#

Чтобы выполнить конфигурирование подключения сервиса Batch Tasks к БД, например настроить подключение к другому экземпляру БД, выполните следующие действия:

1. Сконфигурируйте настройки подключения Batch Tasks к БД:

   1. Измените значение параметра jdbc-url (URL соединения с БД) на нужное.

   2. В случае, если подключение к новой БД осуществляется под новым пользователем, внесите правки в значения параметров database.main.password и database.main.username.

   3. Разместите секреты с новыми username, password в среде контейнеризации согласно инструкции «Передача и использование секретных данных» в Руководстве по установке.

   4. Проверьте актуальность настроек для новой СУБД в os_props.conf:

      # <!- заполните самостоятельно -> — значения параметров необходимо заполнить самостоятельно
   
      # JDBC_URL соединения с основной БД
      MAIN_DB_JDBC_URL=<!- заполните самостоятельно ->
   
      # Текущая схема подключения к основной БД (например: "tasks_schema")
      MAIN_DB_CURRENT_SCHEMA=<!- заполните самостоятельно ->
   
      # Прикладной пользователь основной БД (например: "tasks_appl_user")
      MAIN_DB_USER=<!- заполните самостоятельно ->
   
      # Флаг поддержки SSL/TLS-соединения на основной БД (true/false). Если при подключении к новой БД используется SLL (true), то проверьте нижеследующие параметры (TLS_CERT_PATH, TLS_KEY_PATH, TLS_ROOT_CERT_PATH, TLS_FACTORY); если SLL при подключении к новой БД не используется (false), то эти параметры не применяются.
      MAIN_DB_SSL_ON=<!- заполните самостоятельно: true/false ->
   
      # Путь до volumeMounts публичного клиентского сертификата. Пути не меняются при изменении БД, поэтому менять значения не требуется.
      MAIN_DB_TLS_CERT_PATH=/app/certs/db/tasks_appl_user.crt
   
      # Путь до volumeMounts закрытого клиентского ключа. Пути не меняются при изменении БД, поэтому менять значения не требуется.
      MAIN_DB_TLS_KEY_PATH=/app/certs/db/tasks_appl_user.pk8
   
      # Путь до volumeMounts публичного родительского (CA) сертификата. Пути не меняются при изменении БД, поэтому менять значения не требуется.
      MAIN_DB_TLS_ROOT_CERT_PATH=/app/certs/db/root.crt
   
      # Фабрика для построения JDBC-соединения. Пути не меняются при изменении БД, поэтому менять значения не требуется.
      MAIN_DB_TLS_FACTORY=org.postgresql.ssl.jdbc4.LibPQFactory
   

   5. Если используется репликационная БД, повторите вышеуказанные действия для конфигурирования параметров подключения к репликационной базе данных (Stand-In DB).

2. Если в развертывании сервиса используются Istio (os_props.conf: TASKS_UI_ISTIO_INJECT=true или среда контейнеризации в Deployment (Deployment Config): template.metadata.annotations:sidecar.istio.io/inject: 'true'), поменяйте настройки serviceEntry (указывает, что задаваемый host находится вне namespace) для Istio-proxy в os_props.conf:

   # Host основной БД. Введите параметры для новой БД, например:
   MAIN_DB_HOST=ххх.xxx.xxx
   MAIN_DB_IP=10.53.122.56
   MAIN_DB_PORT=5432
   
   # Host SI БД. Введите параметры для новой SI БД, например:
   SI_DB_HOST=ххх.ххх.ххх
   SI_DB_IP=10.53.125.41
   SI_DB_PORT=5432
   

Реализация Graceful Shutdown и конфигурирование Rolling Update сервиса Batch Tasks#

Graceful shutdown#

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

Общий принцип завершения работы Pod#

1. Pod переводится в статус Terminating и исключается из списка endpoints для сервиса. Начинается отсчет тайм-аута (grace period).

2. Выполняется команда preStop Hook. Конфигурирование команды preStop Hook в yaml-файле позволяет выполнить одно из двух действий: команду или запрос.

3. После завершения команды preStop Hook приложению посылается сигнал SIGTERM.

4. Начинается отсчет тайм-аута (grace period), за время которого приложение завершается. Конфигурируется в yaml-файле.

5. Если за время тайм-аута приложение еще не завершилось, посылается сигнал SIGKILL, приложение принудительно завершает работу, Pod удаляется.

Особенности tasks-worker#

Микросервис tasks-worker выполняет вызовы httpTarget с помощью Apache Async Http Client по мере появления новых Задач. При этом вызовы синхронизируются через БД (таблица билетов).

В команде preStop Hook выполняются несколько действий:

1. В начале команды preStop Hook останавливается цикл отбора новых Задач из БД.

2. Выполняется ожидание в течение времени, необходимого для завершения уже запущенной итерации отбора новых задач из БД. Конфигурируется в os_props.conf в плейсхолдере TASKS_WORKER_PRESTOP_SLEEP_DURATION_SECONDS.

3. Выполняется ожидание завершения запущенных вызовов httpTarget, не дольше заданного времени. Если вызовы завершаются раньше, ожидание также прекращается раньше. Конфигурируется в os_props.conf в TASKS_WORKER_HTTP_CLIENT_GRACE_PERIOD_SECONDS.

4. Завершается выполнение команды preStop Hook, сервис получает SIGTERM и завершается. Длительность выключения компонентов сервиса конфигурируется в os_props.conf в TASKS_WORKER_TIMEOUT_PER_SHUTDOWN_PHASE. При этом сумма трех вышеперечисленных периодов времени не должна превысить общее время выключения Pod, которое конфигурируется в os_props.conf в TASKS_WORKER_TERMINATION_GRACE_PERIOD_SECONDS.

Конфигурирование параметров Graceful Shutdown#

os_props.conf:

## Конфигурирование параметров Graceful Shutdown

### Конфигурирование параметров Graceful Shutdown для TASKS_SERVER
#### Сумма остальных интервалов для TASKS_SERVER. Размерность: целое число секунд
TASKS_SERVER_TERMINATION_GRACE_PERIOD_SECONDS=30
#### Необходимое время ожидания для завершения уже запущенной итерации отбора новых задач из БД. Размерность: целое число секунд
TASKS_SERVER_PRESTOP_SLEEP_DURATION_SECONDS=10
#### Время на Graceful Shutdown для Tomcat, который обрабатывает входящие запросы. Значение параметра задается в формате Duration, например: "PT20S"; если задать просто число, то в качестве размерности будут использованы миллисекунды
TASKS_SERVER_TIMEOUT_PER_SHUTDOWN_PHASE=PT20S

### Конфигурирование параметров Graceful Shutdown для TASKS_WORKER
#### Сумма остальных интервалов для TASKS_WORKER. Размерность: целое число секунд
TASKS_WORKER_TERMINATION_GRACE_PERIOD_SECONDS=45
#### Необходимое время ожидания для завершения уже запущенной итерации отбора новых задач из БД. Размерность: целое число секунд
TASKS_WORKER_PRESTOP_SLEEP_DURATION_SECONDS=5
#### Время ожидания завершения запущенных вызовов httpTarget. Если вызовы завершаются раньше, ожидание также прекращается раньше. Размерность: целое число секунд
TASKS_WORKER_HTTP_CLIENT_GRACE_PERIOD_SECONDS=20
#### Время на Graceful Shutdown для Tomcat, который обрабатывает входящие запросы. Значение параметра задается в формате Duration, например: "PT60S"; если задать просто число, то в качестве размерности будут использованы миллисекунды
TASKS_WORKER_TIMEOUT_PER_SHUTDOWN_PHASE=PT20S

### Конфигурирование параметров Graceful Shutdown для TASKS_GC
#### Сумма остальных интервалов для TASKS_GC. Размерность: целое число секунд
TASKS_GC_TERMINATION_GRACE_PERIOD_SECONDS=30
#### Необходимое время ожидания для завершения уже запущенной итерации отбора новых задач из БД. Размерность: целое число секунд
TASKS_GC_PRESTOP_SLEEP_DURATION_SECONDS=10
#### Время на Graceful Shutdown для Tomcat, который обрабатывает входящие запросы. Значение параметра задается в формате Duration, например: "PT60S"; если задать просто число, то в качестве размерности будут использованы миллисекунды
TASKS_GC_TIMEOUT_PER_SHUTDOWN_PHASE=PT20S

### Конфигурирование параметров Graceful Shutdown для TASKS_JOURNAL_APPLIER
#### Сумма остальных интервалов для TASKS_JOURNAL_APPLIER. Размерность: целое число секунд
TASKS_JA_TERMINATION_GRACE_PERIOD_SECONDS=30
#### Необходимое время ожидания для завершения уже запущенной итерации отбора новых задач из БД. Размерность: целое число секунд
TASKS_JA_PRESTOP_SLEEP_DURATION_SECONDS=10
#### Время на Graceful Shutdown для Tomcat, который обрабатывает входящие запросы. Значение параметра задается в формате Duration, например: "PT60S"; если задать просто число, то в качестве размерности будут использованы миллисекунды
TASKS_JA_TIMEOUT_PER_SHUTDOWN_PHASE=PT20S

Rolling Update#

Обзор#

Сервис Batch Tasks поддерживает Rolling Update — стратегию обновления без прерывания работы сервиса с постепенным отключением экземпляров старой версии и вводом экземпляров новой версии.

В среде контейнеризации предусмотрена стратегия обновления Rolling Update, которая реализует эту логику.

Чтобы просмотреть настройки стратегии обновления, в консоли среды контейнеризации выполните следующие действия:

1. В меню Workloads выберите раздел Deployment (Deployment Configs).

2. В списке выберите необходимую конфигурацию tasks-server/tasks-worker/tasks-gc/tasks-journal-applier.

3. В конфигурации перейдите на вкладку YAML.

4. Поиском найдите параметр spec.strategy.type.

Параметр не конфигурируется в os_props.conf.

При обновлении приложения стратегией Rolling создается новый Replication Controller и количество Pods в старом Replication Controller постепенно сокращается, а в новом — увеличивается, пока в старом не достигнет нуля, а в новом — значения, заданного параметром replicas (в OpenShift конфигурация tasks-server, параметр spec.replicas).

Чтобы просмотреть настройки количества реплик, в консоли среды контейнеризации выполните следующие действия:

1. В меню Workloads выберите раздел Deployment (Deployment Configs).

2. В списке выберите необходимую конфигурацию tasks-server/tasks-worker/tasks-gc/tasks-journal-applier.

3. В конфигурации перейдите на вкладку YAML.

4. Поиском найдите параметр spec.replicas.

Параметр конфигурируется в os_props.conf соответствующими плейсхолдерами *_REPLICAS_COUNT.

Доступные стратегии развертывания#

Существует две стратегии развертывания, которые могут комбинироваться:

1. Поочередное завершение работы старых Pods и запуск на их месте новых Pods:

   • плюсы: способ не требует дополнительных ресурсов,

   • минусы: во время обновления количество работающих Pods будет меньше, чем количество реплик.

2. Поочередный запуск новых Pods, а после их успешного запуска (получение успешной liveness/readiness probes) — завершение старых Pods:

   • плюсы: доступность сервиса не уменьшается,

   • минусы: требует дополнительных ресурсов.

При комбинировании способов ожидаемые:

• Недостатки:

  • временное уменьшение количества работающих экземпляров сервиса,

  • временное использование дополнительных ресурсов.

• Преимущества:

  • более быстрое обновление.

Выбор стратегии остается за администраторами среды контейнеризации.

Конфигурирование параметров Rolling Update#

os_props.conf:

## Конфигурирование параметров Rolling Update

### Дополнительная информация
#### Примеры к параметрам *_UPDATE_MAX_UNAVAILABLE: 1) При replicas=3 и maxUnavailable=1 во время обновления количество работающих Pods не будет опускаться ниже 2 и работа сервиса не будет прерываться. 2) При replicas=2 и maxUnavailable=2 стратегия Rolling сводится к стратегии Recreate — останавливаются оба Pods, вместо них запускаются два новых. Непрерывная работа сервиса в этом случае не обеспечивается
#### Внимание! Значения параметров *_MAX_UNAVAILABLE и *_MAX_SURGE не могут одновременно быть равны нулю

### Конфигурирование параметров Rolling Update для TASKS_SERVER
#### Время в секундах на полное обновление. При превышении выполняется откат к предыдущей версии
TASKS_SERVER_ROLLING_UPDATE_TIMEOUT_SECONDS=600
#### Насколько можно сократить количество работающих Pods, относительно соответствующего параметра *_REPLICAS_COUNT
TASKS_SERVER_ROLLING_UPDATE_MAX_UNAVAILABLE=1
#### Насколько общее число Pods (число: работающие + запускающиеся + завершающиеся), может превысить соответствующий параметр *_REPLICAS_COUNT
TASKS_SERVER_ROLLING_UPDATE_MAX_SURGE=0

### Конфигурирование параметров Rolling Update для TASKS_WORKER
#### Время в секундах на полное обновление. При превышении выполняется откат к предыдущей версии
TASKS_WORKER_ROLLING_UPDATE_TIMEOUT_SECONDS=600
#### Насколько можно сократить количество работающих Pods, относительно соответствующего параметра *_REPLICAS_COUNT
TASKS_WORKER_ROLLING_UPDATE_MAX_UNAVAILABLE=1
#### Насколько общее число Pods (число: работающие + запускающиеся + завершающиеся), может превысить соответствующий параметр *_REPLICAS_COUNT
TASKS_WORKER_ROLLING_UPDATE_MAX_SURGE=0

### Конфигурирование параметров Rolling Update для TASKS_GC
#### Время в секундах на полное обновление. При превышении выполняется откат к предыдущей версии
TASKS_GC_ROLLING_UPDATE_TIMEOUT_SECONDS=600
#### Насколько можно сократить количество работающих Pods, относительно соответствующего параметра *_REPLICAS_COUNT
TASKS_GC_ROLLING_UPDATE_MAX_UNAVAILABLE=1
#### Насколько общее число Pods (число: работающие + запускающиеся + завершающиеся), может превысить соответствующий параметр *_REPLICAS_COUNT
TASKS_GC_ROLLING_UPDATE_MAX_SURGE=0

### Конфигурирование параметров Rolling Update для TASKS_JOURNAL_APPLIER
#### Время в секундах на полное обновление. При превышении выполняется откат к предыдущей версии
TASKS_JA_ROLLING_UPDATE_TIMEOUT_SECONDS=600
#### Насколько можно сократить количество работающих Pods, относительно соответствующего параметра *_REPLICAS_COUNT
TASKS_JA_ROLLING_UPDATE_MAX_UNAVAILABLE=1
#### Насколько общее число Pods (число: работающие + запускающиеся + завершающиеся), может превысить соответствующий параметр *_REPLICAS_COUNT
TASKS_JA_ROLLING_UPDATE_MAX_SURGE=0

Администрирование внешних средств защиты информации осуществляется в соответствии с их документацией.

Настройка геобалансировщика#

Для настройки геобалансировки с health-check установите параметры согласно таблице.

События системного журнала#

Уровни событий системного журнала#

Сервис Batch Tasks приводит следующие основные типы (уровни) событий системного журнала:

1. error — ошибки, возникающие в процессе работы сервиса. Выводятся по умолчанию в компонент Прикладной журнал. Пример: Ошибка при создании Job name=test, Ошибка при поиске Job name= test.

2. warn — предупреждения, возникающие в процессе работы сервиса. Выводятся по умолчанию в компонент Прикладной журнал. Пример: Число итераций диспетчеризации превысило значение: 15. Номер текущей итерации: 16., Не заданы HTTP коды ошибок, при получении которых допускается повторный запуск Задания!.

3. info — информационные сообщения, возникающие в процессе работы сервиса. Выводятся по умолчанию в компонент Прикладной журнал. Пример: Создана Задача Job name=test, Получена Задача Job name=test.

4. debug — отладочные сообщения (детали взаимодействия с внешними системами), возникающие в процессе работы сервиса. Не выводятся по умолчанию в компонент Прикладной журнал. Пример: Выполнена диспетчеризации экземпляров истории Заданий. Количество итераций: 5., Не удалось вставить запись о блокировке test.

5. trace — трассировочные сообщения (ход выполнения сложных участков сервиса — информация для анализа ошибок), возникающие в процессе работы сервиса. Пример: Блокировки по CRON и по onlyOneInstance захвачены для test, Запуск Задания name=test resourceName=rn, cronTime=22.06.2022.

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

События мониторинга#

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

Часто встречающиеся проблемы и пути их устранения#

Алгоритм для диагностирования и решения проблем с внешними интеграциями:

1. Проанализируйте журнал сервиса на наличие ошибок/успешных запросов.

2. Проанализируйте журнал Istio Proxy в поде сервиса на наличие ошибок/успешных запросов.

3. Проанализируйте журнал Egress Gateway на наличие ошибок/успешных запросов.

4. Проанализируйте журнал Ott Sidecar на Egress на наличие ошибок/успешных запросов.

Термины и определения#