Облегченная реализация сервера Python AMQP для dev и mock? - PullRequest
Новая
       13

Облегченная реализация сервера Python AMQP для dev и mock?

5 голосов
/ 03 марта 2011

В Django запуск ./manage.py runserver действительно хорош для dev, избегая хлопот по настройке и запуску реального веб-сервера.

Если вы не используете Django, вы все равно можете очень легко настроить сервер gunicorn.

Есть ли что-то похожее для AMQP?

Мне не нужна полная реализация или что-то надежное, просто что-то, что легко установить и запустить для dev. Пакет PyPi был бы великолепен.

Сельдерей не является ответом. Я не хочу клиента, я хочу сервер. Как мини-питон RabbitMq.

Ответы [ 2 ]

3 голосов
/ 03 марта 2011

Я не знаю ни одного брокера AMQP, реализованного на Python. И я не знаю о «облегченной» реализации в целом; Я думаю, что реализация брокера AMQP достаточно сложна, и те, кто его пробует, либо стремятся быть близкими к одной из версий спецификации AMQP, либо вообще не заморачиваются. :)

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

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

Но вы не реализуете внутренние компоненты брокера, и вы можете настроить его динамически, чтобы (в отличие от веб-сервера) ему не нужно было перезапускаться каждый раз, когда вы меняете свой код. Обмены, привязки и очереди могут быть объявлены тестируемым приложением, а затем автоматически удалены.

Установка RabbitMQ совсем не сложна, и для нее практически не требуется настройка, если таковая имеется, поскольку она поставляется с учетной записью пользователя по умолчанию vhost и guest, которая подходит для использования в изолированной тестовой среде. Поэтому у меня никогда не было проблем с тем, чтобы RabbitMQ просто работал на моей тестовой машине.

Может быть, у вас была какая-то конкретная проблема, о которой я не думал; если это так, пожалуйста, оставьте комментарий (или разверните свой вопрос), чтобы объяснить это.

Редактировать: В последнее время я довольно много тестировал приложения на основе AMQP, и я обнаружил, что Плагин управления RabbitMQ очень полезен. Он включает в себя HTTP API , который я использую для создания нового виртуального хоста для каждого запуска теста и последующего его уничтожения для очистки состояния брокера. Это делает запуск тестов на совместно используемом брокере гораздо менее навязчивым. Использование HTTP API для управления этим, а не тестируемый клиент AMQP позволяет избежать нескольких цикличных испытаний.

0 голосов
/ 19 января 2018

У меня был такой же вопрос, и я был шокирован, увидев, насколько сухое место Даже после всего этого времени вряд ли найдется легкий сервер AMQP. Я даже не мог найти игрушечные реализации на Github. AMQP выглядит как зверь протокола. Я также обнаружил, что RabbitMQ, вероятно, настолько легок, насколько это возможно.

В итоге я выбрал решение на основе Docker для своих интеграционных тестов, которое автоматически запускает и убивает контейнер RabbitMQ. Вам необходимо установить библиотеку Docker Python и (конечно) иметь на своем компьютере работающий демон Docker. Я уже использовал Docker для других вещей, так что это не было важным для моей установки; YMMV. После этого в основном делаю: 

import docker

client = docker.from_env()
c = client.containers.run(
    'rabbitmq:alpine',                       # use Alpine Linux build (smaller)
    auto_remove=True,                        # Remove automatically when stopped
    detach=True,                             # Run in daemon mode  
    ports={'5672/tcp' : ('127.0.0.1', None)} # Bind to a random localhost port
)

container = client.containers.get(c.id)      # Re-fetch container for port
port = container.attrs['NetworkSettings']['Ports']['5672/tcp'][0]['HostPort']

# ... Do any set up of the RabbitMQ instance needed on (127.0.0.1:<port>)

# ... Run tests against (127.0.0.1:<port>)

container.kill()   # Faster than 'stop'. Will also delete it so no need to be nice

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

Если вы хотите что-то более долгое, что не обязательно программно запускается и убивается для постоянного разработчика, тогда нормальный маршрут Docker , вероятно, будет вам лучше.

...