개발과 일상

개요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를 실행했..

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는 AWS에서 관리되는 "쿠버네티스" 서비스이다. 외부 인터넷 망과 쿠버네티스 서비스를 연결해주기만 하면(여기서도 권한이 필요하긴하지만) 쿠버네티스 내부의 노드/파드들에게 특별한 권한이 주어질 필요는 없다.  문제는, 쿠버네티스 내부에서 AWS 리소스에 대한 접근 권한을 줘야하는 경우다. AWS 리소스들에 접근하기 위해서는 파드들에게 권한을 부여해줘야 한다.  쿠버네티스 파드들에게 IAM Role을 부여하는 것을 IRSA(IAM Roles for Service Accounts)이라 한다. 파드들에게 권한을 주기 위한 다양한 방법이 있는데 이 중에서 IRSA가 모범사례로 제시되어있다.https://aws.github.io/aw..

EKS는 컨트롤 플레인을 자동 관리해주고, 추가 기능으로 클러스터 관리의 편의성까지 제공해준다. 하지만 데이터플레인 관리는 사용자의 몫이다. EKS는 AWS 환경이다보니 온프레미스 환경보다 자유로운 자원의 확장과 축소 설정이 가능하다. 이러한 기능을 노드 오토스케일링이라고 하는데 대표적으로 CA(Cluster Autoscaler)와 Karpenter가 있다. Karpenter가 CA 비해 빠르고 비용 절감효과가 있어서, 본 포스팅은 Karpenter를 정리해보려고 한다. 그래도 차근차근 알아가는게 중요하니 CA부터 정리해보자. Cluster Autoscaler (CA)Cluster Autoscaler는 AWS의 Auto Scaling Group(ASG)을 이용하여 EKS의 노드를 관리합니다. ASG는 E..

쿠버네티스를 사용하기 위해 바닐라 쿠버네티스를 설치하면, 컨트롤 플레인에 설정해야하는 오픈소스와 정책들이 많다. 결정해야하는게 많다는 것은 좋게보면 높은 자유도를 제공하는거지만, 나쁘게 보면 사용 허들이 높다. 그래서 여러 클라우드 벤더들은 컨트롤 플레인에서 결정해야하는 것들을 베스트 프랙티스로 제공해주는데, 이러한 제품들을 매니지드(Managed) 쿠버네티스라고 한다. 당연히 AWS에서도 매니지드 쿠버네티스 제품을 제공하는데, 이 제품이 Amazon Elastic Kubernetes Service(Amazon EKS)다.    EKS 클러스터란?Amazon EKS 클러스터에는 두 가지 기본 구성 요소가 있습니다.1. Amazon EKS 제어 영역2. 제어 영역에 등록된 Amazon EKS 노드Amazo..

사실 AWS 리소스를 HCL로 정의하는 것 보다 선행되어야 하는 것들이 있다. Provider 설정과 AWS 인증에 관한 내용이었는데, 그 전까지는 별다른 설정없이도 잘 동작해서 필요했는지 잘 몰랐다. Provider부터 하나씩 알아보자.Terraform provider는 Terraform이 특정 기술 스택이나 API와 통신할 수 있게 해주는 플러그인이다.https://registry.terraform.io/browse/providers AWS용 Terraform provider는 AWS API와 통신하여 AWS 리소스를 생성, 관리 및 삭제할 수 있게 해준다.Provider는 Terraform이 관리할 수 있는 resource type과 data sources를 추가해서, Provider가 구현해놓은 ..

2024.04.18 - [개발/인프라] - Terraform AWS VPC 셋업하기 - 1 의 후속편 이전 포스팅에서 Terraform VPC 모듈을 이용해 구축하는 방법을 정리했었다. 어떻게보면 당연한 이야기지만 VPC 모듈 외의 요소들도 실 서비스에서 많이 사용된다. 진짜 다양한 리소스들이 있지만 내가 써본 것들 위주로 정리해볼 예정이다. AWS 엔드포인트(AWS EndPoint)VPC 엔드포인트를 사용하면 인터넷 게이트웨이, NAT 디바이스, VPN 연결 또는 AWS Direct Connect 연결을 사용할 필요 없이 Virtual Private Cloud(VPC)와 지원되는 서비스 간에 연결할 수 있습니다. 따라서 VPC는 퍼블릭 인터넷에 노출되지 않습니다. 어떻게보면 구축하면 효과는 확실하지만 ..