без ручных диффов и прочего

не, metal

....k8s

ибо описанное - костыли

там есть роллинг и блю-грин деплойменты

на крайняк ansible, что обеспечит минимальную повторяемость, и перед этим раскатывать в стейжинге с полными тестами

Даже если про k8s то речь об обновлении ОС на ноде.

на дедике

в случае кубера - отвалиться может только нода, а это сразу будет видно. Суть же что серверов много, потеря нескольких вполне штатна

и проверять нужно только 2 сервиса, а не пачку "включая нгигх"

более того, читаем про .service файлы, там есть авторестарт (с пинками типа бесконечное количество попыток + выставить время между рестартами), и время работы сервиса в графану. Так же, нужны некие проверки что сервис не просто "типа запустился" а полноценно работает. Нет базы например - оно может работать и ждать базу, но ничего не обслуживать.

собсно, это и можно назвать девопсом наверное, правильно уметь всё автоматизировать

Хорошо быть богатым и здоровым… Ладно, на баше и курле напишу смоктесты

советую всё-таки тогда с ансибла начать.

ибо "диффы снапшотов" это полный бред. Снапшоты что дисков что памяти будут всегда отличаться, а ps -aux > step1 и подобное - это даже не костыли, это костыли для костылей.. Даже если откинуть версии, оставить только имена, а тут yum|apt сам доставил новых пакетов, потому что они появились в зависимостях и так далее... С другой стороны надо идти. Тестировать приложения, апи + селениум, а не снапшоты дёргать. И обкатывать в тесте.

Ансибль есть в арсенале, но для установки того же nginx

на тесте обновление убунты до 18.04 прошло без проблем

при state:latest он вполне может проверить что пакеты обновило, а через тот же сервис потом проверить что сделан рестарт и статус рабочий..

но я бы ооочень советовал отделить мух от котлет

хост ноду от среды для приложений, и тесты что стоит от тестов что приложение работает