OnTheTop - 프로젝트

GitHub클라우드 개요(> - 클라우드 WHY? 문서(> - 버전 별 아키텍처(> - 단계 별 설계 문서(클라우드 프로젝트는 매 순간순간이 선택의 연속이었습니다. 그 선택 속에서 질문하고, 시도하고, 경험했던 사항들을 토대로 우리가 왜 이것을 선택했는가를 정리한 문서

데이터베이스에 UUID로 저장된 S3 이미지 파일 조회 흐름.이미지를 업로드할 때:UUID를 생성 (예: abc123-uuid.jpg)S3에 abc123-uuid.jpg 이름으로 업로드이 UUID를 DB에 저장 (컬럼에 저장)이미지를 조회할 때:DB에서 UUID를 조회

CI/CD 환경에서 테스트는 필수지만, 테스트 결과를 보기 좋게 정리해서 확인하는 과정은 종종 놓치기 쉽다.그래서 GitHub Actions에서 Java(Spring Boot) 기반 프로젝트의 테스트 결과를 HTML 리포트로 출력하고, 린트 도구까지 자동화해보았다.Sp

이 글에서는 Blue‑Green 전략을 활용해 GCP 백엔드와 S3 + CloudFront 프론트엔드를 한 번에 배포하는 GitHub Actions 워크플로 Deploy Prod를 해부합니다. 백엔드: GCP Managed Instance Group(MIG) + HTT

Confirm Prod Deployment (Clean Old MIG) 워크플로는 배포가 정상적으로 검증된 뒤 여분의 MIG를 제거해 리소스 비용을 줄입니다.대상 식별 : 입력 슬롯이 blue면 green MIG를, 반대면 blue MIG를 OLD_MIG로 지정.MIG

최근 백엔드 서버를 Dev 환경에 자동으로 Docker 컨테이너로 배포하는 파이프라인을 구성했습니다. 기존에는 JAR 빌드 후 수동으로 배포하거나 shell script 수준에서 멈춰 있었는데, 이를 GitHub Actions로 깔끔하게 자동화하면서 생산성을 꽤 끌어올

🔧 프로젝트 개요 이 글에서는 GCP의 Managed Instance Group (MIG) 환경에서 Blue-Green 배포 전략을 적용하고, GitHub Actions로 CI/CD를 자동화한 전체 구현 과정을 정리합니다. ✅ 목표 여러 GCP VM 인스턴스(M

이 문서는 Onthe-Top 프로젝트의 Terraform 기반 개발/운영 프로젝트의 파일 구조, 항목 설명, 활용 방식, 변수 관리 전략, 그리고 개선 방향에 대한 정보를 제공합니다. 본 프로젝트는 AWS와 GCP를 병행 활용하며, Terraform의 모듈화와 환경 분

배경 Blue-Green 배포를 사용하면 다운타임 없이 안전하게 서비스를 교체할 수 있습니다. 하지만 \\배포 후 사용하지 않는 슬롯(Docker 컨테이너)\\이 계속 남아 있으면 자원을 낭비하거나 장애의 원인이 될 수 있습니다. 그래서 저는 \\"현재 Nginx가

3\. 도커가 blue, green 이미 2개 뛰워져있고, nginx가 전환이 안되있을 경우(서버에 들어가서 바꿀 경우) -> confirm 에도 health check 로직을 넣어서 해당 버전을 지워도 되는지 확인.

✨ 목적 Blue-Green 배포를 사용하는 경우, 두 슬롯(blue/green)에 서로 다른 버전의 Docker 컨테이너가 동시에 떠 있는 상태에서 배포가 이루어집니다. 새 버전이 성공적으로 배포되고 안정성이 확인되면, 이전 버전은 삭제해주는 것이 좋습니다. 이 글

이 문서는 EKS (Amazon Elastic Kubernetes Service) 클러스터 환경에서 애플리케이션에 필요한 민감한 시크릿 값(예: 데이터베이스 비밀번호, API 키)과 비민감 환경 변수를 안전하고 자동화된 방식으로 주입하는 전체 과정을 상세히 설명합니다.