Figure out the correct Cpu and Memory parameters for Fargate containers' ContainerDefinitions and TaskDefinition

[MikeTheCanuck]

In the Fargate container YAMLs there are Cpu and Memory parameters in two sections:

• ContainerDefinitions
• TaskDefinition

Currently these are both configured to the same value. There's a good chance these don't need to be configured to the same values, and that we could save some $$ by using differing values.

Need to understand what these actually control, and determine what appropriate values should be for both our staging and production deploys.

[MikeTheCanuck]

Resolved by https://github.com/hackoregon/hackoregon-aws-infrastructure/pull/81

[MikeTheCanuck]

Summary:

• TaskDefinition controls the total amount of Cpu or Memory that is allocated to each Task in the associated Service
• ContainerDefinition can subdivide those resources in cases where an ECS Task is configured to run more than one container
• for example imagine a Task with three Containers, each of which temporarily uses some additional memory during "bursty" operations - setting Memory at the Task level to 2048, Memory at the Container level to 512, and MemoryReservation at the Container level to 1024 would allow all three Containers to start out with a minimum of 512 MB of memory, and that at any time, any of the containers in that Task could allocate up to another 512 MB (subject to the total 2048 MB allocation at the Task level).

Given that we currently allocate only one Container per Task, setting the same values (using the TaskCpu and TaskMemory variables throughout) at both the Task and Container level is sufficient and completely supported.

When and if we start grouping containers into Tasks (if that's even possible, given the container-level unique configurations we have), we can refactor as necessary.

(Note: grouping Containers into Tasks seems more appropriate when you have complementary containers all contributing to a single coordinated workload - e.g. an API container and a dependent database container, or two microservices that perform coupled operations. It doesn't make as much sense in practice - at least not for the Hack Oregon model - as it might for more highly-coupled, complex container architectures.)