[DAY 100] 최종 프로젝트

[천재교육] 프로젝트 기반 빅데이터 서비스 개발자 양성 과정 9기
학습일 : 2024.12.10

📕 프로젝트 작업 내역

CI/CD
GitLab

📗 수행 결과

1. GitLab CI/CD 목표 설정

1) 프로젝트에서의 CI/CD

CI (Continuous Integration): 프로젝트에서 코드 및 환경 변경 사항을 자동으로 통합하고, 테스트 및 실행을 통해 변경된 코드가 정상 작동하는지 확인
CD (Continuous Deployment): 테스트를 통과한 코드를 배포하고 실행 환경에 반영하여 최신 상태를 유지

(1) 모델 학습용 데이터를 추가하여 Fine-Tuning 시키는 경우

[목표]

학습 가상환경(EC2 A)
- 모델 종류별로 총 3가 존재
- train.py 코드가 포함된 최신 학습 환경을 ECR에 저장하고, EC2 A의 가상환경을 업데이트

[작업 흐름]
① Lambda가 GitLab Runner 호출

Lambda가 새로운 학습 데이터 업로드를 감지(S3 이벤트 알림)
Lambda가 학습 실행 코드(train.py) 수정
- 코드 내 데이터 경로 업데이트
수정된 코드를 기반으로 Lambda가 GitLab Runner API를 호출
- CI 파이프라인 실행

② Docker 이미지 빌드 & 컨테이너 생성

* CI 단계에서의 빌드: 코드를 테스트하기 위한 환경을 생성(임시 환경, ci-environment:latest)

Docker 이미지 빌드
- 수정된 모델 학습 코드의 테스트를 위한 Docker 이미지 생성
- 이 이미지는 테스트 환경 설정을 포함
컨테이너 생성
- 빌드된 Docker 이미지를 사용하여 테스트를 실행할 컨테이너 생성

③ 코드 테스트

CI 환경에서 수정된 코드의 안정성을 검증
- CI 전용 컨테이너에서 모델 학습 코드(train.py) 테스트
  - 새로운 데이터 경로에서 코드가 정상 작동하는지 확인
- 테스트 결과 처리
  - 테스트 성공: 배포(CD) 단계로 이동
  - 테스트 실패: 기존 코드로 복구

④ 코드 배포

* CD 단계에서의 빌드: 테스트를 통과한 코드를 포함한 최종 실행 환경을 생성(training:latest, trainig:v1.0)

테스트 성공 시 최종 학습 환경을 ECR에 업로드
- train.py 코드가 통합된 최종 Docker 이미지를 빌드
- 태그별로 관리
  - latest: 최신 버전
  - v1.0, v1.1: 커밋 ID 또는 버전을 기준으로 관리
- ECR에 업로드하여 중앙 저장소로 관리
가상환경 업데이트 (EC2 A)
- ECR에 업로드된 최신 이미지를 EC2 A에서 Pull
- Docker 이미지에서 최신 소스코드와 패키지 추출
  - Docker 컨테이너를 실행하여 최신 train.py 및 필요한 의존성 파일을 추출
- 가상환경 활성화 및 패키지 업데이트
  - EC2 A에서 가상환경을 활성화하고, Docker 이미지에서 추출한 최신 requirements.txt를 사용해 패키지를 설치
- 최신 소스코드 적용
  - Docker 이미지에서 추출한 최신 모델 학습 코드(train.py)를 기존 프로젝트 경로에 복사
- 최신 환경으로 가상환경 갱신 완료
  - 가상환경이 최신 패키지와 코드로 업데이트되어 모델 학습이 준비 완료
MLflow 설정 및 학습 기록 유지
- 기존 가상환경에서의 MLflow 설정을 유지
- 최신 코드가 설치된 가상환경에서 MLflow와 연동하여 학습 결과를 이어서 저장

(2) 교육과정 로드맵을 교체하여 Graph RAG에 반영하는 경우
[목표]

Neo4j 가상환경(EC2 B)
- json_to_neo4j.py 코드가 포함된 최신 데이터 처리 환경을 ECR에 저장하고, EC2 B의 가상환경을 업데이트

[작업 흐름]
① Lambda가 GitLab Runner 호출

Lambda가 새로운 교육과정 JSON 파일 업로드를 감지(S3 이벤트 알림)
Lambda가 데이터 전처리 코드(json_to_neo4j.py)를 수정
- 코드 내 데이터 경로 업데이트
수정된 코드를 기반으로 Lambda가 GitLab Runner API를 호출
- CI 파이프라인 실행

② Docker 이미지 빌드 & 컨테이너 생성
* CI 단계에서의 빌드: 코드를 테스트하기 위한 환경을 생성(임시 환경, ci-environment:latest)

Docker 이미지 빌드
- 수정된 데이터 전처리 코드의 테스트를 위한 Docker 이미지 생성
- 이 이미지는 Neo4j와의 연동 설정을 포함
컨테이너 생성
- 빌드된 Docker 이미지를 사용하여 테스트를 실행할 컨테이너 생성

③ 코드 테스트

CI 환경에서 데이터 전처리 코드(json_to_neo4j.py) 테스트
- 새로운 데이터 경로에서 코드가 정상 작동하는지 확인; JSON 데이터를 Neo4j에 정상적으로 반영할 수 있는지 검증

테스트 결과 처리
- 테스트 성공: 배포(CD) 단계로 이동
- 테스트 실패: 기존 코드로 복구

④ 코드 배포
* CD 단계에서의 빌드: 테스트를 통과한 코드를 포함한 최종 실행 환경을 생성(training:latest, trainig:v1.0)

테스트 성공 시 최종 데이터 처리 환경을 ECR에 업로드
- json_to_neo4j.py 코드가 통합된 최종 Docker 이미지를 빌드
- 태그별로 관리
  - latest: 최신 버전
  - v1.0, v1.1: 커밋 ID 또는 버전을 기준으로 관리
- ECR에 업로드하여 중앙 저장소로 관리
가상환경 업데이트 (EC2 B)
- ECR에서 최신 Docker 이미지 Pull
  - ECR에 저장된 최신 데이터 처리 환경(neo4j-processor:latest) 이미지를 EC2 B에서 Pull
- Docker 이미지에서 최신 소스코드와 패키지 추출
  - Docker 컨테이너를 실행하여 최신 json_to_neo4j.py 및 필요한 의존성 파일(requirements.txt)을 추출
- 가상환경 활성화 및 패키지 업데이트
  - EC2 B에서 가상환경을 활성화하고, Docker 이미지에서 추출한 최신 requirements.txt를 사용해 패키지를 설치
- 최신 소스코드 적용
  - Docker 이미지에서 추출한 최신 데이터 처리 코드(json_to_neo4j.py)를 기존 프로젝트 경로에 복사
- 최신 환경으로 가상환경 갱신 완료
  - 가상환경이 최신 패키지와 코드로 업데이트되어 데이터 처리가 준비 완료
Neo4j 설정 및 데이터 반영 유지
- 기존 가상환경에서의 Neo4j 설정을 유지
- 최신 코드가 설치된 가상환경에서 Neo4j 데이터베이스와 연동하여 데이터 반영 작업을 이어서 수행

[tip] 레지스트리 옵션 비교

레지스트리	특징	비용	성능
AWS Elastic Container Registry (ECR)	AWS 서비스와 통합, 높은 보안성 (IAM 사용)	이미지 저장소 사용량 기준 (저렴)	AWS 환경에서 최적화됨
Docker Hub	가장 널리 사용됨, 간단한 설정	무료 (공개 저장소), 프라이빗은 월 $5~	글로벌 사용, 속도 보통
Google Container Registry (GCR)	GCP 환경에 최적화, 높은 확장성	이미지 저장소 사용량 기준 (저렴)	GCP 환경에서 최적화됨
Azure Container Registry (ACR)	Azure와 긴밀히 통합, 보안 및 스케일링 우수	이미지 저장소 사용량 기준 (저렴)	Azure 환경에서 최적화됨
Harbor	오픈소스, 자체 호스팅 가능, 강력한 보안 및 접근 제어	자체 호스팅 비용 발생 (서버 유지 필요)	서버 성능에 따라 다름
GitLab Container Registry	GitLab과 통합된 레지스트리, CI/CD에 최적화	무료 플랜에 포함	GitLab CI/CD에 최적화됨

2. GitLab CI/CD 코드 작성

1) GitLab 프로젝트 설정

① GitLab 프로젝트 생성

GitLab에 로그인하고 새 프로젝트 생성
기존 코드를 사용하려면 저장소를 클론하거나 새 코드를 푸시

② GitLab Runner 등록

CI/CD 작업을 실행하기 위해 GitLab Runner가 필요
GitLab Shared Runner 사용
- GitLab이 기본 제공하는 Shared Runner를 사용
- 별도 설정이 필요 없으며 .gitlab-ci.yml 파일만 작성하면 바로 실행됨

2) .gitlab-ci.yml 작성

.gitlab-ci.yml은 CI/CD 파이프라인의 핵심 파일로, 각 스테이지와 작업을 정의

# .gitlab-ci.yml
stages:
  - build
  - test
  - deploy

variables:
  # Docker 데몬 설정
  DOCKER_HOST: tcp://docker:2375
  DOCKER_TLS_CERTDIR: ""
  # EC2 인스턴스 IP 주소 변수화
  EC2_A_IP: "<EC2_A_IP>"
  EC2_B_IP: "<EC2_B_IP>"

# 학습 환경 빌드
build_train:
  stage: build
  image: docker:latest
  services:
    - docker:dind
  script:
    # AWS CLI 자격 증명 설정
    - aws configure set aws_access_key_id $AWS_ACCESS_KEY_ID
    - aws configure set aws_secret_access_key $AWS_SECRET_ACCESS_KEY
    # Docker 이미지를 빌드하여 training:latest 태그로 지정
    - docker build -t $ECR_REGISTRY/training:latest .
    # 빌드한 이미지를 커밋 ID 기반 버전 태그로 추가
    - docker tag $ECR_REGISTRY/training:latest $ECR_REGISTRY/training:$CI_COMMIT_SHORT_SHA
  rules:
    # train.py 또는 requirements.txt가 변경된 경우에만 실행
    - changes:
        - train.py
        - requirements.txt

# 학습 환경 테스트
test_train:
  stage: test
  image: docker:latest
  services:
    - docker:dind
  script:
    # training:latest 이미지를 실행하여 train.py를 테스트
    - docker run --rm $ECR_REGISTRY/training:latest pytest train.py
  rules:
    # train.py 또는 requirements.txt가 변경된 경우에만 실행
    - changes:
        - train.py
        - requirements.txt

# 학습 환경 배포 및 가상환경 갱신
deploy_train:
  stage: deploy
  image: docker:latest
  services:
    - docker:dind
  script:
    # 빌드된 training 이미지를 ECR에 push (최신 버전)
    - docker push $ECR_REGISTRY/training:latest
    # 빌드된 training 이미지를 ECR에 push (커밋 ID 기반 버전)
    - docker push $ECR_REGISTRY/training:$CI_COMMIT_SHORT_SHA
    # EC2 A에 SSH 접속하여 가상환경 갱신
    - ssh -i /path/to/key.pem ec2-user@$EC2_A_IP << EOF
        # ECR에서 최신 training 이미지를 pull
        docker pull $ECR_REGISTRY/training:latest
        # Docker 컨테이너 실행 후 최신 소스코드 및 requirements 추출
        docker run --rm -v /home/ec2-user/output:/output $ECR_REGISTRY/training:latest cp -r /app /output
        # 가상환경 활성화 및 패키지 갱신
        source /home/ec2-user/my-venv/bin/activate
        pip install --upgrade -r /home/ec2-user/output/requirements.txt
        # 최신 소스코드 복사
        cp /home/ec2-user/output/train.py /home/ec2-user/project/train.py
      EOF
  rules:
    # train.py 또는 requirements.txt가 변경된 경우에만 실행
    - changes:
        - train.py
        - requirements.txt

# Neo4j 데이터 처리 환경 빌드
build_neo4j:
  stage: build
  image: docker:latest
  services:
    - docker:dind
  script:
    # AWS CLI 자격 증명 설정
    - aws configure set aws_access_key_id $AWS_ACCESS_KEY_ID
    - aws configure set aws_secret_access_key $AWS_SECRET_ACCESS_KEY
    # Docker 이미지를 빌드하여 neo4j-processor:latest 태그로 지정
    - docker build -t $ECR_REGISTRY/neo4j-processor:latest .
    # 빌드한 이미지를 커밋 ID 기반 버전 태그로 추가
    - docker tag $ECR_REGISTRY/neo4j-processor:latest $ECR_REGISTRY/neo4j-processor:$CI_COMMIT_SHORT_SHA
  rules:
    # json_to_neo4j.py 또는 neo4j-config.yaml이 변경된 경우에만 실행
    - changes:
        - json_to_neo4j.py
        - neo4j-config.yaml

# Neo4j 데이터 처리 환경 테스트
test_neo4j:
  stage: test
  image: docker:latest
  services:
    - docker:dind
  script:
    # neo4j-processor:latest 이미지를 실행하여 json_to_neo4j.py를 테스트
    - docker run --rm $ECR_REGISTRY/neo4j-processor:latest pytest json_to_neo4j.py
  rules:
    # json_to_neo4j.py 또는 neo4j-config.yaml이 변경된 경우에만 실행
    - changes:
        - json_to_neo4j.py
        - neo4j-config.yaml

# Neo4j 환경 배포 및 가상환경 갱신
deploy_neo4j:
  stage: deploy
  image: docker:latest
  services:
    - docker:dind
  script:
    # 빌드된 neo4j-processor 이미지를 ECR에 push (최신 버전)
    - docker push $ECR_REGISTRY/neo4j-processor:latest
    # 빌드된 neo4j-processor 이미지를 ECR에 push (커밋 ID 기반 버전)
    - docker push $ECR_REGISTRY/neo4j-processor:$CI_COMMIT_SHORT_SHA
    # EC2 B에 SSH 접속하여 가상환경 갱신
    - ssh -i /path/to/key.pem ec2-user@$EC2_B_IP << EOF
        # ECR에서 최신 neo4j-processor 이미지를 pull
        docker pull $ECR_REGISTRY/neo4j-processor:latest
        # Docker 컨테이너 실행 후 최신 소스코드 및 requirements 추출
        docker run --rm -v /home/ec2-user/output:/output $ECR_REGISTRY/neo4j-processor:latest cp -r /app /output
        # 가상환경 활성화 및 패키지 갱신
        source /home/ec2-user/neo4j-venv/bin/activate
        pip install --upgrade -r /home/ec2-user/output/requirements.txt
        # 최신 소스코드 복사
        cp /home/ec2-user/output/json_to_neo4j.py /home/ec2-user/project/json_to_neo4j.py
      EOF
  rules:
    # json_to_neo4j.py 또는 neo4j-config.yaml이 변경된 경우에만 실행
    - changes:
        - json_to_neo4j.py
        - neo4j-config.yaml

3) CI/CD 환경 변수 설정

GitLab 프로젝트에서 CI/CD 파이프라인이 외부 서비스(S3, Neo4j 등)와 통신하려면 환경 변수를 설정해야 함
① GitLab 환경 변수 설정

GitLab 프로젝트 > Settings > CI/CD > Variables에서 추가
ex:
- AWS_ACCESS_KEY_ID: AWS IAM 사용자 액세스 키
- AWS_SECRET_ACCESS_KEY: AWS IAM 사용자 시크릿 키
- ECR_REGISTRY: ECR URL
- EC2_A_IP, EC2_B_IP: 학습 및 Neo4j 가상환경이 실행되는 EC2의 IP

② 환경 변수 사용

.gitlab-ci.yml에서 $VARIABLE_NAME으로 참조

4) Docker 이미지 빌드

GitLab Runner가 작업을 실행하려면 Docker 이미지를 사용해야 함

필요한 환경을 Dockerfile로 정의하고 커스텀 Docker 이미지 빌드
- Docker 이미지 정의: Dockerfile
- 어떤 환경에서 어떤 의존성을 설치하고 어떤 코드를 포함해야 하는지를 지정

# Dockerfile
FROM python:3.9
RUN pip install -r requirements.txt
WORKDIR /app
COPY . /app

- Docker 이미지 빌드: .gitlab-ci.yml의 build script 에 포함

5) Lambda가 GitLab Runner 호출

Lambda는 S3 이벤트를 감지한 후 GitLab Runner를 호출

Lambda 함수

import requests

def trigger_gitlab_runner():
    url = "https://gitlab.com/api/v4/projects/<project_id>/trigger/pipeline"
    token = "<trigger_token>"
    response = requests.post(url, data={
        "token": token,
        "ref": "main"
    })
    print(response.status_code, response.text)

# 호출 예시
trigger_gitlab_runner()

6) ECR 저장 및 EC2 가상환경 통합

① ECR 저장

테스트를 통과한 Docker 이미지를 latest와 커밋 ID 기반 태그로 저장
ex: training:latest, training:<commit_id>

② EC2 A 및 EC2 B 가상환경 업데이트

EC2 A (학습 환경)
- ECR에서 최신 Docker 이미지를 Pull
- Docker 이미지를 실행하여 최신 소스코드(train.py) 및 패키지(requirements.txt)를 추출
- 가상환경을 활성화하고, 추출된 requirements.txt를 사용하여 최신 패키지를 설치
- 기존 학습 코드(train.py)를 최신 버전으로 교체
EC2 B (Neo4j 데이터 처리 환경)
- ECR에서 최신 Docker 이미지를 Pull
- Docker 이미지를 실행하여 최신 소스코드(json_to_neo4j.py) 및 패키지(requirements.txt)를 추출
- 가상환경을 활성화하고, 추출된 requirements.txt를 사용하여 최신 패키지를 설치
- 기존 데이터 처리 코드(json_to_neo4j.py)를 최신 버전으로 교체

7) 실패 디버깅

GitLab > CI/CD > Pipelines에서 실행 기록 확인
각 작업의 실행 로그를 통해 실패 원인 파악

8) 요약

Lambda 역할
- S3 이벤트를 감지하여 GitLab Runner를 호출
GitLab CI/CD 역할
- Docker 이미지를 빌드 및 테스트 후 ECR에 저장
- 최신 이미지를 EC2 A, B로 배포 및 가상환경 갱신
최종 상태
- 모든 과정이 자동화되어 최신 학습 환경 및 데이터 처리 환경이 가상환경 단위로 관리됨

3. GitHub Action VS GitLab

	GitHub Actions	GitLab CI/CD
플랫폼	GitHub 전용 (GitHub 저장소와 통합)	GitLab 전용 (GitLab 저장소와 통합)
설정 파일	.github/workflows/*.yml 파일 사용	.gitlab-ci.yml 파일 사용
실행 환경 (Runner)	GitHub에서 제공하는 호스팅 Runner 또는 셀프 호스팅 Runner 지원	GitLab에서 제공하는 공유 Runner 또는 셀프 호스팅 Runner 지원
직관성	작업 워크플로우를 직관적으로 설계 가능 (워크플로우 중심)	단계별로 작업을 정의 (스테이지 중심)
멀티 OS 지원	Linux, macOS, Windows 지원	주로 Linux 지원 (Windows는 제한적으로 셀프 호스팅 Runner로 지원 가능)
확장성	GitHub Actions Marketplace에서 수많은 액션 사용 가능	GitLab에서 스크립트 기반으로 작업 정의
로그 및 디버깅	웹 UI에서 각 스텝별로 로그 확인 가능	GitLab 웹 UI에서 단계별로 로그 확인 가능
보안	- GitHub Secrets로 보안 토큰 및 환경 변수 관리 - Runner에 컨테이너 실행 가능. 하지만 추가 세팅 필요 - GitHub 저장소의 Branch Protection Rules, Team Permissions 지원	- GitLab Variables로 보안 토큰 및 환경 변수 관리 - GitLab Runner에서 컨테이너화된 CI/CD 파이프라인 실행 가능. Docker와 네이티브 통합 - GitLab의 Protected Branch, User Roles로 세분화된 접근 제어 가능

1) GitLab 채택 이유

컨테이너 단위 최신 환경 업데이트
- Docker 컨테이너 기반으로 작업을 구성할 수 있어, 최신 환경의 배포 및 복구가 간단
- CI/CD 파이프라인 단계에서 컨테이너를 빌드, 테스트, 배포하기 때문에 환경 간 불일치 문제를 최소화
- ECR과 같은 레지스트리에 이미지를 업로드하여 버전 관리를 통해 어떤 환경에서든 재현 가능
유연한 파이프라인 설정
- .gitlab-ci.yml 파일로 파이프라인 조건, 병렬 처리, 단계 간 의존성을 세부적으로 설정 가능
- rules 및 only/except 조건을 통해 특정 파일 변경 시에만 빌드나 배포를 실행 가능
- 병렬 처리로 학습 코드와 Neo4j 코드 등 다른 워크로드를 동시에 처리 가능
GitLab 내장 기능
- 종속성 관리: GitLab CI/CD는 Python의 requirements.txt 같은 종속성 관리도 단계별 테스트와 결합 가능
- 테스트 결과 통합: CI/CD 단계에서 발생한 테스트 결과를 GitLab의 UI에서 바로 확인 가능
- 모니터링: 각 단계의 로그를 GitLab UI에서 한눈에 확인 가능
- 디버깅: 실패한 파이프라인에 대한 디버깅을 지원하며, 실패 지점에서 재시작 가능
보안
- IAM 및 세부 권한 관리: GitLab은 세부적인 권한 관리를 제공하며, CI/CD 작업별로 접근을 제한할 수 있음
- 보안 취약점 스캐닝: GitLab CI/CD는 기본적으로 SAST, DAST 등 보안 스캔을 통합 지원하여 코드와 파이프라인의 보안성을 자동으로 확인
- 컨테이너?

2) 추가 개념

(1) Runner

GitLab Runner
- GitLab Runner: .gitlab-ci.yml 파일에 정의된 CI/CD 작업을 실행하는 도구
- 이 Runner는 CI/CD 작업을 실행할 때 Docker 컨테이너를 이용해 격리된 환경을 제공
- ex:
  - image: python: 3.9 라고 지정 → python 3.9가 설치된 Docker 이미지를 사용하여 작업이 실행됨

(2) Executor

Docker Executor
- GitLab Runner: Executor를 관리∙실행
- Docker Executor: Runner가 Docker를 사용하여 작업을 실행하는 구체적인 방법

(3) CI/CD 컨테이너

컨테이너화된 실행
- GitLab CI/CD: 작업을 실행할 때 Docker 컨테이너를 임시로 생성 → 그 안에서 CI/CD 작업을 실행
- 이 컨테이너는 .gitlab-ci.yml 에서 지정한 image를 기반으로 생성됨
- 작업이 끝나면 컨테이너가 삭제됨
컨테이너화의 의미
- .gitlab-ci.yml 파일에 정의된 파이프라인(빌드, 테스트, 배포 작업)을 실행하기 위해, GitLab Runner는 지정된 Docker 이미지를 기반으로 컨테이너를 생성
- 컨테이너 내부에서 파이프라인 작업 실행
  - 필요한 의존성 설치
  - 코드(New 모델 학습 코드) 실행
  - 테스트( New 모델 학습 코드 실행 테스트 / New 모델의 성능 테스트) 수행
  - 결과물(New 모델)을 저장하거나 배포
- .gitlab-ci.yml에서 image: python:3.9을 지정하면 CI/CD 작업은 이 이미지를 기반으로 생성된 컨테이너에서 실행됨. 이는 CI/CD 파이프라인 작업 환경을 일관되게 유지("어느 서버에서 실행해도 같은 결과가 나오도록")하기 위한 것
  - Docker 이미지 ≒ 가상환경
컨테이너 생성 흐름

① .gitlab-ci.yml 파일에 Python 3.9 이미지를 지정
② GitLab Runner는 Python 3.9 이미지를 사용해 컨테이너를 생성
③ 생성된 컨테이너에서 CI/CD 작업 수행
- ex: pip install -r requirements.txt로 필요한 의존성을 설치
- 모델 학습 코드 실행(train.py)
④ 작업 완료 후 컨테이너는 삭제

컨테이너화가 보안에 좋은 이유

① 작업 환경의 격리

컨테이너는 격리된 환경에서 실행되기 때문에, CI/CD 작업이 다른 작업 환경에 영향을 미치지 않음
만약 실행 중인 작업에서 문제가 발생하거나 악성 코드가 삽입되더라도, 컨테이너 내부에 제한되어 호스트 시스템이나 다른 작업 환경으로 확산되지 않음

② 의존성과 권한의 제한

Docker 컨테이너는 필요한 의존성만 포함하도록 구성할 수 있어 필요하지 않은 시스템 자원 접근을 차단
ex:
- CI/CD 작업에 Python 3.9와 몇 가지 라이브러리만 필요하다면, 다른 불필요한 소프트웨어는 포함되지 않음
- 특정 권한(네트워크, 파일 시스템 등)만 부여하여 작업 범위를 최소화
- 원격 코드 실행 취약점 같은 보안 이슈가 있어도 제한된 환경에서 실행되기 때문에 피해가 줄어듦

③ 환경의 일관성 유지 (Reproducibility)

CI/CD 파이프라인 작업 환경이 항상 동일한 Docker 이미지를 기반으로 하므로, 알 수 없는 외부 요인에 의해 보안이 위협되는 상황을 예방
ex:
- 호스트 서버의 Python 버전, 패키지 충돌 등으로 인해 발생할 수 있는 예상치 못한 취약점을 최소화

④ 최소한의 공격 표면

컨테이너는 CI/CD 작업에 필요한 최소한의 환경만 포함
작업 중 사용하는 컨테이너는 임시로 생성되며, 작업 종료 후 삭제되기 때문에 공격자가 접근할 기회가 줄어듦

⑤ 비밀 관리 (Secrets Management)

컨테이너 내부에서만 환경 변수 또는 비밀 키를 사용하도록 설정
GitLab CI/CD는 GitLab Variables를 사용해 환경 변수를 안전하게 관리
비밀 키나 토큰이 노출되지 않고, 컨테이너 외부로 유출될 위험을 최소화

⑥ 컨테이너 이미지의 신뢰성 검증

Docker 이미지는 사전에 검증된 상태로 사용 가능
공식 이미지나 내부에서 관리하는 이미지만 사용하면, 악성 코드가 포함된 환경을 사용하는 위험을 줄일 수 있음

📙 내일 일정

최종 프로젝트

'TIL _Today I Learned > 2024.12' 카테고리의 다른 글

[DAY 102] 최종 프로젝트_ Labeling Pipeline (2)	2024.12.12
[DAY 101] 최종 프로젝트_ 네트워크 (0)	2024.12.11
[DAY 99] 최종 프로젝트_ AWS 아키텍처 설계 (1)	2024.12.09
[DAY 98] 최종 프로젝트_ 모델 Fine Tuning, 플로우 차트 (2)	2024.12.06
[DAY 97] 최종 프로젝트_ GraphRAG, MLOps, CI/CD (0)	2024.12.05

즐기는 코딩 [즐:코]

[DAY 100] 최종 프로젝트_ GitLab

📕 프로젝트 작업 내역

📗 수행 결과

1. GitLab CI/CD 목표 설정

2. GitLab CI/CD 코드 작성

3. GitHub Action VS GitLab

📙 내일 일정

'TIL _Today I Learned > 2024.12' 카테고리의 다른 글

티스토리툴바

[DAY 100] 최종 프로젝트_ GitLab

📕 프로젝트 작업 내역

📗 수행 결과

1. GitLab CI/CD 목표 설정

2. GitLab CI/CD 코드 작성

3. GitHub Action VS GitLab

📙 내일 일정

'TIL _Today I Learned > 2024.12' 카테고리의 다른 글

관련글

티스토리툴바