선택적으로 새 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요청의 본문에 포함될 수 있어야 하므로 클라이언트 ID와 클라이언트 보안 비밀번호에 영숫자 문자만 사용하는 것이 좋습니다.
예를 들어 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 파일을 삭제합니다.
새 사용자로 로그인한 후에는 프로비저닝된 API 사용자가 Looker에 의해 자동으로 삭제되므로 추가 관리자 사용자를 하나 이상 만들어야 합니다.
프로비저닝된 사용자 인증 정보 자동 삭제
프로비저닝된 API 사용자는 새 인스턴스를 프로비저닝하기 위한 용도로만 사용되며 인스턴스에 무기한으로 남아 있지 않습니다.
다음 조건 중 하나가 충족되면 Looker에서 프로비저닝된 API 사용자를 자동으로 삭제합니다.
- 프로비저닝된 API 사용자 이외의 관리자 사용자가 인스턴스에 로그인했습니다.
- 프로비저닝된 API 사용자가 처음 로그인한 후 50분이 지났습니다.
따라서 프로비저닝된 사용자로 처음 로그인한 후 즉시 하나 이상의 추가 관리자 사용자를 만드는 것이 중요합니다.