Task

Приложение будет построено по трёхзвенной архитектуре, то есть состоять из двух серверных частей и одной клиентской части:

"Back-end" сервер
Простой HTTP ping-сервер: слушает заданный порт, на любой запрос отвечает "OK" с HTTP-кодом ответа 200.
Логирует время и источник запроса в файл.
Символизирует некие источники данных в системе.

"Front-end" сервер
HTTP-сервер. Слушает заданный порт, принимает в post-data список адресов back-end серверов, обращается к каждому из них,
и после этого отвечает своему клиенту "OK" с кодом ответа 200. Логирует время и источник запроса, а также время,
длительность похода и адрес каждого back-end сервера в файл.
Символизирует слой бизнес-логики, собирающей информацию с back-end серверов и формирующий результат обработки для пользователя.

"Клиент"
Консольная утилита. Читает файл со списком адресов back-end серверов и формирует запрос на front-end сервер.
Дожидается ответа, логирует время, длительность запроса и список back-end серверов в файл.

Модули:
logging
argparse

Посмотрел - неплохо бы еще и клиент запихнуть в контейнер.
А то например на OS X у меня проблемы с запуском - там снаружи контейнеров попасть внутрь нетривиально.

Заодно должны уйти эти непонятки с абсолютными путями до файлов - в контейнер с клиентским "приложением" должны
монтироваться папки для логов и конфигов (backend_list.txt например)

Ну и да, посмотри в сторону docker-compose. Опыт с нативным docker это очень полезно,
но композ тут очень хорошо должен подойти.

Я имел ввиду что пробросить порт из контейнера наружу на не-линуксе не тривиально, т.к. контейнер запускается не нативно,
а внутри линуксового virtualbox . И, как следствие, все порты сам докер пробрасывает только до туда.

У контейнеров по идее разные адреса, и пора перестать рандомить порты.
Сделать замыкание - контейнеры доступны внутри своей композиции.