Terraform 프로젝트: 섹션 1 - 위대한 모듈 구축

지형
저는 Terraform을 몇 주 동안 사용했습니다. 지금까지 Terraform의 업무 방식에 대해 인상이 깊었습니다.나는 이전의 인프라 시설을 CDK에서Terraform으로 바꾸어 왔지만, 내 프로젝트 폴더가 좀 어지럽다는 것을 발견하기 시작했다.나의 최초의 계획은 모든 AWS 계정에git repo가 있고 모든 서비스에는 단독 파일이 있다는 것이다. 예를 들어 다음과 같다.

terraform-prod/
|── main.tf
|── iam.tf
|── route53.tf
└── s3.tf

그러나 나는 이런 구조 아래에서 모든 문서가 붐비고 조리가 없다는 것을 발견했다.예를 들어 route53.tf 파일은 나의 모든 영역과 기록을 가득 채웠다.
나는 나의 프로젝트를 위해 더 좋은 포석을 찾으러 간다.나는 내가 찾았다고 생각한다.

더욱 모듈화된 지형 방법

마이그레이션의 일부로 Terraform 모듈을 만들었지만, 같은 모듈화 방법이 내 계정 코드 라이브러리에 적용될 수 있다는 것을 깨닫지 못했다.내가 선택한 레이아웃을 살펴보자.

terraform-prod/
|── main.tf
|── outputs.tf
└── modules
     └── blog_systemsmystery_tech
     | |── main.tf
     | └── outputs.tf
     └── dns
     | |── main.tf
     | └── outputs.tf
     └── ses
          └── main.tf

이 예에서 나는 일반적인main.tf과outputs.tf가 있지만 이번에는 이 블로그를 위해modules 폴더를 만들었는데 그 중에서 세 개의 서브 모듈, 내가 필요로 하는 모든 DNS 기록과 나의 SES 설정을 포함한다.본 블로그의 나머지 부분에서, 나는 내가 어떻게 나의 블로그 모듈을 조직했는지 되돌아볼 것이다.

그것을 분해하다

내 모듈에는 다음과 같은 구조가 있다.

blog_systemsmystery_tech/
|── iam.tf
|── lightsail.tf
|── main.tf
|── modules.tf
|── outputs.tf
|── README.md
└── route53.tf

나는 이 문서들의 용도를 상세하게 분석할 것이다.

국제 기계사 협회.tf

나는 iam.tf 내가 필요로 하는 모든 IAM 관련 프로젝트를 사용한다.일반적으로 이러한 모듈은 부팅되는 내장 모듈aws_iam_입니다.예를 들어 저는 SES를 사용하여 블로그를 통해 보내야 할 전자메일을 마운트 해제합니다. 따라서 IAM 사용자, 액세스 키와 정책을 사용하여 블로그가 SES 서비스에 접근할 수 있도록 해야 합니다.먼저 IAM 사용자를 만들었습니다.

resource "aws_iam_user" "wordpress_ses_user" {
  name = "blog_ses_user"
}

그리고 키베이스를 사용하여 접근 카드를 만듭니다. 암호화된 비밀을 제공합니다.

resource "aws_iam_access_key" "wordpress_ses_user_access_key" {
  user = aws_iam_user.wordpress_ses_user.name
  pgp_key = "keybase:a_keybase_user"
}

마지막으로 AWS 관리AmazonSESFullAccess 정책을 사용자에게 첨부합니다.

resource "aws_iam_policy_attachment" "wordpress_ses_policy_attachment" {
  name = "wordpress_ses_policy_attachment"
  users = [aws_iam_user.wordpress_ses_user.name]
  policy_arn = "arn:aws:iam::aws:policy/AmazonSESFullAccess"
}

이제 IAM 사용자 설정이 있으므로 액세스 키의 출력이 필요합니다.이를 위해 outputs.tf 파일을 사용하고 액세스 키와 암호화 키의 출력을 정의합니다.

output "wordpress_ses_user_iam_access_key" {
  value = aws_iam_access_key.wordpress_ses_user_access_key.id
  description = "Wordpress SES user access key ID."
}

output "wordpress_ses_user_iam_encrypted_secret" {
  value = aws_iam_access_key.wordpress_ses_user_access_key.encrypted_secret
  description = "Wordpress SES user encrypted secret."
}

보시다시피 모든 파일이 하나의 모듈에 포함되어 있기 때문에 iam.tf 파일(또는 다른 파일)에 정의된 모든 내용을 인용하여 출력을 만들 수 있습니다.이 예에서 나는 aws_iam_access_key.wordpress_ses_user_access_key 대상을 인용한 다음에 id와 encrypted_secret를 사용하여 필요한 값을 얻었다.

돛.tf

나의 다음 파일은 나의 모든 Lightsail 인프라를 포함한다.Terraforms에서 Lightsail 실례를 만드는 능력은 내가 그것을 사용하기로 결정한 관건적인 구동 요소 중 하나이다.먼저 Lightsail 인스턴스를 만듭니다.

resource "aws_lightsail_instance" "wordpress_instance" {
  name = "wordpress"
  availability_zone = "eu-west-2b"
  blueprint_id = "wordpress"
  bundle_id = "nano_2_0"
}

이 실례를 만들 때 두 가지를 주의해야 한다. 첫 번째는 blueprint_id 이고, 두 번째는 bundle_id 이다.
명령줄에서 검색blueprint_id하려면 aws lightsail get-blueprints을 실행합니다.이것은 Lightsail이 지원하는 모든 현재 청사진을 되돌려줍니다.WordPress 청사진을 사용하고 싶어서 목록을 살펴보니 다음과 같습니다.

{
   "blueprintId":"wordpress",
   "name":"WordPress",
   "group":"wordpress",
   "type":"app",
   "description":"...",
   "isActive":true,
   "minPower":0,
   "version":"5.4.2",
   "versionCode":"1",
   "productUrl":"https://aws.amazon.com/marketplace/pp/B00NN8Y43U",
   "licenseUrl":"https://d7umqicpi7263.cloudfront.net/eula/product/7d426cb7-9522-4dd7-a56b-55dd8cc1c8d0/588fd495-6492-4610-b3e8-d15ce864454c.txt",
   "platform":"LINUX_UNIX"
}

여기서부터 나는 blueprintId를 사용하고 나의 실례 대상에서 그것을 사용한다.bundle_id 사용할 인스턴스의 크기를 선택합니다.나에게 있어서 이것은 나노의 실례 유형이거나Terraform의 nano_2_0이다.aws_lightsail_instance 리소스의 Terraform 문서를 보면 이 값에 필요한 형식에 대한 더 많은 정보를 얻을 수 있습니다.
마지막 수수께끼는 실례에 할당하고 싶은 정적 IP 주소입니다.이렇게 하려면 먼저 정적 IP를 만들고 이름을 지정한 다음 위에서 만든 객체를 참조하여 인스턴스에 추가합니다.

resource "aws_lightsail_static_ip" "wordpress_static_ip" {
  name = "blog_systemsmystery_tech"
}

resource "aws_lightsail_static_ip_attachment" "wordpress_static_ip_attachment" {
  static_ip_name = aws_lightsail_static_ip.wordpress_static_ip.id
  instance_name = aws_lightsail_instance.wordpress_instance.id
}

모듈tf

이 프로젝트에 가져온 모듈에 단독 파일을 만들기로 결정했습니다.예를 들어 WordPress에서 나는 백업 플러그인을 사용하여 나의 모든 백업을 S3에 저장할 것이다.Home Assistant backups에 대한 게시물을 발표한 후에 write my own module를 만들기로 결정했습니다. 이 점을 실현하기 위해 모든 구성 요소를 만들 것입니다.만약 이것도 당신에게 도움이 된다면, 당신은 Terraform registry에서 나의 모듈을 찾을 수 있습니다.프로젝트에 이 모듈을 추가하여 새 리소스module를 만들고 필요에 따라 구성했습니다.

module "wordpress_backup_bucket" {
  source = "rj175/s3-backup-bucket/aws"
  version = "1.0.1"
  pgp_key = "keybase:a_keybase_user"
  service_name = replace(var.blog_domain, ".", "-")
}

너는 var.blog_domain에 대한 인용에 주의할 것이다.이것은 이 자원에 전달되는 변수다.이 변수들은 내 variables.tf 파일에서 찾을 수 있으니, 나는 뒤에서 토론할 것이다.

노선tf

내가 만들어야 할 마지막 인프라 구성 요소는 Route53의 DNS 기록입니다.이것은 lightsail.tf에 정의된 정적 IP 주소를 참조하고 다른 변수를 영역 ID로 사용합니다. 이 ID는 레코드를 만드는 데 사용됩니다.

resource "aws_route53_record" "wordpress_a_record" {
  name = "blog"
  zone_id = var.zone_id
  records = [
    aws_lightsail_static_ip.wordpress_static_ip.ip_address
  ]
  type = "A"
  ttl = 300
}

매인.tf

나의 주요 직책 범위 내에서.tf 파일, 지형과 관련된 모든 설정을 저장합니다.

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "3.18.0"
    }
  }
}

여기서, 나는 어떤 공급자가 필요한지 (이 프로젝트에 AWS가 필요한지), 그리고 내가 사용하고 싶은 버전을 정의했다.HashiCorp에서 공급자를 업데이트할 때 문제가 발생하지 않도록 제 버전을 잠갔습니다.main.tf 파일에서 나는 내가 필요로 하는 모든 변수를 정의했다.위에서 설명한 바와 같이, 내가 필요로 하는 유일한 변수는 백업 통의 서비스 이름과 지역 ID입니다.

variable "blog_domain" {
  description = "Domain name to use for blog."
  type = string
}
variable "zone_id" {
  description = "Zone ID to create DNS records in."
  type = string
}

너는 이 변수들이 값이 없다는 것을 알아차릴 것이다.이것은 이 모듈 이외의 항목의 맨 위에 정의됩니다.

결론

요컨대, 나는 이 프로젝트를 위해 로컬에서 모듈을 만들었는데, 이 블로그에 필요한 모든 구성 요소를 만들었다.다음 부분에서, 나는 당신에게 나의 주요 프로젝트에서 이 모듈을 어떻게 사용해서 생산에 배치할 준비를 하는지 보여 드리겠습니다.
다음까지 즐거운 코딩!