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 가 사설 인증서를 사용한 것이라면 다음과 같은 오류가 발생한다. Docker 컨테이너 안이라 사설 인증서에 […]
Git 브랜치 목록 동기화
Git 를 사용할때에 원격과 로컬의 브랜치를 동기화되서 동작한다. 그런데, 원격 브랜치를 삭제하고 난후에 로컬 브랜치를 보면 동기화 되지 않는다. 위 예제를 보면 원격 브랜치가 여러개 보인다. 하지만 실제 원격 브랜치를 보면 main 빼고는 전부 삭제된 상태 이다. 이럴때는 다음과 같이 하면 된다. 위와같이 로컬에 원격 브랜치 목록이 실제 원격 브랜치 목록과 동기화 되었다.
Gitlab 을 위한 opentofu 도커 이미지 제작
Gitlab 에서 사용할 opentofu 도커 이미지를 제작해보자. Gitlab 에서 Auto DevOps 를 이용할 경우에 Docker 이미지를 이용해서 Terraform 빌드, 배포 하는게 가능하다. 지금은 Terraform 을 위한 Docker 이미지만 존재하는데, Opentofu 를 위한 도커 이미지를 제작해서 사용할 수 있도록 이미지를 만들어 보자. Dockerfile Docker 빌드를 위해서 Dockerfile 이 있어야 한다. 다음과 같다. 내용을 보면 gitlab-terraform.sh 스크립트 파일이 있어야 한다. 이 파일은 실제 Gitlab 을 이용해서 CI/CD 를 할 경우에 실제로 사용하게 되는 스크립트 파일이다. Docker Build Docker 빌드는 다음과 같은 명령어로 […]
GitLab, Merge Request 일때만 Auto DevOps 되도록 하기
Gitlab 은 매우 강력한 툴이다. 이거 하나면 다 된다. 문제는 다루기가 여간 쉽지가 않다는데 있다. 많은 것을 알고 있는 상태라면 Gitlab 을 손댈 필요가 없지만 그것을 몰랐을 때에는 예기치 않은 반응과 결과를 보게 된다. Gitlab 은 CI/CD Pipeline 을 지원하는데, 이에 대한 설정은 Auto DevOps 에서 하게 된다. 정확하게 말하면 CI/CD Pipeline 을 Auto DevOps 라고 부른다고 이해해도 된다. 각 프로젝트 마다 Auto DevOps 설정이 존재한다. 이 설정의 기본은 다음과 같다. “Default Auto DevOps pipeline” 이 체크되어 있는데, 아래 설명에 […]
Gitlab 으로 terraform 상태(state) 관리하기
Terraform 을 여러명이 사용할때에 필요한 것이 Terraform 의 상태를 변경하지 못하도록 하는 것이다. terraform 을 실행할때마다 상태(state) 파일이 갱신되는데, 여러사람이 같이 일을 할때에는 이 파일을 공유해서 사용해야 한다. 대부분이 terraform state 파일을 AWS S3 저장소와 Dynamo DB 를 이용해 lock 을 거는 방식이 많이 거론된다. 이 방법은 AWS 클라우드를 사용해야 한다는 강제가 필요한데, 물론 Terraform 이 클라우드를 빠르게 코드로 만들도록 도와주기 때문에 어짜피 AWS 클라우드 인프라를 구성할 거면 S3 를 사용하는 것이 문제가 되지 않는다. 또, 인터넷상에 보면 Gitlab 을 […]
Terraform 을 위한 VSCode 세팅
VSCode 에서 Terraform 을 사용하기 위한 세팅은 다음과 같다. 필요한 Extensions 위와같은 Extensions 들을 설치하면 Terraform 을 사용하기가 편하다. 사용자 설정 Terraform 을 위한 사용자 설정은 다음과 같다. 위 설정은 Prettier – Code formatter 가 설치되어 있어야 한다.
Kafka 설치하기
이벤트 스트림을 제공하는 브로커 이다. 더블어 메시지 스트림도 지원한다. Scala 로 제작되었으며 JVM 위에서 동작한다. 따라서 Java 가 있어야 한다. 환경 서버는 3대로 준비했다. Production 에서는 적어도 3대의 Broker 를 권장대로 설치한 것이다. 서버 3대는 다음과 같다. 배포판은 Rocky Linux 9.3 최신 버전이다. 요구사항 Apache Kafka 를 실행하기 위해 JVM 이 필요하다. Kafka 버전에 따라서 Java 버전도 선택해야 한다. 최신의 Kafka 는 Java 11 을 필요로 한다. Java 11 을 설치는 패키지로 설치 했다. Kafka 다운로드 및 설치 Apache Kafka […]
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 […]
SRE 를 보고 느끼는 점들..
SRE(Site Reliability Engineering) 이라고 부르는게 요새 자주 들린다. 모든 내용을 다 아는건 아니지만, 이것저것 살펴보고 난 후 웃음이 났다. 그동안 내가 바라보는 관점이 그대로 같았기 때문이다. 나는 오래전부터 인프라 시스템, 좁게는 리눅스를 개발자 관점에서 다룰 수 있어야 한다고 생각해왔다. 나는 오랫동안 인프라 분야에 몸 담았다. 이렇게 말을 하면 대부분 서버, WAS 등을 다루는 것으로 생각할지 모른다. 실제로 내가 지원하는 분야는 TA 인데, 각 프로젝트마다 다르지만 그래도 TA 하면 인프라적인 요소를 많이 생각한다. 하지만 나는 적어도 인프라를 그야말로 전통적인 운영(Traditional Organizations) […]
Kubernetes 관련 기술 스택..
쿠버네티스 관련된 기술들이 워낙 많다보니 뭘 어디서부터 손대야할지 모를때도 있고 하다보면 어디에 서 있는지도 모를때가 있다. 더 나가 쿠버네티스를 시작하려고할때에 이게 어디에 있는건지를 알고 싶을때가 종종 있는데, 웹 서핑을 하다가 주운걸 기록해본다. 딱봐도 채용공고에 내용인데, 굵직하게 정리가 되어서 긁어왔다. 여기서 한가지 추가해야 한다면 IaC 부분인데, 요새는 쿠버네티스에 뭔가를 설치할때는 다음과 같은 걸 많이 사용한다. ArgoCD 도 있지만 이것은 사실 애플리케이션 배포에 쓰인다고 보면 된다. 요새 하도 공부를 하지 않아서 잃어버리는 기억도 많고 이제는 쓰지 않는 기술들도 많은데, 슬슬 다시 공부를해야 […]