Руководство по установке#

В руководстве приведены инструкции по установке программного компонента Deploy tools (CDJE) программного продукта Platform V DevOps Tools (DOT).

Термины и определения#

Системные требования#

Настройки безопасности окружения и перечень платформенных (дополнительных внешних) продуктов, используемых для установки, настройки и контроля в конечной информационной системе (далее — ИС), выбираются при разработке конечной ИС, исходя из характера обрабатываемой в ней информации и иных требований информационной безопасности (далее — ИБ), предъявляемых к ней.

Системное программное обеспечение#

Ниже представлены категории системного программного обеспечения, которые обязательны для установки, настройки, контроля и функционирования программного компонента. В каждой категории перечислены все поддерживаемые продукты сторонних правообладателей. Отдельно обозначены варианты, которые рекомендует АО «СберТех» (маркировка «Рекомендовано» в столбце Комментарий). Клиенту необходимо выбрать один из продуктов в каждой категории, исходя из условий использования конечной ИС.

Категории системного программного обеспечения, представленные ниже, обязательны для установки, настройки, контроля и функционирования компонента. В рамках каждой категории перечислены все поддерживаемые системные программы сторонних правообладателей, в том числе рекомендованные АО «СберТех». Выбор системной программы в каждой категории остается на стороне клиента (пользователя):

Системные требования#

Примечание:

*

• Да — категория ПО обязательна для функционирования сервиса (это означает, что сервис не может выполнять свои основные функции без установки данной категории ПО).

• Нет — категория ПО необязательна для функционирования сервиса (это означает, что сервис может выполнять свои основные функции без установки данной категории ПО).

**

• Рекомендовано — рекомендованный правообладателем АО «СберТех» продукт.

• Опционально — альтернативный по отношению к рекомендованному правообладателем АО «СберТех» продукт.

Также, перед началом работы на Jenkins Nodes должны быть установлены следующие утилиты:

• yq – версии не ниже чем: 4.25.3;

• jq – версии не ниже чем: 1.6

⚠️ Важно – При работе со средой контейнеризации также необходима установка набора Jenkins плагинов для корректного функционирования программного компонента:

ℹ️ Важно – для исправной работы c pipeline необходимо, чтобы версия используемого СПО соответствовала поддерживаемой:

• Kubernetes – (не ниже) kubectl_v1.22.7x.

  • Kustomize – v4.5.4.

  • Helm – 3.8.2.

• OpenSSL – 1.0.

У программного компонента Deploy tools отсутствуют собственные/встроенные механизмы защиты данных и нет интеграции с соответствующими платформенными сервисами (функциональными подсистемами). В процессе создания конечной информационной системы её архитектору/разработчику необходимо самостоятельно выбирать платформенные механизмы защиты данных с учетом требований к уровню конфиденциальности обрабатываемой информации, требований внутренних документов, отраслевых/национальных/международных стандартов, требований уполномоченных регуляторов, национального законодательства и лучших практик.

Аппаратные требования#

Поскольку программный компонент представляет собой скрипты и конфигурации, хранящиеся (GitLab/BitBucket) и обрабатываемые (Jenkins) сторонними функциональными подсистемами, особых аппаратных требований к нему не предъявляется. Заказчиком самостоятельно определяются аппаратные мощности для развертывания и функционирования собственного решения, с помощью описываемого программного компонента CDJE, в зависимости от назначения ФП и требований к его архитектуре.

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

Подготовка окружения#

1. Наличие у пользователя, производящего установку возможности создания репозиториев в GitLab/BitBucket, Nexus и получения прав на чтение/запись, включая права на чтение/запись в ветке master.

2. Наличие ТУЗ для работы с репозиториями:

   • для чтения/записи репозиториев в GitLab/BitBucket по протоколу SSH, например, ТУЗ: Domen\\TENGRI;

   • для чтения/записи репозиториев в Nexus и GitLab/BitBucket по протоколу HTTP, например, ТУЗ: Domen\\CABSATENGRI10.

3. Должны быть созданы следующие репозитории GitLab/BitBucket (например в такой проектной области, как CI02587203):

   a) Репозитории pipeline, например:

   • CI00380023_efs_tengri_pipeline — репозиторий с кодовой базой релизов pipeline (на каждый стенд свой репозиторий, например CI00380023_efs_tengri_pipeline_ift / CI00380023_efs_tengri_pipeline_psi);

   • CI00380023_efs_tengri_common — репозиторий с глобальными (одинаковыми для всех компонент в рамках одного стенда) переменными среды (на каждый стенд свой репозиторий, например CI00380023_efs_tengri_common_ift / CI00380023_efs_tengri_common_psi);

   • CI00380023_efs_releases — репозиторий для версионирования версий ФП (один общий на все стенды).

   b) Репозитории с конфигурациями функциональных подсистем, например:

   • CI00380023_efs_tengri_indicator (на каждый стенд свой репозиторий);

   • CI00380023_efs_tengri_osiris (на каждый стенд свой репозиторий);

   • CI00380023_efs_tengri_unimon (на каждый стенд свой репозиторий).

4. Должны быть прописаны доступы в репозитории по протоколам SSH + HTTP на чтение/запись во все ветки, в т.ч. в ветку master.

5. В Nexus должны быть размещены дистрибутивы разворачиваемых функциональных подсистем, к данным репозиториям должен быть доступ с правами на чтение для ТУЗ: Domen\\CABSATENGRI10.

6. В Nexus должны быть созданы следующие репозитории, в которые загружены дистрибутивы всех компонентов pipeline (Installer.Migration, Installer.Common):

   • Installer.Migration — дистрибутив утилиты миграции;

   • Installer.Common — базовый дистрибутив common — это глобальные параметры по умолчанию для pipeline.

   К перечисленным в п.6 репозиториям должен быть доступ с правами на чтение для ТУЗ: Domen\\CABSATENGRI10.

7. В GitLab/BitBucket должны быть созданы следующие репозитории, в которые загружены дистрибутивы всех компонентов pipeline (ci00380023_efs_pipeline, ci00380023_efs_scripts):

   • <Например: доменное имя используемого репозитория в GitLab/BitBucket>/CI00428440/repos/ci00380023_efs_pipeline/browse;

   • <Например: доменное имя используемого репозитория в GitLab/BitBucket>/CI00428440/repos/ci00380023_efs_scripts/browse.

   К перечисленным в п.7 репозиториям должен быть доступ с правами на чтение для ТУЗ Domen\\TENGRI.

Установка#

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

Создание Jenkins job инструментов развертывания#

Предусмотрены следующие инструменты развёртывания:

• JOB Service — Jenkins job обновления (первичная загрузка кода Deploy на полигон, обновление кода JOB Deploy при выпуске новых релизов Deploy job);

• JOB Deploy — Jenkins job развертывания дистрибутивов.

Данная инструкция описана для создания одного экземпляра набора Jenkins job. На каждый фрагмент контура платформы создается отдельный набор job.

Создание Service job#

Service job предназначен для миграции кодовой базы Pipeline и параметров Common на стенд.

ℹ️ Пререквизиты:

• Проектная область в Jenkins c правами на создание Jenkins job;

• заведенные параметры УЗ (credentials) Jenkins и GitLab/Bitbucket.

Создание и взаимодействие с реквизитами в Jenkins:

• Username with password - Логин + Пароль реквизитов для работы с API Nexus, Bitbucket или Jenkins.
  
  Например: получение списка веток или скачивания артефактов из Nexus.
  В качестве ID необходимо указать user_pass_tech – при указании отличного ID от этого, необходимо будет произвести дополнительную настройку в Service job (CUSTOM_USER_PASS_CREDS) и в файле environment.json.
  В качестве логина указать Логин используемого ТУЗ, а в качестве пароля – Пароль от ТУЗ, описание на усмотрение.

• SSH with private key – реквизиты для доступа к Bitbucket с помощью SSH ключа.
  
  Для данного способа необходимо сгенерировать SSH ключ: приватный и публичный:
  В качестве ID необходимо указать git_ssh_tech – при указании отличного ID от данного, необходимо будет произвести дополнительную настройку в Service job (GIT_CRED) и в файле environment.json, в качестве логина – Логин используемого ТУЗ, а для приватного ключа – содержимое файла id_rsa.ppk (приватный ключ), полученного в ходе генерации SSH ключа.
  Если в ходе генерации SSH ключа вы указали пароль, его необходимо ввести в поле Passphrase, поле Описание заполнить на усмотрение.
  Дополнительно необходимо добавить используемому ТУЗ публичную часть SSH ключа в Bitbucket (см. официальную инструкцию Bitbucket – Step 3.)

• Secret Text cred - секретный пароль для работы с файлом.

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

В завершении в Bitbucket для используемого ТУЗ необходимо добавить публичную часть сгенерированного SSH ключа (см. пункт SSH with private key).

В инсталляции Jenkins создайте новый job с типом pipeline:

1. Нажмите на кнопку New item ;

2. Создайте новый job с типом pipeline (название в поле Enter an item name — любое удобное).

Заполнение параметров на вкладках:

Заполнение параметров на вкладках:

1. Вкладка Pipeline:

   

   Параметры:

   • Repository URL: ssh://<bitbucket_address>/ci00428440/ci00380023_efs_pipeline.git

   • Branch Specifier: service

   • Script Path: deploy-fpi-service.groovy

2. Вкладка Build triggers:

   

   Параметры:

   • ENVIR=mmv — наименование стенда (условное название стенда, например mmv или ift — должно совпадать с суффиксом созданных репозиториев);

   • NODE=EFS — Агент Jenkins, на котором будет произведен запуск (приведен пример значения);

   • CONFIG_DIR_LIST=main:main (здесь main — директория конфигурации стенда. Директория конфигурации в общем случае может быть только одна).

   • CHANNEL=tengri — используемый канал. Используется для идентификации принадлежности к продукту (приведен пример значения);

   • GIT_URL=ssh://<SCM_address>/CI02587203 — проектная область стенда в SCM системе

После задания всех необходимых параметров проведите реконфигурацию Jenkins job — для этого выполните запуск Service job без параметров.

Проведение последовательной миграции pipeline, subsystems, common#

Сценарии использования Service job:

1. PIPELINE:

   • MIGRATION — миграция кода/библиотек pipeline, а так же миграция основного файла конфигураций на стенд (environment.json_);

   • MIGRATION_DEPLOY_SCRIPTS — миграция скриптов запуска для Jenkins job;

   • JOBS_RECONF_ALL — реконфигурация Jenkins job, указанных в файле JenkinsJobs.conf .

2. COMMON:

   • MIGRATION — миграция файлов из дистрибутива common в репозиторий common;

   • MIGRATION_SUBSYSTEMS — миграция файлов конфигураций устанавливаемых компонентов (subsystems.json_).

3. PIPELINE_AT:

   • MIGRATION — миграция кода/библиотек pipeline AT (Job автотестов).

4. PIPELINE_ORCH:

   • MIGRATION — миграция кода/библиотек pipeline ORCH (Job оркестрации).

5. PIPELINE_SCHEDULER:

   • MIGRATION — миграция кода/библиотек pipeline scheduler (AutoInstaller job).

6. PIPELINE_EXTENSIONS:

   • MIGRATION — миграция кода/библиотек pipeline extensions (Точки расширения для Pipeline).

1. Pipeline:

Запустите Service job со следующими параметрами для обновления версии pipeline:

Входные параметры:

• CONFIG_DIR : main (main — блок, на который будет проводиться миграция Pipeline)

• ARTIFACT_TYPE : PIPELINE

• ARTIFACT_VERSION : release/D-01.038.172-11404 (приведен пример значения)

• PARAMS : MIGRATION, MIGRATE_DEPLOY_SCRIPTS

Результат:

В репозитории common отобразится набор файлов (если был задан параметр CONFIG_DIR, то файлы будут расположены в указанной в нём директории):

• environment.json — основной конфигурационный файл Pipeline (создается, если ранее отсутствовал, если есть, то мигрируется). Мигрируется при помощи environment.json из релиза.

• version.conf — версии (pipeline, common, ansible scripts) (создается, если ранее отсутствовал, если есть, то мигрируется);

В репозитории Pipeline происходит следующее:

• Ветка master обновится до состояния сервисной ветки, в которой хранятся загрузчик разделяемой библиотеки для всех Jenkins jobs развертывания (deploy-fpi.\*.groovy).

• Ветка release/D-01.038.172-11404 создастся (номер ветки — это значение, которое было указано в ARTIFACT_VERSION).

• version.conf содержит корректную версию Pipeline (release/D-01.038.172-11404 — номер ветки — это значение, которое было указано в ARTIFACT_VERSION);

• В файле environment.json обновлены блоки: main и _default.

2. Subsystems:

Запустите Service job со следующими параметрами:

Входные параметры:

• CONFIG_DIR : main

• ARTIFACT_TYPE : COMMON

• ARTIFACT_VERSION : D-01-001.00.313 (приведен пример значения)

• PARAMS : MIGRATION_SUBSYSTEMS

Результат:

В репозитории common отобразится следующий набор файлов (если был задан параметр CONFIG_DIR, то файлы будут расположены в указанной в нём директории):

• subsystems.json — список конфигураций ФП для Deploy job (создается, если ранее отсутствовал, если есть, то мигрируется). Мигрируется из релиза сервисной ветки.

3. Common:

Запустите Service job со следующими параметрами:

Входные параметры:

• CONFIG_DIR : main

• ARTIFACT_TYPE : COMMON

• ARTIFACT_VERSION : D-01-001.00.313 (приведен пример значения)

• PARAMS : MIGRATION

Результат: в репозитории с common в директории main появятся две папки ansible и installer.

Настройка глобальных параметров#

Используемое имя efs_tengri — это пример наименование репозитория выбранного в примерах ранее.

a) в репозитории CI00380023_efs_tengri_common откройте файл environment.json в блоке main и переопределите параметры:

• "efsReleaseRepo": "https://<bitbucket_projects_address>/CI00428440/repos/ci00380023_efs_releases" — это пример, здесь необходимо указать ссылку на свой репозиторий с ci00380023_efs_releases;

• "iag": "true";

• "openshiftMultiClusters": "true";

• "useMavenForDownload": "true";

• "openshiftRegistry": "http://<registry_address>/ci02587203/ci02809205_tengri" — это пример, здесь необходимо указать ссылку на свой проект в OSE.

b) в репозитории CI00380023_efs_tengri_common откройте файл subsystems.json и заполните параметры:

{  
   "__default":
    {   			        // Блок настроек по умолчанию.
      "classifier": "distrib",  	        // Классификатор дистрибутива ФП в хранилище Nexus
      "groupId": "Nexus_PROD",  	        // Group ID дистрибутива ФП в хранилище Nexus
      "packaging": "zip",  		        // Расширение файла с дистрибутивом ФП
      "strict": "false",  		        // Режим миграции настроек ФП (true - будут мигрировать только файлы, начинающиеся на <fpi_name>, false - все конфигурационные файлы)
      "sqlReport": "false",  
      "limit": 200,  				        // Ограничение кол-ва версий дистрибутива в меню Jenkins
      "deployType": "manual",  	        // Тип автоматического деплоя (parallel - параллельный, consistently - последовательный)
      "fpType": "p69",  			        // Указываем тип приложения для фильтрации в джобе. 
      "openshiftProject": "",  
      "at": {  					        // Блок с реквизитами дистрибутива API-автотестов по умолчанию
         "groupId": "Nexus_PROD",  	        // Group ID дистрибутива API-автотестов
         "branch": "master",  		        // Ветка репозитория с настройками API-автотестов по умолчанию
         "classifier": "distrib",  	        // Классификатор дистрибутива API-автотестов по умолчанию
         "packaging": "zip"  		        // Расширение дистрибутива API-автотестов по умолчанию
      },  
      "at_ui": {  				        // Блок с реквизитами дистрибутива UI-автотестов по умолчанию
      "groupId": "Nexus_PROD",  	        // Group ID дистрибутива UI-автотестов
      "branch": "master",  		        // Ветка репозитория с настройками UI-автотестов по умолчанию
      "classifier": "distrib",  	        // Классификатор дистрибутива UI-автотестов по умолчанию
      "packaging": "zip"  		        // Расширение дистрибутива UI-автотестов по умолчанию
      }  
    },  
    "INDICATOR":
    {  
      "fpType": "bts",  					// Указываем тип приложения для фильтрации в Jenkins job. Для выбора нескольких вариантов указываем в настройках джобы FP_TYPE_FILTER=bts, bfs
      "fpi_name": "indicator",  			// Название ФП в Инсталяторе
      "artifactId": "PVM_Indicator",  
      "groupId": "Nexus_PROD.CI02809205_tengri_new_main",  
      "versionFilter": "D-01"  
    }  
}

c) в репозитории CI00380023_efs_tengri_common откройте installer/system/efs/config/parameters файл _global.resources.conf и заполните параметры значениями host в соответствии с архитектурой развертываемого стенда, либо сделайте заглушки, например:

Пример с заглушками (dummy)
# mm — межмодульное взаимодействие
global.default.nlb_mm.host=dummy 
# ii — интеграционное взаимодействие (для импорта)
global.default.nlb_ii.host=dummy  
# bh — бизнес хаб
global.default.nlb_bh.host=dummy

пример с хостами
# адрес балансировщика  без протокола и порта
# mm — межмодульное взаимодействие
global.default.nlb_mm.host=tkli-efs11692.<domain_address>
# ii — интеграционное взаимодействие (для импорта)
global.default.nlb_ii.host=tkli-efs11693.<domain_address>
# bh — бизнес хаб
global.default.nlb_bh.host=tkli-efs11695.<domain_address>

d) в репозитории CI00380023_efs_tengri_common откройте файл multiClusters.json и заполните параметры:

Пример:

{  
 "datacenters":
 {  
   "megacod":
   {  
      "openshiftCluster": "[https://<api_dev_address>](https://<api_dev_address>/)",   		// Адрес вашего OSE кластера 1
      "openshiftSATokenCred": "ose_token_cred_ift",  											// Имя jenkins cred (тип - secret text), содержащего токен сервисной учетной записи сервисного проекта вашего OSE кластера 1. Используется для доступа к API OpenShift.
      "openshiftProjectName": "ci02587203-i-as-tengri-solution",  							// Имя вашего проекта в OSE в кластере 1
      "openshiftAppsDomain": "[<sh1_dev_address>](http://<sh1_dev_address>/)",  				// Суффикс домена для сервисов вашего кластера. Значение этого параметра подставляется в параметр {{appsDomain}} в конфигурации развертывания OSE в процессе развертывания.
      "openshiftWebConsole": "<https://<console_openshift_address>/k8s/cluster/projects>", 	// Ссылка на кластер опеншифта для формирования корректной ссылки на проект в описании Deploy job 
      "openshiftRoutersFQDN": \[ '1.1.1.1' \]  												// Fully qualified domain name или ip адрес роутера/ов OpenShift. Этот адрес можно узнать у ЦИ. Либо, на средах до ПСИ, можно попробовать сделать ping любому routes в проекте. Все пути внутри проекта (скорее, кластера) по wildcards резолвятся в один или более адресов нод, на которых располагаются HAProxy OpenShift (или, возможно, в балансировщик перед этими nod'ами).
   }  
 }  
}

e) Отредактируйте файлы secret.yml (зашифрованный файл, содержащий нераскрываемую информацию) и _password.conf (файлы размещены в директории/ansible):

• secret.yml (пароли от БД/WAS/Шлюзы) — зависит от диаграммы развертывания разворачиваемого сервиса;

• _password.conf (секреты для OSE);

Шифрование данных конфигурационных файлов необходимо производить на сервере с установленными openssl и ansible.

Шифрование _passwords.conf производится следующими командами:

• для шифрования используйте: openssl enc -aes-256-cbc -md md5 -salt -in _passwords_d.conf -out _passwords.conf

• для расшифровывания используйте: openssl enc -aes-256-cbc -md md5 -salt -in _passwords.conf -out _passwords_d.conf -d

Шифрование secret.yml производится следующими командами:

• для шифрования используйте: ansible-vault encrypt secret.yml

• для расшифровывания используйте: ansible-vault decrypt secret.yml

⚠️ Важно! – При шифровании файлов будет запрошен пароль. Этот пароль необходимо придумать самостоятельно. Пароль по сложности, длине, уникальности и периодичности замены должен соответствовать установленным в организации требованиям. Пароль необходимо запомнить и добавить credentials с данным паролем в Jenkins (тип secret text). ID данных credential требуется прописать в файле environment.json в разделе вашего стенда:

• "ansible_vault_id": "encrypt_secret" — ID данных credential с паролем, которым был зашифрован файл secret.yml (ID может быть любым, здесь в значении параметра приведен пример);

• "openshiftOpsPasswordsCred": "encrypt_pass" — ID данных credential с паролем, которым зашифрован файл passwords.conf (ID может быть любым, здесь в значении параметра приведен пример).

f) Создайте credentials в проектной области, в которой производится настройка job следующих типов:

• для ТУЗ: Domen\\TENGRI (ТУЗ указан для примера) создайте credentials в jenkins типа SSH Username with private key в нем укажите приватный ключ + Passphrase (если есть) от ТУЗ: Domen\\TENGRI;

• для ТУЗ: Domen\\CABSATENGRI10 (ТУЗ указан для примера) создайте credentials в jenkins типа Username with password в нем укажите логин/пароль от ТУЗ: Domen\\CABSATENGRI10.

Чтобы создать credentials для входа:

1. В файле environment.json переопределите для своей среды секцию credentials (скопируйте значение из блока default).

2. Для credentials SshKeyCreds и UserPassCreds переопределите id, которые были созданы ранее (SshKeyCreds = id от jenkins credentials TENGRI, UserPassCreds = id от jenkins credentials CABSATENGRI10).

Пример:

   "ift": {                               // Настройки среды "ift". 
   "credentials": {                       // Настройки Credential ID
   "SshKeyCreds": "pipeline_git_ssh",     // Credential ID для доступа в репозитории Git с использованием ssh-ключей (ssh ключ)
   "UserPassCreds": "697864ec-a6f8-40d7-a68c-9402566ecaa8",  	// Credential ID для доступа в хранилище Nexus с ипользованием base аутентификации (логин/пароль)
}

Создание Deploy job#

Deploy job предназначен для установки приложения на стенд.

Пререквизиты:

• Проектная область в Jenkins c правами на создание job.

В инсталляции Jenkins создайте Jenkins job – тип pipeline:

• Нажмите New item ;

• Создайте item с типом pipeline (название в поле Enter an item name — любое удобное).

Заполните параметры на вкладках:

1. Вкладка Pipeline:

В области Definition выберите Pipeline scripts from SCM → в SCM выберите Git и заполните параметры:

• Repositories — созданный ранее репозиторий CI00380023_efs_tengri_pipeline — репозиторий с кодовой базой релизов pipeline (см. раздел Пререквизиты для установки);

• Credentials — созданный ранее credentials jenkins SshKeyCreds (см. раздел Пререквизиты для установки);

• Script Path — deploy-fpi.groovy.

  

  

2. Вкладка Build triggers:

   • Выбрать опцию Prepare an environment for the run;

   • В поле Properties Content задать следующие параметры:

     • NODE=Linux_Default || kubernetes || openshift (slave jenkins, на которых будет выполняться операция развертывания)

     • ENVIR=ift (стенд)

     • CONFIG_DIR_LIST=main:main (блок стенда) — любое удобное наименование

     • CHANNEL=tengri (сегмент) — любое удобное наименование

     • SCRIPTS_GIT_URL=ssh://git@<GitLab/BitBucket>/CI00000110 – SSH путь до проектной области репозитория Ansible-скриптов (см. пункт 7. → раздел Подготовка окружения).

   

Нажмите Сохранить, после чего необходимо будет провести реконфигурацию Jenkins job (действие Собрать сейчас), будет проведена реконфигурация, по завершении которой появятся параметры для запуска Jenkins job.

Настройка закончена. Можно выполнять установку приложения.

Создание ELK job#

ELK job предназначен для установки компонентов Elastic Search (далее ELK).

Пререквизиты:

• Проектная область в Jenkins c правами на создание job.

В инсталляции Jenkins создайте новый Jenkins job – тип pipeline:

• Нажмите New item;

• Создайте item с типом pipeline (название в поле Enter an item name — любое удобное).

Заполните параметры на вкладках:

1. Вкладка Pipeline:

В области Definition выберите Pipeline scripts from SCM → в SCM выберите Git и заполните параметры:

• Repositories — созданный ранее репозиторий CI00380023_efs_tengri_pipeline — репозиторий с кодовой базой релизов pipeline (см. раздел Пререквизиты для установки);

• Credentials — созданный ранее credentials jenkins SshKeyCreds (см. раздел Пререквизиты для установки);

• Script Path — deploy-fpi-elasticsearch.groovy.

  

2. Вкладка Build triggers:

   • Выбрать опцию Prepare an environment for the run;

   • В поле Properties Content задать следующие параметры:

     • NODE=Linux_Default || kubernetes || openshift (slave jenkins, на которых будет выполняться операция развертывания)

     • ENVIR=ift (стенд)

     • CONFIG_DIR_LIST=main:main (блок стенда) — любое удобное наименование

     • CHANNEL=tengri (сегмент) — любое удобное наименование

     • SCRIPTS_GIT_URL=ssh://git@<GitLab/BitBucket>/CI00000110 – SSH путь до проектной области репозитория Ansible-скриптов (см. пункт 7. → раздел Подготовка окружения).

   

Нажмите Сохранить, после чего необходимо будет провести реконфигурацию Jenkins job (действие Собрать сейчас), будет проведена реконфигурация, по завершении которой появятся параметры для запуска Jenkins job.

Настройка закончена. Можно выполнять установку ELK компонентов.

Создание SPO job#

SPO job предназначен для установки компонентов SPO (специальное программное обеспечение).

Пререквизиты:

• Проектная область в Jenkins c правами на создание job.

В инсталляции Jenkins создайте Jenkins job – тип pipeline:

• Нажмите New item ;

• Создайте item с типом pipeline (название в поле Enter an item name — любое удобное).

Заполните параметры на вкладках:

1. Вкладка Pipeline:

В области Definition выберите Pipeline scripts from SCM → в SCM выберите Git и заполните параметры:

• Repositories — созданный ранее репозиторий CI00380023_efs_tengri_pipeline — репозиторий с кодовой базой релизов pipeline (см. раздел Пререквизиты для установки);

• Credentials — созданный ранее credentials jenkins SshKeyCreds (см. раздел Пререквизиты для установки);

• Script Path — deploy-fpi-spo.groovy.

  

2. Вкладка Build triggers:

   • Выбрать опцию Prepare an environment for the run;

   • В поле Properties Content задать следующие параметры:

     • NODE=Linux_Default || kubernetes || openshift (slave jenkins, на которых будет выполняться операция развертывания)

     • ENVIR=ift (стенд)

     • CONFIG_DIR_LIST=main:main (блок стенда) — любое удобное наименование

     • CHANNEL=tengri (сегмент) — любое удобное наименование

     • SCRIPTS_GIT_URL=ssh://git@<GitLab/BitBucket>/CI00000110 – SSH путь до проектной области репозитория Ansible-скриптов (см. пункт 7. → раздел Подготовка окружения).

   

Нажмите Сохранить, после чего необходимо будет провести реконфигурацию Jenkins job (действие Собрать сейчас), будет проведена реконфигурация, по завершении которой появятся параметры для запуска Jenkins job.

Настройка закончена. Можно выполнять установку SPO.

Создание Security job#

Security job предназначен для администраторов для настройки новых КТС и перенастройки имеющихся.

Пререквизиты:

• Проектная область в Jenkins c правами на создание job.

В инсталляции Jenkins создайте Jenkins job – тип pipeline:

• Нажмите New item ;

• Создайте item с типом pipeline (название в поле Enter an item name — любое удобное).

Заполните параметры на вкладках:

1. Вкладка Pipeline:

В области Definition выберите Pipeline scripts from SCM → в SCM выберите Git и заполните параметры:

• Repositories — созданный ранее репозиторий CI00380023_efs_tengri_pipeline — репозиторий с кодовой базой релизов pipeline (см. раздел Пререквизиты для установки);

• Credentials — созданный ранее credentials jenkins SshKeyCreds (см. раздел Пререквизиты для установки);

• Script Path — deploy-fpi-security.groovy.

  

2. Вкладка Build triggers:

   • Выбрать опцию Prepare an environment for the run;

   • В поле Properties Content задать следующие параметры:

     • NODE=Linux_Default || kubernetes || openshift (slave jenkins, на которых будет выполняться операция развертывания)

     • ENVIR=ift (стенд)

     • CONFIG_DIR_LIST=main:main (блок стенда) — любое удобное наименование

     • CHANNEL=tengri (сегмент) — любое удобное наименование

     • SCRIPTS_GIT_URL=ssh://git@<GitLab/BitBucket>/CI00000110 – SSH путь до проектной области репозитория Ansible-скриптов (см. пункт 7. → раздел Подготовка окружения).

   

Нажмите Сохранить, после чего необходимо будет провести реконфигурацию Jenkins job (действие Собрать сейчас), будет проведена реконфигурация, по завершении которой появятся параметры для запуска Jenkins job.

Настройка закончена. Можно выполнять установку SPO.

Создание AT MVN job#

AT MVN job предназначен для запуска тестов, разработанных командой устанавливаемого компонента. Jenkins job производит запуск в оффлайн режиме, в связи с этим требуется собранный дистрибутив с зависимостями, используемыми командами, при запуске тестов и приложения.

Пререквизиты:

• Проектная область в Jenkins c правами на создание job.

• Дополнительная проектная область в SCM системе аналогичная по наименованию уже созданной, с добавлением суффикса _at. Пример: CI02587203 → CI02587203_at.

• Репозиторий pipeline, аналогичный созданному в основной области с добавлением суффикса _at. Пример: CI00380023_efs_tengri_pipeline → CI00380023_efs_tengri_pipeline_at.

• Миграция АТ репозитория при помощи Service job.

В инсталляции Jenkins создайте Jenkins job – тип pipeline:

• В меню слева нажмите на New item;

• Создайте item с типом pipeline (название в поле Enter an item name — любое удобное).

Заполните параметры на вкладках:

1. Вкладка Pipeline:

В области Definition выберите Pipeline scripts from SCM → в SCM выберите Git и заполните параметры:

• Repositories — созданный ранее репозиторий CI00380023_efs_tengri_pipeline_at — репозиторий с кодовой базой релизов pipeline (см. раздел Пререквизиты для установки);

• Credentials — созданный ранее credentials jenkins SshKeyCreds (см. раздел Пререквизиты для установки);

• Script Path — deploy-fpi-at-mvn.groovy.

  

2. Вкладка Build triggers:

   • Выбрать опцию Prepare an environment for the run;

   • В поле Properties Content задать следующие параметры:

     • NODE=Linux_Default || kubernetes || openshift (slave jenkins, на которых будет выполняться операция развертывания)

     • ENVIR=ift (стенд)

     • CONFIG_DIR_LIST=main:main (блок стенда) — любое удобное наименование

     • CHANNEL=tengri (сегмент) — любое удобное наименование

     • SCRIPTS_GIT_URL=ssh://git@<GitLab/BitBucket>/CI00000110 – SSH путь до проектной области репозитория Ansible-скриптов (см. пункт 7. → раздел Подготовка окружения).

   

Нажмите Сохранить, после чего необходимо будет провести реконфигурацию Jenkins job (действие Собрать сейчас), будет проведена реконфигурация, по завершении которой появятся параметры для запуска Jenkins job.

Настройка закончена. Можно выполнять запуск АТ.

Обновление#

Обновление проводится через запуск Service Job:

• Необходимо выполнить миграцию Pipeline (процедура описана в подразделе Проведение последовательной миграции pipeline, subsystems, common).

Удаление#

Удаление осуществляется через UI Jenkins:

• Для удаления необходимо зайти в интерфейс Jenkins, перейти в созданный job и нажать кнопку Удалить Pipeline.

Проверка работоспособности#

Откат#

При необходимости отката pipeline рекомендуется воспользоваться механизмом обновления версии pipeline (Service job → MIGRATION_PPL_DEPLOY), указав при этом необходимую предыдущую версию pipeline.

Часто встречающие проблемы и пути их устранения#

Ошибки в механизмах отката, связанные с ошибкой в коде механизма#

1. В git-репозитории кода pipeline вашего полигона найти ID commit, в комментарии которого указана предыдущая стабильная версия (на которую хотите сделать откат). Пример комментария: <<Migration pipeline library - release/D-01.036.207-3692>>;

2. Выполнить откат кода на этот ID (требуется доступ к git репозиторию на изменение ветки master и локально установленный и настроенный git). Или запросить у уполномоченных специалистов поддержки инфраструктуры вашего полигона выполнить этот откат.

Git команды для выполнения отката:

    git clone <ssh путь до репозитория с кодом pipeline на вашем полигоне>;
    cd <имя репозитория>;
    git checkout master;
    git reset --hard <id коммита из пункта 1>;
    git push --force.

Ошибки в структуре файлов-конфигураций pipeline (environment.json, subsystems.json)#

Восстановить корректность формата файла одним из следующих способов:

1. Если ошибка структуры файла визуально локализуется — исправить ее вручную.

2. Если причина ошибки не ясна, выполнить откат на предыдущую версию файла:

   • открыть проблемный файл в WEB интерфейсе GitLab/BitBucket;

   • в меню history выбрать один из предыдущих commit, с которым работоспособность pipeline была корректной;

   • выделить текст файла и скопировать в буфер обмена;

   • вернуться на последнюю версию этого файла (через выпадающий список в меню history),

   • нажать edit и вставить скопированную версию файла, перезаписав его текущий контент;

   • повторить откат\установку версии pipeline штатным механизмом (service job → MIGRATION_PPL_DEPLOY).

Чек-лист валидации установки#

После выполнения процедуры, описанной в разделе 2, проверьте наличие файлов в репозиториях:

1. В репозитории common (если был задан параметр CONFIG_DIR, то файлы будут расположены в указанной в нём директории):

   • subsystems.json — список конфигураций ФП для Deploy job;

   • environment.json — основной конфигурационный файл pipeline (создается, если ранее отсутствовал, если есть, то мигрируется);

   • jenkinsJobs.conf — список удаленных Jenkins jobs (необходим только для JOB_RECONF_ALL) (создается, если ранее отсутствовал);

   • version.conf — версии pipeline, common, ansible scripts (создается, если ранее отсутствовал, если есть, то мигрируется);

   • в директории main появятся две папки: ansible и installer.

2. В репозитории pipeline:

   • ветка master обновилась до состояния сервисной ветки (в ней хранятся загрузчик и разделяемые библиотеки для всех Deploy jobs) (deploy-fpi.\*.groovy);

   • ветка release/D-01.038.172-11404 создалась (номер ветки — это значение, которое было указано в ARTIFACT_VERSION);

   • в файле environment.json обновлены блоки: main и _default.