AWS 5일차_2025_04_18

어제는 테라폼 코드를 모듈화해서 변수에 따라 다른 리전에서 각 서브넷을 실행하도록 코드를 만들어봤다.

그리고 VPC에 private 서브넷 영역에 endpoint를 만들어서 인터넷 통신이 아닌 내부 통신으로 db 인스턴스와 s3를 통신시켜 보고

라우팅 테이블에 엔드포인트를 추가해서도 되는 것을 확인했다.

VPC피어링으로 서울리전과 도쿄리전이 피어링을 할 수 있게 설정도 해봤다.

마지막으로 비대칭키도 테라폼 코드로 생성하고 aws에 올리기까지 했다.

---

복습으로 어제의 코드를 살짝 고쳐서 키 생성을 해보자

코드에 맞게 생성된 모습이다.

 

현재 경로에 비대칭키쌍 파일 생성

 

잘 생성된 모습이다.

 

해당 공개키로 인스턴스로 생성 시 비밀키로 접속이 잘 되는 것을 볼 수 있다.

 

이제 리눅스에서 설치 -> 사용을 해보자

 

repo 다운로드 후 설치

 

둘 다 설치해 주고 aws 설정을 완료하자

tf파일 코드 생성

 

실행하고 이 키로 인스턴스 생성을 하자

 

키와 인스턴스를 생성했다.

 

local_file 리소스 생성 시 멤버중 file_permission으로 권한을 줄 수 있다.

 

권한이 잘 생성되었다.

 

이제 -i 옵션으로 생성된 키를 이용해 접속해 보자

---

terraform [global option] init [option]으로 사용 가능

 

global 옵션에는 change dir 옵션이 있다.

 

init명령어 사용 시 리스소가 실행될 때 사용되는 플러그인을 다운받고 초기 설정을 한다.

 

terraform plan으로 apply 실행 전 이 코드 실행 전 trstate파일과 비교해서 어떤 일이 일어날 지 확인한다.

 

plan -out 옵션으로 plan 파일을 생성하고 그 파일로 apply 할 수 있다.

 

plan 파일로 실행 시 yes를 물어보는 질문을 하지 않는다.

 

plan->apply

validate

api 작업을 실행하지 않고 문법적 요소의 정확성을 확인해 준다.

 

생성한 후 삭제하는 기능(운영을 위한 옵션)

 

이렇게 설정하면 5.0.x버전중 가장 높은 버전을 받아올 것이다.

 

5.0으로 입력한다면 5.x이므로 마이너 넘버와 패치 넘버가 가장 높은 버전을 받아올 것이다.

%errorlevel%은 윈도우에서 직전 명령어가 잘 실행되었는지 확인해 주는 명령어이다.

 

잘 실행됬으면 0 오류가 있다면 1이 나온다.

 

리눅스에서는 $?로 확인한다.

 

오류 시 1 없는 명령어 사용 시 127이 나오는 모습이다.

csv파일을 만들어서 실행해 보자

오류 없을 시 0

오류가 있을 시 1

오류가 없지만 값이 변했을 시 2가 나온다.

 

csv파일을 열어두고 실행시키면 수정이 불가능하므로 실패하고 1번을 출력한다.

 

plan 파일을 고정된 내용이므로 수정 시 saved plan is stale이란 오류와 함께

도이상 유효하지 않은 plan파일이며 수정된 내용은 다시 plan을 만들어야 한다고 고지한다.

 

뒤에 -auto-approve를 사용하면 yes를 입력하지 않아도 명시적 허용을 시켜준다.

 

rsa 키를 재생성 해보자

 

replace 옵션을 사용해 다시 실행을 시켜주면 된다.

 

핑거프린트가 변한 모습을 볼 수 있다.

---

이렇게 들여쓰기가 안 된 파일도

 

fmt 옵션을 사용하면

 

들여쓰기를 통해 보기 좋은 모양으로 바꿔준다.

 

fmt -recursive를 사용하면 하위 디렉토리까지 전부 고쳐준다.

---

HCL은 하시코프사에서 구성 정보를 명시하기 위해 개발된 오픈소스이다.

 

HCL은 테라폼에서 코드의 영역을 담당하는 기술이다.

locals를 이용해 코드 내부에서 변수를 선언 - 사용이 가능하다.

 

그래도 변수 파일을 하나 지정해서 하는 것이 가독성에 좋다.

---

테라폼 블록

 

테라폼의 구성을 명시하는 데 사용됨

 

버전을 명시하고 조건을 입력할 수 있다.

 

없어도 오류는 없고 latest버전을 자동으로 사용하나 협업 시 서로 다른 버전일 시

문제를 막기 위해 버전을 명시적으로 입력하는 게 좋다.

 

테라폼의 버전관리

Major	아주 큰 변화, 버전 변경 시 호환이 안 될 가능성이 매우 높음, API의 생성 및 삭제가 이루어짐
Minor	신규 기능 추가, 개선 호환 안 될 가능성이 있음,
Patch	버그 및 일부 기능 개선 하위 호환 가능한 버전

 

= or 버전 정보만 명시

해당 버전만 허용하고 다른 버전은 허용하지 않음

 

!=

지정 버전 제외한 나머지 버전

 

>, >=, <=, <

지정한 버전과 비교해서 조건에 맞는 버전

 

~>

지정한 버전에서 가장 자릿수가 낮은 구성요소만 증가하는 것을 허용

 

and 연산을 하려면 ,를 사용하자

---

백엔드 블록

테라폼 실행 시 state 파일의 위치를 선언한다.

 

기본값은 local이다.

 

state 잠금 동작을 위해서 동시에 해당 state를 사용하지 못하게 lock을 걸어버린다.

 

yes를 눌러 tfstate파일의 점유를 풀면 lock이 풀린다.

 

backend 구성의 위치를 지정해 줄 수 있고

 

s3 인스턴스 내부에 설정해 줄 수도 있다.

 

-migrate-state로 최신 스냅샷을 읽고 기록된 정보를 새 구성으로 전환한다.

-reconfigure로 init 실행 전 

---

리소스

 

리소스 유형, 이름, 키, 값을 넣는다.

 

이름은 _를 구분으로 프로바이더 이름 그 뒤는 리소스 유형을 의미한다.

depends_on: 종속성을 선언하며, 선언된 구성 요소와의 생성 시점에 대해 정의

count: n개의 리소스 생성

count로 리소스 생성 시 index라는 변수가 생성된다.

 

아래는 웹1, 2를 각각 생성하고 3, 4를 count로 생성한 모습이다.

lifecycle: 리소스의 수명주기 관리

provider: 동일한 프로바이더가 다수 정의되어 있는 경우 지정

timeouts: 프로바이더에서 정의한 일부 리소스 유형에서는 create, update, delete에 대한 허용 시간을 정의 가능

 

ip를 output으로 출력

 

잘 출력된 것 같다.

---

종속성

 

생성 선후 관계에 따라서 자동으로 연관 관계가 정의되는 암시적 종속성이 생기고,

 

강제로 리소스 간 명시적 종속성을 부여하기 위해선 depends_on을 활용하면 된다.

 

보통 선후관계가 암시적 종속성으로 잘 실행이 되나 선후관계 생성이 완벽하게 되지 않으면

depends_on을 사용해서 선행되야하는 생성 우선순위를 정해줘야 한다.

 

종속성은 보통 암시적으로 해결해 주긴 한다.

 

이런 식으로 키 생성 -> 키 사용으로 우분투에 접속해 보자

 

잘 접속이 된 모습이다.