Open danielhstahl opened 3 years ago
Anyone with a workaround for this one?
My "workaround" was to create a lambda docker that I maintain separately from Amplify.
+1000 for this. We were very excited to find Amplify support for FarGate, because we have run into Run Time limitations with Lambdas for some long-running workloads like import jobs and big data processing.
Initially, FarGate seemed like the perfect solution, but for some reason Amplify CLI will not accept custom CloudFormations settings such as Memory and Environment variables. It just overwrites them on every push.
The same problem here, not being able to modify cloudformation template for containers. Make sense to have this option since this functionality is available for lamdas.
This is a very needed functionality. The default values are not sufficient for our fargate use case.
@josefaidt any idea if this will be worked on by the amplify team?
Hey @kylekirkby :wave: apologies for the delay, and while I do not have a clear timeline for this feature I will bump this with the team 🙂
@josefaidt no worries and thanks for the reply! That sounds great! Really appreciate it 😃
+1000 for this. We were very excited to find Amplify support for FarGate, because we have run into Run Time limitations with Lambdas for some long-running workloads like import jobs and big data processing.
Initially, FarGate seemed like the perfect solution, but for some reason Amplify CLI will not accept custom CloudFormations settings such as Memory and Environment variables. It just overwrites them on every push.
You can set environment variables is the backend-config.json (took me a while to figure it out). You can pass them In the environmentMap of the fargate resource
Anybody figured out a workaround? The 1GB limitation really makes these serverless containers extremely limited.
There was a version of the amplify
cli that would respect values for cpu
and memory
that were added to the environmentMap
property of backend-config.json
:
{
"hosting": {
"ElasticContainer": {
"resourceName": "site",
"service": "ElasticContainer",
"providerPlugin": "awscloudformation",
"domain": ...,
...
],
"environmentMap": {
"cpu": "1024",
"memory": "4096"
},
...
... but when I do amplify push
or amplify publish
with the latest version, this no longer has any effect and any manual changes to amplify/backend/hosting/ElasticContainer/container-template.json
get overridden, as described by the OP.
Are there any updates on this? The memory limitation renders Amplify's serverless containers useless for most applications. Is there anything we can do to help move this along?
Does any one know the last version of the amplify cli that actually respected local changes to container-template.json
?
Any updates on this? We need bigger tasks! I think the issue is caused here. where always the same values are used: https://github.com/aws-amplify/amplify-category-api/blame/ea99daa9e492291138a7eaa7aa8a9a91db8ea426/packages/amplify-category-api/src/provider-utils/awscloudformation/base-api-stack.ts#L285
Is this feature request related to a new or existing Amplify category?
api
Is this related to another service?
Fargate/ECR
Describe the feature you'd like to request
When using serverless containers, the cloud formation defaults to 512 vCPU and 1024 Memory.
If I manually update this to a larger number, amplify overwrites the configuration with the default 512 and 1024.
Describe the solution you'd like
The ability to customize the cloud formation or have an option for sizing within the
api add
cli.Describe alternatives you've considered
Manually configuring the cloud formation template. I've also manually updated the size in the AWS console.
Additional context
No response
Is this something that you'd be interested in working on?