Является ли использование динамического порта хорошим решением для программно-тестовых серверов?

Для тестирования (автоматизированное, TDD, ATDD / BDD, также работающее на конвейере CI / CD) я хочу запустить сервер на динамическом порту. Тест должен запустить сервер, выполнить тесты, остановить сервер. Это должно быть возможно в среде CI / CD, а также на компьютерах разработчиков. Он должен поддерживать одновременное выполнение нескольких тестов. Например, разработчик может работать над двумя ветвями параллельно и, таким образом, запускать тесты параллельно. И решение должно работать на самых разных операционных системах, по крайней мере на BSD, Darwin, Linux и Windows.

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

• Фиксированный номер порта. Это нарушает требование возможности параллельного тестирования. Это можно предотвратить с помощью контейнеризации, но это почти то же самое, что уничтожение плотвы, только виртуальные машины или отдельные HW будут еще хуже. У нас есть «process» и «port» по причине, и нам не нужно бросать контейнеризацию при такой проблеме. Я бы пошел на контейнеризацию, как только интеграционное тестирование подключит несколько серверов и смоделирует их инфраструктуру в среде CI / CD. Но для тестирования компонентов, то есть тестирования отдельного сервера / службы, я бы хотел избежать контейнеризации.
• Случайный порт из диапазона зарегистрированных портов. Это имеет две проблемы. Во-первых, нет никакой гарантии, что случайный порт доступен. Существует небольшая вероятность того, что случайный порт из зарегистрированного диапазона портов недоступен (уже связан другим процессом). Кроме того, диапазон зарегистрированных портов зависит от ОС. В то время как RFC 6056 четко описывает диапазон случайных портов от 1024 до 49151, некоторые операционные системы, такие как Linux, используют другой диапазон.
• Предварительно проверил случайный порт. То же, что и случайный порт, но порт будет проверен на наличие. Я вижу риск возникновения гонки. Программное обеспечение CI проверяет доступность, видит, что оно бесплатно, запускает приложение с портом, и между CI проверяет доступность и вызов приложения bind()другим процессом, уже связавшим порт.
• Использование порта из динамического диапазона портов, обычно используемого для временных портов. Это делается путем пропускания portиз socket-за bind()вызова в качестве 0. ОС назначит порт из своего динамического диапазона портов (также называемого временным диапазоном портов). Для меня это выглядело как лучшее решение, пока я не узнал о самоконтроле TCP. Теперь мне интересно.

Чтобы воспроизвести самоподключение TCP, вы можете просто запустить while true ; do telnet localhost 50000 ; doneи подождать некоторое время. Через некоторое время вы увидите, что телнету удалось подключиться - к себе!

Я думаю, что TCP самоподключение не должно быть проблемой в этом случае. Существует, bind()но нет connect()вызова с сервера, вместоlisten() вызова, поэтому порт заблокирован и не будет использоваться, пока он не освободится. Затем этот номер порта используется для подключения тестового клиента. Самостоятельное подключение TCP будет проблемой только в том случае, если тест будет продолжаться, несмотря на то, что сервер не может подключиться, и будет неоднократно пытаться подключиться к серверу (безуспешно) и не будет проходить тесты, пока один из тестов не попадет в ловушку самопроизвольного TCP. подключиться и, таким образом, тестовый клиент будет общаться с самим собой Это может привести к тайм-ауту, что означает, что тест будет медленным, но этот тест будет так или иначе с самого начала провален (он вообще не должен пытаться запускать какие-либо тесты, если сервер не может быть запущен успешно), что Я не считаю, что это разумный сценарий для решения.

Итак, вопрос заключается в следующем: является ли использование динамического порта ( bind()порта 0) хорошим решением для предотвращения конфликтов портов при тестировании серверов?