home..

테라폼 기본 state 실습하기

October 2023 (936 Words, 6 Minutes)

HLC Hashicorp Infra Gasida Cloud@net IaC Terraform

형상관리 도구

Git이 대표적인 형상관리 도구의 일종으로 소프트웨어의 변경 사항을 효과적으로 관리하고 추적하는 데 도움을 주는 도구입니다.

Untitled

대표적으로 다음과 같은 flow를 가집니다.

테라폼 클라우드

Terraform Cloud (TFC)는 HashiCorp에서 제공하는 Terraform의 호스팅된 서비스 버전입니다. Terraform은 인프라스트럭처를 코드로 작성하고 관리하는 도구로, 여러 클라우드 서비스 제공자와 통합되어 작동합니다. TFC는 이 Terraform을 사용하여 클라우드 리소스를 관리하기 위한 중앙 집중화된 워크스페이스를 제공합니다.

Untitled

가격정책

  • https://app.terraform.io/ 링크 접속 후 하단에 free account 클릭 → 계정 생성 후 이메일 확인 → 암호 입력 후 로그인
  • TFC 초기 설정 화면 → 사용자의 고유 조직 이름 생성 : montkim-org

Untitled

  • CLI 환경에서 TFC 사용을 위한 자격증명

      # 
  **terraform login**
  **yes** 입력
    • TFC 신규 창 → TFC 토큰 생성

    Untitled

      # 
  **terraform login**
  **yes** 입력
  ...
  Terraform will store the token in plain text in the following file
  for use by subsequent commands:
      /Users/gasida/.terraform.d/credentials.tfrc.json
    
  Token for app.terraform.io:
    **Enter a value**: ***<자신의 토큰 입력>***
  ...
    
  # 토큰 확인
  **cat ~/.terraform.d/credentials.tfrc.json | jq**

    token 값을 넣어 로그인을 완료합니다.

    Untitled

    해당 저장소에서 아래 조건에 만족하는 코드를 작성

    조건

    • Terraform Cloud를 상태 저장 백엔드로 설정합니다.
      • 워크스페이스의 이름은 terraform-edu-part1-assessment입니다.
      • 실행 모드는 local입니다.
    • AWS에 공통 태그로 Project = “workshop”을 설정합니다.
    • aws_instance를 반복문을 사용하여 3개 생성합니다.
    • EIP는 삭제하고, EC2에서는 직접 공용 IP를 사용하도록 설정합니다.
    • 세 개의 placeholder 변수를 사용하여 각각의 aws_instance에 다음 웹사이트 URL을 적용합니다:
      • placekitten.com
      • placebear.com
      • placedog.net
    • ‘example’ 브랜치에 풀이 예제가 있습니다. 조건에 따라 작성한 코드와 비교하면서 더 효과적인 방법을 찾아봅니다.
      • 반복문에서는 count와 for_each를 사용할 수 있습니다.
      • Terraform 모듈을 사용하는 방법도 고려해볼 수 있습니다.
      1. TFC를 State 백엔드로 구성 test example 코드 받기
        git clone https://github.com/terraform101/terraform-aws-tfc-workflow
      • workspace 이름 : terraform-edu-part1-assessment
        terraform {
    cloud {
      organization = "montkim-org"             # 생성한 ORG 이름 지정
      hostname     = "app.terraform.io"      # default
        
      workspaces {
        name = "terraform-edu-part1-assessment" # 없으면 생성된다.
      }
    }
      1. AWS Tag : Project = “workshop”
        provider "aws" {
    region = var.region
    default_tags {
      tags = {
        Project = "workshop"
      }
    }
  }

      terraform init, plan이 완료되면 접속주소가 생성됩니다.

      Untitled

      해당 주소로 접속하면 귀여운 고양이가 보입니다.

      Untitled

      # 워크플로우 (Workflow)

      Terraform은 인프라 관리를 위한 주요 워크플로를 갖추고 있습니다. 기본적으로 작성(Write) → 계획(Plan) → 적용(Apply)의 세 가지 주요 단계로 구성되어 있습니다.

      ### 개인 Terraform 워크플로

      1. 작성(Write):
        • 인프라 구축을 위한 Terraform 코드를 준비합니다.
          • 재사용 가능한 코드를 작성합니다.
          • 입력 변수를 통해 유연성을 확보하고, 반복이 필요한 구조에는 반복문 또는 모듈화를 고려합니다.
      2. 계획(Plan):
        • 구성 변경사항을 미리 확인하고 코드의 형식과 보안을 검토합니다.
          • terraform fmt로 코드 스타일을 통일합니다.
          • tfsec나 terrascan 같은 도구로 코드의 보안 취약점을 검사합니다.
      3. 적용(Apply):
        • 준비된 코드를 실행하여 실제 인프라를 생성 또는 변경합니다.
          • 코드의 실행 계획은 문제가 없을지라도, 실제 적용 시 다양한 문제점이 발생할 수 있습니다.
          • 문제가 발생하면 작성 > 계획 > 적용 순서로 다시 작업합니다.
          • 성공적인 실행 후, 코드의 변경사항은 버전 관리 시스템(VCS)에 저장합니다.

      ### 다중 작업자용 Terraform 워크플로

      1. 작성(Write):
        • VCS를 활용하여 여러 작업자간의 코드 충돌을 방지합니다.
        • 원격 저장소에서 최신 코드를 받아와서, 깃 브랜치를 통해 개별적으로 작업합니다.
        • 코드에 민감한 정보(비밀번호, 인증서 등)를 포함시키지 않습니다.
        • 개인적인 변수는 공유하지 않으며, 깃의 .gitignore에 추가합니다.
        • 작은 단위로 코드 작성을 반복하며, 각 단계에서 테스트를 수행합니다.
        • 운영 환경에서의 안정성을 위해 작업 환경과 실행 환경을 분리합니다.
        • 환경의 구조화에 디렉터리 기반 격리나 깃 브랜치 기반의 격리를 사용합니다.
      2. 계획(Plan):
        • 코드 변경 사항을 팀원과 함께 검토하고 공유합니다.
        • 코드 리뷰를 통해 변경 내용을 확인하며, Terraform Plan 결과를 함께 검토합니다.
        • 풀 리퀘스트 단계에서 코드와 Plan 결과를 함께 제공하여 예측을 강화합니다.
        • 필요에 따라 CI 도구나 Terraform Cloud/Enterprise와의 연계를 고려합니다.
      3. 적용(Apply):
        • 최종 코드를 병합하고, 해당 인프라의 변경 사항을 팀원에게 알립니다.
        • 중요도나 변경 사항의 성격에 따라 승인 과정을 거칠 수 있습니다.
        • 관리 단위를 결정할 때는, 조직의 역할, 서비스 유형, 인프라 유형 등을 고려합니다.

      ### 다수 팀의 테라폼 워크플로:

      • 분리된 R&R을 가진 여러 팀이나 조직에서는 프로비저닝 대상은 같으나, 관리하는 리소스가 서로 분리됩니다.
      • 각 팀은 자신의 워크플로를 유지하면서 결과를 다른 팀과 공유해야 합니다.
        1. 작성(Write):
        • 각 워크스페이스는 R&R에 따라 분리됩니다.
        • 각 팀은 저장된 State를 통해 리소스 데이터를 공유하며, 필요한 데이터는 output을 통해 노출됩니다.
        • 다른 워크스페이스의 변경 사항을 terraform_remote_state나 별도의 KV-store로 받아옵니다.
        • 변경의 영향을 최소화하기 위한 기본값 설정과 보상 로직이 필요합니다. 2. 계획(Plan):
        • 각 팀은 VCS 기반의 코드 리뷰를 통해 다른 팀의 변경 사항을 확인합니다.
        • 영향을 받는 모든 팀의 승인이 필요합니다. 3. 적용(Apply):
        • 프로비저닝의 실행과 결과는 파이프라인을 통해 자동화하며, 관련 팀에게 안내됩니다.
        • 변경의 영향 범위가 넓을 경우 롤백 준비가 필요합니다.
        • 다른 워크스페이스에서 참조되는 output 값의 권한 관리와 업데이트 확인이 필요합니다.

      ## 격리구조

      • State를 분리하여 여러 모듈이나 하위 모듈이 동일한 State를 공유하지 않게 하는 것.

      키 포인트:

      1. 모놀리식 vs MSA: 초기에는 테라폼이 모놀리식 방식을 선호할 수 있지만, 유지 보수와 확장성 측면에서는 MSA 방식이 더 적합합니다.
      2. 루트 모듈 격리: 각각의 기능이나 리소스를 독립적으로 관리하고 실행하기 위함.
        • 기본 구조:
          • 테라폼은 기본적으로 하나의 루트 모듈에서 여러 파일이나 하위 모듈을 통합하고 하나의 State로 관리.
          • 리소스 간의 의존성이나 관련성에 따라 여러 루트 모듈로 분리.
      3. 환경 격리:
        • 서비스의 각 단계(개발, 검증, 운영 등)마다 리소스의 독립성을 보장하며, 각 환경의 안정성과 격리를 위함.
        • 깃 브랜치 활용:
          • 각 환경마다 깃 브랜치를 구분하여 코드를 독립적으로 관리.
          • 브랜치 예시:
            • main: 운영 코드를 저장하며, 직접적인 변경을 수행하지 않음.
            • QA: 검증을 위한 코드를 저장.
            • DEV: 개발 및 기능 병합을 위한 코드를 저장.
            • feature: 새로운 리소스나 기능의 추가와 구현을 위한 코드를 저장.
          • 환경마다 깃 브랜치를 변경하여 작업하면 실수를 줄일 수 있음.
          • 디렉터리 격리: 환경마다 디렉터리를 구분하더라도 동일한 깃 저장소의 브랜치별 리모트 구성을 사용하여 환경 간 코드 동기화 및 일관성 유지.
      4. 동일 깃 저장소의 브랜치별 리모트 구성: 작업자가 여러 환경을 관리할 때, 각 환경별로 동일한 깃 저장소의 브랜치별 리모트 구성을 사용하는 것이 권장
© 2024 mont kim   •  Powered by Soopr   •  Theme  Moonwalk