Инструкция по инсталляции облачной платформы ============================================ Подготовка ---------- Перед развертыванием самой облачной платформы необходимо создать несколько типов узлов: 1. Узел Infrastructure (он же LCM — Life Cycle Manager) — предназначен для управления жизненным циклом облака; 2. Узлы Control Plane (контроллеры) — предназначены для выполнения служебных задач по управлению облаком; 3. Узлы Compute (гипервизоры) — предназначены для размещения рабочих нагрузок в виде виртуальных машин; 4. Узлы Network (сетевые) — предназначены для размещения компонентов програмно-определяемых сетей. Процесс развертывания облака состоит из следующих шагов: 1. Запуск установки (инсталлятора), который установит на сервер LCM необходимые компоненты и сервисы для дальнейшей работы с облаком. 2. Выполнение сценариев (пайплайнов) системы управления облаком (CI/CD) для задач настройки/конфигурирования облака. Развертывание сервера LCM ------------------------- Инсталлятор разворачивает Облачную платформу на заранее подготовленной инфраструктуре (ВМ или физических серверах). Требования ~~~~~~~~~~ Требования, предъявляемые к узлу LCM (он же — узел Seed), одновременно являются требованиями к узлу, на котором возможно проведение процесса разработки и доработки компонентов облачной платформы, поскольку разработка производится при помощи встроенной в Gitlab среды разработки. Поддерживаемые базовые ОС LCM ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Установка облачной платформы возможна с использованием нижеперечисленных дистрибутивов Linux. **Для хоста:** - Zed: Ubuntu 22.04 LTS **Для LCM:** - Ubuntu 22.04 LTS Требования к пакетам ^^^^^^^^^^^^^^^^^^^^ Для корректной работы облачной платформы необходимо установить: - docker - docker compose - git версии старше 2.28.0 - openssl, curl, tar, jq Инфраструктурные требования ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Для установки и коректной работы LCM требуется наличие сетевой связности между сервером LCM и хостами контроллеров и гипервизоров: - C узла LCM должен быть доступ до IPMI всех серверов, до mgmt-интерфейсов и до VIP-адресов облака. - Со всех хостов должен быть доступен dhcp-сервер на узле LCM в сети PXE. - Создан пользователь в BMC серверов с правами administrator и включена опция Enable IPMI Over LAN. Включен Redfish. Также для облачной инфраструктуры требуется выделить DNS-зону, в котором необходимо создать записи для следующих сервисов: - config.\<имя домена> — информационный сервис облака; - ks-lcm.\<имя домена> — система управления жизненным циклом облака (CI); - gitlab-runner.\<имя домена> — исполнитель сценариев (пайплайнов); - nexus.\<имя домена> — репозиторий пакетов, контейнеров и других артефактов облака; - vault.\<имя домена> — хранилище паролей и сертификатов; - netbox.\<имя домена> — хранилище настроек для сервиса Baremetal. Доменное имя необходимо использовать второго уровня для генерации Wildcard-сертификата для сервисов LCM, например, demo.local. Возможность разрешения данных имён в IP-адрес сервера LCM является обязательным, поскольку при установке облачной платформы используются сертификаты безопасности, связанные с указанными выше именами. Установка допускает использование разрешения имён либо через сервис DNS, либо через записи в файлах ``/etc/hosts``. Пример записи в ``/etc/hosts``: .. code:: bash config.<имя домена> ks-lcm.<имя домена> gitlab-runner.<имя домена> vault.<имя домена> nexus.<имя домена> netbox.<имя домена> Для узлов Compute необходимо создать записи вида: - 10.10.1.1 \<имя сервера>-rmi.\<имя домена> Эти записи предназначены для разрешения IP-адреса BMC сервера в имя вида \<имя сервера>-rmi.\<имя домена>. Их нужно изменить на реальные адреса интерфейсов BMC узлов Compute. Установка LCM ~~~~~~~~~~~~~ Процесс установки в автоматическом режиме производит развертывание и конфигурирование следующих компонентов на сервере LCM: - Пароля системы автоматизации (Gitlab); - SSH-ключей для беспарольного доступа на сервера; - Сертификатов для служб LCM; - Репозитория пакетов, контейнеров, артефактов Sonatype Nexus; - Системы автоматизации (GitLab-CI); - Репозиториев управления облаком (CI/CD); - Документирования сетей и девайсов Netbox (CMDB). Все действия выполняются от имени пользователя root. Ссылка на архив с инсталлятором: https://repo.itkey.com/repository/k-install/installer-ks2023.2.1.tgz Для начала установки на подготовленном сервере LCM от имени пользователя root требуется распаковать любой удобной утилитой архив с инсталлятором в домашнюю директорию пользователя root. Распаковка должна быть произведена в поддиректорию с именем installer в домашней директории пользователя root. Пример команды разархивирования, выполняемой от имени пользователя root: .. code:: bash tar -xf /installer-ks2023.2.1.tgz -C ~/ Вместо нужно указать путь до директории со скачанным архивом инсталлятора. Запуск процесса установки облачной платформы осуществляется запуском команды ./installer.sh из директории инсталлятора (необходимо наличие прав root или запуск команды при помощи sudo). .. code:: bash root@lcm:~/installer# ./installer.sh *** KeyStack Installer v1.0 (ks2023.2.1) *** Enter the home dir for the installation [/installer]: Enter the IP address of this machine [10.220.107.179]: Enter the root domain name for the KeyStack: demo.local Доменное имя должно быть второго уровня. Возможные ошибки при развёртывании LCM ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Отсутствие каких-либо репозиториев в Gitlab ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Если это пустой репозиторий в Gitlab, значит, при git push могла произойти внутренняя ошибка сервиса Gitlab. В этом случае нужно перейти в каталог, где лежат все репозитории /installer/repo, зайти в каталог репозитория, где произошла ошибка, и выполнить команды: .. code:: bash git push -u origin --all git push -u origin --tags После этого нужно убедиться, что данные репозитория появились в Gitlab. Развертывание облачной платформы -------------------------------- .. _требования-1: Требования ~~~~~~~~~~ Требования к базовой ОС узлов ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Перед развертыванием сервисов облачной платформы необходимо убедиться, что на узлах присутствует пакет python 3, а также включены флаги виртуализации аппаратной платформы. Проверка флагов виртуализации производится при помощи выполнения команды: .. code:: bash egrep '(vmx|svm)' /proc/cpuinfo Предварительная конфигурация ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ После успешной установки на экране отобразится сообщение с текущей конфигурацией облачной платформы. После этого можно перейти в браузере по адресу \http://config.<имя домена> для получения общей информации об инсталляции и доступа к основным параметрам конфигурации. Пример такой страницы приведён на рисунке ниже: .. image:: media/image_1.png Рисунок 1 — Пример страницы с общей информацией об инсталляции Для обеспечения корректной работы браузеров с компонентами облачной платформы требуется добавить Root CA (корневой) сертификат в Доверенные корневые центры сертификации системы пользователя. После выполнения этих шагов требуется перейти по адресу CI/CD системы и использовать пароль GitLab root, полученный на странице с информацией. В интерфейсе CI/CD системы будет доступно несколько репозиториев. Пример интерфейса приведён на рисунке ниже. .. image:: media/image_2.png Рисунок 2 — Репозитории в Gitlab Пароли и сертификаты Облачной платформы ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Все пароли и сертификаты для облака хранятся в сервисе Vault по адресу: \https://vault.<имя домена>. .. image:: media/image_3.png Рисунок 3 — Интерфейс хранилища секретов Рутовый токен можно найти на сервере LCM в файле ``/installer/data/vault/config/unseal_info``. Там же находятся ключи для разблокировки Vault после перезагрузки. Все сертификаты автоматически генерируются при инсталляции сервера LCM с помощью программы openssl. - Инсталлятор создает корневой центр сертификации: Root CA сертификат и приватный ключ. Срок действия — 10 лет. - Инсталлятор создает Wildcard сертификат и приватный ключ для сервисов Gitlab, Nexus, Vault, Netbox и делает их доверенными центру сертификации Root CA. Также создается цепочка сертификатов вида chain-cert.pem для сервисов. Срок действия — 2 года. - Инсталлятор активирует в Vault хранилище pki с именем installer для хранения сертификатов и создает в этом хранилище Центр сертификации на основе центра сертификации Root CA. Также он создает роль, которая может выписывать сертификаты на основе запросов пользователей. Срок действия — 2 года. Сервис по наливке Baremetal серверов ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Установка и настройка Bifrost ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Зайти в Gitlab, перейти в репозиторий project_k → deployments → gen-pwd. Перейти в Build → Pipelines → Run Pipeline. Внести в поле "OPENSTACK_ENV" значение bifrost, как на рисунке ниже, и запустить пайплайн с помощью кнопки "Run Pipeline". .. image:: media/image_6.png Рисунок 4 — Запуск пайплайн-генерации секретов для bifrost Запустить задачу ``create-config``, как на рисунке ниже. .. image:: media/image_7.png Рисунок 5 — Запуск задачи генерации секретов для bifrost Дождаться окончания работы пайплайна. Перейти репозиторий project_k → deployments → bifrost. Открыть на редактирование файл `inventory` и заменить в нем `LCM_IP` на IP-адрес LCM-узла. Открыть на редактирование файл `globals.d/REGION.yml` и заменить в нем `eth0` на имя интерфейса на LCM-узле. Перейти в Build → Pipelines → Run Pipeline и запустить пайплайн с помощью кнопки "Run Pipeline". .. image:: media/image_8.png Рисунок 6 — Запуск задачи установки bifrost Дождаться окончания работы задачи ``setup``, запустить задачу ``deploy-bifrost`` и дождаться окончания ее работы. .. _ubuntu-22.04-lts-1: Зайти на LCM-узел по ssh и выполнить команду: .. code:: bash # docker exec -ti bifrost_deploy bash (bifrost-deploy)# mcedit /etc/dnsmasq.conf Поменять значения: ``listen-address=`` ``dhcp-option=6,`` ``dhcp-boot=tag:ipxe,http://:8080/boot.ipxe`` Диапазон адресов DHCP для выдачи IP-адресов серверам: ``dhcp-range=10.0.0.10,10.0.0.100,255.255.255.0,24h`` Маршрут для IP-адресов, выданных по DHCP: ``dhcp-option=3,10.0.0.254`` Сохранить изменения F2 и выйти F10. Перезапустить сервис dnsmasq: .. code:: bash (bifrost-deploy)# systemctl restart dnsmasq Изменение пользователя и пароля для IPMI серверов гипервизора ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Перейти в ``secret_v2/deployments/bifrost/rmi``, где bifrost — название репозитория с настройками сервиса bifrost. Затем поменять пароль в поле "password" на пароль от интерфейса IPMI BMC-серверов, и пользователя в поле "user" на пользователя интерфейса IPMI BMC-серверов. .. image:: media/image_5.png Рисунок 7 — Изменение пароля IPMI в хранилище секретов для сервиса Baremetal На всех серверах нужно создать одинакового пользователя с именем и паролем, который должен быть записан в Vault. Это необходимо для работы сервиса автоэвакуации ВМ при сбое гипервизора и для сервиса Baremetal. Развертывание серверов с помощью сервиса Baremetal ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Настройка Netbox '''''''''''''''' До начала работ по наливке серверов необходимо заполнить данные в Netbox. Наливка серверов '''''''''''''''' Перейти в Gitlab в репозиторий project_k → services → baremetal. Перейти в Build → Pipelines → Run Pipeline. |image1| Рисунок 8 — Запуск пайплайн развертывания серверов Заполнить переменные для пайплана: - TARGET_ROLE — роль для серверов, определенная в Netbox. Для контроллеров — controller, для узлов Network — network, для узлов Compute — compute. - TARGET_CLOUD — имя тега в Netbox для региона. - TARGET_NODE — имя конкретного узла для деплоя только одного узла. - IRONIC_ENV — окружение для деплоя узлов (по умолчанию — BIFROST). - IRONIC_SSH_KEY — можно добавить свои ключи SSH на узел (формат — один ключ на строку). - IRONIC_IMAGE_URL — путь до образа системы Linux, который будет установлен на узел. Образ должен быть в формате qcow2. Тамже рядом с образом должен лежать файл с md5 хэш образа, формат имени {имя-образа}.md5. - IRONIC_IMAGE_ROOTFS_UUID — для установки системы на софт-рейд нужно указать UUID рутового раздела в образе. https://docs.openstack.org/ironic/yoga/admin/raid.html#image-requirements - IPA_KERNEL_NAME — путь до IPA kernel image. - IPA_RAMDISK_NAME — путь до IPA initramfs image. - KOLLA_ANSIBLE_IMG_TAG — тег контейнера с kolla-ansible, используемый для пайплайна. - KEYSTACK_RELEASE — тег релиза Keystack. - CI_DEBUG_TRACE — для выведения отладочной информации в пайплайне поставить значение true. После заполнения данных нажать кнопку "Run Pipeline". Запустится пайплан для деплоя серверов, необходимо дождаться окончания работы. .. image:: media/image_10.png Рисунок 9 — Пайплайн развертывания серверов Развертывание облака ~~~~~~~~~~~~~~~~~~~~ .. _развертывание-облачной-платформы-1: Развертывание облачной платформы ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Необходимо зайти в Gitlab, перейти в репозиторий project_k → deployments → region1. Здесь находятся демонстрационные настройки для региона region1. Для создания настроек нового региона нужно сделать форк данного репозитория и назвать его по имени нового региона. Зайти в репозиторий нового региона, перейти в Settings → General → Advanced и нажать кнопку "Remove fork relationship". Дальнейшее описание касается демонстрационного региона region1. Файлы конфигурации облачной платформы ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Зайти в Gitlab, перейти в репозиторий project_k → deployments → region1. Открыть на редактирование файл ``inventory`` и заполнить его своими данными: - заполнить группы ``[control]``, ``[network]``, ``[compute]`` данными по образцу. Открыть на редактирование файл ``globals.d/REGION.yml`` и заполнить его своими данными: - ``kolla_internal_vip_address`` — виртуальный IP-адрес для внутреннего VIP-адреса (для балансировки запросов); - ``kolla_external_vip_address`` — виртуальный IP-адрес для внешнего VIP-адреса (для балансировки запросов); - ``network_interface`` — имя интерфейса для managment-сети, на которых будет разворачиваться Openstack; - ``neutron_external_interface`` — имя интерфейса для связи с внешним миром, например, сетями провайдеров, маршрутизаторами и плавающими IP-адресами. Открыть на редактирование файл ``globals.d/octavia.yml`` и заполнить его своими данными: - ``octavia_amp_network_cidr`` — блок IP-адресов для amphora сервиса Octavia Openstack. | Открыть на редактирование файл ``tf_states/settings.tf`` и заполнить его своими данными: | В блоке ``variable "pub_net"``: - cidr — блок IP-адресов для FIP; - allocation_start — начало блока IP-адресов для FIP; - allocation_end — конец блока IP-адресов для FIP; - dns — ДНС-сервера для FIP. В блоке ``resource "openstack_compute_aggregate_v2" "dev_region"``: - ``hosts`` — имена серверов гипервизоров. Запуск задачи с предварительной настройкой региона ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | Необходимо зайти в Gitlab и перейти в репозиторий project_k → deployments → gen-pwd. | Затем перейти в Build → Pipelines → Run Pipeline. | Заполнить переменные для пайплана, как на рисунке ниже: - OPENSTACK_ENV — имя региона и репозитория в Gitlab с настройками региона; - VIP_INTERNAL — Внутренний VIP-адрес для региона; - VIP_EXTERNAL — Внешний VIP-адрес для региона. .. image:: media/image_11.png Рисунок 10 — Запуск пайплайна генерации секретов для region1 После заполнения данных нажать кнопку "Run Pipeline". Запустить задачу ``create-config``, как на рисунке ниже. .. image:: media/image_7.png Рисунок 11 — Запуск задачи генерации секретов для region1 Дождаться окончания работы пайплайна. Изменение пароля для IPMI серверов гипервизора ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Нужно зайти в Vault и перейти в ``secret_v2/deployments/region1/passwords_yml``, где region1 — название репозитория с настройками региона. Затем поменять пароль в поле "ipmi_password" на пароль от интерфейса IPMI BMC серверов гипервизора. .. image:: media/image_4.png Рисунок 12 — Изменение пароля IPMI в хранилище секретов региона. На всех серверах нужно создать одинакового пользователя с именем и паролем, который должен быть записан в Vault. Это необходимо для работы сервиса автоэвакуации ВМ при сбое гипервизора и для сервиса Baremetal. Запуск задачи по развертыванию региона ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | Перейти в репозиторий project_k → deployments → region1. | Перейти в Build → Pipelines → Run Pipeline. | Заполнить переменные для пайплана, как на рисунке ниже: - KOLLA_ARGS — переменная для передачи дополнительных тегов: - --limit host1 — выполнение скрипта для отдельного узла Openstack; - --tags cinder — выполнение скрипта для отдельного компонента. - KOLLA_ANSIBLE_DEPLOY_ACTION — список задач для kolla-ansible; - KOLLA_ANSIBLE_IMG_TAG — переменная для версии образа с kolla-ansible, скачиваемого из репозитория Nexus; - KEYSTACK_RELEASE — переменная, в которой указывается ветка git шаблона конфигурации в репозитории project_k → keystack. .. image:: media/image_12.png Рисунок 13 — Запуск пайплайн развертывания облака для region1. После заполнения данных нажать кнопку "Run Pipeline". .. image:: media/image_13.png Рисунок 14 — Задачи пайплайн развертывания облака для region1. Задачи в пайплайн развертывания облака: - ``setup`` — подготовка паролей и настроек для развертывания облака; - ``bootstrap-servers`` — подготовка узлов для загрузки конфигурации (установка необходимых пакетов и конфигурирование компонентов ОС); - ``deploy`` — развертывание и запуск сервисов Openstack на узлах; - ``postconfig`` — применение квот развернутого облака; - ``states`` — наполнение развернутого облака демо-конфигурацией; - ``rally`` — валидация компонентов облака; - ``tempest`` — тестирование развернутого облака на соответствие конфигурации; - ``backup-db`` — бэкап БД MariaDB развернутого облака. Дождаться окончания работы задачи ``setup``. Запустить задачу ``bootstrap-servers``, дождаться окончания работы задачи. Запустить задачу ``deploy``, дождаться окончания работы задачи. Получение openrc из Vault ^^^^^^^^^^^^^^^^^^^^^^^^^ На LCM-узле в консоли выполнить команду: .. code:: bash docker exec -ti vault vault read secret_v2/data/deployments/region1/openrc -format=json | jq -r '.data.data.value' > openrc-region1 | Где region1 — название региона и репозитория в Gitlab в группе project_k → deployments. | В конец файла добавить строку: .. code:: bash export OS_CACERT=/installer/data/ca/cert/chain-cert.pem По аналогии сделать для остальных регионов. Подключение дисковых массивов ----------------------------- iSCSI ~~~~~ Протокол iSCSI является протоколом хранения данных, инкапсулирующим фреймы SCSI для передачи по IP-сетям. Для подключения iSCSI необходимо выполнить следующие действия: 1. Зайти в репозиторий региона. 2. Открыть на редактирование файл ``globals.d/region.yml``. 3. Внести в файл следующие опции: - Enable_cinder_backend_iscsi: "yes" - Enable_cinder_backend_lvm: "no" 4. Запустить новый пайплайн с KOLLA_ARGS: -t cinder. NFS ~~~ NFS - это сетевая файловая система, которая является методом обеспечения доступности файловой системы по сети. Для ее подключения необходимо выполнить следующие действия: 1. Зайти в репозиторий региона. 2. Открыть на редактирование файл ``globals.d/REGION.yml``. 3. Внести в файл следующую опцию: - Enable_cinder_backend_nfs: "yes" 4. Создать новый файл в каталоге config с именем ``nfs_shares`` и внести в него записи для каждого узла хранения: - storage01:/kolla_nfs - storage02:/kolla_nfs 5. На узлах хранения storage01 и storage02 создать файл ``/etc/exports``, в котором будут храниться тома: - /kolla_nfs 192.168.5.0/24(rw,sync,no_root_squash). В данном примере ``/kolla_nfs`` - это каталог на узле хранения, в который будет смонтирован nfs; ``192.168.5.0/24`` - сеть хранения; ``rw,sync,no_root_squash`` - действие, делающее общий ресурс синхронным для чтения и записи и запрещающее удаленным пользователям root иметь доступ ко всем файлам. 6. Далее на узлах хранения запустить сервис nfsd: - systemctl start nfs 7. Запустить новый пайплайн с KOLLA_ARGS: -t cinder. FC ~~ Для подключения Huawei Dorado с поддержкой FC необходимо выполнить следующие действия: 1. Зайти в репозиторий региона. 2. Открыть на редактирование файл ``globals.d/REGION.yml``. 3. Внести в файл следующие опции: - Enable_multipathd: "yes" - Enable_cinder_backend_lvm: "no" - Default_volume_type: "huawei_storage" 4. Создать новый файл в каталоге config/cinder с именем ``nfs_shares`` и внести в него записи: :: Dorado FC user {{ lookup('hashi_vault', 'secret={{ vault_engine }}/data/{{ vault_prefix }}/{{ OPENSTACK_ENV | lower }}/huawei')['data']['UserPassword'] }} https://IP_ADDRESS:8088/deviceManager/rest/ NAME_POOL Thin 5. Создать файл в каталоге config с именем ``cinder.conf`` с внести в него данные: :: [DEFAULT] default_volume_type = {{ default_volume_type }} enabled_backends = huawei_storage enforce_multipath_for_image_xfer = true use_multipath_for_image_xfer = true [huawei_storage_high] allowed_direct_url_schemes = cinder cinder_huawei_conf_file = /etc/cinder/nfs_shares enforce_multipath_for_image_xfer = true use_multipath_for_image_xfer = true volume_backend_name = huawei_storage volume_driver = cinder.volume.drivers.huawei.huawei_driver.HuaweiFCDriver backend_host = huawei 6. Создать файл в каталоге config с именем ``multipath.conf`` и внести в него данные: :: defaults { user_friendly_names no find_multipaths yes } blacklist { } devices { device { vendor "HUAWEI" product "XSG1" path_grouping_policy "multibus" path_selector "service-time 0" path_checker "tur" prio "const" failback "immediate" dev_loss_tmo 30 fast_io_fail_tmo 5 no_path_retry 15 } } 7. Запустить новый пайплайн с KOLLA_ARGS: - -t cinder, multipath. Описание системы обновления LCM ------------------------------- Реализованная система обновления разделена на две основные составляющие части: 1. Обновление репозиториев в Gitlab. 2. Обновление и добавление новых контейнеров Openstack в Nexus. Для обновления этих компонентов используются сценарии (пайплайны), созданные в gitlab-ci. Обновление репозиториев и контейнеров ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ В репозитории project_k/services/upgrade, который размещен в Gitlab, есть один пункт в пайплайне, отвечающий за обновление компонентов LCM. Для обновления компонентов необходимо выполнить следующие действия: 1. Зайти на узел LCM по ssh, а затем перейти в каталог /installer/update. 2. Скачать или переместить ранее скачанное обновление в этот каталог. 3. В репозитории project_k/deployments/upgrade зайти в раздел CI/CD и выбрать "Pipelines", чтобы открыть пайплайны. .. image:: media/image_15.jpg Рисунок 15 - Выбор нужного пайплайна 4. Запустить новый пайплайн, нажав кнопку "Run pipeline". .. image:: media/image_16.jpg Рисунок 16 - Запуск выбранного пайплайна .. image:: media/image_17.jpg Рисунок 17 - Запуск процесса обновления 5. После успешного завершения пайплайна необходимо удалить все из каталога /installer/update. .. |image1| image:: media/image_9.png