Minecraft 서버를 Terraform으로 관리하는 이유

VM 한 대와 함께 만드는 Google Cloud 리소스와 Terraform plan, state의 관리 범위

Google Cloud Console에서 운영체제, 리전, 머신 유형과 디스크를 고르면 첫 VM을 빠르게 실행할 수 있다. 하루 정도 시험하고 지울 서버에는 이 방법이 가볍다.

외부 IP를 고정하고 게임 포트와 SSH 포트를 따로 열면 관리할 대상이 늘어난다. 백업 저장소와 서비스 계정도 필요하다. 화면에서는 서버 한 대지만 Google Cloud 안에서는 여러 리소스가 서로 연결돼 있다. 몇 달 뒤 사양을 바꾸거나 서버를 접을 때마다 처음 고른 값을 다시 찾아야 한다.

Console로 만든 서버도 계속 운영할 수 있다. 같은 구성을 다시 만들거나 여러 리소스를 함께 바꾸고 지울 계획이 있다면 Terraform의 코드와 state가 후속 작업의 기준이 된다.

첫 시험을 위한 Console

처음 한 번 시험할 서버는 별도 구성 파일 없이 Compute Engine 화면에서 만들 수 있다. 생성을 마친 뒤에도 현재 운영체제, 리전, 머신 유형과 디스크 값을 화면에서 확인할 수 있다.

Console에는 완성된 리소스가 남지만 클릭한 순서는 남지 않는다. 서울 리전을 고른 이유나 방화벽에 넣은 IP는 따로 적어 둬야 한다. 서버를 다시 만들 때 이 메모가 없으면 기억에 의존하게 된다.

gcloud 명령은 클릭을 터미널 명령으로 바꾼다. 명령을 메모해 두면 반복할 수 있지만, 이미 있는 리소스가 명령의 예상과 다르면 운영자가 다음 행동을 정해야 한다. 셸 스크립트에는 이런 분기도 넣을 수 있다. 대신 생성, 수정과 삭제 순서를 모두 직접 작성해야 한다.

VM과 함께 만드는 리소스

외부 접속과 백업까지 고려하면 VM만으로는 부족하다. minecraft-one-root가 만드는 Google Cloud 리소스는 다음과 같다.

Google Cloud 프로젝트
├── VPC와 서브넷
├── 게임 포트 방화벽과 SSH 방화벽
├── 고정 외부 IPv4
├── 전용 서비스 계정
├── Spot VM과 부팅 디스크
├── 월드 백업 버킷
└── Terraform state 버킷

VM을 지워도 고정 IP나 버킷은 남을 수 있다. 반대로 state 버킷을 먼저 지우면 Terraform이 실제 리소스와 코드의 관계를 잃는다. VM, 고정 IP와 두 버킷은 삭제 조건과 시점이 서로 다르다.

도구별 준비와 반복 작업

서버를 한 번 시험할지, 몇 달 동안 바꿔 가며 운영할지에 따라 알맞은 도구와 준비 시간이 달라진다.

방법첫 생성적용 전 변경 확인같은 구성 재현리소스 추적과 삭제월드 보호
Console가장 빠름화면별 확인클릭 기록을 따로 남겨야 함여러 화면에서 찾아야 함별도 백업 필요
gcloud명령을 익혀야 함명령별 확인명령 기록으로 반복 가능이름과 순서를 직접 관리별도 백업 필요
셸 스크립트스크립트 작성 필요작성한 출력에 따름분기까지 구현하면 가능생성, 수정과 삭제 로직을 직접 작성별도 백업 필요
TerraformHCL과 state를 익혀야 함plan으로 전체 차이 확인같은 코드와 입력으로 계획 가능state가 코드 주소와 리소스를 연결별도 백업 필요

HCL은 Terraform이 리소스를 정의할 때 쓰는 설정 파일 문법이다. state는 Terraform 주소와 실제 리소스의 대응을 저장한다. 서버의 Terraform 구성에서 두 파일의 위치를 확인할 수 있다.

첫 VM만 놓고 보면 Terraform이 더 느리다. HCL 문법을 익히고 state를 보관할 곳도 준비해야 한다. 대신 사양을 바꿀 때는 plan에서 관련 변경을 함께 읽고, 운영을 끝낼 때는 state에서 남은 리소스를 찾을 수 있다.

적용 전에 보는 변경 내역

Terraform 파일에는 원하는 상태를 적는다. 예를 들어 머신 유형을 e2-standard-2에서 다른 값으로 바꾸고 terraform plan을 실행하면 Terraform은 현재 state와 새 구성을 비교한다.

코드와 입력값 ──┐
                ├─ terraform plan ── 생성, 수정, 교체, 삭제 예정
현재 state ─────┘

plan만으로는 아무것도 바뀌지 않는다. 출력에는 VM을 제자리에서 수정하는지, 중지해야 하는지, 새 리소스로 교체하는지가 표시된다. 함께 제공하는 review-plan.sh는 첫 배포 계획에 수정, 삭제나 교체가 섞이면 멈춘다.

계획 파일을 오래 보관해 두고 나중에 적용하면 곤란하다. 그사이 Console에서 리소스가 바뀔 수 있기 때문이다. 적용할 계획은 직전에 새로 만들고 직접 읽는다.

코드와 실제 VM을 잇는 state

state는 google_compute_instance.minecraft 같은 Terraform 주소와 실제 Compute Engine VM을 연결한다. 이 기록이 있어야 Terraform은 이미 있는 VM을 수정할지, 새로 만들지 구분할 수 있다. minecraft-one-root는 Cloud Shell 세션이 끝나도 기록이 남도록 Cloud Storage backend를 사용한다.

state에는 리소스 속성이 들어갈 수 있다. 비밀번호나 토큰을 Terraform 입력에 넣으면 민감한 값도 state에 남을 수 있다. minecraft-one-root는 Minecraft 콘솔 비밀번호를 만들지 않고 state 버킷 접근 권한을 제한한다. state 파일을 Git이나 공개 ZIP에 넣지 않는 이유다.

state는 월드 파일을 담지 않는다. VM의 /srv/minecraft/world가 손상돼도 state는 정상일 수 있다. Terraform은 Google Cloud 리소스와 그 속성을 기억하고, 게임 데이터는 별도 백업으로 보존한다.

apply 뒤에 따로 확인할 상태

minecraft-one-root의 Terraform은 VPC, 방화벽, 고정 IP, 서비스 계정, VM과 백업 버킷을 만든다. VM metadata에는 시작 스크립트와 Minecraft JAR의 URL, 해시와 Java 버전이 들어간다. 부팅 뒤에는 startup script가 Java와 systemd 서비스를 준비한다.

terraform apply가 끝난 뒤에는 서로 다른 상태를 차례로 봐야 한다.

  • Compute Engine API에서 VM이 RUNNING인지 본다.
  • systemctl에서 minecraft.service가 active인지 본다.
  • Minecraft 로그에서 Done (...)!이 나왔는지 본다.
  • Minecraft 콘솔에서 whitelist와 운영자를 관리한다.
  • 백업 스크립트가 월드와 운영 설정을 압축하고 Cloud Storage에 올린다.
  • 격리 복원 시험이 archive를 실제 Minecraft 프로세스로 불러온다.

Terraform apply의 성공은 Google Cloud 리소스가 계획대로 만들어졌다는 뜻이다. Minecraft 준비 완료는 서버 로그의 Done (...)!에서 알 수 있다. 백업은 별도 서버에서 월드를 불러오는 시험까지 통과해야 복구에 쓸 수 있다.

Console만으로 충분한 서버

아래와 같은 서버라면 Console에서 만들고 작업 내용을 메모하는 편이 가볍다.

  • 하루나 주말 동안만 쓰고 삭제할 시험 서버다.
  • 같은 구성을 다시 만들 계획이 없다.
  • 한 사람이 Console에서 만든 리소스를 끝까지 정리할 수 있다.
  • VM을 지워도 되는 새 월드만 사용한다.

몇 달 동안 서버를 켜고 끄면서 사양과 버전을 바꾸거나 같은 구성을 다시 만들 예정이라면 Terraform의 코드와 state를 활용할 수 있다. 운영을 끝낼 때도 state를 기준으로 관리 중인 리소스를 확인한다.

Terraform을 선택해도 월드 백업은 별도로 준비해야 한다. 중요한 기존 월드는 06편의 격리 복원 시험을 통과하기 전까지 이 서버로 옮기지 않는다.

구축에는 Google Cloud 결제 계정과 Minecraft Java Edition 클라이언트가 필요하다. 무료 체험 대상인 신규 고객은 지원되는 결제 수단으로 본인을 확인하면 90일 동안 쓸 수 있는 $300 크레딧을 받는다. 직접 유료 계정으로 전환하기 전에는 자동으로 과금되지 않는다. 유료 계정 전환 여부와 예산 알림을 확인하는 절차는 프로젝트와 Cloud Shell 준비에 있다. 예산 알림은 지출을 통보하지만 과금을 자동으로 중단하지 않는다.

참고

Comments

댓글

    이미지 확대