컨테이너화 기술은 클라우드 환경에서 애플리케이션을 패키징하고 배포하는 가장 보편적인 방법으로 소프트웨어 개발 기술 분야에서 크게 발전했습니다. 이는 DevOps의 정의적인 측면인 지속적 통합(CI) 및 지속적 배포(CD)의 필요성에 의해 필수적이 되었습니다. 소프트웨어 개발자와 엔지니어는 소프트웨어 아키텍처의 CI/CD 측면을 달성하기 위해 컨테이너를 사용합니다. 컨테이너는 본질적으로 완전히 패키징된 이식 가능하고 독립적인 컴퓨팅 플랫폼입니다. 웹상에는 여러 컨테이너 플랫폼이 있지만, Docker가 가장 일반적입니다.
Docker는 오픈 소스 컨테이너 플랫폼으로, 개발을 효율적이고 예측 가능하게 만듭니다. Docker는 Docker Hub에서 제공되는 공개 Docker 이미지 저장소를 제공합니다. 여기에는 가져와서 사용할 수 있는 가장 일반적인 구현을 위한 많은 오픈 소스 Docker 이미지가 포함되어 있습니다. 공개 저장소이므로 자신의 Docker 이미지를 자유롭게 추가하여 대중과 공유할 수도 있습니다. 하지만 비공개/독점 코드가 있는 경우 비공개 이미지 저장소 비용을 지불하거나 자체 이미지 저장소 서비스를 구축해야 할 수 있습니다. 여기서 GitLab이 등장합니다.
GitLab은 웹 기반 Git 저장소로, 단순한 버전 관리 도구 그 이상입니다. 지속적인 통합 및 배포, 이슈 추적, Docker 이미지 레지스트리 등을 위한 DevOps 도구를 제공합니다. GitLab Community Edition (CE), GitLab Enterprise Edition (EE), GitLab SaaS의 세 가지 옵션을 제공합니다. GitLab CE 및 GitLab EE는 GitLab 인스턴스를 직접 다운로드, 설치 및 관리할 수 있는 자체 관리형 솔루션입니다. GitLab SaaS는 GitLab Inc.에서 호스팅하므로 사용하기 위해 아무것도 설치할 걱정을 하지 않아도 됩니다.
이전 튜토리얼에서 저희는 CloudSigma 서버에 GitLab 인스턴스를 설정하고 자체 Git 저장소를 호스팅하는 방법을 보여드렸습니다. 또한 GitLab runner를 사용하여 지속적 통합 파이프라인을 구현하여 새로운 커밋이 있을 때마다 테스트를 자동으로 빌드하고 실행하는 방법도 보여드렸습니다. 언급된 튜토리얼을 아직 진행하지 않으셨다면, 이 튜토리얼의 빌딩 블록이 되므로 먼저 진행해 주시기 바랍니다.
이 튜토리얼에서는 간단한 Docker 이미지를 빌드하고 GitLab 자체 호스팅 인스턴스(Community Edition 또는 Enterprise Edition 사용 여부에 관계없이 – 단계 흐름은 동일합니다)로 호스팅하는 방법을 시연합니다.
전제 조건
이 튜토리얼의 모든 단계를 따라 하려면 아래에 설명된 대로 GitLab CI runner 및 자체 호스팅 GitLab 서버를 준비해 주세요.
1. 보안 GitLab 서버
이것은 소스 코드를 저장하고, CI/CD 작업을 실행하며, Docker 이미지 레지스트리를 호스팅하는 데 사용됩니다. 자체 관리형 GitLab 인스턴스를 설치하려면 GitLab에서 권장하는 최소 2 CPU 코어 및 4GB의 RAM이 장착된 서버가 필요합니다. 또한 서버를 보호하기 위해 Let’s Encrypt의 SSL 인증서를 받는 데 사용할 것이므로 서버를 가리키는 등록된 도메인 이름이 필요합니다. 다음은 GitLab 자체 호스팅 인스턴스를 설정하기 위해 따를 수 있는 몇 가지 링크입니다.
- 원하는 도메인 이름 등록 대행자를 통해 도메인 이름을 등록하고 CloudSigma를 가리키도록 설정합니다.
- 다음 튜토리얼을 따라 초기 Ubuntu 서버 설정, , 루트가 아닌 사용자 추가, 그리고 Ubuntu의 UFW 방화벽 활성화.
- 마지막으로 이 튜토리얼을 따라 자체 호스팅 GitLab 인스턴스를 설치하고 구성합니다.
2. GitLab CI runner
테스트 케이스에 대해 자동화된 작업을 실행하려면 GitLab CI runner가 필요합니다. Ubuntu 20.04에서 GitLab 지속적 통합 파이프라인을 설정하는 방법에 대한 튜토리얼은 GitLab CI 서버에 대한 개요를 제공하고 작업을 트리거하는 방법을 보여줍니다. 아직 설정하지 않았다면 튜토리얼의 단계에 따라 GitLab CI runner 서비스를 설정하세요. 이 튜토리얼에는 테스트 케이스가 포함된 Node.js 데모 앱이 있으며 – 본 튜토리얼에서 이를 사용할 것입니다.
이제 시작해 보겠습니다!
1단계: 권한이 부여된 GitLab CI Runner 구성
GitLab CI Runner 설정 방법에 대한 튜토리얼에서 저희는 다음 명령어를 사용하여 GitLab runner를 구성했습니다: sudo gitlab-runner register 명령어를 통해 필요한 매개변수를 대화식으로 추가할 수 있었습니다. 격리된 Docker 컨테이너에서 빌드 및 테스트를 실행하는 이전 사용 사례에서는 이 방식이 작동했지만, Docker 이미지를 빌드하는 작업은 처리하지 못할 수 있습니다. Docker 이미지를 빌드하려면 러너가 Docker 서비스에 대한 전체 액세스 권한을 가져야 합니다. 공식 docker-in-docker 이미지를 사용하여 작업을 실행하면 이 구성을 구현할 수 있습니다. 이러한 구성에는 러너에게 privileged 실행 모드를 부여하는 것이 포함됩니다.
Docker 이미지를 빌드하려면 privileged 실행 모드를 부여하는 것이 필요하지만, 이는 보안 문제를 야기합니다. 컨테이너의 보안상 이점을 없애기 때문입니다. 다른 Docker 러너들은 안전하다고 생각할 수 있지만, in the official Docker documentation.
에 설명된 것과 동일한 문제를 가지고 있습니다. 우리는 privileged 실행 모드를 가진 또 다른 러너를 생성할 것입니다. 위에서 언급한 보안상의 영향 때문에 이는 프로젝트 전용 러너가 될 것입니다. 이 러너는 Node Pipeline 프로젝트로부터 작업을 수락할 것입니다. 이 프로젝트는 GitLab으로 지속적인 CI 파이프라인을 구축하는 방법 튜토리얼에서 생성했습니다..
가장 먼저 해야 할 일은 프로젝트에서 Shared Runners가 비활성화되어 있는지 확인하는 것입니다. Node Pipeline 프로젝트의 프로젝트 페이지에서 왼쪽 하단 메뉴의 Settings를 클릭하고 하위 메뉴에서 CI/CD를 선택합니다:
Find the Expand 버튼을 Runners 섹션에서 찾아 클릭하면 사용 가능한 러너에 대한 세부 정보가 표시됩니다:
스위치를 클릭하여 이 프로젝트에 대한 Disable Shared Runners를 설정합니다. 이전 섹션에서 프로젝트 전용 러너를 추가했다면 이 또한 비활성화하십시오. 우리는 이 프로젝트의 작업을 실행하기 위해 privileged 프로젝트 전용 러너를 추가할 것입니다. 이렇게 하면 GitLab이 privileged 실행 모드로 등록되지 않은 러너에 작업을 무작위로 할당하여 빌드 오류가 발생하는 것을 방지할 수 있습니다. 위의 스크린샷에서 Specific runners 탭 아래에 프로젝트의 registration token이 보일 것입니다. 아래에서 사용해야 하므로 메모해 두십시오.
| Note: 프로젝트 전용 러너는 Admin panel > Runners 섹션에서 다른 프로젝트에 할당할 수도 있습니다. 러너 목록에서 러너를 선택하면 러너 구성 페이지로 이동합니다. 아래로 스크롤하여 Restrict projects for this runner: |
섹션을 확인하십시오. 이제 터미널을 켤 시간입니다. 만약 Ubuntu 20.04에서 GitLab 지속적 통합 파이프라인을 구축하는 방법 튜토리얼의 단계를 완료하지 않았다면, 이 튜토리얼을 잠시 멈추고 해당 단계를 따라 진행하여 GitLab CI 러너 서비스가 있는 서버를 준비하십시오. 그렇지 않다면, 다음 단계를 위해 GitLab CI runner server에 sudo user로 SSH 접속하십시오.
privileged 프로젝트 전용 러너를 설정하려면 터미널에 다음 명령어를 입력하십시오. 이때 위에서 복사한 도메인 이름과 등록 토큰을 입력해야 합니다:
|
1 2 3 4 5 6 7 |
sudo gitlab-runner register -n \ --url https://your-gitlab-instance-domain.com/ \ --registration-token your-project-specifc-registration-token \ --executor docker \ --description "docker-privileged-builder" \ --docker-image "docker:latest" \ --docker-privilegedh |
이 출력은 성공적인 등록을 보여줍니다:
GitLab 인스턴스가 러너를 인식했는지 확인하려면 브라우저로 돌아가 Settings > CI/CD 페이지를 새로고침하십시오. Runners 섹션을 확장하면 Specific Runners:
아래에 러너가 표시됩니다. 선택 사항으로, Admin Panel (상단 바의 Menu 버튼을 클릭하고 Admin),을 선택)로 이동한 다음, 메뉴 옵션에서 Runners를 선택합니다:
공유 러너와 프로젝트 전용 러너를 포함하여 GitLab instance,에 연결된 사용 가능한 모든 러너를 보여주는 이 페이지로 이동해야 합니다:
여기까지 완료했다면 Docker 이미지를 빌드할 수 있는 러너를 성공적으로 설정한 것입니다.
2단계: GitLab의 Docker 레지스트리 구성하기
일부 중요한 워크플로는 외부 서비스로부터의 독립성을 필요로 합니다. 바로 이 부분에서 GitLab의 자체 관리형 Docker Registry가 유용합니다. 이는 안전할 뿐만 아니라 필요에 따라 작업과 파이프라인을 유연하게 조정할 수 있도록 보장합니다. Docker Registry를 설정하려면 GitLab의 설정 파일을 수정해야 합니다. 먼저 GitLab 인스턴스에 SSH로 접속한 후 다음 명령어로 파일을 엽니다:
|
1 |
sudo nano /etc/gitlab/gitlab.rb |
다음이 보일 때까지 아래로 스크롤합니다: Container Registry Settings:
다음이 포함된 행의 주석을 해제합니다: registry_external_url 그리고 이를 GitLab 인스턴스의 도메인 이름으로 설정하고, 끝에 포트 8888를 지정합니다:
|
1 |
registry_external_url 'https://your-gitlab-domain.com:8888' |
다음으로, 다음 행들을 추가하여 레지스트리가 Let's Encrypt 인증서를 찾을 위치를 지정해야 합니다. 실제 GitLab 인스턴스 도메인 이름으로 수정해야 함을 기억하세요:
|
1 2 |
registry_nginx['ssl_certificate'] = "/etc/letsencrypt/live/your-gitlab-domain.com/fullchain.pem" registry_nginx['ssl_certificate_key'] = "/etc/letsencrypt/live/your-gitlab-domain.com/privkey.pem" |
완료되면 파일을 저장하고 닫습니다. 터미널에 다음 명령어를 입력하여 GitLab을 재구성합니다:
|
1 |
sudo gitlab-ctl reconfigure |
다음으로, 명령어 실행이 완료될 때까지 몇 초간 기다립니다. 성공하면 다음과 같은 출력이 표시됩니다:
다음으로, 방화벽(ufw)이 다음 명령어를 사용하여 우리가 할당한 레지스트리 포트로의 트래픽을 허용하는지 확인해야 합니다:
|
1 |
sudo ufw allow 8888 |
그런 다음, Docker Registry가 실행 중인지 테스트해야 합니다. Docker가 설치된 다른 머신에서 docker login 명령어를 사용하여 로그인하면 됩니다. 로컬 환경에 Docker를 설정하지 않은 경우, 이미 Docker가 설치되어 있는 GitLab CI 러너 서버에 SSH로 접속할 수 있습니다. 다음으로, 당연히 본인의 GitLab 인스턴스 도메인 이름을 지정하여 다음 명령어를 실행합니다:
|
1 |
docker login your-gitlab-domain.com:8888 |
출력에 다음과 같이 Login Succeeded 메시지가 표시됩니다:
이는 레지스트리가 성공적으로 구성되었으며 작동 중임을 의미합니다. 이미지를 생성하면 GitLab 서버의 파일 시스템에 로컬로 저장됩니다. 이는 사내 비공개 레지스트리에는 괜찮습니다. 하지만 레지스트리를 대중에게 공개할 계획이라면 더 큰 저장 공간이 필요할 수 있습니다. 다행히 GitLab은 스토리지 버킷에 연결할 수 있는 옵션을 제공합니다. 공식 GitLab container registry docs에서 GitLab 인스턴스용 스토리지 버킷을 구성하는 방법을 자세히 알아볼 수 있습니다.
3단계: gitlab-ci.yml 파일 수정 및 Docker 이미지 빌드
이 단계를 진행하려면 GitLab 인스턴스에 Node Pipeline 프로젝트가 있어야 합니다. 다음은 GitLab에서의 프로젝트 보기 화면입니다:
우리는 이전에 gitlab-ci.yml 파일이 애플리케이션을 빌드하고 자동화된 테스트를 수행하는 방법을 알기 위해 트리거될 때 GitLab CI 러너가 읽는 파일이라고 설명했습니다. Docker 이미지를 빌드하기 위한 지침을 추가하려면 이 파일을 수정해야 합니다. GitLab 인터페이스 내에서 바로 이 파일을 편집하도록 선택할 수 있습니다. 또는 로컬 머신에 복제(clone)하여 선호하는 에디터로 편집한 다음, 커밋하고 GitLab으로 다시 git push할 수도 있습니다. 간결함을 위해 여기서는 GitLab 인스턴스를 사용하겠습니다.
파일을 클릭하여 연 다음, 편집 버튼을 클릭합니다:
이렇게 하면 파일을 편집할 준비가 됩니다. 파일의 모든 내용을 삭제하고 다음 코드를 추가합니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 |
image: docker:20-dind services: - name: docker:20-dind alias: docker command: ["--tls=false"] stages: - build - test - release variables: TEST_IMAGE: gitlab-domain.com:8888/hackins/node_pipeline:$CI_COMMIT_REF_NAME RELEASE_IMAGE: gitlab-domain.com:8888/hackins/node_pipeline:latest DOCKER_HOST: tcp://docker:2375 DOCKER_DRIVER: overlay2 DOCKER_TLS_CERTDIR: "" before_script: - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN gitlab-domain.com:8888 build: stage: build script: - docker build --pull -t $TEST_IMAGE . - docker push $TEST_IMAGE test: stage: test script: - docker pull $TEST_IMAGE - docker run $TEST_IMAGE npm test release: stage: release script: - docker pull $TEST_IMAGE - docker tag $TEST_IMAGE $RELEASE_IMAGE - docker push $RELEASE_IMAGE only: - master |
위의 코드 스니펫을 추가하는 동안, 강조 표시된 부분을 실제 세부 정보로 업데이트해야 합니다. 완료되면 다음 버튼을 눌러 변경 사항을 저장합니다: Commit changes 버튼을 누르세요. GitLab 외부에서 작업한 경우, 변경 사항을 커밋하고 푸시하세요.
우리가 .gitlab-ci.yml 파일에 추가한 코드가 무엇을 하는지 알아보겠습니다. 첫 번째 줄은 GitLab에 공식 Docker-in-Docker 이미지를 사용하도록 지시하고, 이를 docker-in-docker 서비스(docker:dind)에 연결합니다. 그런 다음 build, test, 및 release 단계를 정의합니다. build 단계는 Dockerfile에 있는 지침을 사용하여 이미지를 빌드한 다음, Docker 레지스트리에 업로드합니다(이전 단계에서 설정).
When the build 단계가 성공하면, test 단계에서 이미지를 다운로드하고 컨테이너로 실행한 다음, 컨테이너 내부에서 자동 테스트를 수행하기 위해 npm test 명령을 실행합니다. test 단계가 성공하면 release 단계가 이어받습니다. release 단계에서는 이미지를 다운로드하고 node_pipeline:latest로 태그를 지정합니다. 그런 다음 레지스트리에 다시 푸시합니다.
이것은 데모 프로젝트를 위한 기본 구성일 뿐입니다. 실제 프로젝트에서는 예를 들어 staging, production 등 다른 단계가 있을 수 있습니다. 편집 후 파일을 저장하면 파이프라인이 트리거되고 작업 실행이 시작됩니다. Node Pipeline 페이지로 돌아가면 작업이 현재 실행 중인 것을 볼 수 있습니다:
작업의 다양한 단계를 보려면 CI 표시기 아이콘을 클릭하세요:
위의 스크린샷에서 볼 수 있듯이, 녹색 체크마크 아이콘으로 표시된 모든 단계가 성공적으로 완료되었습니다. 각 단계를 클릭하여 작업 출력을 볼 수 있습니다:
왼쪽 메뉴에서 Packages & Registries를 클릭하고 Container Registry:
를 선택합니다. 그러면 선택한 프로젝트에 사용 가능한 Docker 이미지 목록이 표시되는 페이지가 나타납니다. 우리가 빌드하고 릴리스한 이미지가 목록에 assigned:
태그와 함께 나타나야 합니다. 클릭하여 이미지의 다양한 태그를 확인하세요:
로컬 환경에 Docker가 설치되어 있다면 이미지를 풀(pull)하여 예상대로 실행되는지 테스트할 수 있습니다. 이미지 태그 이름 옆에 있는 Copy 아이콘을 클릭하세요. docker pull 명령에 사용할 수 있는 전체 이미지 이름이 클립보드에 복사됩니다:
|
1 2 |
docker pull feetspark.com:8888/hackins/node_pipeline:latest docker run -it --rm -p 8090:8090 feetspark.com:8888/hackins/node_pipeline:latest |
위의 명령은 이미지를 풀하고 컨테이너 내부에서 실행합니다:
이제 앱이 다음 포트에서 서비스됩니다: 8090. 브라우저를 열고 다음 주소로 이동하면 your-IP-address:8090 다음과 같은 페이지가 표시될 것입니다:
브라우저에서 이러한 페이지가 보인다면, Docker 이미지를 성공적으로 빌드하고 이를 사설 Docker Registry. 앞으로 master 브랜치에 변경 사항을 적용하면, .gitlab-ci.yml 파일에 정의된 단계들이 실행되고, 성공하면 latest 태그가 지정된 새로운 Docker 이미지가 다시 빌드되어 레지스트리에 푸시됩니다.
결론
이번 프로젝트에서는 Docker 이미지를 빌드할 수 있도록 GitLab 자체 관리형 인스턴스에 privileged GitLab 러너를 추가하는 방법을 배웠습니다. 또한 이미지를 호스팅할 사설 Docker 이미지 레지스트리도 구성했습니다. Node pipeline 프로젝트를 사용하여 설정의 모든 구성 요소를 테스트하고 예상대로 연결 및 통신하는지 확인할 수 있었습니다. 이미지를 레지스트리에서 사용할 수 있게 된 후에는, 이미지를 풀(pull)하여 컨테이너 내부에서 실행되는지 확인할 수 있었습니다.
이 튜토리얼은 기초를 다지기 위한 입문용 가이드입니다. 더 자세한 내용은 공식 GitLab 문서를 참조하여 GitLab에 대해 자세히 알아보세요. 이 링크는 GitLab Container Registry.
Docker 활용에 관한 추가 리소스는 저희 블로그:
- Docker 컨테이너 간 데이터 공유하기
- Ubuntu 18.04에서 사설 Docker 레지스트리 구축하기
- Docker 컨테이너와 호스트 간에 데이터를 공유하는 방법
- Docker 리소스 정리하기 – 이미지, 컨테이너, 볼륨
즐거운 컴퓨팅 되세요!
댓글
아직 댓글이 없습니다. 첫 번째로 작성해 보세요.