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

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

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

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

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

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

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

Рекомендации по заданию стойких паролей#

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

• пароль изменяется минимум один раз за 80 дней;

• в пароле используются строчные и прописные буквы и цифры;

• длина пароля составляет не менее 12 символов;

• пароль не должен содержать логин УЗ пользователя или какую-либо его часть;

• пароль должен быть уникален, недопустимо использование одного и того же пароля для нескольких УЗ одного пользователя;

• пароль должен храниться в зашифрованном виде, хранение пароля в незащищенном виде (в текстовых, конфигурационных файлах, скриптов) запрещено;

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

• при компрометации пароля необходимо незамедлительно его сменить;

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

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

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

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

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

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

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

   • разместите секреты с новыми username, password в системе оркестрации контейнерами согласно инструкции, приведенной в Руководстве по установке в разделе «Настройка окружения»;

   • проверьте актуальность настроек для новой СУБД batch-scheduler.all.conf:

# URL соединения с основной БД. Пример: jdbc:postgresql://example.com:5432/dbname
# Если установка происходит вместе с конфигурационными файлами Istio, то порт должен совпадать с MAIN_DB_EGRESS_IN_PORT
MAIN_DB_JDBC_URL=<!- заполните самостоятельно ->
# Флаг поддержки SSL/TLS соединения на основной БД (true/false)
MAIN_DB_SSL_ON=<!- заполните самостоятельно: true/false ->
# Путь до volumeMounts публичного клиентского сертификата
MAIN_DB_TLS_CERT_PATH=/app/certs/db/postgresql.crt
# Путь до volumeMounts приватного клиентского ключа
MAIN_DB_TLS_KEY_PATH=/app/certs/db/postgresql.pk8
# Путь до volumeMounts публичного родительского (CA) сертификата
MAIN_DB_TLS_ROOT_CERT_PATH=/app/certs/db/root.crt
# Фабрика для построения соединения с БД
MAIN_DB_TLS_FACTORY=org.postgresql.ssl.jdbc4.LibPQFactory
# Дополнительные параметры URL основной базы данных. Добавляются в конец url путем добавления &param1=value1&param2=value2&....
# Если дополнительные параметры отсутствуют, то необходимо оставить значение плейсхолдера пустым. Пример параметров: &targetServerType=master&prepareThreshold=0. При добавлении параметров учесть, что добавление начинается с символа "&"
# В этом параметре указывается схема подключения. Значение по умолчанию: &currentSchema=scheduler_schema
ADDITIONAL_PARAMETERS_MAIN_DB=&currentSchema={{lookup('custom_vars','jdbc.scheduler_postgres.schema.main')}}
MAIN_DB_FULL_JDBC_URL={{MAIN_DB_JDBC_URL}}?ssl={{MAIN_DB_SSL_ON}}&sslfactory={{MAIN_DB_TLS_FACTORY}}&sslrootcert={{MAIN_DB_TLS_ROOT_CERT_PATH}}&sslcert={{MAIN_DB_TLS_CERT_PATH}}&sslkey={{MAIN_DB_TLS_KEY_PATH}}{{ADDITIONAL_PARAMETERS_MAIN_DB}}

Для использования кластера БД Patroni в файле batch-scheduler.istio.all.conf необходимо сконфигурировать следующие параметры:

### Конфигурирование параметров Stand-In БД
MAIN_DB_HOST_M=<Обязательно к заполнению>
MAIN_DB_IP_M=<Обязательно к заполнению>
MAIN_DB_PORT_M=5432

### Мастер БД в кластере Main
MAIN_DB_EGRESS_IN_PORT_M=12001
MAIN_DB_EGRESS_OUT_PORT_M=2001

### Конфигурирование параметров Stand-In БД
### Мастер БД в кластере SI - заполнить при необходимости
SI_DB_HOST_M=<Обязательно к заполнению>
SI_DB_IP_M=<Обязательно к заполнению>
SI_DB_PORT_M=5432

### Мастер БД в кластере SI
SI_DB_EGRESS_IN_PORT_M=12003
SI_DB_EGRESS_OUT_PORT_M=2003

# Флаг включения дополнительных параметров и конфигурационных файлов для возможности использования кластера Pangolin\Postgres основной базы данных PG_CLUSTER_CONFIGURATION_MAIN_ENABLED=true
# Флаг включения дополнительных параметров и конфигурационных файлов для возможности использования кластера Pangolin\Postgres базы данных SI
PG_CLUSTER_CONFIGURATION_SI_ENABLED=true

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

# Host основной БД. Ввести параметры для новой БД, например:
MAIN_DB_HOST=xxx.xxx.xxx
MAIN_DB_IP=10.xx.xxx.xx
MAIN_DB_PORT=5432
   
# Параметры внешнего взаимодействия основной БД
MAIN_DB_EGRESS_IN_PORT=12001
MAIN_DB_EGRESS_OUT_PORT=2001 
   
# host SI БД. Ввести параметры для новой SI БД, например:
SI_DB_HOST=xxx.xxx.xxx
SI_DB_IP=10.xx.xxx.xx
SI_DB_PORT=5432
      
# Параметры внешнего взаимодействия Stand-In БД
SI_DB_EGRESS_IN_PORT=12003
SI_DB_EGRESS_OUT_PORT=2003 

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

Graceful shutdown#

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

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

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

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

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

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

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

Особенности scheduler-dispatcher#

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

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

1. Планировщик заданий останавливается, обновляется список запланированных к запуску задач.

2. В начале команды preStop Hook выполняется остановка всех запланированных вызовов.

3. Выполняется ожидание в течение времени, необходимого для обработки запросов, которые могут приходить, пока Pod не удален из списка endpoint. Конфигурируется в файле scheduler-dispatcher в плейсхолдер SCHD_DISPATCHER_PRESTOP_SLEEP_DURATION_SECONDS.

4. Выполняется ожидание завершения запущенных вызовов HttpTarget до истечения заданного времени. Если вызовы завершаются раньше, то и ожидание прекращается раньше. Конфигурируется в scheduler-dispatcher в плейсхолдер SCHD_DISPATCHER``_HTTP_CLIENT_GRACE_PERIOD_SECONDS.

5. Завершается выполнение команды preStop Hook, сервис получает SIGTERM и завершается (вместе с scheduler-dispatcher). Длительность выключения компонентов сервиса конфигурируется в scheduler-dispatcher в SCHD_DISPATCHER_TIMEOUT_PER_SHUTDOWN_PHASE. При этом сумма вышеперечисленных периодов времени не должна превысить общее время выключения Pod, которое конфигурируется в scheduler-dispatcher в SCHD_DISPATCHER_TERMINATION_GRACE_PERIOD_SECONDS.

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

Для конфигурирования параметров Graceful Shutdown заполните следующие файлы:

• scheduler-dispatcher.conf:

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

#### Сумма остальных интервалов для SCHD_DISPATCHER. Размерность: целое число секунд
SCHD_DISPATCHER_TERMINATION_GRACE_PERIOD_SECONDS=50
#### Необходимое время ожидания для обработки запросов, которые могут приходить, пока Pod не удален из списка endpoint. Размерность: целое число секунд
SCHD_DISPATCHER_PRESTOP_SLEEP_DURATION_SECONDS=10
#### Время ожидания завершения запущенных вызовов HttpTarget. Если вызовы завершаются раньше, ожидание также прекращается раньше. Размерность: целое число секунд
SCHD_DISPATCHER_HTTP_CLIENT_GRACE_PERIOD_SECONDS=20
#### Время на graceful shutdown для Tomcat, который обрабатывает входящие запросы. Значение параметра задается в формате Duration, например: «PT60S»; если задать просто число, то в качестве размерности будут использованы миллисекунды
SCHD_DISPATCHER_TIMEOUT_PER_SHUTDOWN_PHASE=PT20S

• scheduler-server.conf:

### Конфигурирование параметров Graceful Shutdown для SCHD_SERVER
#### Сумма остальных интервалов для SCHD_SERVER. Размерность: целое число секунд
SCHD_SERVER_TERMINATION_GRACE_PERIOD_SECONDS=30
#### Необходимое время ожидания для обработки запросов, которые могут приходить, пока Pod не удален из списка endpoint. Размерность: целое число секунд
SCHD_SERVER_PRESTOP_SLEEP_DURATION_SECONDS=10
#### Время на graceful shutdown для Tomcat, который обрабатывает входящие запросы. Значение параметра задается в формате Duration, например: «PT60S»; если задать просто число, то в качестве размерности будут использованы миллисекунды
SCHD_SERVER_TIMEOUT_PER_SHUTDOWN_PHASE=PT20S

• scheduler-journal-applier.conf:

### Конфигурирование параметров Graceful Shutdown для SCHD_JA
#### Сумма остальных интервалов для SCHD_JA. Размерность: целое число секунд
SCHD_JA_TERMINATION_GRACE_PERIOD_SECONDS=30
#### Необходимое время ожидания для обработки запросов, которые могут приходить, пока Pod не удален из списка endpoint. Размерность: целое число секунд
SCHD_JA_PRESTOP_SLEEP_DURATION_SECONDS=10
#### Время на graceful shutdown для Tomcat, который обрабатывает входящие запросы. Значение параметра задается в формате Duration, например: «PT60S»; если задать просто число, то в качестве размерности будут использованы миллисекунды
SCHD_JA_TIMEOUT_PER_SHUTDOWN_PHASE=PT20S

• scheduler-gc.conf:

### Конфигурирование параметров Graceful Shutdown для SCHD_GC
#### Сумма остальных интервалов для SCHD_GC. Размерность: целое число секунд
SCHD_GC_TERMINATION_GRACE_PERIOD_SECONDS=30
#### Необходимое время ожидания для обработки запросов, которые могут приходить, пока Pod не удален из списка endpoint. Размерность: целое число секунд
SCHD_GC_PRESTOP_SLEEP_DURATION_SECONDS=10
#### Время на graceful shutdown для Tomcat, который обрабатывает входящие запросы. Значение параметра задается в формате Duration, например: «PT60S»; если задать просто число, то в качестве размерности будут использованы миллисекунды
SCHD_GC_TIMEOUT_PER_SHUTDOWN_PHASE=PT20S

Rolling Update#

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

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

1. Перейдите Workloads → Deployment (Deployment Configs).

2. В списке выберите конфигурацию scheduler-dispatcher/scheduler-server/scheduler-journal-applier.

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

Параметр конфигурируется в batch-scheduler.k8s.all.conf.

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

Для просмотра настройки количества реплик в системе оркестрации контейнерами:

1. Последовательно перейдите по вкладкам Workloads → Deployment (Deployment Configs).

2. В списке выберите конфигурацию scheduler-dispatcher/scheduler-server/scheduler-journal-applier.

3. В выбранной конфигурации перейдите на вкладку YAML и поиском найдите spec.replicas.

Параметр конфигурируется в файлах:

• scheduler-server.conf с плейсхолдер SCHD_SERVER_REPLICAS_COUNT;

• scheduler-dispatcher.conf с плейсхолдер SCHD_DISPATCHER_REPLICAS_COUNT;

• scheduler-server.conf с плейсхолдер SCHD_JA_APPLIER_REPLICAS_COUNT.

Для gc не конфигурируется, т.к. для корректной работы Pod необходим только один экземпляр.

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

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

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

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

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

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

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

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

При комбинировании способов:

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

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

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

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

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

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

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

Пример заполненного файла scheduler-dispatcher.conf:

#### Примеры к параметрам *_UPDATE_MAX_UNAVAILABLE: 1) При replicas=3 и maxUnavailable=1 во время обновления количество работающих Pods не будет опускаться ниже 2 и работа сервиса не будет прерываться; 2) При replicas=2 и maxUnavailable=2 стратегия Rolling сводится к стратегии Recreate - останавливаются оба Pods, вместо них запускаются два новых. Непрерывная работа сервиса в этом случае не обеспечивается.
#### Внимание! Значения параметров *_MAX_UNAVAILABLE и *_MAX_SURGE не могут одновременно быть равны нулю.
 
### Конфигурирование параметров Rolling Update для SCHD_DISPATCHER
#### Время в секундах на полное обновление. При превышении выполняется откат к предыдущей версии
SCHD_DISPATCHER_ROLLING_UPDATE_TIMEOUT_SECONDS=600
#### Насколько можно сократить количество работающих Pods относительно соответствующего параметра *_REPLICAS_COUNT
SCHD_DISPATCHER_ROLLING_UPDATE_MAX_UNAVAILABLE=1
#### Насколько общее число Pods (число: работающие + запускающиеся + завершающиеся) может превысить соответствующий параметр *_REPLICAS_COUNT
SCHD_DISPATCHER_ROLLING_UPDATE_MAX_SURGE=0

Пример заполненного файла scheduler-server.conf:

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

Пример заполненного файла scheduler-journal-applier.conf:

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

Пример заполненного файла scheduler-gc.conf:

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

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

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

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

Просмотр метрик мониторинга#

Для просмотра метрик мониторинга с использованием компонента Объединенный мониторинг Unimon (MONA):

1. В среде контейнеризации перейдите на вкладку PODs и выберите pod, например, scheduler-server.

2. Перейдите в терминал и введите команду:

curl localhost:8081/actuator/prometheus

3. В полученном сообщении отобразятся отбрасываемые метрики с событиями мониторинга (также приведены в разделе «События мониторинга»).

4. Перейдите в систему отображения метрик (например, Prometheus), указав необходимую метрику. Например, system_cpu_usage.

Контроль сертификатов#

Подробная инструкция по получению сертификатов приведена в Руководстве по установке в разделе «Настройка окружения».

Сертификаты хранятся в зашифрованном виде на сервере, где будет развернут компонент, и необходимы для всех TLS/mTLS-соединений. Сервис Batch Scheduler не предусматривает дополнительных средств защиты сертификатов. Также сертификаты могут храниться в зашифрованном виде в SecMan (при наличии интеграции с ним).

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

1. Передача секретных данных в систему оркестрации контейнерами.

2. Использование секретных данных при выполнении шагов развертывания (например, для добавления скриптов с использованием библиотеки Liquibase).

В первом случае необходимо передать в систему оркестрации контейнерами секрет, во втором — просто хранить секретные данные, которые будут использоваться при работе Jenkins Job. В обоих случаях также имеется возможность получить секреты из SecMan.

Сервис Batch Scheduler может использовать сторонние сертификаты:

• Istio (Ingress, Egress) при использовании Istio для сетевой безопасности;

• клиентский и серверный сертификаты для подключения к БД по SSL (при необходимости);

• сертификат для ОТТ (при необходимости).

Рекомендации по работе с сертификатами:

1. Сертификат должен быть подписан только удостоверяющим центром (CA). Необходимо удостовериться в отсутствии самоподписных сертификатов.

2. Сертификат должен «принадлежать» сервису Batch Scheduler (нельзя использовать один и тот же сертификат для функционирования разных сервисов в рамках одной инсталляции Platform V).

3. Сертификат должен быть действительным на текущую дату. Необходима проверка срока действия сертификата.

4. Сертификат не должен быть отозван соответствующим удостоверяющим центром (CA). Необходима проверка списков исключения сертификатов.

5. Должны быть подключены механизмы аутентификации, авторизации и валидации по сертификатам (при интеграции сервиса с компонентами Platform V, реализующими данный функционал, например, OTT).

6. Приватный/доверенный ключ не должен распространяться по каналам связи и должен иметь стойкий пароль.

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

Для хранения ключевой информации в системе оркестрации контейнерами должны использоваться только защищенные артефакты Secret или монтирование в файловую систему pod с помощью sidecar vault-agent, который получает ключевую информацию из сервиса Secret Management System.

Сертификаты для тестовых и промышленных сред должны быть выданы удостоверяющим центром.

Для сред разработки разрешено использование самоподписанных сертификатов.

Подробная инструкция по получению сертификатов приведена в Руководстве по установке в разделе «Настройка окружения».

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

Безопасная загрузка настроек сервиса Batch Scheduler#

В сервисе Batch Scheduler первоначальный запуск контейнера и загрузка всех настроек, необходимых для запуска компонента, происходят при старте контейнера из ConfigMap, Secrets, внешнего хранилища конфигураций, интегрированного в среду исполнения. Монтирование секретов происходит в папку вместо монтирования в переменные окружения. Также секреты могут быть получены из сервиса SecMan.

Приложению для запуска и работы нужны конфигурационные файлы, в которых прописаны настройки и сертификаты. Сертификаты хранятся в Secrets и монтируются на файловую систему при старте контейнера, откуда их читает приложение. Конфигурационные файлы хранятся в ConfigMaps и также монтируются на файловую систему контейнера.

ConfigMap и Secret подключаются к файловой системе контейнера в режиме .spec.containers[].volumeMounts[].readOnly: true.

В конфигурационных файлах вместо настроек, которые нельзя хранить в ConfigMaps в открытом виде (например логины и пароли), оставлены плейсхолдерs. Пароли хранятся в Secrets и монтируются при запуске контейнера в отдельную папку. Приложение при запуске читает конфигурационный файл и секреты и подставляет вместо плейсхолдерs соответствующие значения из Secrets.

Настройки ConfigMap в виде переменных окружения не передаются.

Обязательный секрет#

В каталоге /install/secrets дистрибутива представлены шаблоны секретов для инсталляции.

Для выполнения подстановки значений из Secrets вместо плейсхолдерs необходимо наличие секрета в namespace системы оркестрации контейнерами Kubernetes или OpenShift с именем batch-scheduler-app-secret, с набором полей с необходимыми именами:

kind: Secret
apiVersion: v1
metadata:
  name: batch-scheduler-app-secret
data:
  access.secret-key: <!- SPAS secret key ->
  database.main.password: <!- main database password ->
  database.main.username: <!- main database username ->
  database.stand-in.password: <!- stand-in database password ->
  database.stand-in.username: <!- stand-in database username ->
  journal.ssl.key.password: <!- journal ssl key password ->
  journal.ssl.keystore.password: <!- journal ssl keystore password ->
  journal.ssl.truststore.password: <!- journal ssl truststore password ->
type: Opaque

«Безопасная» загрузка#

Секрет монтируется в определенную папку внутри контейнера (/app/secrets). Для каждого поля в секрете создается файл с определенным именем, содержимое файла — значение поля в секрете. Имена файлов в этой папке совпадают с именами плейсхолдерs в конфигурационном файле. Вспомогательный класс EnvironmentPostProcessor читает файлы из этой папки и вместо каждого плейсхолдерs подставляет значение из соответствующего файла. Таким образом, пароли хранятся в секретах, а не в открытом виде; они не объявляются как переменные окружения, а загружаются из файлов напрямую.

Рекомендации к проверке подлинности сертификатов#

Для проверки подлинности сертификата выполните команду:

keytool -v -list -keystore <FileName>.jks | awk '/Owner:|Issuer:|Valid from/'

Вывод содержит следующую информацию:

• Owner: информация о CN сертификата.

• Issuer: УЦ банка.

• Valid from: срок действия сертификата.

Порядок действий в случае компрометации криптографических ключей#

При компрометации криптографических ключей (для выпуска и подписи токена) рекомендуется:

1. Приостановить информационное взаимодействие с применением скопрометированного ключа.

2. Незамедлительно поставить в известность Администратора безопасности или иное уполномоченное лицо Организации по вопросам информационной безопасности о произошедшем инциденте.

3. Следовать указания Администратора безопасности. Общий порядок действий:

• вывод из эскплуатации скомпрометированного ключа;

• проведение мероприятий по замене ключа;

• проверка работоспособности с новым ключом.

Конфигурирование валидатора URL#

Для включения валидатора UrlValidator для проверки HttpTarget.url в Configmap микросервиса scheduler-server установите значение параметра enabled=true.

  static:
    scheduler:
      url:
        validation:
          enabled: {{URL_VALIDATOR_ENABLED}} # Флаг включения валидации Httptarget.url: true - включена; false - выключена
          domains: {{URL_DOMAINS}}

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

Для расширения доменов первого уровня (валидатор обрабатывает и не генерирует исключение InvalidFormat url) перечислите через запятую домены в параметре domains.

Включение/отключение health-check для сервиса Аудит#

Для включения/отключения работы health-check в файле scheduler-server.conf для параметра SCHD_AUDIT_HEALTH_CHECK установите нужное значение флага true/false.

• При значении параметра false проверка доступности сервиса Аудит не проверяется. В этом случае при недоступности сервиса Аудит, события могут не попадать в Аудит (readiness probe Аудита в actuator/health нет).

• При значении параметра true и недоступном сервисе Аудит, трафик не принимается и не отправляется до тех пор, пока Аудит не станет доступным (в Batch Scheduler значение readiness probe false).

Пример:

# Проверка доступности сервиса Аудит (Readiness), так же включает в себя прерывание операций при ошибке отправки события в аудит: true — проверка доступности Аудит и прерывание операции включены, false — проверка доступности Аудит и прерывание операции выключены
SCHD_AUDIT_HEALTH_CHECK=true

По умолчанию health check включен, для отключения перед установкой сервиса в репозитории конфигураций необходимо установить значение параметра false.

Переопределение метрик#

Режим переопределения метрик#

Для включения механизма переопределения записи метрик:

• в файле batch-scheduler.all.conf установите значение параметра SCHD_OVERRIDE_METRIC_MODE=true;

• в файле batch-scheduler.all.conf установите режим переопределения установив соответствующее значение параметра SCHD_OVERRIDE_METRIC_MODE.

Возможные значения SCHD_OVERRIDE_METRIC_MODE:

• default - нет возможности переопределения метрик из Counter в Gauge, присутствуют метрики с окончанием на «sum» и «max»

• timer - есть возможность переопределения метрик из Counter в Gauge, присутствуют метрики с окончанием на «sum» и «max»

• target - есть возможность переопределения метрик из Counter в Gauge, метрики с окончанием на «sum» и «max» отсутствуют

Переопределение метрик из типа Counter (счетчик) в Gauge (измеритель)#

Переопределить метрики из типа Counter (счетчик) в Gauge (измеритель) возможно двумя способами.

1. Переопределение всех метрик:

• в файле scheduler-dispatcher.conf установите значение параметра SCHD_DISPATCHER_GAUGE_ALL_METRICS_FLAG=TRUE;

• при необходимости повторите для файлов: scheduler-server.conf, scheduler-gc.conf, scheduler-journal-applier.conf.

2. Точечное переопределение метрик:

• в файле scheduler-dispatcher.conf установите значение параметра SCHD_DISPATCHER_GAUGE_ALL_METRICS_FLAG=FALSE;

• в файле scheduler-dispatcher.conf в параметре SCHD_DISPATCHER_LIST_GAUGE_METRICS перечислите наименования метрик. Например: SCHD_DISPATCHER_LIST_GAUGE_METRICS=batch.scheduler-dispatcher.gauge.job.success_count,batch.scheduler-dispatcher.gauge.job.fail_count;

• при необходимости повторите для файлов: scheduler-server.conf, scheduler-gc.conf, scheduler-journal-applier.conf.

Для определения метрик, которые переопределены, имеется возможность установки суффикса. Для этого в файле scheduler-dispatcher.conf укажите значение параметра:

# Суффикс наименований метрик, которые переопределены
SCHD_DISPATCHER_METRICS_SUFFIX=<например: "_counter", "_gauge">

При необходимости повторите для файлов: scheduler-server.conf, scheduler-gc.conf, scheduler-journal-applier.conf.

Механизм включения/отключения заданных пользователем метрик#

В сервисе реализовано три режима работы: disabled, exclude, expand.

• В режиме disabled сервис игнорирует значение параметра SCHD_SERVER_METRICS_LIST_FROM_MODE. Установлен по умолчанию.

• В режиме exclude сервис не выполняет отправку метрик заданных в настройке параметра SCHD_SERVER_METRICS_LIST_FROM_MODE, метрики, не указанные в настройке, сервис продолжает отправлять.

• В режиме expand сервис выполняет отправку только тех метрик, которые указаны в настройке параметра SCHD_SERVER_METRICS_LIST_FROM_MODE, метрики, указанные в настройке, сервис продолжает отправлять.

Каждый pod сервиса оперирует своими метриками, поэтому для настройки механизма необходимо настраивать метрики для каждого микросервиса: scheduler-journal-applier, scheduler-dispatcher, scheduler-gc, scheduler-server.

Пример

Для включения в микросервис scheduler-server метрик: batch_scheduler_server_job_create_count_request_success, batch_scheduler_server_job_create_count_request_failed заполните в файле scheduler-server.conf блок кода (отправляются только метрики, указанные в параметре SCHD_SERVER_METRICS_LIST_FROM_MODE).

# Параметр задает текущий режим работы метрик, может принимать следующие значения: disabled, exclude, expand.
SCHD_SERVER_METRICS_MODE=expand

# Список метрик, которые нужно включить (mode=expand) или наоборот исключить (mode=exclude)
SCHD_SERVER_METRICS_LIST_FROM_MODE=batch.scheduler-server.job.create.count.request.success,batch.scheduler-server.job.create.count.request.successfailed

Учет нагрузки в разрезе потребителей#

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

1. Скачайте файл dashboard_billing.json.

2. Перейдите на страницу Grafana, например: https://ext-iam-spas-01.opsmon.xxx/indicator/.

3. На странице последовательно выберите Create — Dashboard и нажмите кнопку Add a new panel.

4. На открывшейся странице JSON Model слева выберите поле JSON Model.

5. В поле добавьте содержимое файла, скачанного в п.1, и нажмите кнопку Save Changes.

6. На странице JSON Model в поле datasource укажите наименование источника данных.

7. Выберите слева на поле Variables.

8. На открывшейся странице:

• выберите поле druidtable;

• в поле Value укажите наименование таблицы, которая соответствует контуру, где располагаются стенды;

• нажмите кнопку Update;

• нажмите кнопку Save dashboard.

Конфигурация стратегии удаления Заданий#

Для конфигурирования стратегии удаления Заданий в файле scheduler-server.conf установите значение параметра SCHD_SERVER_USING_GC_TO_DELETE_JOB = true — для применения стратегии по умолчанию (хранение в БД — 30 дней). Для удаления из БД в момент выполнения API запроса delete установите значение флага SCHD_SERVER_USING_GC_TO_DELETE_JOB = false. Пример:

# Флаг для переключения удаления Заданий через GC или немедленно при запросе. true — использовать gc, false — удалять сразу после запроса
SCHD_SERVER_USING_GC_TO_DELETE_JOB = false

Прерывание передачи событий аудита#

В сервисе Batch Scheduler реализована возможность прерывания текущей операции при ошибке отправки событий в Аудит (AUDT). Для этого в файле batch-scheduler.all.conf установите значение флага SCHD_AUDIT_ERROR_ENABLED=TRUE. Если значение параметра не установлено, то по умолчанию устанавливается значение TRUE.

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

Для конфигурирования параметров упругости в таблице resource_name (в основной и репликационной БД) создаются тенанты с лимитами, которые предварительно были созданы в файле custom_property.yml. При этом:

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

• Если лимит Задний изначально меньше, чем количество партиций, то после последующего увеличения лимита Заданий для тенанта и после рестарта pod scheduler-server партиции досоздаются до заданного количества партиций. Также производится перерасчет значений параметров partition_limit для каждой партиции. Если были созданы Задания, то их количество так же будет перераспределено по партициям, где главным условием является то, что количество созданных Заданий для каждой партиции не должно превышать значение в параметре partition_limit. Неравномерность распределения количества созданных Заданий по партициям не имеет значения.

• Если лимит Заданий изначально больше, чем количество партиций, то после последующего уменьшения (меньше чем количество партиций) лимита Заданий для тенанта и после рестарта pod scheduler-server часть партиций в параметре partition_limit принимает значение равным 0, т.е. использоваться для подсчета количества созданных Заданий не будут.

• В параметре partition_limit указываются лимиты для каждой партиции, которые рассчитываются по формуле: jobs_limit / количество партиций. А также учитывается остаток от деления и распределяется как +1 на partition_limit для каждой партиции. Такое вычисление применяется для каждого тенанта.

Для настройки ограничений на создание Заданий в разрезе потребителя:

1. В файле batch-scheduler.all.conf установите флаг включения механизма лимитов тенантов (true — для включения (установлено по умолчанию), false — для выключения):

# Включение/выключение механизма лимитов тенантов
SCHD_SERVER_JOBS_LIMIT_ENABLED=true

2. В файле batch-scheduler.all.conf установите значение переменной (минимальное значение — 1, максимальное — определяют администраторы сопровождения, по умолчанию (рекомендовано) — 1000):

# Лимит на создание Заданий в разрезе тенантов
SCHD_SERVER_JOBS_LIMIT=1000

Для настройки ограничений на создание Заданий в разрезе тенанта:

1. В файле custom_property.yml установите значение лимитов на Задания в блоке настроек tenants. Пример заполнения:

# Блок добавления тенантов
tenants:
- name: httptarget
  module_id: httptarget
  jobs_limit: 1000000

Описание блока кода по добавлению тенантов#

2. В файле scheduler-server.conf установите значение параметра SCHD_SERVER_CREATE_RN_LIMIT_ENABLED=true. Пример:

# Включение/выключение механизма создания тенантов в таблице БД resource-name. false - тенант с дефолтными лимитами не создается в таблице resource-name, true - тенант с дефолтными лимитами создается в таблице resource-name
SCHD_CREATE_RN_ENABLED=true

3. Переустановите сервис Batch Tasks с использованием Deploy Tools.

Определение момента отправления вектора в ПЖ#

В сервисе Batch Scheduler реализована возможность выбора момента отправки вектора в ПЖ: перед коммитом транзакции или после. Для отправки вектора в ПЖ перед коммитом транзакции в файле batch-scheduler.all.conf установите значение флага AJ_SENDER_BEFORE_COMMIT_ENABLED равным true. В случае установки false отправка вектора будет выполнена после коммита транзакции. Пример:

AJ_SENDER_BEFORE_COMMIT_ENABLED=true

Внимание!

Рекомендуется устанавливать момент отправки векторов в ПЖ до коммита транзакции, т.к. иной режим может привести к рассинхронизации доставки векторов в кафку.

Длительность ожидания ответа#

Описание#

Конфигурационные параметры SCHD_SERVER_JOB_RESPONSE_TIMEOUT_MAX и SCHD_SERVER_JOB_RESPONSE_TIMEOUT_DEFAULT управляют поведением сервера при обработке задач.
Настройки влияют на:

• Максимально допустимое время выполнения задачи

• Стандартное время ожидания ответа для новых запросов

Параметры конфигурации#

1. SCHD_SERVER_JOB_RESPONSE_TIMEOUT_MAX#

Назначение: Максимальное время ожидания ответа (в секундах), которое может быть установлено для задачи.

Формат: Целое число в секундах

Примеры допустимых значений:

SCHD_SERVER_JOB_RESPONSE_TIMEOUT_MAX=900  # 15 минут
SCHD_SERVER_JOB_RESPONSE_TIMEOUT_MAX=1800 # 30 минут

Особенности:

• Значение должно быть ≥ 1;

• Запрещает установку таймаутов сверх указанного лимита;

• Применяется ко всем типам задач.

2. SCHD_SERVER_JOB_RESPONSE_TIMEOUT_DEFAULT#

Назначение: Стандартная длительность ожидания ответа для новых запросов.

Формат: ISO 8601 Duration Формат: PTnS (где n — время в секундах)

Примеры:

SCHD_SERVER_JOB_RESPONSE_TIMEOUT_DEFAULT=PT900S   # 15 минут
SCHD_SERVER_JOB_RESPONSE_TIMEOUT_DEFAULT=PT3600S # 1 час

Рекомендации по настройке#

1. Соотношение параметров:

   • TIMEOUT_DEFAULT должен быть ≤ TIMEOUT_MAX.

2. Оптимальные значения:

   • Для CPU-intensive задач: 1800+ секунд;

   • Для IO-bound операций: 300-600 секунд;

   • Для интерактивных задач: 60-120 секунд.

3. Безопасность:

   • Не устанавливать TIMEOUT_MAX > 86400 (24 часа);

   • Избегать значений < 10 секунд.

Процедура изменения#

1. Отредактируйте конфигурационный файл scheduler-server.conf;

2. Добавьте/измените параметры:

# Максимальная длительность (15 минут)
SCHD_SERVER_JOB_RESPONSE_TIMEOUT_MAX=900
# Стандартная длительность (15 минут)
SCHD_SERVER_JOB_RESPONSE_TIMEOUT_DEFAULT=PT900S

3. Сохраните файл и перезапустите сервис;

4. Проверьте применение параметров.

Настройка параметров идемпотентности#

Описание#

Параметры конфигурации SCHD_SERVER_IDEMPOTENT_WINDOW, SCHD_SERVER_IDEMPOTENT_WINDOW_REFRESH_JOB_ENABLED, SCHD_SERVER_IDEMPOTENT_WINDOW_REFRESH_JOB_INTERVAL, SCHD_SERVER_IDEMPOTENT_WINDOW_REFRESH_JOB_INIT_DELAY и SCHD_SERVER_IDEMPOTENT_WINDOW_REFRESH_BATCH_SIZE управляют поведением идемпотентного окна.
Настройки влияют на:

• Временной интервал, в течение которого операции считаются идемпотентными.

• Автоматическое обновление окна для предотвращения дублирования операций.

Параметры конфигурации#

1. SCHD_SERVER_IDEMPOTENT_WINDOW#

Назначение: Определяет длительность временного окна, в рамках которого повторные операции считаются идемпотентными.

Формат: Время в формате ISO 8601 (например, PT1M — 1 минута).

Примеры допустимых значений:

SCHD_SERVER_IDEMPOTENT_WINDOW=PT5M    # 5 минут  
SCHD_SERVER_IDEMPOTENT_WINDOW=PT30M  # 30 минут  

Особенности:

• Значение по умолчанию: PT1M.

• Применяется ко всем операциям в системе.

2. SCHD_SERVER_IDEMPOTENT_WINDOW_REFRESH_JOB_ENABLED#

Назначение: Активирует фоновую задачу для автоматического обновления идемпотентного окна.

Формат: true (включено) / false (выключено).

Примеры:

SCHD_SERVER_IDEMPOTENT_WINDOW_REFRESH_JOB_ENABLED=true  

Особенности:

• При отключении (false) возможны дублирующиеся операции.

3. SCHD_SERVER_IDEMPOTENT_WINDOW_REFRESH_JOB_INTERVAL#

Назначение: Задает интервал запуска задачи обновления окна.

Формат: Время в формате ISO 8601 (например, PT10M — 10 минут).

Примеры:

SCHD_SERVER_IDEMPOTENT_WINDOW_REFRESH_JOB_INTERVAL=PT15M  # 15 минут  

Особенности:

• Частые обновления повышают надежность, но увеличивают нагрузку.

4. SCHD_SERVER_IDEMPOTENT_WINDOW_REFRESH_JOB_INIT_DELAY#

Назначение: Определяет задержку перед первым запуском задачи обновления после старта сервиса.

Формат: Время в формате ISO 8601 (например, PT30S — 30 секунд).

Примеры:

SCHD_SERVER_IDEMPOTENT_WINDOW_REFRESH_JOB_INIT_DELAY=PT30S  

Особенности:

• Позволяет избежать конфликтов при инициализации системы.

5. SCHD_SERVER_IDEMPOTENT_WINDOW_REFRESH_BATCH_SIZE#

Назначение: Указывает количество записей, обрабатываемых за один цикл обновления.

Формат: Целое число ≥ 1.

Примеры:

SCHD_SERVER_IDEMPOTENT_WINDOW_REFRESH_BATCH_SIZE=2000  

Особенности:

• Большой размер ускоряет обработку, но требует больше ресурсов.

Рекомендации по настройке#

1. Соотношение параметров:

   • Интервал обновления (REFRESH_JOB_INTERVAL) должен быть меньше или равен длительности окна (IDEMPOTENT_WINDOW).

2. Оптимальные значения:

   • Для систем с высоким трафиком:

     • IDEMPOTENT_WINDOW=PT5M, REFRESH_JOB_INTERVAL=PT5M, BATCH_SIZE=2000.

   • Для систем с редкими операциями:

     • IDEMPOTENT_WINDOW=PT30M, REFRESH_JOB_INTERVAL=PT15M, BATCH_SIZE=500.

3. Безопасность:

   • Не устанавливайте IDEMPOTENT_WINDOW больше 24 часов (PT24H).

   • Минимальное значение BATCH_SIZE — 10 для избежания избыточной нагрузки.

Процедура изменения#

1. Откройте конфигурационный файл scheduler-server.conf.

2. Добавьте или измените параметры:

# Идемпотентное окно (5 минут)  
SCHD_SERVER_IDEMPOTENT_WINDOW=PT5M  
# Включение задачи обновления  
SCHD_SERVER_IDEMPOTENT_WINDOW_REFRESH_JOB_ENABLED=true  
# Интервал обновления (15 минут)  
SCHD_SERVER_IDEMPOTENT_WINDOW_REFRESH_JOB_INTERVAL=PT15M  
# Задержка перед первым запуском (30 секунд)  
SCHD_SERVER_IDEMPOTENT_WINDOW_REFRESH_JOB_INIT_DELAY=PT30S  
# Размер пакета (2000 записей)  
SCHD_SERVER_IDEMPOTENT_WINDOW_REFRESH_BATCH_SIZE=2000  

3. Сохраните файл и перезапустите сервис:

systemctl restart scheduler-server  

4. Проверьте применение настроек:

   • В логах сервиса ищите сообщения об успешной инициализации параметров.

   • Убедитесь, что задачи обновления выполняются по расписанию.

Типичные проблемы и решения#

Примечание: Для динамического изменения параметров (без перезапуска) убедитесь, что сервис поддерживает hot-reload конфигурации.

Настройка часового пояса по умолчанию#

Описание#

Параметр конфигурации SCHD_DEFAULT_TIME_ZONE определяет часовой пояс, используемый по умолчанию для всех новых тенантов и заданий.
Влияет на:

• Создание новых тенантов/заданий без явного указания тайм-зоны.

• Расписание выполнения задач для стендов, где тайм-зона не задана явно.

Параметр конфигурации#

SCHD_DEFAULT_TIME_ZONE#

Назначение:
Устанавливает региональный часовой пояс для системы.

Формат:
Имя зоны из директории /usr/share/zoneinfo (например, Europe/Moscow, America/New_York).

Допустимые значения:

# Примеры доступных зон:
ls /usr/share/zoneinfo/
Africa      CET    EST      GMT-0      Japan      MST7MDT  Poland     UTC
America    Chile  EST5EDT  GMT+0      Kwajalein  Navajo   Portugal   WET
...

Примеры:

SCHD_DEFAULT_TIME_ZONE=Europe/London     # Лондон (UTC+0/+1)
SCHD_DEFAULT_TIME_ZONE=Asia/Tokyo       # Токио (UTC+9)
SCHD_DEFAULT_TIME_ZONE=America/Los_Angeles # Лос-Анджелес (UTC-8/-7)

Особенности:

• Значение по умолчанию: Europe/Moscow (UTC+3).

• Применяется только к новым сущностям (тенантам/заданиям).

• Для существующих тенантов изменения не затрагивают уже назначенные time_zone.

Рекомендации по настройке#

1. Согласованность с инфраструктурой:

   • Используйте тот же часовой пояс, что и у связанных систем (логирование, мониторинг).

   • Для глобальных сервисов предпочтительнее UTC.

2. Региональные требования:

   • Учитывайте локацию пользователей (например, Europe/Berlin для EU, Asia/Dubai для Ближнего Востока).

3. Летнее время:

   • Выбирайте зоны с автоматическим переходом (например, Europe/Paris вместо CET).

Процедура изменения#

1. Откройте конфигурационный файл:

   nano /etc/scheduler/scheduler-server.conf
   

2. Добавьте/измените параметр:

   # Часовой пояс по умолчанию (Токио)
   SCHD_DEFAULT_TIME_ZONE=Asia/Tokyo
   

3. Примените изменения:

   systemctl restart scheduler-server
   

4. Проверка:

   • Создайте нового тенанта без явного указания time_zone.

   • Убедитесь, что в БД поле time_zone соответствует новому значению:

     SELECT name, time_zone FROM resource_name WHERE created_at > NOW() - INTERVAL '5 minutes';
     

Типичные проблемы и решения#

Дополнительные примечания#

• Hot-reload: Изменения применяются только после перезапуска сервиса.

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

  UPDATE resource_name SET time_zone = EXTRACT(TIMEZONE_HOUR FROM NOW() AT TIME ZONE 'Новая_зона') * 60 
  WHERE time_zone IS NULL;
  

• Синхронизация с ОС: Убедитесь, что системное время сервера совпадает с выбранной зоной (timedatectl status).

Настройка календарей#

Описание#

Интеграционная часть (загрузка календарей) настраивается с помощью следующих параметров конфигурации:

• SCHD_CALENDAR_ADAPTER_NSI_ROOT_HOST,

• SCHD_SE_NSI_PROTOCOL,

• SCHD_SE_NSI_PORT,

• SCHD_SE_NSI_TLS_MODE,

• SCHD_SE_NSI_TIMEOUT,

• SCHD_SE_NSI_RETRIES_ATTEMPTS,

• SCHD_SE_NSI_PER_TRY_TIMEOUT,

• SCHD_SE_NSI_RETRY_ON.

Данные параметры находятся в файле batch-scheduler.istio.all.conf. Описание каждого параметра приведено в описании конфигурационных параметров.

Период очистки календарей задается параметром конфигурации SCHD_GC_CALENDAR_CLEANPERIOD, находящемся в файле scheduler-gc.conf. Описание приведено в описании конфигурационных параметров.

В файле custom_property.yml настраивается управление глубиной хранения (количество лет) календаря в разрезе тенанта путем установки в блоке настроек tenants свойства calendar_storage_depth.

В файле custom_property.yml настраивается признак проверки (логика) календаря в разрезе тенанта путем установки в блоке настроек tenants свойства launch_without_calendar. Если признак включен - при планировании времени следующего запуска календарь не принимается во внимание, т.е не проверяется совпадения типа планового дня по календарю с типом, указанным в настройке задания launchDayType. Если признак выключен - календарь учитывается и проверка выполняется.

Пример заполнения:

# Блок добавления тенантов
tenants:
- name: httptarget
  module_id: httptarget
  calendar_source_id: API
  working_area_code: RU
  calendar_storage_depth: 3
  launch_without_calendar: false