Windows, x509: certificate signed by unknown authority 오류 해결

윈도우즈(Windows) 에서 개발을 할때에 사설 인증서를 사용한 서버에 접속하게 되면 제목과 같이 인증서 오류가 발생한다. 사설 인증서를 사용한 서버에 인증을 위해서는 Root CA 인증서를 내장하고 있어야 한다. Root CA 인증서는 공개키를 가지고 있고 이를 사용해서 서버에 사설 인증서에 내장된 해쉬값과 인증서명을 해독한다.

인증서 추가

윈도우즈(Windows) 도 이제는 인증서를 시스템에서 다룬다. 과거에는 브라우져에서 다루었지만 이제는 시스템에서 통합해 다루도록 변경되었다.

인증서를 추가하는 방법은 다양하지만, certutil.exe 커맨드 라인을 사용하는게 쉽다. certutils.exe 는 인증서 추가는 물론 파일의 해쉬값도 구할 수 있는 기능도 있다.

다양한 인증서 추가

certutil.exe 를 이용하면 다양한 인증서를 추가할 수 있다. 여기서 다양한 인증서는 Root CA 인증서, Intermediate 인증서, Server 인증서를 말한다. 이것을 구분해서 certutil.exe 를 사용해야 한다.

Root CA 인증서 추가

다음과 같이 Root CA 인증서를 추가 할 수 있다.

RootCA 인증서 추가
ZSH
1
certutil.exe -addstore "Root" "Download\RootCA.crt"

Root CA 인증서는 각 브라우져에 탑재되어 있는 것으로 공개키가 내장되어 있다. 모든 인증서는 Root 인증기관에서 암호화를 하는데, 인증기관에서 인증된 모든 인증서는 인증기관의 Root CA 인증서로 해독이 가능해 진다.

사설 인증서 관련해서 x509: certificate signed by unknown authority 오류가 발생하는 것은 사설 인증서를 받아서 해독을 할 수 없는 경우임으로 Root CA 인증서를 가지고 있으면 해독이 가능해진다. 따라서 제목의 문제 해결은 Root CA 인증서를 추가하면 된다.

혹은 클라이언트 인증서를 활용해도 문제는 해결되지만, 시스템에 설치되는 인증서는 Root CA 인증서임으로 클리이언트 인증서는 특정 애플리케이션에서 활용된다.

인터미데이트 인증서 추가

인터미데이트 인증서는 루트 인증기관에서 인증한 중간의 인증기관에 배포되어 인증이된 인증서를 말한다. 인증서는 3단계 인증서가 존재하는데, 루트 인증기관의 루트 인증서, 중간자 인증기관의 인터미데이트 인증서, 최종적으로 사용자 인증서다.

루트 인증기관의 인증서는 인터미데이트, 사용자 인증서 모두를 해독할 수 있다. 인터미데이터 인증서가 만들어진 이유는 중간에 카테고리를 하나 더 둠으로 인해서 인증서 유출에 따른 파급력을 줄이려는 의도다. 모든 사용자 인증서를 루트 인증기관으로부터 인증을 받은 상태에서 루트 인증서가 유출되면 그 파급력은 매우 크게 된다. 이를 쪼개기 위한 방안으로 인터미데이트 인증서가 필요해졌다.

재미있는 것은 인터미데이트 인증서는 보통 Root CA, Server 인증서를 모두 가지고 있다. 파일을 열어보면 인증서가 3개가 담겨 있는 경우가 대부분이다.

인터미데이트 인증서 추가
ZSH
1
certutil -addstore "CA" "Download\Intermediate.crt"

사용자 인증서 추가

윈도우즈 메뉴얼에는 사용자 인증서라고 되어 있는데, 이게 클라이언트 인증서인지 서버 인증서인지는 모르겠다. 추가하는 방법은 다음과 같다.

사용자 인증서 추가
ZSH
1
certutil -addstore "My" "Download\user.crt"

로컬 머신 인증서 관리 코솔(Certificate Local Machine)

로컬 머신 인증서 관리 콘솔이 있다. certlm.msc 명령어를 이용하면 되는데, 관리자 권한을 요구한다. 이는 시스템 와이드 적용이 되는 것으로 전체 사용자에게 영향을 준다.

Root CA 인증서를 추가된 것을 확인해 볼 수 있다.

사용자 인증서 콘솔(Certificate Manager)

사용자 인증서 관리 콘솔이 있다. 이는 아마도 개인 계정 범위내에서 사용되는 것을 보인다. certmgr.msc 로 실행해 확인해 볼 수 있다.

인증서 삭제

인증서 삭제는 관리 콘솔에서 가능하다.

Gitlab, CI/CD 변수가 사용되지 않을때

Gitlab 에서 Settings -> CI/CD -> Variables 에서 CI/CD 에서 사용가능한 변수를 지정할 수 있다. 여기서 지정한 변수는 CI/CD 에서 활용되며 CI/CD 진행할때 운영체제의 환경변수로 자동 지정된다. 따라서 빌드시에 운영체제에 환경변수를 활용하고자 한다면 여기서 변수를 설정하면 된다.

AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY 등은 운영체제 환경변수로 지정하면 AWS API 통신이 가능해진다. 소스코드에 하드코딩하는 것보다야 낫다.

Merge Request Pipeline 에서 변수가 활용 불가 문제

그런데, Merge Request Pipeline 에서는 이 변수가 적용되지 않았다. TF_USERNAME 이 적용되어야 하는데, 적용되지 않았다.

이는 CI/CD 변수의 Protect 기능 때문이다. 위에 스크린샷을 보면 변수 아래에 Protected 라고 적혀 있다. Gitlab 문서에는 다음과 같이 기술 되어 있다.

Protect a CI/CD variable

You can configure a project, group, or instance CI/CD variable to be available only to pipelines that run on protected branches or protected tags.

Merged results pipelines, which run on a temporary merge commit, not a branch or tag, do not have access to these variables.
Merge request pipelines, which do not use a temporary merge commit, can access these variables if the branch is a protected branch.

이런 제약을 없애기 위해서는 Protect 를 해제 하면 되는데, 변수 설정에서 체크 박스를 해제하면 된다. 기본값은 체크박스 체크된 상태이다.

“Protect variabe” 체크를 해제해주면 된다. 이렇게 되면 protected branches, protected tags 가 아니여도 변수가 적용된다.

Gitlab, Docker 빌드시 x509: certificate signed by unknown authority 오류 해결

Gitlab 은 CI/CD 를 내장하고 있다. 이는 Gitlab-runner 를 통해서 이루어진다. gitlab-ci.yaml 파일을 이용해 CI/CD 명세를 작성하면 Gitlab-Runner 가 이 파일을 읽어 실행해 준다. Gitlab-Runner 에는 타입이 존재하는데, docker 로 할 경우에 Docker 를 이용해서 CI/CD 를 진행하게 된다. 다시말해서, Docker 를 이용해서 Container 안에서 빌드, 테스트, 배포가 이루어진다는 것이다.

Private Certificate

문제는 사설 인증서다. Docker 컨테이너내에서 외부 접속을 하기 위해서 HTTPS 통신이 필요한데, 하필이면 HTTPS 가 사설 인증서를 사용한 것이라면 다음과 같은 오류가 발생한다.

TLS 오류
ZSH
1
2
$ gitlab-terraform validate
Error refreshing state: Failed to get state: GET https://gitlab.systemv.local:8001/api/v4/projects/21/terraform/state/default giving up after 1 attempt(s): Get "https://gitlab.systemv.local:8001/api/v4/projects/21/terraform/state/default": x509: certificate signed by unknown authority

Docker 컨테이너 안이라 사설 인증서에 대한 인증서를 붙여놔야 하는데, 어떻게 해야하는 문제가 있다.

Self-signed certificates or custom Certification Authorities

다음의 Gitlab 문서에 이에 대한 내용이 나와 있다.

Self-signed certificates or custom Certification Authorities

문서가 조금 부족한 감이 있는데, 두가지 절차가 필요하다.

Gitlab-Runner 에 볼륨 마운트

Pipeline 에서 사용할 Gitlab-Runner 에서, 당연히 Docker 타입, 볼륨 마운트 설정을 해준다. 이 설정은 Docker 명령어의 -v 옵션과 동일하다. 볼륨 마운트를 할때에 ca.crt (Root CA 인증서) 파일을 마운트 해준다.

Gitlab-Runner 설정
YAML
1
2
3
4
5
6
7
8
  [runners.docker]
    tls_verify = false
    image = "maven:3.8.4-openjdk-8-slim"
    privileged = false
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/etc/docker/certs.d/regi.gitlab.systemv.local/ca.crt:/tmp/ca.crt","/cache"]

Pipeline 이 실행되고 Docker 컨테이너가 시작되면 설정한 볼륨을 마운트 해준다. 그러면 Docker 컨테이너 내에 /tmp/ca.crt 파일이 존재하게 된다.

이제 Docker 컨테이너에 ca.crt 파일을 설치해주면 된다.

gitlab-ci.yaml 에 job 내에 ca.crt 설치

이제 gitlab-ci.yaml 파일에 job 내에 ca.crt 를 설치해 준다. 다음과 같다.

ca.crt 설치
YAML
1
2
3
4
5
6
7
8
9
build:
  before_script:
    - apk update >/dev/null
    - apk add ca-certificates > /dev/null
    - rm -rf /var/cache/apk/*
 
    # The trick is the following:
    - cp /tmp/ca.crt /usr/local/share/ca-certificates/ca.crt
    - update-ca-certificates --fresh > /dev/null

위 내용은 Alpine 이미지를 사용할 경우, ca.crt 파일을 설치하는 방법을 기술한 것이다. 아래 두번째에 보면 Gitlab-Runner 설정에서 마운트 되었던, /tmp/ca.crt 파일을 Alpine 이 CA 설정 디렉토리로 복사해주고 있다.

이렇게 하면 build 단계에서 인증서를 설치하게 된다.

결론

Gitlab-Runner 를 사용하다보면 대부분 Docker 기반으로 빌드,테스트,배포를 하게 된다. Shell 타입도 Docker 기반일 경우에 별도의 프로그램 설치와 설정이 필요 없기 때문이다. 하지만 사설 인증서를 사용할 경우에 통신이 되지 않을 수도 있는데, 위와 같은 방법으로 해결 할 수 있다.

Git 브랜치 목록 동기화

Git 를 사용할때에 원격과 로컬의 브랜치를 동기화되서 동작한다. 그런데, 원격 브랜치를 삭제하고 난후에 로컬 브랜치를 보면 동기화 되지 않는다.

원격 branch 상태
ZSH
1
2
3
4
5
6
7
8
9
10
11
$ git branch -a
* main
  remotes/origin/1-git-ignore
  remotes/origin/HEAD -> origin/main
  remotes/origin/docker-ci
  remotes/origin/main
$ git branch -r
  origin/1-git-ignore
  origin/HEAD -> origin/main
  origin/docker-ci
  origin/main

위 예제를 보면 원격 브랜치가 여러개 보인다. 하지만 실제 원격 브랜치를 보면 main 빼고는 전부 삭제된 상태 이다. 이럴때는 다음과 같이 하면 된다.

원격 브랜치와 로컬 브랜치 동기화
ZSH
1
2
3
4
5
6
$ git fetch -p
Username for 'https://gitlab.systemv.local:8001': systemv
Password for 'https://systemv@gitlab.systemv.local:8001':
From https://gitlab.systemv.local:8001/infrateam/terraform_state
- [deleted]         (none)     -> origin/1-git-ignore
- [deleted]         (none)     -> origin/docker-ci

위와같이 로컬에 원격 브랜치 목록이 실제 원격 브랜치 목록과 동기화 되었다.

Gitlab 을 위한 opentofu 도커 이미지 제작

Gitlab 에서 사용할 opentofu 도커 이미지를 제작해보자. Gitlab 에서 Auto DevOps 를 이용할 경우에 Docker 이미지를 이용해서 Terraform 빌드, 배포 하는게 가능하다. 지금은 Terraform 을 위한 Docker 이미지만 존재하는데, Opentofu 를 위한 도커 이미지를 제작해서 사용할 수 있도록 이미지를 만들어 보자.

Dockerfile

Docker 빌드를 위해서 Dockerfile 이 있어야 한다. 다음과 같다.

Dockerfile
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
ARG BASE_IMAGE
 
FROM $BASE_IMAGE
 
RUN apk add --no-cache \
  curl \
  gcompat \
  git \
  idn2-utils \
  jq \
  openssh
 
 
# Install tofu from the alpine registry and symlink to terraform (for the utility script)
RUN apk add --no-cache opentofu --repository=https://dl-cdn.alpinelinux.org/alpine/edge/testing/ && \
    ln -s "$(which tofu)" /usr/local/bin/terraform && \
    terraform --version && \
    tofu --version
 
WORKDIR /
 
COPY gitlab-terraform.sh /usr/bin/gitlab-terraform
RUN chmod +x /usr/bin/gitlab-terraform
 
# Override ENTRYPOINT
ENTRYPOINT []

내용을 보면 gitlab-terraform.sh 스크립트 파일이 있어야 한다. 이 파일은 실제 Gitlab 을 이용해서 CI/CD 를 할 경우에 실제로 사용하게 되는 스크립트 파일이다.

Docker Build

Docker 빌드는 다음과 같은 명령어로 가능 하다.

Docker 빌드하기
ZSH
1
2
]$ docker build --build-arg BASE_IMAGE=alpine:3.19.0 --build-arg TOFU_BINARY_VERION=1.6.0_rc1-r0 -f Dockerfile -t systemv/opentofu-images:1.6.0_rc1 .
]$ docker push systemv/opentofu-images:1.6.0_rc1

빌드를 하고 난 후에 Docker Hub 에 푸쉬를 해줬다.

GitLab, Merge Request 일때만 Auto DevOps 되도록 하기

Gitlab 은 매우 강력한 툴이다. 이거 하나면 다 된다. 문제는 다루기가 여간 쉽지가 않다는데 있다. 많은 것을 알고 있는 상태라면 Gitlab 을 손댈 필요가 없지만 그것을 몰랐을 때에는 예기치 않은 반응과 결과를 보게 된다.

Gitlab 은 CI/CD Pipeline 을 지원하는데, 이에 대한 설정은 Auto DevOps 에서 하게 된다. 정확하게 말하면 CI/CD Pipeline 을 Auto DevOps 라고 부른다고 이해해도 된다. 각 프로젝트 마다 Auto DevOps 설정이 존재한다. 이 설정의 기본은 다음과 같다.

“Default Auto DevOps pipeline” 이 체크되어 있는데, 아래 설명에 따라 별도의 CI 설정이 없을 경우에 Auto DevOps 를 실행한다는 의미다. 이 말은 저장소에 .gitlab-ci.yaml 파일이 존재할 경우에 무조건 실행 된다는 것을 의미한다.

이렇게 되면 CI/CD 를 실행하는데 있어서 조건을 달 수가 없다. 그래서 많은 사람들이 별도의 메뉴로 존재하는 줄 알고 열심히 찾아보지만 그런거 없다. 그러다보니 Gitlab 을 사용하면서 당황하게 된다. “나는 main(혹은 master) 브랜치를 기반으로 배포를 하고 싶은데, Gitlab 은 그냥 아무 브랜치에 push 만 되면 그냥 실행 된다… 별로 안좋네..” 이런 식으로 결론이 난다.

workflow

Gitlab 은 Auto DevOps (혹은 CI/CD) 관련해서는 .gitlab-ci.yaml 파일에서 모두 처리할 수 있도록 했다. 특정 조건에 맞게 실행되도록 workflow 라는 문법을 지원 한다. 예를들면 다음과 같다.

gitlab-ci
YAML
1
2
3
4
5
6
workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS
      when: never
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

위 예제는 merge request 가 발생하거나 기본 브랜치에 push 가 발생하면 동작하도록 규칙(rule)를 정의한다. 위 예제 내용을 .gitlab-ci.yaml 맨 위에 적어놓게 되면 된다.

아니면 다음과 같은 예제도 있다.

workflow 예제2
YAML
1
2
3
4
5
workflow:  
    rules:
      - if: $CI_COMMIT_BRANCH != "main" && $CI_PIPELINE_SOURCE != "merge_request_event"
        when: never
      - when: always

commit branch 가 main (main 은 Gitlab 의 기본 브랜치) 도 아니고 파이프라인 소스가 merge request 도 아니면 CI/CD 를 실행하지 말라는 예제다.

rules

여기서 한가지 짚고 넘어가면, rules 다. rules 는 반드시 workflow 에서만 사용되는게 아니다. 각 stage 마다 사용 될 수 있다. 다음의 예제입니다.

rules 예제
YAML
1
2
3
4
5
6
7
8
9
10
.terraform:fmt:
  stage: validate
  script:
    - gitlab-terraform fmt
  allow_failure: true
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_OPEN_MERGE_REQUESTS  # Don't add it to a *branch* pipeline if it's already in a merge request pipeline.
      when: never
    - if: $CI_COMMIT_BRANCH        # If there's no open merge request, add it to a *branch* pipeline instead.

terraform 를 위한 gitlab-ci 예제 중 일부 입니다. stage 단계에서 rules 를 설정해서 사용하고 있다는 것을 알 수 있습니다.

Gitlab 으로 terraform 상태(state) 관리하기

Terraform 을 여러명이 사용할때에 필요한 것이 Terraform 의 상태를 변경하지 못하도록 하는 것이다. terraform 을 실행할때마다 상태(state) 파일이 갱신되는데, 여러사람이 같이 일을 할때에는 이 파일을 공유해서 사용해야 한다.

대부분이 terraform state 파일을 AWS S3 저장소와 Dynamo DB 를 이용해 lock 을 거는 방식이 많이 거론된다. 이 방법은 AWS 클라우드를 사용해야 한다는 강제가 필요한데, 물론 Terraform 이 클라우드를 빠르게 코드로 만들도록 도와주기 때문에 어짜피 AWS 클라우드 인프라를 구성할 거면 S3 를 사용하는 것이 문제가 되지 않는다.

또, 인터넷상에 보면 Gitlab 을 이용한 상태관리 관련한 문서, 심지여 Gitlab 의 공식문서조차도 잘못된 내용이 있어 이 글을 작성한다.

하지만 꼭 AWS S3와 DynamoDB 를 이용해야만 가능하냐 하는 질문에는 그렇지 않다는 답이 존재한다. 이 문서는 AWS 클라우드 서비스를 이용하지 않고 Gitlab 을 이용해 Terraform 의 상태(state) 파일을 관리하는 방법에 대해서 알아 본다.

GitLab

매우 훌륭한 시스템이다. 소스코드 저장소는 물론이고 Container Registry, Terraform state 저장소, CI/CD, Wiki, Ticket 시스템등 거의 모든 IT 업무를 한곳에서 수행할 수 있게 해준다.

Terraform state 파일 저장소를 네이티브 기능으로 사용할 수 있도록 만들어져 있어서 이걸 이용하면 클라우드 저장소의 도움 없이도 Terraform 의 상태 파일을 관리 할 수 있다.

저장소 생성하기

Terraform 상태 파일 저장을 위한 저장소를 만들어 준다.

Terraform 상태 파일을 저장하기 위한 저장소 생성

Gitlab 에서 저장소 생성은 단순한 절차임으로 큰 어려움 없이 생성이 된다.

Terraform 파일 작성

간단하게 Terraform 파일을 작성해 보자. provider 와 backend, 그리고 AWS Resource 중에 Security Group 하나를 만들어 보자. 파일은 main.tf 와 backend.tf 두개로 작성 됐다.

main.tf

main.tf
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
provider "aws" {
  access_key = ""
  secret_key = ""
  alias = "seoul"
  region = "ap-northeast-2"
}
 
resource "aws_security_group" "terraform-example-sg" {
 
  provider = aws.seoul
 
  name = "terraform-example-sg"
 
  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
 
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
 
}

backend.tf

backend.tf
TypeScript
1
2
3
4
5
6
7
8
9
10
11
terraform {
 
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
  
  backend "http" {}
}

위 코드를 보면 변수 3개가 보인다. $PROJECT_ID 는 Gitlab 에 프로젝트 Settings -> General 을 보면 번호가 부여된 Project ID 를 알 수 있다.

API 통신을 위해서 인증 토큰이 필요하다. 공식문서에는 사용자 계정 토큰을 발행하라고 되어 있다. 사용자 계정 토큰은 사용자 Profile -> Access Tokens 에서 생성이 가능하다.

하지만, 여기서 한가지 주의해야 할게 있다. 인터넷을 검색해보면 개인 토큰으로는 인증 실패가 발생한다고 하는데, API 통신을 위해서는 Maintainer 권한을 필요로 한다. 그러니까 계정의 권한이 Maintainer 를 가지고 있지 않는다면 토큰을 발행이 되어도 인증에 실패하게 된다.

Gitlab 에서 API 통신을 위해서는 적절한 권한을 필요로하게 되는데, Maintainer 권한이 필요하게 된다. 이 말은 Access Tokens 은 Maintainer 권한만 있다면 사용자 구분 없이 사용이 가능하게 된다.

그러면, 프로젝트 Access Tokens 을 이용할 수 있지 않을까? 당연히 가능 하다. 앞서 생성한 프로젝트 -> Settings -> Access tokens 에서 토큰 발생이 가능하다. 프로젝트 토큰 발생은 사용자도 함게 생성되는데, 그 사용자는 bot 이다.

한가지 주의해야 할 것은 프로젝트 access token 을 생성할때에 권한(role) 을 Maintainer 권한으로 해야 한다. 그리고 이렇게 생성을 하게 되면 bot 계정이 생성이 되는데, 이 계정이 access token 소유자가 된다.

이 계정의 Id 는 @ 로 시작하는 문자열이다.

어떤 Access Tokens 을 사용해도 상관은 없다. 핵심은 권한(Role) 이다. 반드시 Maintainer 권한이 있어야 한다.

Terraform init

이제 Terraform 을 초기화 한. 초기화는 다음과 같은 명령어를 사용 한다.

terraform init
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
export TF_USERNAME=project_21_bot_213a2c1faa436d68d8984837afaa3460
export TF_PASSWORD=glpat-92txtMPCAK-gnbWvrC7C
export TF_STATE_NAME=default
export PROJECT_ID="21"
export TF_ADDRESS="https://gitlab.systemv.local:8001/api/v4/projects/${PROJECT_ID}/terraform/state/${TF_STATE_NAME}"
 
terraform init \
    -backend-config="address=${TF_ADDRESS}" \
    -backend-config="lock_address=${TF_ADDRESS}/lock" \
    -backend-config="unlock_address=${TF_ADDRESS}/lock" \
    -backend-config="username=$TF_USERNAME" \
    -backend-config="password=$TF_PASSWORD" \
    -backend-config="lock_method=POST" \
    -backend-config="unlock_method=DELETE" \
    -backend-config="retry_wait_min=5"

TF_USERNAME 은 Project Access Token 소유자인 bot 이고 TF_PASSWORD 는 Project Access Token 이다.

terraform plan

이 명령어를 실행하면 드디어 Gitlab 저장소에 Terraform state 에 상태 파일이 생성된다. Operate -> Terraform states 에서 확인이 가능하다.

결론

인터넷을 살펴보면 Gitlab 을 이용한 Terraform state 관련 내용에서 Personal Access Token 으로 되지 않는다는 내용이 많다. 핵심은 Access Token 의 권한이다. 반드시 Maintainer 권한이 있어야 하며 이 권한만 있다면 Personal 이던 Project 이던 상관이 없다.

Terraform 을 위한 VSCode 세팅

VSCode 에서 Terraform 을 사용하기 위한 세팅은 다음과 같다.

필요한 Extensions

  • HashiCorp Terraform
  • IntelliCode
  • Prettier – Code formatter

위와같은 Extensions 들을 설치하면 Terraform 을 사용하기가 편하다.

사용자 설정

Terraform 을 위한 사용자 설정은 다음과 같다.

Terraform 을 위한 사용자 설정
JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
    "terraform.languageServer.path": "D:\\Terraform\\terraform.exe",
    "[terraform]": {
        "editor.formatOnSaveMode": "file",
        "editor.formatOnSave": true,
        "editor.defaultFormatter": "hashicorp.terraform",
        "editor.tabSize": 2, // optionally
    },
    "[terraform-vars]": {
        "editor.formatOnSave": true,
        "editor.defaultFormatter": "hashicorp.terraform",
        "editor.formatOnSaveMode": "file",
        "editor.tabSize": 2 // optionally
    }

위 설정은 Prettier – Code formatter 가 설치되어 있어야 한다.

Kafka 설치하기

이벤트 스트림을 제공하는 브로커 이다. 더블어 메시지 스트림도 지원한다. Scala 로 제작되었으며 JVM 위에서 동작한다. 따라서 Java 가 있어야 한다.

환경

서버는 3대로 준비했다. Production 에서는 적어도 3대의 Broker 를 권장대로 설치한 것이다. 서버 3대는 다음과 같다.

  • klab-master1.systemv.local(192.168.96.60)
  • klab-worker1.systemv.local(192.168.96.61)
  • klab-worker2.systemv.local(192.168.96.62)

배포판은 Rocky Linux 9.3 최신 버전이다.

요구사항

Apache Kafka 를 실행하기 위해 JVM 이 필요하다. Kafka 버전에 따라서 Java 버전도 선택해야 한다. 최신의 Kafka 는 Java 11 을 필요로 한다.

Java 11 을 설치는 패키지로 설치 했다.

Java 설치
ZSH
1
sudo dnf install java-11-openjdk-headless.x86_64

Kafka 다운로드 및 설치

Apache Kafka 는 AWS 의 MSK 에 버전과 동일하게 선택했다.

Kafka 다운로드
ZSH
1
curl -LJO https://downloads.apache.org/kafka/3.5.2/kafka_2.13-3.5.2.tgz

다음과 같이 /app 디렉토리에 압축해제로 설치를 완료 한다.

Kafka 설치
ZSH
1
2
3
4
sudo tar xvzf kafka_2.13-3.5.2.tgz -C /app
cd /app
sudo chown -R systemv: kafka_2.13-3.5.2/
sudo ln -s /app/kafka_2.13-3.5.2 kafka

Zookeeper 설정

kafka 에 zookeeper 가 내장되어 있다. 설정은 /app/kafka/config 디렉토리에 zookeeper.properties 파일이다. 다음은 예시다.

Zookeeper 설정
INI
1
2
3
4
5
6
7
8
9
10
11
12
13
# zookeeper.properties
tickTime=2000       # 다른 zookeeper 의 heartbeats 시간으로 millisec                          
dataDir=/app/kafka/data/zookeeper   # 데이터 디렉토리. dataLogDir 를 정의하지 않으면 이 디렉토리에 로그도 함께 쌓인다.
clientPort=2181     # client 접속을 받기 위한 포트. Broker 의 접속을 받기 위한 포트
maxClientCnxns=60   # client 의 접속을 받을 수 있는 최대 접속개수. 기본값 60, unlimited 는 0 이다.
initLimit=20
syncLimit=5
# server.<myid> = <hostname>:<leaderport>:<electionport>
server.1=klab-master1.systemv.local:2888:3888  
server.2=klab-worker1.systemv.local:2888:3888
server.3=klab-worker2.systemv.local:2888:3888
 
admin.enableServer=false

systemd Unit을 작성해서 관리한다.

Zookeeper 의 systemd unit 파일
INI
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
[Unit]
Description=Zookeeper Daemon
Documentation=https://zookeeper.apache.org
 
Requires=network.target remote-fs.target
After=network.target remote-fs.target
 
[Service]
Type=simple
User=systemv
Group=systemv
WorkingDirectory=/app/kafka
ExecStart=/app/kafka/bin/zookeeper-server-start.sh /app/kafka/config/zookeeper.properties
ExecStop=/app/kafka/bin/zookeeper-server-stop.sh
Restart=on-abnormal
 
StandardOutput=append:/app/kafka/logs/zookeeper.log
StandardError=append:/app/kafka/logs/zookeeper.log
 
[Install]
WantedBy=multi-user.target

Kafka 설정

kafka 의 설정은 /app/kafka/conf/server.properties 파일이다. 주요한 설정은 다음과 같다.

Kafka 설정하기
INI
1
2
3
4
5
6
7
8
broker.id=1
listeners=PLAINTEXT://klab-master1.systemv.local:9092
advertised.listeners=PLAINTEXT://klab-master1.systemv.local:9092
log.dirs=/app/kafka/data/kafka
zookeeper.connect=klab-master1.systemv.local:2181,klab-worker1.systemv.local:2181,klab-worker2.systemv.local:2181/kafka_znode
log.retention.hours=72
delete.topic.enable=true
allow.auto.create.topics=false

systemd Unit을 작성해서 관리한다.

Kafka 의 systemd unit 파일 작성
INI
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
[Unit]
Description=Apache Kafka server (broker)
Requires=network.target remote-fs.target zookeeper.service
After=network.target remote-fs.target zookeeper.service
 
[Service]
Type=simple
User=systemv
Group=systemv
#Environment='KAFKA_HEAP_OPTS=-Xms500m -Xmx500m'
WorkingDirectory=/app/kafka
ExecStart=/app/kafka/bin/kafka-server-start.sh /app/kafka/config/server.properties
ExecStop=/app/kafka/bin/kafka-server-stop.sh
LimitNOFILE=16384:163840
Restart=on-abnormal
 
StandardOutput=append:/app/kafka/logs/kafka-server.log
StandardError=append:/app/kafka/logs/kafka-server.log
 
[Install]
WantedBy=multi-user.target

토픽 테스트

이제 토픽을 생성해 테스트를 해본다. 다음과 같이 Topic 을 생성한다.

Topic 생성하기
ZSH
1
2
/app/kafka/bin/kafka-topics.sh --bootstrap-server klab-master1.systemv.local:9092 --create --topic test-overview01 --partitions 1 --replication-factor 3
Created topic test-overview01.

파티션 1개 복제는 3개로 토픽이 생성되었다. consumer 명령어를 이용해서 토픽에 접속한다.

Consumer 를 Topic 에 가입
ZSH
1
/app/kafka/bin/kafka-console-consumer.sh --bootstrap-server klab-worker1.systemv.local:9092 --topic test-overview01

접속을 하면 아무런 일도 발생하지 않는다.

이제 producer 를 이용해서 메시지를 생산한다.

Producer 를 이용해서 메시지 생산
ZSH
1
2
/app/kafka/bin/kafka-console-producer.sh --bootstrap-server klab-worker2.systemv.local:9092 --topic test-overview01
>First message

이렇게 메시지를 생성하면 앞서 접속한 consumer 화면에 똑같이 내용이 나와야 한다.

topic 의 통계 정보를 다음과 같이 확인해 볼 수 있다.

Kafka 상태 조회
ZSH
1
2
3
/app/kafka/bin/kafka-topics.sh --bootstrap-server klab-worker2.systemv.local:9092 --topic test-overview01 --describe
Topic: test-overview01  TopicId: nKyjCrdyQN6AGtaT4IWs7w PartitionCount: 1       ReplicationFactor: 3    Configs:
        Topic: test-overview01  Partition: 0    Leader: 3       Replicas: 3,1,2 Isr: 3,1,2

참고

Amazon MSK 2-AZ

Kafka 를 보게 되면서 Amazon MSK 를 보고 있는데, 문서를 보기에는 운영 환경에서 3-AZ 를 권장하고 있다. 성능 문서를 보았을때에도 3-AZ 를 권장하고 있고 Kafka 의 일반적은 환경에서도 3개의 브로커를 사용하도록 하고 있다.

하지만 Amazon MSK 에서는 2-AZ 로도 얼마든지 가능하다고 한다. 2019년 10월 16일 문서에 다음과 같이 되어 있다.

You can now expand your Amazon MSK clusters and deploy new clusters across 2-AZs

The new capability to expand allows your Amazon MSK cluster to scale out as your business grows by dynamically increasing the number of brokers within a cluster. The use of 2-AZ clusters is a good option for customers who already run Apache Kafka brokers in two AZs or use a replication factor of 2 by default.

Replication Factor 를 2로 할 경우에 얼마든지 2-AZ 로 할 수 있다고 되어 있다.