LocalStack provides an easy-to-use test/mock framework for developing cloud applications. It builds on the existing best-of-the-breed test tools like kinesalite/dynalite and Moto. These tools may be individually awesome but lack functionality for certain use cases. LocalStack combines these tools, makes them interoperable and adds important missing functionality on top of them.
Today, Web services are quickly moving to a cloud architecture, and DevOps and testing are following closely. While cloud architectures are highly scalable, there are some challenges to overcome before they provide the maximum benefit to businesses. There are so many benefits in running business applications such as banking services, mobile collaboration apps, mailbox on cloud apps, cloud backup apps, virtual storage drives, etc, on cloud computing environments. Yet, organisations still want to have the ability to visualise how their deployment on the cloud looks like, in order to meet any challenges, before moving on to a full-fledged cloud deployment.
Currently, with the focus primarily on supporting the AWS cloud stack, LocalStack provides an easy-to-use test/mock framework for developing cloud applications. It builds on the existing best-of-breed mock/testing tools like kinesalite/dynalite and Moto. While these tools are individually awesome, they lack functionality for certain use cases. LocalStack combines these tools, makes them interoperable and adds important missing functionality on top of them.
Let us look at some of the functions that LocalStack adds.
Error injection: LocalStack allows injection of the errors that frequently occur in real cloud environments — for instance, ProvisionedThroughputExceededException, which is thrown by Kinesis or DynamoDB if the amount of read/write throughput is exceeded.
Isolated processes: All services in LocalStack run in separate processes. The overhead of additional processes is negligible, and the entire stack can easily be executed on any developer machine and CI server. In Moto, the components are often hard-wired in the RAM, e.g., when forwarding a message on an SNS topic to an SQS queue, the queue endpoint is looked up in a local hash map. In contrast, LocalStack services live in isolation as separate processes available via HTTP, which fosters true decoupling and more closely resembles the real cloud environment.
Pluggable services: All services in LocalStack are easily pluggable and replaceable, due to the fact that we are using isolated processes for each service. This allows us to keep the framework up-to-date and select best-of-breed mocks for each individual service.
Installing LocalStack
The easiest way to install LocalStack is via Pip:
pip install localstack
Once installed, run the infrastructure using the following command:
localstack start
Note: Please do not use sudo or the root user. LocalStack should be installed and started entirely under a local non-root user. If you have problems with permissions in MacOS X Sierra, install with ‘pip install —user localstack’.
Running LocalStack in Docker
You can also spin up LocalStack in Docker, as follows:
localstack start --docker
Or by using docker-compose (you need to clone the repository first; it currently requires docker-compose version 2.1+):
docker-compose up
Note: On MacOS you may have to run TMPDIR=/private$TMPDIR localstack start —docker if $TMPDIR contains a symbolic link that cannot be mounted by Docker.
Use an existing docker-compose project. Add in existing services. The project can be found in Docker Hub, so there’s no need to download or clone the source:
version: '2.1'
services:
...
localstack:
image: localstack/localstack
ports:
- "4567-4584:4567-4584"
- "${PORT_WEB_UI-8080}:${PORT_WEB_UI-8080}"
environment:
- SERVICES=${SERVICES- }
- DEBUG=${DEBUG- }
- DATA_DIR=${DATA_DIR- }
- PORT_WEB_UI=${PORT_WEB_UI- }
- LAMBDA_EXECUTOR=${LAMBDA_EXECUTOR- }
- KINESIS_ERROR_PROBABILITY=${KINESIS_ERROR_PROBABILITY- }
- DOCKER_HOST=unix:///var/run/docker.sock
volumes:
- "${TMPDIR:-/tmp/localstack}:/tmp/localstack"
To facilitate interoperability, configuration variables can be prefixed with LOCALSTACK_ in Docker. For instance, setting LOCALSTACK_SERVICES=s3 is equivalent to SERVICES=s3.
LocalStack spins up the following core Cloud APIs on your local machine:
API Gateway at http://localhost:4567 Kinesis at http://localhost:4568 DynamoDB at http://localhost:4569 DynamoDB Streams at http://localhost:4570 Elasticsearch at http://localhost:4571 S3 at http://localhost:4572 Firehose at http://localhost:4573 Lambda at http://localhost:4574 SNS at http://localhost:4575 SQS at http://localhost:4576 Redshift at http://localhost:4577 ES (Elasticsearch Service) at http://localhost:4578 SES at http://localhost:4579 Route53 at http://localhost:4580 CloudFormation at http://localhost:4581 CloudWatch at http://localhost:4582 SSM at http://localhost:4583 SecretsManager at http://localhost:4584 StepFunctions at http://localhost:4585 CloudWatch Logs at http://localhost:4586 STS at http://localhost:4592 IAM at http://localhost:4593
Additionally, LocalStack provides a powerful set of tools to interact with the cloud services, including a fully featured KCL Kinesis client with Python binding, simple setup/teardown integration for nose tests, as well as an environment abstraction that allows easy switching between local and remote cloud implementations.
