Postman Postman은 API(Application Programming Interface) 개발, 테스트, 문서화 및 협업을 위한 종합적인 플랫폼이다. 2012년 Abhinav Asthana가 개인 프로젝트로 시작한 이 도구는 현재 전 세계 2,000만 명 이상의 개발자와 50만 개 이상의 조직에서 사용하는 API 생태계의 핵심 요소로 성장했다. Postman은 원래 Chrome 브라우저의 확장 프로그램으로 시작되어 API 요청을 쉽게 테스트할 수 있는 간단한 도구였다. 그러나 시간이 지남에 따라 독립 실행형 애플리케이션으로 발전했으며, 현재는 API 개발 수명주기 전체를 지원하는 클라우드 기반 플랫폼으로 확장되었다. ...
Portainer란? 컨테이너 환경을 관리하기 위한 오픈소스 웹 기반 GUI 도구 개요 Docker, Kubernetes 등 다양한 컨테이너 플랫폼을 지원하는 범용 컨테이너 관리 솔루션 직관적인 웹 인터페이스를 통해 컨테이너 환경의 복잡성을 단순화 100만 명 이상의 사용자와 30,000개 이상의 GitHub 스타를 보유한 인기 있는 도구 주요 특징과 기능 컨테이너 관리: 컨테이너의 배포, 시작, 중지, 로그 확인 등을 GUI로 수행 스택 배포: Docker Compose를 사용한 멀티 컨테이너 애플리케이션 배포 지원 볼륨 및 네트워크 관리: 데이터 저장소와 네트워크 구성 관리 이미지 관리: Docker 레지스트리 연동 및 이미지 관리 리소스 모니터링: CPU, 메모리 사용량 등 컨테이너 성능 모니터링 템플릿: 미리 정의된 애플리케이션 템플릿을 통한 간편한 배포 장점 사용 편의성: 명령줄 지식 없이도 컨테이너 관리 가능 중앙 집중식 관리: 여러 Docker 환경을 단일 인터페이스에서 관리 보안 강화: 사용자 및 팀 단위의 접근 제어 기능 제공 확장성: 소규모 프로젝트부터 대규모 엔터프라이즈 환경까지 지원 버전 Community Edition (CE): 무료 오픈소스 버전 Business Edition (BE): 기업용 고급 기능(보안, 감사 등) 제공 버전 Portainer 설치 Host간 볼륨 매칭을 위한 디렉토리 생성 1 mkdir -p /kubernetes/portainer_data Portainerdmf docker run 명령어를 통해 docker에 설치 위에서 생성한 폴더와 마운트 1 docker run -d -p 9000:9000 -v /var/run/docker.sock:/var/run/docker.sock -v /kubernetes/portainer_data:/data portainer/portainer-ce:latest Portainer 로그인 웹브라우저 Portainer 서버(예: http://서버IP:9000)에 접근 [처음 접속시] username과 password 입력 Source: hyunyoun ...
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 # 아티팩트 유효 기간 이러한 설정들은 프로젝트의 요구사항과 규모에 따라 적절히 조정하여 사용할 수 있습니다. ...
Version Control Systems 버전 관리 시스템(Version Control System, VCS)은 소스 코드, 문서, 설정 파일 등 디지털 자산의 변경 이력을 시간순으로 기록하고, 특정 시점의 버전으로 복원하거나 변경 내역을 추적할 수 있게 해주는 시스템이다. 또한, 각 변경의 작성자, 시점, 변경 이유 등 메타데이터를 함께 저장하는 등의 기능을 통하여 여러 개발자가 동시에 협업할 수 있도록 지원하는 핵심 도구이다. 버전 관리 시스템은 크게 중앙집중식(CVCS), 분산식(DVCS), 로컬 방식으로 분류된다. 대표적인 도구로는 Git, Subversion(SVN), Mercurial 등이 있으며, 특히 Git은 현대 소프트웨어 개발에서 가장 널리 사용되는 버전 관리 시스템이다. ...