Looker 문서를 보고 있습니다. Looker Studio 문서는 https://support.google.com/looker-studio를 참조하세요.

새 Looker 인스턴스 자동 프로비저닝

선택적으로 새 Looker 고객 호스팅 인스턴스를 시작할 때 라이선스 키, 호스트 URL, 초기 사용자 계정과 함께 인스턴스를 자동으로 프로비저닝할 수 있습니다.

이메일 사용자로 새 인스턴스 자동 프로비저닝

처음 시작할 때 Looker는 JAR 파일이 있는 looker 디렉터리에서 provision.yml이라는 파일을 스캔합니다. 이 파일의 형식은 다음과 같습니다.

license_key: "1234-5678-ABCD-EFGH-IJKL"
host_url: "https://looker.mycompany.com"
user:
  first_name: "Ariel"
  last_name: "Q"
  email: "arielq@altostrat.com"
  password: "password123"

Looker 인스턴스가 새롭고 아직 설정되지 않은 경우 지정된 라이선스 키와 제공된 정보의 사용자 계정으로 프로비저닝됩니다.

Looker가 이미 프로비저닝되어 있으면 현재 설정된 라이선스 키 및 호스트 URL이 해당 라이선스 키 및 호스트 URL 값으로 재정의됩니다. 사용자 정보는 무시됩니다. 스테이징 서버의 별도 라이선스 키와 URL을 유지하면서 프로덕션 인스턴스 내부 데이터베이스의 새 사본으로 Looker의 스테이징 인스턴스를 업데이트하는 데 유용합니다.

새 API 사용자로 새 인스턴스 자동 프로비저닝

새 Looker 인스턴스를 시작할 때 초기 API 사용자를 프로그래매틱 방식으로 프로비저닝할 수 있습니다. API 사용자 또는 이메일 사용자를 프로비저닝할 수 있지만 Looker에서 API 사용자와 이메일 사용자의 동시 프로비저닝은 지원되지 않습니다.

API 사용자 인증 정보 생성

API 사용자를 프로비저닝하려면 Looker가 읽고 데이터베이스에 저장하는 클라이언트 ID 및 클라이언트 보안 비밀번호를 생성합니다. 이러한 사용자 인증 정보의 요구사항은 다음과 같습니다.

클라이언트 ID는 길이가 20자여야 합니다.
클라이언트 보안 비밀번호는 24자(영문 기준)여야 합니다.
두 문자열 모두 POST 요청의 본문에 포함될 수 있어야 하므로 영숫자 문자만 사용하는 것이 좋습니다.

예를 들어 Looker는 다음 코드를 사용하여 이러한 사용자 인증 정보를 프로그래매틱 방식으로 생성합니다.

require 'securerandom'

TOKEN_SYMBOLS = "bcdfghjkmnpqrstvwxyzBCDFGHJKMNPQRSTVWXYZ23456789".freeze

def generate_token(size)
  Array.new(size).map { TOKEN_SYMBOLS[SecureRandom.random_number(TOKEN_SYMBOLS.size)] }.join
end

이 코드는 문자열에 오류가 적게 발생하도록 모호한 문자를 방지합니다.

또한 openssl 명령어를 사용하여 적합한 문자열을 생성할 수 있습니다.

openssl rand -hex 10

openssl 명령어 끝에 있는 숫자는 문자열의 바이트 수이므로 클라이언트 ID에 10을, 클라이언트 보안 비밀번호에 12를 사용합니다.

API 사용자 프로비저닝

시작할 때 API를 프로비저닝하려면 looker 디렉터리에 라이선스 키와 호스트 URL이 포함된 provision.yml 파일이 있는지 확인합니다. 예를 들면 다음과 같습니다.

license_key: "1234-5678-ABCD-EFGH-IJKL"
host_url: "https://looker.mycompany.com"

looker 디렉터리에서 0600 권한이 있고 API 사용자 정보를 포함하는 api-provision.yml이라는 파일을 만듭니다. 예를 들면 다음과 같습니다.

user:
  first_name: "Ariel"
  last_name: "Q"
  client_id: "M9hZb8vRh9bSZzdPxw42"
  client_secret: "NMnqBVbHqPsPzTvbZk6xZfV3"

Looker 인스턴스가 데이터베이스에서 사용자를 처리하고 만든 다음에는 시작할 때 이 파일이 삭제되기 때문에 이 파일 외부에서 Secret Manager를 사용하여 이러한 사용자 인증 정보를 저장하는 것이 좋습니다.

시작 시 인스턴스가 비어 있고 사용자가 없는 경우 Looker는 이러한 사용자 인증 정보로 Looker Admin API 사용자를 만들고 디스크에서 api-provision.yml 파일을 삭제합니다.

그런 후 사용자 인증 정보가 내부 데이터베이스에서 삭제되고 더 이상 사용 불가능한 상태가 되기 전에 30분 동안 이러한 사용자 인증 정보를 사용하여 추가 프로비저닝을 수행할 수 있습니다. 이러한 초기 사용자 인증 정보를 제거하면 애플리케이션에 장기 백도어가 생성되는 것을 방지하고 의도된 사용 사례를 프로비저닝으로 엄격하게 유지합니다.