Azure-네트워크 구성 및 망분리

azure 에서 망분리가 먼저 선행되어야 할 과제이다.
aws 에서의 망분리는 계층적 망분리로 서브넷과 라우팅 테이블을 이용하여 망분리를 구현한다. 하지만 gcp / azure는 망분리의 개념이 좀 다르다.

서브넷을 통한 망분리가 아닌 공인IP의 유무로 망분리를 구현한다.

근래에 구성도를 작성하면서 한편으로 계층적 망구성이 구성도 그리긴 불편한 생각이 들긴한데 그래도 익숙하고 편한데 azure 와 gcp 를 보니까 aws 의 망구성이 관리의 편의성이 떨어지는 느낌이기도 하고..조금 애매한 느낌이 든다.

azure 에서는 어떤 인프라도 리소스그룹안에서 만들어진다. gcp의 프로젝트 개념과도 같다. 그렇지만 좀 다른게 리전에 종속된다.

한국리전은 중부와 남부로 나뉘는데 중부를 azure 에선 중부를 주로 추천하는데 나는 중부말고 남부를 선택했다.

요구하는 바는 구독 그룹네임 리전 리소스 그룹다음에는 virtual network 를 생성하는데 VN은 서브넷을 생성하게 된다.

가상네트웤의 최대 크기는 10.0.0.0/8 까지로 16777216개 주소 를 사용할수 있다.

서브넷을 3개로 나누었고 서브넷은

보안그룹을 서브넷에 설정하여 접근제어가 가능하다.

aws 의 구성의 경우엔 az 별 서비스별 서브넷을 설정했지만 azure 는 az가 명시적으로 지정되지 않아 서비스별 서브넷을 생성해서 사용하는것이 최선으로보인다.

서브넷의 보안그룹으로 막으려면 tag ip id 로 명시적으로 막자.

서브넷별 nsg 가 구성되는게 좋을것 같다.

가상머신은 공용아이피를 없앤 채로 생성한후 나중에 공용IP를 부여할수있었다.

직렬연결은 가상화 머신의 화면을 그대로 포워딩해주는 방식으로 보이며 공용IP가 없는 상태에서도 연결할수 있었다.

굉장히 불편한 부분은 이다음에 발생했는데 lb 는 sku 개념덕분에 혼파망이 되었다.

sku는 basic / standard 두가지로 나누어져있는데

Configures outbound SNAT for the instances in the backend pool to use the public IP address specified in the frontend.

인터넷 통신

기본적으로 VNet의 모든 리소스는 인터넷으로 아웃바운드 통신을 할 수 있습니다. 공용 IP 주소 또는 공용 Load Balancer를 할당하여 리소스에 대해 인바운드로 통신할 수 있습니다. 공용 IP 또는 공용 Load Balancer를 사용하여 아웃바운드 연결을 관리할 수도 있습니다. Azure의 아웃바운드 연결에 대한 자세한 내용은 아웃바운드 연결공용 IP 주소 및 Load Balancer를 참조하세요.

하…모든인스턴스는 인터넷과 통신이 가능하다. 이거때문에 한참을 헤멧다.

nat gw가 필요가 없다…………………………충격 막으려면 NSG로 막아라.

그래서 일단 정리하자면 azure 의 모든 네트워크 접근제어는 네트워크 단위가 아니라 NSG에서 모두 컨트롤한다.

선택한 서브넷 ‘linuxer-subnet-pri(10.0.0.0/24)’이(가) 네트워크 보안 그룹 ‘pri-sub-sg’에 이미 연결되어 있습니다. 여기에 새 네트워크 보안 그룹을 만드는 대신 기존 네트워크 보안 그룹을 통해 이 가상 머신과 연결을 관리하는 것이 좋습니다.

azure LB사용할땐 가용성 집합을 이용해서 VM을 만든다.

리소스그룹-vpc-subnet-가용성집합-vm-lb 순으로 생성하게 된다.

LB는 베이직과 스텐다드..하 sku 개념이 제일짜증난다.

LB를 베이직으로 생성시에

???같은 가용성 집합인데????

음…이유는 다음에 찾아보기로 하고..

sku 가 스텐다드인경우엔 잘 된다..음 베이직이라 제한이 있는것으로 이해하고 지나가기로 한다.

상태 체크는 로드벨런스 안에서..아니면 zure monitor 을 이용하자.

근데 LB에서 페이지가 뜨는건 잘안됬다 왜지?

그리고 스터디를 마치고 집에와서 백엔드 규칙만 재생성하니 정상적으로 잘됨..뭐야이거..빡치네..

aws-cloudfront-s3-lambda cross-account access

cloudfront – s3 를 이용하게되면 결국 OAI를 이용한 Bucket policy를 사용하게 된다.

단일 계정에서 사용할 경우엔 cloudfront 에서 자동으로 생성까지 해주므로 어려울것이 전혀없다.

그런데 이제 이게 파트너사를 통해서 cloudfront 전용계정을 사용하게 된다던거 multi account 로 프로젝트를 진행할경우 자동으로 생성이 되지 않는다. 이 경우에 어떤방식으로 s3 Bucket policy 를 설정해야 하는지 포스팅하려 한다.

먼저 Bucket policy 를보자

{
“Version”: “2012-10-17”,
“Id”: “PolicyForCloudFrontPrivateContent”,
“Statement”: [
{
“Sid”: ” Grant a CloudFront Origin Identity access to support private content”,
“Effect”: “Allow”,
“Principal”: {
“AWS”: [
“arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E39X8K28W3EQ”
]
},
“Action”: “s3:GetObject”,
“Resource”: “arn:aws:s3:::*”
}
]
}

일반적으로 계정에서 버킷정책을 설정하면 위와같은 형태로 적용을 한다.
가끔 정상적으로 적용이되지않는경우엔

{
“Version”: “2012-10-17”,
“Id”: “PolicyForCloudFrontPrivateContent”,
“Statement”: [
{
“Sid”: ” Grant a CloudFront Origin Identity access to support private content”,
“Effect”: “Allow”,
“Principal”: {
“AWS”: [
“arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity 49821f785cce6ee4f575de3f01c503dade8a7b15003aa337faa471d830d07493cbb195eec14f0d86d4a914622e1e42”
]
},
“Action”: “s3:GetObject”,
“Resource”: “arn:aws:s3:::*”
}
]
}

이런식으로 caninucal user id 를 이용하여 정책을 설정하면 자동으로 OAI ID로 정책이 적용되게 된다.

여기까진 아주 쉬웠다. 그런데

람다 엣지를 이용한 리사이즈를 하는 프로세스에서 단일계정이 아니라 교차계정을 구성하게 되면 lambda가 A 계정에서 B 계정으로 접근하게 해줘야한다. 이부분에서 조금 헤멧는데 결국엔 굉장히 간단한 부분이었다.

s3 Bucket policy 에서 계정의 role을 허용해주면 끝..

{
“Version”: “2012-10-17”,
“Id”: “PolicyForCloudFrontPrivateContent”,
“Statement”: [
{
“Sid”: ” Grant a CloudFront Origin Identity access to support private content”,
“Effect”: “Allow”,
“Principal”: {
“AWS”: [
“arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E39X8K58WRN3EQ”,
“arn:aws:iam::328341115633:role/lambda-resize-cloudfront”
]
},
“Action”: “s3:GetObject”,
“Resource”: “arn:aws:s3:::linuxer-resize/*”
}
]
}

arn:aws:iam::328341115633:role/lambda-resize-cloudfront

json 문법에 또 약해서 좀 해멧는데 금새 해결할수 있었다..

aws-EFS-backup-restore

EFS를 사용하고 백업/복구 이야기를 하려고한다.

EFS는 NFS기반의 편리한 서비스다. aws backup로 스냅샷 방식의 백업이 가능하다.

현재 측정크기가 6.0kib인데

# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 475M 0 475M 0% /dev
tmpfs 492M 0 492M 0% /dev/shm
tmpfs 492M 404K 492M 1% /run
tmpfs 492M 0 492M 0% /sys/fs/cgroup
/dev/xvda1 8.0G 4.6G 3.5G 57% /
tmpfs 99M 0 99M 0% /run/user/0
fs-7eb4fb1f.s.ap-northeast-2.amazonaws.com:/ 8.0E 0 8.0E 0% /mnt/efs

root@ip-10-0-0-12 wordpress]# cd /mnt/efs
# du –max-depth=1 -h
258M ./ftp
258M .

실제론 그렇지 않다. 일정 GB이상의 데이터가 쌓여야 명령어가아닌 gui에서 확인할수 있다.

오늘은 이 파일시스템을 백업할거다.

aws backup를 사용할때 유의할점은 백업볼트를 생성할때 각각 목적에 맞게 분할해서 사용하라는 거다. 급하게 작업하다가 관리가 너무 불편해져서 결국 나눴다.

일반적으론 볼트생성->계획생성->규칙생성->리소스할당 순서다.

리소스할당은 tag 기반으로도 가능하고 리소스ID 유형으로도 가능하다.

여기까지 백업계획을 이용한 스케줄 백업이었고 단발성 백업은 대시보드에서 온디멘드 백업으로 진행하면 된다.

진행중인 jab는 작업부분에서 확인할수 있다.

용량이 작어서 금방 백업이 완료됬다.

백업은 증분방식이고 복구지점에 카운트가 올라간다.

복원을 진행해 보면

전체/부분/소스/새 이렇게 선택지가 나눠지는데 얼마전 나에게 혼란을 줬던 부분은 전체-소스 파일 시스템에 복원이다.

복원을 누르면 작업탭에 복원에서 확인할수 있다.

Pending-> Running -> Completed 단계를 거친다.

Pending 이 한국어 에선 보류중으로 나오는데 처음에 좀 당황했다.
보류…??????????????????????????????????????????????
하고 Pending 좀 오래걸린다. 거의 10분 이상걸린적도있다.

root@ip-10-0-0-12 ~]# cd /mnt/efs/
root@ip-10-0-0-12 efs]# ll
total 16
drwxr-xr-x 4 root root 6144 Jan 18 11:24 aws-backup-restore_2020-01-18T03-33-30-039Z
drwxr-xr-x 4 root root 6144 Jan 18 11:24 aws-backup-restore_2020-01-18T03-47-22-912Z
drwxr-xr-x 4 root root 6144 Jan 18 11:24 aws-backup-restore_2020-01-18T03-49-03-261Z
drwxr-xr-x 3 jth-ftp jth-ftp 6144 Aug 21 21:20 jth-ftp

aws-backup-restore_2020-01-18T03-33-30-039Z 같은 형식으로 복원 시작시간으로 디렉토리가 생성되고 복원이 된다. 당연히 복원되는 양에 따라서 속도도 다르다.

3번 복원을해서 3개의 디렉토리가 추가 생성된거다. 사용용량이 df 로는 안보이지만 aws 콘솔에선 보인다.

처음 복구할 땐 덮어쓰기로 생각해서 한참을 기다려도 복구가 안되는거같아 EFS의 /를 마운트 해보고서야 알았다. 아 디렉토리 생성 후 복구되는구나.

그래서 이제 추가로 파일 복구를 해보기로 했다.

root@ip-10-0-0-12 wp-admin]# pwd
/mnt/efs/jth-ftp/wordpress/wp-admin
root@ip-10-0-0-12 wp-admin]# ll
total 980

/mnt/efs/jth-ftp/wordpress/wp-admin 디렉토리를 복구해보겠다.

부분 복원으로 선택하고~ 작업은 부분복원이 좀더 걸리는거 같았다.

/mnt/efs/aws-backup-restore_2020-01-18T04-09-39-782Z/jth-ftp/wordpress/wp-admin

경로로 이동해서 복구 확인해봤다.

root@ip-10-0-0-12 wp-admin]# ll
total 980

정상적으로 잘복구 된것을 확인할수 있었다.

efs 를 매우 애용하는 입장에서 파일복구가 가능해진것은 매우 반길 일이다.

아 추가로 EFS 에서 Bursting 모드를 사용할경우 BurstCreditBalance 를 가지게 되고 사용시 소모가 된다. 그런데 백업이나 복구시에는 크레딧을 따로 소모하지 않았다.

읽어주셔서 감사하다!

aws-dynamic-cloudfront

오늘의 주제는 dynamic cdn / 동적 cloudfront 다.

cloudfront 는 cdn 이다. cdn 이 뭔가?

Contents Delivery Network 컨텐츠를 빠르게 전송하기 위해서 사용자에게 가까운 edge 에서 응답해주는 방식이다. – edge 는 aws에서 말하는 용어이고 보통 pop라고 한다.

많은 지역에 pop이 존재하고 이 pop에선 원본 컨텐츠를 캐싱하여 user에게 전달한다.

구성도로 보자면 다음과 같다.

user 가 네임서버에 domain 에대한 확인을 하고 cf의 위치를 알려주면 user는 가장가까운 pop에 연결된다.

간단하게 확인하려면 f12를 눌러서 cloudfront 의 헤더를 확인해 보면 된다.

https://cdn.linuxer.name/test/iu.jpg

x-amz-cf-pop : ICN50 이부분이 근처의 팝인것이다.

이렇게 정성스럽게 설명하는 이유는 간단하다.

오늘 설정할 부분이 일반적인 CDN의 사용방법이 아니기때문이다.

사이트의 응답속도를 빠르게 하려면 어떻게 해야할까?

많은 방법이 있는데 제일 좋은 방법은 먼저 컨텐츠에 도달하는 속도를 올리는 방법이다. 컨텐츠에 대한 도달속도를 확인하는 방법은 첫번째로

tracert 이다.

테스트하는 도메인의 구성이다.

>tracert 리눅서.com
1 1 ms <1 ms <1 ms 192.168.2.1
2 1 ms 1 ms 1 ms 121.125.68.225
3 2 ms 3 ms 3 ms 100.127.39.21
4 3 ms 4 ms 2 ms 10.222.41.224
5 3 ms 2 ms 3 ms 10.222.14.73
6 2 ms 2 ms 6 ms 211.210.54.34
7 * * * 요청 시간이 만료되었습니다.
8 * * * 요청 시간이 만료되었습니다.
9 * * * 요청 시간이 만료되었습니다.
10 * * * 요청 시간이 만료되었습니다.
11 4 ms 5 ms 4 ms 52.93.248.221
12 4 ms 3 ms 4 ms 54.239.123.121
13 3 ms 3 ms 3 ms 54.239.122.38

54.239.122.38 IP는 아마존 IP로 아마존 내 네트워크 까지 연결된것을 확인할수 있었다.

그다음 도메인은 cf에 연결된 도메인이다.

>tracert linuxer.name
1 1 ms <1 ms <1 ms 192.168.2.1
2 1 ms 1 ms 1 ms 121.125.68.225
3 1 ms 3 ms 3 ms 100.127.36.21
4 4 ms 2 ms 2 ms 10.222.41.230
5 2 ms 1 ms 1 ms 10.222.15.91
6 2 ms 3 ms 3 ms 211.210.54.34
7 3 ms 3 ms 3 ms 52.93.248.36
8 3 ms 2 ms 2 ms 52.93.248.83
9 2 ms 2 ms 2 ms 54.239.41.13
10 * * * 요청 시간이 만료되었습니다.
11 * * * 요청 시간이 만료되었습니다.
12 * * * 요청 시간이 만료되었습니다.
13 2 ms 2 ms 2 ms server-54-230-181-122.icn50.r.cloudfront.net [54.230.181.122]
추적을 완료했습니다.

지금 구성에서 linuxer.name 과 리눅서.com 사이트의 동작 자체는 동일하나 리눅서.com은 로드벨런서를 다이렉트로 바라보고 있고 linuxer.name 은 cloudfront 로 연결되어 오리즌을 로드벨런서로 바라보고 있는상태이다.

그럼 라우팅은 정상적으로 cloudfront 쪽이 빠른걸 확인했으니 컨텐츠에 대해 접근이 빠른지 확인해 보려면 어떤방법을 사용해야할까? TTFB와 여러지표를 확인하기로 했다. 웹개발자 도구로 timing을 확인하면정확하게 확인할수 있을거라 생각했다.

ttfb 가 312.65ms 다 그럼 다이렉트로 로드벨런서에 연결된 도메인은 속도가 얼마나 나올까?

ttfb 가 435.53ms 다. 오잉? 생각보다 속도 차이가 있다.

그럼 일단 더테스트하려면…어쩔까..간단하게 해외로 간다!

18353km 떨어진 상파울루 리전의 win ec2 이용하여 테스트 하겠다.

cf가 적용되어있는-linuxer.name

cf가 적용되지 않은 리눅서.com

상황에 따른 응답속도의 차이가 있긴하지만 확실히 dynamic cdn 을 적용한 도메인쪽이 좀더 빨리 떳다.

어느정도 유효한 결과를 확인했다는 뜻이다.

물론 내블로그는 가벼우므로..또르륵

https://aws.amazon.com/ko/cloudfront/dynamic-content/

https://aws.amazon.com/ko/blogs/korea/how-to-improve-dynamic-contents-delievery-using-amazon-cloudfront/

직접 경험해야 하는터라 다하고나니까 문서를 봤다 ㅋㅋㅋ

그래서 이제 어느정도 검증이 끝났고 설정방법이다.

Cache Based on Selected Request Headers -> ALL 로 수정하면 끝이다.

나머지는 자신의 설정대로..잘하면 된다.

끝. 좋은하루 되시라!

gcp terraform-3 vpc-nat create

vpc-nat 를 연결하기로 했다.
어젠 subnet 을 만들었고 오늘은 망분리 환경을 구성하기 위해 nat 를 넣었다.

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.vpc.self_link}”
}
resource “google_compute_router” “us-central1-router” {
name = “${local.name_suffix}-us-central1-router”
region = google_compute_subnetwork.us-central1-subnet.region
network = google_compute_network.vpc.self_link
}
resource “google_compute_address” “address” {
count = 2
name = “${local.name_suffix}-nat-manual-ip-${count.index}”
region = google_compute_subnetwork.us-central1-subnet.region
}
resource “google_compute_router_nat” “nat_manual” {
name = “${local.name_suffix}-us-central1-router-nat”
router = google_compute_router.us-central1-router.name
region = google_compute_router.us-central1-router.region
nat_ip_allocate_option = “MANUAL_ONLY”
nat_ips = google_compute_address.address.*.self_link

source_subnetwork_ip_ranges_to_nat = “LIST_OF_SUBNETWORKS”
subnetwork {
name = “${local.name_suffix}-us-central1-subnet”
source_ip_ranges_to_nat = [“10.2.0.0/16”]
}
}

resource “google_compute_network” “vpc” {
name = “${local.name_suffix}-vpc”
auto_create_subnetworks = false
}

backing_file.tf

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

vpc 와 nat nat route 까지 정상적으로 만들어져서 동작하는 것을 확인할 수 있었다.

리전당 nat는 1개를 꼭만들어야 했다.

현재 생성한 tf는 subnet 하나에 대한 설정이다. 다른 리전으로도 네임만 수정을 적절히 하면 수정해서 쓸수 있다.

gcp- Google Kubernetes Engine

https://cloud.google.com/kubernetes-engine/docs/quickstart?hl=ko

먼저 cloud shell 에서 프로젝트 지정하고 리전(아님)을 지정한다. – 수정- zone 을 지정한다.

linuxer@cloudshell:~ (elated-ranger-263505)$ gcloud config set compute/zone us-central1-a
Updated property [compute/zone].

그리고 컨테이너 클러스터를 생성한다.

linuxer@cloudshell:~ (elated-ranger-263505)$ gcloud container clusters create linuxer-k8s

WARNING: Currently VPC-native is not the default mode during cluster creation. In the future, this will become the default mode and can be disabled using --no-enable-ip-ali as flag. Use --[no-]enable-ip-alias flag to suppress this warning.
WARNING: Newly created clusters and node-pools will have node auto-upgrade enabled by default. This can be disabled using the --no-enable-autoupgrade flag.
WARNING: Starting in 1.12, default node pools in new clusters will have their legacy Compute Engine instance metadata endpoints disabled by default. To create a cluster with
legacy instance metadata endpoints disabled in the default node pool, run clusters create with the flag --metadata disable-legacy-endpoints=true.
WARNING: Your Pod address range (--cluster-ipv4-cidr) can accommodate at most 1008 node(s).
This will enable the autorepair feature for nodes. Please see https://cloud.google.com/kubernetes-engine/docs/node-auto-repair for more information on node autorepairs.
ERROR: (gcloud.container.clusters.create) ResponseError: code=403, message=Kubernetes Engine API is not enabled for this project. Please ensure it is enabled in Google Cloud
Console and try again: visit https://console.cloud.google.com/apis/api/container.googleapis.com/overview?project=elated-ranger-26 to do so.

api error 는 역시나 사이트로 이동해서 허용해준다.

zone 을 지정하지 않고 리전을 자꾸 지정해서 클러스터를 생성할 수 없었다.

서태호님께서 잘못된 부분을 알려주셨다. 덕분에 진행할수 있었다.ㅜㅜ다행

gcloud container clusters get-credentials linuxer-k8s@cloudshell:~ (jth3434-197516)$ gcloud config set compute/zone us-central1-a

정상적으로 클러스터를 생성하고

@cloudshell:~ (jth3434-197516)$ gcloud container clusters get-credentials linuxer-k8s

클러스터 사용자 인증하고~

https://github.com/GoogleCloudPlatform/kubernetes-engine-samples/tree/master/hello-app

URL 참고하시고 hello-app 으로 deployment 한다.

@cloudshell:~/hello-app (jth3434-197516)$ kubectl create deployment hello-server –image=gcr.io/google-samples/hello-app:1.0

hello-app ver 1.0 이다. dockerfile 을 확인하면 컨테이너 설정을 확인할수 있다.

kubectl expose 를 이용하여 생성한 파일을 노출한다.

@cloudshell:~/hello-app (jth3434-197516)$ kubectl get pods
NAME READY STATUS RESTARTS AGE
hello-server-64db4d4dc7-xtrcd 1/1 Running 0 12m
@cloudshell:~/hello-app (jth3434-197516)$ kubectl get service hello-server
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hello-server LoadBalancer 10.35.255.80 35.223.145.93 80:30201/TCP 5m30s

그리고 get pads 으로 pads 의 상태를 확인하고 서비스를 확인해서 정상적으로 external-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에서도 대문자 사용은 불가하네..좋은걸 알았다..

내두시간..!

gcp-terrafrom-1 with google cloud shell

gcp 스터디를 위해서 테라폼의 사용을 익히려고 한다.
그러기 위해선 먼저 테라폼을 gcp cloudshell 에서 사용하는것이 우선이라 생각했다.

테라폼으로 aws내 에선 테스트 경험이 있으므로 gcp 의 네트워크 구성과 환경에 맞춰서 테라폼을 설정하는 방법을 익혀야 했다.

gcp 에서 테라폼을 사용하려면 cloudshell 을 사용하는 방법과 인스턴스를 생성하여 사용하는 방법 아니면 클라이언트 PC에서 사용하는 방법 이렇게 3가지가 있는데 나는 cloudshell 을 매우 좋아하므로 cloudshell 로 진행 할것이다.

먼저 cloud shell 에서 테라폼을 사용하려면 몇가지 단계를 거쳐야 했다.

1 terrafrom install
2 gcp api setup
3 config setting

이 단계를 간단하게 줄여주는 페이지가 있어서 먼저 테스트 해봤다.

https://www.hashicorp.com/blog/kickstart-terraform-on-gcp-with-google-cloud-shell/  

https://github.com/terraform-google-modules/docs-examples

두개의 URL 을 참고하시기 바란다.

URL 을 따라서 진행하던중 terraform init 에서 에러가 발생하였다.

Provider “registry.terraform.io/-/google” v1.19.1 is not compatible with Terraform 0.12.18.
Provider version 2.5.0 is the earliest compatible version. Select it with
the following version constraint:

version = “~> 2.5”
Terraform checked all of the plugin versions matching the given constraint:
~> 1.19.0
Consult the documentation for this provider for more information on
compatibility between provider and Terraform versions.
Downloading plugin for provider “random” (hashicorp/random) 2.2.1…
Error: incompatible provider version

error 는 backing_file.tf 파일에서 발생하고 있었다.
간단하게 version 차이..

cloud shell 의 terrafrom version 은

dellpa34@cloudshell:~/docs-examples/oics-blog$ terraform -version
Terraform v0.12.18
provider.google v2.20.1
provider.random v2.2.1

provider.google v2.20.1 로 1.19보다 많이 높은 상태였다. 일단 진행해 보기로 했으니.. backing_file.tf 수정

provider “google” {
version = “~> 1.19.0”
region = “us-central1”
zone = “us-central1-c”
}

provider “google” {
version = “~> 2.5”
region = “us-central1”
zone = “us-central1-c”
}

수정후에 다시 terraform init 을 실행 하였다.

Initializing provider plugins…
Checking for available provider plugins…
Downloading plugin for provider “google” (hashicorp/google) 2.20.1…
Terraform has been successfully initialized!
You may now begin working with Terraform. Try running “terraform plan” to see
any changes that are required for your infrastructure. All Terraform commands
should now work.
If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

정상적으로 실행 되는것을 확인하였다.

init 후에 apply 하니 다시 Warning 과 함께 error 가 발생하였다.

Warning: Interpolation-only expressions are deprecated
on main.tf line 9, in resource “google_compute_instance” “instance”:
9: image = “${data.google_compute_image.debian_image.self_link}”
Error: Error loading zone ‘us-central1-a’: googleapi: Error 403: Access Not Configured. Compute Engine API has not been used in project 45002 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/compute.googleapis.com/overview?project=304102002 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry., accessNotConfigured
on main.tf line 1, in resource “google_compute_instance” “instance”:
1: resource “google_compute_instance” “instance” {

이건 이전에도 겪은 케이스 같다…functions api 셋팅할때 발생한 거였는데…googleapi 관련 에러다. cloudshell 에서 컴퓨팅쪽의 api를 사용할 수 없어서 발생하는 에러로 로그에 보이는 페이지로 이동해서 그냥 허용해 준다.

Enter a value: yes
google_compute_instance.instance: Creating…
google_compute_instance.instance: Still creating… [10s elapsed]
google_compute_instance.instance: Creation complete after 10s [id=vm-instance-optimum-badger]
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

허용후에 다시 terraform apply 를 치면 정상적으로 실행이 된다. 그럼 확인해 보자.

인스턴스가 생성이 됬다. 그렇다면 이젠 간단히 생성하는것 까지 완료했으므로. 이젠 기본 템플릿을 이용한 구성을 만들것이다. 생성한 테라폼은 terraform destroy 명령어로 삭제 했다.

google_compute_instance.instance: Destroying… [id=vm-instance-optimum-badger]
google_compute_instance.instance: Still destroying… [id=vm-instance-optimum-badger, 10s elapsed]
google_compute_instance.instance: Still destroying… [id=vm-instance-optimum-badger, 20s elapsed]
google_compute_instance.instance: Still destroying… [id=vm-instance-optimum-badger, 30s elapsed]
google_compute_instance.instance: Destruction complete after 38s
random_pet.suffix: Destroying… [id=optimum-badger]
random_pet.suffix: Destruction complete after 0s

정상적으로 삭제되는것을 확인할수 있었다.

gcp cloud shell 에서 terraform 을 사용하는 방법을 테스트해 보았다.
다음엔 VPC 구성과 인스턴스 그룹 생성 로드벨런서 구성까지 한방에 진행할것이다.

여담으로 cloud shell은 진짜 강력한 도구이다.

스크린샷과 같이 shell을 지원하면서 동시에 에디터도 지원한다.

vi 에 익숙한 나같은경우에는 그냥 vi 로 작업하지만 익숙하지 않은 사용자의 경우에는 우와할정도다..

쓸수록 감탄하는 cloudshell………..

GCP Professional Cloud Architect 합격 후기

AWS sap 취득 다음 순번 자격증이 GCP PCA 였다.

사실 정리를 하는 편은 아니구.. 해서 참조한 URL 을 나열 하겠다.

이수진-님의 합격후기다.

https://brunch.co.kr/@topasvga/728

서태호-님의 자격증 가이드다.

다른 사람후기는 한섭님의..첫번째 어드바이스가 있었다.

시험은 영어로 진행되서 많이 고민을 했다. 케이스를 책읽듯이 거의 외웠다.
케이스 에서 뭘 원하는지 스스로 그렸다.

이공부 덕분에 케이스 문제는 한번도 막힘없이 완벽하게 다풀었다.

그렇게 케이스 공부가 완료되고 서비스간의 연계와 사용방법을 gcp docs 를 위주로 봤다. aws sap 를 취득하면서 요령이 생긴터라 docs 를 보면서 공부하는건 어렵지 않았다.

udemy를 주로봤고 인터넷에 올라와있는 사이트들에서 문제를 많이 풀었다.

자격증 취득에 도움을 주신 서태호님,한섭님,이수진님께 감사를 드린다.