DevOps-and-Infrastructure

Gitlab CI .gitlab-ci.yml 구조 Stage/Job 구성 및 GitLab Pages 활용 Multi-Project 파이프라인 Auto DevOps 설정 Kubernetes 배포 자동화 GitLab에 내장된 지속적 통합/배포 도구로, .gitlab-ci.yml 파일을 통해 파이프라인을 정의하고 관리 특징 통합성: GitLab 저장소와 긴밀하게 통합되어 있어 별도의 도구 없이 CI/CD 파이프라인을 구축할 수 있습니다. 유연성: YAML 파일을 통해 파이프라인을 구성할 수 있어 다양한 프로젝트 요구사항에 맞춤 설정이 가능합니다. 확장성: 다양한 Runner 유형을 지원하여 다양한 환경에서 작업을 실행할 수 있습니다. 가시성: 파이프라인 실행 상태와 결과를 GitLab 인터페이스에서 쉽게 확인할 수 있습니다. 기능 자동 빌드 및 테스트: 코드 변경 시 자동으로 빌드 및 테스트를 실행합니다. 환경 배포: 다양한 환경(개발, 스테이징, 프로덕션 등)에 자동으로 배포할 수 있습니다. 아티팩트 관리: 빌드 결과물을 저장하고 관리할 수 있습니다. 병렬 실행: 여러 작업을 동시에 실행하여 파이프라인 속도를 향상시킵니다. 환경 변수 관리: 민감한 정보를 안전하게 저장하고 사용할 수 있습니다. 구성요소 .gitlab-ci.yml: 파이프라인 구성 파일 Runners: 작업을 실행하는 에이전트 Jobs: 실행할 개별 작업 Stages: 작업의 실행 순서를 정의하는 단계 Pipeline: 전체 CI/CD 프로세스 장점 GitLab과의 긴밀한 통합 쉬운 설정과 사용 확장성과 유연성 무료로 사용 가능한 기능이 많음 단점 GitLab에 종속적 복잡한 워크플로우의 경우 설정이 복잡해질 수 있음 일부 고급 기능은 유료 버전에서만 사용 가능 설정 방법 프로젝트 루트에.gitlab-ci.yml 파일 생성 YAML 형식으로 파이프라인 구성 작성 변경사항을 커밋하고 푸시 GitLab에서 파이프라인 실행 확인 .gitlab-ci.yml 파일의 기본 구조 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 stages: - build - test - deploy job1: stage: build script: - echo "Building the project..." job2: stage: test script: - echo "Running tests..." job3: stage: deploy script: - echo "Deploying to production..." 주요 구성 요소 stages: 파이프라인의 실행 단계를 정의합니다. 각 단계는 순차적으로 실행됩니다. jobs: 각 작업을 정의합니다. 작업은 특정 단계에 속하며, 실행할 스크립트를 포함합니다. script: 작업에서 실행할 명령어들을 정의합니다. image: 작업을 실행할 Docker 이미지를 지정합니다. artifacts: 작업 결과물을 저장하고 다른 작업에서 사용할 수 있게 합니다. cache: 작업 간에 공유할 파일이나 디렉토리를 지정합니다. 고급 구성 옵션 only/except: 특정 브랜치나 태그에서만 작업을 실행하거나 제외할 수 있습니다. variables: 파이프라인 전체 또는 특정 작업에서 사용할 변수를 정의합니다. before_script/after_script: 작업 실행 전후에 실행할 스크립트를 정의합니다. environment: 배포 환경을 지정합니다. 예시 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 32 33 34 35 36 37 38 39 40 41 42 43 # 파이프라인 단계 정의 stages: - build - test - deploy # 캐시 설정: node_modules 폴더를 캐시하여 빌드 속도 향상 cache: paths: - node_modules/ # 빌드 작업 정의 build: stage: build image: node:14 # Node.js 14 버전 이미지 사용 script: - npm install # 의존성 설치 - npm run build # 프로젝트 빌드 artifacts: paths: - dist/ # 빌드 결과물 저장 # 테스트 작업 정의 test: stage: test image: node:14 script: - npm install # 의존성 설치 - npm test # 테스트 실행 # 배포 작업 정의 deploy: stage: deploy image: alpine:latest script: - apk add --no-cache rsync openssh # 배포에 필요한 도구 설치 - mkdir -p ~/.ssh - echo "$SSH_PRIVATE_KEY" | tr -d '\r' > ~/.ssh/id_rsa - chmod 600 ~/.ssh/id_rsa - ssh-keyscan -H $DEPLOY_SERVER_IP >> ~/.ssh/known_hosts - rsync -avz --delete dist/ $DEPLOY_USER@$DEPLOY_SERVER_IP:/path/to/deployment/ only: - master # master 브랜치에 푸시될 때만 실행 stages: 파이프라인의 단계를 정의합니다. 여기서는 build, test, deploy 세 단계로 구성됩니다. cache: node_modules 폴더를 캐시하여 빌드 속도를 향상시킵니다. build 작업: stage: build로 빌드 단계에 할당합니다. Node.js 14 버전 이미지를 사용합니다. npm install로 의존성을 설치하고, npm run build로 프로젝트를 빌드합니다. artifacts를 사용하여 빌드 결과물을 저장합니다. test 작업: stage: test로 테스트 단계에 할당합니다. npm test 명령으로 테스트를 실행합니다. deploy 작업: stage: deploy로 배포 단계에 할당합니다. Alpine Linux 이미지를 사용하여 가벼운 환경을 구성합니다. SSH 키를 설정하고 rsync를 사용하여 빌드 결과물을 서버에 배포합니다. only: - master로 master 브랜치에 푸시될 때만 실행되도록 설정합니다. 기본 설정 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 32 33 34 35 36 37 38 39 40 # GitLab CI의 기본 설정 예시 image: node:16 # 기본 Docker 이미지 지정 # 파이프라인 스테이지 정의 stages: - build - test - deploy # 캐시 설정 - node_modules 디렉토리를 캐시 cache: paths: - node_modules/ # 빌드 작업 정의 build: stage: build # 속한 스테이지 지정 script: - npm install # 의존성 설치 - npm run build # 빌드 실행 artifacts: # 빌드 결과물 저장 paths: - dist/ # 테스트 작업 정의 test: stage: test script: - npm run test # 테스트 실행 dependencies: # build 작업의 결과물 사용 - build # 배포 작업 정의 deploy: stage: deploy script: - echo "Deploying application…" - npm run deploy only: # main 브랜치에서만 실행 - main 고급 설정 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 32 33 34 35 36 37 38 39 40 # 환경변수와 조건부 실행이 포함된 고급 설정 예시 variables: DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG # Docker 이미지 태그 정의 # 커스텀 도커 이미지 빌드 build_image: image: docker:20.10.16 services: - docker:20.10.16-dind # Docker-in-Docker 서비스 stage: build script: # Docker 레지스트리 로그인 - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY # Docker 이미지 빌드 및 푸시 - docker build -t $DOCKER_IMAGE . - docker push $DOCKER_IMAGE rules: - if: $CI_COMMIT_BRANCH == "main" # main 브랜치에서만 실행 when: always - when: never # 그 외의 경우 실행하지 않음 # 보안 스캔 작업 security_scan: image: security-scanner stage: test script: - scan-dependencies # 의존성 취약점 검사 - scan-code # 코드 보안 검사 allow_failure: true # 실패해도 파이프라인 계속 진행 # 스테이징 환경 배포 deploy_staging: stage: deploy environment: name: staging script: - deploy-to-kubernetes.sh --env staging rules: - if: $CI_COMMIT_BRANCH == "develop" 환경별 배포 설정 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 # 환경별 배포 구성 예시 .deploy_template: &deploy_template # 재사용 가능한 배포 템플릿 정의 script: - echo "Deploying to $CI_ENVIRONMENT_NAME" - kubectl apply -f k8s/$CI_ENVIRONMENT_NAME/ deploy_dev: <<: *deploy_template # 템플릿 상속 environment: name: development rules: - if: $CI_COMMIT_BRANCH == "develop" deploy_prod: <<: *deploy_template environment: name: production rules: - if: $CI_COMMIT_BRANCH == "main" when: manual # 수동 승인 후 배포 병렬 작업 실행 1 2 3 4 5 6 7 8 9 10 11 12 13 14 # 병렬 테스트 실행 예시 test: parallel: 3 # 3개의 병렬 작업 생성 script: - npm run test -- --split=$CI_NODE_INDEX/$CI_NODE_TOTAL # 매트릭스 작업 정의 test_matrix: parallel: matrix: - NODE_VERSION: ["14", "16", "18"] DB_TYPE: ["mysql", "postgres"] script: - docker-compose run --rm -e NODE_VERSION=$NODE_VERSION -e DB_TYPE=$DB_TYPE test 캐시와 아티팩트 관리 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 # 캐시와 아티팩트 관리 예시 build: cache: key: ${CI_COMMIT_REF_SLUG} # 브랜치별 캐시 키 paths: - node_modules/ - .npm/ policy: pull-push # 캐시 정책 설정 artifacts: paths: - dist/ # 빌드 결과물 - coverage/ # 테스트 커버리지 리포트 reports: junit: test-results.xml # 테스트 결과 리포트 coverage: coverage/lcov.info # 커버리지 리포트 expire_in: 1 week # 아티팩트 유효 기간 이러한 설정들은 프로젝트의 요구사항과 규모에 따라 적절히 조정하여 사용할 수 있습니다. ...

CI(지속적 통합) Vs. CD(지속적 전달) vs. CD(지속적 배포) CI/CD 는 현대 소프트웨어 개발 방법론의 핵심으로, 개발 과정을 자동화하고 신속하게 가치를 전달하는 데 중점을 둔다. 지속적 통합 (CI) 은 개발자가 코드 변경 사항을 자주 통합하고 검증하는 과정을 말하며, 지속적 전달 (CD) 은 검증된 코드를 자동으로 프로덕션 환경에 배포 가능한 상태로 준비하는 과정을, 지속적 배포 (CD) 는 검증된 코드를 자동으로 프로덕션 환경에 배포하는 과정을, 각각 자동화하는 방법론이다. 이 세 가지 접근 방식의 주요 차이점은 코드 변경 사항이 프로덕션 환경에 도달하는 자동화 수준과 사람의 개입 정도에 있다. CI/CD 파이프라인은 코드 품질 향상, 출시 주기 단축, 팀 협업 강화 등 다양한 이점을 제공하며, 최신 트렌드로는 GitOps, AIOps, 보안 통합 (DevSecOps) 등이 있다. ...

History and Evolution of CI/CD CI/CD(지속적 통합/지속적 배포) 의 역사와 발전은 소프트웨어 개발 방법론의 진화를 보여주는 중요한 여정입니다. 1990 년대 후반 익스트림 프로그래밍 (XP) 에서 처음 등장한 지속적 통합 개념이 시작점이었으며, 이후 애자일 방법론의 부상과 함께 발전했다. 워터폴 모델의 한계를 극복하기 위해 등장한 CI/CD 는 개발자들이 코드 변경사항을 빈번하게 통합하고 자동화된 테스트를 수행하는 방식으로 진화했다. 2000 년대 중반 젠킨스 (이전의 허드슨) 의 등장은 CI/CD 도구의 대중화를 이끌었고, 이후 클라우드와 컨테이너 기술의 발전과 함께 GitLab CI, CircleCI, GitHub Actions 등 다양한 도구들이 등장했다. 현재 CI/CD 는 GitOps, AIOps, 보안 통합 (DevSecOps) 등의 최신 트렌드를 포함하며 계속 발전하고 있다. 이 발전 과정은 수동적이고 경직된 개발 프로세스에서 자동화되고 유연한 방식으로의 전환을 보여주며, 소프트웨어 산업의 혁신과 속도를 가속화하는 데 중요한 역할을 하고 있다. ...

Code Review Best Practices **Version Control Systems (VCS)**에서 Code Review Best Practices는 코드 품질 향상과 팀 협업 강화를 위한 핵심 프로세스입니다. 소프트웨어 개발 과정에서 동료 개발자가 작성한 코드를 검토하여 품질을 향상시키고, 버그를 사전에 방지하며, 지식 공유를 촉진하는 역할을 한다. 2025 년 현재 AI 통합, 자동화된 검토 도구, 지표 기반 평가가 주요 트렌드로 부상하며, Git 을 중심으로 한 워크플로우 최적화가 중요시된다. 핵심 개념 및 목적 코드 리뷰는 한 개발자가 작성한 코드를 다른 개발자가 검토하는 체계적인 프로세스이다. 주로 풀 리퀘스트 (Pull Request) 또는 머지 리퀘스트 (Merge Request) 를 통해 이루어지며, 코드의 품질, 가독성, 기능성 및 표준 준수 여부를 평가한다. ...

Release Management 릴리스 관리 (Release Management) 는 소프트웨어 개발 프로세스에서 코드 변경사항을 개발 환경에서 프로덕션 환경으로 안전하고 체계적으로 배포하는 전체 과정을 관리하는 방법론이다. 이는 버전 관리 시스템과 긴밀하게 연계되어 코드 변경사항의 추적, 버전 관리, 배포 프로세스 자동화 등을 포함한다. 효과적인 릴리스 관리는 소프트웨어의 품질 보장, 배포 위험 최소화, 사용자 경험 향상, 개발 팀의 생산성 증대에 기여한다. 2025 년 현재 DevOps 및 CI/CD 도구와의 통합을 통해 지속적 배포 자동화가 강화되고 있으며, AI 기반 위험 관리 및 클라우드 네이티브 아키텍처 지원이 주목받고 있다. ...

Open Source Contribution 오픈소스 기여 (Open Source Contribution) 는 공개된 소프트웨어 프로젝트에 개인이나 조직이 코드, 문서, 테스트, 버그 리포트 등을 통해 참여하는 활동이다. 이는 버전 관리 시스템 (특히 Git) 을 중심으로 이루어지며, Fork-Clone- 수정 -Pull Request 로 이어지는 표준화된 워크플로우를 통해 진행된다. 오픈소스 기여는 소프트웨어 개발 생태계의 지속 가능성을 유지하고, 개발자 간 지식 공유와 협업을 촉진하며, 개인 개발자에게는 실무 경험과 평판을 쌓을 기회를 제공한다. 핵심 개념 오픈소스 기여는 공개된 소프트웨어 프로젝트에 개발자가 자발적으로 참여하여 코드, 문서, 디자인, 테스트 등을 통해 가치를 더하는 활동이다. ...

Large-scale Management 대규모 버전 관리 시스템 (Version Control Systems) 의 엔터프라이즈 활용은 수백 명의 개발자와 수십 기가바이트 이상의 코드베이스를 효율적으로 관리하기 위한 전략과 기술을 포함한다. Git 과 같은 분산 버전 관리 시스템 (DVCS) 은 유연성과 확장성을 제공하지만, 대규모 환경에서는 성능 최적화, 브랜칭 전략, 접근 제어, 코드 소유권 관리 등 추가적인 고려사항이 필요하다. 이를 위해 Partial Clone, Shallow Clone, Submodule, CODEOWNERS 파일 등의 기능이 활용되며, 팀 규모에 따른 브랜칭 전략도 중요하다. ...

MonoRepo vs. MultiRepo 모노레포 (Monorepo) 와 멀티레포 (Multirepo) 는 소프트웨어 개발에서 코드베이스를 관리하는 대표적인 두 가지 전략이다. MonoRepo는 여러 프로젝트를 하나의 저장소에서 관리하는 방식으로, 코드 공유와 일관된 개발 환경을 제공한다. 반면, MultiRepo는 각 프로젝트를 별도의 저장소에서 관리하여 독립성과 유연성을 강조한다. 이 두 접근 방식은 코드 공유, 종속성 관리, 빌드 시스템, 팀 협업, 확장성 등의 측면에서 서로 다른 장단점을 가지고 있다. 프로젝트의 규모, 팀 구조, 회사 문화, 기술 스택 등 다양한 요소에 따라 적합한 방식이 달라질 수 있으며, 최근에는 두 방식의 장점을 결합한 하이브리드 접근법이나 각 방식의 단점을 보완하는 도구들도 등장하고 있다. ...

Observability vs. Monitoring 비교 항목 Observability Monitoring 정의 시스템의 내부 상태를 외부 출력을 통해 이해하고 추론할 수 있는 능력 시스템의 동작과 성능을 지속적으로 관찰하고 추적하는 활동 목적 예측하지 못한 문제의 근본 원인을 파악하고 시스템의 동작을 심층적으로 이해 알려진 문제와 패턴을 감지하고 사전 정의된 임계값을 모니터링 데이터 수집 방식 이벤트, 로그, 트레이스, 메트릭스 등 다양한 형태의 원시 데이터 수집 주로 미리 정의된 메트릭과 상태 정보 수집 데이터 분석 방식 동적이고 탐색적인 분석, 실시간 질의 및 상관관계 분석 사전 정의된 대시보드와 알림 규칙 기반 분석 문제 해결 접근법 귀납적 접근 - 데이터를 통해 문제의 패턴과 원인을 발견 연역적 접근 - 알려진 문제 패턴에 기반한 탐지 도구의 특성 유연하고 탐색적인 도구 (예: Jaeger, OpenTelemetry) 고정된 대시보드와 알림 시스템 (예: Nagios, Prometheus) 데이터 저장 기간 일반적으로 더 긴 기간 (문제 패턴 분석을 위해) 상대적으로 짧은 기간 (실시간 모니터링 중심) 사용자 관점 개발자, SRE, 운영팀의 심층 분석 도구 운영팀의 일상적인 모니터링 도구 비용 구조 상대적으로 높은 초기 비용과 운영 비용 상대적으로 낮은 초기 비용과 예측 가능한 운영 비용 구현 복잡도 높음 (다양한 데이터 소스와 분석 도구 통합 필요) 중간 (표준화된 메트릭 수집과 알림 구성) 확장성 매우 유연한 확장성 (새로운 데이터 소스와 분석 방법 추가 가능) 제한된 확장성 (미리 정의된 메트릭과 알림 중심) 필요한 기술 수준 높은 수준의 기술적 이해와 분석 능력 필요 중간 수준의 운영 지식으로 충분 문제 감지 범위 알려지지 않은 문제까지 포함한 광범위한 감지 알려진 문제와 패턴 중심의 감지 응답 시간 상대적으로 길음 (심층 분석 필요) 즉각적 (사전 정의된 알림 기반) 주요 사용 사례 복잡한 분산 시스템의 문제 해결, 성능 최적화 시스템 상태 모니터링, SLA 준수 확인 이러한 차이점들은 각각이 서로 다른 목적과 상황에서 중요한 역할을 한다는 것을 보여준다. Monitoring이 시스템의 기본적인 건강 상태를 확인하는 데 중점을 둔다면, Observability는 더 심층적인 시스템 이해와 문제 해결을 가능하게 한다. ...

Metric Metric는 시스템의 상태와 성능을 수치화하여 측정하는 중요한 관측 도구이다. Metric는 시스템의 상태, 동작, 성능 등을 나타내는 수치화된 측정값이다. 예를 들어, 웹 서버의 응답 시간, CPU 사용률, 메모리 사용량 등이 Metric가 될 수 있다. 장점 효율적인 저장: 숫자 데이터는 저장 공간을 적게 차지한다. 빠른 쿼리: 시계열 데이터베이스를 사용하여 빠른 검색과 분석이 가능하다. 장기 추세 분석: 오랜 기간 동안의 데이터를 저장하고 분석할 수 있다. 시각화 용이성: 그래프나 대시보드로 쉽게 표현할 수 있다. 단점 초기 설정에 시간과 노력이 필요하다 너무 많은 Metric는 오히려 혼란을 줄 수 있다 저장 공간과 처리 리소스가 필요하다 Metric의 중요성 성능 모니터링: 시스템의 전반적인 성능을 지속적으로 모니터링할 수 있다. 문제 감지: 비정상적인 패턴이나 임계값 초과를 빠르게 감지할 수 있다. 용량 계획: 리소스 사용량 추세를 분석하여 미래의 용량을 계획할 수 있다. 최적화: 성능 병목 현상을 식별하고 최적화할 수 있는 기회를 제공한다. Metric의 구성 요소 일반적인 Metric는 다음 요소로 구성된다: ...