devops(8)
-
GitOps란 무엇인가: Argo CD와 Flux 중심으로
Terraform으로 인프라를 코드로 관리하는 건 익숙해졌는데, Kubernetes 배포는 여전히 CI 파이프라인에서 kubectl apply를 실행합니다. 어느 날 누군가 클러스터에 직접 kubectl edit으로 설정을 바꿨고, 다음 배포에서 그 변경이 덮어씌워져 장애가 발생합니다. GitOps는 이 문제를 구조적으로 해결하는 운영 모델입니다.핵심 요약GitOps는 Git을 Single Source of Truth로 사용하여, 선언적으로 정의된 상태를 클러스터에 지속적으로 동기화하는 운영 모델입니다.전통적인 CI/CD의 Push 방식과 달리, GitOps는 Pull 방식으로 동작합니다. 클러스터 내부의 Agent가 Git 상태를 감시하고 자동으로 조정합니다.Argo CD는 Web UI와 멀티 클러스터..
2026.06.08 -
GitHub Actions와 Jenkins 차이: CI/CD 도구 선택 기준
CI/CD 도구를 선택할 때 "Jenkins가 레거시니까 GitHub Actions로 가자"라는 판단은 위험합니다. 팀 규모, 빌드 볼륨, 보안 요구사항, 운영 역량에 따라 적합한 도구가 다릅니다. 이 글에서는 두 도구의 구조적 차이를 분석하고, 상황별 선택 기준을 정리합니다.핵심 요약GitHub Actions는 GitHub과 통합된 SaaS CI/CD 서비스로, 별도 인프라 운영 없이 시작할 수 있습니다.Jenkins는 자체 호스팅 오픈소스 CI/CD 서버로, 높은 유연성과 커스터마이징이 가능하지만 운영 부담이 있습니다.소규모 팀이 GitHub을 사용하고 있다면 GitHub Actions가 대부분 적합합니다.빌드 볼륨이 크거나 네트워크 격리 요구사항이 있다면 Jenkins가 비용/보안 측면에서 유리할 ..
2026.06.08 -
Blue-Green Deployment와 Rolling Update 차이: 배포 전략 선택 기준
신규 버전을 배포할 때 "서비스 중단 없이 안전하게"는 기본 요구사항입니다. 문제는 어떤 방식으로 무중단을 달성할지입니다. 리소스를 2배 확보해서 한 번에 전환할지, 점진적으로 교체하면서 리소스를 절약할지. 이 선택이 롤백 속도, 비용, 운영 복잡도를 결정합니다.핵심 요약Blue-Green Deployment는 동일한 환경 2세트를 운영하고, 트래픽을 한 번에 전환하는 방식입니다. 롤백이 빠르지만 리소스가 2배 필요합니다.Rolling Update는 기존 인스턴스를 하나씩(또는 일정 비율씩) 새 버전으로 교체하는 방식입니다. 리소스 효율이 높지만 배포 중 두 버전이 공존합니다.Kubernetes에서 Rolling Update는 Deployment의 기본 전략이고, Blue-Green은 Argo Rollo..
2026.06.07 -
GitHub Actions로 Docker 이미지를 빌드하고 배포하기: CI/CD 파이프라인 실습
코드를 Push하면 Docker 이미지가 자동으로 빌드되고, 테스트를 통과한 뒤 프로덕션에 배포됩니다. 이 흐름을 GitHub Actions로 구성하는 방법을 단계별로 설명합니다. 단순히 "돌아가는" 파이프라인이 아니라, 캐싱으로 빌드 시간을 줄이고, OIDC로 보안을 강화하고, 이미지 스캔으로 취약점을 차단하는 운영 수준의 워크플로우를 만듭니다.핵심 요약GitHub Actions에서 Docker 이미지를 빌드하려면 docker/build-push-action을 사용합니다. BuildKit 기반으로 Multi-platform 빌드와 레이어 캐싱을 지원합니다.AWS ECR에 Push할 때는 OIDC 인증을 사용하면 장기 Access Key 없이 임시 자격 증명으로 접근할 수 있습니다.레이어 캐싱(cache..
2026.06.06 -
Terraform Error acquiring the state lock 해결 방법
terraform plan을 실행했는데 "Error acquiring the state lock"이 뜨면서 아무 작업도 진행되지 않습니다. 팀원이 작업 중인 것도 아닌데 lock이 걸려 있습니다. CI/CD 파이프라인이 중간에 실패하면서 lock이 해제되지 않은 경우, 이 상황이 자주 발생합니다.핵심 요약구분내용에러 메시지Error acquiring the state lock원인이전 Terraform 실행이 비정상 종료되면서 DynamoDB Lock이 해제되지 않음즉시 해결terraform force-unlock 근본 원인CI/CD timeout, 수동 중단(Ctrl+C), 네트워크 단절, 프로세스 강제 종료재발 방지CI/CD timeout 설정, Graceful shutdown, Lock 모니터링 알람..
2026.06.05 -
Terraform S3 Backend와 State Lock 구성하기: 팀 협업을 위한 원격 상태 관리
팀원 3명이 같은 인프라를 Terraform으로 관리할 때, Local State로는 충돌을 피할 수 없습니다. S3 Backend와 DynamoDB Lock을 구성하면 이 문제를 구조적으로 해결할 수 있습니다.핵심 요약S3 Backend는 Terraform State를 팀 전체가 공유할 수 있는 원격 저장소에 보관합니다.DynamoDB를 사용한 State Locking은 동시 작업으로 인한 State 충돌을 방지합니다.Backend 리소스(S3 버킷, DynamoDB 테이블)는 Terraform이 아닌 별도 방법으로 먼저 생성하는 것이 일반적입니다.State 파일에는 민감 정보가 포함될 수 있으므로 암호화와 접근 제어가 필수입니다.환경별(dev/staging/prod) State를 분리하면 blast ..
2026.05.31