IaC 관리 구조Layer 구조Terragrunt Live ├ dev │ ├ infra │ ├ platform ├ stg ├ prodTerraform Modules ├ network ├ bastion ├ nks ├ database ├ storage ├ certInfrastructure (NCP) ├ VPC / Subnet / NAT ├ Bastion ├ NKS ├ Cloud DB ├ Object Storage Repo 구조terragrunt repository ├ dev │ ├ infra │ │ ├ network │ │ │ ├ terragrunt.hclmodules ├ network │ ├ main.tf │ ├ variables.tf │ ├ outputs.tf Ia..
전체 글
Let’s become the best developer 꼬부기Terraform / Terragrunt 도입 이후, 바로 구축하지 않고 먼저 설계한 것들Terraform / Terragrunt를 도입한 이후, 바로 dev 환경부터 IaC로 구축하지는 않았다.먼저 전체 IaC 운영 프로세스를 어떻게 가져갈지 큰 흐름을 정리하는 과정부터 진행했다. 기존 인프라 기준으로 IaC를 정리해야 하는 상황이었고, 프로젝트와 환경이 계속 늘어나는 구조였기 때문에초기 운영 기준을 먼저 정의하는 것이 중요하다고 판단했다. IaC 전환 전에 먼저 정리했던 기준IaC 전환을 시작하기 전에 몇 가지 운영 기준을 먼저 정리했다.프로젝트 단위는 어떻게 나눌지, dev / stg / prod 같은 환경은 어떤 기준으로 분리할지remote state는 어떤 단위로 관리할지그리고 리소스 간 dep..
Terraform 이란?Terraform은 인프라를 코드로 관리하기 위한 IaC 도구다.서버, 네트워크, DB 같은 리소스를 코드로 정의하고 자동으로 생성할 수 있다.반복 작업을 줄이고, 인프라 구성을 표준화할 수 있어서 프로젝트가 늘어날수록 효과가 커진다. Terrafrunt 란?Terragrunt는 Terraform을 더 효율적으로 운영하기 위한 Wrapper 도구다.Terraform 모듈 재사용, 환경(dev/stg/prod) 분리, State 관리, Dependency 관리 등을 쉽게 해준다. Terragrunt를 도입한 이유?Terraform을 도입할 때 Terraform만 단독으로 도입하지는 않았다.처음부터 멀티 프로젝트, 멀티 환경 운영을 고려해서 Terragrunt를 같이 도입했다. SI ..
Naver Cloud Platform(NCP)을 사용하면서 여러 SI 프로젝트를 진행해왔다.처음에는 클라우드 콘솔에서 직접 인프라를 생성하고 운영하는 방식으로 작업했다. 프로젝트 수가 많지 않았을 때는 크게 불편하지 않았고, 빠르게 환경을 만들 수 있어서 오히려 편하다고 느꼈다.하지만 프로젝트가 점점 늘어나면서 같은 작업을 계속 반복하고 있다는 느낌이 들기 시작했다.반복되는 인프라 작업프로젝트를 새로 시작할 때마다 비슷한 작업을 계속 반복해야 했다.VPC 생성Subnet 생성서버 생성DB 생성Bastion 설정작업 자체가 어렵지는 않았지만, 프로젝트가 늘어날수록 같은 작업을 계속 반복하는 것이 점점 부담이 됐다. 비슷하지만 항상 조금씩 다른 인프라또 하나 불편했던 점은 프로젝트마다 인프라 구성이 조금씩..
Elasticsearch node 역할elasticsearch의 node들은 아래와같은 역학들을 가지고있다. Master NodeElasticsearch Cluster 구성을 관리, 제어(인덱스 생성/삭제)를 담당한다. Elasticsearch Cluster는 최소 1개의 마스터노드를 가지고 있어야하며, 데이터 무결성을 위해서 최소 3개(split-brain 방지)의 마스터노드를 권장한다고한다. Data Nodedata를 실제로 저장하고 검색 로직을 처리하는 노드데이터를 처리하기 때문에 cpu, mem 사용량이 많다. Ingest Nodedata를 Elasticsearch 에 저장하기 전에 전처리 하는 노드Ingest Pipeline을 이용해서 데이터 필터링, 전환, 정규화 등의 작업을 수행한다...
쿠버네티스를 완벽하게 이해하고 있지는 않지만, 점점 익숙해지는 과정에서 자연스럽게 모니터링의 필요성을 느끼게 되었다. 백엔드 서비스를 운영하다 보면 "현재 서비스가 정상적으로 동작하고 있는가?", "어떤 요청이 많고, 장애가 발생했을 때 원인을 어떻게 찾을 수 있을까?" 같은 고민이 생기기 마련이다. 이를 해결하기 위해 쿠버네티스 환경에서 ELK Stack을 구축하여 BE 서비스의 로그를 효율적으로 모니터링하는 방법을 직접 경험해보기로 했다. 이번 글에서는 Kubernetes에서 ELK Stack을 배포하고, 로그를 수집 및 분석하는 과정을 정리해보려고 한다. ELK Stack VS GrafanaELK 와 Grafana 둘 다 모니터링 도구이지만 각각의 사용 용도는 조금 다르다. ELK 로그 수집 ..
Object란?쿠버네티스 시스템의 상태를 나타내는 영속성 엔티티 Object 주요 특징Spec (명세)사용자가 정의한 "원하는 상태" 설명 그대로 사용자가 kubernets에 원하는 상태를 정의하는 역할을 한다. 정의 가능 내용에는 아래와같은 내용들이 있다.컨테이너 이름사용 이미지리소스 제한 (CPU, MEM)볼륨 마운트 (Local, PVC) Status (상태)kubernetes Cluster의 "현재 상태" Status는 현재 상태를 나타내며, Spec 에서 사용자가 정의한 상태를 유지하려고 능동적으로 작업한다."읽기 전용"이므로 사용자가 수정할 수 없고, 변경 시 event가 발생한다. Object 종류1. Podkubernetes 에서 배포되는 최소 단위이며, 하나 이상의 컨테이너를 그룹..
LIST
