일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
- sql사이트
- 쿼리사이트
- error 2002 (hy000): can't connect to local mysql server through socket '/tmp/mysql.sock' (2)
- JPA
- spring cloud stream
- group by group by rollup 차이
- 자바
- 설치없이쿼리실행
- dto매핑우선순위
- port&adapter architecture
- 포트앤어댑터 아키텍처
- 쿼리실행사이트
- Oracle
- ls -lgaf
- 쓰기지연sql저장소 쿼리실행순서
- 스트림
- sql 테스트 사이트
- 쿼리테스트사이트
- 컬럼명중복
- IntelliJ
- 쓰기지연저장소
- Kafka
- 오라클쿼리테스트사이트
- 쿼리실행순서
- 중복컬럼dto매핑
- hibernate 쿼리실행 순서
- spring kakfa
- Stream
- Java
- Flush
- Today
- Total
개린이 탈출기
ci/cid pipeline와 관련된 조각 정보 본문
일할 때, 배포된 서비스를 사용하는 경우가 있었는데,
배포된 서비스가 잘 돌아가지 않는 경우가 종종 있었고, 그럴 때, argoCd를 확인하면 된다고해서
급급하게 어떤 것을 보면 되는지 얼추 듣기만하고 알려주신 것들만 확인하곤 했다.
오늘 작업을 위해 회사 수석님이 작업을 위해 argoCd에 대한 간략한 설명을 해주셨는데,
새롭게 들은 점을 정리하고 추가적으로 찾아보고 정리해 놓기 위해서 글을 작성한다.
ArgoCd 보기
위의 argoCD는 여러 개의 그룹을 감지하고 있다.
namespace 라고 적어둔 부분에 그룹의 이름이 올 수도 있고, application 이름 될 수도 있는 등 정하기 나름인 것 같다.
해당 영역으로 들어가보면 다음과 같은 화면을 볼 수 있다.
cm : config map
: 설정 파일과 같은 것이다. 프로그램의 yml 파일에 cm 에 적힌 설정들이 덮어진다고 생각하면 쉽다.
따라서 프로그램 내에서 yml 과 충돌되는 설정이 있다면 cm 에 적힌 설정이 사용된다.
ns : name space
: ArgoCD 와 Kubernatis 클러스터에서 애플리케이션과 리소스를 격리하고 관리하기 위한 논리적 단위이다.
secret
: 설정의 일종으로 노출되면 안되는 값들을 놓는다.
deploy : deployment
: 컨테이너 배포 설정이다.
gateway
: 네임스페이스 분리하기 위해 사용된다.
나중에 uri 가 gateway + prefix(svc) 로 들어오게 될 것이다. (설정에 따라 다를 것으로 보인다.)
CI/CD PipeLine 수행과정과 배포까지 대략적인 흐름
하단의 흐름은 설정에 따라 조금 달라질 수 있다.
환경적인 부분에서는 git lab runner 를 사용중이라고 가정한다.
1. GitLab 의 main 브랜치에 코드 푸쉬
- main 브랜치에 새로운 코드가 푸쉬되어 GitLab CI/CD 파이프라인이 트리거된다.
- . gitlab-ci.yml 파일에 정의된 작업들이 단계별로 수행될 준비를 한다.
( 보통 빌드단계, 패키지단계, 배포단계 등을 설정해놓음)
2. GitLab Runner 에서 CI/CD 파이프라인 실행
- GitLab 서버가 파이프라인을 트리거하면 GitLab Runner가 이를 수신하여 CI/CD 파이프라인의 작업을 실제로 실행한다
- Runner는 파이프라인의 각 단계에서 다음과 같은 작업을 한다.
- 빌드 단계: 애플리케이션 코드를 빌드.
- 테스트 단계: 애플리케이션을 실행 가능한 형태로 패키징.
- 도커 이미지 빌드: Dockerfile을 기반으로 애플리케이션을 Docker 이미지로 빌드.
3. 도커 이미지 생성 및 저장
- GitLab Runner가 애플리케이션의 Docker 이미지를 생성하고 저장소에 업로드한다.
(보통 Docker Registry(GitLab 레지스트리나 Docker Hub 같은 외부 레지스트리에 업로드)
- 이 과정에서 docker build와 docker push 명령어가 사용되며, 성공적으로 Push되면 해당 이미지는 버전과 함께 저장됨.
4. Kubernetes용 매니페스트 파일 생성 또는 업데이트
- GitLab CI/CD 파이프라인이 성공적으로 완료되면, 배포에 필요한 Kubernetes 매니페스트 파일(예: deployment.yaml, service.yaml)도 업데이트된다.
(.git 저장소에 업데이트 될 수도 있고, kubernatis 에 직접 적용될 수도 있다고 한다.)
(이 파일에는 어떤 Docker 이미지를 배포할지에 대한 정보가 포함되어 있음(예: image: myregistry.com/myapp:latest)) - ArgoCD는 이러한 매니페스트 파일의 변화를 감지하여 자동으로 새로고침하도록 설정됨.
5. ArgoCD에서 변화를 감지하여 Kubernetes 클러스터에 배포
- ArgoCD는 설정된 Git 저장소에서 주기적으로 변경 사항을 모니터링하는데,
새로운 Docker 이미지 태그나 매니페스트 파일의 변경 사항이 감지되면, ArgoCD는 이를 Kubernetes 클러스터에 동기화하도록 트리거한다.
(ArgoCD 는 kubernaetes 클러슽어에 매니페스트 파일의 변경 사항을 적용함)
6. Kubernetes에서 새로운 애플리케이션 버전 배포
- ArgoCD에 의해 변경 사항이 Kubernetes 클러스터에 반영되면, Kubernetes는 새로운 애플리케이션 버전을 배포하기 시작한다.
- Kubernetes는 변경된 Docker 이미지를 포함하는 새로운 파드를 생성하여 서비스에 연결함.
- 무중단 배포(예: Rolling Update) 설정이 되어 있다면, 기존 파드는 점진적으로 교체되고 애플리케이션이 중단 없이 새 버전으로 전환됨
'개발 조각 지식' 카테고리의 다른 글
EAI 간단 개요 (0) | 2025.03.12 |
---|---|
Apache Kafka, Spring Kakfa, Spring Cloud Stream 의 차이점 (0) | 2025.03.12 |
[Gradle] 라이브러리 의존성 설정 종류 (0) | 2024.11.27 |
[IntelliJ] 빌드 오류 해결.(Language level 변경) (0) | 2024.11.20 |
[k8s]@Value 를 통한 baseUrl 값 설정 (1) | 2024.11.11 |