Во время собственно деплоя подтверждение успешности выкатки бранча производится путём захода на одну или несколько виртуалок бранча и анализа выхлопа скрипта pan-test. В случае коллекторов - анализ скорости и содержимого логов, выдаваемых скриптом logs (под sudo).

Идём на ong-backend.mhd.local, делаем sudo -i
Идём в «/root/bin10» Запускаем ./deb-backend-upgrade.sh, ждём его завершения (+-40 минут), проводит все бэкенды через руддер; не забываем в ГУЕ руддера смотреть, как добавляются бэкенды. По завершению скрипта должны быть добавлены все 10 и со временем посереть - это нормально.
Далее запускаем ./deb-backend-clean.sh - данный скрипт, в частности, удаляет бэкенды из руддера.
Далее запускаем ./deb-backend-selinux-relabel.sh, после чего объявляем о готовности бэкендов.

При необходимости зайти в бэкенд и что-то проверить делаем это - ./deb-backend-attach.sh cde-deb-proxy/deb-proxy. После проверки необходимого выходим из контейнера и повторяем -clean и -selinux-relabel скрипты.

Идём на p-ong1.mhd.local
Проверяем, что ucarp-ip тут - ip a | grep ucarp -B 2 | grep 172. Если нет, то идём на p-ong1.mhd.local
Снятие нагрузки: nc -U /tmp/haproxy «< «set server main-http-mhd/GGS state maint»
Возврат нагрузки: nc -U /tmp/haproxy «< «set server main-http-mhd/GGS state ready»

Проводится с первого гейта (CDE и DMZ соответственно)

Снимаем нагрузку со второго полужопия CDE (осуществляем в момент проверки успешности деплоя бранча deb-logcollector): ./haproxy_switch.sh cde 1 2 drain
Расшифровка: «На CDE на первой p-proxy перевести в drain все вторые сервисы».
Возвращаем нагрузку на второе полужопие CDE: ./haproxy_switch.sh cde 1 2 ready
Первое полужопие:

• ./haproxy_switch.sh cde 2 1 drain
• ./haproxy_switch.sh cde 2 1 ready

Аналогично делаем в DMZ (c первого гейта dmz, заменяя cde на dmz)

Переключаем ucarp аналогично с первых гейтов скриптами ./deploy_switch_to_2.sh и ./deploy_switch_to_1.sh соответственно. Пояснять тут нечего - всё очевидно.

Проводится на ong-deploy.mhd.local под sudo.

drepo10 update other ossec
drepo10 update panbet panbet
drepo10 update vendor debian
drepo10 snap other
drepo10 snap panbet
drepo10 snap vendor
drepo10 switch other
drepo10 switch panbet
drepo10 switch vendor

Обновляем стенд, прогоняя на каждой виртуалке apt-get update ; apt-get upgrade. Можно использовать bash for, если очень лениво. Потом заходим (attach) в каждый бэкенд и делаем аналогичное.

cd /repo/ol8/other/ol8-atomic
wget -xrkp -N –no-parent -nH –cut-dirs=5 http://www3.atomicorp.com/channels/atomic/centos/8/x86_64/
cd /repo/ol8/panbet/ol8-panbet
wget -xrkp -N –no-parent -nH –cut-dirs=5 http://repo.mhd.local/rpm/oracle/8/STABLE/x86_64/
cd /repo/ol8/vendor/ol8-uek
wget -xrkp –no-parent -nH –cut-dirs=5 http://yum.oracle.com/repo/OracleLinux/OL8/UEKR6/x86_64/
cd /repo/ol8/vendor/ol8-dev-epel
wget -xrkp -N –no-parent -nH –cut-dirs=6 https://yum.oracle.com/repo/OracleLinux/OL8/developer/EPEL/x86_64/
cd /repo/ol8/vendor/ol8-baseos
wget -xrkp -N –no-parent -nH –cut-dirs=6 http://yum.oracle.com/repo/OracleLinux/OL8/baseos/latest/x86_64/
cd /repo/ol8/vendor/ol8-appstream
wget -xrkp -N –no-parent -nH –cut-dirs=5 http://yum.oracle.com/repo/OracleLinux/OL8/appstream/x86_64/
orepo snap other
orepo snap panbet
orepo snap vendor
orepo switch other
orepo switch panbet
orepo switch vendor Да-да, загрузка осуществляется вручную, потому что rpm - говно. Не стоит об этом распространяться.

Обновляем ds с помощью dnf update. При возникновении проблем с сертификатом не стесняемся использовать –nogpgcheck.

Рассмотрим на примере ecommpay: sudo su - panbet
cd instances/ecommpay-service/tomcat/ecommpay-service/
./tomcat stop
sleep 15
./tomcat start

• xl list
• xl create /ZFS/174/config-…-…/….cde.lan
• xl shutdown mail-relay3-cde.cde.lan
• xl console mail-relay3-cde.cde.lan (Ctrl+] для того, чтобы выйти из физ. консоли)
• xl top
• xl dmesg - логи старта гипера