search

hackoregon / civic-devops

Master collection point for issues, procedures, and code to manage the HackOregon Civic platform
MIT License
11 stars 4 forks source link

Get a handle on the per-service Cpu and Memory configurations in Fargate #246

Closed MikeTheCanuck closed 4 years ago

MikeTheCanuck commented 5 years ago

Goal: understand the interaction between the two levels of Cpu & Memory configuration for each Fargate task, then set the one we need -OR- ensure that we have master-level parameters to pass into the CF templates that control each in turn. (Get rid of the apparent conflict if any between 512/1024 and 256/512 configuration)

One of the more puzzling aspects of the Fargate services as I'm experimenting with getting them running is why there are Cpu + TaskCpu and Memory + TaskMemory definitions in the Fargate service template.

I made an initial attempt to consolidate these parameters - thinking that this was merely an artifact of using multiple sources for Fargate template examples, I commented out the TaskDefinition > Properties > Cpu/Memory parameters and left in the TaskDefinition > Properties > ContainerDefinitions > Cpu/Memory parameters.

That deployment failed with the following error:

Fargate requires that 'cpu' be defined at the task level. (Service: AmazonECS; Status Code: 400; Error Code: ClientException; Request ID: e58daca0-9323-49f2-87bb-c8c1db38ae17)

So I'm going to park this optimization for later, since it's already clear that the 256/512 configuration at the ContainerDefinitions level is what gets assigned to each container task anyway, and we at least have a basic ability to scale these as we learn more about them.

Additionally, we should address Michael's comment here: https://github.com/hackoregon/hackoregon-aws-infrastructure/pull/69/files#r298851914

MikeTheCanuck commented 4 years ago

Duplicates #256, and is also resolved by https://github.com/hackoregon/hackoregon-aws-infrastructure/pull/81