본 가이드는 ci bitbucket pipelines.yml 핵심 가이드 및 실전 아키텍처의 핵심 개념, 실전 구성 명령어 및 아키텍처 베스트 프랙티스를 다룹니다. 클라우드 네이티브 및 인프라 엔지니어링 실무에 즉시 활용 가능하도록 체계적으로 정리했습니다.
📑 Table of Contents
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
#private
image:
name: registry/image:tag
username: username
password: password
#public
image: registry/image:tag
options
실험적 기능으로 거의 사용되지 않음
#(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
#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
#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.
# 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.
# public registry
definitions:
services:
custom-dind:
image: { insecure-dind input }
type: docker
variables:
DOCKER_OPTS: "--insecure-registry={ registry input }"
Yaml anchors
반복되는 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
- 특정 브랜치는 매뉴얼 트리거 사용
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
#파이프라인 속성은 저장소의 빌드 프로세스를 정의하는 데 사용됩니다. 파이프라인 시작 조건과 파이프라인 단계가 포함됩니다. 파이프라인 속성은 필수이며 저장소당 한 번만 정의해야 합니다.
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
pipelines:
default:
#스테이지를 사용하면 공유 속성을 사용하여 파이프라인 단계를 그룹화할 수 있습니다. 예를 들어, 스테이지를 사용하여 배포에 필요한 단계(예: 앱 배포 및 배포 성공 확인)를 그룹화할 수 있습니다.
- stage:
name: name
steps: [step]
step
이 step옵션은 빌드 실행 단위를 정의하는 데 사용됩니다. 각 단계는 파일에 나타나는 순서대로 실행됩니다 bitbucket-pipelines.yml . 단일 파이프라인은 최대 100개의 단계를 포함할 수 있습니다.
파이프라인의 각 단계는 옵션에 구성된 명령을 실행하기 위해 별도의 Docker 컨테이너를 시작합니다. 각 단계는 다음과 같은 옵션을 사용하여 사용자 지정할 수 있습니다.
runtime– 단계의 런타임 환경을 사용자 지정합니다.cloudatlassian-ip-rangesimage— 다른 Docker 이미지를 사용합니다.max-time— 단계에 허용되는 최대 시간을 설정합니다.caches그리고services— 특정 캐시와 서비스에 대해서.artifacts— 후속 단계에서 사용할 수 있는 아티팩트를 유지합니다.clone— 해당 단계에 대한 Git 복제 작업을 사용자 지정합니다.-
triggermanual— 파이프라인을 계속 진행하기 전에 수동이 필요하도록 단계를 설정합니다 . -
features
-
self-hosted pipeline using custom Defined service
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
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
– Pre-defined caches
파이프라인은 일반적으로 사용되는 언어 도구에 대한 미리 정의된 캐시 위치를 제공합니다.
| Cache name | In your step | Directories |
| [docker](https://support.atlassian.com/bitbucket-cloud/docs/run-docker-commands-in-bitbucket-pipelines/) |
caches:
|
n/a – 빌드에서 생성된 레이어에서 [캐시를 생성합니다.](https://support.atlassian.com/bitbucket-cloud/docs/run-docker-commands-in-bitbucket-pipelines/#RunDockercommandsinBitbucketPipelines-ci_caching) |
| composer |
caches:
|
~/.composer/cache
|
| dotnetcore |
caches:
|
~/.nuget/packages
|
| gradle |
caches:
|
~/.gradle/caches
|
| ivy2 |
caches:
|
~/.ivy2/cache
|
| maven |
caches:
|
~/.m2/repository
|
| node |
caches:
|
node_modules
|
| pip |
caches:
|
~/.cache/pip
|
|
sbt Note: sbt도구를 사용하려면 sbt와 ivy2 캐시를 모두 활성화해야 합니다 .
|
caches:
|
~/.sbt~/.ivy2/cache
|
Services
도커 데몬을 사용하거나, DB를 활용한 테스트를 구성하기 위한 backing서비스
파이프라인 서비스에는 다음과 같은 제한이 있습니다.
- 한 단계에 최대 5개의 서비스
- 아래에 설명된 대로 메모리 제한
- 파이프라인 결과에 따라 서비스 및 로그에 액세스하기 위한 REST API가 없습니다.
- 서비스 시작을 기다리는 메커니즘이 없습니다.
- 더 많은 수의 소규모 서비스를 실행하려면 Docker run 또는 docker-compose를 사용하세요.
- 포트 29418을 사용할 수 없습니다.
Features
Enterprise Cloud-si
Leave a Reply