[Terraform] 테라폼에서 사용할 코드 케이스 정해보기

Intro

프로그램 코딩을 하기전에 코드 케이스를 정하는데요. 일반적으로 Application Architecture 분들이 잡아주는 표준을 사용하곤 합니다.

자바 개발자들에게 물어보니 대부분 카멜 케이스를 사용 한다고 하더라구요. (혹시 이유를 아시는 분 계시면 알려주세요) 참고로 고랭에서도 카멜 케이스를 쓴다고 합니다.

참고로 프로그램 코드 케이스 스타일 종류는 크게 4가지가 있고 자세한 내용은 아래링크를 참고 바랍니다.

프로그램 코드 케이스 스타일 종류(카멜,스네이크,케밥,파스칼)

우리 DevOps 담당자 분들도 테라폼 코딩하기전에 표준을 정해야겠죠. 어떤 코드 케이스를 사용하면 좋을까요? 오늘은 간략히 테라폼 코딩을 할때 어떤 케이스를 사용해야할지 고민했던 내용을 공유해보고자 합니다.

테라폼은 무슨 언어?

테라폼은 하시코프 설정 언어HCL, Hashicorp Configuration Language을 사용해 클라우드 리소스를 선언 합니다.

하시코프 설정언어는 어떤 케이스를 사용할까?

테라폼 코드를 작성할때 테라폼 문서를 자주 사용하게 될텐데요. 공식 문서에 있는 소스코드들은 어떤 케이스를 사용하고 있는지 확인 해보겠습니다.

아래 AWS IAM Role을 생성하는 예시를 보면 "aws_iam_role" 부분이 테라폼에서 정의하는 리소스 명 이름인데요. 스네이크 케이스를 사용하고 있습니다.

그 옆에 test_role 이 소스코드에서 사용할 리소스 이름 입니다. 얘도 스네이크 케이스네요. 그안에 name 은 실제 리소스 이름입니다. 얘도 스네이크 케이스네요.

resource "aws_iam_role" "test_role" {
  name = "test_role"

  # Terraform's "jsonencode" function converts a
  # Terraform expression result to valid JSON syntax.
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Sid    = ""
        Principal = {
          Service = "ec2.amazonaws.com"
        }
      },
    ]
  })

  tags = {
    tag-key = "tag-value"
  }
}

참고 URL : https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/iam_group

그런데 어떤 예제에는 케밥형으로도 사용하는 걸 확인할 수 있습니다만 대부분 스네이크 케이스를 사용합니다.

data "aws_iam_policy_document" "instance-assume-role-policy" {
  statement {
    actions = ["sts:AssumeRole"]

    principals {
      type        = "Service"
      identifiers = ["ec2.amazonaws.com"]
    }
  }
}

resource "aws_iam_role" "instance" {
  name               = "instance_role"
  path               = "/system/"
  assume_role_policy = data.aws_iam_policy_document.instance-assume-role-policy.json
}

그러면 그냥 모두 스네이크 케이스로 통일 하면되겠네? 라고 표준을 정해 놓고 코딩을 시작하면 됩니다.

하지만 다양한 담당자들의 의견을 모아모아 더 좋은 방향이 있을지는 고민해봐야겠죠. (이 부분은 아주 아주 사소하지만 아주아주 중요한 것 같습니다.)

스네이크 케이스의 장점

스네이크 케이스를 사용했을 경우의 장점은 우선 테라폼 공식 문서의 예제가 대부분 스네이크 케이스로 되어있어서 조금더 익숙하다 라는 장점있겠고, 가장 큰 장점중 하나는 더블클릭을할때 전체 선택이 된다는 점입니다. 예를들어 hello-world 라고 케밥형을 사용하면 전체 선택이 안되지만 hello_world 라고 스네이크 형을 쓰면 전체 선택이 됩니다. (와.. 나만 몰랐나?)

케밥 케이스의 장점

개발자분들에게 물어보니 케밥 케이스를 사용하는 경우는 api를 선언할때 사용하는데 보통 상하위 개념으로 표기한다고 합니다. 이런식이죠 동물-표유류-고양이과-사자

저도 AWS리소스의 Name Tag 규칙을 사용할때 회사명-환경명-리소스명-서비스명 으로 주로 사용하는데요. 개발자분들이 api표준을 정할때와 비슷하게 상하위 개념을 갖고 있습니다.

이 케밥 케이스의 가장 큰 장점은 가시성에 있습니다. 사람이 눈으로 볼때 한번에 확인하기가 좋다는 장점이 있습니다. 대부분 클라우드 담당자들은 각 CSP사에서 제공하는 웹 관리 콘솔을 사용합니다. 이 웹화면을 눈으로 보면서 리소스를 확인하는 경우가 많은데요. 이때 가시성이 높은 케밥형을 사용하는게 유리하겠죠.

결론

그래서 결론은 스네이크 케이스와 케밥케이스를 혼합하여 사용하자 입니다. 예를들어 아래와 같이 말이죠. 중괄호 {}안에 있는 name 은 실제로 웹 관리 콘솔에서 보여질 이름입니다. 따라서 이부분만 케밥케이스로 하고 소스코드에서 실제로 자주 사용하게된 리소스 네임 "test_role" 은 스네이크로 가자로 정하였습니다.

resource "aws_iam_role" "test_role" {
  name = "test-role"

#..omit..
}

여러분들은 프로그램 코딩할때 어떤 케이스를 사용하시나요? 그리고 그 이유는 무엇인가요? 오늘 주변 동료들과 이야기 해보시면 재미있는 토론이 될것 같습니다.