vpc

T101-Study-4Week

가시다님과 스터디를 한지도 5번째 이번엔 테라폼이다.

오늘 블로그를 쓰게된건 중간과제를 설명하기 위해서다.

바로 본론으로 들어간다. 내 GIT 이다

https://github.com/Cloud-Linuxer/T101/tree/main/4week

variable "availability_zone" {
        description = "Seoul region availability zone"
        type = list
        default = ["ap-northeast-2a", "ap-northeast-2b", "ap-northeast-2c", "ap-northeast-2d"]
}

variable "subnet_numbers" {
  type    = list
  default = [10, 20, 30, 40]
}
variable "az_count" {
  type    = list
  default = ["A", "B", "C", "D"]
}

나의 Variables는 이런식으로 구성되어있다. 모든 타입을 List로 선언하여 사용한다. 5주차에 할 테라폼 의 반복문을 사용하기 위한 형태다. 가장 중요한 부분은 subnet_numbers 부분이다. 10, 20, 30, 40 이 핵심이다.

resource "aws_subnet" "pub-common" {
        count = "${length(var.availability_zone)}"
        vpc_id = "${aws_vpc.default.id}"
        cidr_block = [
                for num in var.subnet_numbers:
                cidrsubnet(aws_vpc.default.cidr_block, 8, num)
                ][count.index]
        availability_zone = "${element(var.availability_zone, count.index)}"
        tags = {
                Name = "Linuxer-Dev-Pub-Common-${element(var.az_count, count.index)}"
        }
}

이 코드만 봐서는 이게 무엇을 뜻하는지 한눈에 보기 어렵다. 그럼 하나씩 설명하겠다. 하시코프에서는 cidrsubnet 이라는 Function 을 지원한다. 이 함수를 통해서 나는 /16비트의 서브넷을 24비트로 자를거다.

간단히 보여주자면 이렇다

terraform console
> cidrsubnet("10.0.0.0/16",8,10)
"10.0.10.0/24"
> cidrsubnet("10.0.0.0/16",8,20)
"10.0.20.0/24"
> cidrsubnet("10.0.0.0/16",8,30)
"10.0.30.0/24"
> cidrsubnet("10.0.0.0/16",8,40)
"10.0.40.0/24"

for로 list 에 담긴 subnet_numbers를 가져다가 CIDR 을 반환한다. 위처럼 24비트의 4개 서브넷이다.
위와같이 24비트로 나뉜 4개의 서브넷을 테라폼은 생성한다.
위의 리소스선언 한줄로 Subnet 4개를 생성하는 것이다.

서울 리전의 4개 AZ를 모두 사용하고, A zone은 10대역대 B Zone은 20대역대 C Zone은 30대역 D Zone은 40 대역인것이다.

이렇게 사용하면 장점이 있다. 한개의 존이 문제가 생긴것을 파악하기 쉽고, 아이피 대역대 만으로 서비스의 역할을 파악할수 있는 장점이 있는 것이다.

처음엔 리스트로 서브넷 선언도 모두 입력해서 하나의 리소스 선언으로 모든 서브넷을 생성하려했지만 그렇게 사용할 경우 리스트가 변경되면 모든 서브넷이 영향을 받는 이슈가 있어서 각 서브넷별 리소스 선언을 하는 방향으로 수정했다.

NCP-VPC-Update

드디어 NCP 에도 VPC가 업데이트 되었습니다.

VPC 모드로 전환하면 파란색으로 인터페이스가 전환됩니다.

금융존은 주황색

TMI는 여기 까지고 VPC를 생성해 보겠습니다.

아직 none-rfc-1918은 지원하지 않습니다. 다른 벤더에서도 rfc1918을 쓰는것을 권장하지만, none-rfc-1918의 필요성이 가끔 있으므로 차차 업데이트 되지 않을까 생각됩니다.

VPC 이름에는 대문자를 사용할 수 없습니다.

생성할떄 public / privite 으로 지정해서 만들게 됩니다. 인스턴스를 생성할때 public 으로 생성하면 인스턴스 용도로만 사용할수있고, private 으로 생성하면 로드벨런서 용도와 일반용도를 나누어서 생성할수 있습니다.

AWS 에서 계층화 된 서브넷의 구성에서 자유도를 빼놓은 구성같습니다.

사용자가 선택할수 있는 pub/pri 구분은 서브넷을 생성할 때 만 결정할 수 있는 것 입니다.

라우팅 테이블의 메뉴가 있긴 하나, 이 라우팅 테이블은 서브넷간 통신과 VPN 통신등을 컨트롤하는거고 public / privite 은 한번 설정하면 수정할 수 없습니다.

일단 VPC 와 Subnet을 생성했으니, 한번 classic 모드와 VPC 모드 전환시도를 간단하게 진행해 보겠습니다.

classic 모드에서 인스턴스를 생성하고, 이생성한 인스턴스를 이미지로 만든후 vpc에서 이미지로 인스턴스를 생성해보겠습니다.

생성된 서버이미지를 이제 VPC 모드에서 보겠습니다.

안보입니다.

여긴어디 나는누구........그럼 어쩌지...vpc mode 로 전환 어쩌지..

짤봇!

아직 전환할수 있는 지원은 안나온거 같고..서로 풀을 공유하지 않는것으로 보입니다.

이후 3월 4일 패치내용입니다.

서버이미지 공유와 Classic 에서 VPC로 이미지 복제기능이 런칭되었습니다.

아주 칭찬해!

옮길수있는 이미지리스트는 정해져있지만 아주 수월하게 이동이 가능합니다.

https://manvscloud.com/?p=516

manvscloud 님의 블로그를 링크하며 글을 마칩니다.

AWS-VPC-rfc1918

요즘 ANS 공부를 하고 있다. 그러던 와중에 알게된 부분이다.

AWS에선 VPC 를 생성할때 RFC1918을 권장한다.

10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

이 대역이다. 그러던중 IPv4 블록 연결제한 부분을 보게되었다.

https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/VPC_Subnets.html#VPC_Sizing

IPv4 CIDR 블록 연결 제한
기본 VPC CIDR 블록이 상주하는 IP 주소 범위제한되는 CIDR 블록 연결허용되는 CIDR 블록 연결
10.0.0.0/8다른 RFC 1918* 범위(172.16.0.0/12 및 192.168.0.0/16)의 CIDR 블록입니다.기본 CIDR이 10.0.0.0/15 범위에 해당되면 10.0.0.0/16 범위의 CIDR 블록을 추가할 수 없습니다.198.19.0.0/16 범위의 CIDR 블록입니다.제한되지 않는 10.0.0.0/8 r범위의 기타 모든 CIDR입니다.공개적으로 라우팅이 가능한 모든 IPv4 CIDR 블록(비-RFC 1918) 또는 100.64.0.0/10 범위의 CIDR 블록.
172.16.0.0/12다른 RFC 1918* 범위(10.0.0.0/8 및 192.168.0.0/16)의 CIDR 블록입니다.172.31.0.0/16 범위의 CIDR 블록입니다.198.19.0.0/16 범위의 CIDR 블록입니다.제한되지 않는 172.16.0.0/12 r범위의 기타 모든 CIDR입니다.공개적으로 라우팅이 가능한 모든 IPv4 CIDR 블록(비-RFC 1918) 또는 100.64.0.0/10 범위의 CIDR 블록.
192.168.0.0/16다른 RFC 1918* 범위(172.16.0.0/12 및 10.0.0.0/8)의 CIDR 블록입니다.198.19.0.0/16 범위의 CIDR 블록입니다.192.168.0.0/16 범위의 기타 모든 CIDR입니다.공개적으로 라우팅이 가능한 모든 IPv4 CIDR 블록(비-RFC 1918) 또는 100.64.0.0/10 범위의 CIDR 블록.
198.19.0.0/16RFC 1918* 범위의 CIDR 블록입니다.공개적으로 라우팅이 가능한 모든 IPv4 CIDR 블록(비-RFC 1918) 또는 100.64.0.0/10 범위의 CIDR 블록.
공개적으로 라우팅이 가능한 CIDR 블록(비-RFC 1918) 또는 100.64.0.0/10 범위의 CIDR 블록.RFC 1918* 범위의 CIDR 블록입니다.198.19.0.0/16 범위의 CIDR 블록입니다.공개적으로 라우팅이 가능한 모든 다른 IPv4 CIDR 블록(비-RFC 1918) 또는 100.64.0.0/10 범위의 CIDR 블록.

간단히 정리하면 해당 RFC1918중 하나의 대역을 사용하면 다른 대역을 사용할수 없는것이다.

예로..

이런식이다..

왜이렇게 AWS에서는 RFC1918에 대한 제한을 두었는지는 알수없다.

non-RFC1918 은또 사용할수 있기 때문이다.

추측을 하자면 어제 조언을해주신..여러분들의 의견을 종합해보자면..

관리상의 측면때문일거라 생각은 드는데..

결론은 나지 않았다.

간단하게 정리한 스샷..

긴밤에 같이 고민해 주신 김용대님 신승광님 서노아님께 감사를 드립니다!

읽어주셔서 감사하다!

AWS-GCP-Azure-network-none-rfc1918

VPC를 생성하는 경우, 다음과 같이 /16RFC 1918:규격에 따라 프라이빗(비공개적으로 라우팅 가능) IPv4 주소 범위에 속하는 CIDR 블록( 또는 이하)을 지정하는 것이 좋습니다.

-_-;공인IP를 쓸수있는건 아니지만 걍 아무대역 가져다 써도 VPC는 생성 가능하다.

갑자기 궁금해져서 퍼블릭클라우드는 비RFC1918을 지원하는지 모두 테스트 해보았고 모두 지원한다~

DOCS에서 명확하게 적혀있는것은 AWS 뿐이었다.

Azure

VNet 내에서 사용할 수 있는 주소 범위는 무엇입니까?

RFC 1918에 정의되어 있는 모든 IP 주소 범위를 사용할 수 있습니다. 예를 들어 10.0.0.0/16을 사용할 수 있습니다. 다음 주소 범위는 추가할 수 없습니다.

  • 224.0.0.0/4(멀티캐스트)
  • 255.255.255.255/32(브로드캐스트)
  • 127.0.0.0/8(루프백)
  • 169.254.0.0/16(링크-로컬)
  • 168.63.129.16/32(내부 DNS)

GCP

서브넷 및 IP 범위

서브넷을 만들 때 기본 IP 주소 범위를 정의해야 합니다. 선택사항으로 보조 IP 주소 범위를 정의할 수 있습니다.

  • 기본 IP 주소 범위: 서브넷의 기본 IP 주소 범위에 대한 비공개 RFC 1918 CIDR 블록을 선택할 수 있습니다. 이러한 IP 주소는 VM 기본 내부 IP 주소, VM 별칭 IP 주소, 내부 부하 분산기의 IP 주소에 사용할 수 있습니다.

뭐야.. 애매하잖아 다되는데

gcp-terrafrom-2 with VPC create

이전 포스팅에서 cloud shell 을 이용해서 terraform 을 사용하는 방법을 포스팅 했다.

이번에는 VPC 를 생성하는 방법을 포스팅 하기로 하였다.

https://www.terraform.io/docs/providers/google/r/compute_subnetwork.html

다음 docs 를 참고하였다.

resource name -실제 vpc name -에 대문자가 들어가면
Error: Error creating Network: googleapi: Error 400: Invalid value for field 'resource.name'
에러가 발생한다 참고하자.

이걸 몰라서 한참..테스트를 했다.

main.tf

resource "google_compute_subnetwork" "us-central1-subnet" {
name = "${local.name_suffix}-us-central1-subnet"
ip_cidr_range = "10.2.0.0/16"
region = "us-central1"
network = google_compute_network.linuxer-VPC.self_link
}
resource "google_compute_subnetwork" "europe-west1-subnet" {
name = "${local.name_suffix}-europe-west1-subnet"
ip_cidr_range = "10.3.0.0/16"
region = "europe-west1"
network = google_compute_network.linuxer-VPC.self_link
}
resource "google_compute_network" "linuxer-VPC" {
name = "${local.name_suffix}-vpc"
auto_create_subnetworks = false
}

backing_file.tf - provider 에서 리전을 지정하지 않아도 된다고 하는데 지정해주었다.

locals {
name_suffix = "linuxer"
}
provider "google" {
region = "us-central1"
zone = "us-central1-c"
}

VPC : linuxer-vpc
linuxer-us-central1-subnet us-central1 / 10.2.0.0/16
linuxer-europe-west1-subnet europe-west1 / 10.3.0.0/16

dellpa34@cloudshell:~/docs-examples/subnetwork_basic$ terraform plan
Error: Error locking state: Error acquiring the state lock: resource temporarily unavailable
Lock Info:
ID: 640725d0-1fad-c74e-7cff-35baf4c72937
Path: terraform.tfstate
Operation: OperationTypeApply
Who: dellpa34@cs-6000-devshell-vm-3de0c123-93a9-4a2f-a584-d94918d8801a
Version: 0.12.18
Created: 2020-01-04 12:07:10.301086954 +0000 UTC
Info:
Terraform acquires a state lock to protect the state from being written
by multiple users at the same time. Please resolve the issue above and try
again. For most commands, you can disable locking with the "-lock=false"
flag, but this is not recommended.

테스트중에 캔슬 한번했더니 프로세스가 종료되지 않아서 자꾸 -lock=false 옵션을 주라고 떳다. 귀찮아서 그냥 죽였다. kill -9 4120

dellpa34 284 0.0 0.3 23080 6800 pts/1 S<s 18:01 0:00 _ -bash
dellpa34 4120 0.0 1.7 151504 29856 pts/1 T<l 21:07 0:00 _ terraform destroy
dellpa34 4123 0.1 3.0 153232 52824 pts/1 T<l 21:07 0:01 | _ /usr/local/bin/terraform destroy
dellpa34 4179 0.0 2.1 153020 37296 pts/1 T<l 21:07 0:00 | _ /home/dellpa34/docs-examples/subnetwork_basic/.terraform/plugins/linux_amd64/terraform-provider-google_v3.3.0_x5
dellpa34 4186 0.0 1.3 124688 22536 pts/1 T<l 21:07 0:00 | _ /home/dellpa34/docs-examples/subnetwork_basic/.terraform/plugins/linux_amd64/terraform-provider-random_v2.2.1_x4
dellpa34 4462 0.0 0.1 38304 3200 pts/1 R<+ 21:17 0:00 _ ps afxuwww
dellpa34@cloudshell:~/docs-examples/subnetwork_basic$ kill -9 4120

프로세스를 죽이고 apply 하여 정상적으로 생성되는것을 확인하였다.

대문자..-_-;;

일단 테라폼에서 vpc 생성할때 대문자는 안된다.

GUI에서도 대문자 사용은 불가하네..좋은걸 알았다..

내두시간..!