คู่มือนี้จะช่วยคุณเลือกและกำหนดค่าวิธีการตรวจสอบสิทธิ์ที่เหมาะสมสำหรับการติดตั้งใช้งานจริงของ Data Manager API
เลือกสถานการณ์การติดตั้งใช้งาน
เลือกแนวทางการตรวจสอบสิทธิ์ที่ตรงกับสถาปัตยกรรมแอปพลิเคชัน และสภาพแวดล้อมการติดตั้งใช้งาน
- ภาระงานใน Google Cloud: สำหรับภาระงานอัตโนมัติ (เช่น ไปป์ไลน์ ETL, งานแบบกลุ่ม หรือบริการแบ็กเอนด์) ที่ทำงานใน Compute Engine, Cloud Run, Cloud Functions หรือ GKE ให้ใช้ข้อมูลรับรองเริ่มต้นของแอปพลิเคชัน (ADC) ที่มีบัญชีบริการแนบอยู่หรือการรวมศูนย์ของ Workload Identity สำหรับ GKE
- เวิร์กโหลดภายนอก Google Cloud สำหรับเวิร์กโหลดอัตโนมัติที่ทำงานในองค์กรหรือผู้ให้บริการระบบคลาวด์รายอื่นๆ ให้ใช้ ข้อมูลรับรองเริ่มต้นของแอปพลิเคชัน (ADC) กับการรวมศูนย์ Workload Identity หรือคีย์บัญชีบริการ
- ดำเนินการในนามของผู้ใช้: สำหรับแพลตฟอร์มของบุคคลที่สาม และแอปพลิเคชันแบบหลายผู้เช่าที่จัดการบัญชีสำหรับผู้ใช้ภายนอก (เช่น ผู้ลงโฆษณาที่ลงชื่อสมัครใช้ในแพลตฟอร์มของคุณ) ให้ใช้ โฟลว์เว็บเซิร์ฟเวอร์ OAuth 2.0 ที่มีโทเค็นเพื่อรีเฟรชต่อผู้ใช้ หรือลิงก์พาร์ทเนอร์หากคุณเป็นพาร์ทเนอร์ด้านข้อมูลที่ได้รับอนุมัติ
ดูคำแนะนำทั่วไปเกี่ยวกับการตรวจสอบสิทธิ์ของ Google Cloud ได้ที่ แผนผังการตัดสินใจเกี่ยวกับการตรวจสอบสิทธิ์ของ Google Cloud
เวิร์กโหลดใน Google Cloud
เมื่อเรียกใช้ใน Google Cloud ให้ แนบบัญชีบริการกับทรัพยากรการคำนวณโดยตรง หรือ กำหนดค่าการรวมศูนย์ของ Workload Identity สำหรับ GKE ไลบรารีของไคลเอ็นต์ใช้ ADC เพื่อดึงข้อมูลเข้าสู่ระบบแบบมีอายุสั้นสำหรับบัญชีบริการ โดยอัตโนมัติโดยไม่ต้องใช้ไฟล์ข้อมูลเข้าสู่ระบบหรือตัวแปรสภาพแวดล้อม
Compute Engine
เมื่อสร้างอินสแตนซ์เครื่องเสมือน ให้ระบุบัญชีบริการและ ขอบเขต API ของ Data Manager เพื่อให้โทเค็นการเข้าถึงที่เซิร์ฟเวอร์ข้อมูลเมตาของอินสแตนซ์ส่งคืนมีสิทธิ์ที่จำเป็น
gcloud compute instances create INSTANCE_NAME \
--service-account="SERVICE_ACCOUNT_EMAIL" \
--scopes="https://www.googleapis.com/auth/datamanager,https://www.googleapis.com/auth/cloud-platform"
หากต้องการอัปเดตขอบเขตหรือบัญชีบริการในอินสแตนซ์ที่มีอยู่ ให้หยุดอินสแตนซ์ อัปเดตการกำหนดค่าด้วย set-service-account แล้วรีสตาร์ทอินสแตนซ์
gcloud compute instances stop INSTANCE_NAME
gcloud compute instances set-service-account \
INSTANCE_NAME \
--service-account="SERVICE_ACCOUNT_EMAIL" \
--scopes="https://www.googleapis.com/auth/datamanager,https://www.googleapis.com/auth/cloud-platform"
gcloud compute instances start INSTANCE_NAME
Cloud Run
ระบุบัญชีบริการเมื่อติดตั้งใช้งานบริการ
gcloud run deploy SERVICE_NAME \
--image="IMAGE_URL" \
--service-account="SERVICE_ACCOUNT_EMAIL"
Cloud Functions
ระบุบัญชีบริการเมื่อทำให้ฟังก์ชันใช้งานได้
gcloud functions deploy FUNCTION_NAME \
--service-account="SERVICE_ACCOUNT_EMAIL" \
--runtime="RUNTIME" \
--trigger-http
GKE
- เปิดใช้การรวมศูนย์ Workload Identity สำหรับ GKE ในคลัสเตอร์
เชื่อมโยงบัญชีบริการ Kubernetes (KSA) กับบัญชีบริการ Google (GSA) โดยทำดังนี้
# Define the Kubernetes service account member: KUBERNETES_MEMBER="serviceAccount:PROJECT_ID.svc.id.goog[KUBERNETES_NAMESPACE/KUBERNETES_SA_NAME]" # Grant the Workload Identity User role to the Kubernetes service account: gcloud iam service-accounts add-iam-policy-binding \ SERVICE_ACCOUNT_EMAIL \ --role="roles/iam.workloadIdentityUser" \ --member="${KUBERNETES_MEMBER}"ใส่คำอธิบายประกอบบัญชีบริการ Kubernetes ด้วยอีเมลบัญชีบริการของ Google
kubectl annotate serviceaccount KUBERNETES_SA_NAME \ --namespace="KUBERNETES_NAMESPACE" \ iam.gke.io/gcp-service-account="SERVICE_ACCOUNT_EMAIL"ระบุบัญชีบริการ Kubernetes ในข้อกำหนดพ็อด
apiVersion: v1 kind: Pod metadata: name: data-manager-worker spec: serviceAccountName: KUBERNETES_SA_NAME containers: - name: worker image: IMAGE_URL
ยืนยันการเข้าถึง IAM และบัญชี
ก่อนที่จะติดตั้งใช้งานแอปพลิเคชันเวอร์ชันที่ใช้งานจริง ให้ตรวจสอบว่าบัญชีบริการ มีสิทธิ์ที่จำเป็นดังนี้
สิทธิ์ IAM ของ Google Cloud: มอบบทบาทผู้ใช้บริการ (
roles/serviceusage.serviceUsageConsumer) ให้กับบัญชีบริการ ในโปรเจ็กต์ Google Cloud ที่เปิดใช้ Data Manager APIgcloud projects add-iam-policy-binding PROJECT_ID \ --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \ --role="roles/serviceusage.serviceUsageConsumer"สิทธิ์เข้าถึงบัญชีปลายทาง: ให้สิทธิ์เข้าถึงที่จำเป็นแก่บัญชีบริการ ในบัญชีปลายทาง ดูวิธีการทีละขั้นตอนได้ที่หัวข้อตั้งค่าการเข้าถึงบัญชี
ภาระงานภายนอก Google Cloud
เมื่อเรียกใช้โค้ดในศูนย์ข้อมูลในองค์กรหรือผู้ให้บริการคลาวด์รายอื่น ให้เลือกกลไกการตรวจสอบสิทธิ์ต่อไปนี้อย่างใดอย่างหนึ่ง
การรวมศูนย์ Workload Identity (แนะนํา): กําหนดค่าการรวมศูนย์ Workload Identity เพื่อให้แอปพลิเคชันแลกเปลี่ยนข้อมูลเข้าสู่ระบบจากผู้ให้บริการข้อมูลประจำตัวภายนอกเป็นข้อมูลเข้าสู่ระบบ Google Cloud ที่มีอายุสั้นได้โดยไม่ต้องจัดการคีย์บัญชีบริการ สร้างไฟล์การกำหนดค่าข้อมูลเข้าสู่ระบบและระบุให้ ADC โดยใช้ตัวแปรสภาพแวดล้อม
GOOGLE_APPLICATION_CREDENTIALSคีย์บัญชีบริการ (Fallback): หาก Workload Identity Federation ไม่พร้อมใช้งาน ให้สร้างคีย์บัญชีบริการและระบุคีย์ดังกล่าวให้กับ ADC โดยใช้ตัวแปรสภาพแวดล้อม
GOOGLE_APPLICATION_CREDENTIALS
ชุด GOOGLE_APPLICATION_CREDENTIALS
ตั้งค่าตัวแปรสภาพแวดล้อม GOOGLE_APPLICATION_CREDENTIALS เป็นเส้นทางแบบสัมบูรณ์ของไฟล์กำหนดค่าข้อมูลเข้าสู่ระบบการรวมศูนย์ Workload Identity หรือไฟล์คีย์บัญชีบริการ เพื่อให้ไลบรารีของไคลเอ็นต์ค้นหาข้อมูลเข้าสู่ระบบได้โดยอัตโนมัติโดยใช้ ADC
Linux / macOS
ตั้งค่าตัวแปรสภาพแวดล้อมในโปรไฟล์เชลล์หรือสคริปต์การติดตั้งใช้งาน
export GOOGLE_APPLICATION_CREDENTIALS=\
"/path/to/credentials.json"
Windows (PowerShell)
ตั้งค่าตัวแปรสภาพแวดล้อมใน PowerShell ดังนี้
$env:GOOGLE_APPLICATION_CREDENTIALS = `
"C:\path\to\credentials.json"
Docker / คอนเทนเนอร์
เมานต์ไฟล์ข้อมูลเข้าสู่ระบบลงในคอนเทนเนอร์และตั้งค่าตัวแปรสภาพแวดล้อม
ENV GOOGLE_APPLICATION_CREDENTIALS="/secrets/credentials.json"
หรือส่งตัวแปรสภาพแวดล้อมที่รันไทม์
HOST_CREDS="/host/path/credentials.json"
docker run -e GOOGLE_APPLICATION_CREDENTIALS="/secrets/credentials.json" \
-v "${HOST_CREDS}:/secrets/credentials.json:ro" \
IMAGE_NAME
Kubernetes
ติดตั้งข้อมูลเข้าสู่ระบบเป็น Secret และอ้างอิงในสภาพแวดล้อมของพ็อด
apiVersion: v1
kind: Pod
metadata:
name: data-manager-worker
spec:
containers:
- name: worker
image: IMAGE_URL
env:
- name: GOOGLE_APPLICATION_CREDENTIALS
value: "/etc/secrets/google/credentials.json"
volumeMounts:
- name: credentials-volume
mountPath: "/etc/secrets/google"
readOnly: true
volumes:
- name: credentials-volume
secret:
secretName: data-manager-credentials
ตรวจสอบสิทธิ์คำขอ REST และ curl
หากไปป์ไลน์อัตโนมัติของคุณส่งคำขอ HTTP ดิบด้วย curl แทนการใช้
ไลบรารีของไคลเอ็นต์ ให้ใช้ Google Cloud CLI เพื่อตรวจสอบสิทธิ์แบบไม่โต้ตอบและ
จัดการโทเค็นการเข้าถึงโดยไม่ต้องลงนามโทเค็นด้วยตนเอง
ให้สิทธิ์ Google Cloud CLI โดยใช้ไฟล์ข้อมูลเข้าสู่ระบบที่กำหนดค่าไว้ใน สภาพแวดล้อมของคุณ
gcloud auth login --cred-file="${GOOGLE_APPLICATION_CREDENTIALS}"ส่งโทเค็นเพื่อการเข้าถึงที่สร้างขึ้นในส่วนหัว
Authorizationของคำขอ APIcurl -X POST "https://datamanager.googleapis.com/v1/..." \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ -H "Content-Type: application/json" \ -d @request.jsonGoogle Cloud CLI จะแคชโทเค็นเพื่อการเข้าถึงโดยอัตโนมัติและรีเฟรชโทเค็น ก่อนที่จะหมดอายุ
ยืนยันการเข้าถึง IAM และบัญชี
ก่อนที่จะติดตั้งใช้งานแอปพลิเคชันเวอร์ชันที่ใช้งานจริง ให้ตรวจสอบว่าบัญชีบริการ มีสิทธิ์ที่จำเป็นดังนี้
สิทธิ์ IAM ของ Google Cloud: มอบบทบาทผู้ใช้บริการ (
roles/serviceusage.serviceUsageConsumer) ให้กับบัญชีบริการ ในโปรเจ็กต์ Google Cloud ที่เปิดใช้ Data Manager APIgcloud projects add-iam-policy-binding PROJECT_ID \ --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \ --role="roles/serviceusage.serviceUsageConsumer"สิทธิ์เข้าถึงบัญชีปลายทาง: ให้สิทธิ์เข้าถึงที่จำเป็นแก่บัญชีบริการ ในบัญชีปลายทาง ดูวิธีการทีละขั้นตอนได้ที่หัวข้อตั้งค่าการเข้าถึงบัญชี
ดำเนินการในนามของผู้ใช้
แพลตฟอร์มบุคคลที่สาม เช่น แพลตฟอร์มการตลาดและเอเจนซี มักจะต้องส่งคำขอ API ในนามของผู้ลงโฆษณาหลายรายที่ลงชื่อสมัครใช้บริการของตน
ในสถาปัตยกรรมนี้ ให้ใช้ขั้นตอนของเว็บเซิร์ฟเวอร์ OAuth 2.0 แทนการใช้ข้อมูลรับรองเริ่มต้นของแอปพลิเคชันเพื่อรับข้อมูลเข้าสู่ระบบของผู้ใช้ที่มีสิทธิ์เข้าถึงแบบออฟไลน์จากผู้ลงโฆษณาแต่ละราย จากนั้นใช้ข้อมูลเข้าสู่ระบบเหล่านั้นเพื่อกำหนดค่าไลบรารีของไคลเอ็นต์ที่รันไทม์โดยอิงตามบัญชีผู้ลงโฆษณาที่คำขอกำลังจัดการ
ใช้ขั้นตอนเว็บ OAuth 2.0
วิธีตั้งค่าการมอบสิทธิ์ของผู้ใช้สำหรับแอปพลิเคชันแบบหลายผู้เช่ามีดังนี้
ขอสิทธิ์เข้าถึงแบบออฟไลน์: นำผู้ใช้ไปยังหน้าจอขอความยินยอม OAuth ของ Google โดยขอขอบเขต
https://www.googleapis.com/auth/datamanagerด้วยaccess_type=offlineและprompt=consentเซิร์ฟเวอร์ของคุณจะแลกรหัสการให้สิทธิ์เป็น โทเค็นเพื่อการเข้าถึงและrefresh_tokenดูวิธีการแบบทีละขั้นตอนได้ที่ OAuth 2.0 สำหรับแอปพลิเคชันเว็บเซิร์ฟเวอร์จัดเก็บข้อมูลเข้าสู่ระบบอย่างปลอดภัย: จัดเก็บโทเค็นการรีเฟรชของผู้ใช้แต่ละรายอย่างปลอดภัย ในที่เก็บข้อมูลเข้าสู่ระบบที่เข้ารหัสซึ่งเชื่อมโยงกับบัญชีของผู้ใช้ในแพลตฟอร์มของคุณ
เริ่มต้นไลบรารีของไคลเอ็นต์ในรันไทม์: เมื่อส่งคำขอ API ในนามของผู้ใช้ที่เฉพาะเจาะจง ให้สร้างข้อมูลเข้าสู่ระบบของผู้ใช้จากโทเค็นการรีเฟรช ที่คุณจัดเก็บไว้สำหรับผู้ใช้ รวมถึงรหัสไคลเอ็นต์และข้อมูลลับของไคลเอ็นต์สำหรับแอปของคุณ และส่งข้อมูลดังกล่าวเมื่อเริ่มต้นไคลเอ็นต์
.NET
using Google.Ads.DataManager.V1; using Google.Apis.Auth.OAuth2; UserCredential credential = CredentialFactory.FromJsonParameters<UserCredential>( new JsonCredentialParameters { Type = JsonCredentialParameters.AuthorizedUserCredentialType, ClientId = clientId, ClientSecret = clientSecret, RefreshToken = refreshToken }); IngestionServiceClient client = new IngestionServiceClientBuilder { Credential = credential }.Build();Go
import ( "context" datamanager "cloud.google.com/go/datamanager/apiv1" "golang.org/x/oauth2" "golang.org/x/oauth2/google" "google.golang.org/api/option" ) cfg := &oauth2.Config{ ClientID: clientID, ClientSecret: clientSecret, Endpoint: google.Endpoint, } ts := cfg.TokenSource(ctx, &oauth2.Token{RefreshToken: refreshToken}) client, err := datamanager.NewIngestionClient(ctx, option.WithTokenSource(ts))Java
import com.google.ads.datamanager.v1.IngestionServiceClient; import com.google.ads.datamanager.v1.IngestionServiceSettings; import com.google.api.gax.core.FixedCredentialsProvider; import com.google.auth.oauth2.UserCredentials; UserCredentials credentials = UserCredentials.newBuilder() .setClientId(clientId) .setClientSecret(clientSecret) .setRefreshToken(refreshToken) .build(); IngestionServiceSettings settings = IngestionServiceSettings.newBuilder() .setCredentialsProvider(FixedCredentialsProvider.create(credentials)) .build(); try (IngestionServiceClient client = IngestionServiceClient.create(settings)) { // Send API requests using client... }Node.js
const {IngestionServiceClient} = require('@google-ads/datamanager').v1; const {UserRefreshClient} = require('google-auth-library'); const authClient = new UserRefreshClient({ clientId, clientSecret, refreshToken, }); const client = new IngestionServiceClient({authClient});PHP
use Google\Ads\DataManager\V1\Client\IngestionServiceClient; use Google\Auth\Credentials\UserRefreshCredentials; $credentials = new UserRefreshCredentials( null, [ 'client_id' => $clientId, 'client_secret' => $clientSecret, 'refresh_token' => $refreshToken, ] ); $client = new IngestionServiceClient(['credentials' => $credentials]);Python
from google.ads.datamanager_v1 import IngestionServiceClient from google.oauth2.credentials import Credentials credentials = Credentials.from_authorized_user_info({ "client_id": client_id, "client_secret": client_secret, "refresh_token": refresh_token, }) client = IngestionServiceClient(credentials=credentials)Ruby
require "google/ads/data_manager/v1" require "googleauth" credentials = Google::Auth::UserRefreshCredentials.new( client_id: client_id, client_secret: client_secret, refresh_token: refresh_token ) client = Google::Ads::DataManager::V1::IngestionService::Client.new do |config| config.credentials = credentials end
ยืนยันการตรวจสอบแอป OAuth ให้เสร็จสมบูรณ์
เนื่องจาก https://www.googleapis.com/auth/datamanager เป็นขอบเขตที่ละเอียดอ่อน แอป Google Cloud
ที่ใช้เพื่อรับข้อมูลเข้าสู่ระบบของผู้ใช้จากบัญชี Google ภายนอกจึงต้องผ่านการยืนยัน OAuth ของ Google ก่อนที่จะเข้าสู่การใช้งานจริง
- การพัฒนา: ขณะที่สถานะการเผยแพร่ของแอปตั้งค่าเป็นการทดสอบในหน้ากลุ่มเป้าหมายใน Google Cloud Console มีเพียงบัญชีทดสอบที่กำหนดเท่านั้นที่สามารถให้สิทธิ์แอปพลิเคชันของคุณได้
- เวอร์ชันที่ใช้งานจริง: ก่อนที่จะทำให้แอปพลิเคชันพร้อมให้บริการแก่ผู้ใช้ภายนอก ให้ตั้งสถานะการเผยแพร่เป็นเวอร์ชันที่ใช้งานจริงและ ส่งแอปเพื่อรับการยืนยัน
ไม่จำเป็นต้องมีการตรวจสอบแอปสำหรับเวิร์กโหลดที่ทำงานโดยใช้บัญชีบริการ นอกจากนี้ ยังมีข้อยกเว้นบางอย่างสำหรับสถานการณ์ต่างๆ เช่น แอปพลิเคชันภายใน ดูรายละเอียดได้ที่หัวข้อกรณีที่ไม่จำเป็นต้องยืนยัน
ทางเลือก: ลิงก์พาร์ทเนอร์
หากองค์กรของคุณเป็นพาร์ทเนอร์ด้านข้อมูลที่ได้รับอนุมัติ คุณสามารถใช้ลิงก์พาร์ทเนอร์แทนการจัดการโทเค็น OAuth ต่อผู้ใช้แต่ละรายสำหรับการนำเข้าข้อมูลอย่างต่อเนื่อง
ลิงก์พาร์ทเนอร์ช่วยให้ผู้ลงโฆษณาสามารถเชื่อมต่อบัญชีของตนกับบัญชีพาร์ทเนอร์ด้านข้อมูลใน UI ของ Google Ads, Display & Video 360 หรือ Google Ad Manager หลังจากสร้างลิงก์แล้ว แอปพลิเคชันจะส่งคำขอการส่งผ่านข้อมูลโดยใช้ข้อมูลเข้าสู่ระบบของบัญชีบริการของคุณเอง ผ่าน ADC ซึ่งช่วยให้ไม่ต้องจัดเก็บและดูแลรักษาโทเค็นการรีเฟรชของผู้ใช้ ที่มีอายุยาวนาน
แนวทางปฏิบัติแนะนำในการผลิต
โปรดพิจารณาข้อควรพิจารณาที่สำคัญด้านการดำเนินงานต่อไปนี้เมื่อย้ายไปยังเวอร์ชันที่ใช้งานจริง
- การจัดการข้อผิดพลาดและการตรวจสอบ: ทำความเข้าใจวิธีที่ API ตรวจสอบคำขอโดยใช้โมเดลการล้มเหลวอย่างรวดเร็วและแสดง รายละเอียดข้อผิดพลาดที่มีโครงสร้าง
- กลยุทธ์การลองใหม่: ใช้ Exponential Backoff ที่มี Jitter สำหรับข้อผิดพลาดของเซิร์ฟเวอร์แบบชั่วคราว
- การประมวลผลเป็นกลุ่มและการทำงานพร้อมกัน: เพิ่มปริมาณงานสูงสุดโดย การประมวลผลเรคคอร์ดเป็นกลุ่มและส่งคำขอพร้อมกันภายในขีดจำกัด
- การวินิจฉัยและการตรวจสอบ: บันทึกรหัสคำขอ การตอบกลับและค้นหาบริการวินิจฉัยเพื่อยืนยันการประมวลผลแบบไม่พร้อมกัน และตรวจหาคำเตือนและข้อผิดพลาด