| En

홈랩 구축기 #8: IDP 구축 (2)

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

2025년 2월 28일 · 11 분 · 2174 단어 · In-Jun

홈랩 구축기 #7: IDP 구축 기반 구성

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

2025년 2월 28일 · 7 분 · 1431 단어 · In-Jun

Docker Compose 멀티 컨테이너 개발 환경

Docker Compose는 다중 컨테이너 Docker 애플리케이션을 정의하고 실행하는 도구이다. YAML 파일에 서비스를 선언적으로 구성하고 단일 명령어로 전체 스택을 띄울 수 있어, 복잡한 멀티 컨테이너 환경도 일관되게 관리하기 쉽다. Docker Compose의 개요 Docker Compose란? Docker Compose는 여러 컨테이너로 구성된 애플리케이션을 정의, 실행, 관리하기 위한 도구로, docker-compose.yml 파일에 서비스, 네트워크, 볼륨을 선언적으로 정의하고 단일 명령어로 전체 애플리케이션 스택을 관리할 수 있다. Docker Compose의 역사 연도 이벤트 설명 2013 Fig 프로젝트 시작 Orchard 팀이 Docker 컨테이너 오케스트레이션 도구 Fig 개발 시작 2014 Docker의 Fig 인수 Docker가 Orchard를 인수하고 Fig를 Docker Compose로 리브랜딩 2015 Compose v1 안정화 Docker Compose가 공식 Docker 도구로 통합 2020 Compose Specification Docker Compose 사양이 오픈 표준으로 공개 2021 Compose v2 출시 Go로 재작성된 Compose v2가 Docker CLI 플러그인으로 통합 2023 Compose v2 기본화 docker-compose 명령이 docker compose로 대체되어 기본 도구로 채택 Docker Compose의 필요성 현대 웹 애플리케이션은 단일 컨테이너로 구성되는 경우가 드물며, 일반적으로 웹 서버, 애플리케이션 서버, 데이터베이스, 캐시, 메시지 큐 등 여러 서비스가 협력하여 동작한다. 이러한 멀티 컨테이너 환경을 개별 docker run 명령으로 관리하는 것은 다음과 같은 문제점을 야기한다. ...

2025년 2월 17일 · 8 분 · 1701 단어 · In-Jun

React 애플리케이션 Dockerfile 작성

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

2025년 2월 17일 · 7 분 · 1480 단어 · In-Jun

GitOps 배포 전략 Push vs Pull

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

2025년 2월 14일 · 7 분 · 1424 단어 · In-Jun

Git 브랜치 전략, Git Flow와 GitHub Flow 그리고 GitLab Flow

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

2024년 7월 10일 · 6 분 · 1083 단어 · In-Jun

DevOps 개념과 실천

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

2024년 6월 22일 · 8 분 · 1496 단어 · In-Jun

CI/CD 지속적 통합 Continuous Delivery와 Continuous Deployment

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

2024년 6월 10일 · 10 분 · 2002 단어 · In-Jun
[email protected]