Установка без использования компонента Deploy Tools#

Текущая инструкция предназначена для установки без использования компонента Deploy Tools (CDJE) продукта Platform V DevOps Tools (DOT). Для данной установки потребуются скрипты Delivery Lite и DevOps Tools Lite

Установка выполняется последовательно, начиная с Delivery Lite.

Версии пакетов могут отличаться от заданных примеров.

Установка с Delivery Lite#

Более подробная инструкция к скриптам находится в файле README.md в директории Delivery Lite.

Для запуска процесса требуется выполнить следующие шаги:

  1. Распаковать архив дистрибутива в директорию и переключиться на эту директорию:

    mkdir dcg

unzip ./dcg-1.4.1.1-04-distrib.zip -d dcg

cd dcg

  2. Распаковать скрипты Delivery Lite и задать путь к директории в качестве PYTHONPATH:

    unzip dcgn-scripts-1.0.0-1-distrib.zip dcgn-1.0.0-scripts-distrib/delivery-lite/*

export PYTHONPATH=$PWD/dcgn-1.0.0-scripts-distrib/delivery-lite

  3. Запустить скрипт в режиме dryrun для создания файла build_config.json:

    #Для выполнения основной команды требуется модуль pyyaml:
sudo pip3 install pyyaml

python3 $PYTHONPATH/src/scripts/build_product.py --dryrun

  4. В созданном файле build_config.json добавить параметры в build_args для каждого компонента:

    "build_args":
{ "BASE_IMAGE": "<новый базовый образ>" }

    Проверенный базовый образ — «BASE_IMAGE»: «openjdk:11-jdk-stretch».

    Пример для template-provider, произвести для всех компонентов (docgen-service, template-provider, template-registry, ufs-adapter):

    ...
    "template-provider:(...)": {
        (...)
        "build": {
            "build_args": {"BASE_IMAGE": "openjdk:11-jdk-stretch"},
        (...)
        },
...

  5. Запустить скрипт сборки и загрузки образа: (ТУЗ — учетная запись от docker registry):

    #Пользователь, запускающий скрипты должен состоять в группе docker или иметь доступ к docker socket без sudo. Пример добавления пользователя в группу:
sudo usermod -aG docker ${USER}

    python3 $PYTHONPATH/src/scripts/build_product.py  --config_path 'build_config.json' --user <имя ТУЗ> --password <пароль> --registry <адрес docker registry> --registry_path <путь в docker registry> --push_images true

    Адрес docker registry должен быть указан без протокола, например: registry-1.docker.io вместо https://registry-1.docker.io.

  6. Инициализировать БД:

    • На сервере с БД создать 3 директории под tablespace и заменить <dir> на локацию, где будут располагаться Tablespace:

      mkdir <dir>/dcgn_ts_data
mkdir <dir>/dcgn_ts_idx
mkdir <dir>/dcgn_ts_lob

    • На сервере с БД Убедиться, что файлы принадлежат системному пользователю БД (postgres в стандартных настройках):

      ls -l <dir>

drwxr-xr-x  2 postgres postgres 4096 Jun 19 16:17 dcgn_ts_data
drwxr-xr-x  2 postgres postgres 4096 Jun 19 16:17 dcgn_ts_idx
drwxr-xr-x  2 postgres postgres 4096 Jun 19 16:17 dcgn_ts_lob

      При необходимости сменить владельца директории:

      chown <user> <dir>/dcgn_ts_data
chown <user> <dir>/dcgn_ts_idx
chown <user> <dir>/dcgn_ts_lob

    • Заменить в SQL-скриптах ниже переменные <DB_SCHEMA_SUFFIX> <DB_NAME> <пароль> и заполнить <dir> (из первого пункта)

      create user dcgn_<DB_SCHEMA_SUFFIX> with encrypted password '<пароль>';
create schema dcgn_<DB_SCHEMA_SUFFIX>;
grant connect on database <DB_NAME> to dcgn_<DB_SCHEMA_SUFFIX>;
grant all on schema dcgn_<DB_SCHEMA_SUFFIX> to dcgn_<DB_SCHEMA_SUFFIX>;
alter user dcgn_<DB_SCHEMA_SUFFIX> VALID UNTIL 'INFINITY';
grant usage on schema dcgn_<DB_SCHEMA_SUFFIX> to dcgn_<DB_SCHEMA_SUFFIX>;
create tablespace dcgn_ts_data owner dcgn_<DB_SCHEMA_SUFFIX> location '<dir>/dcgn_ts_data';
create tablespace dcgn_ts_idx owner dcgn_<DB_SCHEMA_SUFFIX> location '<dir>/dcgn_ts_idx';
create tablespace dcgn_ts_lob owner dcgn_<DB_SCHEMA_SUFFIX> location '<dir>/dcgn_ts_lob';

  7. Запустить Liquibase скрипты:

    • Переключиться на директорию owned/dcgn-bin-D-01.004.01-1076-distrib/package/db

    • Распаковать архив:

      unzip ./template-registry-db-D-01.004.01-1076.zip

    • Переключиться на директорию template-registry-db-D-01.004.01-1076

    • Заполнить файл template-registry-db-D-01.004.01-1076/scripts/properties_block.xml
      Параметр db_schema_suffix - аналогично DB_SCHEMA_SUFFIX выше, но с “_” в начале (пример: DB_SCHEMA_SUFFIX = aflt, db_schema_suffix в xml = _aflt)

    • Запустить миграцию:

         java -cp "liquibase-core-4.9.1.jar:postgresql-42.5.1.jar" liquibase.integration.commandline.Main --url="jdbc:postgresql://<DB_HOST>:<DB_PORT>/<DB_NAME>" --changeLogFile=./scripts/0001_changelog.xml --username=dcgn_<DB_SCHEMA_SUFFIX> --password=<пароль> update

    Очень важно находиться в директории выше /scripts

  8. Перейти к установке с помощью DevOps Tools Lite (DOT Lite)

Установка с DevOps Tools Lite (DOT Lite)#

Требования для запуска - Выполнена установка с Delivery Lite.

Более подробная инструкция к скриптам находится в файле README.md в директории DOT Lite.

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

  1. Из директории, в которую был распакован дистрибутив, переключиться в директорию со скриптами установки:

cd ./owned/dcgn-cfg-D-01.004.01-1953_BD-distrib/package/conf/scripts/install_scripts/

  1. Заполнить файл external_params.yml с обязательными параметрами установки.

    • Параметры Registry;

    • Параметры дистрибутива;

    • Параметры БД;

    • Параметр пути до keystore (в директории install_scripts должен быть файл db-keystore.jks: корневой сертификат, клиентский и ключ от клиентского);

    • Указать hostname ingress;

    • Указать путь к распакованному дистрибутиву (заменить на путь на сервере).

  2. Заполнить файл secrets.yml с обязательными параметрами установки

    • Заполнить пароль к keystore

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

  • При необходимости сохранить текущую, уже установленную в namespace конфигурацию, для возможности последующего отката на нее, в случае неуспешной установки текущего дистрибутива:

chmod +x install.sh
export TOKEN=<token_аккаунта_для_установки_в_k8s>
# Создаем dump-файл тех манифестов, которые планируются к обновлению в рамках текущего дистрибутива
./install.sh --server=<адрес_api_сервера_k8s_например_https://api.example.com:6443> --token=$TOKEN --namespace=<имя_name_k8s_куда_устанавливать> --dump-file=<файл_в_которой_будет_сохранена_конфигурация>
# Проверяем валидность созданного dump-файла при помощи запуска восстановления из него в "холостом" режиме (--dry-run)
./install.sh --server=<адрес_api_сервера_k8s_например_https://api.example.com:6443> --token=$TOKEN --namespace=<имя_namespace_k8s_куда_устанавливать> --from-dump=<файл_в_которой_будет_сохранена_конфигурация> --dry-run

  • Для установки манифестов из текущего дистрибутива:

chmod +x install.sh
export TOKEN=<token_аккаунта_для_установки_в_k8s>
./install.sh --server=<адрес_api_сервера_k8s_например_https://api.example.com:6443> --token=$TOKEN --namespace=<имя_namespace_k8s_куда_устанавливать> --dry-run
./install.sh --server=<адрес_api_сервера_k8s_например_https://api.example.com:6443> --token=$TOKEN --namespace=<имя_namespace_k8s_куда_устанавливать>

  • Для восстановления из сохраненного файла конфигурации (в случае неуспеха установки из текущего дистрибутива):

chmod +x install.sh
export TOKEN=<token_аккаунта_для_установки_в_k8s>
./install.sh --server=<адрес_api_сервера_k8s_например_https://api.example.com:6443> --token=$TOKEN --namespace=<имя_namespace_k8s_куда_устанавливать> --from-dump=<файл_в_которой_будет_сохранена_конфигурация>

где:

  • --server - адрес до API целевого namespace Kubernetes/DropApp (опционально OpenShift);

  • --token - token, используемый для deploy в целевой namespace Kubernetes/DropApp (опционально OpenShift);

  • --namespace - целевой namespace Kubernetes/DropApp (опционально OpenShift), в который будет произведена попытка установки;

  • --dry-run - параметр, управляющий режимом deploy в Kubernetes/DropApp (опционально OpenShift), при указании выполнятся только проверки манифестов со стороны сервера (фактической установки и применения манифестов не произойдет). Используйте данный режим для предварительной проверки валидности настроенных вами параметров (оценки готовности к установке). При необходимости уже применения самих манифестов (реальной установки) не указывайте данный ключ;

  • --dump-file - имя файла, куда сохранить слепок текущих манифестов из Kubernetes/DropApp (опционально OpenShift). Сохраняет только те манифесты, которые планируются к обновлению в рамках текущего дистрибутива (пересекаются по имени с манифестами из текущего дистрибутива). При указании данного ключа не выполняется установка манифестов из текущего дистрибутива. Данный файл в последствии может понадобиться при неуспешной установке текущего дистрибутива, чтобы восстановить предыдущее рабочее состояние (смотри ключ --from-dump);

  • --from-dump - имя файла, из которого сделать восстановление манифестов (предварительно сохранненых ранее при запуске с ключом --dump-file). Возможно указать вместе с ключом --dry-run, для предварительной проверки манифестов (без их реальной установки);

  • --withIstio - параметр, управляющий режимом установки в Kubernetes/DropApp (опционально OpenShift) из каталога конфигураций Istio.

Алгоритм работы скрипта install.sh:

  • Шаблонизация всех файлов в директории manifests, используя все найденные *.conf и *.yml файлы настроенных параметров. При этом параметры из external_params.yml будут с самым высоким приоритетом.

  • В зависимости от наличия ключа --dry-run происходит один из следующих шагов:

    • --dry-run: выполняется проверка параметров и манифестов к установке («холостая» установка).

    • --dry-run: выполняется применение манифестов из директории manifests в Kubernetes/DropApp (опционально OpenShift).

При успешном прохождении этапа шаблонизации появится сообщение: «Шаблонизация успешно завершена». При успешном прохождении этапа установки в Kubernetes/DropApp (опционально OpenShift): «Деплой успешно завершен» или «Деплой в режиме DryRun успешно завершен» при использовании --dry-run.

Успешное завершение скрипта (exit code = 0) подразумевает следующее:

  1. Все манифесты успешно применены в Kubernetes/DropApp (опционально OpenShift).

  2. Все healthcheck-приложения пройдены успешно (readiness probe).

  3. Приложение готово обрабатывать запросы.