Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DockerCon 2021 - Building AWS Lambda functions ...

DockerCon 2021 - Building AWS Lambda functions from container images

You can now build AWS Lambda functions from container images!
Attend this session to learn how it works, see it in action, and find out how you can combine the power of event-driven serverless computing and your existing container image tooling.This session covers one of the most requested new features for AWS Lambda: container image support. With container image support, developers can now package their Lambda functions and required dependencies using familiar container image tooling. You can also build and test your functions using familiar tools and services to analyze their contents and perform audits. Learn about the new developer workflow that is possible with this capability and how to potentially improve your continuous integration and deployment pipelines. Lastly, hear an explanation of container image security and how to share container images inside your organization.

Julian Wood

May 27, 2021
Tweet

More Decks by Julian Wood

Other Decks in Technology

Transcript

  1. Julian Wood Building AWS Lambda functions from container images Senior

    Developer Advocate AWS Serverless @julian_wood
  2. Serverless applications Event source Services (anything) Changes in data state

    Requests to endpoints Changes in Resource state Function Node.js Python Java Go Ruby .Net (C#/Powershell) Custom Runtime API
  3. Anatomy of a Lambda function Handler function Function to be

    executed upon invocation Event object Data sent during Lambda function invocation Context object Methods available to interact with runtime information (request ID, log group, more) CODE EDITOR let response; exports.handler = async (event, context) => { try { response = { 'statusCode': 200, 'body': JSON.stringify({ message: 'hello world’, }) } } catch (err) { console.log(err); return err; } return response };
  4. AWS Lambda container image support Package and deploy functions as

    container images • Why use Lambda • Lambda container image benefits • Working with Lambda container images • Developer workflow • What changes and what stays the same
  5. Why Lambda? Operational support AWS Lambda is the general compute

    option that provides the greatest level of operational support by AWS Designed to simplify high availability, scale and security concerns
  6. AWS manages Customer manages Data source integrations Physical hardware, software,

    networking, and facilities Provisioning Application code Container orchestration, provisioning Cluster scaling Physical hardware, host OS/kernel, networking, and facilities Application code Data source integrations Security config and updates Network config Management tasks Container orchestration control plane Physical hardware software, networking, and facilities Application code Data source integrations Work clusters Security config and updates, network config, firewall, management tasks Physical hardware software, networking, and facilities Application code Data source integrations Scaling Security config and updates Network config Management tasks Provisioning, managing scaling and patching of servers Why Lambda? Operational support AWS Lambda Serverless functions AWS Fargate Serverless containers Amazon ECS/EKS Container management as a service Amazon EC2 Infrastructure as a service Most Least What you manage
  7. AWS Shared Responsibility Model: Managed container services Operating System &

    Network Configuration Customer data Application identity and access management AWS (what we manage) Customer (what you manage) AWS Identity & Access Management Platform Management Code Encryption At Rest Network Traffic Protection Firewall Configuration Data Encryption & Integrity Authentication Application Management Internet Access Monitoring & Logging Compute Storage Database Networking AWS Infrastructure Regions, AZs & Data centers
  8. AWS Shared Responsibility Model: Lambda Compute Storage Database Networking AWS

    Infrastructure Regions, AZs & Data centers Operating System & Network Configuration Customer data Application identity and access management AWS Identity & Access Management Platform Management Code Encryption At Rest Network Traffic Protection Firewall Configuration Data Encryption & Integrity Authentication Application Management Internet Access Monitoring & Logging (Tools provided by platform) AWS (what we manage) Customer (what you manage)
  9. Why Lambda? Application integrations 140+ AWS service integrations • polling

    • queueing • batching • event routing • retries • stream checkpointing • graceful error back-offs Amazon Kinesis AWS AppSync Amazon Simple Notification Service Amazon Simple Queue Service AWS Step Function Amazon EventBridge Amazon DynamoDB Amazon API Gateway Amazon Elastic File System Amazon Simple Storage Service (S3) Amazon CloudFront Amazon CloudWatch Amazon MQ Amazon RDS
  10. Why Lambda? Automatic scaling • Burst capacity of up to

    3,000 in select Regions ◦ (us-west-2, us-east-1, eu-west-1) • Enables scaling from 0 to 3,000 concurrent executions in seconds • After the initial burst, functions concurrency can scale by an additional 500 instances each minute • Provisioned Concurrency available for highly consistent function executions
  11. Why Lambda? Cost considerations • Only pay for use, never

    pay for idle resources by default • Scales to zero • Precise cost measurements: 1 ms billing • Allocate memory for cost/performance • No need to pay for patching and maintenance
  12. Benefit: Agility Flexibility and familiarity of container tooling (Docker, CI

    / CD, security, governance) Plus operational simplicity of AWS Lambda Equals more agility when building applications
  13. Benefit: Dependency management • Manage all dependencies as immutable artifact

    • Add dependences in Dockerfile • Install native operating system packages • Install language-compatible dependencies
  14. Benefit: Familiar container tooling • Use the same build and

    pipeline tools to deploy • Use the same container registry to store application artifacts (Amazon ECR, Docker Hub) • Tools that can inspect Dockerfiles work the same
  15. Benefit: Larger Lambda functions Developers can now configure Lambda functions

    for: 10 GB deployment package max 10 GB in memory with up to 6 vCPUs proportional to memory configuration Build compute-intensive workloads: • Machine learning, genomics, gaming, HPC applications Build memory-intensive workloads: • Batch, ETL, analytics, media processing Configured memory (MB) Allocated cores 128 – 1769 1 1770 – 3538 2 3539 – 5307 3 5308 – 7076 4 7077 – 8845 5 8846 – 10240 6
  16. Benefit: Immutability • Lambda treats container images as immutability entities

    • When invoked, functions deployed as container images are run without modification • Invoked functions are immutable across environments: • Desktop, CI / CD • Elastic Container Registry • Lambda execution environment OS and runtime patching no longer performed by AWS Any image change requires a separate redeployment step
  17. Benefit: Flexibility ◦ Use your preferred base image to deploy

    Lambda-based applications. ◦ Simplifies running images on additional compute services. ◦ (Runtime Interface Emulator)
  18. Amazon ECS AWS Fargate Amazon EKS On-premises Hybrid cloud Benefit:

    Portability AWS Lambda Lambda container image
  19. Container image format & distros Lambda supports container images that

    have manifest files following these formats: • Docker image manifest V2, schema 2 (used with Docker version 1.10 and newer) • Open Container Initiative (OCI) Specifications (v1.0.0 and up) Can use non-Amazon Linux distributions such as Alpine or Debian Images can be up to 10 GB More here: https://docs.aws.amazon.com/lambda/latest/dg/images-create.html
  20. Container image registry Container images are stored in Amazon Elastic

    Container Registry (ECR) • Fully managed container registry • Required for deploying Lambda functions • Public and private repositories • Cross-account sharing controls • Can replicate images across Regions • Encryption at rest and in transport to Lambda • Integrated vulnerability scanning Amazon Elastic Container Registry
  21. Base images AWS provided Lambda base images for every managed

    runtime • Patched and maintained by AWS • Images available from both Docker Hub and Amazon ECR Public Bring your own base image • Linux kernels supported Multi-stage builds • Node.js • Python • Java • Provided.al2 • .Net • Ruby • Go (Runtime API) CODE EDITOR $ cat Dockerfile FROM public.ecr.aws/lambda/nodejs:12 COPY app.js package*.json ./ RUN npm install CMD [ "app.lambdaHandler" ]
  22. Dockerfile for Lambda functions Use the Node.js v12 base image

    from Amazon ECR Public Copy the application files to the image Run the npm command to install dependencies in the image When the container runs, use my application’s handler CODE EDITOR FROM public.ecr.aws/lambda/nodejs:12 COPY app.js package*.json ./ RUN npm install CMD [ "app.lambdaHandler" ] The container image includes your function and becomes the entire filesystem
  23. Dockerfile for Lambda functions Lambda supports the following container image

    settings in the Dockerfile: • ENTRYPOINT – Specifies the absolute path to the entry point of the application. • CMD – Specifies parameters that you want to pass in with ENTRYPOINT. • WORKDIR – Specifies the absolute path to the working directory. • ENV – Specifies an environment variable for the Lambda function. Lambda ignores the values of any unsupported container image settings in the Dockerfile.
  24. Intoducing the RIC and the RIE There are two extra

    components we’ve released as part of container image support: • AWS Lambda Runtime Interface Client(s) (RIC) • Allows container-based function code to interact with Lambda Runtime API • AWS has released these for each managed runtime • Open-sourced (for example: https://github.com/aws/aws-lambda-nodejs-runtime-interface-client) • AWS Lambda Runtime Interface Emulator (RIE) • Mimics the Runtime API locally for testing purposes • Exposes an HTTP interface that converts requests to JSON for the RIC • Also open-sourced: https://github.com/aws/aws-lambda-runtime-interface-emulator/
  25. Developer workflow: Build and local test docker build / sam

    build Container image 1. Add base layer image 2. Copy function code 3. Install dependencies Local testing (with RIE) • docker run • sam local invoke Lambda function local test Code Dockerfile Container image
  26. Developer workflow: Deploy and run Amazon Elastic Container Registry Container

    image 1. Tag image 2. Upload image to registry Invoke Status: ACTIVE Ready for invoke Lambda function 1. Pull image from Amazon ECR 2. Optimize image 3. Deploy image to Lambda CreateFunction Container image Status: PENDING AWS Lambda docker tag docker push Container image
  27. Developer workflow: Deploy and run Amazon Elastic Container Registry Container

    image 1. Tag image 2. Upload image to registry Invoke Status: ACTIVE Ready for invoke Lambda function 1. Pull image from Amazon ECR 2. Optimize image 3. Deploy image to Lambda CreateFunction Container image Status: PENDING AWS Lambda docker tag docker push On create / update Lambda caches the image in the service to speed up cold start of functions during execution or for provisioned concurrency spin-up Container image
  28. Developer workflow: Deploy and run Amazon Elastic Container Registry Container

    image 1. Tag image 2. Upload image to registry Invoke Status: ACTIVE Ready for invoke Lambda function 1. Pull image from Amazon ECR 2. Optimize image 3. Deploy image to Lambda CreateFunction Container image Status: PENDING AWS Lambda docker tag docker push sam deploy AWS SAM packages the container, pushes it to a repo, and creates or updates the Lambda function with a single command Container image
  29. What changes and what stays the same? What changes? •

    Larger function size • Use preferred base image (Requires RIC to talk to Runtime API) • No auto-updates without a redeploy (immutable) What stays the same? • Operational models • Invoke model • Performance • Storage options • Logging / metrics / tracing • Other service limits • Pricing
  30. What’s the same? Performance Memory and CPU configurations match zip

    archive functions Performance varies based on image size, composition, runtimes and dependencies Cold start times targeted to be same as zip archive (small % of production traffic) Container images are proactively cached near to where the function runs for faster start-up
  31. What’s the same? Pricing Now 1 ms billing granularity, reduced

    from 100 ms. No additional changes to any Lambda pricing calculations or dimension. You do pay for the ECR repository.
  32. What’s the same? Operational Models • Automatic scaling characteristics •

    High availability (multi-AZ deployments) • Security and isolation
  33. Lambda function isolation • AWS Lambda runs your functions on

    Lambda Workers which are EC2 Nitro instances • Execution environments isolated from each other using hardware-virtualized MicroVMs • Execution environments are never reused across different function versions or customers • In-memory & disk state is not accessible or shared across execution environments • Writeable /tmp directory is backed by an EC2 instance store and is encrypted at-rest Firecracker Virtual Machine Monitor MicroVM Execution Environment MicroVM Execution Environment MicroVM Execution Environment MicroVM Execution Environment Bare metal EC2 Nitro instance AWS owned VPC
  34. Storage in Lambda Lambda function Memory (128 MB – 10240

    MB) /tmp space (512 MB) Deployment package (10 GB for container images) Amazon S3 bucket Amazon EFS file system internal storage external storage
  35. Summary Container image support can simplify the way you build

    Lambda-based applications: • Unified tooling with container-based workloads • Easier dependency management • Larger application artifacts Same benefits of Lambda as a compute service and simplified developer experience with AWS SAM Much more here: s12d.com/lambda-containers