GitLab CI 파이프라인에서 Docker 이미지를 빌드하는 방법

class="co4">docker_build:class="co3">
  stageclass="sy2">: buildclass="co3">
  imageclass="sy2">: docker:latestclass="co4">
  scriptclass="sy2">:
    - docker pull $CI_REGISTRY_IMAGE:latest || true
    - docker build --cache-from $CI_REGISTRY_IMAGE:latest -t $CI_REGISTRY_IMAGE:latest .

소켓 바인드 마운트

호스트의 Docker 소켓을 작업 환경에 마운트하는 것은 Docker 실행기를 사용할 때 대체 옵션입니다. 이렇게 하면 원활한 캐싱이 가능하며 CI 구성에 docker:dind 서비스를 추가할 필요가 없습니다.

이를 설정하려면 호스트의 Docker 소켓을 작업 컨테이너 내부의 /var/run/docker.sock에 바인딩하는 docker-volumes 플래그로 Runner를 등록합니다.

sudo gitlab-runner register -n 
  --url https://example.com 
  --registration-token $GITLAB_REGISTRATION_TOKEN 
  --executor docker 
  --description "Docker Runner" 
  --docker-image "docker:20.10" 
  --docker-volumes /var/run/docker.sock:/var/run/docker.sock

이제 docker 이미지로 실행되는 작업은 docker 바이너리를 정상적으로 사용할 수 있습니다. 작업은 실제로 호스트 시스템에서 발생하여 자식 대신 작업 컨테이너의 형제가 됩니다.

이는 호스트의 Docker 설치와 함께 셸 실행기를 사용하는 것과 사실상 유사합니다. 이미지는 호스트에 상주하여 일반 docker 빌드 레이어 캐싱을 원활하게 사용할 수 있습니다.

이 접근 방식은 성능 향상, 구성 감소, DinD의 제한 없음으로 이어질 수 있지만 고유한 문제가 있습니다. 그중 가장 눈에 띄는 것은 보안 관련 사항입니다. 작업은 Runner 호스트에서 임의의 Docker 명령을 실행할 수 있으므로 GitLab 인스턴스의 악성 프로젝트는 docker run -it malable-image:latest 또는 를 실행할 수 있습니다. docker rm -f $ (docker ps -a)는 엄청난 결과를 초래합니다.

GitLab은 또한 작업이 동시에 실행될 때 소켓 바인딩이 문제를 일으킬 수 있다고 경고합니다. 이는 특정 이름으로 생성되는 컨테이너에 의존할 때 발생합니다. 작업의 두 인스턴스가 병렬로 실행되는 경우 컨테이너 이름이 호스트에 이미 존재하므로 두 번째 인스턴스는 실패합니다.

이러한 문제 중 하나가 문제가 될 것으로 예상되는 경우 DinD를 대신 사용하는 것이 좋습니다. DinD는 더 이상 일반적으로 권장되지 않지만 동시 CI 작업을 실행하는 공용 GitLab 인스턴스에 더 적합할 수 있습니다.

GitLab의 레지스트리에 이미지 푸시

GitLab 프로젝트에는 이미지를 저장하는 데 사용할 수 있는 통합 레지스트리 옵션이 있습니다. 프로젝트의 사이드바에서 패키지 및 레지스트리 > 컨테이너 레지스트리로 이동하여 레지스트리의 콘텐츠를 볼 수 있습니다. 이 링크가 보이지 않으면 설정 > 일반 > 가시성, 프로젝트, 기능 및 권한으로 이동하고 컨테이너 레지스트리 토글을 활성화하여 레지스트리를 활성화하십시오.

GitLab은 CI 작업에서 프로젝트의 컨테이너 레지스트리를 참조할 수 있는 환경 변수를 자동으로 설정합니다. script 섹션을 조정하여 레지스트리에 로그인하고 이미지를 푸시합니다.

class="co4">scriptclass="sy2">:
  - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
  - docker build -t $CI_REGISTRY_IMAGE:latest .
  - docker push $CI_REGISTRY_IMAGE:latest

GitLab은 각 CI 작업에 대한 보안 자격 증명 세트를 생성합니다. $CI_JOB_TOKEN 환경 변수에는 작업이 gitlab-ci-token 사용자로 레지스트리에 연결하는 데 사용할 수 있는 액세스 토큰이 포함됩니다. 레지스트리 서버 URL은 $CI_REGISTRY로 사용할 수 있습니다.

마지막 변수인 $CI_REGISTRY_IMAGE는 프로젝트의 컨테이너 레지스트리에 대한 전체 경로를 제공합니다. 이것은 이미지 태그에 적합한 기반입니다. 이 변수를 확장하여 $CI_REGISTRY_IMAGE/production/api:latest와 같은 하위 리포지토리를 만들 수 있습니다.

다른 Docker 클라이언트는 액세스 토큰을 사용하여 인증하여 레지스트리에서 이미지를 가져올 수 있습니다. 프로젝트의 설정 > 액세스 토큰 화면에서 이를 생성할 수 있습니다. read_registry 범위를 추가한 다음 표시된 자격 증명을 사용하여 프로젝트 레지스트리에 docker 로그인합니다.

GitLab의 종속성 프록시 사용

GitLab의 종속성 프록시는 Docker 허브에서 가져오는 업스트림 이미지에 대한 캐싱 계층을 제공합니다. 이미지가 실제로 변경된 경우에만 이미지 콘텐츠를 가져옴으로써 Docker Hub의 속도 제한 내에서 유지하는 데 도움이 됩니다. 이렇게 하면 빌드 성능도 향상됩니다.

종속성 프록시는 설정 > 패키지 및 레지스트리 > 종속성 프록시로 이동하여 GitLab 그룹 수준에서 활성화됩니다. 활성화되면 .gitlab-ci.yml 파일의 이미지 참조에 $CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX 접두사를 붙여 프록시를 통해 가져옵니다.

class="co4">docker_build:class="co3">
  stageclass="sy2">: buildclass="co3">
  imageclass="sy2">: $CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX/docker:latestclass="co4">
  services:class="co3">
    - nameclass="sy2">: $CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX/docker:dindclass="co3">
      aliasclass="sy2">: docker

그게 전부입니다! GitLab Runner는 종속성 프록시 레지스트리에 자동으로 로그인하므로 자격 증명을 수동으로 제공할 필요가 없습니다.

GitLab은 이제 이미지를 캐시하여 향상된 성능과 네트워크 중단에 대한 복원력을 제공합니다. services 정의도 조정해야 했습니다. 환경 변수는 이전에 사용된 인라인 양식에서 작동하지 않으므로 전체 이미지 이름을 지정해야 합니다. script 섹션에서 참조할 명령 alias.

이제 작업 단계에서 직접 사용하는 이미지에 대한 프록시를 설정했지만 빌드할 Dockerfile의 기본 이미지에 대한 지원을 추가하려면 더 많은 작업이 필요합니다. 이와 같은 일반 명령은 프록시를 거치지 않습니다.

FROM ubuntu:latest

이 마지막 부분을 추가하려면 Docker의 빌드 인수를 사용하여 Dockerfile을 단계별로 실행할 때 종속성 프록시 URL을 사용할 수 있도록 합니다.

ARG GITLAB_DEPENDENCY_PROXY
FROM ${GITLAB_DEPENDENCY_PROXY}/ubuntu:latest

그런 다음 docker build 명령을 수정하여 변수 값을 정의합니다.

class="co4">scriptclass="sy2">:
  class="sy2">>
class="co0">    - docker build 
        --build-arg GITLAB_DEPENDENCY_PROXY=${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX} 
        -t example-image:latest .

이제 기본 이미지도 종속성 프록시를 통해 가져옵니다.

요약

Docker 이미지 빌드는 GitLab CI 파이프라인에 쉽게 통합됩니다. 초기 Runner 구성 후 작업의 script 섹션에 있는 docker build 및 docker push 명령만 있으면 저장소의 Dockerfile. GitLab의 내장 컨테이너 레지스트리는 프로젝트 이미지를 위한 개인 스토리지를 제공합니다.

기본 빌드 외에도 GitLab의 종속성 프록시를 통합하여 성능을 가속화하고 Docker Hub 속도 제한에 도달하지 않도록 하는 것이 좋습니다. 또한 선택한 방법이 신뢰할 수 없는 프로젝트가 Runner 호스트에서 명령을 실행하도록 허용하는지 여부를 평가하여 설치의 보안을 확인해야 합니다. 고유한 문제가 있지만 Docker-in-Docker는 GitLab 인스턴스에 공개적으로 액세스하거나 대규모 사용자 기반에서 액세스할 때 가장 안전한 접근 방식입니다.

관련기사:

• 다양한 Linux 빌드 수정 사항이 포함된 VirtualBox 5.2.16 출시
• 커널 4.19 빌드 수정 사항과 함께 출시된 Virtualbox 5.2.20
• Pinguy Builder - 나만의 맞춤형 설치 가능한 Ubuntu ISO 구축
• 여러 플랫폼에 대해 Fpm을 사용하여 Linux 패키지를 쉽게 구축하는 방법
• CheckInstall을 사용하여 소스에서 패키지를 빌드하는 방법
• 소스에서 데비안 패키지를 빌드하는 방법
• Virt-builder를 사용하여 가상 머신 이미지를 구축하는 방법
• OpenELEC로 나만의 미디어 센터를 구축하는 방법
• 라즈베리 파이로 DIY 무선 프린터를 만드는 방법
• Linux의 소스에서 패키지를 빌드하는 방법
• Ubuntu에서 사용자 정의 커널을 구축하고 설치하는 방법
• 지금 당장 구축할 수 있는 최고의 Arduino 프로젝트 15가지
• 강력한 AI 봇을 구축하기 위한 최고의 챗봇 프레임워크 Top 30
• 최신 소프트웨어 개발을 위한 20가지 최고의 빌드 자동화 도구
• 적절한 수면 습관을 기르는 데 도움이 되는 안드로이드용 최고의 수면 앱 10가지

---