개발과 일상

개요기존 서비스에서는 EKS + ArgoCD를 이용한 GitOps를 구축해놨었다. 그런데, 새로운 프로젝트에서는 ECS를 쓰면서 CI/CD를 아예 갈아치워야 하는 상황이 됐다. ECS 환경에서도 ArgoCD를 할 수 있다고는 하는데... 하는 방법이 구체적으로 나와있지 않았다. ArgoCD 메인테이너가 해준 설명 : https://github.com/argoproj/argo-cd/discussions/17843 어떻게해야하나 찾아보니까... GitHub Actions에서 ECS용 워크플로우를 만들어놔서 ArgoCD보다 더 쉽게 CI/CD를 구축할 수 있었다. 원리는 Task Definition에 명시해둔 이미지 이름을 변경하고 Task를 재실행시켜서 재배포하는 방식이다.  준비물은 Task Definit..

개요AWS ECS 기초부터 파악해보기에서도 이야기했지만, 이번 프로젝트는 ECS로 구축했다. 그런데, 작업을 시작할 당시에 아직 상용 서버용 AWS  계정을 전달 받지 못 했고, 개발 서버를 운영해야한다는 문제가 있었다. 이럴 경우 계정을 옮겨가야 하는데 인프라 구성을 AWS 콘솔로 작업할 경우, 개발 서버의 인프라를 상용 서버와 동일하게 구성하기 어려울 수 있다. 워낙 작업이 많아서 뭔가 놓칠 가능성이 크고, 특히 IAM과 보안 그룹이 싱크가 안맞아서 예상치 못한 문제가 생길 여지가 있다. 그래서 개발 서버에서의 모든 인프라를 Terraform으로 구성해 상용 서버용 계정을 전달 받았을 때 바로 옮길 수 있게 작업 했고, 이 글은 이 내용을 정리했다. 들어가기전에 1. Terraform 리소스는 S3에..

이번에 새로 진행하는 프로젝트의 인프라는 k8s가 아니라 ECS로 선택했다. BE를 병행하는 입장에서 k8s의 계속해서 바뀌는 업데이트와 복잡성을 따라가기 어렵다 판단해서였다. 그래서 차근차근 Terraform으로 ECS를 구축하던 중 IAM을 설정하다 의외의 문제를 발견했다. aws_iam_policy_attachment와 관련된 문제여서 짚고가보려고한다. 현상부터 특이하다. 1. terraform init (-upgrade)2. terraform plan를 할때 매번 새로운 upgrade 요소가 나옴3. terraform apply에서 아래와 같은 에러가 발생4. 다시 1로 돌아가서 upgade를 해주면 plan에서 새로운 리소스가 잡힘. 2~3의 반복 분명 정책을 만들고 attachment를 실행했..

내가 막 입사했을 때만해도 로그 관리 자체가 안되고 있었다. Cloud Watch를 뒤적거리던가, ArgoCD 대시보드에서 컨테이너에 접근해서 로그를 파악했다. .... 그래서 DevOps 관리자 분과 가장 먼저 협업한 것이 로그 파이프라인 구성이었다. 내가 한 일은 다음과 같다. 1. Application 단에서 발생한 로그를 어느 단위로 남길 것인지 판단하고 필요한 정보를 검토2. 검토된 정보들을 로그로 만들어 JSON 형태로 남김3. LogQL 쿼리로 Loki 데이터를 쿼리해서 Grafana에 대시보드를 추가 DevOps 관리자분은 따로 작업하셨어서 어떤 일을 했었는지 정확히 알기 어려웠는데, 이번 기회에 잘 알게 됐다. DevOps 관리자분이 한 일은 다음과 같다. 1. JSON 형태의 로그가 생..

AWS에서 제공하는 완전관리형 쿠버네티스 서비스인 EKS는 업데이트 주기가 엄청나게 빠르다. Amazon EKS Kubernetes 버전에 관한 문서를 읽어보면 다음과 같이 안내한다. 1. EKS 신규 버전 출시는 쿠버네티스 업스트림 릴리즈 주기(4개월)을 따름.2. 신규 버전 출시 후 14개월은 무료로 표준 지원3. 표준 지원 종료 후 12개월 추가 지원 (클러스터 당 0.6$/h의 추가 요금 발생)4. 추가버전 종료까지 업그레이드를 하지 않을경우 가장 마지막 버전으로 강제 업그레이드5. 평균적으로 업스트림 릴리즈 이후 약 2~6개월 이후 EKS 지원 만약 추가 지원으로 빠진다면, 클러스터 당 한달에 약 60만원(0.6 × 1380 × 24 × 30) 정도의 추가 비용이 발생한다. 그래서 그런지 콘솔에..

GitOps를 구축하는데 가장 중요한 단계이다. CI/CD 부분에서 키 설정등의 내용이 많아서 100% 전달할 수 있을지 잘 모르겠다. 이전까지 진행 상황 이 전 글에서 봤던 파이프라인이지만 이전 글에서는 ArgoCD를 EKS 내부에 띄우는데까지만 진행했었다.(위 그림에서 할당된 번호도 없음) 그리고 CI는 이전 글들에서 진행했었다. 아래 글에 1 ~ 3번 과정이 정리되어있다.2023.11.06 - [개발/인프라] - github action으로 CI/CD 구축하기 - 1. CI2023.11.12 - [개발/인프라] - github action으로 CI/CD 구축하기 - 2. JIB 마지막으로 남은 CD 자동화 부분이다. 자동화를 위해서는 ArgoCD가 모니터링할 GitHub Repository를 지정해..

실제 EKS에서 동작 확인을 하는건 ArgoCD 까지만 진행할 예정이다. 백엔드 개발자에게 관찰 가능성 도구들까지 배포하고 기능 확인까지하라는건 너무 가혹하다. k8s에서 어플리케이션을 개발하고 배포한다면, ArgoCD는 한번쯤 들어봤을 수 있다. 주로 GitOps를 위해 사용되는데 ArgoCD와 GitHub을 이용해 자동 배포까지 진행해보려 한다. 이번 장에서는 ArgoCD를 배포하고 대시보드를 만들어 볼 것이다. GitOps란?GitOps는 Git 리포지토리를 단일 정보 소스로 사용하여 인프라를 코드로 제공합니다. 제출된 코드에서는 CI 프로세스를 확인하고, CD 프로세스에서는 보안, 코드형 인프라(IaC) 또는 애플리케이션 프레임워크에 설정된 기타 경계와 같은 요구 사항을 확인하고 적용합니다. 코드..

현재 하고 있는게 간단한 샘플 코드로 EKS를 구축하는 과정이라 이스티오(Istio)에 대해 다루는게 맞는지 잘 모르겠다. 그래도 서비스 메시(Service Mesh) 개념 정리도 할 겸 짚고 넘어가보려고 한다. 서비스 메시(Service Mesh)란?서비스 메시는 애플리케이션의 서비스 간 모든 통신을 처리하는 소프트웨어 계층입니다. 이 계층은 컨테이너화된 마이크로서비스로 구성됩니다. 애플리케이션이 확장되고 마이크로서비스의 수가 증가함에 따라 서비스의 성능을 모니터링하기가 점점 어려워지고 있습니다. 서비스 메시는 서비스 간 연결을 관리하기 위해 모니터링, 로깅, 추적, 트래픽 제어와 같은 새로운 기능을 제공합니다. 이러한 기능은 각 서비스의 코드와 독립적이므로 네트워크 경계를 넘어 여러 서비스 관리 시스..