Brug LocalStack og spar tid og besvær, når du udvikler dit AWS-system

Sådan kommer du i gang med LocalStack

Der er flere måder at installere og starte for LocalStack, men den letteste måde er klart at gøre brug af Docker og Docker-compose. Udover Docker kræver dette kun, at du har installeret AWS CLI på dit system, før du er i gang.

1. Opret docker-compose.yml fil
2. Kør cli kommandoen “docker-compose up”
3. Når der bliver meldt ready, er LocalStack oppe at køre.
4. Benyt AWS CLI-kommandoer med ”–endpoint-url” parameteren for at interagere med LocalStack. Fx ”aws –endpoint-url=http://localhost:4572 s3 ls” for at liste aktive buckets.

Docker-compose-eksempel

version: '2.1'

services:
  localstack:
    image: localstack/localstack:0.9.0
    ports:
      - "4567-4583:4567-4583"
      - "${PORT_WEB_UI-8080}:${PORT_WEB_UI-8080}"
    environment:
      - SERVICES=${SERVICES- }
      - DEBUG=1
      - DATA_DIR=/tmp/localstack/data
      - PORT_WEB_UI=${PORT_WEB_UI- }
      - LAMBDA_EXECUTOR=docker
      - KINESIS_ERROR_PROBABILITY=${KINESIS_ERROR_PROBABILITY- }
      - DOCKER_HOST=unix:///var/run/docker.sock
      - LOCALSTACK_HOSTNAME=${LOCALSTACK_HOSTNAME- }
      - DEFAULT_REGION=us-east-1
    volumes:
      - "localstack-vol:/tmp/localstack"
      - "/var/run/docker.sock:/var/run/docker.sock"
volumes:
  localstack-vol:

Her er et eksempel på en docker-compose.yml-fil, der starter LocalStack i version 0.9.0. Nogle vigtige punkter her er det image, der bruges, da man her bestemmer versionen, og det ikke er alle versioner af LocalStack, der fungerer på alle OS. Udover dette er det forskellige miljøvariabler, der kan sættes til forskellige ting.

DEBUG øger beskrivelsen af de fejlbeskeder, du får, når noget fejler. Det kan være en Lambda-funktion, der ikke er kodet korrekt, hvor du så får lidt mere information om, hvad der fejlede.

LAMBDA_EXECUTOR skal være sat til Docker for at køre Dotnet Lambdaer.

LOCALSTACK_HOSTNAME giver en IP-adresse, som skal bruges i Lambda-funktionerne, for at de kan kommunikere med LocalStack services.

Eksempel på Lambda-kode der konfigurerer en S3-klient til at snakke med LocalStack ved at bruge LOCALSTACK_HOSTNAME:

AmazonS3Config config = new AmazonS3Config
{
    ServiceURL = "http://" + Environment.GetEnvironmentVariable("LOCALSTACK_HOSTNAME") + ":4572",
    UseHttp = true,
    ForcePathStyle = true
};
S3Client = new AmazonS3Client("default", "default", config);

Se dette link for mere information om konfigurationer.

Virker også med Serverless

Foretrækker du at benytte Serverless, så har LocalStack lavet en Serverless LocalStack. Dette tillader dig at konfigurere dit Serverless system til at deploye til LocalStack i stedet for AWS.

Et lille system der fungerer ens på AWS og LocalStack

Dette er en konceptuel tegning, der viser et system, der kan køres både i AWS og LocalStack. Det består af en S3 bucket, der indeholder Dotnet Lambda-kode. Denne kode abonnerer på en SQS-besked og gemmer indholdet af den i en S3 bucket. Du kan altså sende en besked til en SQS. Dette event modtages så af en Lambda-funktion, der gemmer beskeden i en .txt fil i en S3 bucket. Denne fil kan herefter downloades, hvori du kan læse beskeden.

For at opsætte dette system manuelt på LocalStack køres følgende AWS CLI-kommandoer i denne rækkefølge:

1. aws –endpoint-url=http://localhost:4572 s3api create-bucket –bucket store-bucket
2. Byg dotnet.zip file med Lambda-funktionens kode.
3. aws –endpoint-url=http://localhost:4574 lambda create-function –function-name SQSReader –runtime dotnetcore2.1 –handler LambdaSQSToS3::LambdaSQSToS3.Function::FunctionHandler –environment Variables={Environment=LocalStack} –role NotNeeded –zip-file fileb://dotnet.zip
4. aws –endpoint-url=http://localhost:4576 sqs create-queue –queue-name SimpleSQS –attributes VisibilityTimeout=300
5. aws –endpoint-url=http://localhost:4574 lambda create-event-source-mapping –batch-size 10 –event-source-arn arn:aws:sqs:elasticmq:000000000000:SimpleSQS –function-name SQSReader

Systemet kører nu og er klar til at modtage beskeder til SQS:

1. aws –endpoint-url=http://localhost:4576 sqs send-message –queue-url http://localhost:4576/queue/SimpleSQS –message-body “testing 123”
2. aws –endpoint-url=http://localhost:4572 s3 cp s3://store-bucket/SQSTest.txt localOutput.txt

Filen localOutput.txt vil nu indeholde beskeden ”testing 123”.

For at opsætte samme system ved brug af CloudFormation:

1. aws –endpoint-url=http://localhost:4572 s3api create-bucket –bucket code-bucket
2. aws –endpoint-url=http://localhost:4572 s3api put-object –body fileb://dotnet.zip –bucket code-bucket –key dotnet.zip
3. aws –endpoint-url=http://localhost:4581 cloudformation create-stack –stack-name test –template-body file://AutomatedDeployment.yaml –parameters ParameterKey=DeploymentTarget,ParameterValue=LocalStack

Filen AutomatedDeployment.yaml er en konfigurationsfil, der beskriver systemet, som ellers opsættes manuelt ovenover. Den er lavet, så den kan deployes til både LocalStack og AWS afhængig af, hvilken miljøvariabel der bliver givet med. Det er altså muligt at benytte sig af CloudFormation i LocalStack.

Begrænsninger

Vi har opdelt de begrænsninger, vi har mødt i betydelige som nogle, der resulterer i manglende funktionalitet og mindre betydelige, som er nogle, der kræver manuel opsætning eller giver andre mindre problemer.

Forskelle mellem LocalStack og AWS

Selv om LocalStack og AWS fungerer meget ens, er der stadig forskel. Det kan gøre det lidt besværligt at arbejde med, når du har noget, der fungerer i AWS, men ikke kan genskabe det i LocalStack eller omvendt.

Krav om StartingPosition i EventSourceMappings

Et andet problem med EventSourceMappings og CloudFormation er at den kræver StartingPosition i SQS mappings. Dette er ikke et krav i AWS, da den ikke har nogen effekt for SQS, og fejlbeskeden du får fra LocalStack, er bare at din CloudFormation konfigurationsfil ikke er korrekt. Læs mere her.

Strukturen af SQS ARN

En af de store forskelle er, hvordan ARN bliver lavet til SQS. Normalt ser konstruktionen sådan ud “arn:aws:sqs:{region}:000000000000:{queue_navn}”, men i LocalStack er konstruktionen derimod “arn:aws:sqs:elasticmq:000000000000:{queue_navn}”.

Problem i CloudFormation

Især i CloudFormation er dette et problem. Hvis du laver en EventSourceMapping, er du nødt til manuelt at konstruere det meste af din ARN, da !GetAtt for SQS returnerer den forkerte ARN.

Problem i Dashboard

I LocalStacks dashboard viser dette problem sig også, da det viser den forkerte ARN til SQS. Og værre endnu, hvis du benytter dashboardet til at se dine services, og du har brugt den forkerte ARN til din EventSourceMapping. Så laves der visuelt en mapping mellem SQS og Lambda-funktionen, som ikke er korrekt. Laver du derimod en korrekt mapping, der fungerer i koden, vises denne ikke i dashboardet.

Samtidig er der også andre services, som slet ikke vises i dashboardet. Her er der bl.a. tale om API Gateway, som du kun kan se gennem CLI, hvis du spørger efter den.

Så skal du bruge LocalStack eller ej?

Vi har samlet fordele og ulemper, så du let kan se, om LocalStack kunne være noget for dig.