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

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

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

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

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

• роль (role): Maintainer;

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

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

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

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

1. Сформируйте строчку формата из скопированного текста токена:

«<Название токена>:<Project Access Token>»

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

Update_manager:glpat-rdTGhzQzdyd-2C9ubZjX

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

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

Для автоматизации исполняемых действий при переносе изменений между контурами системы на уровне GitLab должна быть реализована сборочная линия, выполняемая службой GitLab Runner (агентом) и описанная в файле .gitlab-ci.yml. Это значит, что для 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 "GitLab_Runner"

      - git config --global user.email "GitLab_Runner@sng.local"

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

    - git config --global user.email "GitLab_Runner@sng.local"

    - 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']

Код описывает поведение пайплайна при создании определенного тега на TEST-ветке. Пайплайн создает клон TEST-ветки и от него создает merge request к PROD-ветке с удалением ветки-клона после слияния веток. Для тестовой инфраструктуры подойдёт и такая простая логика, однако при копировании для своей инфраструктуры код стоит немного адаптировать:

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

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

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

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

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

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

- target_branch=comp_prod

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

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

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

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

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

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. Оставьте поле пустым.

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

• используемая ОС ALT Server 10.4 (Mendelevium). Для проверки используемой ОС выполните команду:

hostnamect l

• версия ядра: Kernel: Linux 5.10.176-std-def-alt1;

• количество ядер/потоков, не менее: 8/16. Например, CPU Intel Xeon E5-2690. Для проверки характеристик CPU выполните команду:

lscpu

• объём оперативной памяти, не менее: 16 Gb. Для проверки объёма памяти выполните команду:

free

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

• выполнена интеграция с Python версии 3.7.3. По умолчанию в комплекте с Alt-Linux идёт альтернативная подходящая версия Python 3.9.16. Для проверки подключенной версии Python выполните команду:

python3 --version

• добавлены ссылки на библиотеки:

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

sudo apt-get install libpython3-dev

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

sudo apt-get install python3-module-gitlab

• добавлен якорь:

ln -s /usr/lib/python3.7/config-3.7m-x86_64-linux-gnu/libpython3m.so /opt/foresight/fp10.x-biserver/bin/

После выполнения команды в каталоге /opt/foresight/fp10.x-biserver/bin/ появится символьная ссылка libpython3.7m.so, которая указывает на файл /usr/lib/python3.7/config-3.7m-x86_64-linux-gnu/libpython3.7m.so. Эта ссылка может использоваться для того, чтобы программы, ищущие libpython3.7m.so в своем каталоге, могли найти её там, не копируя сам файл.

• изменён владелец директории на пользователя:

sudo chown -R apache2:apache2 /opt/foresight/fp10.x-biserver

Где:

• chown. Команда для раздачи прав доступа для пользователя Apache2 на папку с установленным BI-сервером в ОС Linux, используется для изменения владельца и группы;

• -R. Опция рекурсивной обработки, то есть изменения будут применяться не только к указанному каталогу, но и ко всем его подкаталогам;

• apache2. Указание нового владельца и группы;

• /opt/foresight/fp10.x-biserver. Путь к папке с установленным BI-сервером.

Изменение владельца директории для Планировщика производится на пользователя, под которым запущена соответствующая служба scheduler.service.