Amazon Elastic Beanstalk является одним из самых популярных сервисов, предоставляемых AWS. Эластичный бобовый стебель поставляется с двумя вариантами: рабочий и веб-приложение.
Рабочее приложение получает сообщения из очереди sqs и обрабатывает их. Если процесс прошел успешно, сообщение удаляется из очереди, в противном случае сообщение должно оставаться в очереди или после нескольких неудачных попыток оно возвращается в очередь недоставленных сообщений. Если вы хотите больше узнать о elb, я написал руководство по развертыванию вашего весеннего приложения с использованием elb и cloudformation.
Работники Elastic Beanstalk действительно хороши тем, что ими управляют, их можно масштабировать вверх / вниз в зависимости от ваших рабочих нагрузок, и они предоставляют широкий спектр сред разработки, таких как java, node.js, а также вы можете использовать образы докеров.
Хотя эластичный компонент может творить чудеса, если у вас есть инфраструктура на основе aws, у вас могут возникнуть некоторые проблемы, когда вы попытаетесь перейти к инфраструктуре на основе контейнеров с помощью механизма оркестровки контейнеров.
Скорее всего, ваше контейнерное рабочее приложение будет работать без каких-либо дополнительных настроек, однако вам нужно найти альтернативу для агента, который отправит сообщения очереди в ваше приложение.
Для простоты я реализовал механизм, который извлекает сообщения из очереди и отправляет их в рабочее приложение.
Проекты контейнер-очередь-работники направлены на то, чтобы обеспечить простой способ миграции ваших гибких рабочих бобовых стеблей в систему оркестровки докеров.
Поскольку решение основано на Scala, его можно использовать как автономное приложение jvm или запустить в контейнере с помощью образа из dockerhub .
После того, как настроить то, что вам нужно, чтобы добавить конфигурации маршрутизации.
Это можно сделать с помощью переменных среды
1
2
3
|
WORKER_TYPE=sqs WORKER_SERVER_ENDPOINT=http: // {docker-service} WORKER_AWS_QUEUE_ENDPOINT=http: // {amazon queue endpoint} |
Или, если вы используете его в качестве контейнера, вы можете добавить файл конфигурации по пути /etc/worker/worker.conf.
1
2
3
4
5
6
7
|
worker { type = sqs server-endpoint = http: // {docker-service} aws { queue-endpoint = http: // {amazon queue endpoint} } } |
Чтобы вам было проще, я добавил файл составления докера, имитирующий желаемый результат.
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
version: '3.5' networks: queue-worker-network: name: queue-worker-network services: worker-server: build: context: . /worker-server dockerfile: Dockerfile ports: - 8080:8080 networks: - queue-worker-network elasticmq: build: context: . /elasticmq dockerfile: Dockerfile ports: - 9324:9324 networks: - queue-worker-network container-queue-worker: image: gkatzioura /container-queue-worker :0.1 depends_on: - elasticmq - worker-server environment: WORKER_TYPE: sqs WORKER_SERVER_ENDPOINT: http: //worker-server :8080/ WORKER_AWS_QUEUE_ENDPOINT: http: //elasticmq :9324 /queue/test-queue AWS_DEFAULT_REGION: eu-west-1 AWS_ACCESS_KEY_ID: access-key AWS_SECRET_ACCESS_KEY: secret-key networks: - queue-worker-network |
Опубликовано на Java Code Geeks с разрешения Эммануила Гкациоураса, партнера нашей программы JCG. Посмотрите оригинальную статью здесь: Перенесите своих эластичных рабочих бобовых стеблей в контейнеры докеров
Мнения, высказанные участниками Java Code Geeks, являются их собственными. |