Настройка программного обеспечения

Контроль версий обновлений и хранение файлов со связанными изменениями в транспорте изменений осуществляется совместно со следующим дополнительным программным обеспечением:

• GitLab. Платформа, используемая для управления проектами и репозиториями данных;

• GitLab Runner. Служба, используемая для автоматизации исполняемых действий при переносе изменений между контурами на уровне Gitlab. Настройки службы содержатся в файле .gitlab-ci.yml;

• Sonatype Nexus. Платформа, используемая для хранения файлов, связанных с наборами изменений.

Примечание. Платформы GitLab, GitLabRunner и Sonatype Nexus являются коммерческими продуктами и не входят в комплект поставки продукта комплект поставки продукта «Форсайт. Аналитическая платформа».

Для получения подробной информации по установке и настройке обратитесь к документации GitLab, GitLabRunner и Sonatype Nexus.

Шаг 1. Настройка GitLab

1. Установите GitLab. Если используется протокол HTTPS, укажите 443 порт для доступа до сервера GitLab.

2. Выполните вход в GitLab, используя учётные данные.

3. Создайте проект и несколько веток. Количество веток должно быть на одну меньше количества контуров системы. Например, при минимальном количестве контуров DEV, TEST, PROD создайте две ветки: одна для контуров DEV и TEST, а другая для контура PROD.

4. Создайте и сохраните токен доступа проекта со следующими обязательными настройками:

• роль (role): Maintainer;

• область действия (scorpes): read_repository, write_repository.

Важно. Токен доступа проекта отображается только один раз при его создании. После закрытия страницы или её обновления просмотр токена будет невозможен.

5. Далее созданный токен доступа проекта используйте при настройке планировщика задач.

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

1. Дополните строку значением параметра user.name, которое используется в команде git config при настройке планировщика задач:

<user.name>:<Project Access Token>

Пример строки:

Update_manager:glpat-rdTGhzQzdyd-2C9ubZjX

2. Зашифруйте строку в base64, выполнив команду:

echo -n ‘Update_manager:glpat-rdTGhzQzdyd-2C9ubZjX' | base64

3. Укажите зашифрованную строку в переменной планировщика GIT_AUTH_HEADER. Пример для версии fp10.x:

Environment=HOME=/opt/foresight/fp10.x-biserver/etc

Environment=PP_LOG=1

Environment=GIT_AUTH_HEADER="Authorization: Basic <Зашифрованный токен>"

Environment=NEXUS_CREDENTIALS="admin:Qwerty1">

6. Для автоматизации исполняемых действий при переносе изменений между контурами системы на уровне GitLab должна быть реализована сборочная линия, выполняемая службой GitLab Runner (агентом) и описанная в файле .gitlab-ci.yml. Сборочная линия необходима для тех веток, которые выполняют миграцию изменений. При минимальном количестве трёх контуров с двумя ветками, сборочная линия настраивается для ветки TEST.

Код описывает поведение пайплайна при создании тега на ветке TEST при нажатии кнопки «Создать метку» в форме «Установка журнала изменений» в контуре TEST при использовании транспорта изменений. Пайплайн создает клон TEST-ветки и от него создает merge request к PROD-ветке с удалением ветки-клона после слияния веток. 

Для TEST-ветки содержимое файла .gitlab-ci.yaml должно выглядеть следующим образом:

stages:

  - prepare

  - createBranch

  - createMerge

prepareGit-job:

  stage: prepare

  tags:

      - UPDATE

  script:

      - git fetch --prune origin

      - git fetch --prune --prune-tags

      - git fetch --all

      - git branch -a

      - git remote -v

createProdBranch-job:

  stage: createBranch

  tags:

    - UPDATE

  script:

      - if [[ $(git branch -D branch_${CI_COMMIT_TAG}) ]]; then echo "delete branch branch_${CI_COMMIT_TAG}"; else echo "branch_${CI_COMMIT_TAG} does not exist"; fi

      - git config --global user.name "Update_manager"

      - git config --global user.email "Update_manager@email.ru"

      - if [[ $(git checkout -b branch_${CI_COMMIT_TAG} tags/${CI_COMMIT_TAG}) ]]; then echo "create branch branch_${CI_COMMIT_TAG}"; else git checkout branch_${CI_COMMIT_TAG}; fi

      - git branch -a

      - git remote -v

      - git remote set-url --push origin "http://Update_manager:${CI_PUSH_TOKEN}@10.30.45.25/update_manager/dops_master.git"

      - git push origin "branch_${CI_COMMIT_TAG}"

  rules:

    - if: '$CI_COMMIT_TAG =~ /^comp_prod-[A-Z]{2}([-]\d+)?([-]\d+)?$/'

      needs: ['prepareGit-job']

createProdMerge-job:

  stage: createMerge

  tags:

    - UPDATE

  script:

    - git checkout branch_${CI_COMMIT_TAG}

    - git branch -a

    - git config --global user.name "Update_manager"

    - git config --global user.email "Update_manager@email.ru"

    - block=${CI_COMMIT_TAG:5:2}

    - echo $block

    - git commit --allow-empty -m "Merge request trigger"

    - target_branch=comp_prod

    - echo "${CI_PUSH_TOKEN}"

    - git remote set-url --push origin "http://Update_manager:${CI_PUSH_TOKEN}@10.30.45.25/update_manager/dops_master.git"

    - git push origin "branch_${CI_COMMIT_TAG}" -o merge_request.create -o merge_request.target="$target_branch" -o merge_request.remove_source_branch -o merge_request.title="comp_prod Merge request $(date)"

  rules:

    - if: '$CI_COMMIT_TAG =~ /^comp_prod-[A-Z]{2}([-]\d+)?([-]\d+)?$/'

      needs: ['createProdBranch-job']

Адаптируйте содержимое файла:

1. Укажите псевдоним, от имени которого будет выполняться сборочная линия, в строках

- git config --global user.name "Update_manager"

- git config --global user.email «Update_manager@email.ru»

2. Укажите актуальный адрес используемого GitLab в строках:

- git remote set-url --push origin http://Update_manager:${CI_PUSH_TOKEN}@10.30.45.25/update_manager/dops_master.git

Где в строке Update_manager:${CI_PUSH_TOKEN}, Update_manager - значение параметра user.name, которое используется в команде git config.

3. Укажите ожидаемое регулярное выражение, под которое будет попадать создаваемый для TEST-ветки тег в строках:

- if: '$CI_COMMIT_TAG =~ /^comp_prod-[A-Z]{2}([-]\d+)?([-]\d+)?$/'

Тег задается в настройках транспорта обновлений TEST-репозитория, в параметр «Шаблон метки» с идентификатором tagTemplate.

4. Укажите актуальное название PROD-ветки в строке:

- target_branch=comp_prod

Шаг 2. Настройка GitLab Runner

1. Установите GitLab Runner.

2. Убедитесь, что в разделе администрирования GitLab отображается Runner со статусом Online. Для этого используйте адрес:

<адрес_GitLab>/admin/runners

3. Укажите созданный Runner, как средство выполнения проекта, на вкладке «Настройки > CI\CD» в GitLab.

4. Убедитесь, что Runner корректно выполняет пайплайн. Это происходит при выполнении шага «Создать метку» при использовании транспорта изменений.

Шаг 3. Настройка Sonatype Nexus

1. Установите Nexus. Если используется протокол HTTPS, укажите 443 порт для доступа до сервера Nexus.

2. Создайте репозиторий с типом raw(hosted) со следующими настройками:

• Name. Укажите наименование репозитория, которое будет указано в настройках транспорта изменений;

• Online. Установите флажок;

• Content Disposition. Укажите Attachment;

• Blob store. Значение по умолчанию (default);

• Strict Content Type Validation. Снимите флажок;

• Deployment Policy. Укажите Allow Redeploy;

• Proprietary Components. Снимите флажок;

• Cleanup Policies. Оставьте поле пустым.

Шаг 4. Настройка программного обеспечения для BI-сервера и планировщика задач

Для корректной работы механизма переноса обновлений убедитесь, что выполняются требования для BI-сервера продукта «Форсайт. Аналитическая платформа» и планировщика задач:

• на стендах BI-сервером и планировщиком задач установлен актуальный Python 3 версии.
  

• добавлена ссылка на библиотеку libpython3-dev. Для установки библиотеки libpython3 выполните команду:

sudo apt-get install libpython3-dev