An Introduction to Local AWS Deployment with LocalStack

0
943

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.

Advertisement

LEAVE A REPLY

Please enter your comment!
Please enter your name here