반응형
GitOps란?
- Git을 단일 소스로 사용
- 모든 서비스, 인프라에 대한 관리를 Git을 통해 선언적으로 진행한다. 버전 관리, 협업, 코드 리뷰 등이 표준화된다.
- 자동화된 배포
- gitops에서는 argocd와 같은 툴을 이용하여 배포를 자동화할 수 있다. argocd는 git에 명시되어있는 desired state와 운영환경의 상태가 일치하도록 한다.
- 이떄문에 변경 사항이 빠르게 배포되고, 롤백할 경우에도 히스토리 관리가 용이하다
GitOps의 작동 방식
GitOps는 크게 두 가지 방식으로 작동한다.
- Push 기반 (배포 방식, CI)
- 대표 툴 : GitHub Actions, GitLab CI, Jenkins
- 새로운 코드나 인프라 변경 사항이 Git에 push되면, CI 파이프라인이 이를 감지하여 빌드를 진행하고, 클러스터나 배포 환경에 반영한다.
- Pull 기반 (운영 방식, CD)
- 대표 툴 : ArgoCD
- Kubernetes 클러스터에서 GitOps 에이전트가 Git 저장소를 주기적으로 모니터링하여 변경 사항이 있는지 감지한다.
- Git 저장소와 클러스터 상태가 다르면 에이전트가 이를 자동으로 조정하여 클러스터가 Git 저장소에 정의된 상태와 일치하게 만든다.
GitOps의 장점
- 일관성 및 표준화
- 모든 인프라와 애플리케이션 배포가 Git을 통해 이루어지므로 일관된 배포 프로세스를 보장하여 문제가 발생하였을 시 관리 포인트가 git으로 단일화된다.
- 자동화 및 신속한 배포
- 인프라 구성과 애플리케이션의 상태 변경이 자동으로 배포되므로, 배포의 자동화가 가능해진다.
- 안정성 향상
- Git 히스토리로 인해 모든 변경 사항이 추적 가능하며, 롤백 시 Git의 특정 커밋 상태로 쉽게 돌아갈 수 있습니다. 감사 로그를 통해 변경의 출처와 내용을 쉽게 파악할 수 있다.
Repository 구조
├── applications/
│ └── my-app/
│ ├── charts/ # Helm 차트 디렉토리
│ │ └── my-app-chart/ # 애플리케이션 Helm 차트
│ │ ├── Chart.yaml # 차트 메타데이터
│ │ ├── values.yaml # 기본 값 파일
│ │ ├── templates/ # Kubernetes 리소스 템플릿
│ │ │ ├── deployment.yaml
│ │ │ └── service.yaml
│ │ └── README.md
│ └── README.md
├── infrastructure/
│ └── my-infrastructure/
│ ├── base/
│ └── overlays/
└── deployment/
├── ci-cd/
│ ├── github-actions/ # CI/CD 설정
│ └── argocd/
└── README.md
아키텍처
아래의 실습을 모두 완료하게 된 이후 gitops 아키텍처는 아래와 같다.
Git
이후 문서에서는 GitOps를 통해 프로젝트를 자동화하는 방법을 작성하였다.
이에 git에 대한 사용이 필수적이므로, git에 대한 기본 사용법과 충돌 관리에 대한 내용을 작성하였다.
Git과 GitHub의 기본 이해
- Git: 분산 버전 관리 시스템으로, 파일의 변경 사항을 추적하고 협업할 수 있게 해줍니다.
- GitHub: Git 저장소를 호스팅하고, 협업 기능(이슈, PR, 리뷰)을 제공하는 클라우드 플랫폼.
git init
git clone <repo_url>
git status
로컬과 리모트 저장소의 차이점
- 로컬 저장소: 사용자 컴퓨터에 있는 Git 저장소.
- 리모트 저장소: GitHub 등의 서버에 호스팅된 저장소.
git remote add origin <repo_url> # 원격 저장소 연결
git push origin <branch> # 원격으로 푸시
git pull origin <branch> # 원격에서 풀
브랜치와 기본적인 협업 흐름
- 브랜치: 각 기능 개발을 독립적으로 진행하는 방법 (master, main, develop, feature)
git branch # 브랜치 목록 확인
git checkout -b <branch_name> # 새로운 브랜치 생성 및 이동
git merge <branch_name> # 브랜치 병합
GPG 키 설정과 서명된 커밋
- GPG 키: 커밋을 서명해 커밋한 사람을 검증할 수 있는 방법.(어떤 사람이 변경을 수행하였는지 히스토리를 확인하고, 원격저장소의 보안을 위해서 필수적이다)
brew install gnupg # macOS gpg 생성을 위한 명
gpg --gen-key # GPG 키 생성
git config --global user.signingkey <GPG_key_ID> # 서명 설정
gpg --armor --export <GPG_key_ID>
git commit -S -m "서명된 커밋 메시지" # 서명된 커밋
아래 기본 정보를 입력하고, 비밀번호를 설정한다.설정이 완료되면, pub 2번째 줄에 있는 문자열 값이 keyid가 된다.
git에 keyid를 통해 gpgkey를 export하고, 해당 내용을 (-----BEGIN PGP PUBLIC KEY BLOCK----- ~-----END PGP PUBLIC KEY BLOCK-----) 붙여넣어 등록한다.
Pull Request 모범 사례
- 대형 PR의 문제점과 작은 단위 PR의 중요성
- 대형 PR은 코드 리뷰 및 충돌 관리가 어려워질 수 있으며, 작은 단위 PR은 피드백을 빠르게 받고 충돌을 줄일 수 있음.
효율적인 코드 리뷰와 협업 방법
- 리뷰어는 논리적 흐름, 코드 스타일, 성능을 검토.
- 실시간 코드 리뷰, 코멘트 남기기, 제안 사항 반영을 통한 협업.
기본적인 충돌 해결 전략
- 충돌 상황 이해
- 두 사람이 같은 파일의 동일한 부분을 수정하면 충돌 발생.
- 충돌은 직접 수동으로 해결해야 함.
- Merge: 서로 다른 브랜치에서 다수의 변경 사항이 발생한 경우 —> “수동 해결 후 다시 merge”
- 장점: 히스토리에서 병합 흐름을 명확하게 확인할 수 있음.
- 단점: 히스토리가 복잡해질 수 있음.
git merge <branch_name> # 충돌 발생 시 수동 해결 후 커밋
git commit
- Rebase: 커밋 히스토리를 다시 정리.
- 장점: 히스토리가 깨끗하고 병합 흔적이 남지 않음.
- 주의사항: 이미 공유된 브랜치에서의 Rebase는 충돌과 혼란을 야기할 수 있음.
- Rebase 중 충돌 발생 시 각 커밋마다 충돌을 해결해야 함.
git rebase master # Rebase 중 충돌 발생 시 해결 후 재커밋
A---B---C topic
/
D---E---F---G master
--> git rebase master topic
A'--B'--C' topic
/
D---E---F---G master
- Stash: 현재 작업을 임시로 저장해 다른 작업을 먼저 처리.
- git 이 HEAD를 기준으로 두가지 커밋을 생성 (index와 workingtree)
- 작업 중이던 변경 사항을 stash로 임시 보관하고, 다른 브랜치로 이동해 우선 해결 후 복구 가능.
git stash # 작업 중인 파일 임시 저장
git stash pop # 저장한 파일 복구
.----W (워킹 디렉토리의 수정 내용)
/ /
-----H----I (인덱스의 내용)
반응형
'사이드 프로젝트' 카테고리의 다른 글
[CI/CD 프로젝트] K8S - Containerd 내부 구조 이해 (0) | 2024.11.19 |
---|---|
[CI/CD 프로젝트] SonarQube 사용한 코드품질 향상 (0) | 2024.11.19 |
[CI/CD 프로젝트] Terraform을 사용하여 bastion 서버 생성하기 (0) | 2024.11.19 |
[인프라 구축]AWS 사용 시 Identity Center로 여러 계정을 SSO로 관리하기 (0) | 2024.03.25 |
AWS 사용 시 Identity Center로 여러 계정을 SSO로 관리하기 (0) | 2024.03.22 |