Евгений Хлебников

https://www.haproxy.com/blog/introduction-to-hapro... - но нужно определять параметры стикнеса самому

можно прилипнуть к кукам, которые устанавливаются из параметра квери resumableIdentifier, взяв его с помощью
https://cbonte.github.io/haproxy-dconv/2.1/configu...
пример прилипания к кукам https://www.haproxy.com/blog/enable-sticky-session...

Я, в общем то, никогда не делал такого, но начал бы с документации по `stick on` :D

вот вам максимально похоже на PoSH

Test-Connection -Ping ya.ru -count 100 | FT -HideTableHeaders {Get-Date -Format "ddd MMM dd HH:mm:ss z yyyy"},{$_.BufferSize.ToString()+' bytes'},{'from '+$_.Destination+' ('+$_.Address+'):'},{'icmp_seq='+$_.Ping},{'time='+$_.Latency+' ms'}

Учитывая, что ваши клиенты раньше работали с вашим сайтом - городить инфраструктуру и разные схемы репликации - не имеет особого смысла
Ваши варианты, которые стоит попробовать:
1. CloudFlare
настраиваете domain2.name на вашем сайте, отдаете его под управление CF
не будет работать если для cloudflare наш сайт тоже заблокирован
2. VPS\Cloud
тут схема простая
- domain2.name на VPS там, установка и настройка haproxy или nginx с прокси
- (опционально) VPN до вашего хостинга
- domain.name на вашем хостинге
Почему VPN опционален: трафик в прокси может ходить через ssl

дистриб ничем не отличается
OEM - проверка (если она вообще когда будет) будет проверять что ключ OEM установлен на том пк, с которым покупался

Я поддержу Вадим : опишите эту инфраструктуру как код и поднимайте тестовый стенд только тогда, когда вам надо
В идеале, да - лучше создать второй аккаунт AWS( и связать их в организацию для централизованного управления), чтобы изменениями инфраструктуры теста случайно не задеть прод.
Подход разделения, как описывает ваш коллега, правильный(пункты дальше описывают далеко не все кейсы, так, что в голову пришло пока ответ писал):
1. Трафик теста не пересекается с трафиком прода, что позволяет измерять нагрузку (и планировать, в том числе, расходы на инфраструктуру, у AWS вы как раз в основном за нагрузку и платите) на приложение прямо на балансировщике (если у вас все таки появится больше нагрузки и придется применять горизонтальное масштабирование - добавлять нод приложения за балансером)
2. Трафик теста не пересекается с трафиком прода - не возникнет коллизий, "лишней" нагрузки на балансировщик, всплеска ошибок в мониторинге балансировщика из-за тестового стенда
3. Правила на балансировщике могут быть обезличены(не иметь отношения к среде) и протестированы до внедрения в прод - важно для развития приложения

тот же terraform plan вам напишет почему он хочет заменить инстансы - какие параметры общей для инстансов конфигурации изменились, при невозможности их замены на лету
Если вы меняете важный элемент в настройке, который невозможно заменить без пересоздания инстанса, его надо игнорировать через lifecycle -> ignore changes
Однако так вы потенциально можете получить исключительно увеличение количества объектов
Если вы деплоите в AWS то ASG может помочь - она не пересоздает инстансы без надобности, при добавлении необходимого количества инстансов. При уменьшении, базовая политика удаления инстансов - удалять наиболее старый.

https://habr.com/ru/post/448312/
https://habr.com/ru/company/ruvds/blog/583784/
начните изучение вопроса с этих двух ссылок
В самих статьях есть еще ссылки, в комментариях тоже
Там ответы не на все ваши вопросы но поможет копать в правильном направлении (а так же есть возможность задать вопрос авторам)

P.S. в долгоиграющих планах есть ровно такая же задача, поэтому понемногу собираю данные

защита работала из коробки, без доп. манипуляций.

универсальной защиты не бывает, а это значит, что или надо будет предпринимать какие-то меры на основе того, что происходит (когда настроенная защита не предотвращает ddos), или довериться профессионалам, тем же qrator и подобным, если вы возьмете их услуги. Или же смириться с достаточным уровнем защиты от сетевых атак, которые закроют условные 80% всех случаев DDOS

решение с которого можно начать, чтобы не думать, как мне кажется, это cloudflare
aws предоставляет достаточный уровень базовой защиты всех публичных эндпойнтов, но для более продвинутой защиты используются дополнительные сервисы, за дополнительные деньги, а еще их настраивать надо. самому.

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

для начала: в bat файлах %AllUsersProfile% должно выглядеть как %%AllUsersProfile%%
Во вторых, проверьте, есть ли вообще эта переменная и куда она ведет : в командной строке
echo %AllUsersProfile%
И, конечно, C:\Users в изначальном батнике лишнее, поскольку в современных ОС Windows AllUsersProfile ведет в C:\ProgramData
Заодно проверьте а есть ли по указанному в AllUsersProfile пути ваш исполняемый файл

во первых: это возможно через import VM image
https://docs.aws.amazon.com/vm-import/latest/userg...
во вторых: в связи с изменением виртуального железа - винда попытается переактивироваться после импорта.
у AWS есть свой KMS сервер и если активация по какой то причине не удастся - импорт по идее будет зафейлен.
Впрочем, на stackoverflow люди пишут и об удачных импортах
Для своих лицензий у AWS есть BYOL программа, но, насколько я помню, она относится только к Server продуктам, добавить свою лицензию Win10 вряд ли выйдет

Так что легально использовать клиентские версии Windows на AWS вам вряд ли удастся, даже если импорт пройдет успешно. А нелегально - это вполне себе определенные риски, тем более что все ваши данные у AWS есть

P.S. хочется добавить, что это мои теоретические знания о вопросе. Даже с серверными продуктами зачастую проще сделать новые образы (packer, cloud-init) чем переносить то что у вас на другом хостинге работало, поэтому я миграцией образами никогда не занимался

попробуйте telegraf c input windows_eventlog натравить на нужные логи радиуса - это делается через xpath query
затем выплёвывайте в output в формате прометея

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

#!/bin/bash
#usage check-dates.sh `date in YYYYMMDD format`

for f in /certificates/*.cer
do
  date=$(openssl x509 -in $f -noout -enddate | sed 's/notAfter=//g')
  enddate=$(date -d "$date" +%Y%m%d)
  if (($enddate < "$1"))
  then
### your code here
  fi
done

в "your code" можно хоть письма отсылать со списком сертификатов у которых enddate удовлетворяет вашим критериям
Или же можете, используя пример с openssl, вывести список всех сертификатов с enddate в csv и использовать как то по другому

какие-то пакеты ходят по сети туда сюда

ходють тут всякие..
Wireguard, на секундочку, это UDP, а пинги - ICMP. Протоколы то разные
Открывайте icmp или проверяйте доступность другим способом, например доступность UDP порта с помощью nc
nc -zvu <SERVER> <PORT>

Есть два варианта развития событий: вы распределяете последовательность выполнения по стейжам или рисуете свой граф выполнения
В первом случае последовательность стейжей важна - джобы параллелятся в рамках одного стейжа и следующий стейж не запустится пока не выполнятся все джобы предыдущего.
.pre всегда запускается перед пользовательскими стейжами,
Во втором - вы можете запланировать свой граф выполнения с помощью needs
Я не нашел в документации, что .pre все еще будет выполняться первой, если ее джобы участвуют в вашем собственном графе, так что возможно это решение. В случае использования needs (и gitlab 14.2+ или gitlab.com 14.1) можно вообще не прописывать стейжи. В случае gitlab <=14.0 стейжи все еще нужны, потому что needs не будет работать с джобами одного стейжа.
Внимательно прочитайте требования к needs https://docs.gitlab.com/ee/ci/yaml/#requirements-a... соответственно вашей версии gitlab

внимательно прочитайте https://docs.gitlab.com/runner/executors/docker_ma...
поставили форк docker-machine?