피드 구독

지속적 통합 및 지속적 배포(Continuous Inegration and Continuous Deployment, CI/CD) 파이프라인은 현대적인 소프트웨어 개발의 중요한 부분으로 자리 잡았으며, 개발자는 이를 통해 코드 변경 사항을 빠르고 효율적으로 빌드, 테스트하고 배포할 수 있습니다. CI/CD 파이프라인은 애플리케이션 빌드 및 배포 프로세스를 자동화함으로써 팀이 코드 품질을 개선하고, 오류를 줄이며, 새로운 기능 및 애플리케이션의 시장 출시 시간을 단축하는 데 도움을 줄 수 있습니다.

GitLab 러너는 GitLab.com 및 자체 호스팅된 GitLab 인스턴스에서 CI/CD 작업을 처리하는 애플리케이션입니다. GitLab.com은 사이트 사용자 간에 공유되는 자체 호스팅된 러너를 제공하지만, 다양한 설치 유형을 통해 프로젝트에 대한 전용 개인 러너를 설정할 수도 있습니다. 클라우드에서 자체 파이프라인 인프라를 관리하고자 하는 기업 또는 개인을 위해 OpenShift에서 Red Hat 인증 오퍼레이터로 사용할 수 있는 GitLab 러너 오퍼레이터는 GitLab 러너의 빠르고 쉬운 클라우드 네이티브 설치를 제공합니다.

GitLab 러너 오퍼레이터의 단순성과 기능을 흥미롭게 소개해 드리기 위해, Fedora Linux의 몇 가지 주목할 만한 개발 사항을 집중적으로 살펴보고 GitLab 러너 오퍼레이터를 사용하여 Fedora Silverblue를 위한 사용자 정의 기본 이미지를 빌드해 보려고 합니다.

Fedora Silverblue는 Fedora Linux의 변경 불가능한 최첨단 배포판입니다. 최근에는 해당 하이브리드 이미지 및 패키지 관리 시스템 rpm-ostree 가 OCI 컨테이너에서 부팅할 수 있게 되었습니다. 이를 통해 사용자 또는 기업은 익숙한 Dockerfile 및 Containerfile 워크플로우를 사용하여 사용자 정의 기본 이미지를 빌드할 수 있습니다.

다음 튜토리얼에서는 GitLab 러너 오퍼레이터를 사용하여 Fedora Silverblue 이미지에 대해 완전히 자동화된 빌드 시스템을 설정합니다.

전제 조건

몇 가지 리소스를 사전에 구성하고 설치해야 합니다. 이 리소스에 대해서는 튜토리얼에서 다루지 않습니다.

  • OpenShift 클러스터
  • 기존 Fedora Silverblue 설치(사용자 정의 이미지를 실제로 사용하려는 경우)
  • GitLab.com 계정

GitLab 러너 오퍼레이터 설치 및 구성

OpenShift 클러스터의 사이드바에서 Operators(오퍼레이터) 제목을 열고 OperatorHub를 클릭합니다. GitLab 러너 오퍼레이터를 검색하고 Certified(인증) 옵션을 클릭합니다(커뮤니티 버전의 오퍼레이터도 사용할 수 있지만 이 튜토리얼에서는 OpenShift 인증 오퍼레이터만 사용).  Install(설치)을 클릭하기 전에 오퍼레이터 설명의 전제 조건 섹션을 확인합니다. GitLab 러너 오퍼레이터를 사용하려면 먼저 cert-manager를 설치해야 합니다.

oc apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.yaml

그런 다음 Install(설치) 을 클릭하여 GitLab 러너 오퍼레이터를 설치합니다.

다음 화면에서 기본 설치 옵션을 변경하라는 메시지가 표시됩니다. 특정 네임스페이스로 범위를 지정하려는 경우 지금 지정하고, 그렇지 않으면 기본 옵션을 사용하여 계속합니다. 또한 Update approval(업데이트 승인) Automatic(자동) 으로 설정하는 것이 좋습니다. 이는 오퍼레이터 사용으로 얻는 주요 이점 중 하나이기 때문입니다.

설치가 완료될 때까지 잠시 기다린 다음 Installed Operators(설치된 오퍼레이터)와 GitLab Runner Operator(GitLab 러너 오퍼레이터)로 이동합니다. 여기에는 이전과 동일한 정보 텍스트 외에도 러너 인스턴스를 생성할 수 있는 링크(제공된 API 아래에서 확인)가 표시되어 있습니다. 아래의 정보 텍스트에는 러너를 GitLab 리포지토리에 연결하는 방법에 대한 지침이 나와 있으며, 지금 따라 해 보겠습니다.

러너 인스턴스 생성 및 등록

1. 등록 토큰 시크릿 생성

먼저 새 러너가 리포지토리에 등록하는 데 사용할 GitLab의 등록 토큰으로 시크릿을 생성해야 합니다. GitLab.com 또는 개인 GitLab 인스턴스를 연 다음 등록할 리포지토리를 엽니다. Settings(설정)로 이동한 다음 CI/CD로 이동합니다. Runners(러너) 섹션을 펼친 다음 Project runners(프로젝트 러너) 섹션을 찾습니다. 여기에서 러너 인스턴스를 등록하는 데 사용할 등록 토큰과 URL을 찾을 수 있습니다.

GitLab.com을 사용하는 경우 Shared runners(공유 러너) 섹션도 확인합니다. 이는 GitLab.com에서 제공하는 공용 러너입니다. 여기서는 자체 개인 러너를 사용하므로 이 프로젝트의 공유 러너를 비활성화합니다.

리포지토리의 등록 토큰을 runner-registration-token 필드에 삽입하여 시크릿을 생성합니다. 이 작업은 웹 콘솔에서 또는 터미널 인터페이스를 통해 수행할 수 있습니다.  gitlab-runner-secret.yml 이라는 파일을 생성한 다음 내 클러스터에 추가했습니다.

apiVersion: v1
kind: Secret
metadata:
name: gitlab-runner-secret
type: Opaque
stringData:
runner-registration-token: YOUR_TOKEN_HERE
oc apply -f gitlab-runner-secret.yml

2. ConfigMap을 사용하여 러너 구성

러너를 생성하기 전에 몇 가지 사용자 지정 옵션을 사용하여 ConfigMap도 생성해야 합니다. GitLab 러너는 일반적으로 config.toml 파일을 사용하여 구성할 수 있습니다. 쿠버네티스 컨텍스트에서는 config.toml 파일이 포함된 ConfigMap으로 사용자 정의 항목 을 추가할 수 있습니다.

OpenShift 클러스터의 환경에서 빌드 컨테이너를 실행하고 있으므로, 빌드 컨테이너가 에스컬레이션된 권한 없이 루트가 아닌 사용자 로 실행되어야 합니다(참고: 권한 부여된 빌드 환경이 필요한 경우 이를 여러 가지 방법으로 우회 할 수 있지만, 여기서는 루트가 아닌 설정을 사용). 다음은 러너 포드가 루트가 아닌 사용자 1000으로 실행되도록 지정하는 간단한 config.toml 입니다.

[[runners]]
name = "gitlab-runner"
url = "https://gitlab.com"
executor = "kubernetes"
[runners.kubernetes]
[runners.kubernetes.pod_security_context]
run_as_non_root = true
run_as_user = 1000

다음과 같이 이를 클러스터에 ConfigMap으로 추가합니다.

oc create configmap my-runner-config --from-file=config.toml

3. 러너 인스턴스 시작

이제 실제 러너 인스턴스를 생성할 수 있습니다. 아까 알려드린 대로 GitLab Runner Operator(GitLab 러너 오퍼레이터) 페이지에서 Create instance(인스턴스 생성)를 클릭하거나 터미널을 통해 웹 콘솔에서 이 작업을 수행할 수 있습니다. 어느 방식을 선택하든 사용자 정의 리소스 정의에 올바른 GitLab URL, 등록 토큰 시크릿의 이름, ConfigMap의 이름이 포함되어 있고 태그에 "openshift"가 포함되어 있는지 확인하려고 합니다(마지막 항목인 "openshift" 태그는 작업을 클러스터에 전달하는 데 필요). 다음은 모든 기준을 충족하는 gitlab-runner.yml 이라는 기본 CRD입니다

.

apiVersion: apps.gitlab.com/v1beta2
kind: Runner
metadata:
name: gitlab-runner
spec:
gitlabUrl: https://gitlab.com
token: gitlab-runner-secret
tags: openshift
config: my-runner-config

다음과 같이 클러스터에 설치합니다.

oc apply -f gitlab-runner.yml

이제 웹 콘솔에서 또는 oc get runners를 사용하여 터미널을 통해 새 러너의 상태를 확인할 수 있습니다. 또한 GitLab 프로젝트의 CI/CD 설정을 확인하여 러너가 리포지토리에 올바르게 연결되었는지 확인해야 합니다. 이제 생성하고 설치한 CRD와 동일한 이름의 Assigned project runners(할당된 프로젝트 러너) 제목 아래에 러너가 표시됩니다.

러너를 사용하여 Silverblue 이미지 빌드

1. GitLab CI/CD 파이프라인 작업 정의

이제 러너가 설치 및 구성되고 프로젝트에 연결되었으므로 이미지 빌드를 정의할 GitLab CI 파일을 작성할 수 있습니다. GitLab은 다양한 프로젝트 유형에 대해 gitlab-ci.yml 파일 구조의 많은 예시를 제공합니다. 여기서는 buildah로 자체 파일을 작성하여 Silverblue 이미지를 빌드해 보겠습니다.

사용할 gitlab-ci.yml 은 다음과 같습니다.

stages:
- build

buildah-build:
stage: build
tags:
- openshift
image: quay.io/buildah/stable
variables:
STORAGE_DRIVER: vfs
script:
- export HOME=/tmp
- buildah login --username "$CI_REGISTRY_USER" --password "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
- buildah build -t "$CI_REGISTRY_IMAGE:latest" .
- buildah push "$CI_REGISTRY_IMAGE:latest"
- buildah logout "$CI_REGISTRY"

이 파일에는 주목해야 할 몇 가지 중요한 요소가 있습니다.

  • GitLab 러너 오퍼레이터에서 작업을 선택하려면 앞에서 언급한 대로 최소한 openshift 태그를 포함해야 합니다.
  • 여기서는 Quay.io에서 호스팅되는 안정적인 공식 Buildah 이미지를 빌드 이미지로 사용합니다.
  • 오버레이-온-오버레이(Overlay-on-overlay) 파일 시스템의 문제로 인해 스토리지 드라이버를 vfs로 설정했습니다. 현재로서는 vfs를 사용하는 것이 가장 간단한 솔루션입니다.
  • OpenShift에서 대부분의 컨테이너 파일 시스템은 읽기 전용이므로 쓰기 가능하도록 $HOME /tmp로 변경합니다.

마지막 섹션인 script는 빌드 작업에서 실행할 명령 목록입니다. 여기에서는 GitLab CI의 사전 정의된 변수를 사용하여 GitLab 컨테이너 레지스트리에 로그인하고, 이미지를 빌드한 다음 태그를 지정하고, 이미지를 레지스트리로 내보낸 다음 로그아웃합니다.

2. 사용자 정의 Silverblue 이미지에 대한 Containerfile 작성

 gitlab-ci.yml을 리포지토리에 추가한 후에 빌드하려는 Containerfile도 추가해야 합니다. Red Hat의 사용자 정의 Fedora Silverblue 이미지는 Universal Blue 커뮤니티가 이룬 훌륭한 업적을 토대로 합니다. 커뮤니티는 다양한 활용 사례를 위해 다양한 버전의 Silverblue를 작업해 왔으며, Fedora Silverblue 시스템을 위한 변경 불가능한 사용자 정의 기본 이미지를 생성하는 데 관심이 있는 경우 큰 도움이 될 것입니다.

매일 사용하는 모든 OpenShift 및 Operator 툴링의 최신 릴리스를 포함하는 기본 이미지를 생성하는 것이 유용할 것입니다. 이 작업을 매일 빌드하도록 설정할 것이기 때문에 기본 이미지가 최신 Fedora 패키지로 업데이트될 뿐만 아니라 일반적으로 수동 업데이트가 필요한 이러한 OpenShift 및 오퍼레이터 툴의 최신 버전에도 뒤쳐지지 않습니다.

ARG FEDORA_MAJOR_VERSION=38

FROM quay.io/fedora-ostree-desktops/silverblue:${FEDORA_MAJOR_VERSION}
# Starting with Fedora 39, the new official location for these images is quay.io/fedora/fedora-silverblue
# See https://pagure.io/releng/issue/11047 for more information

# Install Openshift tools -- oc, opm, kubectl, operator-sdk, odo, helm, crc from official OpenShift sources
RUN curl -SL https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/latest/opm-linux.tar.gz | tar xvzf - -C /usr/bin
RUN curl -SL https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/operator-sdk/latest/operator-sdk-linux-x86_64.tar.gz | tar xvzf - --strip-components 2 -C /usr/bin
RUN curl -SL https://mirror.openshift.com/pub/openshift-v4/clients/oc/latest/linux/oc.tar.gz | tar xvzf - -C /usr/bin
RUN curl -SL https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/helm/latest/helm-linux-amd64 -o /usr/bin/helm && chmod +x /usr/bin/helm
RUN curl -SL https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/odo/latest/odo-linux-amd64 -o /usr/bin/odo && chmod +x /usr/bin/odo
RUN curl -SL https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/crc/latest/crc-linux-amd64.tar.xz | tar xfJ - --strip-components 1 -C /usr/bin

# Install awscli
RUN curl -SL https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip -o awscliv2.zip && unzip awscliv2.zip && ./aws/install --bin-dir /usr/bin --install-dir /usr/bin

# Install overrides and additions, remove lingering files
RUN rpm-ostree install podman-docker
RUN rm -rf aws && \
rm -f awscliv2.zip && \
rm -f /usr/bin/README.md && \
rm -f /usr/bin/LICENSE

이 Containerfile에서 수행되는 작업을 간단하게 나눠서 살펴보면 다음과 같습니다.

  • 먼저 빌드하려는 Fedora의 버전을 지정합니다(이 경우 안정적인 최신 버전인 38).
  • 그런 다음 빌드에 사용할 기본 이미지를 지정합니다. 이 이미지는 FEDORA_MAJOR_VERSION 대체 다음의 silverblue:38 입니다(해당 이미지의 위치는 Containerfile의 주석 참조).
  • 가장 큰 섹션에서는 여러 개의 curl 명령을 실행하여 설치하려는 모든 OpenShift 프로그램을 다운로드하고 해당 바이너리를 /usr/bin 디렉터리에 넣습니다.
  •  .zip 파일의 압축을 풀고 설치 스크립트를 실행하여 awscli 도 설치합니다.
  • 마지막으로, Fedora 패키지 리포지토리에서 rpm-ostree 를 사용하여 podman-docker 를 설치합니다(이는 기본적으로 도커 실행에 익숙한 사용자를 위해 모든 도커 명령에 Podman이라는 별칭을 지정함). 그런 다음 awscli 추출에서 나머지 파일을 삭제합니다.

앞서 언급했듯이, 더 많은 Silverblue 사용자 정의 아이디어를 확인하려면 관련 커뮤니티인 Universal Blue를 참조하세요. 저는 이 워크플로우를 학습할 때 이 커뮤니티의 작업에 큰 도움을 받았습니다. 그들은 이미 Silverblue에서 부팅 가능한 OCI 기능의 새롭고 흥미로운 용도에 대해 연구하고 있습니다.

3. 파이프라인 작업 사용 및 모니터링

 gitlab-ci.yml  buildah 에서 현재 작업 중인 디렉터리를 Containerfile 인수로 사용하도록 지정하므로 이 Containerfile 또는 대신 빌드하려는 Containerfile 또는 Dockerfile을 프로젝트 리포지토리의 루트에 추가해야 합니다. 이 리포지토리의 모든 변경 사항을 커밋한 방법에 따라, 실패한 파이프라인 작업에 대한 알림을 이미 받았을 수 있습니다. 또는 이 모든 것을 한 번에 커밋하는 경우 빌드 작업을 실행하는 첫 번째 시도가 지금 시작됩니다. GitLab.com 프로젝트 페이지에서 CI/CD 제목으로 이동한 다음 Pipelines(파이프라인) 또는 Jobs(작업) 를 클릭하고 buildah-build작업의 로그 출력이 표시될 때까지 클릭하여 빌드에 대한 로그를 볼 수 있습니다.

모든 항목을 올바르게 설정하면 작성한 gitlab-ci.yml 및 Containerfile의 각 단계를 설명하는 로그가 표시되며, 완료되면 "Job successful(작업 성공)"이 표시되고 종료됩니다. 작업이 성공하면 프로젝트 레지스트리에서 완료된 컨테이너도 확인할 수 있습니다. 왼쪽 탐색 바에서 Packages and registries(패키지 및 레지스트리) 를 클릭한 다음 Container Registry(컨테이너 레지스트리)를 클릭합니다. 프로젝트의 이름을 딴 단일 이미지가 "latest(최신)"이라는 단일 태그와 함께 표시되어야 합니다. 이 이미지는 registry.gitlab.com/{YOUR_USERNAME}/{YOUR_REPOSITORY_NAME}에 있습니다.

작업은 main 분기에 대한 모든 커밋과 함께 실행되도록 작성되었지만 gitlab-ci.yml 파일에서 이 동작을 사용자 정의할 수 있습니다. 정규 빌드를 예약하려는 경우 리포지토리 페이지 CI/CD 설정의 Schedule(일정) 섹션 아래에서 할 수 있습니다.  New schedule(새 일정) 을 클릭하여 파이프라인의 타이밍과 빈도를 구성합니다. GitLab.com 파이프라인 스케줄링에 대한 자세한 내용은 여기에서 확인할 수 있습니다. 사용자 정의 Silverblue 이미지의 경우 공식 이미지의 빌드 주기에 일치하도록 최소한 매일 빌드하는 것이 좋습니다.

사용자 정의 이미지 사용

이 이미지를 실제로 Silverblue의 부팅 가능한 기반으로 사용하려면 기존 설치가 없는 경우 먼저 공식 이미지 에서 Fedora Silverblue를 설치해야 합니다. 설치가 완료되고 로그인하면 사용자 정의 이미지로 설치 기반을 변경할 수 있습니다.

 OCI 이미지에서 부팅하는 것은 아직 실험적인 기능이므로 개인 또는 프로덕션 시스템에서 사용하는 경우 최선의 판단과 재량에 따라 그렇게 해야 합니다. 그러나 Silverblue는 손상에 대한 복원력을 갖추도록 빌드되었으므로 사용자 정의 이미지가 예상대로 작동하지 않는 경우 원래 기본 이미지로 롤백할 수 있습니다. 원본 기반이 제거되지 않도록 sudo ostree admin pin 0 을 실행하여 현재 이미지를 고정할 수 있습니다. 이렇게 하면 후속 업데이트에서 참조가 손실되지 않습니다. 일반적으로 Silverblue는 현재 및 이전 이미지 참조만 유지하기 때문입니다. 다음에 따라 사용자 정의 이미지로 기반을 변경합니다.

rpm-ostree rebase ostree-unverified-registry:registry.gitlab.com/{YOUR_USERNAME}/{YOUR_REPOSITORY_NAME}:latest

그런 다음 재부팅합니다.

재부팅 후 rpm-ostree status의 출력을 보고 사용자 정의 이미지가 실행되고 있는지 확인할 수 있습니다. 왼쪽에 있는 원/파이프가 표시된 현재 배포에는 사용자 정의 이미지의 ostree-unverified-registry URI가 표시되어야 합니다. 터미널에 추가한 OpenShift 툴(예: oc, operator-sdk또는 helm)을 실행할 수도 있습니다.

또한 rpm-ostree status의 출력에 이전 기본 참조가 있는 고정된 배포가 표시되어야 합니다. 롤백하려면 rpm-ostree rollback 을 실행하고 재부팅하면 됩니다. Fedora Silverblue 관리에 대한 자세한 내용은 설명서를 참조하세요.

결과

모든 것이 문제없이 진행되었다고 가정하면, 이제 자체 호스팅된 CI/CD 파이프라인을 자체 OpenShift 클러스터에서 실행하여 새로운 사용자 정의 Silverblue 이미지를 정기적으로 생성합니다. 빌드 작업 태그를 재구성하거나 더 많은 동시 작업을 처리하기 위해 더 많은 러너를 생성하려는 경우가 아니면 러너에 수동 개입이 필요하지 않습니다. 빌드는 예정된 간격에 따라 새 코드를 main 분기에 커밋할 때 시작되며, 사용자 정의 이미지를 Silverblue 설치에서 실행하는 경우 rpm-ostree update 를 실행하여 일일 업데이트에 가져오기만 하면 됩니다.

이 튜토리얼의 예시는 GitLab 러너 오퍼레이터와 GitLab CI/CD 시스템의 기능을 간략하게 보여줍니다. 둘 다 훨씬 더 정교한 CI/CD 요구 사항을 관리할 수 있으며, OpenShift에서 인증 GitLab 러너 오퍼레이터를 실행하면 러너 자체의 수동 설정 및 유지 관리의 상당 부분을 없앨 수 있으므로 빌드의 실제 콘텐츠 및 구성에 드는 시간과 노력을 절약할 수 있습니다.

저는 이 튜토리얼에서 사용된 모든 텍스트 파일을 사용하여 참조 리포지토리를 생성했습니다( 여기를 참조). 아래의 유용한 참조 목록도 확인하시기 바랍니다.


저자 소개

UI_Icon-Red_Hat-Close-A-Black-RGB

채널별 검색

automation icon

오토메이션

기술, 팀, 인프라를 위한 IT 자동화 최신 동향

AI icon

인공지능

고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트

open hybrid cloud icon

오픈 하이브리드 클라우드

하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요

security icon

보안

환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보

edge icon

엣지 컴퓨팅

엣지에서의 운영을 단순화하는 플랫폼 업데이트

Infrastructure icon

인프라

세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보

application development icon

애플리케이션

복잡한 애플리케이션에 대한 솔루션 더 보기

Original series icon

오리지널 쇼

엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리