
Использование Terraform v1.0.11 на Ubuntu 18.04
После terraform apply
выполнения main.tf
приведенного ниже действия и ожидания, пока экземпляр пройдет проверки (а затем еще минуту), попытки подключиться по SSH упираются в стену.
$ 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
Я вручную поднял экземпляр с тем же AMI и парой ключей и могу войти по SSH. Сравнивая настройки сети и безопасности в консоли, я заметил только то, что экземпляр, развернутый вручную, использует VPC по умолчанию, а «Ответить на имя DNS частного ресурса» показывает «IPv4 (A)» для экземпляра, развернутого вручную, и «-» для экземпляра, созданного Terraformed. Оба кажутся безопасными, но я могу ошибаться.
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"
}
Если ничего из перечисленного ниже не вызовет у вас проблем и вы сможете указать мне на работающий пример, это тоже будет признательно.
Решено
Более детальное изучение показало, что таблица маршрутизации маршрутизировала только подсеть, а не 0.0.0.0/0. Добавление следующего решило проблему.
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
}
решение1
Истечение времени ожидания соединения обычно указывает на проблему с сетью. Проверьте:
- Группа безопасности / NACL открыты для вашего IP на порту 22
- VPC имеет интернет-шлюз
- Подсеть имеет маршрут к интернет-шлюзу
- Экземпляр имеет публичный IP-адрес
- Маршрутизация настроена правильно
Это ключевая строка от вашей попытки подключения, которая сообщает вам, что происходит.
ssh: connect to host 18.144.125.224 port 22: Connection timed out