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

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

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

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 архитектур.

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

[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 (раздел доступен в личном кабинете).

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

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

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

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

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

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

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

pangolin_license_path - полный путь к файлу лицензии, например, pangolin_license_path=/home/admin/license_trial.json. Имя файла значения не имеет.

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

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

Сгенерируйте сертификаты, в случае, если в настраиваемом конфигурационном файле выше было выставлено значение для параметра: 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 для пользователей (опционально)#

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

• 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

Шаг 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'

Внимание!

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

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 <Порт> -a 'user1 user2' -u 'user3 user4' -w /home/postgres/role_BASIC -c "0,30 * * * *" -g  "'as_admin_pass':SCRAM-SHA-256$4096:2H6ypfV3DJP0LUZLrSnPsA==$yOIhGySEsNiY9p91PkJ5a2/kUQhxAwzUAQcjwCHov3A=:gd7X+KDJ+4GY44H9Xelan5dkhLwLLyDZLrhw4LhmDo8= 'as_tuz_pass':SCRAM-SHA-256$4096:TTysuRbQcMM3tOQAoR7LWg==$t89DzT7Y92HXMQxolmGXxG8AGQPvu/yDWV4leOAXiO0=:0vZGdq40uKFLLzfzB2JJ9SD1Ei8rxSObHUlPUcdHByM=" -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'

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

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
   

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

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