#teamcity #aws
Для работы тестов в билдах в качестве шага сборки запускается скрипт, добавляющий Teamcity agent в Security Group нашего VPC на AWS.
В какой-то момент билды стали падать в Teamcity, т.к лимит на правила Security Groups исчерпан.
Все бы ничего, но в сборках явно прописано, что при падении билда нужно подчищать за собой и удалять из SG айпи адреса EC2 инстансов.
В Teamcity при этом есть какая-то фича, которая скипает обязательные шаги, если билд был Отменен, тем самым возникает ситуация, когда IP адрес был добавлен, но не был удален. Количество правил в SG растет за день.
Аудит не помог выявить ни людей, отменяющих билды, ни причины отмены билдов и ситуаций, когда +1 -1 действия по добавлению/подчистке правил выстраивают такую очередь.
За сим вопрос:
За какую метрику зацепиться, чтобы точно знать, что конкретный ЕС2 инстанс отработал свое? Вместо подхода "убери за собой" я хочу добавить периодический таск на вычистку SG, но не совсем понятно в какой момент времени и основываясь на чем формировать пул IP адресов машин-агентов, которые можно подчистить
Как воркэраунд я вижу вариант:
1 Оценить максимальное время билдов, добавить временной оффсет для надежности
2 Когда запускаются билды, как только известен айпи машины, помещать время старта агента с его айпи в тимсити параметр
3 В момент запуска таски на удаление IP проверять IP, которые уже были завершены давно (сравниваем с временем из п1) и удаляем
Некоторую сложность добавляет то, что ЕС2 инстансы теряют свои атрибуты после того как переходят в состояние terminated. То есть AWS API не очень тут поможет как я вижу
А при старте инстанса можно вызвать curl yourapiservice/hostname=fsgyxvbhjhvcsfj или переменную окружения type=auto tests, core, ui и потом прочитать из контейнеров или нормальный способ)
