Amazon Elastic Beanstalk является одним из самых популярных сервисов, предоставляемых AWS. Эластичный бобовый стебель поставляется с двумя вариантами: рабочий и веб-приложение.
Рабочее приложение получает сообщения из очереди sqs и обрабатывает их. Если процесс прошел успешно, сообщение удаляется из очереди, в противном случае сообщение должно оставаться в очереди или после нескольких неудачных попыток оно возвращается в очередь недоставленных сообщений. Если вы хотите больше узнать о elb, я написал руководство по развертыванию вашего весеннего приложения с использованием elb и cloudformation.
Работники Elastic Beanstalk действительно хороши тем, что ими управляют, их можно масштабировать вверх / вниз в зависимости от ваших рабочих нагрузок, и они предоставляют широкий спектр сред разработки, таких как java, node.js, а также вы можете использовать образы докеров.
Хотя эластичный компонент может творить чудеса, если у вас есть инфраструктура на основе aws, у вас могут возникнуть некоторые проблемы, когда вы попытаетесь перейти к инфраструктуре на основе контейнеров с помощью механизма оркестровки контейнеров.
Скорее всего, ваше контейнерное рабочее приложение будет работать без каких-либо дополнительных настроек, однако вам нужно найти альтернативу для агента, который отправит сообщения очереди в ваше приложение.
Для простоты я реализовал механизм, который извлекает сообщения из очереди и отправляет их в рабочее приложение.
Проекты контейнер-очередь-работники направлены на то, чтобы обеспечить простой способ миграции ваших гибких рабочих бобовых стеблей в систему оркестровки докеров.
Поскольку решение основано на Scala, его можно использовать как автономное приложение jvm или запустить в контейнере с помощью образа из dockerhub .
После того, как настроить то, что вам нужно, чтобы добавить конфигурации маршрутизации.
Это можно сделать с помощью переменных среды
|
1
2
3
|
WORKER_TYPE=sqsWORKER_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-networkservices: 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, являются их собственными. |

