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

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

Важно

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

Установка скриптами Delivery Lite#

Примечание

Далее <VERSION> — версия дистрибутива.

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

  1. Распакуйте архив дистрибутива в директорию и перейдите в эту директорию:

    mkdir dcg

unzip ./dcg-<VERSION>-distrib.zip -d dcg

cd dcg

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

    unzip dcgn-scripts-<VERSION>-distrib.zip dcgn-<VERSION>-scripts-distrib/delivery-lite/*

export PYTHONPATH=$PWD/dcgn-<VERSION>-scripts-distrib/delivery-lite

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

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

python3 $PYTHONPATH/src/scripts/build_product.py --dry-run

  4. Добавьте в созданном файле build_config.json для каждого компонента (в файлах docgen-service, template-provider, template-registry, ufs-adapter) параметр в build_args:

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

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

    Пример для компонента Template Provider

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

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

    Важно

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

    # ТУЗ — учетная запись от docker registry

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

  6. Инициализируйте БД:

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

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

    2. На сервере с БД убедитесь, что файлы принадлежат системному пользователю БД (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

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

      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 скрипты:

    1. Перейдите в директорию owned/dcgn-bin-<VERSION>-distrib/package/db.

    2. Распакуйте архив:

      unzip ./template-registry-db-<VERSION>.zip

    3. Перейдите в директорию template-registry-db-<VERSION>.

    4. Заполните файл template-registry-db-<VERSION>/scripts/properties_block.xml: параметр db_schema_suffix — аналогично <DB_SCHEMA_SUFFIX> выше, но с нижним подчеркиванием в начале.

      Пример

      Если значение <DB_SCHEMA_SUFFIX> = aflt, то значение db_schema_suffix = _aflt.

    5. Запустите миграцию:

      Важно

      Необходимо находиться в директории выше /scripts.

      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

  8. Перейдите к установке скриптами DevOps Tools Lite.

Установка скриптами DevOps Tools Lite#

Примечание

Далее <VERSION> — версия дистрибутива.

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

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

    cd ./owned/dcgn-cfg-<VERSION>-distrib/package/conf/scripts/install_scripts/

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

    • параметры Template Registry;

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

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

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

    • hostname Ingress;

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

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

    • пароль к keystore.

  4. Выполните следующие команды:

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

    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 целевого пространства имен среды контейнеризации.

    • --token — токен, используемый для развертывания в целевом пространстве имен среды контейнеризации.

    • --namespace — целевое пространство имен среды контейнеризации для развертывания.

    • --dry-run — режим развертывания в среде контейнеризации, при использовании ключа выполняются только проверки манифестов со стороны сервера, фактической установки и применения манифестов не происходит. Режим служит для предварительной проверки валидности настроенных параметров и оценки готовности к развертыванию.

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

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

    • --withIstio — параметр, управляющий режимом установки в среды контейнеризации из каталога конфигураций Istio.

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

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

    При успешном прохождении этапа шаблонизации выводится сообщение «Шаблонизация успешно завершена».

    В зависимости от наличия ключа --dry-run выполняется проверка параметров и манифестов («холостая» установка) или выполняется применение манифестов из директории manifests в среде контейнеризации.

    При успешном прохождении этапа установки в среде контейнеризации выводится сообщение «Деплой успешно завершен» или «Деплой в режиме DryRun успешно завершен» при использовании ключа --dry-run.

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

    • все манифесты успешно применены в среды контейнеризации;

    • все healthcheck-приложения пройдены успешно (readiness probe);

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