Bitbucket Pipelines CI/CD: DinD 빌드 및 레지스트리 배포

💡 핵심 요약 (Executive Summary)

본 가이드는 ci bitbucket pipelines.yml 핵심 가이드 및 실전 아키텍처의 핵심 개념, 실전 구성 명령어 및 아키텍처 베스트 프랙티스를 다룹니다. 클라우드 네이티브 및 인프라 엔지니어링 실무에 즉시 활용 가능하도록 체계적으로 정리했습니다.

📑 Table of Contents
yaml
image:
  #Docker image options page
options:
  #Global options page
clone:
  #Git clone behavior page
definitions:
  #Cache and service container definitions page
pipeline:
  #Pipeline start options page
    parallel:
      #Parallel step options page
    stage:
      #Stage options page
    step:
      #Step options page
image
yaml
#private
image:
  name: registry/image:tag
  username: username
  password: password

#public
image: registry/image:tag
options
Reference & Guidelines (NOTE)

실험적 기능으로 거의 사용되지 않음

yaml
#(premium-only) 동일한 작업 공간 내의 다른 저장소와 파이프라인 정의를 공유할지 여부를 지정합니다.
export: true

options:
	#max-time 옵션은 단계가 시간 초과되기 전까지 실행할 수 있는 최대 시간(분)을 설정합니다. max-time 옵션은 전역 옵션 속성과 개별 파이프라인 단계를 모두 사용하여 설정할 수 있습니다. 파이프라인 단계의 기본 최대 시간은 120분입니다.
  max-time: 30
	#글로벌 docker 옵션은 파이프라인의 모든 단계에 Docker 서비스를 추가합니다. 이 Docker 서비스를 사용하면 모든 파이프라인 단계에서 Docker 명령을 실행할 수 있습니다. Bitbucket 파이프라인에서 Docker를 사용하는 방법에 대한 자세한 내용은 Bitbucket 파이프라인에서 Docker 명령 실행을 참조하세요.  
  docker: true
  #크기 옵션은 Bitbucket Cloud 인프라나 Linux Docker 자체 호스팅 러너에서 실행할 때 단계나 전체 파이프라인에 추가 리소스를 할당합니다.
  size: 2x
  #단계에 적용할 런타임 구성입니다.
  runtime:
	  #클라우드 단계에 적용할 런타임 구성입니다.
    cloud:
	    #이 옵션은 수신/송신 트래픽에 대한 단계를 실행할 때 기본 aws-ip-ranges를 사용할지 아니면 atlassian-ip-ranges를 사용할지 여부를 나타냅니다.
      atlassian-ip-ranges: true
      #이 옵션은 단계를 실행할 때 사용할 아키텍처를 제어합니다.
      arch: arm
clone
yaml
#clone 속성은 빌드 중에 Bitbucket Pipelines가 저장소를 복제하는 방법을 제어하는 옵션을 제공합니다.
clone:
	#Git 복제본을 비활성화할 수 있습니다. (pipelines.step.clone.enabled 에서 특정 step 활성화 가능)
	enabled: false
	#lfs 옵션은 git clone 작업 중에 저장소의 모든 LFS 파일을 다운로드하도록 git에 지시합니다. lfs를 전역 옵션으로 true로 설정하면 모든 LFS 파일이 각 단계 시작 시 다운로드됩니다. lfs를 개별 단계에서 true로 설정하면 해당 단계의 모든 LFS 파일이 다운로드됩니다. 빌드 시간과 리소스 사용량을 줄이려면 개별 단계에서 LFS를 사용하거나 각 단계에 필요한 파일만 다운로드하는 것이 좋습니다.
	lfs: true
	#모든 파이프라인 또는 파이프라인 단계에 대한 Git 복제본의 깊이를 정의합니다. 전체 복제본을 만들려면 full을 사용하세요. 지정하지 않으면 기본값은 최근 50개 커밋입니다. Git 복제 깊이 옵션에 대한 자세한 내용은 Git 문서 — git clone을 참조하세요.
	depth: 2
	#skip-ssl-verify 옵션은 git clone 중에 SSL 검증을 비활성화하여 자체 서명된 인증서를 사용할 수 있도록 합니다.
	skip-ssl-verify: true
definitions
yaml
#definitions 속성은 파이프라인 구성의 다른 곳에서 사용되는 리소스를 정의하는 데 사용됩니다.
definitions:
	#Bitbucket Pipelines는 빌드 종속성과 디렉토리 캐싱을 지원하여 빌드 속도를 높이고 소요되는 빌드 시간을 줄입니다. 미리 정의된 캐시가 여러 개 있습니다. 미리 정의된 캐시의 전체 목록은 캐시 — 미리 정의된 캐시를 참조하세요 .
	caches:
	#Bitbucket 파이프라인은 서비스별로 별도의 Docker 컨테이너를 생성할 수 있어 빌드 속도가 빨라지고 서비스 편집이 간편해집니다. 서비스 생성에 대한 자세한 내용은 데이터베이스 및 서비스 컨테이너를 참조하세요 . 이 services옵션은 서비스를 정의하여 파이프라인 단계에서 사용할 수 있도록 하는 데 사용됩니다.
	services:
		#service daemon image
		image: registry/image:tag
		#이 memory옵션은 서비스 컨테이너에서 사용할 수 있는 메모리(메가바이트)를 제한하는 데 사용됩니다. 4096MB( 빌드 8192의 경우 MB size: 2x)는 스크립트 및 파이프라인 서비스를 포함하여 에 할당할 수 있는 총 메모리 양입니다 step. 예를 들어, 서비스에 3072MB가 필요한 경우 1024해당 서비스를 사용하여 단계를 실행하는 데 사용할 수 있는 메모리는 MB뿐입니다. 서비스 컨테이너 메모리 제한에 대한 자세한 내용은 데이터베이스 및 서비스 컨테이너 - 서비스 메모리 제한을 참조하십시오 .
		memory: 512
		#이 type옵션은 다음을 위한 Docker 서비스 컨테이너(Docker-in-Docker 실행)를 지정하는 데 사용됩니다. (--privileged 불가로 docker-daemon 사용을 위해 필요함.)
		type: docker
		#서비스 variables옵션은 서비스 컨테이너에 환경 변수를 전달하는 데 사용되며, 일반적으로 서비스를 구성하는 데 사용됩니다. 서비스 생성에 대한 자세한 내용은 데이터베이스 및 서비스 컨테이너를 참조하세요 .
		variables: [env]
	#반복되는 yaml 구성 셋을 사전정의하고 재사용
	{yamlAnchor}: [anchor]
  • features

  • Definitions for using a Docker-in-Docker (DIND) image from a private registry.

yaml
# private registry
    definitions:
      services:
        custom-dind:
          image:
            name: { insecure-dind input }
            username: "$private_docker_hub"
            password: "$private_docker_hub_pw"
          type: docker
          variables:
            DOCKER_OPTS: "--insecure-registry={ registry input }"
  • Definitions for using a Docker-in-Docker (DIND) image from a public registry.
yaml
# public registry
    definitions:
      services:
        custom-dind:
          image: { insecure-dind input }
          type: docker
          variables:
            DOCKER_OPTS: "--insecure-registry={ registry input }"
Yaml anchors
Reference & Guidelines (NOTE)

반복되는 yaml 구성 셋을 사전정의하고 재사용

yaml
#정의: {$}
definitions: 
  steps:
    - step: &build-test
        name: Build and test
        script:
          - mvn package
        artifacts:
          - target/**
#참조: {*}
pipelines:
  branches:
    develop:
      - step: *build-test
    main:
      - step: *build-test

#참조시 Overwrite: {<<: *}
ipelines:
  branches:
    develop:
      - step: *build-test
    main:
      - step: 
          <<: *build-test
          name: Testing on Main
  • feature
  • 특정 브랜치는 매뉴얼 트리거 사용
yaml
definitions: 
      steps:
        - step: &build-test
            name: Build and test
            script:
              - mvn package
            artifacts:
              - target/**
        - step: &deploy
            name: Deploy
            deployment: test
            script:
              - ./deploy.sh target/my-app.jar

    pipelines:
      branches:
        develop:
          - step: *build-test
          - step: *deploy
        main:
          - step: *build-test
          - step:
              <<: *deploy
              deployment: production
              trigger: manual
pipeline
yaml
#파이프라인 속성은 저장소의 빌드 프로세스를 정의하는 데 사용됩니다. 파이프라인 시작 조건과 파이프라인 단계가 포함됩니다. 파이프라인 속성은 필수이며 저장소당 한 번만 정의해야 합니다.
pipelines:
	#다른 섹션의 파이프라인 정의와 일치하지 않는 모든 브랜치에 대한 파이프라인 정의를 포함합니다.
	default: [step]
	#모든 브랜치별 빌드 파이프라인을 정의합니다. 이 섹션의 이름 또는 표현식은 Git 저장소의 브랜치와 일치합니다. Glob 패턴을 사용하여 브랜치를 일치시킬 수 있습니다. Glob 패턴을 사용하여 브랜치 이름을 일치시키는 방법에 대한 자세한 내용은 파이프라인 YAML 파일에서 Glob 패턴 사용을 참조하세요.
	branches: 
		main: [step]
		"feature/*": [step]
	#풀 리퀘스트 속성은 풀 리퀘스트가 생성될 때만 실행되는 파이프라인을 정의합니다. 실행 전에 대상 브랜치를 작업 브랜치에 병합합니다. 포크된 저장소의 풀 리퀘스트는 파이프라인을 트리거하지 않습니다. 병합이 실패하면 파이프라인이 중지됩니다. 참고: 할당된 브랜치는 풀 리퀘스트의 소스 브랜치여야 합니다. 풀 리퀘스트 파이프라인은 정의된 모든 브랜치 및 기본 파이프라인과 함께 실행되므로 정의가 겹치면 두 개의 파이프라인이 동시에 실행될 수 있습니다.
  pull-requests:
		main: [step]
		"feature/*": [step]
		#pr default
		'**': [step]
	#모든 태그별 빌드 파이프라인을 정의합니다. 이 섹션의 이름이나 표현식은 Git 저장소의 태그 및 주석이 달린 태그와 일치합니다. Glob 패턴을 사용하여 태그를 일치시킬 수 있습니다.
	tags:
		"*-windows": [step]
		"*-linux": [step]
	#사용자 지정 속성은 Bitbucket Cloud 인터페이스에서 수동으로만 트리거하거나 예약할 수 있는 파이프라인을 정의하는 데 사용됩니다. 수동 또는 예약된 파이프라인 생성에 대한 자세한 내용은 수동 및 예약된 파이프라인 생성을 참조하세요.
	custom:
		"defined-trigger-name1": [step]
		"defined-trigger-name2": [step]


custom-trigger

stage
yaml
pipelines:
   default:
   #스테이지를 사용하면 공유 속성을 사용하여 파이프라인 단계를 그룹화할 수 있습니다. 예를 들어, 스테이지를 사용하여 배포에 필요한 단계(예: 앱 배포 및 배포 성공 확인)를 그룹화할 수 있습니다.
    - stage:
        name: name
        steps: [step]
step
Reference & Guidelines (NOTE)

이 step옵션은 빌드 실행 단위를 정의하는 데 사용됩니다. 각 단계는 파일에 나타나는 순서대로 실행됩니다  bitbucket-pipelines.yml . 단일 파이프라인은 최대 100개의 단계를 포함할 수 있습니다.


파이프라인의 각 단계는 옵션에 구성된 명령을 실행하기 위해 별도의 Docker 컨테이너를 시작합니다. 각 단계는 다음과 같은 옵션을 사용하여 사용자 지정할 수 있습니다.

  • runtime– 단계의 런타임 환경을 사용자 지정합니다.
  • cloud
  • atlassian-ip-ranges
  • image— 다른 Docker 이미지를 사용합니다.
  • max-time— 단계에 허용되는 최대 시간을 설정합니다.
  • caches그리고 services— 특정 캐시와 서비스에 대해서.
  • artifacts— 후속 단계에서 사용할 수 있는 아티팩트를 유지합니다.
  • clone— 해당 단계에 대한 Git 복제 작업을 사용자 지정합니다.
  • triggermanual— 파이프라인을 계속 진행하기 전에 수동이 필요하도록 단계를 설정합니다 .

  • features

  • self-hosted pipeline using custom Defined service

yaml
pipelines:
      branches:
        "feature/pipeline-test":
          - step:
              name: "on-premise-agent :: Images push & Kubernetes Deploy"
              runs-on:
                - self.hosted
              services:
                - custom-dind
              image: { client input }
              script:
                - docker info
parallel
yaml
pipelines:
  default:
    - step: # sequential step
        name: Build
        script:
          - ./build.sh
    - step: # sequential step
        name: Build
        script:
          - ./build.sh
		#parallel 옵션을 사용하면 여러 단계를 동시에 실행하여 코드를 더 빠르게 빌드하고 테스트할 수 있습니다. 파이프라인에서 사용하는 총 빌드 시간은 단계를 병렬로 설정해도 변하지 않지만, 결과를 더 빨리 확인할 수 있습니다. 파이프라인 정의에 포함할 수 있는 총 단계 수는 병렬 또는 직렬 실행 여부와 관계없이 100개로 제한됩니다.
    - parallel: # these 2 steps will run in parallel
        steps:
          - step:
              name: Integration 1
              script:
                - ./integration-tests.sh --batch 1
          - step:
              name: Integration 2
              script:
                - ./integration-tests.sh --batch 2
built-in
Caches
Reference & Guidelines (NOTE)

– Pre-defined caches

파이프라인은 일반적으로 사용되는 언어 도구에 대한 미리 정의된 캐시 위치를 제공합니다.

Cache name In your step Directories
[docker](https://support.atlassian.com/bitbucket-cloud/docs/run-docker-commands-in-bitbucket-pipelines/) caches:
- docker
n/a – 빌드에서 생성된 레이어에서 [캐시를 생성합니다.](https://support.atlassian.com/bitbucket-cloud/docs/run-docker-commands-in-bitbucket-pipelines/#RunDockercommandsinBitbucketPipelines-ci_caching)
composer caches:
- composer
~/.composer/cache
dotnetcore caches:
- dotnetcore
~/.nuget/packages
gradle caches:
- gradle
~/.gradle/caches
ivy2 caches:
- ivy2
~/.ivy2/cache
maven caches:
- maven
~/.m2/repository
node caches:
- node
node_modules
pip caches:
- pip
~/.cache/pip
sbt
Note: sbt도구를 사용하려면 sbt와 ivy2 캐시를 모두 활성화해야 합니다 .
caches:
- sbt
- ivy2
~/.sbt
~/.ivy2/cache
Services
Reference & Guidelines (NOTE)

도커 데몬을 사용하거나, DB를 활용한 테스트를 구성하기 위한 backing서비스


파이프라인 서비스에는 다음과 같은 제한이 있습니다.

  • 한 단계에 최대 5개의 서비스
  • 아래에 설명된 대로 메모리 제한
  • 파이프라인 결과에 따라 서비스 및 로그에 액세스하기 위한 REST API가 없습니다.
  • 서비스 시작을 기다리는 메커니즘이 없습니다.
  • 더 많은 수의 소규모 서비스를 실행하려면 Docker run 또는 docker-compose를 사용하세요.
  • 포트 29418을 사용할 수 없습니다.

Features

Enterprise Cloud-si

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *