Установка базового кластера

Назначение и ограничения

Базовый кластер — это минимальная отказоустойчивая конфигурация из трёх узлов с совмещёнными сервисами Закрома.Хранение и ZDS.

Сервис ZDS по умолчанию использует схему Erasure Coding 2+1. При недоступности одного узла чтение и запись продолжаются, если две оставшиеся части данных доступны. Политику хранения можно изменить для каждого бакета в Admin UI, выбрав вариант, доступный для текущего кластера.

Каждый экземпляр Закрома.Хранение самодостаточен: S3 API и Admin UI доступны, пока работает хотя бы один экземпляр. Клиентские запросы можно направлять на любой доступный узел.

Для доступа клиентов на тех же трёх узлах устанавливается отказоустойчивый балансировщик haproxy-ha. HAProxy работает в режиме TCP passthrough и публикует S3 API (порт 443) и Admin UI (порт 8443) на общем виртуальном IP-адресе (VIP), а keepalived переносит VIP на доступный узел. TLS терминируется на узлах Закрома.Хранение. Другие схемы доступа — внешний балансировщик, DNS Round-Robin или их комбинация — описаны в статье Рекомендации по балансировке.

Admin UI по HTTP

Для пилотных инсталляций без HTTPS и инсталляций, где балансировщик публикует Admin UI по HTTP, задайте zakroma_storage_admin.reverse_proxy.tls: false.

Ограничения отказоустойчивости

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

Устанавливаемые компоненты

Имена rutherford-* используются только в примере. Замените их реальными именами и IP-адресами из вашей инфраструктуры и используйте те же имена в инвентаре Ansible и переменных group_vars.

Kafka и сервис seclog

Kafka нужна для работы сервиса seclog, который в поставке выключен (zakroma_storage_seclog.enable: false). Если seclog требуется, установите Kafka ролями java и kafka по аналогии с разделом 2.3 статьи Установка мультикластера и задайте параметры подключения в zakroma_storage_kafka.

Схема установки

На каждом из трёх узлов совместно работают сервисы Закрома.Хранение, ZDS и HAProxy с keepalived. Клиенты обращаются к S3 API и Admin UI по VIP, HAProxy распределяет запросы между тремя экземплярами Закрома.Хранение. Все экземпляры Закрома.Хранение подключаются к внешнему PostgreSQL.

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

Минимальные требования

Подготовка PostgreSQL, DNS и TLS

До начала установки:

1. Подготовьте PostgreSQL по инструкции Настройка PostgreSQL.
2. Рассчитайте требуемое количество подключений по инструкции Расчёт max_connections PostgreSQL.
3. Убедитесь, что FQDN PostgreSQL, узлов кластера, Admin UI и S3 API разрешаются с управляющего сервера и со всех целевых узлов. Записи Admin UI и S3 API, включая имена рабочих областей, должны указывать на VIP.
4. Подготовьте wildcard-сертификат или сертификат, содержащий необходимые DNS-имена в расширении SAN. Требования к DNS, сертификатам, узлам и дискам приведены в Подготовке окружения к установке.
5. Убедитесь, что лицензия и TLS-файлы доступны на управляющем сервере.

Установка

1. Получение и распаковка архива поставки zakroma-roles

Copy
1tar -xvzf zakroma-roles-<ВЕРСИЯ_АРХИВА>.tar.gz
2cd zakroma-roles-<ВЕРСИЯ_АРХИВА>

Проверьте структуру распакованной поставки:

Copy
1tree -L 1

В корне должны присутствовать как минимум ansible.cfg, files, inventories, playbooks, requirements.yml.template и roles.

Установка из локальных файлов

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

2. Настройка инвентаря Ansible для текущего кластера

Отредактируйте inventories/base-cluster/hosts. Оставьте в группах certificates, zakroma-storage, haproxy-ha и zakroma-zds-v2-ec только три узла базового кластера.

Замените имена узлов и IP-адреса. Значения zakroma_zds_node_name должны быть уникальными, постоянными и не должны меняться в процессе эксплуатации. Значения haproxy_ha_keepalived_priority должны различаться: VIP по умолчанию находится на узле с наибольшим приоритетом.

Copy
1[certificates]
2rutherford-2 ansible_host=192.168.1.2
3rutherford-3 ansible_host=192.168.1.3
4rutherford-4 ansible_host=192.168.1.4
5
6[zakroma-storage]
7rutherford-2 ansible_host=192.168.1.2
8rutherford-3 ansible_host=192.168.1.3
9rutherford-4 ansible_host=192.168.1.4
10
11[haproxy-ha]
12rutherford-2 ansible_host=192.168.1.2 haproxy_ha_keepalived_priority=110
13rutherford-3 ansible_host=192.168.1.3 haproxy_ha_keepalived_priority=100
14rutherford-4 ansible_host=192.168.1.4 haproxy_ha_keepalived_priority=90
15
16# Не изменяйте zakroma_zds_node_name после ввода кластера в эксплуатацию.
17[zakroma-zds-v2-ec]
18rutherford-2 ansible_host=192.168.1.2 zakroma_zds_node_name=rutherford-2
19rutherford-3 ansible_host=192.168.1.3 zakroma_zds_node_name=rutherford-3
20rutherford-4 ansible_host=192.168.1.4 zakroma_zds_node_name=rutherford-4

Проверьте SSH-доступ и выполнение Python-модулей Ansible:

Copy
1ANSIBLE_CONFIG=ansible.cfg ansible -m ping -i inventories/base-cluster/hosts all

Ожидаемый результат: каждый узел отвечает SUCCESS и pong.

3. Распространение сертификатов по узлам кластера

Поместите сертификат и ключ в каталог roles/certificates/files/ в корне распакованной поставки на управляющем сервере. Затем отредактируйте inventories/base-cluster/group_vars/certificates.yml.

Исходный файл содержит блок узла rutherford-1 с файлами keycloak.crt и keycloak.key. В базовом сценарии Keycloak не устанавливается — удалите весь блок rutherford-1 из host_cert_config. Затем измените имена остальных узлов, имена файлов, каталог назначения, владельца и права. В примере сертификат распространяется на все три узла Закрома.Хранение и ZDS.

Copy
1---
2certificates_copy_source_path: "files"
3
4host_cert_config:
5  rutherford-2: # имя из инвентаря Ansible
6    certs:
7      - src_dir: "{{ certificates_copy_source_path }}"
8        dest_dir: "/opt/certs/"
9        cert_file: "zakroma.crt"
10        key_file: "zakroma.key"
11        owner: "zakroma"
12        group: "zakroma"
13        cert_permissions: "0644"
14        key_permissions: "0600"
15  rutherford-3: # имя из инвентаря Ansible
16    certs:
17      - src_dir: "{{ certificates_copy_source_path }}"
18        dest_dir: "/opt/certs/"
19        cert_file: "zakroma.crt"
20        key_file: "zakroma.key"
21        owner: "zakroma"
22        group: "zakroma"
23        cert_permissions: "0644"
24        key_permissions: "0600"
25  rutherford-4: # имя из инвентаря Ansible
26    certs:
27      - src_dir: "{{ certificates_copy_source_path }}"
28        dest_dir: "/opt/certs/"
29        cert_file: "zakroma.crt"
30        key_file: "zakroma.key"
31        owner: "zakroma"
32        group: "zakroma"
33        cert_permissions: "0644"
34        key_permissions: "0600"

4. Настройка Закрома.Хранение

Отредактируйте inventories/base-cluster/group_vars/zakroma-storage.yml. Не заменяйте файл приведёнными ниже фрагментами целиком: сохраните остальные параметры поставки без изменений и измените только перечисленные параметры.

4.1. Настройка подключения к PostgreSQL

В примере все три экземпляра Закрома.Хранение подключаются к одной базе данных PostgreSQL. Параметры подключения находятся в нескольких блоках исходного файла. Во всех блоках могут использоваться одинаковые хост, порт, пользователь, пароль, имя базы и SSL-режим; значение postgresql_schema_name оставьте соответствующим компоненту.

Количество схем или БД для компонента worker (шардов БД) определяется совместно с технической поддержкой по требованиям к RPS и планируемому количеству объектов.

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

Copy
1zakroma_storage_postgresql_host: "<POSTGRESQL_FQDN>"
2zakroma_storage_postgresql_port: 5432
3zakroma_storage_postgresql_username: "<POSTGRESQL_USER>"
4zakroma_storage_postgresql_password: "<POSTGRESQL_PASSWORD>"
5zakroma_storage_postgresql_dbname: "zakroma"
6zakroma_storage_postgresql_sslmode: "<POSTGRESQL_SSLMODE>"
7zakroma_storage_postgresql_max_open_conns: 10
8zakroma_storage_postgresql_max_idle_conns: 5
9zakroma_storage_postgresql_connection_timeout: "10s"
10zakroma_storage_postgresql_target_session_attrs: "read-write"

В поставляемой конфигурации компоненты уже используют общие переменные zakroma_storage_postgresql_*. Измените их значения; ссылки в блоках компонентов и имена схем оставьте без изменений.

Защита чувствительных данных

Храните пароли и ключи в зашифрованном виде с помощью ansible-vault. Пример шифрования пароля PostgreSQL:

Copy
1ANSIBLE_CONFIG=ansible.cfg ansible-vault encrypt_string \
2  --name zakroma_storage_postgresql_password

Завершение ввода значения

После ввода пароля Vault введите значение переменной и, не нажимая Enter, нажмите Ctrl+D — так в значение не попадёт перевод строки.

Вставьте полученный YAML-блок с !vault целиком вместо открытого значения zakroma_storage_postgresql_password. Если используются зашифрованные переменные, запускайте плейбуки с ключом --ask-vault-pass.

4.2. Настройка домена, TLS и локальной авторизации

Измените FQDN сервиса Admin UI, базовый домен, параметры TLS и параметры учётной записи локального администратора. Остальные параметры внутри блока zakroma_storage_gateway можно оставить без изменений.

Copy
1zakroma_storage_config_encrypt: false
2
3zakroma_storage_admin:
4  path: "<ADMIN_UI_FQDN>"
5  reverse_proxy:
6    enabled: true
7    port: 8443
8
9zakroma_storage_base_domain: "<BASE_DOMAIN>"
10
11zakroma_storage_gateway:
12  s3api_port: 6443
13  management_port: 8444
14  admin_console_location: "/opt/zakroma/zakroma-storage-admin/frontend/dist/admin-ui/"
15  tls:
16    enabled: true
17    certs:
18      - key: "/opt/certs/zakroma.key"
19        crt: "/opt/certs/zakroma.crt"
20  path_to_licence: "/opt/zakroma/zakroma-storage-monolith/bin/licence"
21
22  default_admin: "<LOCAL_ADMIN>"
23  auth:
24    auth_provider: file
25    user_provider: file
26    users:
27      - name: "<LOCAL_ADMIN>"
28        password: "<LOCAL_ADMIN_PASSWORD>"
29        groups:
30          - clouduser
31# Группа clouduser тут указана в качестве примера.

При zakroma_storage_config_encrypt: true роль шифрует конфигурационные файлы через systemd LoadCredentialEncrypted=. Включайте параметр только на узлах с systemd версии 250 или новее и установленной утилитой systemd-creds.

Порты балансировщика берутся из этих параметров: frontend S3 API слушает 443 и проксирует на s3api_port, frontend Admin UI слушает reverse_proxy.port и проксирует на management_port. Если доступ организуется через внешний балансировщик или legacy-схему с Nginx, см. Рекомендации по балансировке и Настройку Nginx.

4.3. Настройка ключей шифрования данных в БД

Ключи scrambler_keys шифруют параметры конфигурации и ключи доступа, которые Закрома.Хранение хранит в БД. Ключи задаются в блоках zakroma_storage_gateway и zakroma_storage_core. Если используется сервис notification, задайте те же ключи в блоке zakroma_storage_notification.

Только для новых инсталляций

Шифрование настраивается только при новой инсталляции. Если в существующей инсталляции ключи не использовались, записи в БД зашифровать уже нельзя — оставьте scrambler_keys: [].

Сгенерируйте ключ — 64 шестнадцатеричных символа:

Copy
1python3 -c 'import secrets; print(secrets.token_hex(32))'

Укажите ключ в zakroma-storage.yml:

Copy
1zakroma_storage_gateway:
2  scrambler_keys:
3    - name: key1
4      key: "<SCRAMBLER_KEY>"
5      default: true
6      deprecated: false
7
8zakroma_storage_core:
9  scrambler_keys:
10    - name: key1
11      key: "<SCRAMBLER_KEY>"
12      default: true
13      deprecated: false

Для ротации добавьте новый ключ с default: true, а текущему ключу установите default: false и deprecated: true. Отозванные ключи из списка не удаляйте.

Copy
1  scrambler_keys:
2    - name: key2
3      key: "<NEW_SCRAMBLER_KEY>"
4      default: true
5      deprecated: false
6    - name: key1
7      key: "<SCRAMBLER_KEY>"
8      default: false
9      deprecated: true

Значение ключа можно хранить в ansible-vault: зашифруйте его командой ansible-vault encrypt_string по примеру пароля PostgreSQL и укажите в key ссылку на переменную.

5. Настройка сервиса ZDS

Для установки сервиса хранения ZDS отредактируйте inventories/base-cluster/group_vars/zakroma-zds-v2-ec.yml. Сохраните неизменяемые параметры поставки и замените только значения, которые зависят от конфигурации вашего кластера.

5.1. Настройка API, межузлового взаимодействия и Erasure Coding

Задайте пару ключей доступа один раз в переменных zakroma_zds_access_key и zakroma_zds_secret_key. Блоки server, cluster_server и client используют эти значения. При необходимости также измените интерфейсы, порты и параметры TLS.

Copy
1# Укажите учётные данные ZDS один раз.
2zakroma_zds_access_key: "<ZDS_ACCESS_KEY>"
3zakroma_zds_secret_key: "<ZDS_SECRET_KEY>"
4
5zakroma_zds_protocol_prefix: "http://"
6
7zakroma_zds_server:
8  host: "0.0.0.0"
9  port: 8088
10  accessKey: "{{ zakroma_zds_access_key }}"
11  secretKey: "{{ zakroma_zds_secret_key }}"
12  tls:
13    enable: false
14    key: "/etc/zakroma/ssl/server.key"
15    crt: "/etc/zakroma/ssl/server.crt"
16
17zakroma_zds_publicServer_interface: ""
18
19zakroma_zds_cluster_server:
20  host: "0.0.0.0"
21  interface: ""
22  port: 8089
23  accessKey: "{{ zakroma_zds_access_key }}"
24  secretKey: "{{ zakroma_zds_secret_key }}"
25  tls:
26    enable: false
27    key: "/etc/zakroma/ssl/cluster.key"
28    crt: "/etc/zakroma/ssl/cluster.crt"
29
30zakroma_zds_client:
31  # Определите параметры доступа к ZDS (только для доступа сервиса Закрома.Хранение и для внутрикластерного взаимодействия)
32  accessKey: "{{ zakroma_zds_access_key }}"
33  secretKey: "{{ zakroma_zds_secret_key }}"
34
35zakroma_zds_providers:
36  # В данной секции задаются параметры по умолчанию для текущего хранилища.
37  # Их всегда можно переопределить для нового бакета через Admin UI
38  ec:
39    dataPart: 2
40    parityPart: 1
41    cleanup: false

Разделение публичного и кластерного трафика

zakroma_zds_publicServer_interface задаёт интерфейс, IPv4-адрес которого роль использует в nodes.hostPort для основного API ZDS на порту 8088. Если значение оставить пустым, роль использует ansible_default_ipv4.address.

Чтобы вынести межузловой трафик на отдельный интерфейс и порт, задайте zakroma_zds_cluster_server.interface. В этом случае роль создаст отдельные clusterServer и nodes.clusterHostPort на порту 8089. Если значение оставить пустым, отдельный кластерный endpoint не создаётся и межузловые запросы выполняются через nodes.hostPort на порту 8088.

5.2. Настройка служебных каталогов и дисков

Пути ниже приведены как пример. Замените их фактическими точками монтирования, которые существуют на каждом узле с сервисом ZDS.

Copy
1zakroma_zds_background_window_jobs:
2  vacuum:
3    enabled: true
4    storePath: "/mnt/lvm1/system/vacuum-state"
5  scan:
6    enabled: true
7    storePath: "/mnt/lvm1/system/scan-state"
8  # Измените данные параметры в соответствии с инструкцией для подготовки узла и вашей конфигурации сервера
9
10zakroma_zds_registry:
11  path: "/mnt/lvm1/system/db"
12  # Измените данные параметры в соответствии с инструкцией для подготовки узла и вашей конфигурации сервера
13
14zakroma_zds_hosts_group_name: "zakroma-zds-v2-ec"
15
16zakroma_zds_drive:
17  # Измените данные параметры в соответствии с инструкцией для подготовки узла и вашей конфигурации сервера
18  list:
19    - index: 1
20      path: "/mnt/lvm2/data"
21      storageGroup: 1
22      storageClass: ""
23    - index: 2
24      path: "/mnt/lvm3/data"
25      storageGroup: 2
26      storageClass: "HDD"
27    - index: 3
28      path: "/mnt/lvm4/data"
29      storageGroup: 3
30      storageClass: "SSD"

6. Настройка балансировщика haproxy-ha

Отредактируйте inventories/base-cluster/group_vars/haproxy-ha.yml. Frontend-ы S3 API и Admin UI уже описаны в haproxy_ha_frontends и получают порты из переменных zakroma-storage.yml; измените только параметры keepalived.

Copy
1haproxy_ha_backend_hosts_group_name: zakroma-storage
2
3haproxy_ha_keepalived_interface: eth0
4haproxy_ha_keepalived_virtual_ip: <VIP>/24
5haproxy_ha_keepalived_virtual_router_id: 51
6haproxy_ha_keepalived_auth_pass: "{{ vault_haproxy_ha_keepalived_auth_pass }}"

Зашифруйте пароль VRRP и добавьте полученный блок в haproxy-ha.yml:

Copy
1ANSIBLE_CONFIG=ansible.cfg ansible-vault encrypt_string \
2  --name vault_haproxy_ha_keepalived_auth_pass

7. Проверка конфигурации

Проверьте, что инвентарь и YAML-файлы корректно загружаются Ansible:

Copy
1ANSIBLE_CONFIG=ansible.cfg ansible-inventory \
2  -i inventories/base-cluster/hosts \
3  --list >/dev/null

8. Распространение сертификатов и лицензии по узлам кластера

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

Copy
1ANSIBLE_CONFIG=ansible.cfg ansible-playbook \
2  -i inventories/base-cluster/hosts \
3  playbooks/sample-play-copy-certificates.yml

На каждом узле проверьте файлы, владельца и права.

Copy
1sudo stat -c '%U:%G %a %n' /opt/certs/zakroma.crt /opt/certs/zakroma.key
2openssl x509 -in /opt/certs/zakroma.crt -noout -subject -issuer -dates

Ожидаются владелец zakroma, права 644 для сертификата и 600 для ключа.

На управляющем сервере проверьте цепочку исходного сертификата с доверенным CA:

Copy
1openssl verify -CAfile <CA_CERTIFICATE> roles/certificates/files/zakroma.crt

Ожидаемый результат — roles/certificates/files/zakroma.crt: OK.

Поместите лицензию в files/zakroma-licence/licence и убедитесь, что файл существует:

Copy
1test -f files/zakroma-licence/licence

Скопируйте лицензию на узлы Закрома.Хранение:

Copy
1ANSIBLE_CONFIG=ansible.cfg ansible-playbook \
2  -i inventories/base-cluster/hosts \
3  playbooks/sample-play-copy-licence-file.yml \
4  --ask-vault-pass

Проверьте на одном из узлов, что лицензия находится по пути из zakroma_storage_gateway.path_to_licence:

Copy
1sudo test -f /opt/zakroma/zakroma-storage-monolith/bin/licence

9. Preflight-проверки перед установкой

После распространения сертификатов и лицензии выполните preflight-проверку Закрома.Хранение, затем ZDS:

Copy
1ANSIBLE_CONFIG=ansible.cfg ansible-playbook \
2  -i inventories/base-cluster/hosts \
3  playbooks/sample-play-zakroma-storage-preflight.yml
4
5ANSIBLE_CONFIG=ansible.cfg ansible-playbook \
6  -i inventories/base-cluster/hosts \
7  playbooks/sample-play-zakroma-zds-v2-preflight.yml

Переходите к установке только после успешного выполнения обоих плейбуков. В PLAY RECAP для всех узлов должны быть unreachable=0 и failed=0.

9.1. Диагностика ошибок preflight

Preflight проверяет разрешение имени и доступность PostgreSQL, подключение с указанными учётными данными, наличие базы данных и требуемых схем. Если проверка завершилась ошибкой, используйте сообщение Ansible, чтобы определить причину:

10. Установка Закрома.Хранение, сервиса ZDS и балансировщика

Установите сервисы Закрома.Хранение:

Copy
1ANSIBLE_CONFIG=ansible.cfg ansible-playbook \
2  -i inventories/base-cluster/hosts \
3  playbooks/sample-play-zakroma-storage.yml

В выводе Ansible PLAY RECAP должны быть unreachable=0 и failed=0. До установки ZDS на каждом узле проверьте доступность сервисов Закрома.Хранение:

Copy
1sudo systemctl status --no-pager --full zakroma-storage-monolith.service

Ожидаемое состояние — Active: active (running) с указанием времени работы сервиса. После этого установите сервис ZDS:

Copy
1ANSIBLE_CONFIG=ansible.cfg ansible-playbook \
2  -i inventories/base-cluster/hosts \
3  playbooks/sample-play-zakroma-zds-v2-ec.yml

В выводе Ansible PLAY RECAP должны быть unreachable=0 и failed=0. На каждом узле проверьте сервис ZDS:

Copy
1sudo systemctl status --no-pager --full zakroma-ds-agent.service

Ожидаемое состояние — Active: active (running) с указанием времени работы сервиса.

После установки сервиса ZDS Ansible выводит адреса, по которым Закрома.Хранение подключается к ZDS:

Copy
1TASK [zakroma-zds : Вывод адресов подключения к ZDS] ***************************
2ok: [rutherford-2] => {
3    "msg": "Адреса подключения к ZDS: 192.168.1.2:8088, 192.168.1.3:8088, 192.168.1.4:8088"
4}

Скопируйте эти адреса: они понадобятся при добавлении кластера ZDS в Admin UI.

Установите балансировщик:

Copy
1ANSIBLE_CONFIG=ansible.cfg ansible-playbook \
2  -i inventories/base-cluster/hosts \
3  playbooks/sample-play-haproxy-ha.yml \
4  --ask-vault-pass

В выводе Ansible PLAY RECAP должны быть unreachable=0 и failed=0. На каждом узле проверьте сервисы балансировщика:

Copy
1sudo systemctl status --no-pager --full haproxy.service keepalived.service

Ожидаемое состояние — Active: active (running). Убедитесь, что VIP назначен ровно одному узлу — узлу с наибольшим haproxy_ha_keepalived_priority:

Copy
1ip -brief address show | grep '<VIP>'

Проверка готовности

11. Проверка работоспособности сервисов и API

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

Copy
1sudo systemctl status --no-pager --full \
2  zakroma-storage-monolith.service \
3  zakroma-ds-agent.service \
4  haproxy.service \
5  keepalived.service

Для каждого сервиса ожидаются Active: active (running) и состояние автозапуска enabled в строке Loaded. Значение preset не заменяет проверку текущего состояния автозапуска.

Проверьте, что Admin UI открывается по адресу https://<ADMIN_UI_FQDN>:8443. Подробная проверка сервисов приведена в Проверке статуса сервисов.

12. Функциональная проверка S3

Откройте Admin UI по настроенному FQDN и подключите кластер ZDS, указав адреса подключения из вывода Ansible на шаге 10. Затем создайте рабочую область, бакет, разрешающую политику и выпустите S3-ключ для локального администратора или отдельного тестового пользователя. Для проверки используйте отдельный тестовый объект, который после проверки можно удалить.

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

Copy
1export AWS_ACCESS_KEY_ID='<S3_ACCESS_KEY>'
2read -rsp 'AWS Secret Access Key: ' AWS_SECRET_ACCESS_KEY
3export AWS_SECRET_ACCESS_KEY
4echo
5export S3_ENDPOINT='https://<WORKSPACE_FQDN>'
6export S3_BUCKET='<TEST_BUCKET>'
7AWS_TLS_OPTION=''

Самоподписанный сертификат

Если S3 API использует самоподписанный сертификат, перед проверкой задайте AWS_TLS_OPTION='--no-verify-ssl'. Параметр отключает для AWS CLI проверку сертификата сервера, поэтому используйте его только для функционального теста. Для сертификата от доверенного центра сертификации оставьте переменную пустой.

Загрузите объект, проверьте его наличие, скачайте, сравните и удалите:

Copy
1object="base-cluster-$(date +%s).txt"
2printf 'S3 functional check\n' >/tmp/zakroma-s3-source.txt
3aws ${AWS_TLS_OPTION} --endpoint-url "$S3_ENDPOINT" s3 cp /tmp/zakroma-s3-source.txt "s3://${S3_BUCKET}/${object}"
4aws ${AWS_TLS_OPTION} --endpoint-url "$S3_ENDPOINT" s3 ls "s3://${S3_BUCKET}/${object}"
5aws ${AWS_TLS_OPTION} --endpoint-url "$S3_ENDPOINT" s3 cp "s3://${S3_BUCKET}/${object}" /tmp/zakroma-s3-downloaded.txt
6cmp /tmp/zakroma-s3-source.txt /tmp/zakroma-s3-downloaded.txt
7aws ${AWS_TLS_OPTION} --endpoint-url "$S3_ENDPOINT" s3 rm "s3://${S3_BUCKET}/${object}"
8rm -f /tmp/zakroma-s3-source.txt /tmp/zakroma-s3-downloaded.txt
9unset AWS_SECRET_ACCESS_KEY
10unset AWS_TLS_OPTION

Проверка успешна, если cmp не вывел различий, а объект удалён из бакета.

13. Повторный запуск и проверка идемпотентности

Повторно выполните плейбуки установки с тем же инвентарём Ansible и переменными group_vars:

Copy
1ANSIBLE_CONFIG=ansible.cfg ansible-playbook \
2  -i inventories/base-cluster/hosts \
3  playbooks/sample-play-zakroma-storage.yml
4
5ANSIBLE_CONFIG=ansible.cfg ansible-playbook \
6  -i inventories/base-cluster/hosts \
7  playbooks/sample-play-zakroma-zds-v2-ec.yml
8
9ANSIBLE_CONFIG=ansible.cfg ansible-playbook \
10  -i inventories/base-cluster/hosts \
11  playbooks/sample-play-haproxy-ha.yml \
12  --ask-vault-pass

Успешный результат повторного запуска:

• в PLAY RECAP нет failed и unreachable;
• сервисы и функциональный S3-тест остаются рабочими;
• изменения (changed) в PLAY RECAP объяснимы, например перезапуском сервиса после фактического изменения конфигурации.