Jenkins, Packer, Kubernetes를 통한 자동 이미지 빌드

Compute Engine 인스턴스 또는 Docker 컨테이너를 부팅하기 위한 커스텀 이미지를 만들어 부팅 시간을 줄이고 안정성을 높일 수 있습니다. 또한 커스텀 이미지에 소프트웨어를 사전 설치함으로써 직접 제어할 수 없는 타사 저장소의 가용성에 대한 의존도를 낮출 수 있습니다.

커스텀 이미지에 얼만큼의 소프트웨어와 구성을 포함할지를 직접 선택합니다. 최소 구성 이미지(이 문서에서는 기반 이미지로 지칭)에는 기본 OS 이미지(예를 들어 Ubuntu 14.10)가 포함되며 경우에 따라 기본적인 소프트웨어와 구성도 포함될 수 있습니다. 예를 들어 자바 또는 Ruby와 같은 언어 런타임을 사전 설치하고 원격 로깅을 구성하거나 보안 패치를 적용할 수 있습니다. 기반 이미지는 애플리케이션에 맞는 부가적인 맞춤설정이 가능한 안정적인 기준 이미지를 제공합니다.

최소 구성 이미지와 상반된 개념인 완전 구성 이미지(이 문서에서는 불변성 이미지로 지칭)에는 기본 OS 또는 기반 이미지 뿐만 아니라 애플리케이션을 실행하기 위해 필요한 모든 요소가 포함됩니다. 데이터베이스 연결 정보 또는 민감한 정보와 같은 런타임 구성을 이미지에 포함하거나 실행 시에 환경, 메타데이터 또는 키 관리 서비스를 통해 제공할 수 있습니다.

이미지 빌드 프로세스는 소프트웨어 빌드와 공통점이 많습니다.많은. 즉, 코드(Chef, Puppet, bash 등)와 그 코드를 작성하는 사람들이 있고, 코드를 기본 이미지에 적용하는 시점에 빌드가 실행되며, 성공적인 빌드 프로세스는 아티팩트를 출력하고, 많은 경우 아티팩트를 테스트해야 합니다. 소프트웨어 빌드에 적용되는 권장사항의 상당수는 이미지에도 적용됩니다. 버전 제어를 통해 이미지 구성 스크립트를 관리하고, 스크립트가 변경될 때 빌드를 트리거하고, 이미지 빌드를 자동으로 수행하고, 빌드가 완료되면 이미지 아티팩트에 버전을 설정하고 테스트할 수도 있습니다.

학습할 내용

이 솔루션에서는 커스텀 이미지를 빌드하는 두 가지 일반적인 접근 방식과 Jenkins, Packer, Docker, Kubernetes를 비롯한 여러 인기 있는 오픈소스 도구를 사용하여 이미지를 지속적으로 빌드하는 자동화된 파이프라인을 만드는 방법을 알아봅니다. 이 파이프라인은 Google Cloud Platform(GCP)에서 Cloud Source Repositories와 통합되고 Compute Engine 이미지와 Docker 이미지를 모두 출력합니다.

기반 이미지 및 불변성 이미지를 빌드하는 방법을 익히고 GCP의 여러 프로젝트 전반에서 이러한 이미지 액세스를 관리하기 위한 최상의 권장사항에 대해 알아봅니다. 이 문서의 마지막 섹션에서는 솔루션의 오픈소스 참조 구현을 배포하고 사용할 수 있도록 종합 가이드도 제시합니다.

이미지 유형

확장 가능하고 탄력적인 웹 애플리케이션 솔루션에서 Ruby on Rails 웹 애플리케이션은 GCP에서 웹 애플리케이션을 실행하기 위한 참조로 사용됩니다. 이 솔루션의 소스 코드는 커스텀 이미지를 사용하지 않습니다. Google Compute Engine 인스턴스가 부팅되면 시작 스크립트가 Chef Solo를 설치하고 Chef Solo는 애플리케이션을 실행하는 데 필요한 모든 요소를 설치합니다. 여기에는 nginx, Ruby 2, cURL 및 기타 시스템 도구, Unicorn, Rails 앱 및 모든 Gem, imagemagick, 앱 구성이 포함됩니다.

다음 다이어그램에서 부팅 프로세스를 볼 수 있습니다.

커스텀 이미지를 사용하지 않는 부팅 프로세스를 보여주는 다이어그램

프로세스의 속도는 빠르지 않습니다. 패키지에 필요한 다양한 저장소의 다운로드 속도에 따라 각 인스턴스가 부팅되는 데 10~15분이 소요됩니다. 또한 이러한 패키지를 호스팅하는 모든 저장소가 온라인 상태이며 가용하다는 것을 전제로 합니다. 다음 섹션에서는 기반 이미지와 불변성 이미지를 통해 인스턴스 부팅 프로세스의 성능과 안정성을 어떻게 개선할 수 있는지 살펴봅니다.

기반 이미지

기반 이미지를 만들 때 이미지에 포함할 소프트웨어와 패키지를 결정합니다. 이 결정 시 고려해야 할 몇 가지 사항은 다음과 같습니다.

  • 설치 속도. 큰 패키지는 다운로드 속도가 느릴 수 있습니다. 소스에서 빌드해야 하는 소프트웨어에는 많은 시간이 소요될 수 있습니다. 종속 항목이 많은 패키지는 문제를 더 악화시킵니다. 이러한 유형의 소프트웨어 및 패키지는 기반 이미지에 포함하는 것이 좋습니다.
  • 원격 저장소의 안정성. 기반 이미지에 소프트웨어를 포함하지 않고 부팅 시 다운로드하는 경우 원격 저장소의 가용성을 신뢰할 수 있나요? 부팅 중 이 저장소를 사용할 수 없는 경우 애플리케이션 기능이 정상적으로 작동할 수 없나요? 직접 통제할 수 없는 원격 저장소에 대한 의존도를 낮추려면 핵심 종속 항목을 기반 이미지에 포함하는 것이 좋습니다.
  • 변경 빈도. 소프트웨어 또는 패키지가 매우 자주 변경되나요? 그렇다면 기반 이미지에 넣지 말고 Google Cloud Storage(GCS) 버킷과 같은 안정적이고 액세스 가능한 위치에 두는 것이 좋습니다.
  • 필수 또는 보안 의무. 특정 패키지(예를 들어 로깅, OSSEC 등)를 특정 구성으로 조직의 모든 인스턴스에서 반드시 실행해야 하는 경우 이러한 패키지는 다른 모든 이미지가 확장되는 기반 이미지에 설치되어야 합니다. 보안팀은 Chef 또는 Puppet과 같은 더 고급 도구를 사용하여 Docker 기반 이미지를 빌드할 수 있으며 다운스트림 개발자는 Dockerfile을 사용하여 이 기반 이미지를 손쉽게 확장할 수 있습니다.

이러한 기준은 Scalable and Resilient Web Applications 솔루션의 Ruby on Rails 애플리케이션을 위한 기반 이미지가 Chef Solo, nginx, Ruby, cURL 및 기타 시스템 도구와 Unicorn을 포함할 수 있음을 시사합니다. 다른 종속 항목은 부팅 시 설치됩니다.

다음 다이어그램은 기반 이미지를 사용하는 부팅 프로세스를 보여줍니다.

기반 이미지를 사용하는 부팅 프로세스를 보여주는 다이어그램

이 예의 기능 인스턴스는 Compute Engine 메타데이터 서비스에서 구성(예를 들어 데이터베이스 연결 문자열, API 키 등)을 검색합니다. etcd와 같은 다른 서비스 또는 간단한 Cloud Storage 버킷을 선택하여 구성을 관리할 수도 있습니다.

다음 섹션에서는 이 그림의 Ruby 기반 이미지 빌드를 자동화하는 데 사용되는 도구를 중점적으로 살펴봅니다.

불변성 이미지

불변성 이미지는 기반 이미지와 달리 이미지에 모든 소프트웨어를 포함합니다. 이미지에서 인스턴스 또는 컨테이너가 실행될 때 다운로드할 패키지나 설치할 소프트웨어가 없습니다. Scalable and Resilient Web Applications 솔루션의 Ruby on Rails 애플리케이션을 위한 불변성 이미지는 모든 소프트웨어를 포함하며 인스턴스는 부팅 시 즉시 트래픽을 처리할 수 있습니다.

불변성 이미지를 사용하는 부팅 프로세스를 보여주는 다이어그램

구성 및 불변성 이미지

애플리케이션이 구성 서비스에서 필요한 구성 데이터에 액세스하도록 하거나 모든 구성을 불변성 이미지에 포함할 수 있습니다. 후자의 방식을 선택하는 경우 이미지에 기밀 사항을 포함하는 데 따르는 보안 측면의 영향을 고려해야 합니다. 불변성 이미지를 Docker Hub의 공개 저장소에 푸시하는 경우 모든 사람이 이 이미지에 액세스할 수 있으므로 민감한 정보 또는 기밀 정보를 이미지에 포함되면 안 됩니다.

배포 단위로서의 불변성 이미지

불변성 이미지를 배포 단위로 사용하면 하나 이상의 인스턴스가 예상과 다른 상태가 되는 구성 드리프트 가능성이 제거됩니다. 예를 들어 100개의 실행 중인 컨테이너에 보안 패치를 적용했는데 그 중 일부에서 업데이트가 실패하는 경우 구성 드리프트가 발생할 수 있습니다. 이미지는 변경이 수행될 때 배포하는 이미지가 됩니다. OS에 소프트웨어 패치가 필요하거나 로깅 구성을 업데이트해야 하는 경우 이러한 변경을 포함하도록 새 이미지를 빌드하고 새 인스턴스 또는 컨테이너를 실행해서 이전 인스턴스 또는 컨테이너를 대체하는 방식으로 이미지를 릴리스해야 합니다. 불변성 이미지에 애플리케이션 구성을 포함하는 경우 데이터베이스 연결 문자열 업데이트와 같은 간단한 변경도 새 이미지를 만들어서 릴리스해야 함을 의미합니다.

자동 이미지 빌드 파이프라인의 아키텍처 및 구현

이 섹션에는 Jenkins, Packer, Docker, Google Kubernetes Engine(GKE)을 사용하여 자동으로 커스텀 이미지를 빌드하는 자동 이미지 빌드 파이프라인의 구현 세부정보가 포함됩니다. 각 섹션에는 소개, 아키텍처 다이어그램, 다이어그램의 구성요소에 대한 세부적인 분석이 포함됩니다.

사용되는 소프트웨어 및 서비스

자동 이미지 빌더를 만드는 데 사용되는 소프트웨어 및 서비스는 다음과 같습니다.

소프트웨어 사용
Jenkins Jenkins는 인기 있는 오픈소스 지속적 통합(CI) 서버입니다. Jenkins를 사용하여 이미지 구성 스크립트가 포함된 다른 프로젝트의 Git 저장소를 폴링한 다음 이러한 저장소를 기반으로 이미지를 빌드합니다.
Packer Packer는 하나의 소스 구성에서 여러 플랫폼을 위한 동일한 머신 이미지를 만들기 위한 도구입니다. Shell, Chef, Puppet, Ansible, Salt를 포함한 다양한 구성 소스를 지원하며 Compute Engine, Docker 등을 위한 이미지를 출력할 수 있습니다. Packer는 Jenkins 에이전트가 Git 저장소의 구성에서 이미지를 빌드하는 데 사용됩니다.
Docker Docker는 애플리케이션을 컨테이너로 패키징 및 배포하기 위한 오픈소스 도구입니다. 이 아키텍처 및 가이드의 Jenkins 배포(리더 노드와 빌드 에이전트 포함)는 Docker 컨테이너로 배포됩니다. 빌드 에이전트는 에이전트의 아키텍처 중 하나로도 Docker 이미지를 출력합니다.
GKE 오픈소스 기술인 Kubernetes를 기반으로 하는 GKE를 사용하면 GCP의 가상 머신에서 Docker 컨테이너를 실행 및 관리할 수 있습니다.
Container Registry Container Registry는 GCP에서 안전한 비공개 Docker 이미지 스토리지를 제공합니다. GCP에서 실행되며 HTTPS 엔드포인트를 통해 액세스됩니다.
Compute Engine GKE는 Compute Engine VM을 사용하여 Kubernetes를 실행하고 Jenkins 리더 및 빌드 에이전트 컨테이너를 호스팅합니다. 또한 Jenkins 빌드 프로세스는 Docker 이미지 외에 Compute Engine VM 이미지도 출력합니다.
Cloud Storage Cloud Storage를 사용하여 Jenkins 구성의 백업을 저장합니다.
Nginx Nginx는 역방향 프록시 기능을 제공하여 수신 요청을 Jenkins 리더 웹 인터페이스로 전달합니다. SSL 연결을 종료하고 기본적인 인증을 제공하도록 구성할 수 있습니다.

이미지 빌더 개요

다음 다이어그램은 다양한 구성요소가 상호작용하여 VM 및 Docker 이미지를 자동으로 빌드하는 시스템을 만드는 방법을 보여줍니다.

이미지 빌더 프로젝트의 다양한 구성요소를 보여주는 다이어그램

빌드하려는 각 이미지의 Jenkins 리더에서 작업을 정의합니다. 작업은 구성 스크립트가 포함된 소스 코드 저장소(이 그림에서는 Git)와 이미지 빌드 방법이 설명된 Packer 템플릿을 폴링합니다. 폴링 프로세스가 변경을 감지하면 Jenkins 리더는 빌드 에이전트에 작업을 할당합니다. 에이전트가 Packer를 사용하여 빌드를 실행하면 Container Registry에 Docker 이미지가 출력되고 Compute Engine에 VM 이미지가 출력됩니다.

Packer 및 구성 스크립트

Packer 템플릿 및 관련 구성 스크립트는 이미지를 빌드하는 방법을 정의합니다. 이러한 항목은 소프트웨어처럼 취급되며 자체 Git 저장소에 저장됩니다. 빌드하는 각 이미지에는 자체 저장소, Packer 템플릿과 구성 스크립트가 있습니다.

이 섹션에서는 Chef를 사용해서 Ruby 및 rbenv를 추가하여 Ubuntu 14.04를 맞춤설정하는 Packer 구성의 개요를 제공합니다. Packer에 대한 자세한 내용은 https://www.packer.io/docs에 잘 정리되어 있는 문서를 참조하세요.

이미지 이름 지정 및 packer 변수

이미지 빌더는 이미지의 Packer 템플릿 및 구성 스크립트가 포함된 Git 저장소에 변경이 수행될 때마다 이미지를 빌드합니다. 이미지가 빌드된 Git 브랜치 및 커밋 ID를 사용하여 이미지에 이름 또는 태그를 지정하는 것이 좋습니다. Packer 템플릿을 사용하면 변수를 정의하고 런타임에 변수의 값을 제공할 수 있습니다.

{
...
  "variables": {
      "Git_commit": "",
      "Git_branch": "",
      "ruby_version_name": "212",
      "project_id": "null"
  }
...
}

Jenkins 빌드 에이전트는 Git 브랜치 및 커밋 ID를 찾아서 Packer 명령줄 도구에 변수로 제공할 수 있습니다. 이 문서의 가이드 섹션 후반에서 작동 과정을 볼 수 있습니다.

프로비저닝 도구를 사용한 프로그래매틱 구성

Packer 템플릿은 Chef, Puppet, 셸 스크립트와 같은 도구를 사용하여 인스턴스를 구성하는 방법을 설명하는 하나 이상의 프로비저닝 도구를 정의합니다. Packer는 많은 프로비저닝 도구를 지원합니다. 전체 목록은 Packer 문서의 목차를 참조하세요. 이 스니펫은 이미지를 구성하기 위해 실행할 레시피 및 설명서 경로와 함께 chef-solo 프로비저닝 도구를 정의합니다.

{
  ...
  "provisioners": [
    {
      "type": "chef-solo",
      "install_command": "apt-get install -y curl && curl -L https://www.opscode.com/chef/install.sh | {{if .Sudo}}sudo{{end}} bash",
      "cookbook_paths": ["chef/site-cookbooks"],
      "run_list": [{{
        "recipe[ruby]",
        "recipe[ruby::user]",
        "recipe[ruby::ruby212]"
      ]
    }
  ],
  ...
}

chef 설명서 및 레시피는 Packer 템플릿과 동일한 Git 저장소에 저장됩니다.

빌더를 사용하여 이미지 출력 정의

템플릿의 builders 섹션은 새 이미지를 만들기 위해 프로비저닝 도구가 실행되는 장소를 정의합니다. Compute Engine 이미지와 Docker 이미지를 빌드하려면 두 빌더를 정의합니다.

{
  "variables": {...},
  "provisioners": [...],
  "builders": [
    {
      "type": "googlecompute",
      "project_id": "{{user `project_id`}}",
      "source_image": "ubuntu-1410-utopic-v20150202",
      "zone": "us-central1-a",
      "image_name": "{{user `ruby_version_name`}}-{{user `Git_branch`}}-{{user `Git_commit`}}"
    },
    {
      "type": "docker",
      "image": "ubuntu:14.10",
      "commit": "true"
    }
  ],
 ...
}

googlecompute 빌더에는 결과 이미지가 저장되는 장소를 가리키는 project_id 속성이 포함됩니다. 결과 이미지에 이름을 할당하는 image_name 속성은 변수를 연결하여 Ruby의 버전, Git 브랜치, 이미지를 빌드하는 데 사용된 Git 커밋 ID 등 이미지에 대한 정보가 포함된 이름을 만듭니다. googlecompute 빌더가 만든 이미지의 샘플 URI는 다음과 같은 형태가 됩니다.

https://www.googleapis.com/compute/v1/projects/image-builder-project-name/global/images/ruby212-master-9909043

docker 빌더는 Docker 레지스트리 및 푸시되는 저장소를 사용하여 이미지에 태그를 지정하기 위한 post-processors 속성을 포함해야 합니다.

{
  "variables": {...},
  "provisioners": [...],
  "builders": [...],
  "post-processors": [
    [
      {
        "type": "docker-tag",
        "repository": "gcr.io/{{user `project_id`}}/ruby212",
        "tag": "{{user `Git_branch`}}-{{user `Git_commit`}}",
        "only": ["docker"]
      }
    ]
  ]
}

이 포스트 프로세서는 빌드가 실행될 때 Container Registry에 저장하기 위해 이미지에 제공된 project_id를 사용하여 태그를 지정합니다. 이 Docker 이미지가 푸시된 후 이미지를 검색할 수 있습니다.

docker pull gcr.io/image-builder-project-name/ruby212:master-9909043

빌드하려는 각 이미지에는 자체 소스 저장소에 Packer 템플릿과 구성 스크립트가 있으며, Jenkins 리더에는 각각에 정의된 작업이 있습니다(다음 다이어그램 참조).

커스텀 이미지가 있는 이미지 빌더 프로젝트를 보여주는 다이어그램

Jenkins와 Packer를 함께 사용할 경우 얻는 한 가지 이점은 Packer 템플릿 또는 구성 스크립트의 업데이트를 Jenkins가 감지하고 대응할 수 있다는 점입니다. 예를 들어 Ruby 기반 이미지에 설치된 Ruby 버전을 업데이트하는 경우 Jenkins 리더는 이에 대응하여 에이전트를 할당해서 저장소를 복제하고 템플릿을 대상으로 Packer를 실행하고 이미지를 빌드합니다.

이 솔루션 끝의 가이드에서는 Jenkins 작업을 구성하여 Packer 빌드를 실행하는 프로세스를 자세히 다룹니다.

프로젝트 격리

Jenkins 리더와 빌드 에이전트는 동일한 Cloud Platform 프로젝트에서 함께 실행되며 이 두 가지가 생성하는 이미지는 이 프로젝트에 저장됩니다. 프로젝트는 기능별로 애플리케이션을 격리하도록 허용합니다. 프로젝트에는 비용이 청구되지 않으며 사용하는 리소스에 대해서만 청구됩니다. 이 솔루션에서 Jenkins 인프라는 사용하는 소스 제어 저장소와는 별개인 자체 프로젝트에서 실행됩니다. Jenkins 백업(이후 섹션에서 설명)은 프로젝트 내의 Google Cloud Storage 버킷에 저장됩니다. 이로써 Jenkins는 '이미지 허브' 역할을 하고, 다른 프로젝트가 별도의 액세스 제어로 자체 코드 저장소를 유지하도록 허용하면서 다른 프로젝트와 이미지를 공유합니다.

이미지를 빌드하여 조직 전체에서 공유하기

이미지 공유를 촉진하기 위해 이 솔루션은 Git에 저장된 각 빌드 이미지를 개별 이미지 구성 프로젝트에 배치합니다. 이렇게 분리하면 이미지 빌더 프로젝트와 빌드 이미지 사이에서 프로젝트를 격리할 수 있습니다. 이미지 빌더 프로젝트가 허브, 이미지 구성 프로젝트가 스포크가 되는 이 허브 및 스포크 아키텍처를 통해 개별 팀이 이미지 구성을 보다 쉽게 소유 및 관리할 수 있습니다.

다음 다이어그램에서 이 허브 및 스포크 아키텍처를 볼 수 있습니다.

허브 및 스포크 시스템으로서의 이미지 빌더 프로젝트를 보여주는 다이어그램

액세스 제어(Jenkins 클러스터에 각 이미지 프로젝트에 대한 액세스 권한을 부여하고 다른 프로젝트에 Jenkins가 빌드한 이미지에 대한 액세스 권한 부여)는 아래에서 설명합니다.

이미지당 하나의 프로젝트

만드는 각 프로젝트에는 전용 Git 기반 Cloud Repository가 있습니다. 만들 수 있는 프로젝트의 수에는 제한이 없으며 비용은 Compute Engine 인스턴스와 같이 프로젝트에서 사용한 리소스에 대해서만 지불합니다. 예를 들어 PHP, Ruby, Wordpress 이미지가 있는 경우 각 이미지에는 Google Cloud Platform Console에서 볼 수 있는 자체 프로젝트가 있습니다(아래 다이어그램 참조).

각 커스텀 이미지를 위한 개별 프로젝트가 있는 이미지 빌더 프로젝트를 보여주는 다이어그램

프로젝트의 Cloud Repository는 소스 코드 메뉴 항목에서 액세스할 수 있습니다. 새 프로젝트의 경우 저장소를 초기화하는 방법을 선택합니다. 기존 GitHub 또는 Bitbucket 저장소를 미러링하고 기존 로컬 Git 저장소를 푸시하거나 Cloud Source Repositories에서 새 로컬 Git 저장소를 만들 수 있습니다(아래 이미지 참조).

GCP Console에서 소스 코드를 탐색하는 방법을 보여주는 화면 이미지

다음 이미지에서 빌드를 정의하는 Packer 템플릿 및 Chef 레시피로 초기화된 Ruby 기반 이미지 프로젝트를 볼 수 있습니다.

Packer 템플릿 및 Chef 레시피가 있는 Ruby 기반 이미지

저장소의 URL을 보려면 설정을 클릭합니다. 이 URL은 Jenkins 리더에서 저장소의 빌드 작업을 만들 때 필요합니다(다음 이미지 참조).

Jenkins 리더의 소스 저장소 설정

Cloud Repository 액세스 제어

Jenkins 이미지 빌더에는 각 이미지 구성 프로젝트의 Cloud Repository에 대한 보기 가능 권한이 필요합니다. 다음 다이어그램은 앞서 살펴본 허브 및 스포크 아키텍처를 간략히 보여줍니다.

필요한 권한이 있는 이미지 빌더 프로젝트

각 프로젝트는 이미지 빌더 프로젝트의 컴퓨팅 서비스 계정 이메일 주소를 사용하여 Jenkins 이미지 빌더 프로젝트에 액세스 권한을 부여해야 합니다. 이 주소는 \{PROJECT_ID\}-compute@developer.gserviceaccount.com 형식이며 GCP Console 프로젝트의 권한 섹션에서 복사할 수 있습니다(아래 이미지 참조).

프로젝트의 권한 섹션에서 복사할 주소

Jenkins 이미지 빌더를 실행하는 프로젝트의 컴퓨팅 서비스 계정 이메일 주소를 확보한 후 이미지를 빌드할 Cloud Repository가 있는 각 프로젝트의 권한 섹션으로 이동하여 구성원 추가를 선택하고 보기 가능 권한을 부여합니다.(아래 이미지 참조).

프로젝트에서 보기 가능 권한 설정

이미지 빌더 프로젝트에서 실행 중인 Jenkins 리더는 이제 이러한 프로젝트의 Cloud Repository에서 폴링 및 가져오기가 가능하며 변경사항이 커밋되면 새 이미지를 빌드합니다.

Compute Engine 및 Docker 이미지 공유

이미지 빌더에 의해 생성된 Compute Engine 및 Docker 이미지는 이미지 빌더와 동일한 프로젝트에 저장됩니다. 이미지는 다른 프로젝트의 애플리케이션에서 Compute Engine 인스턴스 및 Docker 컨테이너를 실행하는 데 사용되며 이러한 이미지에 액세스하고자 하는 각 애플리케이션 프로젝트에는 이미지 빌더 프로젝트에 대한 보기 가능 권한이 있어야 합니다. 이전 섹션에 정의된 프로세스에 따르되, 이번에는 각 애플리케이션 프로젝트의 컴퓨팅 서비스 계정을 찾아 이를 보기 가능 권한이 있는 구성원으로 이미지 빌더 프로젝트에 추가합니다(아래 다이어그램 참조).

보기 가능 권한이 있는 다른 프로젝트를 이미지 빌더 프로젝트에 추가

Jenkins 백업 및 복원

Jenkins 리더에는 Jenkins 구성 및 작업 내역을 Google Cloud Storage에 정기적으로 백업하기 위한 사전 정의된 작업이 포함됩니다. 기본적으로 이 작업은 아래 이미지에서 볼 수 있듯이 정기적으로(2시간마다, 평일 매일) 실행됩니다.

Jenkins 리더의 자동 빌드 설정

작업의 빌드 단계는 보안 비밀, 사용자, 작업, 내역을 tarball로 보관처리하는 셸 스크립트를 실행합니다. 보관 파일의 두 가지 복사본이 생성됩니다. 하나의 이름은 날짜 스탬프, 다른 하나의 이름은 LATEST로, 가장 최근 백업을 손쉽게 자동으로 복원할 수 있게 해줍니다. 이 단계를 맞춤설정하여 다음 이미지와 같이 백업되는 항목을 추가 또는 제거할 수 있습니다.

빌드 스크립트를 맞춤설정하는 방법

빌드 후 작업에서는 사용자가 만든 Cloud Storage 플러그인과 Google 메타데이터 사용자 인증 정보를 사용하여 Google API와 상호작용하고 Cloud Storage에 백업 보관 파일을 업로드합니다. 날짜 스탬프와 LATEST 보관 파일을 모두 업로드합니다. 다음 이미지는 단계 정의를 보여줍니다.

빌드 후 작업을 정의하기 위한 인터페이스

다음 이미지는 누적된 백업이 있는 버킷을 보여줍니다.

프로젝트의 누적된 백업 목록

백업 복원

환경 변수를 사용하여 Nginx 역방향 프록시에서 SSL 또는 기본 인증을 사용 설정하는 것과 같은 방식으로 환경 변수를 사용하여 Jenkins 리더의 복제 컨트롤러 정의를 구성해 서비스가 시작될 때 백업을 복원하도록 할 수 있습니다. 다음 코드는 복제 컨트롤러의 정의에서 가져온 스니펫입니다.

{
  "kind": "ReplicationController",
  ...
  "spec": {
    ...
    "template": {
      "spec": {
        "containers": [
            {
              "name": "jenkins",
              "env": [
                {
                  "name": "GCS_RESTORE_URL",
                  "value": "gs://your-backup-bucket/jenkins-backup/LATEST.tar.gz"
                }
              ],
             ...
           }
        ]
      }
    }
  }
}

Jenkins 리더 Docker 이미지는 시작될 때 GCS_RESTORE_URL 환경 변수의 존재를 확인합니다. 환경 변수가 발견되는 경우 값은 백업의 URL로 간주되며(gs:// 체계 포함) 스크립트는 Jenkins 리더 이미지에 설치된 gsutil 명령줄 도구를 사용하여 안전하게 백업을 다운로드하고 복원합니다.

복원 프로세스는 컨테이너가 실행될 때만 수행됩니다. Jenkins 리더를 실행한 후 백업을 복원하려면 복제 컨트롤러의 크기를 0으로 조정하고 컨트롤러의 정의를 백업의 URL을 가리키도록 업데이트한 다음 크기를 다시 1로 설정합니다. 이 내용은 가이드에서 다룹니다.

가이드

안내 및 소스 코드를 포함한 가이드의 전체 내용은 GitHub(https://github.com/GoogleCloudPlatform/kube-jenkins-imager.)에서 볼 수 있습니다.

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...