maestro-aws uses LocalStack to provide SNS and SQS for local runs. I maintain MiniStack, an MIT licensed AWS emulator, and checked whether it covers what maestro needs here. It does, with no changes to the bootstrap scripts and none to application-aws.yml.
What I tested against ministackorg/ministack:latest:
- Both scripts in maestro-aws/localstack ran unchanged. MiniStack reads /etc/localstack/init/ready.d and ships an awslocal shim, so the existing volume mount and the awslocal calls work as they are.
- The six queues are created with the attributes the scripts ask for: VisibilityTimeout 120 on maestro-time-trigger-execution, 30 on maestro-event, FifoQueue=true on the three signal queues, and the RedrivePolicy with maxReceiveCount 5 pointing at maestro-event-dlq.
- The SNS topic, the SQS subscription and RawMessageDelivery=true are all set, and a publish arrives in maestro-event as the raw body with no SNS envelope.
- FIFO ordering holds within a message group, and a message received 6 times lands in maestro-event-dlq.
- Queue URLs come back as http://localhost:4566/000000000000/, the same form already hardcoded in application-aws.yml.
I also ran a probe with the AWS SDK for Java 2.31.78, the version in maestro-aws/gradle.lockfile, covering the calls the Spring Cloud AWS listener makes:
- GetQueueUrl
- GetQueueAttributes with ALL
- FIFO SendMessage with a group id and a dedup id
- ReceiveMessage with long polling and system attributes
- ChangeMessageVisibility
- DeleteMessageBatch
- SNS Publish
All passed.
The change is one line in maestro-aws/docker-compose.yml:
image: ministackorg/ministack
The docker.sock mount and the /var/lib/localstack volume are no longer needed, since SNS and SQS run in process. The redis service is unaffected.
Why it may be worth it: the image is 68 MB to pull against 501 MB for localstack/localstack, and it idles around 50 MB of memory. No account or token is involved for any of the services maestro uses.
What I have not done: I did not run the maestro server end to end, only the AWS surface that the bootstrap and the SDK calls touch. Happy to open a PR with the compose change, and to fix whatever turns up once the full server runs against it.
Disclaimer: I am a mantainer in Ministack
maestro-aws uses LocalStack to provide SNS and SQS for local runs. I maintain MiniStack, an MIT licensed AWS emulator, and checked whether it covers what maestro needs here. It does, with no changes to the bootstrap scripts and none to application-aws.yml.
What I tested against ministackorg/ministack:latest:
I also ran a probe with the AWS SDK for Java 2.31.78, the version in maestro-aws/gradle.lockfile, covering the calls the Spring Cloud AWS listener makes:
All passed.
The change is one line in maestro-aws/docker-compose.yml:
image: ministackorg/ministackThe docker.sock mount and the /var/lib/localstack volume are no longer needed, since SNS and SQS run in process. The redis service is unaffected.
Why it may be worth it: the image is 68 MB to pull against 501 MB for localstack/localstack, and it idles around 50 MB of memory. No account or token is involved for any of the services maestro uses.
What I have not done: I did not run the maestro server end to end, only the AWS surface that the bootstrap and the SDK calls touch. Happy to open a PR with the compose change, and to fix whatever turns up once the full server runs against it.
Disclaimer: I am a mantainer in Ministack