feat: switch to LocalStack Pro image

[pinzon]

Motivation

The localstack/localstack image is being migrated to LocalStack Pro. After March 23rd, the community image will no longer work as expected. This update ensures the serverless-localstack plugin
continues to function by switching to localstack/localstack-pro and requiring users to set a LOCALSTACK_AUTH_TOKEN.

Changes

• docker-compose.yml: Updated image from localstack/localstack to localstack/localstack-pro and added LOCALSTACK_AUTH_TOKEN environment variable
• src/index.js: Updated startContainer() to use the pro image via and log a warning if LOCALSTACK_AUTH_TOKEN is not set
• src/index.js: Added method to determine the image to use by the localstack-cli
• .github/workflows/ci.yml: Updated CI to pull and start localstack/localstack-pro, passing LOCALSTACK_AUTH_TOKEN from GitHub secrets
• README.md: Updated pre-requisites and environment variables documentation to reflect LocalStack Pro requirement
• package.json: Bumped version from 1.3.1 to 1.4.0

Notes

• Co-authored by Claude

[alexrashed]

Thanks for preparing serverless-localstack for our upcoming image consolidation! But I think there might be a bit of a misunderstanding. I think we should move towards using the Pro image (with an auth token) everywhere now, such that - at the time of the image consolidation - this will just continue to work.
This PR - to me - seems like it's moving to explicitly use community (at least for as long as localstack/localstack is still the OSS version). This would mean that some users who are already using Pro would suddenly start using Community (?!) and for all users this will suddenly break with the image consolidation (because no auth token is set).

In addition, there are also other usages of Community here in the repo which are not touched by this PR:

• serverless-localstack/src/index.js

  Lines 525 to 539 in e7e53d8

  	const startContainer = () => {
  	this.log('Starting LocalStack in Docker. This can take a while.');
  	const cwd = process.cwd();
  	const env = this.clone(process.env);
  	env.DEBUG = '1';
  	env.LAMBDA_EXECUTOR = env.LAMBDA_EXECUTOR || 'docker';
  	env.LAMBDA_REMOTE_DOCKER = env.LAMBDA_REMOTE_DOCKER || '0';
  	env.DOCKER_FLAGS = (env.DOCKER_FLAGS || '') + ` -v ${cwd}:${cwd}`;
  	env.START_WEB = env.START_WEB || '0';
  	const maxBuffer = +env.EXEC_MAXBUFFER || 50 * 1000 * 1000; // 50mb buffer to handle output
  	if (this.shouldRunDockerSudo()) {
  	env.DOCKER_CMD = 'sudo docker';
  	}
  	const options = { env: env, maxBuffer };
  	return exec('localstack start -d', options)

• serverless-localstack/.github/workflows/ci.yml

  Lines 56 to 61 in e7e53d8

  	- name: Start LocalStack
  	run: |
  	pip install localstack awscli-local[ver1]
  	docker pull localstack/localstack
  	localstack start -d
  	localstack wait -t 30

• https://github.com/localstack/serverless-examples/blob/c4874f3cb38d67d64f90cc2d444941c55d8064b9/Makefile#L7-L8

Happy to discuss this directly, but I guess the most important question is: How should this tool look like / act when there is no separation between Community and Pro anymore, and how can this be executed on as soon as possible (rather than breaking at the time of the consolidation or in the worst case even twice)?

[alexrashed]

question: I am a bit confused by this change. Why would you stop setting an auth token when switching to Pro explicitly?

[pinzon]

Because the LocalStack CLI detects if the LOCALSTACK_AUTH_TOKEN env var is set. For the case that it is, it will start the Pro image without extra arguments. The idea of the removal was to save 1 line of code. But I can add it it back if you prefer it.

[alexrashed]

nit: This is out of scope fore this PR, bit it definitely is weird 😄 Why is the package listed here twice?

[pinzon]

CI triaging shenanigans 😅 . The awslocal-cli (the wrapper around aws-cli) is not necessary for the testing.

[alexrashed]

question: Similar to the comment above, this change seems to be actually moving back from using Pro to Community (at least for as long as localstack/locastack is still referencing Community).
But I guess it would be fine, IF a user has set an auth token and its forwarded here correctly. Is this the case?

[pinzon]

There is no --image parameter. This was Claude hallucinating.

[pinzon]

@alexrashed Thank you so much for the thorough review. As you will notice from my answers to your questions, I was relying heavily on the auto detection of the auth token by the localstack-cli. That was because the docs and the help message of the tool do not describe any parameter to allow the specification of the docker image.

Looking at the PR I can see why you assumed I was setting the community version as the main image to use, and made me think that users of the plugin could also be confused. So I searched (and found) in the localstack-cli codebase for a config var that allows the specification of the LocalStack image: IMAGE_NAME.

So with that in mind. I added the option for users to set the image variable in the plugin configuration. Now the plugin will default to pro image if no configuration is specifically set.

Happy to discuss any more improvements to this pr 👍