Сценарий установки при помощи запуска Ansible плейбука

Сведения

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

Подготовка к установке

примечание

Для корректной работы скриптов автоматизации необходимо, чтобы на целевых узлах (master/replica/arbiter) у скриптов автоматизации была возможность доступа к rpm/deb-пакетам каждого участвующего в обновлении или первичном развертывании компонента. Для организации данного доступа во время установки будет создан локальный репозиторий со всеми возможными rpm/deb-пакетами дистрибутива, в том числе с rpm/deb-пакетами из 3rd Party части дистрибутива. Данный репозиторий не подвергается процессу удаления после окончания установки Pangolin.

Выполните следующие действия:

1. Подготовьте конфигурационные файлы:
   1. Заполните inventory-файл.
   2. Заполните конфигурационный YAML файл.
2. Активируйте логирование инсталлятора (опционально).
3. Подберите сценарий установки из примеров или сформируйте собственный сценарий при развертывании.
4. Запустите процесс установки.
5. Ознакомьтесь с дальнейшими шагами после завершения процесса установки.

Подсказка

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

Шаг 1. Подготовка конфигурационных файлов

Шаг 1.1. Заполнение inventory-файлов

Заполните inventory-файл в зависимости от конфигурации установки.

Файл hosts.ini заполняется в соответствии с шаблоном:

• для standalone находится по пути: installer/inventories/standalone/hosts.ini;
• для cluster находится по пути: installer/inventories/cluster/hosts.ini.

Файл hosts.ini состоит из нескольких групп (имена определены в скобках), которые используются для классификации и определения того, какие хосты будут использоваться. Для установки необходимо заполнить переменные группы postgres_nodes и arbiter_nodes (для кластерной конфигурации):

• ansible_host — в случае установки по IP-адресу, укажите ip_address, в случае установки по имени DNS укажите hostname;
• ansible_user — имя пользователя для использования при подключении к хосту. Должен иметь права для эскалации до root, то есть должен иметь возможность выполнять все команды от имени root;
• переменная ansible_password должна содержать пароль пользователя в чистом виде или имя переменной, которая будет содержать засекреченный с помощью ansible-vault пароль.

Внимание!

Пароль пользователя следует указывать в кавычках для того, чтобы избежать конфликтов при цитировании специальных символов. Пользователь, указанный в файле hosts.ini, должен обладать правами sudo + nologin.

Ниже представлены примеры файла hosts.ini для standalone и cluster архитектур.

hosts.ini для standalone-конфигурации

[standalone:children]
postgres_group

[postgres_group:children]
postgres_nodes

[postgres_group:vars]
ansible_connection=ssh

[postgres_nodes]
master  ansible_host=<IP-address>  ansible_user=<user>   ansible_password="<password>"

hosts.ini для кластерной конфигурации

[cluster:children]
postgres_group
arbiter_group

[postgres_group:children]
postgres_nodes

[arbiter_group:children]
arbiter_nodes

[postgres_group:vars]
ansible_connection=ssh

[arbiter_group:vars]
ansible_connection=ssh

[postgres_nodes]
master   ansible_host=<IP-address>  ansible_user=<user>   ansible_password="<password>"
replica  ansible_host=<IP-address>  ansible_user=<user>   ansible_password="<password>"

[arbiter_nodes]
arbiter  ansible_host=<IP-address>  ansible_user=<user>   ansible_password="<password>"

примечание

Нельзя менять в inventory имена узлов (master, replica, arbiter). В блоке arbiter_nodes указываются серверы, которые только участвуют в кластере etcd или Pangolin DCS, но не являются master или replica.

Засекречивание паролей (опционально)

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

• Если в файле hosts.ini переменная ansible_password содержит ansible-vault, то пароль необходимо засекретить. Ниже приведен пример засекреченного текста passwordtest с помощью ansible-vault:

  ansible-vault encrypt_string passwordtest
  New Vault password:
  Confirm New Vault password:
  !vault |
      $ANSIBLE_VAULT;1.1;AES256
      {password_encrypted}
  Encryption successful

• В случае, когда пароли для хостов групп postgres_group и arbiter_group совпадают, достаточно вывод команды ansible-vault поместить в inventory-файл сluster.yml/standalone.yml, расположенный в каталоге inventories/(standalone || cluster)/group_vars. Аналогичным образом необходимо перезасекретить пароли в файле custom_file_sample.yml (пример файла доступен в личном кабинете) тем же ключом, которым был засекречен пароль для учетной записи в текущем шаге.

Узнать подробнее о Ansible inventory можно в документации Ansible.

Шаг 1.2. Заполнение файла конфигурации custom_config_sample.yml

Пример конфигурационного файла custom_config_sample.yml, который можно использовать для развертывания продукта со значениями по умолчанию или с минимальными корректировками, находится в каталоге дистрибутива по пути: installer/templates/custom_config_sample.yml.

Поскольку custom_config_sample.yml является примером и вариантом готового решения, некоторые секции и параметры были перенесены в custom_config_initial.yml - конфигурационный файл, содержащий все динамически настраиваемые параметры СУБД Pangolin. Переопределите необходимые параметры в файле custom_config_sample.yml.

Рекомендуется ознакомиться с примером и описанием заполнения конфигурационного файла custom_config_initial.yml (раздел доступен в личном кабинете).

Подсказка

Заполните параметр postgres_db_pass в файл конфигурации для указания пароля пользователя postgres.

Изменение паролей по умолчанию

Замените необходимые пароли установленные по умолчанию в следующих разделах и параметрах при конфигурировании файла custom_config_initial.yml, в зависимости от предполагаемой конфигурации СУБД:

    # 3. INSTALL AND UPDATE
    
    pangolin_dcs_rest_api:
        dcs_root_password: <Пароль>                     # Пароль администратора Pangolin REST API
        dcs_client_password: <Пароль>                   # Пароль клиента Pangolin REST API
    
    patroni_yml.etcd.password: <Пароль>                 # Пароль для подключения etcd
    
    # 3.1 HBA RULES
    
    ldap_bind_tuz_password: <Пароль>                    # Пароль ТУЗ для ldap
    
    # 3.2. SECURITY SETTINGS (SSL)
    
    pg_certs_pwd:
       pg.server_p12.p12_pass: <Пароль>                 # Пароль хранилища p12 для серверного сертификата
       pgbouncer:
         server_p12.p12_pass: <Пароль>                  # Пароль хранилища p12 для серверного сертификата
         client_p12.p12_pass: <Пароль>                  # Пароль хранилища p12 для сертификата pgbouncer
       patroni:
         server_p12.p12_pass: <Пароль>                  # Пароль хранилища p12 для серверного сертификата
         client_p12.p12_pass: <Пароль>                  # Пароль хранилища p12 для сертификата patroni
       pangolin_dcs.p12.p12_pass: <Пароль>              # Пароль хранилища p12 для серверного сертификата
       pangolin_dcs_rest_api.p12.p12_pass: <Пароль>     # Пароль хранилища p12 для серверного сертификата
    
    # 3.6. PASSWORDS
    
    pgbouncer_scram_password: SCRAM-SHA-256$4096:<Хеш>       # Пароль pgbouncer, зашифрованный с использованием SCRAM-SHA-256
    postgres_linux_pass: <Хеш>                               # Хеш пароля пользователя postgres
    kmadmin_pg_linux_pass: <Хеш>                             # Хеш пароля пользователя kmadmin_pg
    postgres_db_pass: <Пароль>                               # Пароль базы данных Postgres
    patroni_password: <Пароль>                               # Пароль Patroni
    pg_backup_user_passwd: <Пароль>                          # Пароль pg_backup_user
    patroni_yml_pass: <Пароль>                               # Пароль patroniyml

Адаптация файла конфигурации СУБД

При запуске Ansible плейбука (playbook_install.yml) утилита Pangolin Tuner будет запущена автоматически. Она определяет оптимальные конфигурационные настройки в зависимости от профиля рабочей нагрузки.

Обязательным параметром для заполнения является путь к файлу конфигурации: tuner_config. Дополнительно выберите необходимый профиль нагрузки, каждый из которых адаптирован под конкретные потребности и использует оптимальные значения параметров, и пропишите его в значение конфигурационного параметра tuner_profile. В ином случае, по умолчанию будет использован профиль OLTP:

   #################################################### PANGOLIN TUNER ###############################################
   tuner_config: "/pgdata/data/data/postgresql.conf"
   tuner_profile: olap

Подсказка

При необходимости адаптированной конфигурации для интеграции с системой 1C:Предприятие используйте профиль 1C.

Заполнение пути до лицензии

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

При запуске установки (на будущем шаге) важно заполнить переменную pangolin_license_path, которая задает путь к директории содержащей лицензии или путь к конкретному файлу лицензии. Например, pangolin_license_path=/home/admin/license_trial.json. Имя файла значения не имеет.

Данная переменная окружения используется самим сервером и его утилитами для получения данных об используемой лицензии. Предпочтительно использовать директорию по пути /opt/pangolin_license.

Примечание

Инсталлятор будет проверять валидность лицензии пяти основных типов:

• license_standard_1C;
• license_standard;
• license_enterprise_1C;
• license_enterprise;
• license_trial.

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

Использование сертификатов (опционально)

Сведения

При использовании функциональности работы с сертификатами между компонентов и/или сертификатами PKCS#12 необходимо обратить внимание на параметры mtls_support и pkcs12_plugin_enable.

Сгенерируйте сертификаты, в случае, если в настраиваемом конфигурационном файле выше было выставлено значение для параметра: mtls_support: true и/или pkcs12_plugin_enable: true:

• Если активирован параметр pkcs12_plugin_enable: true, то сертификаты должны быть сгенерированы в формате PKCS#12 или будут получены из Secret Management System (далее – SecMan), в зависимости от заполненных значений в пользовательском конфигурационном файле. Подробнее читайте в документе «Руководство администратора», раздел «Использование сертификатов PKCS#12 в кластере Pangolin».

  Для поиска или генерации сертификата в SecMan необходимо активировать параметр use_remote_pki: true и заполнить атрибуты в разделе p12_secman: для каждого сертификата.

• При включенном параметре (mtls_support: true) скрипты развертывания и обновления продукта определяют расположение сертификатов через пути параметров соответствующего компонента (параметры из секции «3.2. НАСТРОЙКИ БЕЗОПАСНОГО ПОДКЛЮЧЕНИЯ (SSL)» custom_config_initial.yml) и проверяют их наличие (раздел с описанием параметров конфигурационного файла доступен в личном кабинете).

  Если сертификат отсутствует по указанному пути, то будет выведена блокирующая ошибка. Пример:

  "{{ control_name }}.FAIL__Файл сертификата 'root.crt' не найден на хосте. Проверьте наличие файла и значение в пользовательском конфигурационном файле - 'custom_config_sample.yml'__{{ control_name }}.FAIL"

  Ниже приведен пример скрипта для генерации сертификатов и распространения их на указанные виртуальные машины:

  Генерация сертификатов

  #!/bin/sh
  # IP/DNS-записи хостов.
  hosts_list=(127.0.0.1 127.0.0.2 127.0.0.3)
  # Пароль пользователя с root правами.
  ssh_password=(TestPassword!)
  # Пользователь с root-правами.
  ssh_user=(admin_dev)
  mkdir ssl
  cd ssl
  
  openssl req -new -nodes -text -out ./root.csr -keyout ./root.key -subj "/CN=PGSEdevCA"
  openssl x509 -req -in ./root.csr -text -days 3650  -extfile /etc/pki/tls/openssl.cnf -extensions v3_ca -signkey ./root.key -out ./root.crt
  openssl req -new -nodes -text -out ./client.csr -keyout ./client.key -subj "/CN=postgres"
  openssl x509 -req -in ./client.csr -text -days 3650 -CA ./root.crt -CAkey ./root.key -CAcreateserial -out ./client.crt
  openssl req -new -nodes -text -out ./patroni.csr -keyout ./patroni.key -subj "/CN=patroni"
  openssl x509 -req -in ./patroni.csr -text -days 3650 -CA ./root.crt -CAkey ./root.key -CAcreateserial -out ./patroni.crt
  openssl req -new -nodes -text -out ./patronietcd.csr -keyout ./patronietcd.key -subj "/CN=patronietcd"
  openssl x509 -req -in ./patronietcd.csr -text -days 3650 -CA ./root.crt -CAkey ./root.key -CAcreateserial -out ./patronietcd.crt
  openssl req -new -nodes -text -out ./pgbouncer.csr -keyout ./pgbouncer.key -subj "/CN=pgbouncer"
  openssl x509 -req -in ./pgbouncer.csr -text -days 3650 -CA ./root.crt -CAkey ./root.key -CAcreateserial -out ./pgbouncer.crt
  rm *.csr
  
  ######Copy_certs_on_nodes_and_generate_server_cert
  for host in ${hosts_list[@]}
  do
  sshpass -p ${ssh_password} ssh -o StrictHostKeyChecking=no -p 22 ${ssh_user}@${host} 'sudo rm -rf /pg_ssl && sudo mkdir /pg_ssl && sudo chown $(whoami):$(whoami) /pg_ssl'
  sshpass -p ${ssh_password} scp ./* ${ssh_user}@${host}:/pg_ssl
  sshpass -p ${ssh_password} ssh -o StrictHostKeyChecking=no -p 22 ${ssh_user}@${host} 'cat << EOT >> /pg_ssl/server.conf
  [req]
  req_extensions = v3_req
  distinguished_name = req_distinguished_name
  [req_distinguished_name]
  [ v3_req ]
  basicConstraints = CA:FALSE
  keyUsage = nonRepudiation, digitalSignature, keyEncipherment
  subjectAltName = @alt_names
  [ ssl_client ]
  extendedKeyUsage = clientAuth, serverAuth
  basicConstraints = CA:FALSE
  subjectKeyIdentifier=hash
  authorityKeyIdentifier=keyid,issuer
  subjectAltName = @alt_names
  [ v3_ca ]
  basicConstraints = CA:TRUE
  keyUsage = nonRepudiation, digitalSignature, keyEncipherment
  subjectAltName = @alt_names
  authorityKeyIdentifier=keyid:always,issuer
  [alt_names]
  EOT'
  
  sshpass -p ${ssh_password} ssh -o StrictHostKeyChecking=no -p 22 ${ssh_user}@${host} 'cd /pg_ssl && echo DNS.1 = $(hostname -f) >> server.conf && echo IP.1 = $(hostname -i) >> server.conf && openssl req -new -nodes -text -out ./server.csr -keyout ./server.key -subj "/CN=$(hostname -f)" -config $(echo ./server.conf)'
  sshpass -p ${ssh_password} ssh -o StrictHostKeyChecking=no -p 22 ${ssh_user}@${host} 'cd /pg_ssl && openssl x509 -req -in ./server.csr -text -days 3650 -CA ./root.crt -CAkey ./root.key -CAcreateserial -out ./server.crt -extensions ssl_client -extfile $(echo ./server.conf)'
  sshpass -p ${ssh_password} ssh -o StrictHostKeyChecking=no -p 22 ${ssh_user}@${host} 'sudo chmod 0600 /pg_ssl/*.key && sudo chmod 0644 /pg_ssl/*.crt'
  
  ###/etc/pki/ca-trust/source/anchors/ - 'RedHat' /etc/pki/tls/openssl.cnf\ - 'Altlinux' ###
  sshpass -p ${ssh_password} ssh -o StrictHostKeyChecking=no -p 22 ${ssh_user}@${host} 'sudo cp /pg_ssl/root.crt /etc/pki/ca-trust/source/anchors/ && sudo update-ca-trust'
  done

  Данные сертификаты не будут подписаны, но будут являться минимальными требуемыми для установки. После установки продукта Pangolin необходимо подписать данные сертификаты в удостоверяющем центре (подробная информация о генерации сертификатов в документе «Руководство администратора», раздел «Генерация сертификатов»).

примечание

Скрипты развертывания не осуществляют проверку валидности сертификатов.

Установка с фиксированным UID/GID для пользователей (опционально)

Сведения

Начиная с версии 6.3.0 была добавлена возможность установки с фиксированным UID/GID для пользователей.

Добавлены параметры:

• kmadmin_user_group.is_enabled: переменная типа boolean, служащая для включения функциональности. Значение True принимается как флаг активации - в этом случае пользователь будет создан с указанными значениями UID/GID. По умолчанию используется значение False;
• pangolin_users_group.is_enabled: переменная типа boolean, включение функциональности для группы pangolin_users_group;
• pangolin_users_group.group_gid: переменная типа int, определяющая GID для группы pangolin_users_group. Значение по умолчанию: 226;
• kmadmin_user_group.group_gid: целочисленная переменная, содержащая значение GID для пользователя группы. По умолчанию используется значение 126.
• kmadmin_user_group.user_uid: целочисленная переменная, содержащая значение UID для пользователя. По умолчанию используется значение 126.

При развертывании из rpm/deb-пакетов функциональность активируется через объявление соответствующих переменных окружения.

Например, для пользователя kmadmin_pg перед установкой из пакета задаются $KMADMIN_PG_USER_GUID и $KMADMIN_PG_GROUP_GUID для UID/GID. Объявление (наличии в пространстве имен) этих переменных включает функциональность, при этом UID/GID берутся из заданных значений.

Если переменные не определены, значение для UID/GID выбираются из доступных.

Установка без наличия DNS сервера на устанавливаемых узлах

Начиная с версии 6.4.2, был добавлен параметр used_fqdn_host, отвечающий за установку СУБД Pangolin в средах, где не предусмотрен DNS-сервер. По умолчанию данный параметр активен (true), и скрипты автоматизации будут использовать DNS-сервер для установки продукта.

В случае наличия A-записи, равной DNS-имени hostname проверить работоспособность DNS-сервера можно командой dig hostname с узла, на котором будет запускаться ansible.

Пример:

➜  ~ dig <host_name>

; <<>> DiG 9.10.6 <<>> <host_name>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27230
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;<host_name>.          IN      A

;; ANSWER SECTION:
<host_name>.   3600    IN      A       {ip-address}

В случае отсутствия А-записи или наличия записи, не соответствующей имени hostname, нужно выключить параметр used_fqdn_host (установить в значение false). Далее запустить установку СУБД Pangolin. Результатом данных действий будет установленный продукт в кластерной или standalone-конфигурации с использованием IP-адресов вместо DNS-записи.

При установке параметр следует отключить в конфигурационном файле, установив его значение в false:

used_fqdn_host: false

Подсказка

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

Шаг 2. Логирование инсталлятора (опционально)

Для активации логирования работы инсталлятора необходимо прописать путь для лог-файла, который фиксирует логи процесса установки. Для этого выполните команду:

export ANSIBLE_LOG_PATH=<path>/ansible.log

Примеры сценариев возможных вариантов установки

В разделе приведены примеры сценариев возможных вариантов установки Pangolin.

Сценарий установки кластерного решения Pangolin с Pangolin Manager, etcd, Pangolin Pooler

Пример заполненной команды для запуска playbook_install.yaml в случае сценария cluster-установки Pangolin:

ansible-playbook -vvv playbook_install.yaml \
-i inventories/cluster/hosts.ini \
-t cluster-patroni-etcd-pgbouncer  \
-e '{"as_admins":['admin_1', 'admin_2']}' \
-e '{"as_TUZ":['tuz_1']}' \
--flush-cache \
--extra-vars 'local_distr_path=/home/user/distributive \
installation_type=cluster \
PGDATA=/pgdata/06/data \
PGLOGS=/pgerrorlogs/06 \
tablespace_name=tbl_name \
tablespace_location=/pgdata/06/tablespaces \
schema_name=shema \
db_name=first_db \
clustername=<clustername> \
custom_config=templates/custom_config_sample.yml \
nolog=true \
pangolin_license_path=/home/user/license_trial.json'

Обозначения

Значения используемых в команде запуска сценария ключей:

• -i — путь к inventory-файлу;
• -t — теги для запуска;
• -vvv — уровень логирования Ansible. Может быть, как пустым, так и -vvvvvv, где запуск без v - минимальное логирование;
• -e, --extra-vars — переменные, которые по приоритету важнее переменных из inventory.

Используемые переменные:

• as_admins — Active Directory логин или логины будущих администраторов АС. Если логинов несколько, то они указываются через запятую, без пробелов. Например, -e '{"as_admins":['admin, test_admin]}';
• as_TUZ — логины ТУЗ, которые будут созданы в результате установки. Если логинов несколько, то они указываются через запятую, без пробелов. Например, -e '{"as_TUZ":['tuz, test_tuz]}';
• tablespace_name — имя табличного пространства, которое будет создано в результате установки;
• tablespace_location — полный путь к каталогу, где будет расположено созданное табличное пространство;
• schema_name — имя схемы, которая будет создана в результате установки;
• db_name — имя базы данных, которая будет создана в результате установки;
• local_distr_path — абсолютный путь к загруженному и распакованному дистрибутиву Pangolin;
• custom_config — абсолютный путь к файлу конфигурации custom_config_sample.yml;
• pangolin_license_path — путь к директории, которая содержит лицензии или путь к конкретному файлу лицензии;
• nolog - скрытие логов во время установки.

Внимание!

В случае, если необходимо развернуть стенд с дополнительными настройками ролевой модели, пользовательской БД, схемами и расширениями необходимо отдельно запустить playbook_configure_roles.yaml или sh-скрипт run_configure.sh развертывания ролевой модели, который располагается в компоненте installer по пути scripts_external/configure_roles/configure_roles/templates/role_BASIC/run_configure.sh. Ролевая модель и скрипты ее настройки описаны в документе «Администрирование функциональностей».

Сценарий развертывания дополнительных настроек ролевой модели, пользовательской БД и расширений с помощью ansible-роли

Пример команды запуска сценария базовой ролевой модели:

ansible-playbook playbook_configure_roles.yaml \
-i inventories/cluster/hosts.ini \
-t cluster-patroni-etcd-pgbouncer \
-vv \
-e '{"as_admins":['test_admin']}' \
-e '{"as_TUZ":['test_tuz']}' \
--extra-vars 'local_distr_path=/home/user/distributive \
PGDATA=/pgdata/06/data \
PGLOGS=/pgerrorlogs/06 \
tablespace_name=tbl_name \
tablespace_location=/pgdata/06/tablespaces \
schema_name=shema \
db_name=first_db \
custom_config=templates/custom_config_sample.yml' \
--ask-vault-pass

Обозначения

Используемые в команде переменные:

• as_admins — Active Directory логин или логины будущих администраторов АС. Если логинов несколько, то они указываются через запятую, без пробелов. Например, -e '{"as_admins":['admin, test_admin]}';
• as_TUZ — логины ТУЗ, которые будут созданы в результате установки. Если логинов несколько, то они указываются через запятую, без пробелов. Например, -e '{"as_TUZ":['tuz, test_tuz]}';
• local_distr_path — абсолютный путь к загруженному и распакованному дистрибутиву Pangolin;
• PGDATA — полный путь к каталогу, где будет расположена инициализированная база данных;
• PGLOGS — полный путь к каталогу, где будут расположены логирующие файлы;
• tablespace_name — имя табличного пространства, которое будет создано в результате установки;
• tablespace_location — полный путь к каталогу, где будет расположено созданное табличное пространство;
• schema_name — имя схемы, которая будет создана в результате установки;
• db_name — имя базы данных, которая будет создана в результате установки;
• custom_config — абсолютный путь к файлу конфигурации custom_config_sample.yml;
• --ask-vault-pass или --vault-password-file — рассекречивание преобразованных файлов во время выполнения (опционально).

Внимание!

В случаях, если:

• все пароли указывались в открытом виде, параметр --ask-vault-pass и --vault-password-file='name_file_with_key' добавлять не нужно.
• не планируется использовать custom_config — есть возможность настройки параметров запуска через файл variables.yml, расположенный в роли configure_roles (scripts_external/configure_roles/group_vars/variables.yml).

Cценарий развертывания дополнительных настроек ролевой модели, пользовательской БД и расширений с помощью запускаемого bash-скрипта

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

sh ./role_BASIC/run_configure.sh -d First_db -s Sch1 -t Tbl_t -l /pgdata/06/tablespaces -m <IP-Address> -r <IP-Address> -p <Port> -a 'user1 user2' -u 'user3 user4' -w /home/postgres/role_BASIC -c "0,30 * * * *" -g  "'as_admin_pass':SCRAM-SHA-256$4096:{hash} 'as_tuz_pass':SCRAM-SHA-256$4096:{hash} -f "'pg_profile':True 'rotate_password':True 'psql_lockmon_is_enable':True"  -e 'infinity' -v 'TEMPORARY' -k 'backup_user' -z false -o 'en_US.UTF-8' -n 'postgres'

Обозначения

Используемые в команде переменные:

• d, dbname – имя пользовательской БД;
• s, schname – имя пользовательской схемы;
• t, tsname – имя пользовательского табличного пространства;
• l, tsloc - путь к табличному пространству;
• m, mhost - IP-адрес хоста мастера (данный параметр является обязательным, так как используется для настройки расписания pg_cron);
• r, rhost IP-адрес хоста реплики (данный параметр является обязательным, так как используется для настройки расписания pg_cron);
• p, port - порт PostgreSQL;
• a, asadm – список ТУЗ as_admin;
• u, astuz - список ТУЗ as_TUZ;
• w, way - путь к папке со скриптами конфигурирования (данный параметр является обязательным);
• c, cronp - период времени для cron job pg_profile;
• g, grpas - список паролей для УЗ (передается в виде словаря, например: as_admin_pass':passwd1 'zabbix_pass':passwd2);
• f, fchlst - список включаемой функциональности при развертывании (передается в виде словаря, например: 'pg_profile':True 'rotate_password':False);
• e, expdt - параметр времени жизни УЗ (expire date);
• v, vrpas - флаг, указывающий на использование временных паролей;
• k, backusname - имя пользователя для резервного копирования (по умолчанию backup_user);
• z, tdeadm - включить/выключить TDE;
• o, locale - параметр для определения locale при создании пользовательской БД (должен совпадать с параметром, установленным при развертывании);
• n, prdbname - имя пользовательской БД, где будет создан pg_profile.

Запуск сценария установки

примечание

На начальном этапе установки любой схемы Pangolin проводятся проверки корректности переданных на вход инсталлятору значений. Например, к таким проверкам относится проверка того, что при задании параметров tablespace_name, db_name, schema_name, as_admins, as_TUZ нельзя использовать префикс pg_, так как данный префикс зарезервирован системой для своих нужд.

1. Заполните параметры, заключенные в < >, запустите playbook_install.yaml из директории installer дистрибутива продукта:

   Обозначения

   Значения используемых в команде запуска сценария ключей:

   • -i — путь к inventory-файлу;

   • -t — теги для запуска;

   • -vvv — уровень логирования Ansible. Может быть, как пустым, так и -vvvvvv, где запуск без v - минимальное логирование;

   • -e, --extra-vars — переменные, которые по приоритету важнее переменных из inventory.

   Параметры для самостоятельного заполнения:

   • <cluster||standalone> - выбор нужной конфигурации: cluster или standalone;

   • <configuration> - выбор сценария: cluster-patroni-etcd-pgbouncer или standalone-postgresql-pgbouncer;

   • <clustername> - наименование кластера;

   • <path_to_distributive> - путь к загруженному и распакованному дистрибутиву Pangolin;

   • <base_version> - базовая версия Pangolin (текущая: 6).

   Используемые переменные:

   • as_TUZ — логины ТУЗ, которые будут созданы в результате установки. Если логинов несколько, то они указываются через запятую, без пробелов. Например, -e '{"as_TUZ":['tuz, test_tuz]}' (опционально);
   • local_distr_path — абсолютный путь к загруженному и распакованному дистрибутиву Pangolin;
   • custom_config — абсолютный путь к файлу конфигурации custom_config_sample.yml;
   • pangolin_license_path — путь к директории, которая содержит лицензии или путь к конкретному файлу лицензии;
   • nolog - скрытие логов во время установки.

   ansible-playbook -vvv playbook_install.yaml \
   -i inventories/<cluster||standalone>/hosts.ini \
   -t <configuration>  \
   -e '{"as_TUZ":['tuz_1']}' \
   --flush-cache \
   --extra-vars 'local_distr_path=<path_to_distributive> \
   installation_type=<cluster||standalone> \
   PGDATA=/pgdata/0<base_version>/data \
   PGLOGS=/pgerrorlogs/0<base_version> \
   clustername=<clustername> \
   custom_config=templates/custom_config_sample.yml \
   pangolin_license_path=/home/user/license_trial.json \
   nolog=true'
   Внимание!

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

   • /pgdata/data -> /pgdata/0<base_version>
   • /usr/pangolin -> /usr/pangolin-<product_version>

2. Дождитесь окончания установки и деактивируйте виртуальное окружение:

   deactivate

Дальнейшие шаги

примечание

На конечном этапе установки любой схемы Pangolin происходят следующие автоматические проверки:

• консистентность состава установки;
• наличие документации;
• проверка конфигурационных файлов всех сервисов;
• интерфейсные проверки всех сервисов.

Для проверки успешности завершения установки рекомендуется обратиться к шагам «Проверки результата» в общем блоке автоматизированной установки.