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 를 할 경우에 실제로 사용하게 되는 스크립트 파일이다.
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 라는 문법을 지원 한다. 예를들면 다음과 같다.
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 두개로 작성 됐다.
위 코드를 보면 변수 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 권한이 있어야 한다.
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 이던 상관이 없다.
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 로 할 수 있다고 되어 있다.
SRE(Site Reliability Engineering) 이라고 부르는게 요새 자주 들린다. 모든 내용을 다 아는건 아니지만, 이것저것 살펴보고 난 후 웃음이 났다. 그동안 내가 바라보는 관점이 그대로 같았기 때문이다. 나는 오래전부터 인프라 시스템, 좁게는 리눅스를 개발자 관점에서 다룰 수 있어야 한다고 생각해왔다.
나는 오랫동안 인프라 분야에 몸 담았다. 이렇게 말을 하면 대부분 서버, WAS 등을 다루는 것으로 생각할지 모른다. 실제로 내가 지원하는 분야는 TA 인데, 각 프로젝트마다 다르지만 그래도 TA 하면 인프라적인 요소를 많이 생각한다.
하지만 나는 적어도 인프라를 그야말로 전통적인 운영(Traditional Organizations) 을 지향하지 않았다. 대학교때에는 리눅스(Linux) 에 미쳐살았지만 그것을 벗어나 PHP 웹 개발하면서 취업도 개발자로 했다. 그러던 것이 인프라 팀으로 적을 옮겼는데, 정확하게는 인프라 개발팀이였다. Python 을 그때 배웠다. 그리고 인프라 백엔드 개발과 서버운영을 같이하는 일을 하게되면서 자연스럽게 OSS 와 인프라 개발을 위한 각가지 프로그래밍을 익혔다.
SRE 을 한국에 적용한다면 “인프라 개발팀” 이 가장 현실적이다. SRE 의 정의는 대략 다음과 같다.
Google defines an SRE as an operationally minded software engineer, but what does that mean? At Google, SRE teams are responsible for both capacity planning and provisioning. The teams are different from purely operational teams in that they seek software engineering solutions to problems.
소프트웨어 엔지니어 마인드로 운영을 다룬다는 것인데, 오래전부터 개발자 관점에서 인프라 시스템을 바라보고 다루어야 한다고 생각했었다.
문제는 현실이 그렇지 않다는 것이다. 더군다나 프리랜서 직업에서 프로젝트에 투입되보면 대부분 OS, WAS, 최근에는 Cloud 까지 구축과 운영을 하는 경우가 많았다. 이런 경우에 소프트웨어 엔지니어, 더나가 개발자적 시각으로 일을 할만큼 여건이 되지 않았다. 그리고 그런걸 원하지도 않았다. 전통적인 운영과 구축이였다.
한국의 상황이 안타까움이 있다. TA 직군에서 계약을하고 프로젝트를 하게되면 기술적인 부분에 있어서 그런대로 최근의 트랜드를 따라가긴 한다. 자동화, IaC, 데이터 분석등이 그런 것이다. 문제는 기술적인 부분만 강조할 뿐, 이것을 기반으로 SRE 까지는 가지 못한다는데 있다.
TA 들도 문제다. TA 들은 전통적인 구축, 운영에 적어 있다. 이들에게 Python 정도는 할 줄 알아야 하지 않느냐는 질문에 “그걸 왜 우리가 알아야 하냐?” 식의 답변이 대부분이다. OS 를 명령어를 통해서 세팅하고, WAS 서버를 세팅하고 로그 분석하고 JVM 설정과 덤프 분석등이 그들이 하는 일이라고 생각한다. 그러다보니 Python 은 고사하고 Cloud 에서 많이 쓰이는 Terraform 과 같은 툴을 익히는데 게을리 한다. 어떤 문제가 발생하면 서버에 직접 접속해서 봐야 속이 시원하고 JVM 덤프를 떠서 분석을 해야지만 뭔가 일을 제대로 하는 것마냥 생각한다.
이제 TA 도 소프트웨어 엔지니어를 넘어서 개발자가 되어야 한다. 진정으로 개발을 하는 건 아니지만 적어도 자신이 자신있게 하나 정도의 언어는 능숙하게 다룰 수 있어야 한다.
구글의 SRE 는 팀의 Role 이다. 정확하게는 운영에 대한 Role. 그래서 작금의 TA 직업군에게 적용되어지는 대상이다.
To enforce this, Google caps the amount of time SREs spend on purely operational work at 50%. This means that, at a minimum, 50% of a Google SRE’s time should be allocated to engineering tasks, such as automation and improvements to the service.
문제는 편견과 돈…
지금까지 TA 경력으로 일해오면서 한 마디 했다가 바보 된 경우가 있었다.
100% 장애 안나는 시스템은 없습니다. 대충 해봐도 90%정도 가동률을 보이면 진짜 잘한 겁니다. 장애 안나게 어떻게 시스템을 만듭니까?
특히나 금융 프로젝트에 투입된 상황에서 저런말을 하면 십중팔구 고객으로부터 짐 쌓라는 말을 들을 수 있다. 공공 프로젝트는 더 하지 않나? 100% 장애 안나는 시스템을 구축해야 하는거지, 금융 시스템 운영하다가 장애 날껄 생각하면서 구축하냐?
하지만 SRE 는 100% 장애를 커버하지 않는다. 이것도 나의 생각과 동일 했었는데, 장애 발생하더라도 서비스에 영향이 없다면 어떨까? 장애라는 것이 특정 서버가 다운되거나 네트워크 장비가 이상이 생길 수 있다. 이런 상황에서도 고객 서비스에 아무런 영향을 주지 못했다면 그 시스템은 신뢰성이 높다고 할 수 있지 않을까? 신뢰성(Reliability) 라는 말이 가지는 함의가 이와 같다고 생각한다.
돈.. 기업은 항상 돈을 먼저 생각한다. 기업이 힘들면 IT 부서가 먼저 짤린다는 슬픈 이야기는 더 이상 슬픈 이야기도 아니다. 100% 장애가 나지 않도록 해야지만 고객에 대한 보상도 없을 것이니 장애 발생이 가능할 수도 있다는 말을 꺼내는 순간 돈이 나갈 수 있다는 생각을 먼저 하게 된다. 장애가 나면 그것을 분석하고 장애를 예방하기 위한 일련의 활동이 필요한데, 그렇게 되면 전문가가 항시 있어야 한다. 언제 생길지도 모르는 장애 때문에 전문가를 고용한다는 건 기업에서는 있을 수 없는 일이다.
구축 프로젝트가 끝나면 대부분의 인력이 철수를 한다. 운영으로 넘어가게 되면 안타갑게도 인프라 관련 전문 인력은 뽑지도 않는다. 인프라 담당자를 뽑아 놨다고 하지만 그냥 용어만 잘 알고 있을뿐 실무적인 익숙함도 없는 사람들인 경우가 많다. 어짜피 구축된 시스템은 100% 장애가 발생하지 않도록 구축되었다는 신념이 있기 때문에 운영은 그냥 모니터링 요원정도로만 생각하는 것이다.
만약 이렇게 자동으로 디스크가 인식되지 않는다면 SCSI 디스크 ReScan 기능을 이용해야 한다. Hot Swap 은 SCSI 의 host 번호를 이용해 작동됨으로 SCSI host 번호를 알아야 한다. 하지만 리눅스에서는 /dev/sdc 형식인데 SCSI host 번호와는 다른데, 다음과 같이 알아내야 한다.
