이 페이지에서는 Looker에서 CI/CD 워크플로를 구현하는 데 필요한 구성요소를 설치하고 구성하는 방법을 설명합니다.
이 안내에서는 개발, 품질 보증, 프로덕션으로 구성된 3계층 시스템을 사용합니다. 하지만 2계층 또는 4계층 시스템에 동일한 원칙을 적용할 수 있습니다.
이 안내에서는 GitHub를 Git 제공업체로 사용한다고 가정합니다. 다른 Git 제공업체를 사용하여 CI/CD 워크플로를 만들 수 있습니다. 하지만 제공업체를 위해 이 안내를 수정할 수 있는 전문성을 보유하고 있어야 합니다.
해당하는 섹션의 안내를 따르세요.
기본 요건
Linux 환경
이 프로세스에서는 Unix와 유사한 운영체제에서 작동하도록 설계된 Gazer 및 Spectacles라는 도구를 사용합니다. 각 LookML 개발자는 CI/CD 워크플로를 실행하려는 Linux 환경 또는 macOS에서 명령줄에 액세스할 수 있어야 합니다.
Windows를 사용하는 경우 Microsoft의 Linux용 Windows 하위 시스템(WSL) 내에서 Gazer 및 Spectacles를 사용할 수 있습니다. WSL을 사용하면 다양한 Linux 버전을 실행할 수 있습니다. 선호하는 Linux 운영체제가 없는 경우 광범위한 지원으로 최신 버전의 Ubuntu Linux를 선택하는 것이 좋습니다.
이 안내는 Linux 시스템의 예시를 제공하며 macOS 또는 WSL을 사용하는 경우 수정이 필요할 수 있습니다.
계층당 Looker 인스턴스 1개
이 구성을 사용 설정하려면 시스템의 각 계층에 대해 하나의 Looker 인스턴스가 필요합니다. 예를 들어 개발 단계, 품질 보증 단계, 프로덕션 단계가 있는 시스템에는 3개의 개별 인스턴스가 필요합니다. 인스턴스는 Google에서 호스팅하거나 고객이 호스팅할 수 있습니다.
동일한 연결 이름
데이터베이스 연결은 각 Looker 인스턴스 내에서 해당 인스턴스가 나타내는 등급에 관계없이 동일한 이름을 사용해야 합니다. 예를 들어 sales
연결은 모든 인스턴스에서 sales_dev
또는 sales_qa
가 아닌 해당 이름을 사용해야 합니다.
연결은 동일한 데이터베이스 또는 서로 다른 데이터베이스를 가리킬 수 있습니다. 그러나 연결이 동일한 데이터베이스를 가리키는 경우 개발 또는 품질 보증 인스턴스의 영구 파생 테이블이 프로덕션에 방해가 되지 않도록 연결에 서로 다른 스크래치 스키마가 정의되어 있어야 합니다.
예를 들어 3개 인스턴스 모두에 동일한 데이터베이스가 사용되는 경우 다음과 같이 구성할 수 있습니다.
프로덕션 | 품질 보증 | 개발 | |
연결 이름 | sales |
sales |
sales |
데이터베이스 | sales_db |
sales_db |
sales_db |
스크래치 스키마 | prod_sales_scratch |
qa_sales_scratch |
dev_sales_scratch |
또는 고유 데이터베이스가 3개 인스턴스 모두에 사용되는 경우 다음과 같이 구성할 수 있습니다.
프로덕션 | 품질 보증 | 개발 | |
연결 이름 | sales |
sales |
sales |
데이터베이스 | sales_db_prod |
sales_db_qa |
sales_db_dev |
스크래치 스키마 | sales_scratch |
sales_scratch |
sales_scratch |
Git 저장소
3개 계층 모두에서 각 프로젝트에 대해 단일 git 저장소가 사용됩니다. 개발 인스턴스는 main
브랜치를 추적하지만 품질 보증 및 프로덕션 인스턴스는 일반적으로 git 태그를 가리킵니다(자세한 내용은 뒷부분에 설명).
최초 설정 단계
이 섹션의 단계는 Looker 관리자 권한과 git 공급업체에 대한 관리자 권한이 있는 사용자가 한 번만 완료하면 됩니다.
Git 사용자 인증 정보
각 개발자의 Linux 환경은 LookML을 관리하는 데 사용하는 것과 동일한 저장소에 연결해야 합니다. 이 저장소는 GitHub와 같은 서비스에서 호스팅되는 외부 저장소일 수 있습니다. 저장소를 구성하려면 적절한 사용자 인증 정보가 있는 서비스의 계정이 필요합니다. 계정을 사용하면 Linux 환경에서 해당 서비스에 자동으로 연결하도록 SSH 키를 설정할 수 있습니다.
GitHub의 경우 GitHub 계정에 새 SSH 키 추가의 안내를 따르세요.
Git 서버 저장소 만들기 및 구성
CI/CD 워크플로가 작동하려면 LookML을 git 저장소에 저장하고 Looker 프로젝트에 연결해야 합니다. 프로젝트 설정에서 Git 프로덕션 브랜치 이름을 main
으로 설정하고 고급 배포 모드 사용 설정을 사용 설정해야 합니다.
다음 단계를 아직 수행하지 않은 경우 GitHub에 대한 다음 안내를 따르세요.
새 저장소 만들기
- GitHub UI의 오른쪽 상단에 있는 + 버튼을 누른 다음 +를 선택합니다.
- 소유자(조직일 가능성이 높음)를 선택하고 REPOSITORY_NAME을 입력합니다.
- 저장소를 공개 또는 비공개로 설정할지 선택하고(비공개 저장소에는 유료 GitHub 구독이 필요함) 체크박스를 선택하여 README 파일로 초기화합니다.
- 저장소 만들기 버튼을 누릅니다.
- <> 코드 라벨이 지정된 녹색 버튼을 누르고 SSH URL을 복사합니다.
git@github.com:org_name/REPOSITORY_NAME.git
와 같이 표시됩니다. - Looker에서 새 프로젝트를 만듭니다.
- 개발 모드로 전환하고 왼쪽 사이드바에서 프로젝트 설정 항목을 선택한 다음 Git 구성을 선택합니다.
- 저장소 URL(이 예시에서는
git@github.com:org_name/REPOSITORY_NAME.git
)을 붙여넣고 계속을 선택합니다. - 배포 키를 복사하고 이 저장소의 GitHub UI로 돌아갑니다.
- 설정을 선택한 다음 배포 키를 선택합니다.
- 배포 키 추가 버튼을 클릭하고 키 필드에 배포 키를 붙여넣습니다.
Looker-REPOSITORY_NAME
과 같은 제목을 추가하고 쓰기 액세스 허용 체크박스를 선택한 다음 키 추가 버튼을 누릅니다.- Looker로 돌아가서 설정 테스트 및 완료를 선택합니다.
- 왼쪽 사이드바에서 프로젝트 설정을 다시 선택합니다. Git 프로덕션 브랜치 이름을
main
으로 변경합니다. - 고급 배포 모드 사용 설정을 선택하고 프로젝트 구성 저장을 선택합니다.
왼쪽의 프로젝트 설정 아이콘 아래에 Deployment Manager의 배포 아이콘이 표시됩니다.
기존 저장소 사용
- LookML을 저장하는 GitHub 저장소로 이동합니다.
- <> 코드 라벨이 지정된 녹색 버튼을 누르고 SSH URL을 복사합니다.
git@github.com:org_name/REPOSITORY_NAME.git
와 같이 표시됩니다. - Looker에서 새 프로젝트를 만듭니다.
- 개발 모드로 전환하고 왼쪽 사이드바에서 프로젝트 설정 항목을 선택한 다음 Git 구성을 선택합니다.
- 저장소 URL(이 예시에서는
git@github.com:org_name/REPOSITORY_NAME.git
)을 붙여넣고 계속을 선택합니다. - 배포 키를 복사하고 이 저장소의 GitHub UI로 돌아갑니다.
- 설정을 선택한 다음 배포 키를 선택합니다.
- 배포 키 추가 버튼을 클릭하고 키 필드에 배포 키를 붙여넣습니다.
Looker-REPOSITORY_NAME
과 같은 제목을 추가하고 쓰기 액세스 허용 체크박스를 선택한 다음 키 추가 버튼을 누릅니다.- Looker로 돌아가서 설정 테스트 및 완료를 선택합니다.
- 왼쪽 사이드바에서 프로젝트 설정을 다시 선택합니다. Git 프로덕션 브랜치 이름을
main
으로 변경합니다. - 고급 배포 모드 사용 설정을 선택하고 프로젝트 구성 저장을 선택합니다.
왼쪽의 프로젝트 설정 아이콘 아래에 Deployment Manager의 배포 아이콘이 표시됩니다.
GitHub 작업 만들기
LookML 변경사항이 적용될 때마다 다양한 검사가 자동으로 수행되도록 여러 GitHub 작업을 만드는 것이 유용합니다. 이러한 작업을 추가하려면 Linux 환경에서 Git 저장소를 변경할 수 있어야 합니다. 아직 사용할 수 없는 경우 Git 구성 안내를 따르세요.
GitHub 작업을 추가하려면 Linux 환경의 저장소 디렉터리로 이동하고 .github/workflows
하위 디렉터리를 추가합니다. 설정이 완료되면 GitHub UI의 작업 페이지에서 이러한 작업을 수동으로 실행할 수 있습니다.
LAMS(Look-At-Me-Sideways)
LAMS는 LookML에서 오류 및 잘못된 사례를 검사하는 오픈소스 린터입니다. 다음 콘텐츠가 포함된 lams.yml
이라는 파일을 .github/workflows
디렉터리에 추가합니다.
name: LAMS
on:
pull_request:
branches: [ main ]
push:
workflow_dispatch:
jobs:
lams_job:
runs-on: ubuntu-latest
name: LAMS LookML Linter Job
steps:
- name: Checkout your LookML
uses: actions/checkout@v1
- name: Setup Node
uses: actions/setup-node@v1
with:
node-version: '16.x'
- name: Install LAMS
run: npm install -g @looker/look-at-me-sideways@3
- name: Run LAMS
run: lams --reporting=no
커밋이 GitHub로 푸시되거나 코드와 main
브랜치를 병합하기 위해 pull 요청이 열릴 때마다 LAMS가 실행됩니다.
Release Please
Release Please는 적절한 버전 번호로 출시 버전에 자동으로 태그를 지정하는 오픈소스 도구입니다.
다음 콘텐츠가 포함된 release-please.yml
이라는 파일을 .github/workflows
디렉터리에 추가합니다.
name: release-please
on:
push:
branches:
- main
workflow_dispatch:
permissions:
contents: write
pull-requests: write
jobs:
release-please:
runs-on: ubuntu-latest
steps:
- uses: google-github-actions/release-please-action@v3
with:
release-type: simple
package-name: sales_project
기존 커밋
이 GitHub 작업은 기존 커밋 표준을 준수하는 제목으로 pull 요청이 열리도록 합니다.
다음 콘텐츠가 포함된 lint_pr_title.yml
이라는 파일을 .github/workflows
디렉터리에 추가합니다.
name: "Lint Pull Request Title"
on:
pull_request_target:
types:
- opened
- edited
- synchronize
jobs:
main:
name: Validate PR title
runs-on: ubuntu-latest
steps:
- uses: amannn/action-semantic-pull-request@v5
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
GitHub로 변경사항 푸시
마지막으로 다음 명령어를 사용하여 이러한 GitHub 작업 변경사항을 커밋하고 GitHub로 푸시합니다.
git add .github/workflows/
git commit -m "chore: Added github actions"
git push
main
브랜치 보호
일반 개발자가 변경사항을 해당 브랜치에 직접 푸시할 수 없도록 GitHub UI에서 main
브랜치에 브랜치 보호를 사용 설정해야 합니다. 대신 다른 브랜치에서 변경한 후 pull 요청을 엽니다. pull 요청을 승인하고 main
과 병합하기 전에 다른 개발자가 pull 요청을 검토할 수 있습니다.
브랜치 보호를 구성하려면 저장소의 GitHub UI로 이동하여 설정, 브랜치를 차례로 선택하고 브랜치 보호 규칙 추가 버튼을 누릅니다.
브랜치 이름 패턴으로 main
을 입력하고 다음 옵션을 선택합니다.
- 병합 전에 pull 요청 필요
- 승인 필요
- 새 커밋이 푸시될 때 비활성 pull 요청 승인 닫기
마지막으로 페이지 하단에서 만들기 버튼을 누릅니다.
pull 요청이 생성되면 이 안내의 앞부분에서 구성한 GitHub 작업이 실행됩니다. 처음 실행한 후 이 UI에서 선택할 수도 있으므로 pull 요청을 main
에 병합하려면 먼저 성공해야 합니다.
pull 요청 구성
Looker에서 pull 요청을 사용하도록 요구하고 개발자를 대신하여 Looker가 PR을 열도록 할 수 있습니다. 개발 인스턴스에 대해서만 구성해야 합니다. 품질 보증 및 프로덕션 인스턴스는 고급 배포 모드를 사용하여 업데이트를 받습니다.
각 프로젝트의 프로젝트 설정으로 이동하여 GitHub 통합 제목 아래에서 pull 요청 필요를 선택하여 이를 사용 설정합니다.
버튼을 눌러 웹훅 보안 비밀을 설정하고, 생성된 임의의 문자열을 복사하고, 프로젝트 구성 저장 버튼을 누릅니다.
저장소의 GitHub UI로 돌아가서 설정을 선택한 다음 웹훅을 선택합니다. 오른쪽 상단에서 웹훅 추가 버튼을 누릅니다.
- 페이로드 URL 라벨이 지정된 필드에
https://LOOKER_HOST_NAME/webhooks/projects/PROJECT_NAME/deploy
를 입력합니다. - 보안 비밀 라벨이 지정된 필드에 Looker에서 저장한 보안 비밀을 붙여넣습니다.
- 어떤 이벤트에서 이 웹훅을 트리거하시겠어요?라는 질문에서 개별 이벤트 직접 선택을 선택합니다.
pull 요청 및 푸시가 선택되었는지 확인합니다.
마지막으로 페이지 하단에서 웹훅 추가 버튼을 누릅니다.
각 Looker 개발자의 설정 단계
다음 설치 단계는 모두 Linux 환경에서 수행해야 합니다.
Ruby 설치
Gazer를 실행하려면 Ruby 프로그래밍 언어를 설치해야 합니다. 2.7.7 이후의 모든 Ruby 버전은 Gazer에서 작동하지만 Ruby 3.xx를 사용하는 것이 좋습니다. Ubuntu Linux에 Ruby를 설치하려면 다음 명령어를 실행합니다.
sudo apt update
sudo apt install ruby
ruby -v
를 실행하여 Ruby가 올바르게 설치되었는지 확인합니다. 이렇게 하면 다음과 비슷한 응답이 표시됩니다.
ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux]
이러한 명령어는 Debian Linux, Linux Mint, 그리고 Aptitude 패키지 관리자를 사용하는 여러 다른 Linux 버전에서도 작동합니다. 다른 Linux 버전에서 작동하는 명령어 또는 macOS에 설치하기 위한 명령어를 검색해야 할 수도 있습니다. 자세한 내용은 Ruby 설치를 참조하세요.
Gazer 설치
Gazer는 Google 직원이 명령줄 도구를 사용하여 스페이스, Look, 대시보드를 탐색하고 관리하기 위해 만든 오픈소스 프로젝트입니다.
Ruby가 설치된 경우 Ruby의 Gem 도구를 사용하여 Gazer를 설치할 수 있습니다.
gem install gazer
gzr version
명령어를 사용하여 Gazer가 설치되었는지 확인합니다. 이렇게 하면 다음과 비슷한 응답이 표시됩니다.
v0.3.12
Spectacles 설치
Spectacles는 LookML을 테스트하는 데 사용되는 Google 이외의 도구입니다. Spectacles는 유료 버전과 오픈소스 버전을 모두 제공하며, 설치에 관한 세부정보는 시작하기 페이지에서 확인할 수 있습니다.
Git 설치
다음 명령어를 사용하여 Ubuntu Linux에 Git 버전 제어 소프트웨어를 설치할 수 있습니다.
sudo apt update
sudo apt install git
git --version
명령어를 사용하여 설치가 성공했는지 확인합니다. 이렇게 하면 다음과 비슷한 응답이 표시됩니다.
git version 2.42.0.609.gbb76f46606
이러한 명령어는 Debian Linux, Linux Mint, 그리고 Aptitude 패키지 관리자를 사용하는 여러 다른 Linux 버전에서도 작동합니다. 다른 Linux 버전에서 작동하는 명령어를 검색해야 할 수도 있습니다. 예를 들어 Fedora 및 macOS에 대한 안내는 시작하기 - Git 설치에서 확인할 수 있습니다.
Git 구성
Linux 환경의 Git은 LookML이 저장된 Git 저장소와 상호작용하도록 구성해야 합니다. 이 안내는 GitHub에 저장된 LookML Git 저장소용으로 작성되었습니다.
이름 및 이메일
GitHub(및 대부분의 다른 Git 구현)에서는 활동을 기록할 수 있도록 이름과 이메일 주소를 알아야 합니다. 다음 명령어를 실행하여 Git에서 이름과 이메일을 구성합니다.
git config --global user.name "FIRST_NAME LAST_NAME"
git config --global user.email "EMAIL_ADDRESS"
Git 사용자 인증 정보
초기 CI/CD 설정에서 git 사용자 인증 정보가 생성되었습니다. 생성된 비공개 SSH 키는 $HOME/.ssh/config
파일에 구성해야 합니다. 파일을 만들려면 다음 명령어를 사용합니다.
touch $HOME/.ssh/config
chmod 600 $HOME/.ssh/config
다음 텍스트를 $HOME/.ssh/config
파일에 복사합니다.
Host github.com
User git
IdentityFile ~/.ssh/KEY_NAME
ControlMaster auto
ControlPath ~/.ssh/ctrl-%r@%h:%p
ControlPersist yes
KEY_NAME 대신 GitHub 계정에 새 SSH 키 추가 안내에 따라 생성한 비공개 키 파일의 이름을 사용합니다. 비공개 키 파일은 공개 키 파일과 이름이 같지만 .pub
확장자가 없습니다. 예를 들어 id_ed25519.pub
파일에서 찾은 공개 키를 사용한 경우 비공개 키의 이름은 id_ed25519
입니다.
로컬 Git 저장소 설정
LookML 저장소를 구성한 후 Linux 환경에서 해당 복사본을 만들어야 합니다. 이렇게 하려면 다음 명령어를 실행합니다.
git clone GIT_URL
예를 들어 명령어가 다음과 같이 나타날 수 있습니다.
git clone git@github.com:my_org_name/sales_project.git
이렇게 하면 LookML 저장소가 sales_project
와 같은 하위 디렉터리에 복사됩니다. cd SUB_DIRECTORY
명령어를 사용하여 저장소로 이동합니다. 이 예시에서 명령어는 cd sales_project
입니다.
저장소의 디렉터리에서 다음 명령어를 사용할 수 있습니다.
명령어 | 목적 |
---|---|
git checkout BRANCH_NAME |
브랜치를 전환하는 데 사용됩니다. 대부분의 경우 기본 브랜치는 main 이라고 합니다. 하지만 이전 시스템에서는 master 로 불릴 수 있습니다. |
git fetch |
서버의 최신 변경사항을 검색하는 데 사용됩니다. |
git pull |
체크아웃된 로컬 파일에 변경사항을 적용하는 데 사용됩니다. git pull 은 암시적으로 git fetch 를 수행합니다. |
git tag |
특정 버전에 의미 있는 태그를 만드는 데 사용됩니다. |
git push |
로컬 변경사항을 서버로 푸시하는 데 사용됩니다. |
Gazer 구성
Gazer를 사용하려면 각 개발, 품질 보증, 프로덕션 인스턴스에 대한 API 사용자 인증 정보가 필요합니다. API 사용자 인증 정보를 만드는 방법은 관리자 설정 - 사용자 페이지를 참조하세요. CI/CD 워크플로를 처음 설정한 사용자가 API 사용자 인증 정보를 이미 만들었을 수 있습니다. 이 경우 기존 사용자 인증 정보를 사용할 수 있습니다. 사용자별로 새 사용자 인증 정보를 생성할 필요가 없습니다.
API 사용자 인증 정보는 홈 디렉터리에서 최소한의 권한이 있는 .netrc
파일에 저장합니다. 다음 명령어를 사용하여 올바른 권한이 있는 빈 파일을 만들 수 있습니다.
touch $HOME/.netrc
chmod 600 $HOME/.netrc
파일에 다음과 같은 항목을 추가하되, machine
에는 자체 Looker 서버 호스트 이름, 로그인에는 API client_id
, 비밀번호에는 API client_secret
를 사용합니다. 예를 들면 다음과 같습니다.
machine dev.example.looker.com
login 80ka7nl6lj87ftmn
password u7kw3mj5h2trfz0
machine qa.example.looker.com
login fi3qtv5at5crvd1q
password bdxtaeghnzyz0wm
machine example.looker.com
login k7lr6yv57wvzy9p2
password wcvr5qjd2isbs2s
다음과 같이 각 서버에 간단한 Gazer 명령어를 실행하여 작동하는지 테스트합니다.
gzr user me --host dev.example.looker.com
다음과 비슷한 결과가 표시됩니다.
+----+---------------+---------+----------+------------------+--------------+
| id|email |last_name|first_name|personal_folder_id|home_folder_id|
+----+---------------+---------+----------+------------------+--------------+
|2345|jsm@example.com|Smith |John | 2161| 708|
+----+---------------+---------+----------+------------------+--------------+
이전 명령어가 작동하지 않는 경우 다음과 같이 gzr
명령어 끝에 --port 443
을 추가해야 할 수 있습니다.
gzr user me --host dev.example.looker.com --port 443
Spectacles 구성
Spectacles는 Gazer와 동일한 API client_id
및 client_secret
를 사용합니다. Spectacles 디렉터리에서 각 등급별로 config-TIER.yaml
이라는 파일을 만듭니다(예: config-dev.yaml
). 다음과 같이 해당 등급의 Looker 인스턴스에 맞게 파일에 다음 콘텐츠를 추가합니다.
config-dev.yaml
base_url: https://dev.example.looker.com/
client_id: 80ka7nl6lj87ftmn
client_secret: u7kw3mj5h2trfz0
config-qa.yaml
base_url: https://qa.example.looker.com/
client_id: fi3qtv5at5crvd1q
client_secret: bdxtaeghnzyz0wm
config-prod.yaml
base_url: https://example.looker.com/
client_id: k7lr6yv57wvzy9p2
client_secret: wcvr5qjd2isbs2s
다음 명령어를 실행하고 각 파일 이름을 대체하여 각 파일을 테스트할 수 있습니다.
$ spectacles connect --config-file config-dev.yaml
다음과 비슷한 응답이 표시됩니다.
Connected to Looker version 23.18.60 using Looker API 4.0