Установка#

Состав дистрибутива#

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

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

1. Подготовьте чек-листы переменных запуска и работ по установке.

2. Убедитесь в корректности заполненных и переопределенных переменных.

Чек-лист переменных для Mock-core-app#

Чек-лист переменных для Mock-cloud#

Примечание

* Здесь и далее используемые в названиях параметров и переменных сокращения «meta» или «meta_mock» являются ранее употребляемыми названиями сервиса AMCS и применимы для установки компонента AMCS в текущей версии продукта.

Чек-лист переменных для Mock-audit-app#

Чек-лист переменных для Eureka-server-app#

Чек-лист работ по установке#

Примечание

Заполнение чек-листа во время установки обязательно.

* - обязательно для заполнения

** - обязательно для заполнения в случае ошибки

Подготовка дистрибутива#

Перед развертыванием Mock необходимо подготовить (выполнить слияние разделенного дистрибутива) дистрибутив программного продукта и выгрузить его в репозиторий для дальнейшей установки. Подготовить дистрибутив можно одним из способов:

1. С помощью автоматизированных jobs Solution pipeline.

2. Вручную с помощью скриптов слияния, поставляемых с дистрибутивом (amcs-deploy).

Подготовка дистрибутива с помощью Solution pipeline#

1. Запустите Jenkins job для объединения разделенного Solution(solution-merger). Пример конфигурации можно посмотреть в файле merger.yml.

2. Запустите Jenkins job для раскладки компонентов Solution(solution-unpacker). Пример конфигурации можно посмотреть в файле environment.yml.

3. После работы job, проверьте наличие файла amcs-bin-*-{VERSION}-*-distrib.zip в Nexus для последующей установки.

Ручная подготовка дистрибутива#

1. Скачайте дистрибутив amc-{VERSION}-distrib.zip.

2. Разархивируйте его в отдельную папку. В папке появятся два архива с программным продуктом и сторонними зависимостями: amc-{VERSION}-party-distrib.zip и amc-{VERSION}-owned-distrib.zip.

3. Распакуйте архив amc-{VERSION}-owned-distrib.zip и перейдите в распакованную директорию amc-{VERSION}-owned-distrib.

4. Распакуйте архив amcs-merger-{VERSION}-distrib.zip в директорию amcs-merger-{VERSION}-distrib (либо в любую другую).

5. Скопируйте файл Report.json из текущей директории (amc-{VERSION}-owned-distrib) в директорию amcs-merger-{VERSION}-distrib.

6. Перейдите в директорию amcs-merger-{VERSION}-distrib, сконфигурируйте и запустите следующий скрипт:

   ${PATH_TO_GROOVY_BIN}/groovy -cp ./src merge.groovy --report ./Report.json {PATH_TO_FILE}/amc-{VERSION}-party-distrib.zip {PATH_TO_FILE}/amc-{VERSION}-owned-distrib.zip
   

   Результатом работы будет новый архив в корне директории amcs-merger-{VERSION}-distrib: owned.zip.

7. Распакуйте полученный архив owned.zip.

8. Перейдите в распакованную директорию и выложите архив amcs-bin-{VERSION}-distrib.zip в Nexus для последующей установки на стенд.

Установка сертификатов для эмуляций#

Для работы HTTPS вызовов из groovy скриптов эмуляций к удаленным сервисам необходимо установить следующие сертификаты:

• /etc/ssl/certs/certsCollection.pem

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

• /etc/ssl/certs/client.pem

  Сертификат открытого ключа сервера с приложением Mock.

• /etc/ssl/certs/client_private_key.pem

  Закрытый ключ сертификата.

1. Получите у уполномоченных лиц указанные PEM-сертификаты.

2. Разместите их в директории /etc/ssl/certs/ на целевой сервер {MOCK-APP}.

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

Установка и настройка ФП Авторизации и Аутентификации#

Целевым продуктом, используемым как ФП Авторизации и Аутентификации, является Keycloak.

1. Установите Keycloak версии 9.0.3+.

2. Войдите в консоль администратора Keycloak.

3. Нажмите кнопку Add realm и импортируйте файл sbermock-realm.json.

Установка и настройка Kafka и Zookeeper#

1. Установите Kafka и Zookeeper в директорию /var/kafka или любую другую.

2. Сконфигурируйте Kafka следующим образом, внеся изменения в файл {KAFKA_DIR}/config/server.properties:

   zookeeper.connect={kafka_host_ip}:2181
   advertised.host.name={kafka_host_ip}
   advertised.listeners=PLAINTEXT://{kafka_host_ip}:9092
   auto.create.topics.enable=true
   security.inter.broker.protocol=PLAINTEXT
   

   Обязательно проверьте что в свойствах не включается SSL. Все свойства вида ssl.* должны быть отключены.

3. Запустите Zookeeper:

   ./bin/zookeeper-server-start.sh config/zookeeper.properties
   

4. Запустите Kafka:

   ./bin/kafka-server-start.sh config/server.properties
   

Установка и настройка External-Kafka и External-Zookeeper#

1. Установите External-Kafka и External-Zookeeper в директорию /var/kafka или любую другую.

2. Сконфигурируйте Zookeeper:

   1. В файле {KAFKA_DIR}/config/zookeeper.properties задайте свойства:

      authProvider.1=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
      requireClientAuthScheme=sasl
      jaasLoginRenew=3600000
      

   2. Проверьте, доступен ли выбор файла с настройками JAAS.

      Для этого откройте для просмотра файл {KAFKA_DIR}/bin/zookeeper-server-start.sh. Проверьте, задается ли в нем параметр запуска -Djava.security.auth.login.config.

      Если параметр есть, внесите изменения в указанный в параметре файл. Если параметр не задан, то создайте новый файл {KAFKA_DIR}/config/zookeeper_jaas.conf.

      Содержимое файла настроек JAAS по формату должно совпадать с zookeeper_jaas.conf.

   3. Если файл JAAS был создан вручную, каждый раз перед запуском zookeeper задайте ENV переменную с указанием пути к файлу:

      export KAFKA_OPTS="-Djava.security.auth.login.config={KAFKA_DIR}/config/zookeeper_jaas.conf"
      

   4. Запустите zookeeper:

      ./bin/zookeeper-server-start.sh config/zookeeper.properties
      

3. Сконфигурируйте Kafka:

   1. В файле {KAFKA_DIR}/config/server.properties задайте следующие свойства:

      zookeeper.connect={kafka_host_ip}:2181
      zookeeper.set.acl=true
        
      security.inter.broker.protocol=SASL_PLAINTEXT
      sasl.mechanism.inter.broker.protocol=PLAIN
      sasl.enabled.mechanisms=PLAIN
      
      authorizer.class.name=kafka.security.auth.SimpleAclAuthorizer
        
      allow.everyone.if.no.acl.found=true
      auto.create.topics.enable=false
      super.users=User:kafka
        
      listeners=SASL_PLAINTEXT://:9093,PLAINTEXT://:9092
      advertised.listeners=SASL_PLAINTEXT://{kafka_host_ip}:9093,PLAINTEXT://{kafka_host_ip}:9092
      

      Обязательно проверьте, что в свойствах не включается SSL. Все свойства вида ssl.* должны быть отключены.

   2. Проверьте, доступен ли выбор файла с настройками JAAS.

      Для этого откройте для просмотра файл {KAFKA_DIR}/bin/kafka-server-start.sh. Проверьте, задается ли в нем параметр запуска -Djava.security.auth.login.config.

      Если параметр есть, вносите изменения в указанный в параметре файл. Если параметр не задан, то создайте новый файл {KAFKA_DIR}/config/kafka_server_jaas.conf.

      Содержимое файла настроек JAAS по формату должно совпадать с kafka_server_jaas.conf.

4. В файле допускается изменение имени пользователя и пароля. При изменении значения свойства username важно изменить и название свойства user_kafka так, чтобы оно соответствовало формату user_{new_username}.

5. Если файл JAAS был создан вручную, каждый раз перед запуском kafka требуется задавать ENV переменную с указанием пути к файлу:

   export KAFKA_OPTS="-Djava.security.auth.login.config={KAFKA_DIR}/config/kafka_server_jaas.conf"
   

6. Запустите Kafka:

   ./bin/kafka-server-start.sh config/server.properties
   

Установка и настройка ActiveMQ Artemis#

1. Установите ActiveMQ Artemis версии 2.19.1 и выше.

2. Добавьте пользователя для управления очередями через экземпляр AMCS, сконфигурировав файл artemis-users.properties:
   userName = password

3. Добавьте роль для пользователя, сконфигурировав файл artemis-roles.properties:
   roleName = userName

4. Сконфигурируйте файл broker.xml:

   ...
   <security-settings>
        <security-setting match="#">
           <permission type="createNonDurableQueue" roles="amq,roleName"/>
           <permission type="deleteNonDurableQueue" roles="amq,roleName"/>
           <permission type="createDurableQueue" roles="amq,roleName"/>
           <permission type="deleteDurableQueue" roles="amq,roleName"/>
           <permission type="createAddress" roles="amq,roleName"/>
           <permission type="deleteAddress" roles="amq,roleName"/>
           <permission type="consume" roles="amq,roleName"/>
           <permission type="browse" roles="amq,roleName"/>
           <permission type="send" roles="amq,roleName"/>
           <!-- we need this otherwise ./artemis data imp wouldn't work -->
           <permission type="manage" roles="amq"/>
        </security-setting>
       </security-settings>
   <address-settings>
        ...
        <address-setting match="#">
           ...
           <auto-create-queues>false</auto-create-queues>
           <auto-create-addresses>true</auto-create-addresses>
           <auto-delete-queues>false</auto-delete-queues>
           <auto-delete-addresses>false</auto-delete-addresses>
        </address-setting>
   </address-settings>
   ...
   

5. Запустите брокер.

6. Проверьте запуск брокера, перейдя в консоль администратора по адресу http://<ARTEMIS_HOST>:8161/console.

   Если консоль администратора по адресу http://<ARTEMIS_HOST>:8161/console не доступна, но при этом сервис запущен, проверьте следующие настройки:

   bootstrap.xml:

   ...
   <!-- The web server is only bound to localhost by default -->
   <web bind="http://0.0.0.0:8161" path="web">
       <app url="activemq-branding" war="activemq-branding.war"/>
       <app url="artemis-plugin" war="artemis-plugin.war"/>
       <app url="console" war="console.war"/>
   </web>
   ...
   

   jolokia-access.xml:

   ...
   <cors>
       <!-- Allow cross origin access from localhost ... -->
       <allow-origin>*</allow-origin>
       <!-- Options from this point on are auto-generated by Create.java from the Artemis CLI -->
       <!-- Check for the proper origin on the server side, too -->
       <strict-checking/>
   </cors>
   ...
   

Установка Nginx#

Выполните следующие шаги для конфигурирования Nginx.

1. Выполните стандартную установку Nginx в директорию <NGINX_INSTALL>. Дополнительная информация представлена в официальной документации Nginx.

2. Разместите сертификат и файл ключа certificate.crt, privateKey.key в директорию /etc/nginx/ssl.

3. Сконфигурируйте файл <NGINX_INSTALL>/nginx.conf. Пример конфигурации: пример файла.

4. Сконфигурируйте файл <NGINX_INSTALL>/upstreams.conf. Пример конфигурации: пример файла.

5. Замените значения <MOCK_APP_IP_*> в файле upstreams.conf на соответствующие вашей конфигурации стенда. При кластерной конфигурации Mock необходимо указать все сервера Mock в файле upstreams.conf.

Установка Nginx Mono-rest#

Выполните следующие шаги для конфигурирования Nginx mono-rest, предназначенного для вызова REST-заглушек.

1. Выполните стандартную установку Nginx в директорию <NGINX_INSTALL>. Дополнительная информация представлена в официальной документации Nginx.

2. Разместите сертификат certificate.crt и файл ключа privateKey.key в директорию /etc/nginx/ssl.

3. Сконфигурируйте файл <NGINX_INSTALL>/nginx.conf. Пример конфигурации: пример файла.

4. Сконфигурируйте файл <NGINX_INSTALL>/upstreams.conf. Пример конфигурации: пример файла.

5. Замените значение переменной <MOCK_APP_IP> в файле upstreams.conf на соответствующее вашей конфигурации стенда. При кластерной конфигурации Mock необходимо указать все сервера Mock в файле upstreams.conf.

Установка PostgreSQL#

Информация о версии PostgreSQL: PostgreSQL 11.14 (PostgreSQL Sber Edition 5.1.0) on x86_64-pc-linux-gnu, compiled by x86_64-alt-linux-gcc (GCC) 8.4.1 20200305 (ALT p9 8.4.1-alt0.p91), 64-bit.

Выполните следующие шаги для конфигурирования PostgreSQL:

1. Выполните стандартную установку PostgreSQL. Дополнительная информация представлена в официальной документации PostgreSQL.

   -$su–
   -#systemctl edit postgresql - 11.14.service - [Service] - Environment = PGDATA = < DB_INSTALL > // Директория размещения файлов экземпляра БД
   -#/usr/pgsql - 11.14 / bin / postgresql11.14 - setup initdb
   

2. Разрешите обращение к серверу БД со всех IP-адресов (опционально):

   Внимание
   При работе с СУБД Pangolin изменения конфигурации требуется вносить в файл конфигурации patroni /etc/patroni/postgres.yml.

   1. Внесите в файл <DB_INSTALL>/pg_hba.conf значение host all all all scram-sha-256.

   2. Внесите в файл <DB_INSTALL>/postgresql.conf следующие строки:

      - listen_addresses ='*'
      - port = 5432
      - shared_preload_libraries =
      -'auto_explain,pg_stat_statements'
      -#$libdir/passwordcheck
      

      При необходимости порт можно заменить на другой, используемый СУБД.

   3. Для применения изменений перезапустите службу PostgreSQL с помощью следующей команды:

      <DB_BIN>/pg_ctl restart -D <DB_INSTALL>
      

      Для СУБД Pangolin используйте следующую команду:

      patronictl -c /etc/patroni/postgres.yml reload postgresql_4fbcc4f29ae5b1f9850a41fbc659b718
      

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

      patronictl -c /etc/patroni/postgres.yml reload
      

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

Установка Mock при помощи скриптов развертывания#

Подготовка скриптов развертывания#

Перед началом работы со скриптами развертывания убедитесь в наличии рабочего Jenkins с подключенным Ansible плагином.

1. Распакуйте содержимое zip-архива amcs-deploy-{VERSION}-distrib.zip (находится в owned архиве поставляемого дистрибутива) в удобную директорию. Данный архив содержит скрипты развертывания.

2. Создайте репозиторий в Git (или аналоге) и перенесите в него скрипты.

3. Замените значения указанных переменных соответствующими вашим КТС в файле hosts:

   • <MOCK_DB_IP>: IP сервера базы данных

   • <MOCK_APP_IP>: IP сервера Java приложения Mock

   • <NGINX_UI_IP>: IP сервера Nginx UI (mock-front)

   • <KAFKA_IP>: IP сервера Kafka

   • <EXT_KAFKA_IP>: IP сервера External-Kafka

   • <KEYCLOAK_URL>: полный адрес сервера Keycloak

     Адрес должен быть таким, по которому открывается веб-страница «Welcome to Keycloak».

     Пример: https://example-url/keycloak/auth

   • <MQ_IP>: IP сервера ActiveMQ Artemis

4. Внесите изменения в файл group_vars/dzo_DEV_Mock/mock.yml:

   DNS:
   196      ZONE_NAME: ".<ZONE_NAME>"
   DNS:
   279      ZONE_NAME: ".<ZONE_NAME>"
   HOST: "<NGINX_UI_IP>"
   

   Замените значение <ZONE_NAME> на соответствующую запись в DNS (при наличии) для REST-заглушек (слева указаны номера строк в файле). Замените значение <NGINX_UI_IP> на соответствующий адрес сервера Nginx UI (слева указаны номера строк в файле).

5. Внесите изменения в файл group_vars/dzo_DEV_Mock/pwd.yml (обратите внимание: наименование логинов должно быть в нижнем регистре):

   # PSQL USERS
   # Пользователь с произвольным именем и паролем под которым keycloak сможет пользоваться БД.
   # Пользователь будет создан автоматически, существовать до инициализации БД не должен
   psql_users_mock_keycloak_user:        "<PSQL_KEYCLOAK_USER>"
   psql_users_mock_keycloak_user_pwd:    "<PSQL_KEYCLOAK_USER_PWD>"
    
   # Пароль пользователя meta_mock. Пользователя использует приложение Mock для работы с БД
   # Пользователь будет создан автоматически, существовать до инициализации БД не должен
   psql_users_mock_user_pwd:             "<PSQL_MOCK_USER_PWD>"
   
   # Пользователь с произвольным именем и паролем для администрирования БД и схемы в ней приложением Mock
   # Пользователь будет создан автоматически, существовать до инициализации БД не должен
   psql_users_mock_admin:                "<PSQL_MOCK_ADMIN_USER>"
   psql_users_mock_admin_pwd:            "<PSQL_MOCK_ADMIN_USER_PWD>"
    
   # KAFKA
   mock_extkafka_user: "<EXT_KAFKA_USER>"
   mock_extkafka_pwd: "<EXT_KAFKA_PWD>"
    
   # MQ
   mock_mq_user: "<MQ_USER>"
   mock_mq_pwd: "<MQ_PWD>"
   

   Замените значения <SOME_PARAMS> на соответствующие вашей конфигурации. Обратите внимание, что значения с <SOME_PARAMS> регистрозависимы. Замените значение <EXT_KAFKA_USER> и <EXT_KAFKA_PWD> на соответствующее вашей конфигурации (super.user) External-Kafka. Замените значение <MQ_USER> и <MQ_PWD> на данные пользователя, который был создан/добавлен на шаге конфигурации ActiveMQ Artemis.

   Опционально: зашифруйте данные файлы, используя Ansible_Vault.

6. Внесите изменения в файлы host_vars/dzo_devmock_***_mock/vars.yml:

   ansible_ssh_user: "***"
   ansible_ssh_pass: "***"
   

   Введите данные пользователя для доступа по SSH к соответствующим КТС. IP-адреса были ранее сконфигурированы в файле hosts.

   Опционально: зашифруйте данные файлы, используя Ansible_Vault.

7. Опционально: При необходимости измените параметры в файле group_vars/all/general.yml:

   pg_os_user: "***"
   pg_os_group: "***"
   

Указания по работе с профилями приложения#

Mock имеет несколько профилей запуска приложения, указанные в переменной spring_profiles_active в файле hosts на КТС. Профили указываются через запятую и по умолчанию имеют значение:

cloud,outer

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

cloud: Указывает, что используется Keycloak (по умолчанию всегда используется)
outer: Профиль для внешних организаций (заказчиков)
devops: Указать при интеграции с Devops portal
rest: Включает REST эмуляции
kafka: Включает Kafka эмуляции
mq: Включает Artemis MQ эмуляции

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

cloud,outer,devops,rest,kafka,mq

Дополнительная подготовка скриптов для кластерной конфигурации(опционально)#

При использовании кластерной конфигурации Mock или СПО необходимо дополнительно настроить скрипты следующим образом:

Подготовка скриптов для кластерной конфигурации Mock#

1. Добавить описание всех серверов приложений Eureka, Mock и Nginx(при необходимости) в файле hosts. Название хостов должно соответствовать паттерну уже существующих записей. Пример конфигурации:

   # Кластер Eureka
   dzo_devmock_d_sbermock_eureka_01_eureka_oc_mock       ansible_host=<EUREKA_IP_1> ansible_ssh_host=<EUREKA_IP_1>
   dzo_devmock_d_sbermock_eureka_02_eureka_oc_mock       ansible_host=<EUREKA_IP_2> ansible_ssh_host=<EUREKA_IP_2>
   
   # Кластер Mock
   dzo_devmock_d_sbermock_mock_01_app_node_oc_mock       ansible_host=<MOCK_APP_IP_1> ansible_ssh_host=<MOCK_APP_IP_1> mock_cloud_index=1
   dzo_devmock_d_sbermock_mock_02_app_node_oc_mock       ansible_host=<MOCK_APP_IP_2> ansible_ssh_host=<MOCK_APP_IP_2> mock_cloud_index=2
   
   # Кластер Nginx
   dzo_devmock_d_sbermock_nginx_01_nginx_mock          ansible_host=<NGINX_UI_IP_1> ansible_ssh_host=<NGINX_UI_IP_1>
   dzo_devmock_d_sbermock_nginx_02_nginx_mock          ansible_host=<NGINX_UI_IP_2> ansible_ssh_host=<NGINX_UI_IP_2>
   
   # Пример кластерной конфигурации BASIC-PROXY. Хосты указываются через запятую
   proxy_hosts=<MOCK_APP_IP_1>,<MOCK_APP_IP_2>
   
   # Пример кластерной конфигурации EUREKA:
   eureka_instance_name_host1=<EUREKA_IP_1>
   eureka_instance_name_host2=<EUREKA_IP_2>
   

2. Далее необходимо добавить информацию с пользователями для доступа к КТС по ssh.

   • Создайте новую директорию соответствующую названию КТС(из конфига выше) в директории host_vars/{Название КТС} (например devmock_d_sbermock_eureka_02_eureka_oc_mock). Название директорий должно соответствовать текущим паттернам уже созданных директорий.

   • Создайте в новой директории файл vars.yml и внесите туда данные пользователя(с правами sudo) для доступа по SSH. Пример файла:

   ansible_ssh_user: "***"
   ansible_ssh_pass: "***"
   

Подготовка скриптов для кластерной конфигурации СПО#

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

   # Пример кластерной конфигурации KAFKA:
   kafka_host1=<KAFKA_IP_1>
   kafka_host2=<KAFKA_IP_2>
   
   #Пример кластерной конфигурации EXT_KAFKA:
   ext_kafka_host1=<EXT_KAFKA_IP_1>
   ext_kafka_host2=<EXT_KAFKA_IP_2>
   
   # Пример кластерной конфигурации ELK_KAFKA:
   elk_kafka_host1=<KAFKA_IP_1>
   elk_kafka_host2=<KAFKA_IP_2>
   

2. Далее, в зависимости от вашей конфигурации СПО, необходимо внести изменения в файл group_vars/dzo_DEV_Mock/mock.yml. Ниже приведен пример для двух нодовой конфигурации:

   MOCK:
        KAFKA:
         SERVERS: "{{kafka_host1}}:9092,{{kafka_host2}}:9092" # Указать через запятую все сервера Kafka.
        EXTKAFKA:
         REPLICATION_FACTOR: "2" # Указать кол-во серверов Ext_Kafka
         SASL: "{{ext_kafka_host1}}:9093,{{ext_kafka_host2}}:9093" # Указать через запятую все сервера Ext_Kafka.
         PLAIN: "{{ext_kafka_host1}}:9092,{{ext_kafka_host2}}:9092" # Указать через запятую все сервера Ext_Kafka.
        EUREKA:
         SERVERS: "http://{{eureka_instance_name_host1}}:8761/eureka,http://{{eureka_instance_name_host2}}:8761/eureka" # Указать через запятую все сервера Eureka.
        AUDITELK:
         ELK_KAFKA:
         SERVERS: "{{elk_kafka_host1}}:9092,{{elk_kafka_host2}}:9092" # Указать через запятую все сервера Elk_Kafka.
   

3. Сделайте commit и push в репозиторий.

Создание Jenkins Pipeline#

1. Перейдите в рабочую директорию Jenkins и добавьте новую Job типа Pipeline.

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

   Pipeline->Definition->Pipeline script from SCM->GIT->Repositories
   

3. Укажите ветку для репозитория со скриптами развертывания(например */master):

   Pipeline->Definition->Pipeline script from SCM->GIT->Branches to build
   

4. Укажите файл deploy.groovy для запуска (в данном файле необходимо обратить внимание на наименование агента, с помощью которого будет производиться сборка):

   Pipeline->Definition->Script Path
   

5. Запустите Job (собрать сейчас), дождитесь окончания и перезагрузите страницу. Job создана и автоматически конфигурирована.

Инициализация PostgreSQL#

Этот шаг выполнять только при выполнении всех условий:

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

• Для TCP соединений используется порт 5432;

• Для исполнения команд возможно подключение к PostgreSQL под пользователем postgres;

• Файл UNIX-сокета должен располагаться в файле /tmp/.s.PGSQL.5432.

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

1. Запустите подготовленный выше Jenkins Pipeline, нажав кнопку Собрать с параметрами.

2. Выставите параметры:

   • NODE: Метка агента, на котором будет запускаться сборка;

   • TAGS: DB;

   • VERSION: версия дистрибутива (например SP-2.30.0);

   • STEND: dzo_DEV_Mock;

   • NEXUS_URL: URL репозитория солюшена;

   • GROUP_ID: GROUP_ID солюшена;

   • ARTIFACT_ID: ARTIFACT_ID солюшена;

   • NEXUS_CREDS: Учетная запись от Nexus, для скачивания солюшена.

3. Нажмите кнопку Собрать.

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

Первичная настройка КТС#

1. Запустите подготовленный выше Jenkins Pipeline, нажав кнопку Собрать с параметрами.

2. Выставите параметры:

   • NODE: Метка агента, на котором будет запускаться сборка;

   • TAGS: SERVICE;

   • VERSION: версия дистрибутива (например SP-2.30.0);

   • STEND: dzo_DEV_Mock;

   • NEXUS_URL: URL репозитория солюшена;

   • GROUP_ID: GROUP_ID солюшена;

   • ARTIFACT_ID: ARTIFACT_ID солюшена;

   • NEXUS_CREDS: Учетная запись от Nexus, для скачивания солюшена.

3. Нажмите кнопку Собрать.

В результате выполнения будут установлено необходимое ПО на КТС и созданы сервисы для дальнейшего запуска Mock app.

Установка Mock#

1. Запустите подготовленный выше Jenkins Pipeline, нажав кнопку Собрать с параметрами.

2. Выставите параметры:

   • NODE: Метка агента, на котором будет запускаться сборка;

   • TAGS: DEPLOY;

   • VERSION: версия дистрибутива (например SP-2.30.0);

   • STEND: dzo_DEV_Mock;

   • NEXUS_URL: URL репозитория солюшена;

   • GROUP_ID: GROUP_ID солюшена;

   • ARTIFACT_ID: ARTIFACT_ID солюшена;

   • NEXUS_CREDS: Учетная запись от Nexus, для скачивания солюшена.

3. Нажмите кнопку Собрать.

В результате выполнения будут развернуты (запущены) все приложения Mock.

Перезапуск Mock#

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

1. Запустите подготовленный выше Jenkins Pipeline, нажав кнопку Собрать с параметрами.

2. Выставите параметры:

   • NODE: Метка агента, на котором будет запускаться сборка;

   • TAGS: RESTART;

   • VERSION: версия дистрибутива (например SP-2.30.0);

   • STEND: dzo_DEV_Mock;

   • NEXUS_URL: URL репозитория солюшена;

   • GROUP_ID: GROUP_ID солюшена;

   • ARTIFACT_ID: ARTIFACT_ID солюшена;

   • NEXUS_CREDS: Учетная запись от Nexus, для скачивания солюшена.

3. Нажмите кнопку Собрать.

Ручная установка#

Инициализация PostgreSQL#

Чтобы подготовить PostgreSQL для работы с приложением, необходимо последовательно выполнить следующие шаги:

1. Подключиться к БД.

   Если имеется SSH доступ на КТС с БД и возможность повысить привилегии до root, то для создания пользователей БД можно воспользоваться утилитой psql:

   1. Зайдите на КТС по SSH.

   2. Повысьте привилегии до root. Для этого в оболочке (shell) выполните команду sudo -s. При необходимости введите пароль.

   3. Переключитесь на пользователя postgres: su - postgres.

   4. Выполните команду psql. Если приложение не найдено, вызовите по абсолютному пути: /usr/local/pgsql/bin/psql.

2. Создать пользователя, который будет владельцем БД и схемы приложения:

   CREATE ROLE meta_mock_owner;
   CREATE USER meta_mock_admin LOGIN PASSWORD 'db.owner-password' IN ROLE meta_mock_owner;
   

3. Создать пользователя, под которым приложение будет подключаться к БД приложения:

   CREATE ROLE mock_cloud_app;
   CREATE USER meta_mock LOGIN PASSWORD 'db.password' IN ROLE mock_cloud_app;
   

4. Создать БД приложения, назначив meta_mock_owner владельцем:

   CREATE DATABASE metamockdb OWNER meta_mock_owner ENCODING 'UTF-8';
   

5. Создать схему в БД приложения, назначив meta_mock_owner владельцем:

   CREATE SCHEMA meta_mock AUTHORIZATION meta_mock_admin;
   

6. Выдать права доступа к БД и схеме прикладному пользователю:

   GRANT CONNECT ON DATABASE metamockdb TO meta_mock;
   GRANT USAGE ON SCHEMA meta_mock TO mock_cloud_app;
   

7. Задать пользователям пути поиска:

   ALTER USER meta_mock_admin SET search_path = meta_mock, public;
   ALTER USER meta_mock SET search_path = meta_mock;
   

8. Для выхода из psql использовать команду \q

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

1. Откройте файл pg_hba.conf на редактирование. Редактировать файл нужно от системного (linux) пользователя postgres.

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

   psql -t -P format=unaligned -c 'show hba_file';
   

2. Добавьте в hb_pga.conf следующую строку:

   host metamockdb meta_mock_admin, meta_mock 0.0.0.0/0 scram-sha-256
   

   Где:

   • host - означает, что вход в систему будет производиться с другого хоста;

   • metamockdb - созданная БД;

   • meta_mock_admin, meta_mock - созданные пользователи;

   • 0.0.0.0/0 - разрешенный диапазон хостов (0.0.0.0/0 говорит, что вход разрешен с любого хоста);

   • scram-sha-256 - способ аутентификации по паролю.

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

   Обратите внимание
   Записи в файле pg_hba.conf не должны быть противоречивы. В противном случае PostgreSQL может не подняться при рестарте.

3. После изменений внесенных в pg_hba.conf необходим рестарт базы, так как он не будет перечитан динамически:

   <DB_BIN>/pg_ctl restart -D <DB_INSTALL>
   

Установка сервера приложений JVM#

Выполните следующие шаги для конфигурирования сервера приложений JVM.

1. Установите Java в соответствии с требованиями к аппаратным ресурсам среды. Пример команды:

   -$su- #yum install - y java - 1.8.0 - openjdk.x86_64
   

2. Проверьте версию, используя следующую команду:

   - java -version
   

3. Создайте пользователя <USER_JVM> или используйте существующего.

4. Создайте директорию для установки Mock:

   sudo mkdir <MOCK_INSTALL>;
   

5. Выдайте пользователям необходимые привилегии:

   sudo chown -R <USER_JVM>:<USER_JVM> <MOCK_INSTALL> # Перейдите в директорию <MOCK_INSTALL>
   

Установка сервиса запуска приложений#

1. Перенесите архив mock-front на Nginx UI сервер для дальнейшей распаковки и установки.

2. Перенесите jar файлы из архива pvwmct-SP-{VERSION}-owned-distrib/package/bh на целевой сервер для последующего запуска.

3. Настройте и запустите сервисы.

Настройка сервиса eureka#

Скопируйте файл eureka.service в директорию /etc/systemd/system и замените параметры:

Скопируйте из поставки файл eureka-server-app.jar и разместите по абсолютному пути _{{MOCK.EUREKA.DIR}}/{{MOCK.EUREKA.FILE}}.

Для запуска службы используйте следующую команду:

systemctl start eureka.service

Настройка сервиса mock-basic-proxy#

Скопируйте файл mock-basic-proxy.service в директорию /etc/systemd/system и замените параметры:

Скопируйте из поставки файл sbermock-basic-proxy-server.jar и разместите по абсолютному пути _{{MOCK.BASICPROXY.DIR}}/{{MOCK.BASICPROXY.FILE}}.

Для запуска службы используйте следующую команду:

systemctl start basic-proxy-server.service

Настройка сервиса mock-core#

Скопируйте файл mock-core.service в директорию /etc/systemd/system и замените параметры:

Скопируйте из поставки файл mock-core-app.jar и разместите по абсолютному пути _{{MOCK.CORE.DIR}}/{{MOCK.CORE.FILE}}.

Для запуска службы используйте следующую команду:

systemctl start mock-core-app.service

Настройка сервиса mock-audit-elk#

Скопируйте файл mock-audit-elk.service в директорию /etc/systemd/system и замените параметры:

Скопируйте из поставки файл mock-audit-elk-app.jar и разместите по абсолютному пути _{{MOCK.AUDITELK.DIR}}/{{MOCK.AUDITELK.FILE}}.

Для запуска службы используйте следующую команду:

systemctl start mock-audit-elk.service

Настройка сервиса mock-transport-manager#

Скопируйте файл mock-transport-manager.service в директорию /etc/systemd/system и замените параметры:

1. Скопировать из поставки файл mock-transport-manager-app.jar и разместить по абсолютному пути {{MOCK.TRANSPORTMANAGER.DIR}}/{{MOCK.TRANSPORTMANAGER.FILE}};

2. Скопировать из поставки файл mock-rest-cloud-app.jar и разместить по абсолютному пути {{MOCK.TRANSPORTMANAGER.DIR}}/{{MOCK.REST.FILE}};

3. Скопировать из поставки файл mock-esb-ibm-app.jar и разместить по абсолютному пути {{MOCK.TRANSPORTMANAGER.DIR}}/{{MOCK.ESB.FILE}};

4. Скопировать из поставки файл mock-kafka-app.jar и разместить по абсолютному пути {{MOCK.TRANSPORTMANAGER.DIR}}/{{MOCK.KAFKA.FILE}}.

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

systemctl start mock_transport-manager.service

Настройка сервиса mock-cloud#

Скопировать файл mock-cloud.service в директорию /etc/systemd/system и заменить параметры:

Скопируйте из поставки файл mock-cloud.jar и разместите по абсолютному пути {{MOCK.CLOUD.DIR}}/{{MOCK.CLOUD.FILE}}.

Для запуска службы используйте следующую команду:

systemctl start mock-cloud.service

Установка mock-front#

1. Перейдите на сервер с установленным Nginx.

2. Распакуйте содержимое файла /package/pl/mock-front-{ver}-dist.zip из дистрибутива поставки в директорию /var/mockfront/html.

Использование дополнительного СПО#

Prometheus#

В случае необходимости использования Prometheus установите и настройте его в соответствии с официальной документацией данного СПО.

Интеграция с Prometheus включена в следующих сервисах:

• mock-cloud

• mock-core-app

• mock-audit-elk-app

• mock-transport-manager-app

• mock-rest-cloud-app

Filebeat#

В случае необходимости использования Filebeat установите и настройте его в соответствии с официальной документацией данного СПО.

Файл аудита по умолчанию располагается на сервере Mock в директории /tmp/logs/mock-audit-elk-app.log.

Запуск в контейнерах#

Общая схема сборки образов:

1. Скопировать директорию package из архива pvwmct-{VERSION}-owned-distrib на целевой сервер с docker;

2. Перейти на целевом сервере в скопированную директорию package/bh;

3. Задать переменные окружения:

   • VERSION версия дистрибутива. Например, SP-2.30.0;

   • BASE_IMAGE базовый docker-образ с java 1.8.

4. Собрать образы командой:

   docker build -t "eureka-server-app:${VERSION}" --build-arg "BASE_IMAGE=${BASE_IMAGE}" . -f ../docker/eureka_server_app/Dockerfile
   docker build -t "sbermock-basic-proxy-server:${VERSION}" --build-arg "BASE_IMAGE=${BASE_IMAGE}" . -f ../docker/mock_basic_proxy/Dockerfile
   docker build -t "mock-audit-elk-app:${VERSION}" --build-arg "BASE_IMAGE=${BASE_IMAGE}" . -f ../docker/mock_audit_elk_app/Dockerfile
   docker build -t "mock-core-app:${VERSION}" --build-arg "BASE_IMAGE=${BASE_IMAGE}" . -f ../docker/mock_core/Dockerfile
   docker build -t "mock-transport-manager-app:${VERSION}" --build-arg "BASE_IMAGE=${BASE_IMAGE}" . -f ../docker/mock_transport_manager_app/Dockerfile
   docker build -t "mock-cloud:${VERSION}" --build-arg "BASE_IMAGE=${BASE_IMAGE}" . -f ../docker/mock_cloud/Dockerfile
   

При запуске контейнеров для каждого образа необходимо задать его ENV переменные. Для docker-compose они задаются в формате:

    environment:
      - SPRING_KAFKA_BOOTSTRAP_SERVERS=host.docker.internal:9092
      - EUREKA_CLIENT_SERVICE_URL_DEFAULT_ZONE=http://host.docker.internal:8761/eureka

ENV переменные для каждого сервиса приведены далее.

Параметры образа eureka-server-app#

Параметры образа sbermock-basic-proxy-server#

Параметры образа mock-audit-elk-app#

Параметры образа mock-core-app#

При запуске контейнера требуется передать в него файлы сертификатов. Сертификаты описаны в разделе «Установка сертификатов для эмуляций». Для docker-compose они задаются в формате:

    volumes:
      - /etc/ssl/certs/certsCollection.pem:/certsCollection.pem
      - /etc/ssl/certs/client.pem:/client.pem
      - /etc/ssl/certs/client_private_key.pem:/client_private_key.pem

Параметры образа mock-transport-manager-app#

Приложение использует порты 8082 и 9090.

При запуске контейнера требуется передать в него файлы сертификатов. Сертификаты описаны в разделе «Установка сертификатов для эмуляций». Для docker-compose они задаются в формате:

    volumes:
      - /etc/ssl/certs/certsCollection.pem:/certsCollection.pem
      - /etc/ssl/certs/client.pem:/client.pem
      - /etc/ssl/certs/client_private_key.pem:/client_private_key.pem

Параметры образа mock-cloud#

Образ mock-front#

При необходимости использовать docker для mock-front повторите инструкцию по развертыванию на сервере с Nginx с использованием базового образа с установленным Nginx.