522 ошибка CloudFlare

Имеется сервер на debian, конфигурация из нескольких контейнеров. Регулярно возникает ошибка, в результате которой uwsgi/celery воркеры перестают отвечать, занятость по нулям, с RAM и остальным все ок, контейнеры отображаются как рабочие, не происходит рестарта. Лечится перезапуском stop/up. В какую сторону смотреть и где искать в чем проблема?

Всем привет!
Коллеги, у меня вопрос по TeamCity.

Есть билд-конф для сборки и деплоя приложения.

Он на билд-сервере собирает приложение, потом rsync-ает его на дев-тест-прод сервер в папочку например /var/pkg/app-v.1.2.3, потом делает симлинку на эту папку в /var/app , условный uwsgi рестартует и подхватывает новое приложение по этой симлинке.

Вопрос вот какой: как мне в тимсити настроить удаление старых /var/pkg/app-vX.X.X на серверах?
Есть какие-нибудь в тимсити инструменты, чтоб я мог увидеть список задеплоеных версий и кнопочкой грохнуть ненужные?

/report

Я бы предложил настроить в TC External Artifact Storage или просто в Build Step-e собирать nuget/maven пакет и отправлять в Artifactory/Nexus.
Мы работаем с Nexus-ом, метаданные билдов пишем в базу Деплоймент тулы

Не совсем понял, что именно надо делать.
У нас есть и сборка отдельных библиотек, которые пушатся в артифактори, но мой вопрос был не про артифакты сборки, а про результат деплоя - папка на дев-тест-прод сервере, в которой уже собранное и готовое к работе (или даже работающее) django-приложение. И вот если оно не работает и уже не нужно - хотелось бы иметь возможность его удалить, жмакнув кнопочкой в тимсити.

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

Ну ты можешь накостылить зависимый билд который будет выносить текущий. Но нет возможности предотвратить его случайный запуск

Я думаю проще будет накостылись билд, который будет выносить всё, кроме последних 2-3 деплоев. Тогда можно будет без кнопочки обойтись.
Останется открытым вопрос о кнопочке для переключения симлинка между оставшимися деплоями, но это уже потом

Камрады, не холивара ради, а по насущной потребности, с помощью чего в 2020 деплоить контейнеризованные аппликухи? Kubernetes не предлагать ) Хочется простого решения, которое было бы по силам в сопровождении маленькой командой разрабов, что-то вроде docker swarm'а. Будущность последнего под вопросом, поэтому назрел данный вопрос :)

Камрады, не холивара ради, а по насущной потребности, с помощью чего в 2020 деплоить контейнеризованные аппликухи? Kubernetes не предлагать ) Хочется простого решения, которое было бы по силам в сопровождении маленькой командой разрабов, что-то вроде docker swarm'а. Будущность последнего под вопросом, поэтому назрел данный вопрос :)