Terraform и VPC Peering

Question

Итак, мы очень хорошо используем терраформит в нашей организации, и у меня было несколько вопросов о том, как другие делают пиринг VPC. Первоначальное создание соединения достаточно просто. Мы выходим из VPC, который мы только что создали, и ссылаемся на другой VPC, затем заполняем таблицы маршрутов и т. Д. Проблема в том, что VPC мы только что просмотрели. Теперь нам нужно вручную перейти в другой сетевой стек и добавить идентификатор CIDR/PCX вручную в качестве переменных. Я написал сценарий, который немного облегчил нам задачу, но я хотел спросить, динамически ли кто-то выполняет поиск с AWS для любых существующих VPC и автоматически добавляет существующие PCX в таблицу маршрутизации этого VPC.

Пример того, где это было бы ценно, было бы в VPC OPS. У нас есть OPS, а затем dev, prod, qa, stg, uat, cte и т. Д. Поэтому, когда мы создаем CTE vpc, он автоматически создает pcx и связывает его с ops и маршрутами к ops. Однако операционная система не знает об этом новом ПК. Поэтому мы должны добавить его вручную. Я хотел бы, чтобы операционные системы могли выполнять поиск ресурсов самостоятельно и предоставлять свои собственные ресурсы для любых новых VPC/PCX, которые он находит.

TLDR; Способ для двунаправленного VPC-пиринга быть более динамичным

Answer 1

Мы закончили тем, что просто создали сценарий оболочки вокруг этого. Всякий раз, когда мы добавляем новый VPC, мы переходим в каталог OPC OPC и выполняем этот скрипт, и он будет динамически заполнять файл variables.tf всеми необходимыми переменными для настройки пиринговых соединений/маршрутов OPS vpc.

Пример сценария:

#!/bin/bash 
region=$(find . -name "*vars.tf"|cut -d/ -f2|cut -d- -f1-3) 
profile=$(find . -name "*vars.tf" -exec grep 'variable "profile"' {} \; |awk '{print $6}'|tr -d '"') 
account=$(pwd|cut -d/ -f5|cut -d- -f1) 

getData(){ 
    for id in ${ids[@]}; do 
     output=$(aws ec2 describe-vpc-peering-connections --region $region --profile $account --vpc-peering-connection-ids $id) 
     cidr=$(echo "$output"|jq '.VpcPeeringConnections[].RequesterVpcInfo.CidrBlock'|tr -d '"') 
     if [[ $1 == cidr ]]; then 
      echo $cidr 
     elif [[ $1 == id ]]; then 
      echo $id 
     fi 
    done 
} 
checkOps() { 
    pwd|grep 'ops' &>/dev/null 
} 
populateRoutes() { 
    if ! checkOps; then 
     echo "Must be run from the ops directory" 
     exit 1 
    fi 
    ids=($(aws ec2 describe-vpc-peering-connections --region $region --profile $account --filters "Name=status-code,Values=active"|jq '.VpcPeeringConnections[].VpcPeeringConnectionId'|tr -d '"')) 
    if ((${#ids[@]} == 0)); then 
     echo "No update necessary" 
     exit 0 
    fi 

    cidr_list=($(getData cidr)) 
    cidr_format=$(echo "${cidr_list[@]}"|tr ' ' ',') 
    echo $cidr_format 

    id_list=($(getData id)) 
    id_format=$(echo "${id_list[@]}"|tr ' ' ',') 
    echo $id_format 

    if ((${#cidr_list[@]} != ${#id_list[@]})); then 
     echo "CIDR List and ID List do not match" 
     exit 1 
    fi 

    sed -i "/pcx_count/c\variable\ \"pcx_count\"\ \{\ default \=\ \"${#ids[@]}\" \}" ./variables.tf 
    sed -i "/ops_cidrs/c\variable\ \"ops_cidrs\"\ \{\ default\ \=\ \"$cidr_format\"\ \}" ./variables.tf 
    sed -i "/pcx_ids/c\variable\ \"pcx_ids\"\ \{\ default\ \=\ \"$id_format\"\ \}" ./variables.tf 
} 

populateRoutes 

Answer 2

Предполагая, что вы используете remote state backend, вы можете тянуть в стек OPS сети как remote state data source, а затем вносить изменения в свои таблицы маршрутизации от какой бы эфемерной стек вы хотите, чтобы это было возможность маршрутизации.

Постараюсь и сделать минимальный пример (явно не хватает много котельного листового металла):

# my_ops_stack.tf 

provider "aws" { 
    region = "eu-west-1" 
} 

module "ops_stack" { 
    source = "/my/modules/ops_stack" 
    cidr = "10.1.0.0/16" 
    // other vars probably 
} 

// the outputs which will be accessible 
// via the remote state data source: 
output "routing_table_id" { 
    value = "${module.ops_stack.routing_table_id}" 
} 
output "vpc_id" { 
    value = "${module.ops_stack.vpc_id}" 
} 
output "vpc_cidr" { 
    value = "10.1.0.0/16" 
} 

Теперь я буду configure удаленное состояние бэкенд для этого стека, используя терраформировать (CLI this will soon be possible in config):

# Run in the same folder as my_ops_stack.tf 
terraform remote config \ 
    -backend=s3 \ 
    -backend-config="bucket=my-state-bucket" \ 
    -backend-config="key=ops-stack/terraform.tfstate" \ 
    -backend-config="region=eu-west-1" 

Сейчас состояние бэкенд сконфигурированные, любые изменения, относящиеся к пакету будет синхронизироваться с этой серверной:

terraform apply 
# the usual stuff... but now synced with s3! 

Теперь в шаблоне вашей новой эфемерной стеки (Dev, Prod, Qa, СТГ, ЕСХНО, CTE и т.д.):

# my_dev_stack.tf 

provider "aws" { 
    region = "eu-west-1" 
} 

// Pull in your ops stack from the remote backend: 
data "terraform_remote_state" "ops_stack" { 
    backend = "s3" 
    config { 
     bucket = "my-state-bucket" 
     key = "ops-stack/terraform.tfstate" 
     region = "eu-west-1" 
    } 
} 

// Create your dev stack 
module "dev_stack" { 
    source   = "/my/modules/dev_stack" 
    cidr    = "10.2.0.0/16" 
    // The ops_stack vpc id for creating the peering connection: 
    ops_vpc_id  = "${data.terraform_remote_state.ops_stack.vpc_id}" 
    // Maybe some security group rules you wanna setup 
    allow_access_from = "${data.terraform_remote_state.ops_stack.vpc_cidr}" 
    // other vars probably 
} 

// And use its outputs to add a route to the 
// ops vpc routing table from the dev stack! 
resource "aws_route" "ops_to_dev" { 
    route_table_id = "${data.terraform_remote_state.ops_stack.routing_table_id}" 
    destination_cidr_block = "10.2.0.0/16" // dev_stack's cidr 
    vpc_peering_connection_id = "${module.dev_stack.vpcx_id}" 
} 

После того, как вы закончите с эфемерным стеком, вы можете безопасно уничтожить он, и он даже очистит свой маршрут в стеке ops.

Надеюсь, это то, что вы были после!