DevOps

개요 이전 글에서는 CI/CD 파이프라인의 기반이 되는 Harbor 컨테이너 레지스트리, Argo Events, Argo Workflows를 설치했다. 이번 글에서는 이 구성 요소들을 ArgoCD와 통합하고 Helm 차트 기반의 프로젝트 템플릿을 설계하여 YAML 파일 하나로 완전한 CI/CD 파이프라인을 갖춘 프로젝트를 배포할 수 있는 내부 개발 플랫폼(Internal Developer Platform, IDP)을 구축하는 방법을 다룬다. 내부 개발 플랫폼이란 내부 개발 플랫폼(IDP)이란? 내부 개발 플랫폼(Internal Developer Platform)은 개발자가 인프라와 배포 파이프라인을 직접 구성하지 않고도 애플리케이션을 배포하고 운영할 수 있도록 추상화된 셀프서비스 인터페이스를 제공하는 시스템이다. 플랫폼 엔지니어링의 핵심 결과물로, 개발자 경험을 향상시키고 표준화된 배포 프로세스를 통해 운영 부담을 줄이는 것을 목표로 한다. ...

개요 이전 글에서는 HashiCorp Vault를 설치하여 안전한 시크릿 관리 시스템을 구축했다. 이번 글에서는 CI/CD 파이프라인을 구성하기 위해 필요한 세 가지 핵심 컴포넌트인 Harbor 컨테이너 레지스트리, Argo Events, Argo Workflows를 설치하고 기본 구성을 완료하는 방법을 다룬다. CI/CD 시스템 구성 요소 홈랩 환경에서 완전한 CI/CD 파이프라인을 구축하기 위해서는 다음과 같은 핵심 구성 요소가 필요하다: 컨테이너 레지스트리: 빌드된 컨테이너 이미지를 저장하고 배포하는 중앙 저장소로, Docker Hub와 같은 퍼블릭 레지스트리에 의존하지 않고 자체적으로 이미지를 관리할 수 있게 한다. 이벤트 처리 시스템: Git 저장소의 코드 변경, 웹훅 수신 등 다양한 이벤트를 감지하고 이에 반응하여 후속 작업을 트리거하는 역할을 담당한다. 워크플로우 엔진: 코드 빌드, 테스트 실행, 컨테이너 이미지 생성 등 실제 CI/CD 작업을 정의하고 실행하는 엔진이다. GitOps 배포 시스템: Git 저장소에 정의된 원하는 상태를 클러스터에 자동으로 동기화하는 시스템으로, 이전 시리즈에서 설치한 ArgoCD가 이 역할을 담당한다. 이번 글에서는 컨테이너 레지스트리, 이벤트 처리 시스템, 워크플로우 엔진을 각각 Harbor, Argo Events, Argo Workflows로 구현하고, 다음 글에서 이들을 ArgoCD와 통합하여 완전한 CI/CD 파이프라인을 완성한다. ...

Docker Compose는 다중 컨테이너 Docker 애플리케이션을 정의하고 실행하기 위한 도구로, YAML 파일을 사용하여 애플리케이션의 서비스를 구성하고 단일 명령어로 모든 서비스를 생성하고 시작할 수 있으며, 개발 환경과 프로덕션 환경 간의 일관성을 보장하고 복잡한 멀티 컨테이너 아키텍처를 간단하게 관리할 수 있도록 한다. Docker Compose의 개요 Docker Compose란? Docker Compose는 여러 컨테이너로 구성된 애플리케이션을 정의, 실행, 관리하기 위한 도구로, docker-compose.yml 파일에 서비스, 네트워크, 볼륨을 선언적으로 정의하고 단일 명령어로 전체 애플리케이션 스택을 관리할 수 있다. ...

React 애플리케이션을 Docker 컨테이너로 패키징하면 개발 환경과 프로덕션 환경 간의 일관성을 유지하고, CI/CD 파이프라인과의 통합이 용이해지며, 다양한 배포 환경(Kubernetes, AWS ECS, Azure Container Instances 등)에서 동일한 이미지를 사용할 수 있어 배포 프로세스가 표준화되고, 멀티 스테이지 빌드와 nginx 기반 정적 파일 서빙을 통해 최적화된 프로덕션 이미지를 생성할 수 있다. React 애플리케이션 컨테이너화의 이해 왜 React 앱을 컨테이너화하는가? React는 클라이언트 사이드 JavaScript 애플리케이션으로, 빌드 후 정적 파일(HTML, CSS, JavaScript)로 번들링되어 웹 서버를 통해 제공되는데, Docker 컨테이너를 사용하면 빌드 환경의 일관성 보장, 배포 자동화, 환경별 설정 관리가 용이해진다. ...

GitOps는 Git을 단일 진실 공급원(Single Source of Truth)으로 사용하여 인프라와 애플리케이션의 선언적 상태를 관리하고 자동으로 배포하는 운영 방법론으로, 2017년 Weaveworks의 CEO인 Alexis Richardson이 처음으로 이 용어를 제안하면서 클라우드 네이티브 커뮤니티에 소개되었다. GitOps는 개발자들에게 익숙한 Git 워크플로우(Pull Request, 코드 리뷰, 브랜치 전략 등)를 인프라 운영 영역으로 확장한 것으로, Kubernetes와 같은 선언적 인프라 플랫폼과 결합하여 현대적인 DevOps 실천 방법의 핵심 패러다임으로 자리잡았다. GitOps의 탄생과 핵심 원칙 GitOps란? 모든 인프라 구성과 애플리케이션 설정을 Git 저장소에 선언적으로 정의하고, 이 저장소를 단일 진실 공급원으로 사용하여 실제 시스템 상태를 자동으로 동기화하는 운영 방법론이다. ...

브랜치 전략의 역사와 배경 Git 브랜치 전략의 체계화는 2010년 1월 5일 네덜란드 개발자 Vincent Driessen이 “A successful Git branching model"이라는 블로그 포스트를 발표하면서 시작되었으며, 이 글에서 소개된 Git Flow는 당시 체계적인 릴리스 관리가 필요했던 소프트웨어 개발 환경에서 큰 반향을 일으켰고, 이후 2011년 GitHub의 Scott Chacon이 더 단순한 모델인 GitHub Flow를 제안했으며, 2014년에는 GitLab이 두 전략의 장점을 결합한 GitLab Flow를 발표하여 현재까지 세 가지 전략이 프로젝트 특성에 따라 널리 사용되고 있다. ...

DevOps의 탄생과 진화 DevOps는 2008년 벨기에의 IT 컨설턴트 Patrick Debois가 “DevOpsDays” 컨퍼런스를 조직하면서 공식적으로 시작되었으며, 이는 같은 해 Velocity 컨퍼런스에서 Flickr의 John Allspaw와 Paul Hammond가 발표한 “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr"라는 혁신적인 사례 발표에서 영감을 받았다. 당시 대부분의 조직에서는 개발팀과 운영팀이 서로 다른 목표를 추구하며 갈등하는 상황이 일반적이었으며, 개발팀은 새로운 기능을 빠르게 배포하고자 하고 운영팀은 시스템의 안정성을 유지하려는 상반된 인센티브 구조로 인해 소프트웨어 배포는 몇 주 또는 몇 달에 한 번씩 이루어지는 고통스러운 이벤트였다. ...

CI/CD는 Continuous Integration(지속적 통합)과 Continuous Delivery/Deployment(지속적 제공/배포)의 약자로, 소프트웨어 개발 과정에서 코드 변경 사항을 자동으로 빌드, 테스트, 배포하는 일련의 자동화된 프로세스를 의미하며, 현대 소프트웨어 개발에서 DevOps 문화의 핵심 요소로 자리 잡았다. CI/CD는 개발자들이 코드를 더 자주, 더 안전하게 통합하고 배포할 수 있게 해주며, 이를 통해 소프트웨어 릴리스 주기를 단축하고 버그를 조기에 발견하여 제품 품질을 향상시킬 수 있다. CI/CD의 역사와 유래 CI/CD는 1990년대 소프트웨어 개발 방법론의 혁신 속에서 탄생했으며, Extreme Programming(XP)의 핵심 실천 방법 중 하나로 시작되어 현재까지 지속적으로 발전해왔다. ...