Juntiger

실전 Minecraft Terraform

19개 기록

구축과 운영 가이드

Cloud Shell 준비부터 배포, 백업, 운영과 삭제까지 서버 한 대의 전 과정

  1. Minecraft 서버를 Terraform으로 관리하는 이유 VM 한 대와 함께 만드는 Google Cloud 리소스와 Terraform plan, state의 관리 범위
  2. Google Cloud Minecraft 서버의 Terraform 구성 VPC, 방화벽, 고정 IP, VM, 권한과 저장소를 한 작업 디렉터리에 둔 구성
  3. Google Cloud 프로젝트와 Cloud Shell 준비 프로젝트 생성부터 결제 연결, 예산 알림, Cloud Shell의 Terraform 설치까지
  4. Terraform 인증과 원격 state 준비 Cloud Shell의 배포 계정, 필요한 IAM 권한, state를 보관할 Cloud Storage backend
  5. Minecraft 서버 JAR와 Terraform 입력값 준비 공식 서버 JAR, Java 버전, SHA-256, EULA, 방화벽 IP와 버킷 이름 준비
  6. Terraform plan을 적용하고 Minecraft에 접속하기 첫 Terraform 계획 읽기, 비용 승인, VM 기동과 Java Edition 접속
  7. Minecraft 월드 백업과 복원 시험 월드와 운영 설정 백업, SHA-256 검증, 운영 서버와 분리한 복원 시험
  8. 기존 Minecraft 월드를 Google Cloud로 옮기기 기존 월드 archive 검사부터 VM staging, 교체, 접속과 새 백업까지
  9. Minecraft 서버 전원과 버전 변경 VM 시작과 중지, 관리자 IP, 머신 유형, Minecraft와 Java 버전 변경 절차
  10. Spot VM 선점 뒤 Minecraft 서버 다시 시작하기 Spot 선점만 골라 같은 VM을 다시 시작하는 별도 Terraform 구성
  11. Minecraft 서버와 백업 삭제 절차 마지막 백업 보존, Spot 복구 구성 제거, 삭제 보호 해제와 서버 destroy
  12. Terraform state와 남은 Google Cloud 비용 정리 빈 state 객체와 backend 정리, 프로젝트에 남은 과금 리소스와 IAM 점검

2025년 구성 되짚기

실제 운영 코드와 state, 배포 기록에 남은 리소스 소유권과 구현의 한계

  1. 하나에서 세 개로 나눈 Terraform 한 main.tf에 쌓인 서버, 복구와 백업 설정을 배포 단위가 다른 세 작업 디렉터리로 다시 작성한 과정
  2. 서버, 복구, 백업을 따로 배포한 Terraform 서버, 복구 함수와 백업 정리를 각각 plan하고 apply하도록 세 작업 디렉터리로 나눈 실제 구성
  3. VM metadata와 startup script의 배포 계약 Terraform 입력이 부팅 시점의 파일과 systemd 서비스가 되던 경로와 소비 코드가 없던 값들
  4. ZIP 배포와 Terraform import 기록 배포 묶음과 state가 이미 존재하던 Google Cloud 리소스를 이어받은 순서
  5. 세 작업 디렉터리에 겹친 리소스 소유권 세 state에 중복으로 올라간 리소스와 이름으로만 이어진 연결
  6. HCL, state, metadata와 ZIP으로 퍼진 비밀값 변수 기본값 한 줄이 여섯 곳으로 복제된 경로와, 이력 재작성이 되돌리지 못한 범위
  7. 2025년 Terraform에서 현재 구성으로 옮기는 순서 현재 다시 선택할 제품 설정과 당시 설계 결함을 나누고, 되돌릴 수 있는 이전 경로를 고르는 기준