
Usando Terraform v1.0.11 no Ubuntu 18.04
Depois de um terraform apply
tempo main.tf
abaixo e depois de esperar que a instância passe nas verificações (e depois mais um minuto), as tentativas de SSH estão atingindo um muro.
$ ssh -v -i ~/.ssh/toydeploy.pem [email protected]
OpenSSH_7.6p1 Ubuntu-4ubuntu0.5, OpenSSL 1.0.2n 7 Dec 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 18.144.125.224 [18.144.125.224] port 22.
debug1: connect to address 18.144.125.224 port 22: Connection timed out
ssh: connect to host 18.144.125.224 port 22: Connection timed out
Criei uma instância manualmente com a mesma AMI e par de chaves e posso usar SSH. Comparando as configurações de rede e segurança no console, as únicas diferenças que notei são que a instância implantada manualmente está usando o VPC padrão, e "Responder nome DNS do recurso privado" mostra "IPv4 (A)" para a instância implantada manualmente e "-" para a instância Terraformed. Ambos parecem benignos, mas posso estar errado.
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 3.27"
}
}
}
provider "aws" {
profile = "default"
region = "us-west-1"
}
variable "cidr_vpc" {
description = "CIDR block for VPC"
default = "10.1.0.0/16"
}
variable "cidr_subnet" {
description = "CIDR block for subnet"
default = "10.1.0.0/20"
}
resource "aws_vpc" "toydeploy-vpc" {
cidr_block = var.cidr_vpc
enable_dns_hostnames = true
enable_dns_support = true
}
resource "aws_subnet" "toydeploy-subnet" {
vpc_id = aws_vpc.toydeploy-vpc.id
cidr_block = var.cidr_subnet
}
resource "aws_security_group" "toydeploy-sg" {
name = "toydeploy-sg"
vpc_id = aws_vpc.toydeploy-vpc.id
ingress {
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = [
"0.0.0.0/0"
]
}
# Terraform removes the default rule, so we re-add it.
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
}
resource "aws_instance" "toydeploy" {
ami = "ami-083f68207d3376798" # Ubuntu 18.04
instance_type = "t2.micro"
security_groups = ["${aws_security_group.toydeploy-sg.id}"]
subnet_id = aws_subnet.toydeploy-subnet.id
associate_public_ip_address = true
key_name = "toydeploy"
}
Se nada abaixo parecer um problema e você puder me indicar um exemplo prático, isso também seria apreciado.
Resolvido
Um exame mais detalhado mostrou que a tabela de roteamento estava roteando apenas para a sub-rede, e não para 0.0.0.0/0. Adicionar o seguinte resolveu o problema.
resource "aws_internet_gateway" "toydeploy-ig" {
vpc_id = aws_vpc.toydeploy-vpc.id
}
resource "aws_route_table" "toydeploy-rt" {
vpc_id = aws_vpc.toydeploy-vpc.id
route {
cidr_block = "0.0.0.0/0"
gateway_id = aws_internet_gateway.toydeploy-ig.id
}
}
resource "aws_route_table_association" "toydeploy-rta" {
subnet_id = aws_subnet.toydeploy-subnet.id
route_table_id = aws_route_table.toydeploy-rt.id
}
Responder1
O tempo limite de conexão expirou geralmente indica um problema de rede. Verificar:
- Grupo de segurança/NACLs abertos para seu IP na porta 22
- VPC tem gateway de internet
- A sub-rede tem uma rota para o gateway da Internet
- A instância tem um IP público
- O roteamento está configurado corretamente
Esta é a linha principal da sua tentativa de conexão que informa o que está acontecendo
ssh: connect to host 18.144.125.224 port 22: Connection timed out