Backport of fix typos and update ecs compat table into release/1.16.x (#18220)
* backport of commit 216f79353fe39e9f96b2eba64022ace334bd8887 * backport of commit 1df03269ef0cf336ea28ac65b280416461530765 * backport of commit 12df6a1ac91cb63552a5df2a542f251b60ba3735 --------- Co-authored-by: trujillo-adam <ajosetru@gmail.com> Co-authored-by: trujillo-adam <47586768+trujillo-adam@users.noreply.github.com>
This commit is contained in:
parent
354f1dc6ea
commit
ef4b2e8a05
|
@ -5,19 +5,18 @@ description: >-
|
||||||
The binary for Consul on Amazon Web Services ECS and the Terraform modules for automating deployments are tightly coupled and have specific version requirements. Review compatibility information for versions of Consul and `consul-ecs` to help you choose compatible versions.
|
The binary for Consul on Amazon Web Services ECS and the Terraform modules for automating deployments are tightly coupled and have specific version requirements. Review compatibility information for versions of Consul and `consul-ecs` to help you choose compatible versions.
|
||||||
---
|
---
|
||||||
|
|
||||||
# Consul on AWS Elastic Container Service (ECS) Compatability Matrix
|
# Consul on AWS Elastic Container Service (ECS) compatability matrix
|
||||||
|
|
||||||
For every release of Consul on ECS, the `consul-ecs` binary and `consul-ecs` Terraform module are updated. The versions of the Terraform module and binary are tightly coupled. For example, `consul-ecs` 0.5.2 binary must use the `consul-ecs` 0.5.2 Terraform module.
|
For every release of Consul on ECS, the `consul-ecs` binary and `consul-ecs` Terraform module are updated. The versions of the Terraform module and binary are tightly coupled. For example, `consul-ecs` 0.5.2 binary must use the `consul-ecs` 0.5.2 Terraform module.
|
||||||
|
|
||||||
## Supported Consul versions
|
## Supported Consul versions
|
||||||
|
|
||||||
| Consul Version | Compatible consul-ecs Versions |
|
| Consul Version | Compatible consul-ecs Version |
|
||||||
| -------------- | ------------------------------- |
|
|----------------------- | ----------------------------- |
|
||||||
| 1.14.x | 0.5.2+ |
|
| 1.15.x, 1.14.x, 1.13.x | 0.6.x |
|
||||||
| 1.13.x | 0.5.2+ |
|
| 1.14.x, 1.13.x, 1.12.x | 0.5.2+ |
|
||||||
| 1.12.x | 0.5.x |
|
| 1.11.x | 0.3.0, 0.4.x |
|
||||||
| 1.11.x | 0.3.0, 0.4.x |
|
| 1.10.x | 0.2.x |
|
||||||
| 1.10.x | 0.2.x |
|
|
||||||
|
|
||||||
|
|
||||||
## Supported Envoy versions
|
## Supported Envoy versions
|
||||||
|
|
|
@ -1,11 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Automate Lambda Function Registeration
|
page_title: Automate Lambda function registration
|
||||||
description: >-
|
description: >-
|
||||||
Register AWS Lambda functions with Consul service mesh using the Consul Lambda registrator. The Consul Lambda registrator automates Lambda function registration.
|
Register AWS Lambda functions with Consul service mesh using the Consul Lambda registrator. The Consul Lambda registrator automates Lambda function registration.
|
||||||
---
|
---
|
||||||
|
|
||||||
# Automate Lambda Function Registeration
|
# Automate Lambda function registration
|
||||||
|
|
||||||
This topic describes how to automate Lambda function registration using Consul's Lambda registrator module for Terraform.
|
This topic describes how to automate Lambda function registration using Consul's Lambda registrator module for Terraform.
|
||||||
|
|
||||||
|
|
|
@ -1,14 +1,16 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Run Consul-Terraform-Sync with High Availability
|
page_title: Run Consul-Terraform-Sync with high availability
|
||||||
description: >-
|
description: >-
|
||||||
Improve network automation resiliency by enabling high availability for Consul-Terraform-Sync. HA enables persistent task and event data so that CTS functions as expected during a failover event.
|
Improve network automation resiliency by enabling high availability for Consul-Terraform-Sync. HA enables persistent task and event data so that CTS functions as expected during a failover event.
|
||||||
---
|
---
|
||||||
|
|
||||||
# Run Consul-Terraform-Sync with High Availability
|
# Run Consul-Terraform-Sync with high availability
|
||||||
|
|
||||||
<EnterpriseAlert>
|
<EnterpriseAlert>
|
||||||
Licenses are only required for Consul-Terraform-Sync (CTS) Enterprise
|
An enterpise license is only required for enterprise distributions of Consul-Terraform-Sync (CTS).
|
||||||
</EnterpriseAlert>
|
</EnterpriseAlert>
|
||||||
|
|
||||||
This topic describes how to run Consul-Terraform-Sync (CTS) configured for high availability. High availability is an enterprise capability that ensures that all changes to Consul that occur during a failover transition are processed and that CTS continues to operate as expected.
|
This topic describes how to run Consul-Terraform-Sync (CTS) configured for high availability. High availability is an enterprise capability that ensures that all changes to Consul that occur during a failover transition are processed and that CTS continues to operate as expected.
|
||||||
|
|
||||||
## Introduction
|
## Introduction
|
||||||
|
@ -120,9 +122,9 @@ When high availability is enabled, CTS persists task and event data. Refer to [S
|
||||||
|
|
||||||
You can use the following methods for modifying tasks when high availability is enabled. We recommend choosing a single method to make all task configuration changes because inconsistencies between the state and the configuration can occur when mixing methods.
|
You can use the following methods for modifying tasks when high availability is enabled. We recommend choosing a single method to make all task configuration changes because inconsistencies between the state and the configuration can occur when mixing methods.
|
||||||
|
|
||||||
### Delete and recreate the task (recommended)
|
### Delete and recreate the task
|
||||||
|
|
||||||
Use the CTS API to identify the CTS leader instance as well as delete and replace a task.
|
We recommend deleting and recreating a task if you need to make a modification. Use the CTS API to identify the CTS leader instance and replace a task.
|
||||||
|
|
||||||
1. Identify the leader CTS instance by either making a call to the [`status/cluster` API endpoint](/consul/docs/nia/api/status#cluster-status) or by checking the logs for the following entry:
|
1. Identify the leader CTS instance by either making a call to the [`status/cluster` API endpoint](/consul/docs/nia/api/status#cluster-status) or by checking the logs for the following entry:
|
||||||
|
|
||||||
|
@ -143,7 +145,7 @@ Use the CTS API to identify the CTS leader instance as well as delete and replac
|
||||||
--request POST \
|
--request POST \
|
||||||
--data @payload.json \
|
--data @payload.json \
|
||||||
localhost:8558/v1/tasks
|
localhost:8558/v1/tasks
|
||||||
```
|
```
|
||||||
|
|
||||||
You can also use the [`task-create` command](/consul/docs/nia/cli/task#task-create) to complete this step.
|
You can also use the [`task-create` command](/consul/docs/nia/cli/task#task-create) to complete this step.
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue