By using AWS re:Post, you agree to the Terms of Use
/Serverless/

Serverless

Serverless is a way to describe the services, practices, and strategies that enable you to build more agile applications so you can innovate and respond to change faster. With serverless computing, infrastructure management tasks like capacity provisioning and patching are handled by AWS, so you can focus on only writing code that serves your customers.

Recent questions

see all
1/18

How to ensure using the latest lambda layer version when deploying with CloudFormation and SAM?

Hi, we use CloudFormation and SAM to deploy our Lambda (Node.js) functions. All our Lambda functions has a layer set through `Globals`. When we make breaking changes in the layer code we get errors during deployment because new Lambda functions are rolled out to production with old layer and after a few seconds *(~40 seconds in our case)* it starts using the new layer. For example, let's say we add a new class to the layer and we import it in the function code then we get an error that says `NewClass is not found` for a few seconds during deployment *(this happens because new function code still uses old layer which doesn't have `NewClass`)*. Is it possible to ensure new lambda function is always rolled out with the latest layer version? Example CloudFormation template.yaml: ``` Globals: Function: Runtime: nodejs14.x Layers: - !Ref CoreLayer Resources: CoreLayer: Type: AWS::Serverless::LayerVersion Properties: LayerName: core-layer ContentUri: packages/coreLayer/dist CompatibleRuntimes: - nodejs14.x Metadata: BuildMethod: nodejs14.x ExampleFunction: Type: AWS::Serverless::Function Properties: FunctionName: example-function CodeUri: packages/exampleFunction/dist ``` SAM build: `sam build --base-dir . --template ./template.yaml` SAM package: `sam package --s3-bucket example-lambda --output-template-file ./cf.yaml` Example CloudFormation deployment events, as you can see new layer (`CoreLayer123abc456`) is created before updating the Lambda function so it should be available to use in the new function code but for some reasons Lambda is updated and deployed with the old layer version for a few seconds: | Timestamp | Logical ID | Status | Status reason | | --- | --- | --- | --- | 2022-05-23 16:26:54 | stack-name | UPDATE_COMPLETE | - 2022-05-23 16:26:54 | CoreLayer789def456 | DELETE_SKIPPED | - 2022-05-23 16:26:53 | v3uat-farthing | UPDATE_COMPLETE_CLEANUP_IN_PROGRESS | - 2022-05-23 16:26:44 | ExampleFunction | UPDATE_COMPLETE | - 2022-05-23 16:25:58 | ExampleFunction | UPDATE_IN_PROGRESS | - 2022-05-23 16:25:53 | CoreLayer123abc456 | CREATE_COMPLETE | - 2022-05-23 16:25:53 | CoreLayer123abc456 | CREATE_IN_PROGRESS | Resource creation Initiated 2022-05-23 16:25:50 | CoreLayer123abc456 | CREATE_IN_PROGRESS | - 2022-05-23 16:25:41 | stack-name | UPDATE_IN_PROGRESS | User Initiated
1
answers
0
votes
13
views
asked 6 hours ago

Amazon Linux 2 on Beanstalk isn't installing SQSD and prevents cron.yml from working

We're on solution stack "64bit Amazon Linux 2 v3.3.13 running PHP 7.4" the worker server is spinning up, unpacking the "platform-engine.zip" and when it comes to setting up SQSD: ``` May 23 12:45:01 ip-172-31-12-195 su: (to sqsd) root on none May 23 12:45:10 ip-172-31-12-195 aws-sqsd-monitor: restarting aws-sqsd... May 23 12:45:10 ip-172-31-12-195 systemd: Starting (null)... May 23 12:45:10 ip-172-31-12-195 su: (to sqsd) root on none May 23 12:45:10 ip-172-31-12-195 systemd: Created slice User Slice of sqsd. May 23 12:45:10 ip-172-31-12-195 systemd: Started Session c2 of user sqsd. May 23 12:45:10 ip-172-31-12-195 aws-sqsd: Version 2 of the Ruby SDK will enter maintenance mode as of November 20, 2020. To continue receiving service updates and new features, please upgrade to Version 3. More information can be found here: https://aws.amazon.com/blogs/developer/deprecation-schedule-for-aws-sdk-for-ruby-v2/ May 23 12:45:13 ip-172-31-12-195 aws-sqsd: Cannot load config file. No such file or directory: "/etc/aws-sqsd.d/default.yaml" - (AWS::EB::SQSD::FatalError) May 23 12:45:13 ip-172-31-12-195 systemd: aws-sqsd.service: control process exited, code=exited status=1 May 23 12:45:13 ip-172-31-12-195 systemd: Failed to start (null). May 23 12:45:13 ip-172-31-12-195 systemd: Unit aws-sqsd.service entered failed state. May 23 12:45:13 ip-172-31-12-195 systemd: aws-sqsd.service failed. May 23 12:45:13 ip-172-31-12-195 systemd: Removed slice User Slice of sqsd. ``` I can't find anything online about this, so some help would be greatly appreciated.
0
answers
0
votes
16
views
asked a day ago

Containers/services unable to communicate between them

I have created an ECS cluster that runs one service on Fargate with one task definition. The task definition runs two containers that are supposed to communicate with each other: - nginx (using `fastcgi_pass <hostname>:9000;`) - php-fpm I have tried running them in one task definition or in seperate services (with Service Discovery set with either A records or SRV records - I have tried all the options). Other info: - Public VPC with two public subnets - Security group that allows access from itself to port 9000 (the php-fpm port) - Load balancer connected to the nginx container on port 80 Here is one of the task definitions that I tried, in this case running the containers in the same task definition (nginx has `fastcgi_pass localhost:9000;`). I hope somebody can help me... It can't be this hard to do something so simple. Nothing seems to work. ``` { "ipcMode": null, "executionRoleArn": "arn:aws:iam::359816492978:role/ecsTaskExecutionRole", "containerDefinitions": [ { "dnsSearchDomains": null, "environmentFiles": null, "logConfiguration": { "logDriver": "awslogs", "secretOptions": null, "options": { "awslogs-group": "/ecs/v1-stage", "awslogs-region": "us-east-1", "awslogs-stream-prefix": "ecs" } }, "entryPoint": null, "portMappings": [ { "hostPort": 80, "protocol": "tcp", "containerPort": 80 } ], "command": null, "linuxParameters": null, "cpu": 0, "environment": [], "resourceRequirements": null, "ulimits": null, "dnsServers": null, "mountPoints": [], "workingDirectory": null, "secrets": null, "dockerSecurityOptions": null, "memory": null, "memoryReservation": null, "volumesFrom": [], "stopTimeout": null, "image": "359816492978.dkr.ecr.us-east-1.amazonaws.com/nginx", "startTimeout": null, "firelensConfiguration": null, "dependsOn": null, "disableNetworking": null, "interactive": null, "healthCheck": null, "essential": true, "links": [], "hostname": null, "extraHosts": null, "pseudoTerminal": null, "user": null, "readonlyRootFilesystem": null, "dockerLabels": null, "systemControls": null, "privileged": null, "name": "nginx" }, { "dnsSearchDomains": null, "environmentFiles": null, "logConfiguration": { "logDriver": "awslogs", "secretOptions": null, "options": { "awslogs-group": "/ecs/v1-stage", "awslogs-region": "us-east-1", "awslogs-stream-prefix": "ecs" } }, "entryPoint": null, "portMappings": [ { "hostPort": 9000, "protocol": "tcp", "containerPort": 9000 } ], "command": null, "linuxParameters": null, "cpu": 0, "environment": [], "resourceRequirements": null, "ulimits": null, "dnsServers": null, "mountPoints": [], "workingDirectory": null, "secrets": null, "dockerSecurityOptions": null, "memory": null, "memoryReservation": null, "volumesFrom": [], "stopTimeout": null, "image": "359816492978.dkr.ecr.us-east-1.amazonaws.com/php", "startTimeout": null, "firelensConfiguration": null, "dependsOn": null, "disableNetworking": null, "interactive": null, "healthCheck": null, "essential": true, "links": [], "hostname": null, "extraHosts": null, "pseudoTerminal": null, "user": null, "readonlyRootFilesystem": null, "dockerLabels": null, "systemControls": null, "privileged": null, "name": "php" } ], "placementConstraints": [], "memory": "1024", "taskRoleArn": "arn:aws:iam::359816492978:role/ecsTaskExecutionRole", "compatibilities": [ "EC2", "FARGATE" ], "taskDefinitionArn": "arn:aws:ecs:us-east-1:359816492978:task-definition/v1-stage:5", "family": "v1-stage", "requiresAttributes": [ { "targetId": null, "targetType": null, "value": null, "name": "com.amazonaws.ecs.capability.logging-driver.awslogs" }, { "targetId": null, "targetType": null, "value": null, "name": "ecs.capability.execution-role-awslogs" }, { "targetId": null, "targetType": null, "value": null, "name": "com.amazonaws.ecs.capability.ecr-auth" }, { "targetId": null, "targetType": null, "value": null, "name": "com.amazonaws.ecs.capability.docker-remote-api.1.19" }, { "targetId": null, "targetType": null, "value": null, "name": "com.amazonaws.ecs.capability.task-iam-role" }, { "targetId": null, "targetType": null, "value": null, "name": "ecs.capability.execution-role-ecr-pull" }, { "targetId": null, "targetType": null, "value": null, "name": "com.amazonaws.ecs.capability.docker-remote-api.1.18" }, { "targetId": null, "targetType": null, "value": null, "name": "ecs.capability.task-eni" } ], "pidMode": null, "requiresCompatibilities": [ "FARGATE" ], "networkMode": "awsvpc", "runtimePlatform": { "operatingSystemFamily": "LINUX", "cpuArchitecture": null }, "cpu": "512", "revision": 5, "status": "ACTIVE", "inferenceAccelerators": null, "proxyConfiguration": null, "volumes": [] } ```
1
answers
0
votes
8
views
asked 2 days ago

Popular users

see all
1/18

Learn AWS faster by following popular topics

1/5