Posts

Posted on

AWS connect-streams api testing locally: issues and workarounds

To initialize the Connect CCP using amazon-connect-streams api in a webpage locally there are several steps to configure. The most likely errors if you haven’t followed all the steps is a X-Frame-Options sameorigin error which you’ll see in your devtools console:

… or a Content Security Policy error if you haven’t added your origin url to Connect’s allowed origins:

Add your origin url to Connect following steps here. If you’re loading from an http server locally, you need to add the full url and port, e.g. https://localhost:8080

Allow cookies: if your default browser settings are to block third-party cookies from different origins, this will prevent the app from loading (you’ll get the same X-Frame-Options error which is confusing). Make sure you allow all the cookies from [your-connect-instance-name].awsapps.com – in the screenshot these should all be allowed:

Posted on

http-server with self-signed certs and enabling support in Chrome

To test loading a site locally with http-server you need to generate self-signed certs:

openssl req -newkey rsa:2048 -new -nodes -x509 -days 365 -keyout key.pem -out cert.pem

Now start up http-server using the new cert:

http-server -S -C cert.pem -o .

If you attempt to browse https://localhost:8080 though, Chrome will block self-signed certs by default. To allow self-signed certs, enter in your Chrome address bar:

chrome://flags/#allow-insecure-localhost

And then enable the highlighted setting:

Posted on

Using Serverless Framework to build and deploy Docker images for AWS Lambdas

AWS Lambdas can be packaged and deployed using a Docker image, described in the docs here.

Serverless Framework makes building and deploying a Docker based Lambda incredibly simple. If you have a simplest Dockerfile like this (from the docs here):

FROM public.ecr.aws/lambda/nodejs:14

# Assumes your function is named "app.js", and there is a package.json file in the app directory 
COPY app.js package.json  ${LAMBDA_TASK_ROOT}

# Install NPM dependencies for function
RUN npm install

# Set the CMD to your handler (could also be done as a parameter override outside of the Dockerfile)
CMD [ "app.handler" ]

The handler to be packaged in this image is this simplest hello world function:

exports.handler =  async function(event, context) {
    console.log("EVENT: \n" + JSON.stringify(event, null, 2))
    return "hello!"
  }

To define a Lambda using this image, with Serverless define an ECR section like this to define your image, which will get built using the above Dockerfile in the same folder:

service: lambda-container-1

provider:
  name: aws
  ecr:
    images:
      lambda-container-example:
        path: ./

functions:
  hello:
    image:
      name: lambda-container-example

Run ‘serverless deploy’ and it builds the image, uploads to ECR, and deploys the Lambda all for you.

After deploying, on first test I got this error:

  "errorMessage": "RequestId: 58fe500f-26ee-44ba-b6a9-6079b6ff2896 Error: fork/exec /lambda-entrypoint.sh: exec format error",
  "errorType": "Runtime.InvalidEntrypoint"

The key part of this error is this “exec format error”. I’m building and deploying this from my M1 MacBook Pro, which is Apple’s arm64, not x64.

If we look in the AWS Console for this lambda, on the first page under Image you’ll see the Lambda runtime architecture:

Updating the serverless.yml to include ‘architecture: arm64’, redeploy and now the architecture is arm64:

Invoking with ‘serverless invoke –function hello’ and now it successfully runs!

Proudly powered by WordPress