Updated docs for Consul ECS 0.8.x, architecture, tproxy support (#20473)

* Updated docs for Consul ECS 0.8.x, architecture, tproxy support

* Apply suggestions from code review

Co-authored-by: Jeff Boruszak <104028618+boruszak@users.noreply.github.com>
Co-authored-by: Ganesh S <ganesh.seetharaman@hashicorp.com>

* add apigw as feature, update images

---------

Co-authored-by: Jeff Boruszak <104028618+boruszak@users.noreply.github.com>
Co-authored-by: Ganesh S <ganesh.seetharaman@hashicorp.com>

website/content/docs/ecs/architecture.mdx

@@ -9,28 +9,40 @@ description: >-
 
 This topic provides reference information about the Consul's deployment architecture on AWS ECS. The following diagram shows the main components of the Consul architecture when deployed to an ECS cluster.
 
-![Diagram that provides an overview of the Consul Architecture on ECS](/img/ecs/consul-on-ecs-architecture-dataplanes.jpg#light-theme-only)
-![Diagram that provides an overview of the Consul Architecture on ECS ](/img/ecs/consul-on-ecs-architecture-dataplanes-dark.jpg#dark-theme-only)
+![Diagram that provides an overview of the Consul Architecture on ECS](/img/ecs/consul-on-ecs-architecture-dataplanes.png#light-theme-only)
+![Diagram that provides an overview of the Consul Architecture on ECS ](/img/ecs/consul-on-ecs-architecture-dataplanes-dark.png#dark-theme-only)
 
 ## Components
-Consul starts several components and containers inside the ECS cluster. Refer to [Startup sequence](#startup-sequence) for details about the order of the startup procedure:
 
-### Control-plane container
+Consul starts several components and containers inside the ECS cluster. Using a combination of short-lived containers (`mesh-init`) and long-lived containers (`health-sync`) ensures that any long running containers do not have root access to Consul. Refer to [Startup sequence](#startup-sequence) for details about the order of the startup procedure.
  
-The control-plane container performs the following actions:
+### `mesh-init` container
+
+The `mesh-init` container is a short-lived container that performs the following actions:
 
 - Logs into Consul servers
 - Communicates directly with Consul server
 - Registers proxies and services
 - Creates a bootstrap configuration file for Consul dataplane container and stores it in a shared volume
+- Invokes the `iptables` SDK to configure traffic redirection rules
+
+### `health-sync` container
+
+The `health-sync` container is a long-lived container that performs the following actions:
+
 - Synchronizes ECS health checks
 - Watches the Consul server for changes
 
-### Dataplane containers
+When you stop the ECS task, it performs the following actions:
+
+- Deregisters service and proxy instances on receiving SIGTERM to support graceful shutdown
+- Performs logout from [ACL auth method](/consul/docs/security/acl/auth-methods)
+
+### `dataplane` container
 
 The dataplane process runs in the same container as the Envoy proxy and performs the following actions:
 
-- Consumes and configures itself according to the bootstrap configuration written by the control-plane container.
+- Consumes and configures itself according to the bootstrap configuration written by the `mesh-init` container.
 - Contains and starts up the Envoy sidecar.
 
 ### ECS controller container
@@ -48,13 +60,14 @@ One ECS task in the cluster contains the controller container, which performs th
 
 Deploying Consul to ECS starts the following process to build the architecture:
 
-1. The control-plane container starts and logs into Consul.
-1. The control-plane container registers services and proxies with the Consul servers.
-1. The control-plane container writes the bootstrap configuration for the Consul dataplane process and stores it in a shared volume.
-1. The dataplane container starts and configures itself using the bootstrap configuration generated by the control-plane container. 
-1. The dataplane container starts the Envoy sidecar proxy.
-1. The control-plane container starts listening for ECS health checks.
-1. When the ECS task indicates that the application instance is healthy, the control-plane container marks the service as healthy and starts allowing traffic to flow.
+1. The `mesh-init` container starts and logs in to Consul.
+1. The `mesh-init` container registers services and proxies with the Consul servers.
+1. The `mesh-init` container writes the bootstrap configuration for the Consul dataplane process and stores it in a shared volume.
+1. The `mesh-init` container configures Consul DNS and modifies traffic redirection rules.
+1. The `dataplane` container starts and configures itself using the bootstrap configuration generated by the `mesh-init` container. 
+1. The `dataplane` container starts the Envoy sidecar proxy.
+1. The `health-sync` container starts listening for ECS health checks.
+1. When the ECS task indicates that the application instance is healthy, the `health-sync` container marks the service as healthy and allows traffic to flow.
 
 ## Consul security components
 

website/content/docs/ecs/reference/compatibility.mdx

@@ -11,8 +11,9 @@ For every release of Consul on ECS, the `consul-ecs` binary and `consul-ecs` Ter
 
 ## Supported Consul versions
 
-| Consul Version          | Compatible consul-ecs Version |
+| `consul` version         | Compatible `consul-ecs` version |
 |----------------------- | ----------------------------- |
+| 1.18.x                 | 0.8.x                         |
 | 1.16.x 1.17.x          | 0.7.x                         |
 | 1.15.x, 1.14.x, 1.13.x | 0.6.x                         |
 | 1.14.x, 1.13.x, 1.12.x | 0.5.2+                        |

website/content/docs/ecs/reference/configuration-reference.mdx

@@ -7,20 +7,13 @@ description: >-
 
 # Consul on AWS Elastic Container Service (ECS) Configuration Reference
 
-This topic describes configuration options for the JSON configuration format used
-by the `consul-ecs` binary. This configuration is passed to the `consul-ecs`
-binary as a string using the `CONSUL_ECS_CONFIG_JSON` environment variable.
+This topic describes configuration options for the JSON configuration format used by the `consul-ecs` binary. This configuration is passed to the `consul-ecs` binary as a string using the `CONSUL_ECS_CONFIG_JSON` environment variable.
 
-This configuration format follows a [JSON schema](https://github.com/hashicorp/consul-ecs/blob/main/config/schema.json)
-that can be used for validation.
+This configuration format follows a [JSON schema](https://github.com/hashicorp/consul-ecs/blob/main/config/schema.json) that can be used for validation.
 
-## Terraform Mesh Task Module Configuration
+## Terraform `mesh-task` module configuration
 
-The `mesh-task` Terraform module provides input variables for commonly used fields.
-The following table shows which Terraform input variables correspond to each field
-of the Consul ECS configuration. Refer to the
-[Terraform registry documentation](https://registry.terraform.io/modules/hashicorp/consul-ecs/aws/latest/submodules/mesh-task?tab=inputs)
-for a complete reference of supported input variables for the `mesh-task` module.
+The `mesh-task` Terraform module provides input variables for commonly used fields. The following table shows which Terraform input variables correspond to each field of the Consul ECS configuration. Refer to the [Terraform registry documentation](https://registry.terraform.io/modules/hashicorp/consul-ecs/aws/latest/submodules/mesh-task?tab=inputs) for a complete reference of supported input variables for the `mesh-task` module.
 
 | Terraform Input Variable | Consul ECS Config Field               |
 | ------------------------ | ------------------------------------- |
@@ -32,9 +25,7 @@ for a complete reference of supported input variables for the `mesh-task` module
 | `consul_namespace`       | [`service.namespace`](#service)       |
 | `consul_partition`       | [`service.partition`](#service)       |
 
-Each of these Terraform input variables follow the Consul ECS config schema.
-The remaining fields of the Consul ECS configuration not listed in this table can be passed
-using the `consul_ecs_config` input variable.
+Each of these Terraform input variables follows the Consul ECS configuration schema. The remaining fields of the Consul ECS configuration that are not listed in this table can be passed using the `consul_ecs_config` input variable.
 
 # Top-level fields
 

website/content/docs/ecs/tech-specs.mdx

@@ -11,18 +11,24 @@ This topic describes the supported runtimes and environments for using Consul se
 
 For requirements associated with using the Terraform `mesh-task` module to deploy Consul service mesh, refer [Deploy Consul with the Terraform module](/consul/docs/ecs/deploy/terraform). For requirements associated with manually deploying Consul service mesh to your ECS cluster, refer [Deploy Consul manually](/consul/docs/ecs/deploy/manual). 
 
-## Supported environments and runtimes
+## Supported environments, runtimes, and capabilities
 
-Consul on ECS supports the following environments and runtimes:
+Consul on ECS supports the following environments, runtimes, and capabilities:
 
-- **Launch Types**: Fargate and EC2
-- **Network Modes**: `awsvpc`
-- **Subnets**: Private and public subnets. Tasks must have network access to Amazon ECR or other public container registries to pull images.
-- **Consul servers**: You can use your own Consul servers running on virtual machines or [use HCP Consul to host the servers for you](/hcp/docs/consul/hcp-managed).
-- **ECS controller**: The ECS controller assists with reconciling state back to Consul and facilitates Consul security features.
-- **Admin partitions**: <EnterpriseAlert inline/> Enable ACLs and configure the ECS controller to use admin partitions. You must deploy one controller for each admin partition. 
-- **Namespaces**:  <EnterpriseAlert inline/> Enable ACLs and configure the ECS controller to use namespaces. 
-- **Dataplane containers**: To manage proxies using Consul dataplane, you must use the Terraform `mesh-task` module to install Consul service mesh.
+- **Launch Types:** Fargate and EC2
+- **Network Modes:** `awsvpc`
+- **Subnets:** Private and public subnets. Tasks must have network access to Amazon ECR or other public container registries to pull images.
+- **Consul servers:** You can use your own Consul servers running on virtual machines or [use HCP Consul to host the servers for you](/hcp/docs/consul/hcp-managed).
+- **ECS controller:** The ECS controller assists with reconciling state back to Consul and facilitates Consul security features.
+- **Admin partitions:** <EnterpriseAlert inline/> Enable ACLs and configure the ECS controller to use admin partitions. You must deploy one controller for each admin partition. 
+- **Namespaces:** <EnterpriseAlert inline/> Enable ACLs and configure the ECS controller to use namespaces. 
+- **Dataplane containers:** To manage proxies using Consul dataplane, you must use the Terraform `mesh-task` module to install Consul service mesh.
+- **Transparent proxy:** Consul on ECS 0.8.x supports transparent proxy for ECS on EC2 tasks. Transparent proxy in ECS requires the host to have `NET_ADMIN` capabilities, which ECS Fargate does not currently support. You can enable transparent proxy with the `enable_transparent_proxy` parameter in the `mesh-task` Terraform module or through `ecs_config_json`. The `enable_transparent_proxy` parameter has precedence over `ecs_config_json`.
+
+  Refer to the [`terraform-aws-consul-ecs`](https://github.com/hashicorp/terraform-aws-consul-ecs/tree/main/examples/dev-server-ec2-transparent-proxy) for an example.
+- **API Gateway:** Consul on ECS 0.8.x supports API gateway. Refer to the [`terraform-aws-consul-ecs`](https://github.com/hashicorp/terraform-aws-consul-ecs/tree/main/examples/api-gateway) for an example.
+
+  Refer to the [Consul ECS GitHub repository](https://github.com/hashicorp/terraform-aws-consul-ecs/tree/main/examples/dev-server-ec2-transparent-proxy) for examples of how to use transparent proxy with Consul on ECS.
 
 ## Resource usage