개발자 미연

시나공 빅데이터분석기사 실기 Python 교재 리뷰: 시나공 Python 교재 첫인상과 학습 계획

422haha — Sat, 31 May 2025 21:09:16 +0900

안녕하세요! 이번 포스팅에서는 빅데이터분석기사 실기 시험을 준비하며 활용 중인 시나공 Python 교재의 첫인상과 앞으로의 학습 계획을 공유해보려 합니다.

필기 시험은 최근에 응시해 합격하였으며, 이제 실기 시험 대비를 본격적으로 시작하게 되었습니다.

현재 데이터 분석 역량을 강화하고, 취업 시장에서 경쟁력을 높이기 위해 빅데이터분석기사 자격증을 준비하고 있습니다. 이 자격증은 국가공인 자격으로, 실무 중심의 코딩 역량과 데이터 분석 능력을 종합적으로 평가합니다.

단순한 개념 암기형 시험이 아니라 실제 데이터를 다루고 문제를 해결하는 능력이 요구되기 때문에, 데이터 기반 사고력과 실전 감각을 함께 키울 수 있는 기회라고 판단하여 도전하게 되었습니다.

또한 이 자격증은 데이터 분석 전문가로서의 전문성과 신뢰성을 공식적으로 입증할 수 있는 수단이기도 합니다.

기업의 데이터 기반 의사결정에 기여할 수 있는 인재로 성장하고자, 실력을 쌓기 위한 준비를 본격적으로 시작했습니다.

학습 방향이 막막했을 때 도움이 된 시나공

실기 시험을 처음 준비하면서 가장 막막했던 부분은 무엇부터 시작해야 할지 전혀 감이 잡히지 않았다는 점이었습니다.

시험 유형도 낯설고, 어떤 문제들이 출제되는지조차 알기 어려웠던 상황에서 시나공 빅데이터분석기사 실기 교재는 훌륭한 출발점이 되어주었습니다.

단순히 이론만 나열하는 구성이 아니라, 작업형 1, 2, 3 유형별로 어떻게 접근해야 하는지를 명확하게 안내해 주어 처음 준비하는 입장에서도 학습의 방향을 설정하는 데 많은 도움이 되었습니다.

2주 단기 집중 루틴으로 학습

시험까지 여유가 많지 않은 만큼, 아래와 같은 일정으로 2주간 집중 학습 루틴을 계획하고 있습니다.

1주차

작업형 1, 2, 3 유형별 개념 구조 정리
pandas, seaborn, 머신러닝 기본 문법 복습
확인문제와 실습을 병행하며 흐름 익히기

2주차

예시문제 및 기출 문제 반복 풀이
오답 정리 및 시간 안배 연습
작업형 3 집중 학습 (모델 구현 및 평가 중심)

이 루틴은 시나공 교재의 구성과도 잘 맞습니다.

개념 → 확인문제 → 예시문제 → 최신 기출 문제로 이어지는 흐름이 자연스럽고, 반복 학습을 유도해 실전 감각을 빠르게 끌어올리는 데 효과적이라고 느꼈습니다.

시나공 빅데이터분석기사 실기 Python의 장점

입문자도 따라가기 쉬운 설명 방식
Python 문법이 익숙하지 않은 경우에도, 코드 흐름을 자연스럽게 따라갈 수 있도록 구성되어 있었습니다.

작업형 유형별 전략 제시
유형별 접근법이 명확하게 정리되어 있어, 학습 방향을 설정하는 데 큰 도움이 되었습니다.

셀 단위 실행 결과 확인
코드를 직접 실행해보며 셀 단위로 결과를 확인할 수 있어, 실습 기반 학습과 실전 대비에 효과적이었습니다.

최신 기출 경향 반영
최근 4개년 기출 문제가 수록되어 있어 출제 경향을 파악하고 실제 시험을 대비하는 데 도움이 되었습니다.

마무리

아직 실기 시험은 치르지 않았지만, 그 전 단계에서 학습 흐름을 정리하고 실전 준비의 기반을 마련하는데 시나공 교재가 큰 도움이 되었습니다. 혼자 준비하는 입장에서도 학습 방향을 명확히 설정할 수 있었고, 앞으로 2주 동안 이 교재를 중심으로 전략적인 학습을 이어갈 예정입니다.

데이터 분석 실력을 체계적으로 정리하고 자격증으로 역량을 입증하고자 한다면, 시나공 빅데이터분석기사 실기 교재가 좋은 출발점이 될 수 있을 것입니다.

빅데이터분석기사 실기 시험을 준비하시는 분들께 도움이 되었길 바라며, 저도 열심히 공부해서 좋은 결과로 이어지길 기대해봅니다!

본 포스팅은 업체로부터 제품을 제공받아 학습 후 솔직한 후기를 작성했습니다.

데이터에듀 2025 ADsP 민트책 리뷰: 데이터분석 준전문가 합격을 위한 교재 선택 가이드

422haha — Thu, 24 Apr 2025 10:45:59 +0900

안녕하세요! 이번 포스팅에서는 데이터 분석 준전문가(ADsP) 자격증을 준비하며 사용 중인 데이터에듀 2025 ADsP 민트책에 대한 학습 후기와 인상을 공유하려고 합니다.

ADsP는 데이터 분석 분야의 입문 단계에서 많이 선택하는 자격증입니다. 저 역시 체계적인 공부를 위해 어떤 교재를 사용할지 고민하다가 이 민트색 교재를 선택하게 되었습니다.

데이터에듀 2025 ADsP 민트책의 장점

1. 최신 출제 경향 반영

10년 연속 ADsP 베스트셀러라는 타이틀답게, 한국데이터베이스진흥원의 공식 가이드를 기반으로 최근 기출 트렌드를 잘 반영하고 있습니다.
개념 설명이 단순 나열이 아닌 시험에 나올 수 있는 방식으로 구성되어 있어 읽는 흐름이 매우 자연스럽습니다.

2. 풍부한 문제 구성과 명쾌한 해설

총 1,311문제가 수록되어 있는데요, 기출 복원 문제, 모의고사, 개념 체크 문제가 다양하게 구성되어 있어 반복 학습이 가능합니다.
특히 절마다 핵심 요약 → 문제 풀이 순서가 이어져서 학습 리듬을 유지하기 좋았습니다.

3. 모바일 앱을 통한 자투리 학습

QR 코드를 찍으면 연결되는 앱 데이터에듀PT 은 학습 효율을 높이는 데 큰 도움이 됐습니다.
이론정복강의는 총 16시간 분량인데, 절마다 짧게 끊어져 있어 자투리 시간에 빠르게 개념을 정리할 수 있습니다.

AI 해설 봇인 비기봇을 통해 잘 이해되지 않았던 문제에 대한 해설도 바로 확인할 수 있어서 개인적으로 정말 만족하고 있습니다.

4. 시험 직전 요약용 'D-7 합격마법노트'

아직 본격적인 마무리 학습 단계는 아니지만, 부록으로 제공되는 합격마법노트를 미리 살펴보았는데요, 시험 전 7일 동안 회독하기 좋게 구성이 되어 있어 벌써부터 기대가 됩니다.

5. 설치 없는 웹 기반 R 실습

R 실습도 별도 설치 없이 가능한 웹 기반 환경 코드러닝 을 통해 부담 없이 연습할 수 있었습니다.

마무리

아직 시험을 치르기 전이지만, 현재까지의 학습 만족도는 매우 높습니다.
개념 설명, 문제 구성, 모바일 학습 환경까지 전반적으로 잘 설계된 교재라고 느껴졌습니다.
특히 시간을 효율적으로 쓰고 싶은 분들에게 추천드릴 만한 책입니다.

ADsP 시험을 준비하시는 분들께 도움이 되었길 바라며, 저도 열심히 공부해서 좋은 결과로 이어지길 기대해봅니다!

이 서평은 데이터에듀로부터 도서를 제공받아 작성된 솔직한 후기입니다.

Git Merge, Rebase, Squash: 차이점과 적합한 사용 사례 비교

422haha — Fri, 17 Jan 2025 17:12:22 +0900

안녕하세요! 이번 포스팅에서는 Git의 Merge, Rebase, Squash라는 세 가지 주요 기능을 비교하고, 각각의 적합한 상황에 대해 알아보겠습니다.

Git은 강력한 버전 관리 도구로, 브랜치 전략과 히스토리 관리가 중요한 협업 환경에서 큰 역할을 합니다. 이 글을 통해 Merge, Rebase, Squash의 차이점을 명확히 이해하고, 프로젝트에 맞는 전략을 선택하는 데 도움을 드리고자 합니다.

1. Merge란 무엇인가?

특징

Merge는 두 개의 브랜치를 병합하여 새로운 커밋을 생성하는 방법입니다. 주로 기능 개발이 완료된 브랜치를 메인 브랜치에 병합할 때 사용됩니다.

예시

작업 브랜치 생성:
```
git checkout -b feature-branch
```
작업 완료 후 병합:
```
git checkout master
git merge feature-branch
```
결과적으로 새로운 병합 커밋이 생성됩니다.

장점

브랜치 히스토리를 그대로 유지하여 작업 내용을 명확히 파악 가능.
협업 환경에서 충돌이 적고 간단하게 병합 가능.

단점

병합 시마다 새로운 병합 커밋(Merge Commit)이 생성되어 히스토리가 복잡해질 수 있음.

2. Rebase란 무엇인가?

특징

Rebase는 브랜치의 베이스를 변경하여 히스토리를 재구성하는 방법입니다. 커밋들을 재정렬하여 병합 커밋 없이 깔끔한 히스토리를 유지합니다.

예시

작업 브랜치 생성 및 작업:
```
git checkout -b feature-branch
```
브랜치에서 커밋을 진행합니다.
Rebase 실행:
```
git checkout master
git pull origin master
git checkout feature-branch
git rebase master
```
이 과정에서 커밋 충돌이 발생할 수 있으며, 충돌 해결 후 git rebase --continue 명령을 실행합니다.

장점

히스토리를 선형으로 유지하여 가독성이 높아짐.
협업 시 변경 사항이 명확히 드러남.

단점

복잡한 충돌 해결 과정이 필요할 수 있으며, 잘못 사용할 경우 히스토리가 손상될 위험이 있음.

3. Squash란 무엇인가?

특징

Squash는 여러 개의 커밋을 하나로 합치는 방법으로, 병합 시점을 기준으로 이전 커밋들을 합쳐 새로운 단일 커밋을 생성합니다.

예시

작업 완료 후 Squash 실행:
```
git rebase -i master
```
이 명령으로 인터랙티브 모드가 열리면, 병합할 커밋 앞에 squash 또는 s를 지정합니다.
새 커밋 메시지 작성:
모든 병합된 커밋을 하나로 합친 후, 새로운 커밋 메시지를 작성합니다.

장점

불필요한 커밋을 제거하여 깔끔한 히스토리 유지.
작은 커밋을 다수 포함한 브랜치를 병합할 때 유용.

단점

커밋 히스토리가 단순화되면서 세부 변경 사항을 추적하기 어려움.

4. Merge, Rebase, Squash 비교

기능	특징	장점	단점
Merge	두 브랜치를 병합하여 새 커밋 생성	히스토리 유지, 충돌 관리 간단	병합 커밋 증가로 히스토리 복잡
Rebase	히스토리를 재정렬하여 병합 커밋 없음	선형 히스토리, 가독성 향상	충돌 해결이 복잡, 히스토리 손상 가능
Squash	여러 커밋을 하나로 합침	깔끔한 히스토리, 작은 커밋 정리	세부 변경 사항 추적 어려움

5. 프로젝트 상황에 따른 선택 가이드

Merge를 선택하세요:
- 히스토리를 그대로 유지해야 하는 대규모 협업 프로젝트.
- 각 작업의 진행 과정을 명확히 추적해야 하는 경우.
Rebase를 선택하세요:
- 선형 히스토리가 필요한 경우.
- 병합 커밋 없이 깔끔한 히스토리를 유지하고 싶을 때.
Squash를 선택하세요:
- 다수의 작은 커밋을 하나로 정리하여 병합 시 깔끔한 히스토리가 필요한 경우.
- 최종 병합 전 세부 작업 히스토리가 중요하지 않은 경우.

6. 최종 결론

Merge, Rebase, Squash는 각각의 강점과 단점이 있습니다. 프로젝트 특성과 협업 방식에 따라 적절히 선택하는 것이 중요합니다:

Merge: 안정성과 히스토리 보존.
Rebase: 깔끔하고 선형적인 히스토리.
Squash: 불필요한 커밋 정리로 간결한 히스토리.

여러분의 프로젝트 상황에 맞는 전략을 선택해 Git 히스토리를 더 효율적으로 관리해보세요!

참고 자료

감사합니다!

Git Flow vs GitHub Flow vs GitLab Flow: 브랜치 전략의 차이점과 선택 가이드

422haha — Fri, 10 Jan 2025 15:01:35 +0900

안녕하세요! 이번 포스팅에서는 Git Flow, GitHub Flow, GitLab Flow라는 세 가지 대표적인 Git 브랜치 전략을 비교하고, 각 방식이 어떤 환경에 적합한지 살펴보겠습니다.

프로젝트의 규모와 개발 방식에 따라 적합한 브랜치 전략을 선택하면 협업 효율성과 릴리즈 속도를 크게 향상시킬 수 있습니다. 이 글을 통해 여러분의 프로젝트에 적합한 브랜치 전략을 선택하는 데 도움을 드리고자 합니다.

1. Git Flow 개요

특징

Git Flow는 Vincent Driessen이 제안한 브랜칭 모델로, 복잡한 구조를 통해 대규모 프로젝트에서 명확하고 체계적인 개발 프로세스를 제공합니다.

브랜치 구조

master: 프로덕션 코드가 위치하는 브랜치로, 최종 릴리즈된 안정된 버전만 포함
develop: 개발 중인 코드를 통합하는 브랜치. 모든 새로운 기능이 여기에서 시작
feature: 특정 기능을 개발하기 위한 임시 브랜치로, 작업이 완료되면 develop 브랜치로 병합
release: 릴리즈 준비를 위한 브랜치로, 테스트 및 최종 검증 작업이 수행
hotfix: 긴급 수정이 필요한 경우 master 브랜치에서 파생되어 작업 후 다시 master와 develop에 병합

장점

명확한 브랜치 구조를 통해 안정성과 품질 유지
대규모 팀에서 각기 다른 작업을 분리하여 충돌 최소화

단점

브랜치 복잡도가 높아 관리가 어렵고 초보자에게는 부담될 수 있음
빠른 배포를 요구하는 환경에서는 비효율적

2. GitHub Flow 개요

특징

GitHub Flow는 간단하고 직관적인 브랜치 전략으로, Pull Request(PR)를 중심으로 협업합니다. 빠른 배포가 필요한 프로젝트에서 유용합니다.

브랜치 구조

master: 단일 브랜치로, 모든 코드가 배포 준비 상태를 유지
Feature 브랜치: 단기적인 작업을 위한 브랜치로, 작업 완료 후 PR을 통해 master에 병합

워크플로우

작업을 시작할 때 master에서 Feature 브랜치를 생성
기능 구현 및 테스트를 완료
PR을 생성하여 코드 리뷰 요청
리뷰가 완료되면 master에 병합
자동 배포 또는 수동 배포 수행

장점

간단한 구조로 사용이 용이하며 초보자도 쉽게 적용 가능
Pull Request 중심의 협업으로 코드 리뷰와 CI/CD 통합이 쉬움

단점

릴리즈 관리가 필요한 대규모 프로젝트에는 적합하지 않음
장기적인 기능 개발에는 비효율적일 수 있음

3. GitLab Flow 개요

특징

GitLab Flow는 GitHub Flow의 단순함을 유지하면서, CI/CD 파이프라인과 연계하여 배포 프로세스를 체계적으로 관리하는 전략입니다. 환경별 브랜치를 추가하여 다양한 배포 환경을 지원합니다.

브랜치 구조

master: 항상 프로덕션 배포 준비 상태를 유지
Feature 브랜치: 기능 개발용 브랜치
환경별 브랜치: staging, production과 같은 환경별 브랜치로 릴리즈 관리

워크플로우

Feature 브랜치에서 작업 시작
작업 완료 후 master에 병합
CI/CD 파이프라인이 자동으로 테스트와 빌드를 수행
staging 브랜치를 통해 테스트 환경에 배포
최종 검증 후 production 브랜치로 배포

장점

CI/CD와 자연스럽게 통합되며, 배포 프로세스가 명확
환경별 브랜치로 릴리즈와 배포를 체계적으로 관리 가능

단점

환경별 브랜치 관리로 인해 복잡도가 증가할 수 있음
소규모 팀이나 간단한 프로젝트에는 오히려 부담이 될 수 있음

4. 브랜치 전략 비교

전략	브랜치 구조	주요 특징	적합한 프로젝트
Git Flow	`master`, `develop`, `feature` 등	안정성 중시, 복잡한 구조	대규모 프로젝트, 안정성 중요 환경
GitHub Flow	`master`와 Feature 브랜치만 사용	간단한 구조, PR 중심 협업	소규모 프로젝트, 빠른 배포 환경
GitLab Flow	`master`, 환경별 브랜치(`staging` 등)	배포와 CI/CD 중심	중규모 프로젝트, 배포 프로세스 중시

5. 프로젝트 환경에 따른 선택 가이드

Git Flow를 선택하세요:
- 릴리즈 주기가 길고, 안정성이 중요한 대규모 프로젝트
- 여러 팀이 동시에 작업하며 기능별 분리가 필요한 경우
GitHub Flow를 선택하세요:
- 빠른 배포가 중요한 소규모 프로젝트
- 간단한 브랜치 구조와 PR 기반 협업을 선호하는 경우
GitLab Flow를 선택하세요:
- CI/CD 파이프라인과 연계한 배포가 중요한 프로젝트
- 환경별 브랜치 관리로 릴리즈를 체계적으로 관리하려는 경우

6. 최종 결론

세 가지 브랜치 전략은 각각의 장단점이 뚜렷하며, 프로젝트의 규모, 팀 구성, 릴리즈 주기 등 다양한 요소에 따라 적합성이 달라집니다.

Git Flow: 대규모 프로젝트에서 안정성을 중시할 때
GitHub Flow: 소규모 팀에서 빠른 배포와 간단한 협업을 원할 때
GitLab Flow: CI/CD와 배포 프로세스를 중시하는 환경에서

여러분의 프로젝트에 적합한 브랜치 전략을 선택해 협업과 릴리즈 관리의 효율성을 높여 보세요. 이번 포스팅이 선택에 도움이 되길 바랍니다!

참고 자료

감사합니다!

Git 커밋 컨벤션 가이드: 협업을 위한 베스트 프랙티스

422haha — Fri, 3 Jan 2025 17:28:31 +0900

안녕하세요! 이번 포스팅에서는 Git 커밋 컨벤션에 대해 알아보고, 협업 프로젝트에서 일관된 커밋 메시지를 작성하기 위한 베스트 프랙티스를 공유합니다.

깔끔하고 일관된 커밋 메시지는 협업 과정에서 팀원 간의 이해도를 높이고, 프로젝트 유지보수를 쉽게 만들어줍니다. 이 글을 통해 커밋 메시지 작성 규칙과 실무에서 바로 적용 가능한 팁을 얻어가시길 바랍니다!

1. Git 커밋 컨벤션이란?

Git 커밋 컨벤션은 협업 프로젝트에서 일관된 커밋 메시지를 작성하기 위한 규칙입니다. 이를 통해 다음과 같은 장점을 얻을 수 있습니다:

코드 변경의 히스토리를 명확하게 기록
코드 리뷰 과정에서 의사소통 원활화
자동화 도구(릴리즈 로그 생성, 테스트 실행 등)와의 통합 용이성

2. 커밋 메시지의 기본 구조

일반적으로 커밋 메시지는 다음과 같은 구조를 따릅니다:

<타입>(<스코프>): <짧은 설명>

<본문>

<푸터>

2.1 제목 (Title)

50자 이내로 작성
현재형 동사를 사용 (e.g., "Add", "Fix", "Update")
첫 글자는 대문자, 마침표는 사용하지 않음

2.2 본문 (Body)

변경 사항의 상세 설명을 작성
"무엇을", "왜" 변경했는지 중심으로 작성

2.3 푸터 (Footer)

버그 트래커 ID, Breaking Changes, 참조 정보를 포함

3. 대표적인 커밋 컨벤션 스타일

3.1 Conventional Commits

널리 사용되는 컨벤션으로, 제목에 타입과 스코프를 명시합니다.

예시:

feat(auth): Add JWT authentication support

This update implements JWT authentication for secure API access. Added token validation middleware.

타입 목록:

feat: 새로운 기능 추가
fix: 버그 수정
docs: 문서 수정
style: 코드 스타일 변경 (동작 변경 없음)
refactor: 코드 리팩토링
test: 테스트 추가 또는 수정
chore: 기타 변경 사항 (빌드, 설정 파일 등)

3.2 Gitmoji

이모지를 활용해 커밋 메시지의 목적을 시각적으로 표현합니다.

예시:

  feat: Add user profile feature
 ️ fix: Resolve login page bug

3.3 Custom 스타일

팀에서 별도로 정의한 규칙을 사용하기도 합니다. 프로젝트에 맞는 유연한 스타일을 채택하세요.

4. 협업을 위한 커밋 작성 베스트 프랙티스

의미 있는 단위로 커밋하기: 한 커밋에는 하나의 변경 사항만 포함.
현재형 동사 사용: "Added" 대신 "Add"와 같은 현재형 사용.
짧고 명확하게 작성: 제목은 50자, 본문은 필요 시 72자 단위로 줄바꿈.
팀 컨벤션 준수: 팀원 간 합의된 스타일 유지.
자동화 도구 활용: Linter나 pre-commit 훅으로 일관성 강제.

5. 커밋 메시지 작성 도구와 자동화

5.1 Commitizen

Conventional Commits 스타일로 커밋을 작성하도록 돕는 CLI 도구.

설치 및 사용:

npm install -g commitizen
commitizen init cz-conventional-changelog --save-dev --save-exact

5.2 Linting 도구

Husky를 사용해 pre-commit 훅으로 커밋 메시지 규칙 검사.

설치 및 설정:

npm install husky --save-dev
npx husky add .husky/commit-msg 'npx commitlint --edit "$1"'

최종 결론

일관된 Git 커밋 메시지 작성은 협업의 효율성을 높이고 프로젝트 관리에 큰 도움을 줍니다. 위에서 소개한 규칙과 도구를 활용하여 팀 내에서 통일된 컨벤션을 적용해 보세요. 더 나아가, 커밋 히스토리를 통해 과거의 변경 사항을 쉽게 이해하고 관리할 수 있습니다.

여러분의 프로젝트에서 효과적인 Git 사용이 이루어지길 바랍니다! 감사합니다.

Django vs Spring 비교: 프로젝트 환경에 맞는 백엔드 프레임워크 선택 가이드

422haha — Fri, 27 Dec 2024 14:12:05 +0900

안녕하세요! 이번 포스팅에서는 Django와 Spring의 특징을 비교하고, 각 프레임워크가 어떤 프로젝트 환경에 더 적합한지 정리해 보겠습니다.
백엔드 프레임워크 선택은 프로젝트의 규모, 팀 역량, 개발 언어 선호도 등에 따라 크게 달라질 수 있습니다.

Django: 파이썬(Python) 기반으로 간결한 문법과 빠른 프로토타이핑에 강점
Spring: 자바(Java) 기반으로 엔터프라이즈급 애플리케이션에서 검증된 안정성

이번 포스팅을 통해 어떤 프레임워크가 여러분의 프로젝트에 가장 적합한지 판단하는 데 도움이 되길 바랍니다!

1. Django와 Spring 개요

1.1 Django

파이썬(Python) 기반으로 빠른 개발과 유지보수가 용이합니다.
‘배터리가 포함된(Batteries Included)’ 철학으로, 웹 개발에 필요한 기능을 기본 제공하여 MVP나 프로토타입 제작에 유리합니다.
소규모부터 중규모 프로젝트까지, 빠른 프로토타이핑을 선호하는 팀에 적합합니다.

1.2 Spring

자바(Java) 기반으로, 엔터프라이즈급 애플리케이션 개발에 최적화되어 있습니다.
스프링 부트(Spring Boot), 스프링 시큐리티(Spring Security) 등 다양한 모듈을 통해 복잡한 기능을 세분화해 구축할 수 있습니다.
대규모 프로젝트와 여러 서버 인프라 환경에서 검증된 안정성과 확장성을 제공합니다.

2. 개발 언어 및 주요 특징 비교

2.1 Django (Python)

문법이 간결하고 직관적이어서, 파이썬 경험이 없는 초보자도 비교적 빠르게 학습할 수 있습니다.
파이썬 생태계를 통해 머신 러닝, 데이터 분석, 스크립트 자동화 등 다양한 분야와 연계가 용이합니다.
내장 관리자(Administration) 페이지 등을 제공해, 관리자 기능을 구현하기가 용이합니다.

2.2 Spring (Java)

정적 타입 언어로, 대규모 코드베이스에서 유지보수에 안정적입니다.
풍부한 오픈소스 라이브러리(예: Maven, Gradle)와의 호환성이 뛰어나며,
Spring Boot를 사용하면 기본 설정이 단순화되어 초반 세팅이 쉬워지지만, 여전히 엔터프라이즈급 확장성을 유지합니다.

3. 아키텍처와 MVC 패턴

3.1 Django

MTV(Model-Template-View) 패턴을 기반으로, 전통적인 MVC와 유사한 구조이지만 템플릿과 뷰가 조금 다른 개념으로 구분됩니다.
URL 패턴, 뷰, 모델, 템플릿 파일 구조가 명확해, 프로젝트 규모가 커져도 비교적 직관적으로 관리할 수 있습니다.

3.2 Spring

MVC(Model-View-Controller) 패턴을 기반으로,
의존성 주입(Dependency Injection), 제어의 역전(Inversion of Control) 등 스프링만의 특징을 통해 유연한 계층 아키텍처를 구성할 수 있습니다.
마이크로서비스 아키텍처(MSA)로 확장하기도 용이해, 대규모 엔터프라이즈 환경에서 널리 채택됩니다.

4. 생태계와 커뮤니티 지원

4.1 Django

파이썬 커뮤니티와 패키지 인덱스(PyPI)의 수많은 패키지를 활용할 수 있습니다.
Django 자체 문서와 오픈소스 튜토리얼, 예제 코드가 풍부해, 학습과 문제 해결이 비교적 수월합니다.

4.2 Spring

자바 생태계의 대표적 프레임워크로, 엔터프라이즈급 사례가 풍부합니다.
Stack Overflow, GitHub 등에서 Spring 관련 자료가 방대하게 축적되어 있으며,
세계적으로 가장 큰 자바 기반 커뮤니티 가운데 하나로 활발히 운영됩니다.

5. 데이터베이스 및 ORM 지원

5.1 Django

Django ORM을 통해 데이터베이스 연동을 간단하게 처리하며,
MySQL, PostgreSQL, SQLite 등 대부분의 관계형 DB에 쉽게 연결할 수 있습니다.
기본 ORM이 프레임워크에 내장되어 있어, 추가 설정 없이도 CRUD 작업을 빠르게 구현할 수 있습니다.

5.2 Spring

JPA(Java Persistence API)를 비롯해 Hibernate, MyBatis 등 다양한 ORM/매퍼를 선택해서 사용할 수 있습니다.
프로젝트 특성(고성능, 복잡한 쿼리, 기업 규격 등)에 맞춰 ORM 또는 SQL 매퍼를 자유롭게 구성할 수 있습니다.

6. 확장성 및 배포 환경

6.1 Django

Gunicorn, uWSGI 등을 활용해 간단히 웹 서버와 연동할 수 있으며,
Docker, Kubernetes 등을 통해 클라우드 환경으로 배포하기도 쉽습니다.
서버리스(Serverless) 환경(예: AWS Lambda)에서도 파이썬 함수 형태로 활용 가능해 확장성이 높습니다.

6.2 Spring

Jar 혹은 War 패키지 형태로 배포 가능하며, Spring Boot를 사용하면 실행 가능한 Jar로 쉽게 배포할 수 있습니다.
Kubernetes, Spring Cloud 등과 연계해 마이크로서비스 아키텍처로 확장이 수월하며,
엔터프라이즈 환경 표준으로 자리 잡아 운영 노하우가 풍부합니다.

7. 보안 및 인증

7.1 Django

CSRF 토큰, XSS 방어 등 기본적인 웹 보안 요소를 프레임워크 차원에서 제공합니다.
Django Rest Framework(DRF)와 연동하면 OAuth나 JWT 같은 인증 방식도 쉽게 구현 가능합니다.

7.2 Spring

Spring Security 모듈을 통해 세밀한 보안 정책을 구성할 수 있습니다.
OAuth2, JWT, LDAP, SAML 등 다양한 인증/인가 방식을 지원하며,
엔터프라이즈급 SSO(Single Sign-On) 환경 구축에도 강력한 기능을 제공합니다.

8. 학습 곡선과 팀 역량 고려

Django: 파이썬을 이미 알고 있거나, 간단한 웹 프로젝트를 빠르게 시작하고자 하는 팀에 유리합니다.
Spring: 자바 언어에 익숙하거나, 대규모 엔터프라이즈 수준의 프로젝트 경험을 보유한 팀에 적합합니다.

9. 최종 결론

Django: 빠른 프로토타이핑, 간결한 문법, 파이썬 생태계를 활용하고 싶은 소규모~중규모 웹 프로젝트에 권장됩니다.
Spring: 자바 기반의 안정성, 대규모 프로젝트 및 기업 환경에서 쌓인 운영 노하우가 필요한 엔터프라이즈급 프로젝트에 적합합니다.

이번 포스팅이 Django와 Spring 중 적절한 선택을 내리는 데 도움이 되셨길 바랍니다.
팀 역량과 프로젝트 규모, 그리고 배포 환경 등을 고려해 최적의 백엔드 프레임워크를 선택하시기 바랍니다!

참고 자료

주의 사항

프레임워크 선택 시 프로젝트 요구 사항, 팀 전문성, 확장성 등을 신중히 고려하시기 바랍니다.
Django와 Spring 모두 지속적으로 버전이 업데이트되고 있으므로, 라이브러리 호환성과 릴리즈 노트를 꾸준히 확인하세요.

이제 Django와 Spring의 특성을 잘 이해하고, 여러분의 프로젝트 환경에 맞춰 최고의 백엔드 프레임워크를 선택해 보시길 바랍니다. 성공적인 개발을 응원합니다!

유니티 vs 언리얼 엔진 비교: 프로젝트 환경에 맞는 게임 엔진 선택 가이드

422haha — Tue, 17 Dec 2024 13:15:54 +0900

안녕하세요! 이번 포스팅에서는 유니티(Unity)와 언리얼 엔진(Unreal Engine)의 특징을 비교하고, 각 엔진이 어떤 프로젝트 환경에 더 적합한지 정리해 보겠습니다. 게임 엔진 선택은 프로젝트의 규모, 목표 품질, 개발팀 역량에 따라 달라질 수 있습니다.

유니티(Unity)는 비교적 진입 장벽이 낮아 소규모 팀과 2D/모바일 게임에 적합합니다.
언리얼 엔진(Unreal Engine)은 고급 그래픽과 대규모 AAA급 프로젝트에 강력한 성능을 제공합니다.

이번 포스팅을 통해 어떤 엔진이 여러분의 프로젝트에 가장 적합한지 판단하는 데 도움이 되길 바랍니다!

1. 유니티와 언리얼 엔진 개요

1.1 유니티(Unity)

가볍고 빠른 작업이 장점인 게임 엔진입니다.
2D/3D, 특히 모바일 게임 개발에 강점이 있습니다.
소규모 팀이나 1인 개발자에게 적합합니다.

1.2 언리얼 엔진(Unreal Engine)

고품질 3D 그래픽과 AAA급 프로젝트에 특화된 엔진입니다.
대규모 팀과 복잡한 프로젝트에 적합합니다.
초반 학습 곡선이 가파르지만 확장성과 퍼포먼스가 뛰어납니다.
게임뿐만 아니라 가상 프로덕션, 건축 시뮬레이션, 영화 제작 분야에도 활용됩니다.

2. 스크립팅 언어 및 비주얼 스크립팅 비교

2.1 유니티(Unity)

스크립팅 언어: C# 기반으로 배우기 쉽고 접근성이 높습니다.
비주얼 스크립팅: 기존 Bolt를 기반으로 현재는 Unity Visual Scripting으로 통합되었으며, 기능이 꾸준히 개선되고 있습니다.
비프로그래머 직군도 빠르게 접근 가능합니다.

2.2 언리얼 엔진(Unreal Engine)

스크립팅 언어: C++ 기반으로 고성능과 최적화를 제공하지만, 학습 곡선이 가파르고 초보자에게는 진입 장벽이 있습니다.
비주얼 스크립팅: 블루프린트(Blueprint)를 통해 프로그래머 없이도 로직 구현이 가능합니다.
신규 Verse 언어 도입 예정으로 확장성이 강화될 예정입니다.

3. 2D 및 3D 지원 범위

3.1 유니티(Unity)

2D 게임 개발에 특화된 기능을 제공합니다.
3D 게임도 문제없이 개발 가능하지만 고품질 그래픽을 구현하려면 추가 최적화가 필요할 수 있습니다.

3.2 언리얼 엔진(Unreal Engine)

3D 그래픽에 특화되어 고사양 프로젝트에 강력한 성능을 제공합니다.
2D 기능은 상대적으로 부족하지만 Paper2D를 통해 2D 게임 개발이 가능합니다.

4. 애셋 마켓플레이스 비교

4.1 유니티 애셋 스토어

오랜 기간 축적된 방대한 애셋을 보유하고 있습니다.
저렴하고 다양한 애셋으로 인디팀이나 소규모 개발자에 적합합니다.

4.2 언리얼 엔진 Fab (구 마켓플레이스)

고품질 무료 애셋과 퀵셀 메가스캔이 통합되어 제공됩니다.
언리얼 엔진 사용자는 퀵셀 메가스캔을 무료로 활용할 수 있어 AAA급 프로젝트에 유리합니다.

5. 작업 속도 및 결과물 품질

프로젝트 규모	유니티(Unity)	언리얼 엔진(Unreal Engine)
소규모/2D	빠른 개발 및 경량화가 장점	다소 과도한 기능 제공
중간 규모	빠른 프로토타이핑 가능	고퀄리티 그래픽 구현 가능
대규모/3D	추가 최적화 필요	고급 기능과 성능 제공, AAA 프로젝트에 최적화

6. 프로젝트 규모 및 확장성

유니티(Unity): 가볍고 단순한 구조로 소규모 프로젝트에 유리하지만, 프로젝트가 커질수록 관리 부담이 커질 수 있습니다.
언리얼 엔진(Unreal Engine): 대규모 프로젝트와 복잡한 그래픽 작업에 최적화되어 있으며, 소스 코드 접근성을 통해 확장성과 커스터마이징이 뛰어납니다.

7. 한국어 지원 및 커뮤니티

유니티(Unity): 한국어 문서와 다양한 튜토리얼을 제공하며 커뮤니티가 활성화되어 있습니다.
언리얼 엔진(Unreal Engine): 한국어 문서가 있지만 일부 심화 내용은 영어 문서를 참고해야 합니다.

8. 보안 및 코드 접근성

유니티(Unity): IL2CPP를 통해 보안을 강화할 수 있지만, 완전히 안전하지는 않습니다.
언리얼 엔진(Unreal Engine): C++ 기반으로 보안이 강력하며, 엔진 소스 코드 접근이 가능해 커스터마이징에 유리합니다.

9. 최종 결론

유니티(Unity): 소규모 프로젝트, 2D 게임, 빠른 프로토타이핑에 유리합니다.
언리얼 엔진(Unreal Engine): 대규모 프로젝트, AAA급 게임, 고품질 그래픽에 강력한 성능을 제공하며, 비게임 분야에서도 활용됩니다.

이번 포스팅이 유니티(Unity)와 언리얼 엔진(Unreal Engine) 중 적절한 선택을 내리는 데 도움이 되셨길 바랍니다. 프로젝트 환경과 목표에 맞는 엔진을 선택하여 성공적인 게임 개발을 시작해 보세요!

참고 자료:

주의 사항:

엔진 선택 시 프로젝트의 요구 사항과 팀의 역량을 충분히 고려하시기 바랍니다.
최신 엔진 업데이트와 커뮤니티 동향을 지속적으로 확인하는 것이 중요합니다.

이제 유니티(Unity)와 언리얼 엔진(Unreal Engine)의 특성을 잘 이해하고, 여러분의 프로젝트에 가장 적합한 엔진을 선택하여 성공적인 게임 개발을 진행해 보세요!

GitLab에서 GitHub로 미러링 시 민감 정보 안전하게 제거하기

422haha — Wed, 20 Nov 2024 15:47:19 +0900

안녕하세요! 이번 포스팅에서는 GitLab에서 GitHub로 리포지토리를 미러링하면서 발생할 수 있는 민감 정보 제거 방법을 안내드립니다. 프로젝트를 이전하거나 협업 환경을 변경할 때, Git 히스토리에서 민감한 정보가 유출되지 않도록 처리하는 방법을 단계별로 살펴보겠습니다.

1. GitHub에 Private 리포지토리 생성

GitHub에 접속하여 로그인합니다.
오른쪽 상단 + 아이콘 클릭 → New Repository 선택.
리포지토리 설정:
- Repository name: 원하는 이름 입력. 예: YOGANAVI-temp.
- Privacy: Private 선택.
- Initialize this repository with a README: 초기화 없이 생성.
Create repository 클릭.

2. GitLab 리포지토리 미러링

GitLab 리포지토리를 GitHub로 미러링합니다.

git clone --mirror https://lab.ssafy.com/s11-webmobile4-sub2/S11P12D210.git
cd S11P12D210.git/
git push --mirror https://github.com/422haha/YOGANAVI-temp.git

3. 미러링된 리포지토리 클론

GitHub로 미러링된 리포지토리를 로컬에 클론합니다.

git clone https://github.com/422haha/YOGANAVI-temp.git

4. `.gitignore` 업데이트 및 민감 파일 제거

.gitignore를 업데이트하고 민감 파일을 제거합니다.

브랜치 체크아웃:
git checkout dev-backend
.gitignore 업데이트:
- 아래 내용을 추가:
- /.gradle /.idea /out /build *.iml *.ipr *.iws local.properties
파일 제거:
git add . git commit -m "Update .gitignore" git push origin dev-backend

5. BFG Repo-Cleaner로 민감 파일 기록 제거

BFG Repo-Cleaner를 사용하여 Git 기록에서 민감한 파일을 완전히 제거합니다.

BFG 다운로드 및 이동:
- 여기에서 bfg-1.14.0.jar 파일을 다운로드합니다.
- 프로젝트 루트 디렉토리로 파일을 이동합니다.
민감 파일 제거 명령어 실행:
java -jar bfg-1.14.0.jar --delete-files application.properties java -jar bfg-1.14.0.jar --delete-files local.properties

6. Git 저장소 정리

BFG 실행 후 저장소를 정리합니다.

git reflog expire --expire=now --all
git gc --prune=now --aggressive

7. 변경사항 강제 푸시

변경된 내용을 강제로 푸시합니다.

git push origin --force --all
git push origin --force --tags

8. Git 최종 정리

최종적으로 저장소에서 민감 정보가 완전히 제거되었는지 확인 후, 추가적인 정리를 진행합니다.

rm -rf .git/refs/original/
git reflog expire --expire=now --all
git gc --prune=now --aggressive
git push origin --force --all
git push origin --force --tags

9. 참고 자료 및 결론

이번 포스팅에서는 GitLab에서 GitHub로 리포지토리를 미러링하면서 민감 정보를 안전하게 제거하는 과정을 안내드렸습니다. 프로젝트를 공유하거나 협업하는 과정에서 민감한 정보가 노출되지 않도록 사전 조치를 취하는 것이 중요합니다.

참고 자료:

주의 사항:

작업 전에 백업을 권장합니다.
민감 정보 제거 후 Git 히스토리에 변경사항이 정확히 적용되었는지 확인하세요.

감사합니다!

GitLab에서 GitHub로 리포지토리 미러링

422haha — Wed, 20 Nov 2024 14:19:43 +0900

안녕하세요! 이번 포스팅에서는 GitLab에서 GitHub으로 리포지토리를 미러링하는 방법에 대해 상세히 설명드리겠습니다. 프로젝트를 관리하거나 협업 환경을 GitHub으로 이전하고자 할 때 유용하게 활용할 수 있는 방법으로, GitLab과 GitHub의 기본적인 차이점부터 실제 미러링 과정까지 단계별로 안내해 드립니다. 초보자도 쉽게 따라 할 수 있도록 각 단계별 명령어와 설정 방법을 포함하고 있습니다.

저희 프로젝트는 다양한 협업 도구와 플랫폼을 활용하여 효율적으로 개발을 진행하고 있습니다. 이번 포스팅을 통해 GitLab에서 GitHub으로의 원활한 이전 과정을 경험해보세요!

1. GitHub에서 Private 리포지토리 생성

먼저, GitHub에서 미러링할 대상인 Private 리포지토리를 생성합니다. Private 리포지토리는 공개되지 않으며, 권한이 있는 사용자만 접근할 수 있어 보안이 강화된 환경에서 프로젝트를 관리할 때 유용합니다.

1.1 GitHub 로그인

GitHub에 접속하여 계정에 로그인합니다.
오른쪽 상단의 + 아이콘을 클릭한 후 New repository를 선택합니다.

1.2 리포지토리 생성

Repository name: 원하는 리포지토리 이름을 입력합니다. 예: Arcana.
Description: 리포지토리에 대한 간단한 설명을 추가합니다. (선택 사항)
Privacy: Private을 선택하여 비공개 리포지토리를 생성합니다.
Initialize this repository with a README: 초기화는 하지 않습니다. (기존 GitLab 리포지토리를 미러링하기 위해서는 초기화를 하지 않는 것이 좋습니다.)
Create repository 버튼을 클릭하여 리포지토리를 생성합니다.

2. GitLab 리포지토리 미러링을 위한 클론

이제 GitLab에 존재하는 리포지토리를 미러링하기 위해 클론을 수행합니다. --mirror 옵션을 사용하면 모든 브랜치와 태그, 그리고 리모트 설정까지 포함한 완전한 미러링을 할 수 있습니다.

2.1 GitLab 리포지토리 클론

터미널을 열고 다음 명령어를 입력하여 GitLab 리포지토리를 미러링 클론합니다:

git clone --mirror https://lab.ssafy.com/s11-final/S11P31D103.git

설명:

git clone --mirror: 리포지토리의 모든 내용을 미러링하여 클론합니다.
https://lab.ssafy.com/s11-final/S11P31D103.git: 클론하려는 GitLab 리포지토리의 URL입니다.

클론이 완료되면 S11P31D103.git이라는 폴더가 생성됩니다.

3. 클론한 폴더로 이동

클론한 리포지토리 폴더로 이동하여 다음 단계를 진행합니다.

3.1 폴더 이동 명령어

cd S11P31D103.git

설명:

cd S11P31D103.git: 클론한 리포지토리 폴더로 이동합니다.

이제 GitLab 리포지토리의 모든 내용이 로컬에 미러링되어 저장되었습니다.

4. GitHub으로 미러링 푸시

미러링된 리포지토리를 GitHub의 Private 리포지토리로 푸시하여 이전을 완료합니다.

4.1 GitHub 리포지토리로 푸시

다음 명령어를 입력하여 미러링된 리포지토리를 GitHub으로 푸시합니다:

git push --mirror https://github.com/422haha/Arcana.git

설명:

git push --mirror: 모든 브랜치와 태그, 리모트 설정을 포함하여 푸시합니다.
https://github.com/422haha/Arcana.git: 푸시할 GitHub 리포지토리의 URL입니다.

주의 사항:

GitHub 리포지토리는 미리 생성되어 있어야 합니다.
푸시 과정에서 GitHub 계정의 인증 정보(아이디 및 패스워드 또는 토큰)를 입력해야 할 수 있습니다.

5. GitHub 설정에서 Default Branch 확인 및 변경

미러링이 완료된 후, GitHub 리포지토리의 기본 브랜치(Default Branch)를 확인하고 필요에 따라 변경합니다. 기본 브랜치는 새로 푸시된 리포지토리에서 자동으로 설정되지만, 특정 브랜치를 기본으로 지정하고 싶을 경우 변경할 수 있습니다.

5.1 GitHub 리포지토리 접속

웹 브라우저에서 GitHub에 접속합니다.
422haha 사용자 계정의 Arcana 리포지토리를 엽니다.

5.2 기본 브랜치 확인 및 변경

리포지토리 메인 페이지에서 오른쪽 상단의 Settings 탭을 클릭합니다.
좌측 사이드바에서 Branches를 선택합니다.
Default branch 섹션에서 현재 설정된 기본 브랜치를 확인할 수 있습니다.
기본 브랜치를 변경하고 싶다면 Change default branch 버튼을 클릭하여 원하는 브랜치를 선택합니다.

설명:

Default branch: 리포지토리의 기본 브랜치를 설정합니다. 새로운 풀 리퀘스트나 이슈가 생성될 때 기본적으로 참조되는 브랜치입니다.
Change default branch: 기본 브랜치를 변경할 수 있는 옵션입니다.

이번 포스팅에서는 GitLab에서 GitHub으로 리포지토리를 미러링하는 과정을 단계별로 상세히 설명드렸습니다. GitLab과 GitHub은 각각의 장점이 있으므로, 프로젝트의 요구 사항에 맞게 적절한 플랫폼을 선택하고, 원활한 이전 과정을 통해 효율적인 협업 환경을 구축하시기 바랍니다.

감사합니다!

참고 자료:

주의 사항:

민감한 정보(비밀번호, API 키 등)는 절대로 공개하지 않도록 주의하세요.
리포지토리 미러링 시 데이터 손실을 방지하기 위해 사전에 백업을 권장드립니다.
실제 운영 환경에서는 보안 설정을 더욱 강화하고, 권한 관리를 철저히 해야 합니다.

이제 GitLab에서 GitHub으로의 리포지토리 미러링을 통해 보다 유연하고 효율적인 협업 환경을 경험해보세요!

CI/CD 무중단 배포 구현 가이드: 블루-그린 배포를 통한 안정적인 애플리케이션 업데이트

422haha — Sun, 13 Oct 2024 22:47:17 +0900

안녕하세요! 이번 포스팅에서는 CI/CD 파이프라인을 구축하고 블루-그린 배포 방식을 적용하여 무중단 배포를 구현한 과정을 상세히 공유하고자 합니다. 이 글은 CI/CD를 처음 접하시는 분들도 따라 할 수 있도록 각 단계별로 명령어와 설정 파일을 포함하고 있으며, 필요한 개념에 대한 설명과 파일 생성 및 수정 방법까지 함께 제공합니다.

저희 프로젝트는 자연 탐험과 학습을 돕기 위한 게이미피케이션 기반의 AR/AI 동식물 탐험 애플리케이션인 "이게모야"입니다. 이번 포스팅을 통해 CI/CD 구축 과정에서 사용한 도구와 기술, 그리고 그 선택 이유를 자세히 설명하겠습니다.

프로젝트 소개
CI/CD 및 블루-그린 배포란?
환경 설정 및 초기 구성
Docker 및 Docker Compose 설치
DockerHub 이해하기
Jenkins 설치 및 설정
데이터베이스 및 캐시 서버 설치
프로젝트 Docker화 및 Docker Compose 파일 작성
Nginx 설정 및 무중단 배포 구현
Jenkins 파이프라인 설정
SonarQube를 통한 코드 품질 관리
보안 강화 설정 (Fail2Ban 및 ModSecurity)
마무리 및 개선 사항

1. 프로젝트 소개

"이게모야"는 사용자가 실제 공원을 탐험하며 동식물 정보를 수집하고, AR 기술과 AI를 활용하여 자연과 상호작용할 수 있는 애플리케이션입니다.

주요 기능
- 온디바이스 AI 기반 실시간 동식물 판별: 사용자가 촬영한 동식물 이미지를 기기 내에서 AI 모델을 통해 실시간으로 판별합니다.
- AR을 활용한 네비게이션: AR 기술을 통해 공원 내에서 사용자에게 길 안내 및 위치 정보를 제공합니다.
- LLM(대규모 언어 모델)을 활용한 동식물 정보 제공: 사용자가 질문하면 AI가 동식물에 대한 상세 정보를 제공합니다.
- Redis를 활용한 실시간 데이터 캐싱: 사용자의 위치 데이터와 탐험 정보를 빠르게 처리하기 위해 Redis를 사용합니다.

2. CI/CD 및 블루-그린 배포란?

CI/CD란?

CI/CD는 Continuous Integration (지속적 통합)과 Continuous Deployment/Delivery (지속적 배포/전달)의 약어로, 소프트웨어 개발과 배포 과정을 자동화하여 효율성과 품질을 높이는 방법론입니다.

Continuous Integration (CI): 개발자들이 코드 변경 사항을 중앙 저장소에 자주 병합하여 자동으로 빌드하고 테스트하는 프로세스입니다. 이를 통해 코드의 품질을 유지하고, 통합 과정에서 발생할 수 있는 문제를 조기에 발견할 수 있습니다.
Continuous Deployment/Delivery (CD):
- Continuous Delivery: 자동화된 테스트를 거친 코드를 프로덕션 환경에 배포할 준비를 하는 단계입니다.
- Continuous Deployment: 테스트를 모두 통과한 코드를 자동으로 프로덕션 환경에 배포하는 단계입니다.

CI/CD의 장점:

빠른 피드백 루프: 코드 변경 사항이 즉시 빌드되고 테스트되므로 문제를 빠르게 발견하고 해결할 수 있습니다.
자동화된 배포: 배포 과정을 자동화하여 인적 오류를 줄이고, 배포 속도를 향상시킵니다.
지속적인 개선: 지속적인 통합과 배포를 통해 소프트웨어의 지속적인 개선과 업데이트가 가능합니다.

블루-그린 배포란?

블루-그린 배포는 두 개의 동일한 운영 환경(블루, 그린)을 사용하여 애플리케이션을 배포하는 방식입니다. 이를 통해 무중단 배포를 실현할 수 있습니다.

블루 환경: 현재 프로덕션에서 서비스 중인 환경입니다.
그린 환경: 새로운 버전의 애플리케이션을 배포하는 환경입니다.

배포 과정:

새로운 버전을 그린 환경에 배포하고 테스트합니다.
문제가 없으면 트래픽을 블루에서 그린으로 전환합니다.
이전 버전(블루 환경)은 대기 상태로 유지하거나 제거합니다.

장점:

무중단 배포: 사용자에게 서비스 중단 없이 새로운 버전을 제공할 수 있습니다.
빠른 롤백: 문제가 발생할 경우, 이전 환경으로 빠르게 전환하여 롤백할 수 있습니다.

3. 환경 설정 및 초기 구성

CI/CD 구축을 위해 먼저 서버 환경을 설정하고 초기 구성을 진행해야 합니다.

1) 서버 접속 및 기본 설정

AWS EC2 인스턴스(Ubuntu 20.04 LTS)에 접속하여 기본적인 업데이트와 설정을 진행합니다.

1.1 서버 업데이트 및 업그레이드

# 서버 업데이트 및 업그레이드
sudo apt update
sudo apt upgrade -y

설명:

sudo apt update: 패키지 목록을 업데이트합니다.
sudo apt upgrade -y: 설치된 패키지를 최신 버전으로 업그레이드합니다.

1.2 필수 빌드 도구 설치

# 필수 빌드 도구 설치
sudo apt install -y build-essential

설명:

sudo apt install -y build-essential: 빌드에 필요한 도구들을 설치합니다.

1.3 시간대를 한국 시간대로 설정

# 시간대를 한국 시간대로 설정
sudo ln -sf /usr/share/zoneinfo/Asia/Seoul /etc/localtime

# 시간 확인
date

설명:

sudo ln -sf /usr/share/zoneinfo/Asia/Seoul /etc/localtime: 서버의 시간대를 한국 시간대로 설정합니다.
date: 현재 서버의 시간을 확인합니다.

2) 사용자 권한 설정

Docker 명령을 사용할 때 매번 sudo를 사용하지 않도록 현재 사용자를 Docker 그룹에 추가합니다.

2.1 현재 사용자 Docker 그룹에 추가

# 현재 사용자 Docker 그룹에 추가
sudo usermod -aG docker $USER

설명:

sudo usermod -aG docker $USER: 현재 사용자를 Docker 그룹에 추가하여 Docker 명령을 sudo 없이 실행할 수 있게 합니다.

2.2 변경 사항 적용을 위해 로그아웃 후 재로그인

# 현재 세션에서 로그아웃
exit

설명:

변경 사항을 적용하기 위해 현재 SSH 세션에서 로그아웃하고 다시 로그인합니다.

4. Docker 및 Docker Compose 설치

Docker는 애플리케이션을 컨테이너화하여 일관된 환경에서 실행할 수 있게 해줍니다. Docker Compose는 여러 개의 Docker 컨테이너를 정의하고 실행할 수 있게 해주는 도구입니다.

1) Docker 설치

# 필요한 패키지 설치
sudo apt-get update
sudo apt-get install -y \
  ca-certificates \
  curl \
  gnupg \
  lsb-release

설명:

Docker 설치에 필요한 패키지들을 설치합니다.

1.2 Docker의 공식 GPG 키 추가

# Docker의 공식 GPG 키 추가
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

설명:

Docker 공식 GPG 키를 추가하여 패키지의 신뢰성을 확보합니다.

1.3 Docker 저장소 추가

# Docker 저장소 추가
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] \
  https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

설명:

Docker 저장소를 추가합니다.

1.4 Docker 엔진 설치

# Docker 엔진 설치
sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io

설명:

Docker 엔진을 설치합니다.

1.5 Docker 설치 확인

# Docker 버전 확인
docker --version

설명:

설치된 Docker의 버전을 확인합니다.

2) Docker Compose 설치

sudo apt-get install -y docker-compose

설명:

docker-compose는 여러 Docker 컨테이너를 정의하고 관리하는 데 사용됩니다.

설치 확인

docker-compose --version

5. DockerHub 이해하기

DockerHub는 Docker 컨테이너 이미지를 저장하고 공유할 수 있는 클라우드 기반 레지스트리 서비스입니다. 개발자들은 DockerHub를 통해 자신이 만든 이미지를 업로드하고, 다른 사람들이 이를 다운로드하여 사용할 수 있습니다.

DockerHub의 주요 기능

이미지 저장소: Docker 이미지를 저장하고 관리할 수 있는 공간을 제공합니다.
공개 및 비공개 저장소: 공개 저장소를 통해 누구나 이미지를 볼 수 있으며, 비공개 저장소를 통해 특정 사용자만 접근할 수 있습니다.
자동 빌드: GitHub나 Bitbucket과 연동하여 코드 변경 시 자동으로 Docker 이미지를 빌드할 수 있습니다.
협업 기능: 팀 단위로 이미지를 관리하고 협업할 수 있는 기능을 제공합니다.

DockerHub 사용 이유

손쉬운 이미지 배포: 전 세계 어디서나 접근 가능한 중앙 저장소를 통해 이미지를 쉽게 배포하고 공유할 수 있습니다.
자동화된 워크플로우: 자동 빌드와 연동 기능을 통해 CI/CD 파이프라인과 원활하게 통합할 수 있습니다.
버전 관리: 이미지의 다양한 버전을 관리하고 추적할 수 있습니다.

DockerHub 계정 생성 및 이미지 푸시

5.1 DockerHub 계정 생성

DockerHub에 접속하여 계정을 생성합니다.
계정을 생성한 후, 로그인합니다.

5.2 로컬에서 Docker 이미지 빌드 및 DockerHub에 푸시

5.2.1 DockerHub에 로그인

# DockerHub에 로그인
docker login -u your_dockerhub_username -p your_dockerhub_password

설명:

DockerHub에 로그인하여 인증을 받습니다.

5.2.2 Docker 이미지 태깅

# Docker 이미지 태깅
docker tag your_image:latest your_dockerhub_username/moya:latest

설명:

로컬에서 빌드한 이미지를 DockerHub에 업로드할 수 있도록 태깅합니다.

5.2.3 DockerHub에 이미지 푸시

# DockerHub에 이미지 푸시
docker push your_dockerhub_username/moya:latest

설명:

태깅한 이미지를 DockerHub에 푸시하여 저장소에 업로드합니다.

참고:

DockerHub의 저장소 이름은 your_dockerhub_username/repository_name:tag 형식을 따릅니다.
개인 프로젝트는 비공개 저장소로 설정할 수 있으며, 팀 프로젝트는 협업 기능을 활용할 수 있습니다.

6. Jenkins 설치 및 설정

Jenkins는 오픈 소스 자동화 서버로, CI/CD 파이프라인을 구축하는 데 사용됩니다. Jenkins를 사용하면 코드의 빌드, 테스트, 배포 과정을 자동화할 수 있습니다.

1) Jenkins 설치

6.1 Jenkins 데이터 저장 디렉토리 생성

# Jenkins 데이터 저장 디렉토리 생성
mkdir -p ~/jenkins

설명:

Jenkins 데이터를 호스트의 ~/jenkins 디렉토리에 저장하여 컨테이너 재시작 시 데이터 유실을 방지합니다.

6.2 Jenkins 컨테이너 실행

# Jenkins 컨테이너 실행
sudo docker run -d \
  -p 9090:8080 \
  -p 50000:50000 \
  --name jenkins \
  -v ~/jenkins:/var/jenkins_home \
  -v /var/run/docker.sock:/var/run/docker.sock \
  jenkins/jenkins:jdk17

설명:

-p 9090:8080: 호스트의 9090 포트를 컨테이너의 8080 포트에 매핑하여 Jenkins UI에 접근할 수 있게 합니다.
-p 50000:50000: Jenkins 에이전트 통신을 위한 포트를 매핑합니다.
-v ~/jenkins:/var/jenkins_home: Jenkins 데이터를 호스트의 ~/jenkins 디렉토리에 저장합니다.
-v /var/run/docker.sock:/var/run/docker.sock: Jenkins가 Docker를 제어할 수 있도록 Docker 소켓을 마운트합니다.

2) Jenkins 초기 설정

6.3 Jenkins 초기 비밀번호 확인

# Jenkins 초기 비밀번호 확인
sudo docker exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword

설명:

초기 비밀번호를 확인한 후, 웹 브라우저에서 http://[서버 IP]:9090으로 접속하여 Jenkins 초기 설정을 완료합니다.
기본 계정(admin)으로 로그인하고, 비밀번호를 변경합니다.
필요한 플러그인들을 설치합니다.

3) Jenkins에서 Docker 사용 권한 설정

6.4 Jenkins 컨테이너에서 root 사용자로 접속

# Jenkins 컨테이너에서 root 사용자로 접속
sudo docker exec -it --user root jenkins bash

설명:

Jenkins 컨테이너에 root 사용자로 접속하여 Docker 그룹에 Jenkins 사용자를 추가합니다.

6.5 Docker 그룹에 Jenkins 사용자 추가

# Docker 그룹에 Jenkins 사용자 추가
usermod -aG docker jenkins

설명:

usermod -aG docker jenkins: Jenkins 사용자를 Docker 그룹에 추가하여 Docker 명령을 sudo 없이 실행할 수 있게 합니다.

6.6 컨테이너에서 나와 Jenkins 재시작

# 컨테이너에서 나와 Jenkins 재시작
exit
sudo docker restart jenkins

설명:

컨테이너에서 나와 Jenkins를 재시작하여 변경 사항을 적용합니다.

4) Maven 설치

Jenkins에서 Maven 빌드를 수행하기 위해 Maven을 설치합니다.

6.7 Jenkins 컨테이너에서 root 사용자로 접속

# Jenkins 컨테이너에서 root 사용자로 접속
sudo docker exec -it --user root jenkins bash

6.8 Maven 설치

# Maven 설치
apt-get update
apt-get install -y maven

설명:

Maven을 설치하여 Java 프로젝트를 빌드할 수 있게 합니다.

6.9 Maven 설치 디렉토리 권한 설정

# Maven 설치 디렉토리 권한 설정
chown -R jenkins:jenkins /usr/share/maven

설명:

Maven 디렉토리의 소유권을 Jenkins 사용자로 변경하여 권한 문제를 방지합니다.

6.10 Maven 버전 확인

# Maven 버전 확인
su jenkins
mvn --version

설명:

Maven이 올바르게 설치되었는지 확인합니다.

6.11 컨테이너에서 나와 Jenkins 재시작

# 컨테이너에서 나와 Jenkins 재시작
exit
sudo docker restart jenkins

설명:

컨테이너에서 나와 Jenkins를 재시작하여 변경 사항을 적용합니다.

7. 데이터베이스 및 캐시 서버 설치

애플리케이션의 데이터 저장과 빠른 데이터 접근을 위해 PostgreSQL과 Redis를 설치합니다.

1) PostgreSQL 설치 및 설정

PostgreSQL은 강력한 오픈 소스 관계형 데이터베이스 관리 시스템입니다. PostGIS는 PostgreSQL의 공간 확장 모듈로, 지리 공간 데이터를 처리할 수 있습니다.

7.1 PostgreSQL Docker 컨테이너 실행

# PostgreSQL Docker 컨테이너 실행
docker run -d \
  -p 5432:5432 \
  -v /var/lib/postgres-data:/var/lib/postgresql/data \
  --name postgres \
  -e POSTGRES_PASSWORD=your_password \
  postgres:14

설명:

-p 5432:5432: 호스트의 5432 포트를 컨테이너의 5432 포트에 매핑합니다.
-v /var/lib/postgres-data:/var/lib/postgresql/data: 데이터 지속성을 위해 호스트의 디렉토리를 마운트합니다.
-e POSTGRES_PASSWORD=your_password: PostgreSQL의 postgres 사용자 비밀번호를 설정합니다.

7.2 PostGIS 확장 설치

# PostgreSQL 컨테이너에 접속
docker exec -it postgres bash

설명:

PostgreSQL 컨테이너에 접속하여 PostGIS를 설치합니다.

# 패키지 목록 업데이트 및 PostGIS 설치
apt-get update
apt-get install -y postgis postgresql-14-postgis-3

설명:

PostGIS 확장을 설치하여 공간 데이터를 처리할 수 있게 합니다.

# PostgreSQL에 접속
psql -U postgres

설명:

PostgreSQL에 접속하여 데이터베이스를 생성하고 확장을 추가합니다.

-- 데이터베이스 생성
CREATE DATABASE moya;

-- moya 데이터베이스로 전환
\c moya

-- PostGIS 확장 추가
CREATE EXTENSION postgis;

설명:

CREATE DATABASE moya;: moya라는 이름의 데이터베이스를 생성합니다.
\c moya: moya 데이터베이스로 전환합니다.
CREATE EXTENSION postgis;: moya 데이터베이스에 PostGIS 확장을 추가합니다.

# PostgreSQL 컨테이너에서 나가기
exit

7.3 PostgreSQL 설정 파일 위치 확인 및 권한 설정

# PostgreSQL 데이터 디렉토리 권한 확인
ls -la /var/lib/postgresql/data

설명:

데이터 디렉토리의 권한을 확인하여 데이터가 안전하게 저장되고 있는지 확인합니다.

2) Redis 설치

Redis는 빠른 메모리 기반의 키-값 저장소로, 실시간 데이터 캐싱에 적합합니다.

# Redis Docker 컨테이너 실행
docker run -d \
  -p 6379:6379 \
  -v /var/lib/redis-data:/data \
  --name redis \
  redis:latest

설명:

-p 6379:6379: 호스트의 6379 포트를 컨테이너의 6379 포트에 매핑합니다.
-v /var/lib/redis-data:/data: 데이터 지속성을 위해 호스트의 디렉토리를 마운트합니다.

8. 프로젝트 Docker화 및 Docker Compose 파일 작성

프로젝트를 Docker 컨테이너화하여 일관된 환경에서 실행할 수 있도록 설정합니다.

1) 프로젝트 Dockerfile 작성

Spring Boot 애플리케이션을 Docker 이미지로 빌드하기 위한 Dockerfile을 작성합니다.

1.1 `Dockerfile` 생성 및 편집

파일 생성 위치: 프로젝트의 backend 디렉토리 내에 Dockerfile을 생성합니다.

# backend 디렉토리로 이동
cd backend

# Dockerfile 생성 및 편집
nano Dockerfile

설명:

cd backend: backend 디렉토리로 이동합니다.
nano Dockerfile: Dockerfile을 생성하고 편집합니다. (nano 대신 vi, vim 등 다른 편집기를 사용할 수도 있습니다.)

1.2 `Dockerfile` 내용 복사 및 저장

Dockerfile에 다음 내용을 복사하여 붙여넣습니다:

# backend/Dockerfile

# OpenJDK 17 슬림 버전 사용
FROM openjdk:17-jdk-slim

# 작업 디렉토리 설정
WORKDIR /app

# 필요한 패키지 설치
RUN apt-get update && apt-get install -y curl

# 시간대 설정
RUN ln -sf /usr/share/zoneinfo/Asia/Seoul /etc/localtime

# 애플리케이션 JAR 파일 복사
COPY target/moya-0.0.1-SNAPSHOT.jar app.jar

# 환경 변수 파일 복사
COPY .env .env

# Spring Boot 설정 파일 복사
COPY src/main/resources/application.properties application.properties
COPY src/main/resources/application-oauth-kakao.properties application-oauth-kakao.properties
COPY src/main/resources/application-oauth-naver.properties application-oauth-naver.properties

# 애플리케이션 실행
ENTRYPOINT ["java", "-jar", "app.jar"]

설명:

Base Image: OpenJDK 17 슬림 버전을 사용하여 Java 애플리케이션을 실행할 환경을 구성합니다.
WORKDIR: 컨테이너 내 작업 디렉토리를 /app으로 설정합니다.
RUN: 필요한 패키지인 curl을 설치하고, 시간대를 한국 시간대로 설정합니다.
COPY: 빌드된 JAR 파일과 환경 변수 파일, Spring Boot 설정 파일들을 컨테이너로 복사합니다.
ENTRYPOINT: 애플리케이션을 실행하는 명령어를 설정합니다.

1.3 `Dockerfile` 저장 및 종료

Nano에서 저장: Ctrl + O, Enter
Nano에서 종료: Ctrl + X

2) Docker Compose 파일 작성

블루-그린 배포를 위한 docker-compose.yml 파일을 작성합니다.

2.1 `docker-compose.yml` 생성 및 편집

파일 생성 위치: 프로젝트의 backend 디렉토리 내에 docker-compose.yml 파일을 생성합니다.

# backend 디렉토리로 이동
cd backend

# docker-compose.yml 파일 생성 및 편집
nano docker-compose.yml

설명:

cd backend: backend 디렉토리로 이동합니다.
nano docker-compose.yml: docker-compose.yml 파일을 생성하고 편집합니다.

2.2 `docker-compose.yml` 내용 복사 및 저장

docker-compose.yml에 다음 내용을 복사하여 붙여넣습니다:

# backend/docker-compose.yml

version: '3.8'

services:
  springboot-blue:
    image: your_dockerhub_username/moya:blue
    container_name: springboot-blue
    ports:
      - "8081:8080"
    env_file:
      - .env
    environment:
      - REDIS_HOST=redis
      - REDIS_PORT=6379
      - TZ=Asia/Seoul
    networks:
      - app-network
    restart: unless-stopped

  springboot-green:
    image: your_dockerhub_username/moya:green
    container_name: springboot-green
    ports:
      - "8082:8080"
    env_file:
      - .env
    environment:
      - REDIS_HOST=redis
      - REDIS_PORT=6379
      - TZ=Asia/Seoul
    networks:
      - app-network
    restart: unless-stopped

  redis:
    image: redis:latest
    container_name: redis
    ports:
      - "6379:6379"
    networks:
      - app-network
    restart: unless-stopped

  sonarqube:
    image: sonarqube:latest
    container_name: sonarqube
    ports:
      - "9000:9000"
    networks:
      - app-network
    restart: unless-stopped

  postgres:
    image: postgres:14
    container_name: postgres
    ports:
      - "5432:5432"
    volumes:
      - /var/lib/postgres-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_PASSWORD=your_password
    networks:
      - app-network
    restart: unless-stopped

  jenkins:
    image: jenkins/jenkins:jdk17
    container_name: jenkins
    ports:
      - "9090:8080"
      - "50000:50000"
    volumes:
      - ~/jenkins:/var/jenkins_home
      - /var/run/docker.sock:/var/run/docker.sock
    networks:
      - app-network
    restart: unless-stopped

networks:
  app-network:
    driver: bridge

설명:

Services:
- springboot-blue 및 springboot-green: 블루-그린 배포를 위한 두 개의 Spring Boot 애플리케이션 인스턴스입니다. 각기 다른 포트(8081, 8082)를 사용하여 동시에 실행됩니다.
- redis: 캐시 서버로 사용됩니다.
- sonarqube: 코드 품질 분석 도구인 SonarQube를 실행합니다.
- postgres: PostgreSQL 데이터베이스 서버를 실행합니다.
- jenkins: CI/CD 파이프라인을 관리하는 Jenkins 서버입니다.
Networks:
- app-network: 모든 서비스가 동일한 네트워크 내에서 통신할 수 있도록 설정합니다.

2.3 `docker-compose.yml` 저장 및 종료

Nano에서 저장: Ctrl + O, Enter
Nano에서 종료: Ctrl + X

3) Docker Compose 실행

# backend 디렉토리로 이동
cd backend

# Docker Compose 실행
docker-compose up -d

설명:

docker-compose up -d: 백그라운드에서 모든 서비스를 실행합니다.

4) 현재 Docker 컨테이너 상태 확인

docker ps -a

출력 결과 예시:

CONTAINER ID   IMAGE                         COMMAND                  CREATED        STATUS        PORTS                                       NAMES
ba605bb2fc66   your_dockerhub_username/moya:blue           "java -jar app.jar"      2 days ago     Up 2 days     0.0.0.0:8081->8080/tcp                      springboot-blue
bbb8bb79563b   your_dockerhub_username/moya:green          "java -jar app.jar"      2 days ago     Up 2 days     0.0.0.0:8082->8080/tcp                      springboot-green
3e789de5ad79   postgres:14                   "docker-entrypoint.s…"   2 weeks ago    Up 2 weeks    0.0.0.0:5432->5432/tcp                      postgres
d57bb671e670   redis:latest                  "docker-entrypoint.s…"   2 weeks ago    Up 2 weeks    0.0.0.0:6379->6379/tcp                      redis
7f31b90ff248   sonarqube:latest              "/opt/sonarqube/dock…"   2 weeks ago    Up 2 weeks    0.0.0.0:9000->9000/tcp                      sonarqube
b22097030b69   jenkins/jenkins:jdk17         "/usr/bin/tini -- /u…"   4 weeks ago    Up 2 weeks    0.0.0.0:9090->8080/tcp, 0.0.0.0:50000->50000/tcp  jenkins

설명:

각 컨테이너가 정상적으로 실행되고 있는지 확인합니다.
포트 매핑을 통해 외부에서 서비스에 접근할 수 있는지 확인할 수 있습니다.

9. Nginx 설정 및 무중단 배포 구현

Nginx는 리버스 프록시 서버로, 트래픽을 블루 또는 그린 환경으로 라우팅하여 무중단 배포를 구현합니다.

1) Nginx 설치 및 SSL 인증서 발급

1.1 Nginx 설치

# Nginx 설치
sudo apt-get update
sudo apt-get install nginx -y

설명:

웹 서버인 Nginx를 설치합니다.

1.2 UFW 방화벽 설정 (필요 시)

# UFW 방화벽에서 Nginx 트래픽 허용
sudo ufw allow 'Nginx Full'

# UFW 방화벽 활성화
sudo ufw enable

설명:

UFW 방화벽을 사용 중이라면 Nginx 트래픽을 허용합니다.

1.3 Let's Encrypt 설치 및 SSL 인증서 발급

# Let's Encrypt 및 Certbot 설치
sudo apt-get install certbot python3-certbot-nginx -y

설명:

무료 SSL 인증서를 발급받기 위한 Certbot을 설치합니다.

# SSL 인증서 발급 및 Nginx 설정 자동 업데이트
sudo certbot --nginx -d yourdomain.com

설명:

yourdomain.com을 실제 도메인으로 교체하여 SSL 인증서를 발급받고 Nginx 설정을 자동으로 업데이트합니다.
과정 중 이메일 입력, 서비스 약관 동의, HTTPS 리디렉션 설정 등을 진행합니다.

1.4 인증서 갱신 테스트

# 인증서 갱신 테스트
sudo certbot renew --dry-run

설명:

인증서 갱신이 정상적으로 작동하는지 테스트합니다.

2) Nginx 업스트림 설정 파일 작성

블루-그린 배포를 위해 Nginx의 업스트림 서버를 설정합니다.

2.1 업스트림 설정 파일 생성

# 업스트림 설정 디렉토리로 이동
sudo mkdir -p /etc/nginx/conf.d

# upstream.conf 파일 생성 및 편집
sudo nano /etc/nginx/conf.d/upstream.conf

설명:

/etc/nginx/conf.d/ 디렉토리에 upstream.conf 파일을 생성하여 업스트림 서버 설정을 정의합니다.

2.2 `upstream.conf` 내용 복사 및 저장

upstream.conf 파일에 다음 내용을 복사하여 붙여넣습니다:

# /etc/nginx/conf.d/upstream.conf

upstream app_servers {
    server localhost:8081; # 블루 서버 활성화
    # server localhost:8082; # 그린 서버 비활성화
}

설명:

upstream app_servers: Nginx가 트래픽을 전달할 서버 그룹을 정의합니다.
현재는 springboot-blue 서버만 활성화되어 있습니다.

2.3 `upstream.conf` 저장 및 종료

Nano에서 저장: Ctrl + O, Enter
Nano에서 종료: Ctrl + X

3) Nginx 설정 파일 수정

Nginx의 기본 설정 파일을 수정하여 SSL과 리버스 프록시를 설정합니다.

3.1 기본 설정 파일 편집

# 기본 설정 파일 열기
sudo nano /etc/nginx/sites-available/default

설명:

/etc/nginx/sites-available/default 파일을 열어 편집합니다.

3.2 기본 설정 파일 내용 복사 및 저장

default 파일에 다음 내용을 복사하여 붙여넣습니다:

# /etc/nginx/sites-available/default

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    server_name yourdomain.com;

    # HTTP를 HTTPS로 리디렉션
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name yourdomain.com;

    # SSL 인증서 경로 설정
    ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    # DDoS 방어 및 보안 설정
    client_body_timeout 10s;
    client_header_timeout 10s;
    client_max_body_size 1m;

    # ModSecurity 설정
    modsecurity on;
    modsecurity_rules_file /etc/nginx/modsecurity/modsecurity.conf;

    location / {
        proxy_pass http://app_servers;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # DDoS 방어 설정
        limit_req zone=ddos_limit burst=20 nodelay;
        limit_conn addr 10;
    }
}

설명:

HTTP 서버 블록: 모든 HTTP 요청을 HTTPS로 리디렉션합니다.
HTTPS 서버 블록: SSL 인증서를 사용하여 HTTPS 요청을 처리하고, app_servers 업스트림으로 트래픽을 전달합니다.
보안 설정: 클라이언트 요청의 타임아웃, 최대 본문 크기 등을 설정하여 보안을 강화합니다.
ModSecurity: 웹 애플리케이션 방화벽을 활성화하여 보안 위협으로부터 애플리케이션을 보호합니다.
DDoS 방어: limit_req 및 limit_conn 지시어를 사용하여 DDoS 공격을 방어합니다.

3.3 `default` 파일 저장 및 종료

Nano에서 저장: Ctrl + O, Enter
Nano에서 종료: Ctrl + X

4) Nginx 전환 스크립트 작성

블루-그린 배포 시 Nginx의 업스트림 서버를 전환하는 스크립트를 작성합니다.

4.1 스크립트 파일 생성

# 스크립트 파일 생성
sudo nano /usr/local/bin/switch_nginx.sh

설명:

/usr/local/bin/ 디렉토리에 switch_nginx.sh 스크립트 파일을 생성합니다.

4.2 `switch_nginx.sh` 내용 복사 및 저장

switch_nginx.sh 파일에 다음 내용을 복사하여 붙여넣습니다:

#!/bin/bash

UPSTREAM_CONF="/etc/nginx/conf.d/upstream.conf"
BACKUP_CONF="/etc/nginx/conf.d/upstream.conf.bak"

# 현재 설정 백업
sudo cp $UPSTREAM_CONF $BACKUP_CONF

# 현재 활성화된 포트 확인
ACTIVE_PORT=$(grep -E '^\s*server localhost:808[12];' $UPSTREAM_CONF | grep -o '808[12]' | head -n1)

# 새로운 설정 생성 및 전환
if [ "$ACTIVE_PORT" == "8081" ]; then
    NEW_CONFIG="upstream app_servers {
        # server localhost:8081; # 블루 서버 비활성화
        server localhost:8082; # 그린 서버 활성화
    }"
elif [ "$ACTIVE_PORT" == "8082" ]; then
    NEW_CONFIG="upstream app_servers {
        server localhost:8081; # 블루 서버 활성화
        # server localhost:8082; # 그린 서버 비활성화
    }"
else
    NEW_CONFIG="upstream app_servers {
        server localhost:8081; # 블루 서버 활성화
        # server localhost:8082; # 그린 서버 비활성화
    }"
fi

# 새로운 설정을 파일에 쓰기
echo "$NEW_CONFIG" | sudo tee $UPSTREAM_CONF

# Nginx 설정 테스트 및 적용
if sudo nginx -t; then
    sudo systemctl reload nginx
    echo "Nginx 업스트림 서버 전환 성공: 활성 포트 $ACTIVE_PORT에서 전환됨."
else
    # 설정 오류 시 백업 파일 복원
    sudo cp $BACKUP_CONF $UPSTREAM_CONF
    sudo systemctl reload nginx
    echo "Nginx 설정 테스트 실패: 백업 파일을 복원합니다."
    exit 1
fi

설명:

업스트림 설정 백업: 현재 Nginx 업스트림 설정을 백업합니다.
활성화된 포트 확인: 현재 활성화된 서비스 포트를 확인하여 블루 또는 그린 환경을 판단합니다.
새로운 설정 생성: 현재 활성화된 환경을 비활성화하고, 다른 환경을 활성화하는 새로운 업스트림 설정을 생성합니다.
Nginx 재시작: 설정 파일을 테스트하고 문제가 없으면 Nginx를 재시작하여 변경 사항을 적용합니다. 오류가 발생하면 백업 파일을 복원합니다.
로그 메시지 추가: 성공 및 실패 시 로그 메시지를 출력하여 상태를 알립니다.

4.3 스크립트 저장 및 종료

Nano에서 저장: Ctrl + O, Enter
Nano에서 종료: Ctrl + X

5) 스크립트 실행 권한 부여

# 스크립트에 실행 권한 부여
sudo chmod +x /usr/local/bin/switch_nginx.sh

설명:

스크립트에 실행 권한을 부여하여 실행할 수 있게 합니다.

10. Jenkins 파이프라인 설정

Jenkins를 사용하여 CI/CD 파이프라인을 구축합니다. 이 파이프라인은 코드 변경 사항을 자동으로 빌드, 테스트, 배포하며, SonarQube를 통해 코드 품질을 분석합니다.

1) Jenkins에서 Pipeline 형식의 Item 생성

10.1 Jenkins 대시보드에서 새로운 Pipeline 생성

Jenkins 웹 UI에 접속합니다. (http://[서버 IP]:9090)
새로운 Item을 클릭합니다.
Item 이름을 입력합니다. 예: moya-ci-cd-pipeline
Pipeline을 선택한 후 OK를 클릭합니다.

10.2 Pipeline 설정

Configure 버튼을 클릭합니다.
Pipeline 섹션으로 스크롤합니다.
Definition을 Pipeline script로 선택합니다.
Pipeline Script 입력란에 다음 스크립트를 작성합니다.

2) Pipeline Script 작성

아래는 프로젝트에 맞게 작성한 Jenkins Pipeline 스크립트입니다.

pipeline {
    agent any

    tools {
        maven 'Maven'
    }

    environment {
        MAVEN_HOME = tool 'Maven'
        PATH = "${MAVEN_HOME}/bin:${env.PATH}"
        DOCKER_IMAGE = 'your_dockerhub_username/moya:latest'
        SSH_CREDENTIALS = 'ssh-key-id'
        SERVER_IP = 'yourdomain.com'
        SSH_USER = 'ubuntu'
    }

    stages {
        stage('Git Checkout') {
            steps {
                script {
                    echo "=== Git 레포지토리 체크아웃 중 ==="
                    checkout([$class: 'GitSCM', branches: [[name: '*/develop']], 
                              userRemoteConfigs: [[url: 'https://lab.ssafy.com/s11-ai-image-sub1/S11P21D202.git', 
                                                  credentialsId: 'gitlab']]])
                    sh 'ls -la'
                }
            }
        }

        stage('Set Permissions') {
            steps {
                echo "=== 파일 권한 설정 중 ==="
                sh 'chmod -R 777 backend'
            }
        }

        stage('Copy Secret Files') {
            steps {
                script {
                    echo "=== 시크릿 파일을 복사 중 ==="
                    withCredentials([file(credentialsId: 'env', variable: 'ENV_FILE'),
                                     file(credentialsId: 'application.properties', variable: 'APP_PROPERTIES'),
                                     file(credentialsId: 'application-oauth-kakao.properties', variable: 'OAUTH_PROPERTIES')]) {
                        sh 'cp $ENV_FILE backend/.env'
                        sh 'cp $APP_PROPERTIES backend/src/main/resources/application.properties'
                        sh 'cp $OAUTH_PROPERTIES backend/src/main/resources/application-oauth-kakao.properties'
                    }
                }
            }
        }

        stage('Maven Compile') {
            steps {
                dir('backend') {
                    script {
                        echo "=== Maven Compile ==="
                        if (fileExists('pom.xml')) {
                            sh 'mvn clean compile'
                        } else {
                            error 'pom.xml 파일이 존재하지 않습니다.'
                        }
                    }
                }
            }
        }

        stage('Maven Package') {
            steps {
                dir('backend') {
                    echo "=== Maven 패키징 중 ==="
                    sh 'mvn package -DskipTests'
                }
            }
        }

        stage('Docker Build and Push') {
            steps {
                dir('backend') {
                    script {
                        echo "=== Docker 이미지 빌드 중 ==="
                        sh 'docker build -t your_dockerhub_username/moya:latest .'

                        echo "=== DockerHub로 이미지 푸시 중 ==="
                        withCredentials([usernamePassword(credentialsId: 'docker-credentials-id', passwordVariable: 'DOCKER_HUB_PASSWORD', usernameVariable: 'DOCKER_HUB_USERNAME')]) {
                            sh 'echo $DOCKER_HUB_PASSWORD | docker login -u $DOCKER_HUB_USERNAME --password-stdin'
                            sh 'docker push your_dockerhub_username/moya:latest'
                        }
                    }
                }
            }
        }

        stage('Deploy to Inactive Environment') {
            steps {
                script {
                    echo "=== 비활성화된 환경에 배포 중 ==="
                    sshagent([SSH_CREDENTIALS]) {
                        sh '''
                            ACTIVE_PORT=$(ssh -o StrictHostKeyChecking=no ${SSH_USER}@${SERVER_IP} "sudo grep -E '^\\s*server localhost:808[12];' /etc/nginx/conf.d/upstream.conf | grep -o '808[12]' | head -n1")
                            echo 현재 활성 환경 포트: ${ACTIVE_PORT}

                            if [ "${ACTIVE_PORT}" = "8081" ]; then
                                INACTIVE_SERVICE="springboot-green"
                                IMAGE_TAG="green"
                                INACTIVE_PORT="8082"
                                echo "비활성 환경: 그린 (포트 8082)"
                            elif [ "${ACTIVE_PORT}" = "8082" ]; then
                                INACTIVE_SERVICE="springboot-blue"
                                IMAGE_TAG="blue"
                                INACTIVE_PORT="8081"
                                echo "비활성 환경: 블루 (포트 8081)"
                            else
                                INACTIVE_SERVICE="springboot-blue"
                                IMAGE_TAG="blue"
                                INACTIVE_PORT="8081"
                            fi

                            ssh -o StrictHostKeyChecking=no ${SSH_USER}@${SERVER_IP} "docker-compose -f /home/ubuntu/moya/backend/docker-compose.yml stop ${INACTIVE_SERVICE} && docker-compose -f /home/ubuntu/moya/backend/docker-compose.yml rm -f ${INACTIVE_SERVICE}"
                            ssh -o StrictHostKeyChecking=no ${SSH_USER}@${SERVER_IP} "docker pull your_dockerhub_username/moya:latest && docker tag your_dockerhub_username/moya:latest your_dockerhub_username/moya:${IMAGE_TAG} && cd /home/ubuntu/moya/backend && docker-compose -f /home/ubuntu/moya/backend/docker-compose.yml up -d --no-deps ${INACTIVE_SERVICE}"
                            ssh -o StrictHostKeyChecking=no ${SSH_USER}@${SERVER_IP} "docker-compose -f /home/ubuntu/moya/backend/docker-compose.yml ps ${INACTIVE_SERVICE}"
                        '''
                    }
                }
            }
        }

        stage('Wait for Stabilization') {
            steps {
                echo "=== 새로운 컨테이너 안정화 대기 중 ==="
                sleep time: 10, unit: 'SECONDS'
            }
        }

        stage('Health Check') {
            steps {
                script {
                    echo "=== 헬스 체크 수행 중 ==="
                    sshagent([SSH_CREDENTIALS]) {
                        sh '''
                            set +e
                            MAX_RETRIES=12
                            RETRY_INTERVAL=5

                            ACTIVE_PORT=$(ssh -o StrictHostKeyChecking=no ${SSH_USER}@${SERVER_IP} "sudo grep -E '^\\s*server localhost:808[12];' /etc/nginx/conf.d/upstream.conf | grep -o '808[12]' | head -n1")
                            if [ "${ACTIVE_PORT}" = "8081" ]; then
                                INACTIVE_PORT="8082"
                            else
                                INACTIVE_PORT="8081"
                            fi

                            HEALTH_CHECK_URL="http://${SERVER_IP}:${INACTIVE_PORT}/health"
                            echo "헬스 체크 URL: ${HEALTH_CHECK_URL}"

                            RETRIES=0

                            while [ $RETRIES -lt $MAX_RETRIES ]; do
                                STATUS=$(curl -s -o /dev/null -w '%{http_code}' ${HEALTH_CHECK_URL})
                                if [ "$STATUS" -eq 200 ]; then
                                    echo "헬스 체크 성공!"
                                    exit 0
                                else
                                    echo "헬스 체크 실패, ${RETRY_INTERVAL}초 후 재시도... (${RETRIES}/${MAX_RETRIES})"
                                    RETRIES=$((RETRIES+1))
                                    sleep $RETRY_INTERVAL
                                fi
                            done
                            echo "헬스 체크 실패: 최대 재시도 횟수 초과"
                            exit 1
                        '''
                    }
                }
            }
        }

        stage('Switch Nginx to New Environment') {
            steps {
                script {
                    echo "=== Nginx를 새로운 환경으로 전환 중 ==="
                    sshagent([SSH_CREDENTIALS]) {
                        sh '''
                            ssh -T -o StrictHostKeyChecking=no ${SSH_USER}@${SERVER_IP} << EOF
                                echo "현재 Nginx 설정:"
                                sudo cat /etc/nginx/conf.d/upstream.conf
                                echo "스크립트 실행 중..."
                                sudo bash /usr/local/bin/switch_nginx.sh
                                echo "스크립트 실행 완료"
                                echo "변경 후 Nginx 설정:"
                                sudo cat /etc/nginx/conf.d/upstream.conf
                                echo "Nginx 상태 확인:"
                                sudo systemctl --no-pager status nginx
                                exit
                            EOF
                        '''
                    }
                }
            }
        }

        stage('SonarQube Analysis') {
            steps {
                dir('backend') {
                    script {
                        echo "=== SonarQube 분석 중 ==="
                        withSonarQubeEnv('moya') {
                            withCredentials([string(credentialsId: 'sonarQubeToken', variable: 'SONAR_TOKEN')]) {
                                sh 'mvn sonar:sonar -Dsonar.projectKey=com.e22e:moya -Dsonar.host.url=http://yourdomain.com:9000 -Dsonar.login=$SONAR_TOKEN'
                            }
                        }
                    }
                }
            }
        }

        stage('Notify Mattermost') {
            steps {
                script {
                    echo "=== Mattermost에 알림 전송 중 ==="
                    mattermostSend color: '#32a852', message: """빌드 성공 (${env.JOB_NAME}) #(${env.BUILD_NUMBER}) (<${env.BUILD_URL}|Open>)
See the (<${env.BUILD_URL}console|console>)"""
                }
            }
        }
    }

    post {
        always {
            script {
                echo "=== Cleanup 또는 에러 처리 중 ==="
            }
        }

        failure {
            script {
                echo "=== 빌드 실패, 알림 전송 ==="
                mattermostSend color: '#ff0000', message: """빌드 실패 (${env.JOB_NAME}) #(${env.BUILD_NUMBER}) (<${env.BUILD_URL}|Open>)
See the (<${env.BUILD_URL}console|console>)"""
            }
        }
    }
}

설명:

Environment Variables:
- MAVEN_HOME, PATH: Maven 빌드 도구의 경로 설정.
- DOCKER_IMAGE: Docker Hub에 푸시할 이미지 이름.
- SSH_CREDENTIALS: Jenkins에 등록한 SSH 자격 증명 ID.
- SERVER_IP, SSH_USER: 배포 대상 서버의 IP와 사용자 이름.
Stages:
1. Git Checkout: GitLab 저장소에서 코드를 클론하여 빌드를 준비합니다.
2. Set Permissions: backend 디렉토리의 파일 권한을 설정합니다.
3. Copy Secret Files: 시크릿 파일(.env, Spring 설정 파일 등)을 backend 디렉토리에 복사하여 애플리케이션이 올바르게 설정되도록 합니다.
4. Maven Compile: Maven을 사용하여 프로젝트를 컴파일합니다.
5. Maven Package: Maven을 사용하여 프로젝트를 패키징합니다.
6. Docker Build and Push: Docker 이미지를 빌드하고 Docker Hub에 푸시합니다.
7. Deploy to Inactive Environment: 블루-그린 배포 전략에 따라 비활성화된 환경에 새 버전을 배포합니다.
8. Wait for Stabilization: 새로운 컨테이너의 안정화를 위해 잠시 대기합니다.
9. Health Check: 배포된 애플리케이션의 상태를 확인합니다.
10. Switch Nginx to New Environment: Nginx 설정을 변경하여 트래픽을 새로운 버전으로 전환합니다.
11. SonarQube Analysis: SonarQube를 사용하여 코드 품질을 분석합니다.
12. Notify Mattermost: 빌드 및 배포 결과를 팀 커뮤니케이션 도구인 Mattermost에 알림으로 전송합니다.
Post Actions:
- always: 모든 빌드 후에 수행되는 단계입니다. (예: Cleanup)
- failure: 빌드 실패 시 Mattermost에 실패 알림을 전송합니다.

10.3 `Jenkinsfile` 저장 및 종료

Nano에서 저장: Ctrl + O, Enter
Nano에서 종료: Ctrl + X

2) 파이프라인 설명

Git Checkout: GitLab에서 소스 코드를 클론하여 빌드를 준비합니다.
Set Permissions: 빌드와 배포에 필요한 파일 권한을 설정합니다.
Copy Secret Files: 시크릿 파일(.env, Spring 설정 파일 등)을 backend 디렉토리에 복사하여 애플리케이션이 올바르게 설정되도록 합니다.
Maven Compile: Maven을 사용하여 프로젝트를 컴파일합니다.
Maven Package: Maven을 사용하여 프로젝트를 패키징합니다.
Docker Build and Push: Docker 이미지를 빌드하고, Docker Hub에 푸시하여 배포를 준비합니다.
Deploy to Inactive Environment: 블루-그린 배포 전략에 따라 비활성화된 환경에 새로운 버전을 배포합니다.
Wait for Stabilization: 배포된 애플리케이션의 안정화를 위해 잠시 대기합니다.
Health Check: 애플리케이션의 상태를 확인하여 정상적으로 동작하는지 확인합니다.
Switch Nginx to New Environment: Nginx 설정을 변경하여 트래픽을 새로운 버전으로 전환합니다.
SonarQube Analysis: SonarQube를 사용하여 코드의 버그, 보안 취약점, 코드 스멜 등을 분석하여 코드 품질을 관리합니다.
Notify Mattermost: 빌드 및 배포 결과를 팀 커뮤니케이션 도구인 Mattermost에 알림으로 전송합니다.

11. SonarQube를 통한 코드 품질 관리

SonarQube는 소스 코드의 품질을 자동으로 분석하고, 코드의 버그, 보안 취약점, 코드 스멜 등을 감지하여 개선할 수 있는 도구입니다. 이를 통해 지속적으로 코드 품질을 유지하고 향상시킬 수 있습니다.

1) SonarQube 설치 및 설정

SonarQube를 Docker 컨테이너로 설치합니다.

# SonarQube Docker 컨테이너 실행
docker run -d \
  --name sonarqube \
  -e SONAR_ES_BOOTSTRAP_CHECKS_DISABLE=true \
  -p 9000:9000 \
  sonarqube:latest

설명:

-e SONAR_ES_BOOTSTRAP_CHECKS_DISABLE=true: Elasticsearch 관련 초기 체크를 비활성화하여 메모리 부족 문제를 방지합니다. (실제 환경에서는 적절한 메모리 할당을 권장)
-p 9000:9000: SonarQube UI에 접근하기 위한 포트를 매핑합니다.

SonarQube 컨테이너 상태 확인

docker ps

출력 결과 예시:

CONTAINER ID   IMAGE            COMMAND                  CREATED        STATUS        PORTS                     NAMES
7f31b90ff248   sonarqube:latest "/opt/sonarqube/dock…"   2 weeks ago    Up 2 weeks    0.0.0.0:9000->9000/tcp    sonarqube

2) SonarQube 초기 설정

브라우저에서 http://yourdomain.com:9000에 접속합니다.
기본 계정(admin/admin)으로 로그인합니다.
보안을 위해 비밀번호를 변경합니다.
My Account > Security 탭에서 Token을 생성합니다. 이 토큰은 Jenkins와 연동할 때 사용됩니다.

3) Jenkins에 SonarQube 연동

Jenkins 관리 페이지로 이동합니다.
Manage Jenkins > Configure System으로 들어갑니다.
SonarQube servers 섹션에서 Add SonarQube를 클릭합니다.
Name: SonarQube
Server URL: http://yourdomain.com:9000
Server authentication token: Jenkins의 Credentials에 저장한 SonarQube 토큰을 선택합니다.
Save를 클릭하여 설정을 저장합니다.

4) Jenkins Pipeline에서 SonarQube 분석 단계 추가

이미 작성한 Jenkins Pipeline 스크립트에 SonarQube Analysis 단계가 포함되어 있습니다. 이를 통해 빌드 과정 중에 코드 품질을 자동으로 분석할 수 있습니다.

stage('SonarQube Analysis') {
    steps {
        dir('backend') {
            script {
                echo "=== SonarQube 분석 중 ==="
                withSonarQubeEnv('moya') {
                    withCredentials([string(credentialsId: 'sonarQubeToken', variable: 'SONAR_TOKEN')]) {
                        sh 'mvn sonar:sonar -Dsonar.projectKey=com.e22e:moya -Dsonar.host.url=http://yourdomain.com:9000 -Dsonar.login=$SONAR_TOKEN'
                    }
                }
            }
        }
    }
}

설명:

withSonarQubeEnv: SonarQube 서버와의 연동 환경을 설정합니다.
withCredentials: SonarQube 토큰을 안전하게 Jenkins 파이프라인에 주입합니다.
mvn sonar:sonar: Maven을 사용하여 SonarQube 분석을 실행합니다.

SonarQube 분석 결과:

Jenkins 빌드가 완료된 후, SonarQube 웹 UI에서 코드 품질 보고서를 확인할 수 있습니다.
Jenkins의 콘솔 로그에서도 SonarQube 분석 진행 상황과 결과를 확인할 수 있습니다.

12. 보안 강화 설정 (Fail2Ban 및 ModSecurity)

서버의 보안을 강화하기 위해 Fail2Ban과 ModSecurity를 설치하고 설정합니다.

1) Fail2Ban 설치 및 설정

Fail2Ban은 악의적인 IP 주소로부터 서버를 보호하는 데 사용됩니다. 주로 SSH 로그인 시도, DDoS 공격 등을 방어합니다.

1.1 Fail2Ban 설치

# Fail2Ban 설치
sudo apt-get update
sudo apt-get install fail2ban -y

설명:

sudo apt-get install fail2ban -y: Fail2Ban을 설치합니다.

1.2 설정 파일 생성 및 수정

# jail.local 파일 생성 및 편집
sudo nano /etc/fail2ban/jail.local

설명:

jail.local: Fail2Ban의 규칙을 정의하는 파일입니다. 사용자 정의 규칙을 추가할 수 있습니다.

1.3 `jail.local` 파일에 다음 내용 추가

[nginx-req-limit]
enabled = true
filter = nginx-req-limit
action = iptables-multiport[name=ReqLimit, port="http,https", protocol=tcp]
logpath = /var/log/nginx/error.log
findtime = 600
bantime = 7200
maxretry = 10

설명:

[nginx-req-limit]: Nginx의 요청 제한을 모니터링하는 Fail2Ban 규칙입니다.
enabled = true: 이 규칙을 활성화합니다.
filter = nginx-req-limit: 사용할 필터 이름입니다.
action = iptables-multiport[name=ReqLimit, port="http,https", protocol=tcp]: 차단 시 사용할 액션을 정의합니다.
logpath = /var/log/nginx/error.log: 로그 파일 경로를 지정합니다.
findtime = 600: 10분 동안 시도 횟수를 셉니다.
bantime = 7200: 2시간 동안 IP를 차단합니다.
maxretry = 10: 최대 시도 횟수입니다.

1.4 필터 설정 파일 생성

sudo nano /etc/fail2ban/filter.d/nginx-req-limit.conf

설명:

nginx-req-limit.conf: Nginx의 요청 제한 로그 패턴을 정의하는 Fail2Ban 필터 파일입니다.

1.5 `nginx-req-limit.conf` 파일에 다음 내용 추가

[Definition]
failregex = limiting requests, excess:.* by zone

설명:

failregex: 로그 파일에서 Fail2Ban이 차단할 패턴을 정의합니다.

1.6 Fail2Ban 재시작 및 상태 확인

# Fail2Ban 재시작
sudo systemctl restart fail2ban

# Fail2Ban 상태 확인
sudo fail2ban-client status
sudo fail2ban-client status nginx-req-limit

설명:

sudo systemctl restart fail2ban: Fail2Ban 서비스를 재시작하여 설정을 적용합니다.
sudo fail2ban-client status: Fail2Ban의 전반적인 상태를 확인합니다.
sudo fail2ban-client status nginx-req-limit: 특정 jails의 상태를 확인합니다.

2) ModSecurity 웹 방화벽 설치 및 설정

ModSecurity는 웹 애플리케이션 방화벽으로, 악의적인 요청을 필터링하여 서버를 보호합니다.

2.1 ModSecurity 및 OWASP CRS 설치

# ModSecurity 및 OWASP CRS 설치
sudo apt-get update
sudo apt-get install -y libnginx-mod-security
sudo apt-get install -y modsecurity-crs

설명:

libnginx-mod-security: Nginx용 ModSecurity 모듈을 설치합니다.
modsecurity-crs: OWASP Core Rule Set을 설치하여 기본 보안 규칙을 제공합니다.

2.2 ModSecurity 설정 파일 수정

sudo nano /etc/nginx/modsecurity/modsecurity.conf

설명:

modsecurity.conf: ModSecurity의 주요 설정 파일입니다.

2.3 `modsecurity.conf` 파일에 다음 내용 추가

SecRuleEngine On

설명:

SecRuleEngine On: ModSecurity를 활성화합니다.

2.4 OWASP CRS 설정 파일 복사 및 링크 생성

# CRS 설정 파일 복사
sudo cp /usr/share/modsecurity-crs/crs-setup.conf.example /etc/nginx/modsecurity/crs-setup.conf

# CRS 규칙 파일 링크 생성
sudo ln -s /usr/share/modsecurity-crs/rules /etc/nginx/modsecurity/rules

설명:

crs-setup.conf.example: OWASP CRS의 기본 설정 파일입니다.
/usr/share/modsecurity-crs/rules: CRS 규칙 파일들이 위치한 디렉토리입니다.

2.5 ModSecurity 설정 파일에 CRS 포함

echo 'Include /etc/nginx/modsecurity/crs-setup.conf' | sudo tee -a /etc/nginx/modsecurity/modsecurity.conf
echo 'Include /etc/nginx/modsecurity/rules/*.conf' | sudo tee -a /etc/nginx/modsecurity/modsecurity.conf

설명:

Include 지시어를 사용하여 CRS 설정과 규칙 파일들을 ModSecurity 설정에 포함시킵니다.

2.6 Nginx 설정 테스트 및 재시작

# Nginx 설정 테스트
sudo nginx -t

# Nginx 재시작
sudo systemctl reload nginx

설명:

sudo nginx -t: Nginx 설정 파일의 문법을 검사합니다.
sudo systemctl reload nginx: 설정 파일을 재적용하여 변경 사항을 반영합니다.

13. 마무리 및 개선 사항

결과

무중단 배포 구현 성공: 블루-그린 배포 방식을 통해 서비스 중단 없이 새로운 버전을 배포할 수 있게 되었습니다.
자동화된 배포 프로세스 구축: CI/CD 파이프라인을 통해 배포 과정이 자동화되어 배포 시간과 인적 오류를 줄일 수 있었습니다.
코드 품질 관리 강화: SonarQube를 통해 지속적인 코드 품질 관리를 할 수 있게 되었습니다.
보안 강화: Fail2Ban과 ModSecurity를 적용하여 서버 보안을 강화하였습니다.
DockerHub 활용: DockerHub를 통해 Docker 이미지를 효과적으로 관리하고 배포할 수 있게 되었습니다.

개선 사항

자동 롤백 기능 도입: 배포 실패 시 자동으로 이전 버전으로 롤백하는 기능을 추가하여 배포 안정성을 높일 계획입니다.
모니터링 도구 도입: Prometheus와 Grafana 등을 도입하여 시스템 및 애플리케이션 모니터링을 강화할 예정입니다.
CI/CD 파이프라인 최적화: 빌드 시간 단축 및 효율적인 리소스 사용을 위한 최적화를 진행할 예정입니다.
헬스 체크 강화: 애플리케이션의 상태를 더욱 정확하게 확인하기 위해 다양한 헬스 체크 방법을 도입할 계획입니다.
DockerHub 보안 강화: DockerHub 저장소의 접근 권한을 세분화하고, 보안 설정을 강화하여 이미지 보안을 높일 예정입니다.

이번 포스팅에서는 CI/CD를 통해 블루-그린 배포 방식을 적용하여 무중단 배포를 구현하는 과정을 상세히 설명하였습니다. CI/CD를 처음 접하시는 분들도 따라 할 수 있도록 각 단계별 명령어와 설정 파일 생성 및 수정 방법을 최대한 상세히 포함하였으며, 필요한 개념에 대한 설명도 함께 제공하였습니다. 또한, DockerHub의 활용 방법과 그 중요성에 대해 추가로 설명하였습니다. 이 글이 여러분의 프로젝트에 도움이 되었기를 바랍니다.

감사합니다!

추가 팁 및 참고 자료

파일 편집기 사용법: 본 가이드에서는 nano 편집기를 사용하였으나, 다른 편집기(vi, vim, emacs 등)를 사용할 수도 있습니다. 각 편집기의 기본 사용법을 익히면 더욱 편리하게 파일을 수정할 수 있습니다.
Jenkins 플러그인 설치: Jenkins에서 다양한 기능을 활용하기 위해 필요한 플러그인들을 사전에 설치해두면 파이프라인 설정이 용이합니다.
보안 키 관리: SSH 키, API 토큰 등 민감한 정보는 Jenkins의 Credentials 관리 기능을 통해 안전하게 관리해야 합니다.
로그 모니터링: 배포 및 운영 중 발생하는 문제를 신속하게 파악하기 위해 로그 파일을 지속적으로 모니터링하는 습관을 들이세요.
백업 전략: 중요한 데이터와 설정 파일에 대한 정기적인 백업을 통해 예상치 못한 문제 발생 시 신속하게 복구할 수 있도록 준비하세요.

이 외에도 다양한 자료와 튜토리얼이 온라인에 많이 있으니, 필요에 따라 추가적으로 학습하시기를 권장드립니다.

참고 자료:

주의 사항:

실제 운영 환경에서는 보안 설정을 더욱 강화하고, 비밀번호와 API 키는 절대로 공개하지 않도록 주의하세요.
본 가이드는 기본적인 설정을 다루고 있으며, 실제 프로젝트의 요구 사항에 따라 추가적인 설정이 필요할 수 있습니다.

이제 CI/CD 파이프라인과 블루-그린 배포 방식을 통해 효율적이고 안정적인 애플리케이션 배포를 경험해보세요!

개발자 미연

시나공 빅데이터분석기사 실기 Python 교재 리뷰: 시나공 Python 교재 첫인상과 학습 계획

학습 방향이 막막했을 때 도움이 된 시나공

2주 단기 집중 루틴으로 학습

1주차

2주차

시나공 빅데이터분석기사 실기 Python의 장점

마무리

데이터에듀 2025 ADsP 민트책 리뷰: 데이터분석 준전문가 합격을 위한 교재 선택 가이드

데이터에듀 2025 ADsP 민트책의 장점

1. 최신 출제 경향 반영

2. 풍부한 문제 구성과 명쾌한 해설

3. 모바일 앱을 통한 자투리 학습

4. 시험 직전 요약용 'D-7 합격마법노트'

5. 설치 없는 웹 기반 R 실습

추천 학습 루틴

마무리

Git Merge, Rebase, Squash: 차이점과 적합한 사용 사례 비교

목차

1. Merge란 무엇인가?

특징

예시

장점

단점

2. Rebase란 무엇인가?

특징

예시

장점

단점

3. Squash란 무엇인가?

특징

예시

장점

단점

4. Merge, Rebase, Squash 비교

5. 프로젝트 상황에 따른 선택 가이드

6. 최종 결론

참고 자료

Git Flow vs GitHub Flow vs GitLab Flow: 브랜치 전략의 차이점과 선택 가이드

목차

1. Git Flow 개요

특징

브랜치 구조

장점

단점

2. GitHub Flow 개요

특징

브랜치 구조

워크플로우

장점

단점

3. GitLab Flow 개요

특징

브랜치 구조

워크플로우

장점

단점

4. 브랜치 전략 비교

5. 프로젝트 환경에 따른 선택 가이드

6. 최종 결론

참고 자료

Git 커밋 컨벤션 가이드: 협업을 위한 베스트 프랙티스

목차

1. Git 커밋 컨벤션이란?

2. 커밋 메시지의 기본 구조

2.1 제목 (Title)

2.2 본문 (Body)

2.3 푸터 (Footer)

3. 대표적인 커밋 컨벤션 스타일

3.1 Conventional Commits

3.2 Gitmoji

3.3 Custom 스타일

4. 협업을 위한 커밋 작성 베스트 프랙티스

5. 커밋 메시지 작성 도구와 자동화

5.1 Commitizen

5.2 Linting 도구

최종 결론

Django vs Spring 비교: 프로젝트 환경에 맞는 백엔드 프레임워크 선택 가이드

목차

1. Django와 Spring 개요

4. `.gitignore` 업데이트 및 민감 파일 제거